External monitor on docking station wakeup on F22

The following situation: I have a laptop and two docking stations (DS), one at work and one at home. Both have an external monitor. My setup is to mirror the screens (same resolution on both) so that I use the external screen and keep the lid closed (I'm not so much a multi-screen person). Further, most of the week I find myself simply plugging in my laptop and hitting the DS power button at work in the morning and putting it to sleep using the DS power button and unplugging it in the evening without ever opening it in between.

Now the problem is, that the mirroring will then not be properly enabled (or for any other reason the external screen does not get a signal). The manual workaround is to open the lid, start the display settings (gnome-control-center display). That will enable the external monitor (I guess during probing). Obviously this is rather annoying over time, so the following describes a workaround. The idea is to react to an event that is triggered on wakeup, check if an external monitor is connected, and if so briefly disable and re-enable it.

Step 1: Add a service called when resuming
That used to be somehow simpler, either through pm-utils or acpid. Now it's the magic of systemd. This is fine, but I wish they would just have a compatibility script calling pm-utils scripts. However, the first thing to do is create a file /etc/systemd/system/resume@.service (exactly that name, in particular with the @ at the end) with the following content (courtesy of the fine Arch Linux power management documentation):

[Unit]
Description=User resume actions
After=suspend.target

[Service]
User=%I
Type=simple
ExecStart=/usr/local/bin/resume.sh %I

[Install]
WantedBy=suspend.target

This simply calls a script with what will be a username. Create /usr/local/bin/resume.sh with the following content:

#!/bin/bash

SCRIPT=/home/$1/bin/resume.sh

if [ -x $SCRIPT ]; then
	$SCRIPT
	exit $?
else
	echo 2
fi

It simply allows to have user-specific resume scripts. You can leave out this middleman and simple add your full script path as ExecStart in the unit file.

Finally, we need to enable the systemd unit for a particular user. In my case this is achieved using sudo systemctl enable resume@tim.service. Edit for your username accordingly.

Step 2: resume script
Add your local resume script in $HOME/bin/resume.sh to contain (at least) the following:

#!/bin/bash

PORT=DP2-2
DOCKED=$(cat /sys/devices/platform/dock.0/docked)

if [ "$DOCKED" != "1" ]; then exit 0; fi

export DISPLAY=:0
export XAUTHORITY=/home/user/.Xauthority

if (xrandr -q|grep $PORT|egrep -qv disconnected); then
	xrandr --output $PORT --off
	sleep 1
	xrandr --output $PORT --preferred
	exit 0
fi

exit 1

This will check if the laptop is docked and otherwise quit. I then checks for the connected display and calls xrandr to disable and re-enable the external screen. Update the PORT variable accordingly (check xrandr output). You can disable the DOCKED check to use this with an arbitrary external monitor.

Maybe this helps another soul to get rid of this problem. However, you'll have a new one afterwards: gnome-shell will often crash on resume. It'll recover (most of the time), but anyway.

More Fedora 22 scrollbar annoyances (fixed)

After my previous encounter with scrollbar annoyances there was one more to fix: the 1px dead zone between the scrollbar and screen edge in Firefox. There was a bug report[/url] for quite some time but not fix, yet. Fortunately, there was [exturl=https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/125734]another bug a few years ago for which a workaround had been posted.

So, if you are also using a track point or just like to grab the scroll bar with your mouse after doing a swift "hit the right edge" create a file ~/.mozilla/firefox//chrome/userChrome.css and add:

hbox#browser { margin-right: -1px !important; }

Hopefully that's the last annoyance (well, almost at least). Besides avoiding the duck and cover for robot development for some time there are other reasons to stick with a Fedora version for longer than just six months...

Disable warping scroll bars

Ever since Gnome 3 I was rather annoyed by the new scroll bar behavior that makes you jump to a place where you click, instead of moving one page in that direction. Most of the time, it's ok since you have a mouse wheel (and I can only guess that was the rationale behind this change) -- most of the time...

With a new laptop (and again with a trackpoint and without a scroll wheel) I was once again annoyed by this behavior and decided to look for a fix. And I found one.

The feature is called "primary button warps slider" and is present in Gtk2 and Gtk3. With Gtk 3 the default changed the default to set it to on. At least on Fedora, the Gtk2 theme also overrides it to set it to true. So the fix is to disable it for Gtk3 and Gtk2 (the latter is crucial to fix it in Firefox).

For Gtk3, edit or create ~/.config/gtk-3.0/settings.ini and add or set:

[Settings]
gtk-primary-button-warps-slider = false

For Gtk2 there is a small catch, edit ~/.gnome2/gtkrc-2.0. Not that editing ~/.gtkrc-2.0 does not work. The reason is that the latter is read before the theme file and consequently settings made there are overwritten, while the one in the ~/.gnome2 directory is read after the theme and allows to overwrite theme values. Thanks to the strace tool for helping me find this. So, fixing Gtk2 is then as simple as adding:

gtk-primary-button-warps-slider = 0

Note that it indeed needs to be zero, false does not work here.

I would guess this should be something for the awesome gnome-tweak-tool.

Update: Turns out that the Gtk2 trick with the ~/.gnome2/gtkrc-2.0 only worked on older versions. I had done the modifications on F20 and F22 at the same time. There seems to be no gtkrc file read after the theme file on F22 (according to strace logs). Therefore, the only way to fix this for Gtk2 (e.g., Thunderbird) on F22 is to modify the theme file. Pity!

Extending VM disk

Consider the following situation: a CentOS 6.2 host (this can also be Fedora or RHEL for that matter) using KVM to run virtual machines (VM). The host uses the Logical Volume Manager (LVM) as storage to create disks for the VMs. Now one of the machines needs more disk space then was originally envisioned and thus the space must be extended. The guest system in turn is also running CentOS 6.2 and itself using LVM to setup its storage.

So we have the following entities to deal with:
Host: The physical machine running CentOS 6.2 and KVM.
Guest: Virtual machine running in KVM.
vg_host/lv_vm: The logical volume on the host system which constitutes the disk drive of the Guest.
/dev/vda2: The second partition on the first virtio disk in the Guest. It contains the only physical volume used on the Guest.
vg_vm: The volume group on the Guest where the only physical volume is /dev/vda2.
vg_vm/lv_root: The logical volume in the Guest volume group which facilitates the root of Guest's filesystem.

To keep things simple we assume that there is only a single mount point for the Guest, i.e. /usr etc. are not split off onto own partitions or logical volumes. Replace vg_host, lv_vm, and vg_vm with the actual values from your system. vgdisplay and lvdisplay can help you to find out about it.

So the following steps are necessary to get more disk space into the VM.

1. On Host: Extend vg_host/lv_vm
2. On Guest Extend /dev/vda2 partition
3. On Guest Extend /dev/vda2 physical volume
4. On Guest Extend vg_vm/lv_root logical volume
5. On Guest Extend vg_vm/lv_root file system

Therefore, execute the following steps.

0. Stop the VM:

virsh shutdown VM

1. On Host: Extend vg_host/lv_vm: this code extends by 10GB, change as appropriate, make sure there is enough free space left in the volume group.

lvresize -L+10G vg_host/lv_vm

2. On Guest Extend /dev/vda2 partition: This is critical, take special care! It is important to choose the proper starting cylinder. The suggested start might be wrong, therefore first print the current start and keep it. Sorry this is the German output, but you should be able to match it properly.

fdisk /dev/vda2
Befehl (m für Hilfe): p
   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/vda1   *           3        1018      512000   83  Linux
Partition 1 endet nicht an einer Zylindergrenze.
/dev/vda2            1018       21391    10267648   8e  Linux LVM
Partition 2 endet nicht an einer Zylindergrenze.
Befehl (m für Hilfe): d
Partitionsnummer (1-4): 2

Befehl (m für Hilfe): n
Befehl  Aktion
   e      Erweiterte
   p      Primäre Partition (1-4)
p
Partitionsnummer (1-4): 2
Erster Zylinder (1-62415, Vorgabe: 1): 1018
Last Zylinder, +Zylinder or +size{K,M,G} (1018-62415, Vorgabe: 62415): 
Benutze den Standardwert 62415

Befehl (m für Hilfe): p

Platte /dev/vda: 32.2 GByte, 32212254720 Byte
16 Köpfe, 63 Sektoren/Spur, 62415 Zylinder
Einheiten = Zylinder von 1008 × 512 = 516096 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000407f8

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/vda1   *           3        1018      512000   83  Linux
Partition 1 endet nicht an einer Zylindergrenze.
/dev/vda2            1018       62415    30944136   83  Linux

You now need to reboot because the partition is currently in use.

3. On Guest Extend /dev/vda2 physical volume: extend to maximal size. Make sure you have rebooted your system or otherwise this won't work (even though it doesn't report any errors).

