On a Xen Dom0, I needed to apply a kernel upgrade (from 2.6.18-92something to 2.6.18-128something) and as a result, a reboot. At this point you should memorize that the old kernel worked quite fine and all I did was a yum update followed by a reboot. A procedure I did on quite a number of Dom0 machines in the past weeks.

Well, the reboot this time didn’t work, the kernel halted after printing:
request_module: runaway loop modprobe binfmt-464c

Well, reboot again, select old kernel, systems boots fine….

What happened was that both the x86_64 and i686 versions of the old kernel was installed, so yum update updated both, probably first the x86_64 version, then the i686 version (but I didn’t check). Well, while for the old kernel, grub booted the x86_64 kernel with the x86_64 initrd, for the new kernel it tried to boot the i686 kernel with the x86_64 initrd. (verified by unpacking the initrd and the vmlinuz kernel image and running file on the binaries therein)

Now the big question is: How could the stupid yum/rpm/postinstall script system end up doing this? It is supposed to warn about conflicts if two packages ship different versions of the same file AFAICT, but there is no way the i686 and x86_64 versions of /boot/vmlinuz* could be identical. So there should have been a warning about this. And after that, how come the mkinitrd tool doesn’t even try to check wether the kernel architecture and that of the initrd binaries match? It happily packed 64bit binaries and 64bit kernel modules(sic!) when run against a 32bit kernel….

OK, enough of my frustration….
I really wished I had to maintain not RHEL/CentOS machines but Debian (based distro) machines here at work. Unfortunately, that won’t happen for various reasons…

While the bi-arch support in RHEL/CentOS is helpful in many ways, RPM and the way bi-arch works on these distros caused almost as much trouble to me already as it helped avoid.

Eddy Petrișor has a post about transitioning from lilo to grub2 (considering usage of LVM).

Romain Beauxis writes about what he dislikes about git (or probably most distributes version control systems) when it comes to team-maintained packages, to which Martin F. Krafft responded with an interesting post that puts some aspects of distributed versioning into a more balanced perspective then Romain had. After all though, I agree that there are uses to DVCSs which make sense (like being able to commit while not having any sort of connection to the “central” repository). However, I still think that relatively small “projects” like maintaining Debian packages have more to gain from the central repository then from the ability to commit while not connected. That is, at least as long as upstream doesn’t use a DVCS already, in which case there are other benefits from using the same DVCS, like easily pulling in upstream changes.

David Welton posted about a small script that swaps virtual desktops (please note that you will need to enable javascript to actually see the script).

While not technologically new to me, this post by David Pashley about copying files with netcat was a nice summarization of how to do it (and why it is sometime preferable over scp or rsync, plain or over ssh). One of the comments refers to mbuffer, which might also prove useful if you need really high speeds (>200MByte/s) or want some more advanced buffering options. The pv tool (alias Pipe Viewer) might be of interest to meter the throughput.

Phil Hands writes about getting an USB stick to boot (certain) ISO images with the help of grub4dos.

That’s it for now, will update the post if I find more interesting links in the next few days.

1. Sean Finney has a nice post about storing the list of parameters a (shell) script got in a way that it can be restored later. Quite handy if your script walks through the arguments parsing them (and consuming them while doing so) but you want to be able to display them in a helpful way if the parsing fails at some point.
2. A while ago, Ingo Jürgensmann had a post that helps retrieving files from lost+found after a filesystem check, provided that you run his helper script on a regular basis. The same approach can also be used if you have a backup of all files, but lost the sorting work you did after the backup was done. This is possible because running the script can be done more often then you would normally do backups.
3. He also has a small post about mtr oddities when IPv6 comes into play
4. Adeodato Simó wrote about databases and when timestamps that store the timezone information really are more useful then timestamps that don’t.
5. Adeodato also has a short post on using ssh as a socks proxy, which can be quite handy if you are behind a firewall.

Update: Fixed link to Ingo’s file retrieval from lost+found article. Thanks to Patrick Schoenfeld who pointed me at the wrong link.
Also thanks to the anonymous poster who found an alternative way to store and (in a way) restore commandline parameters. The solution doesn’t work in an as general way as that by Sean Finney et al., but it is much shorter and therefore interesting for where it can be used (when you control how commandline parameters are processed). See comments on this post for details.


<VirtualHost a.b.c.d:443>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_443.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_443-key.pem
</VirtualHost>
<VirtualHost a.b.c.d:444>
ServerName a.b.c.d
SSLCertificateFile /etc/ssl/certs/a.b.c.d_444.pem
SSLCertificateKeyFile /etc/ssl/certs/a.b.c.d_444-key.pem
</VirtualHost>

