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.

How to send email that will expire (Outlook only)

I get notification email from Linux cron jobs. I wanted some way to automatically mark mail as no longer relevant after a week. I recently discovered that there are a couple of mail headers defined for this purpose in RFCs: Expires: and the older, superseded Expiry-date: which is what Outlook uses. They are not honoured by most mail readers though so this tip is specific to Outlook.

I discovered sample code from Internet search. Here is my version in Perl which does the job.


use Net::SMTP;
...
my $expire_time = strftime "%d %b %y %T %Z", localtime(time() + 86400 * 7);
...

$smtp = Net::SMTP->new($mailserver);

...

$smtp->datasend("Expires: $expire_time\n");

$smtp->datasend("Expiry-date: $expire_time\n");

The Net::SMTP module allows one to send arbitrary headers. You can see the required format of the date time string from the strftime() call.

Expired emails are not deleted, but are displayed in desktop Outlook with strikethrough. No effect that I know of in other mail readers, not even the Internet Office 365.

How to change the video resolution in Raspbian PC/Mac Pixel

In case you are not aware, you can also get Raspbian Pixel for your PC or Mac. It's a 32-bit Debian Stretch distro with Raspbian enhancements, notably the Pixel desktop.

One problem is that the default video mode after install is 640x480, rather limiting. I searched a bit for how to change the video resolution but most articles were about Raspbian on the RPi. However this GRUB documentation was the key.

To find the modes available to you, interrupt GRUB's booting with c, then at the grub> prompt, type videoinfo. You will get a list of available modes. This depends on your (real or virtual) video card. In my case I was running under VirtualBox and had sufficient video memory configured. Note a video mode you want, then as root (either via sudo or getting a root shell) do the following:

Edit /etc/default/grub. Change the entry GRUB_GFXMODE which is commented out by default to for example:

GRUB_GFXMODE=1280x1024x32

Check that the file also contains

GRUB_GFXPAYLOAD_LINUX=keep

Run update-grub, which will rewrite the grub.cfg file. Reboot and enjoy your new video resolution.

Addendum: I've found that when the VirtualBox guest additions are installed, a different resolution is used. This can be configured with the program lxrandr. I have to investigate under what circumstances the display switches from the resolution inherited from grub to its own setting.