Kerberos and libvirt

Do you remember my latest libvirt ranting and the recent post about Kerberos and NFSv4 don’t you? Well, let’s tie the two up and consider a couple of good and bad things related to both.

First of all, as Daniel Berrange pointed out, QEmu does support IPv6; unfortunately it doesn’t seem to work just as he supposed it to: even though my hostname resolves to both IPv4 and IPv6, QEmu by default only listens to v4. The same goes if you don’t provide a listening socket (such as “”), and again the identical same happens with the default setting provided by libvirt ( You can force it to listen to v6 by either providing a v6-only hostname, a v6 IP address or the v6 catch-all [::] which makes it work on both v6 and v4, lovely, isn’t it?

Then, about libvirt-remote, as many pointed out it is possible to use it with SSH as user, but there are two catches there: the first is that with the way the arguments are passed down from virt-manager down to libvirt, to ssh and zsh on the other side, something goes funky; it works fine with bash because it splits the parameters again, but with zsh as login shell for my user it tries to call a binary called nc -U ... which as you might have guessed is not correct. The second problem is that even if you set the unix socket access for your user, it won’t let it work if you are using SSH and the system is configured with PolicyKit. I guess this was designed to work in two distinct configuration (desktop and server) and trying to mix the two creates a bit of trouble.

This does not solve two problems though: the dangling connections that are kept alive even after closing virt-manager and its inability to provide diagnostic more human-readable than the Python exceptions. This became tremendously obvious today as I went to consider the idea of using Kerberos for the authentication of libvirt itself, given that it can do that via SASL. It would make more sense, since I’ll be having a Kerberos install anyway at this point, to use the Kerberos credentials for more than a couple of services.

Using Kerberos for libvirt actually makes quite a bit of sense: you can set up properly TLS support for the connection and have an user-based authentication (rather than the whole host-based authentication that is supported with the TLS-only login). Setting up libvirt itself is not difficult, if it wasn’t for the single problem that most of the documentation tells you to use /etc/libvirt/krb5.keytab while it’ll be looking only at /etc/krb5.keytab by default — maybe it’s worth for Gentoo to change the init script so that it searches for the one documented. After that, I can properly login on the libvirt-remote access with virt-manager and Kerberos…. but I still am having trouble with QEmu and VNC this time around.

Now a little note regarding pambase: as I’ve been brought to note the default configuration used by pambase with the kerberos USE flag enabled might not be well suited for all the sites using Kerberos right now. I know that, but Gentoo never pretended to give perfect defaults, or defaults that suit everybody; on the other hand I think it’s important to give a default for Kerberos in our packaging. I’ll have to talk with Robin or someone else for integrating a default regarding pam_ldap as well, since the LDAP guide we provide is hinting at the wrong solution for the PAM configuration, if the system also want to be a desktop.

Having found a decent way to provide multiple optional login systems for users is actually finally paving the way to provide token-based login that I talked about last year.

ZeroConf and VNC software

I used not to be a maintainer of the ZeroConf idea, but it changed drastically when I started using Mac OS X, that – if we ignore the hard fact that it’s a proprietary operating system – is a pretty good UNIX system where a lot of the configuration details are hidden to the basic users, which in my opinion is a good idea. I’m not a person to suggest always and everytime the hard way.

Being able to discover what is available on the network currently is not only interesting on public access networks like, say, schools where students are allowed to connect their laptops to the LAN, but also for small offices where servers might need to be replaced from time to time, or where printers might come and go out of the network depending on the supply of ink and paper available, as well as small home networks to check which boxes are on and which ones are off, and to see which services are running and which failed to start for instance.

It’s for this reason that I started the porting of nss-mdns to FreeBSD a month or two ago – but I wasn’t able to complete it myself for lack of time, a huge thanks goes to Bruce Simpson who completed the port; I still have to merge it in Gentoo though, damn lack of time.

Anwyway, one of the intersting things of the use of ZeroConf, as I said, is that you don’t have to check if the service was started by a box before launching the client, you just launch it and see if it’s available or not; I liked this quite a bit with KRFB and KRDC (VNC server and client for KDE, respectively) when using SLP, but that required openslp installed and the service running, which is quite annoying; KRFB actually already had advertisement over ZeroConf, but KRDC didn’t pick it up, and also KRFB is quite slow when compared with something newer like x11vnc.

So what did I do? In the little spare time I have in the last few days because of my job I decided to study a bit Avahi and see if I could make x11vnc advertise itself over ZeroConf. I succeeded, and Karl Runge (x11vnc author) accepted the patch (although he’s going to rework it a bit), and waiting for the next release, I’ve put the patched x11vnc on my overlay, as usual.

Now this solved half the problem, KRDC still didn’t pick it up, although Chicken of the VNC found it with Bonjour support just fine. So I looked at the code, KRDC 3.5.5 and 3.5.6 were supposed to actually support DNS-SD discovery of the VNC servers, but the code was placed in such a way that you had to actually enable that manually.. and if SLP support wasn’t enabled (or if the SLP daemon wasn’t running) there was no way that the code was started. Also, it was actually going to spawn and destroy the browser on every scan cycle, which was far from a good idea for what I could see of the design of kdnssd library, so it was better that hte code was almost unreachable.

Today I decided to get it fixed once forever, and with a pretty minimal patch, touching only two files, a source and an header file (to replace the empty destructor with one with a single instruction), I was able to finally discover the VNC servers on the lan, included the modified x11vnc. The patch for krdc is both committed upstream, and in portage with kde-base/krdc-3.5.6-r1 (not in kdenetwork).

Now, this was mostly an exercise for me to get my hands dirty with Avahi, as I think that ZeroConf is a pretty good idea: I loved when I bought the Airport Express to just plug it in, set up the name through the assistant (without need to even telling it where to look for it), and then see the printer available from the two laptops. CUPS instead didn’t discover it, and I had to set it up manually, but with my past experience with CUPS development, I’m not going to try patching this up myself 🙂