(note: This happened to me when wanting to open a SSL server for subversion on a host that also had Apache run as a reverse/application proxy for some specific application that managed its own CA)

Both VirtualHosts will use the very same certificate and key (as far as I was able to tell, but at least the same key), in my case that of the specific application (which was(is?), in its way, broken regarding SSL).

This might as well be a bug or a design decision (AKA feature), I don’t know. However the “workaround” that worked for us was to change one of the server names to something else (since it seems it is unused anyway, unless the apache decides to generate a self-refering URL, which it certainly won’t do for the reverse/application proxy part).

Update: Fixed formatting on configuration sample to make it clear this is not about namebased virtual hosts.

A friend of mine might need exactly the sort of scripts someone posted here:

1. Creating a list of file checksum+pathname/filename
2. Reading files from lost+found and moving them to their original filename by identifying from the list in (1)

However, I can’t recall who posted about this, and don’t want to do the same work again. Please, Dear Lazyweb, help me

A few years back, I noticed that I often started as a kind of “Joe User” with new applications, and often even stayed that way, often wishing that the UI of that application was simpler or at least made it more obvious which options are important and which I could most likely keep at their defaults.
Yet I am a system administrator and programmer/developer, so most people would probably consider me as an advanced user by default (wether that is correct in any given context or not, for example I still don’t really grok GIMP).
Also I did have quite a lot of contact with users that have very little experience, knowledge and interest in computers and software and only use them to achive certain goals.

Anyway, I’m quite sure most readers of this blog are aware that Linus Torvalds once complained about the Gnome printing dialog being simplified way too much. And at that time, I had to agree (note that I didn’t check out Gnome again since those days, at least 2 years ago).

What I really wonder (especially since I realized this in some of my own applications) is why it is so hard for developers to add some additional checkbox or button that enables/disables advanced options. For example, let’s take an applications printing dialog. By default, it would only allow the selection of a printer, orientation (if sensible) and (if the selected printer supports more than one) the paper size. Now advanced options might include duplex printing (automatic or manual), printing mutliple pages on a single sheet of paper, printing in grey on color printers,…

These options might be of use to anyone, but would most likely confuse beginners. So what I did in most of my little application was to just show the basic options and add an “advanced options” button which provided access to additional functionality which was not normally needed.

As for the issue with firefox updates mentioned by Sami: I don’t think it is a problem that firefox asks what to do with extensions. For one, it only lists extensions which are installed but claim not to support the new version of firefox. Second, practically everyone I know of who uses any extension can be considered to be an advanced user. And third: The dialog is pretty straightforward about what it is asking and when I once hit it while a (”dumb user”) friend was sitting with me, he understood what it was about quite easily (I didn’t explain the dialog, just what extensions were).

So my idea of a good UI is:
As simple as possible for beginning users, but allow advanced users to get to the details (”Details” or “Advanced options” buttons/checkboxes/dialogs).

UPDATE: Since Frederik (see comments) reminded me of the fact I already knew:
This silly translation is not the fault of the german KDE members, but a bug in the Ubuntu package, which is taking more or less random translations from Rosetta.

There is one notable difference though: AJ proposes fallback values which are compatible with existing application paths (i.e. HOME_ETC/XDG_CONFIG_HOME should default to ~/ – resulting in ~/.foo files/dirs). This is a good proposal in a way: If you patch an existing application to strictly follow the proposal made by AJ, it still finds its old configuration (and other files) if the new environment variables are not set. No need to move anything around. However, I think the XDG approach is better since it makes sure that compliant applications don’t clutter ~/ anymore. They do need some mechanism to move existing configurations and data around though if the XDG-compliant stuff isn’t already there, but an old style config exists.

All in all, I think it is worth following the XDG spec, even if it is slightly more complex than AJs proposal. For one, it already exists for a while and I think that some applications already started following that spec. It also makes slightly more sense to me to have the system fully configurable as to where the apps store data as opposed to the hardcoded fallback/default values AJ proposes (even if we would change AJs proposal to use “$HOME-cleaning” default values).

[1]: href=”http://boincfaq.mundayweb.com/index.php?language=1&view=176
[2]: http://blog.incase.de/index.php/cpu-feature-flags-and-their-meanings/

