crond runs /bin/sh not /bin/bash

Got caught by this today. Cron jobs normally run /bin/sh, not /bin/bash. It's probably required POSIX behaviour.

Normally most commands run out of cron are not affected because they are not dependent on bash, or the shell script starts with #!/bin/bash. However commands like vncserver which start up desktops (e.g. with the @reboot time spec) can be sensitive to the shell used because of environment scripts in /etc/profile.d.

Therefore if you want to ensure that the cron job works the same whether run interactively or from a crontab, specify the shell. E.g.

@reboot SHELL=/bin/bash /usr/bin/vncserver ...

VM in VirtualBox using unbound WiFi interface on host

I have a Linux host with 2 interfaces, a wired gigabit Ethernet and WiFi. Currently only the wired interface is connected. I wanted to experiment using WiFi interface by a VM guest in VirtualBox. There are various scenarios for this. I might want to test network routing by using the WiFi in conjunction with a smartphone offering tethering. Or access the Internet using from a VM on the desktop using the smartphone when the broadband connection is down.

The short answer is yes, this is eminently possible. The key points to take away are that, 1. the host has to configure the WiFi interface, i.e. load the appropriate driver and authenticate to the access point but not assign an IP address to it, and 2. the guest has to use bridging to access the host's WiFi interface. In fact it will appear to be a wired interface to the guest. All the usual IP configuration methods are available, static or DHCP, depending on what the access point allows. Also note that the MAC address seen by the gateway will be the MAC of the guest, not the MAC of the WiFi interface.

XFS partition created under CentOS 7 cannot be mounted on CentOS 6

Found this out the hard way. Error message is invalid FS type, i.e. not backward compatible. You have to backup the contents and restore to a partition created under CentOS 6.

Deploying SSSD for authentication against Windows AD in CentOS 6

In an earlier post I discussed in general terms deploying SSSD on CentOS 7 which is fairly straightforward once the right choices have been made.

I have now successfully deployed it on CentOS 6. This blog post by one of the authors of SSSD gave me the initial clues. The key point is that while sssd and associated packages are available on CentOS 6, realmd is not so you have to do those steps manually using adcli.

There was one big problem though, the join command didn't work for me! When it came to that step I got an error message saying I had insufficient permissions to modify the computer entry in AD. I tried various permutations but still got the same error.

Finally I decided to examine the progress messages of realm -v join on a CentOS 7 machine to see what it was doing under the hood. It turned out to be a command of this form:

net -s /tmp/sssd-smb.tmpfile ads join example.com

So it was using the Samba net command, not adcli for joining!

The temporary file providing the settings to net was of the form:

[global]
workgroup = EXAMPLE
netbios name = MYWORKSTATION-N
realm = EXAMPLE.COM
kerberos method = system keytab
security = ads

Note that the netbios name should be truncated to 15 characters. The reason net is used is explained in the last comment of this bug report.

Now I don't know if realm switched to calling net when it detected that adcli would not work, or uses net since that blog post was written, to satisfy servers that don't allow creation/modification of computer entries with LDAP. I think the latter because realmd comes from the CentOS repo while adcli comes from EPEL repo so can't be a dependency. I suppose I could look at the code.

The next command that realm runs is:

net -s /tmp/sssd-smb.tmpfile ads keytab create

Once that is done, you will be able to run klist -k and get output. Then follow the rest of the blog post to set up sssd. If you were running /etc/passwd authentication, remember to delete those entries in passwd, group, shadow, and gshadow so that they don't mask the user entries from AD. Restart nscd to flush any cached entries afterwards. In the long term you want to follow RedHat's recommendations referred to in my CentOS 7 blog post to disable nscd caching for user and group entries.

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.

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.

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.