# pvresize /dev/vda2
  Physical volume "/dev/vda2" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

4. On Guest Extend vg_vm/lv_root logical volume

lvresize -l+100%FREE vg_vm/lv_root

5. On Guest Extend vg_vm/lv_root file system: this can be done while the file system is mounted and active. But you'd probably be screwed on a power failure or so.

resize2fs vg_vm/lv_root

Done! Now df -h should report the full space.

The long road to Kerberos/LDAP/NFSv4 and a shortcut

Recently we got a new server at university. It will replace the current file and authentication server which uses NIS and NFSv3. It provides us with a good opportunity to upgrade to something more secure and efficient. So I took on the journey to setup OpenLDAP as user directory, Kerberos for authentication, and NFSv4 for file sharing. But the way took a little time, only to find out later a shortcut which makes it almost a piece of cake. The long way still provides insightful information, therefore it's still useful to try it do-it-yourself style first.

Rather than writing yet another howto, I will link to documents that I used during the initial setup. The most relevant source is the Kerberos/LDAP/NFSv4 HOWTO. It describes the way pretty much step by step. If you want to replace NIS like us the Replacing NIS with Kerberos and LDAP HOWTO is a good read. We use CentOS 5.6 on the file server. The most common pitfall to run into then is that the NFS code there only supports weak ciphers. As client we used a Fedora 14 machine, which will only try strong ciphers by default (cf. for example Red Hat/Fedora bug reports #652273 and #573968). First edit /etc/krb5.conf and set allow_weak_crypto = yes in the [libdefaults] section. Then make sure to add -e des-cbc-crc:normal to the ktadd command to export keys to the keytab for the NFS service keys (nfs/host@REALM). It is described in the NFSv4 Kerberos Setup Guide, as well as the mentioned howto, but something to be easily missed and hard to diagnose when new to the system. The NFSv4 Linux FAQ provides some tips for NFS problems. Another document describes common Kerberos issues. When googling the Ubuntu NFSv4 HOWTO frequently comes up, but it does not provide much useful additional information.

Once I had it running I was pointed to FreeIPA. It is an integrated solution that combines the 389 directory server, Kerberos, and the Dogtag Certificate System with nice console administration tools and a helpful WebUI. I went straight for version 2.0.0 for which a new Enterprise Identity Management Guide is currently work in progress. FreeIPA 2.0.0 is not perfect, yet, and I had to report a few bugs, but it makes the overall process much easier. You still need to allo weak cryptos if CentOS/RHEL 5 is involved by yourself, IPA won't do that automatically for you. If you run into problems that the authentication fails (add -vvvvv as RPC idmapd and gssd/svcgssd flags to see this), wipe out the keys on both server and client and get new ones with the -e des-cbc-crc:normal for the NFS service keys! The nice people behind the project are extremely helpful if you ask nicely via IRC.

Have fun and enjoy secure authentication and encrypted file sharing as we hopefully will once the system is deployed.