However I disagree with him in the consequences a bit. Because I noticed that on several projects with good documentation (subversion is an example that immediately comes to my mind, but postfix isn’t too bad either), the internet search returns a reference to the docs more often than not. Of course, this means that the documentation needs to be searchable for those webcrawlers. So if you have the task to write documentation, I strongly suggest to make it searchable in some way. For company-internal projects, this obviously means that the documentation must be reachable via an internal search engine. In a project a few years back, we implemented an internal search engine which included company internal information (even with user based access rules so that each user only got those results he could actually access) as well as an external search engines results. It was closed source, but a pretty nice idea. It didn’t, however, index any locally (user’s desktop) stored documents, only what was on some company web page (but including .doc, .rtf, .pdf and the like which where retrievable via http).

[1] http://www.hezmatt.org/~mpalmer/blog/general/documentation_the_chicken_and_the_egg.html

for i in
    # grep installed package names
    `COLUMNS=200 dpkg -l | grep -E '^ii'| awk '{print $2};' `
do
    # find package in /var/lib/aptitude/pkgstates
    # check for the right state (1 seems to mean
    # auto-installed, 3 manually installed)
    if
        grep-available -s Package,State \
                       -F Package \
                       -X $i /var/lib/aptitude/pkgstates  \
        | grep -q 'State: 1'
    then
            echo $i
    fi
done

Results in a list of auto-installed packages AFAICT. If you change the “State: 1″ into “State: 3″, it seems you get only manually installed packages. So if you take the latter and feed it to “aptitude install”, your database should be right. If you take the former, you feed the list to “aptitude markauto”. A cleaner solution (which works even if /var/lib/aptitude/pkgstates changes formats) would involve checking “aptitude show” output, evaluating the “Automatically installed:” field. However, simply feeding “aptitude show” output to grep-dctrl (or any equivalent) resultes in the rather irritating error message “grep-dctrl: -:14: expected a colon.”, with the 14 changing to a different line in the packages description (usually a line directly following an empty line). So I’m just giving you an idea here.

The DM proposal (don’t get me wrong there, I generally support the idea, I just don’t like the way it is implemented in the proposal) is shifting this responsibility from the sponsor onto the shoulders of the DM, which is a good thing. However I think it doubles some of the work the NM queue already needs done, so my proposal would be not to have it as a completely seperate path for a contributor, but instead see it integrated into the NM process. Wether it would mean adding a new maintainer to the DM keyring after he had an advocate (which is pretty near to the current proposal) or after an AM was assigned and checked some basic things (which I would prefer) doesn’t make a lot of difference to me.

So what should be done instead in my opinion?
I think that a DM like status is fine as part of a (possibly re-designed) NM process. Given the current NM process, I would like people been given a DM like status after they finished the T&S (tasks^IIRC and skills) part if their AM found their skills and knowledge of the policy rules sufficient to give them that status. If that is all they wanted, they can drop from the NM process at that point and stay DMs. If they want to become DDs later on, they can resume the NM process at that very step (or continue right ahead).

This would do several things:

• introduce the DM status as an alternative to full DD status
• integrate the DM status closer with the existing NM process
• take some load of the friendly sponsors who upload non-DD packages now, giving them more time to help more new contributors
• give people waiting for DD status some intermediate level at which they already can do more than before their joining of the NM queue

So I really think “more discussion” is the only valid option for me in this GR. If you want to change my mind: Please leave some feedback in my blog. Or give a precise (but brief) description why the current proposal is better than integration with the current NM process in one way or the other.

Abbreviations:

• DD = Debian Developer (a full Debian project member, includes voting rights)
• DM = Debian Maintainer (planned to be a somewhat restricted DD, among others without voting rights)
• NM = New Maintainer (should actually be: New Developer)
• GR = General Resolution (a way in Debian to create new rules or to ask the project leader or others in the project to do or refrain from doing something)

Update:
The GR even seems to contradict itself a bit. If the upload rules are applied in an AND fashion, one of these rules is superfluous (the first one), at least if I’m not mistaken:

• the Maintainer: field of the uploaded .changes file corresponds with the owner of the key used (ie, non-developer maintainers may not sponsor uploads)
• the most recent version of the package uploaded to unstable or experimental includes the field “DM-Upload-Allowed: yes” in the source section of its control file
• the most recent version of the package uploaded to unstable or experimental lists the uploader in the Maintainer: or Uploaders: fields (ie, non-developer maintainers cannot NMU or hijack packages)

The first rules also means that no DM could ever do an upload for packages team-maintained in the fashion cyrus-imapd-2.2 is maintained (Maintainer address is the teams mailinglist address, all uploading team members are in the Uploaders field). This is IMHO a serious flaw in the proposal. If the first rule was dumped, all would be well for team maintainers.

(edit: Fix spelling of Dirk’s surname)