Wandering Thoughts archives

Comparing RPM versions in the shell

Via Planet Debian I recently read Comparing version numbers in the shell, which sort of suggests using sort -V to compare package version numbers on RPM-derived systems. My reaction to this is kind of mixed, because how good an idea this is depends on what you're trying to do with this comparison.

If you just want to compare generic version numbers, 'sort -V' may do what you want. You should read the coreutils documentation for sort very carefully, especially Details about version sort, because how it works may not be quite what you expect or what you want. You probably want to test it.

If you want to compare version numbers in the same way that RPM does it, so that your idea of a 'newer version' specifically matches what eg 'rpm -U' or 'yum localupdate' would conclude, you should use the rpmdev-vercmp command (it's part of the rpmdevtools package). This uses RPM's actual version comparison code (as exposed through the RPM Python bindings). See 'rpmdev-vercmp -h' for basic usage and then experiment with it; note that it prints output and has somewhat odd status returns. You may also want to see 'rpmdev-sort'.

(If you just care about version numbers, you can ignore the epoch and the release parts of ordinary RPM version numbering; rpmdev-vercmp doesn't require you to supply them.)

If you want to compare the versions of actual RPM packages as rpm and yum do it, you really have to use rpmdev-vercmp and you need to extract full RPM version information about both packages, including their RPM epochs if any. It's a pity that there is no easy command to print out the full version information that rpmdev-vercmp requires (it's a bit complex and annoying for reasons covered here, although for most purposes you can apparently consider a missing epoch number to be equal to an epoch number of '0').

As it turns out, the best approximation of quickly printing out full RPM version information for rpmdev-vercmp purposes is something like:

rpm -q --qf '%{N} %{epochnum}:%{V}-%{R}\n' ...

Note that you should not accidentally give rpmdev-vercmp strings that have the package name in them; it will consider them to be the version and then interpret the version number as the first part of the release numbering (I think).

(I discovered rpmdev-vercmp via this stackoverflow question and its answer when I was researching this entry. Once again writing blog entries has proven usefully educational.)

I'm not very impressed with Ubuntu 14.04 LTS so far

For various reasons I've only recently gotten around to doing anything with Ubuntu 14.04. Specifically I've been working on bringing up our new iSCSI backends on Ubuntu 14.04 instead of 12.04, since this obviously more desirable for machines that we expect to run for four or five years. As a result and to be blunt, I'm not particularly happy with Ubuntu 14.04 right now.

The most serious failure is that Ubuntu 14.04 has switched to the new style 'predictable' Ethernet device names without actually making them stable. On our iSCSI backend hardware the visible names of the 10G interfaces change from boot to boot (and some things suggest that even the management network interface name isn't stable). I fixed this with the blunt hammer of turning off predictable names entirely with 'biosdevname=0' on the kernel command line.

(Inspection of the usual entrails suggests that there is enough system information available that biosdevname should be able to come up with correct names in a stable way. As usual biosdevname does not come up with correct names. 'Predictable Ethernet device names' appears to be 'predictably wrong names' in practice.)

The next issue I ran into is a scary boot time stall with a message from Grub to the effect 'error: diskfilter writes are not supported'. It turns out that this has been an Ubuntu bug with mirrored system disks that's been known for months before 14.04 was released. The bug is harmless apart from giving you five seconds of fright as your system's boot stops, but its presence doesn't impress me with what people call the 'fit and finish' of Ubuntu 14.04.

We're also experiencing a weird SSH issue where with our configuration (which enables host based authentication and SSH (host) key signing), ssh to some hosts will spit out a message saying:

no matching hostkey found
ssh_keysign: no reply
key_sign failed

It does this in the middle of your regular ssh output, which can be kind of a problem. Again, this is at least a fit and finish issue.

(My co-workers are also not happy with 14.04 based on their own work with it, but I'm out of the loop there so I don't know any details.)

All of these leave me unimpressed with 14.04. What really irritates and worries me is that it seems unlikely that any of these will get fixed. Ubuntu has historically not really updated LTS releases apart from security fixes, and none of these three issues are likely to qualify under that policy. Since 14.04 was just released recently, maybe we'll get lucky and Ubuntu will fix these with official updates.

I also don't know if turning off biosdevname based Ethernet naming is officially or practically supported on 14.04. Lack of official support makes me worry that some future Ubuntu update will break things there, which of course would have very bad impacts the next time an iSCSI backend rebooted (or worse, if all of them did at once).

With the recent release of Red Hat Enterprise 7 and CentOS going full steam ahead on a prompt CentOS 7 release, it's now very likely that we'll jettison our previous plan of building our new iSCSI backends on Ubuntu and switch to CentOS 7 instead. At one level the distribution doesn't matter since we don't use any packaged software, but at another level we care a fair bit about whether the thing works and gives us a confident feeling about it. And Ubuntu 14.04 is failing at least the latter at the moment.

An irritating and interesting su change from Ubuntu 12.04 to 14.04

In Ubuntu 12.04, the su manpage describes the -c option with this minimal description:

-c, --command COMMAND

Specify a command that will be invoked by the shell using its -c [option].

In Ubuntu 14.04, the following note was added as well:

The executed command will have no controlling terminal. This option cannot be used to execute interactive programs which need a controlling TTY.

This change broke part of my customary environment. For years I have been su'ing to root but running an alternate shell once I got there by actually doing '/bin/su -c "exec $myshell"' (generally this incantation is hiding behind other scripts). On the traditional su, as found on 12.04 and previous LTS releases as well as on, eg, Fedora, this works fine. On 14.04 my shell started spitting out errors about 'tcsetgrp: Inappropriate ioctl for device' (probably because my shell has readline support these days) and bash complained:

bash: cannot set terminal process group (14684): Inappropriate ioctl for device
bash: no job control in this shell

Contrary to what the manpage says, interactive programs do not actually fail. Pretty much everything runs fine, except of course there's no job control and my shell whined incessantly; the former doesn't bother me since I don't use it anyway, but the latter was rather annoying.

That's the irritating part. The interesting part is why this change was made, because it turns out not to be an arbitrary one; instead it's actually sort of a security fix. In Ubuntu, su comes from the shadow package, which in May of 2012 was updated to a new upstream version that included the following change (from the Ubuntu changelog):

• su: Fix possible tty hijacking by dropping the controlling terminal when executing a command (CVE-2005-4890). Closes: #628843

A longer description of the problem CVE-2005-4890 is about is here, with links to various discussions of the issue. This writeup notes that a number of people don't think that this is a bug and are not fixing it. This includes some Linux distributions and also some upstream authors of versions of su.

(That's right, Linux has multiple versions of su. Fedora 20 uses the util-linux version, for example, and neither Fedora nor the upstream has changed su to fix this CVE's issue.)

On the one hand I can't exactly blame the upstream 'shadow' maintainers for fixing this; it is a possible security issue. On the other hand it is a change to long-standing behavior in order to fix what is very likely to be an extremely rare vulnerability and it doesn't even apply in this situation (since I am su'ing to root, not away from it). So on the whole I selfishly wish that they hadn't changed the behavior of 'su -c', at least for people su'ing to root.

Fortunately the fix is easy. I just need to use '/bin/su -s $myshell' instead of my old incantation. Unfortunately this is slightly less portable as the -s option is not present on things like Solaris (well, OmniOS) while -c goes back to the mists of time.

(I only discovered that this was a CVE fix when I started writing this entry and decided to dig into the exact versions involved, read the changelogs, and so on so that I could write an informed entry. Once again blogging has proved educational.)