Friday, 16 February 2018

Software whose authors won't update to keep up with advances

Now and then I am frustrated by software that doesn't implement modern functionality. So I'm creating a dynamic list here of the ones I've come across, if only to get the annoyance off my chest. If subsequent changes prove me wrong, let me know in the comments and I'll be more than happy to remove the software from this list.

Fetchmail

Google keeps nagging me to disable less secure apps for my accounts. But I can't do this yet because fetchmail doesn't implement OAuth2. Apparently somebody has submitted changes to implement this but it isn't in the mainline code. I've also started looking at the Perl script fetchgmail. This however requires a lot of Perl modules to support so it was a chore to find the ready-made packages for my distro and use CPAN for the rest. But I may switch to this.

Addendum: A solution to this is to get an application specific password from Gmail settings just for fetchmail. In this case you are not exposing your login password in fetchmail config files.

Filezilla

Filezilla is a useful tool for sftp between hosts. At my workplace the Linux hosts are joined to the domain, and so support gssapi-with-mic from Windows workstations. Quite handy since the user is already authenticated to the domain. Openssh has supported gssapi-with-mic for quite a while, as has Putty. Again someone has submitted changes to Filezilla to implement this feature, but this has not been taken up.

Thursday, 8 February 2018

Experimenting with ext4 encryption on openSUSE Leap 42.3

I decided to encrypt some of my directories both on internal hard disks and external hard disks. One of the reasons for encrypting on an external hard disk is so that I can keep an offsite copy of my files without worrying that somebody who gets hold of the disk can read the files.

The best guide I found was the ArchWiki one. It's succinct but all that is essential is there.

For openSUSE, the kernel is recent enough but the stock e2fsprogs 1.42 package is not. You'll need to download 1.43 sources and compile. These utilities must be the 1.43 version: tune2fs (for enabling the encrypt feature), e2fsck (to deal with the new feature), and of course e4crypt (for adding a key to the kernel keychain). The other utilities can be the stock ones.

A short word about keys. When you add a key with e4crypt, it will attempt to use the key with all filesystems for which the password matches. So if you have been using the same password on several filesystems, all the matching ones will be unlocked.

If you have unlocked a directory and then delete the key from the keychain with keyctl, the encrypted directories on the mounted filesystem remain unlocked. Access will be lost only when you umount.

When assigning policies to directories, you need to use the one for the filesystem it resides on. To avoid confusion if possible you should clear the kernel keychain, and then e4crypt add_key for the target filesystem, then use the corresponding descriptor. Otherwise if you use the descriptor for another filesystem by accident, you will not be able to read the directory when the other filesystem has not been unlocked.

These commands of keyctl will be of most use: show, clear, new_session. You might also want to specify the keyring. Most likely it's @us.

Thursday, 1 February 2018

Reinstating the nouveau driver after having installed the NVidia driver on CentOS 7

Due to the NVidia proprietary driver not working with 3D acceleration on VNC, which meant that users had to use MATE (GNOME 2) on VNC sessions, and couldn't use vino-server for the :0 session if the console desktop was GNOME 3, we decided to try the nouveau driver instead.

The steps for removing the NVidia driver are in this post for Fedora. For CentOS 7 the corresponding steps are:

nvidia-uninstall
yum install -y xorg-x11-drv-nouveau (just in case it wasn't installed)
rm -f /etc/modprobe.d/nvidia-installer-disable-nouveau.conf
rm -f /usr/lib/modprobe.d/nvidia-installer-disable-nouveau.conf
dracut -f
systemctl reboot

Note the removal of the second occurrence of the modprobe blacklist file created by the NVidia installer. Without removing this, the blacklist is still in place in the initramfs.

The symptom was that the nouveau driver was loaded only when the X server was started, not at boot, which caused it to not detect anything but one monitor and only one mode setting, as the output of xrandr showed.