Zugschlusbeobachtungen - Debian

Heute mal wieder Debian

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 18 Jun 2012 18:53:44 +0200

In den letzten 24 Stunden habe ich endlich mal wieder was für Debian gemacht: dnstop und sipcalc vom bisherigen Maintainer übernommen, auf Vordermann gebracht und uploaded, und immerhin einen Alibi-Upload von pdns-recursor, damit auch der recursor mit der neuen Maintainer-Mailingliste im Maintainerfeld und dem korrekten Alioth-Vcs-Link im debian/control nach Wheezy kommt.

Next PowerDNS version for Debian ready for testing

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 17 Jun 2012 17:34:00 +0200

I have published PowerDNS version 3.1-1.0 on https://ivanova.notwork.de/~mh/debian/pdns/

This is a preliminary package and a release candidate to be 3.1-2 in Debian. If you’re interested in PowerDNS on Debian, please test this package.

I plan to upload next week. This package will vanish from the web server once the package is visible in Debian.

atop in unstable

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 31 May 2012 09:13:06 +0200

Eight days ago, I uploaded atop 1.26-1 to DELAYED/8, listing me as new maintainer. This means that the package has in the mean time appeared in unstable, and I hope that it’ll swiftly migrate to testing.

How much added complexity in packages to cater for apt's shortcomings?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 23 Jan 2010 12:08:00 +0100

It is well known that apt has an issue when it comes to resolving circular dependencies. Therefore, Debian bug reporters have set out to eradicate circular dependencies from the archive. This does, however, add significant bloat to the actual packages, and I am questioning why this is really necessary.

For example, aide. aide has an aide-common package, depending on aide | aide-binary. aide-binary is a virtual package by aide, aide-dynamic, and aide-xen. All three providers of aide-binary depend on aide-common again, which is a circular dependency.

If I now follow the request posed in #545852 and remove aide-common’s dependency on aide | aide-binary, I’ll have to cater for the case of the aide-binary bein absent in each and every helper script included in aide-common, which would drive the script’s complexity up to a new level. I really hate that idea.

Is it really necessary to work around apt’s shortcomings by eliminating the case that apt doesn’t handle well from the archive, and driving up other packages’ complexity (and the possibility of bugs in this added complexity)?

How to have socat open a listening socket in the file system?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 07 Aug 2009 12:10:40 +0200

Dear Lazyweb, can anybody with some advanced socat-foo tell me the command line needed to have socat create a socket in the local file system and to listen on it, so that I can have Virtualbox connect a virtual serial console to it?

The material available on socat on the web is sparse, and virtualbox-related docs usually contain “tick the create pipe option”, which is not helpful here since I would like to see the first output the virtual machine prints to its serial port. It would be vastly more useful to have the socket already created with socat listening so that I can immediately see what is being printed to the socket.

Unified Kernel for etch, lenny and sid

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 06 Aug 2009 10:44:00 +0200

Traditionally, the Linux kernel is software that I compile myself from pristine upstream sources for various reasons. I have three major kernel flavours that get built (server, desktop and notebook), and I am pretty current in running a bleeding edge kernel. This is not really necessary any more nowadays, but it’s a tradition that works pretty well.

My kernels get built on sid and are packaged up with kernel-package, and equivs builds a dependency helper package which pulls in the kernel’s dependencies such as initramfs-tools and takes care of cross-version updates like going from 2.6.29 to 2.6.30. Up to now, I was always able to run a kernel built this way on all my systems which can range from oldstable to unstable.

This has recently become a bit harder when unstable’s udev started to complain that the sysfs layout was deprecated and that I should unset CONFIG_DEPRECATED_SYSFS in my kernel configuration or lose some of udev’s functionality, since a kernel compiled without CONFIG_DEPRECATED_SYSFS doesn’t properly boot on etch.

Since I wanted to avoid building even more kernel flavours, I decided to investigate which package I need to backport to etch to get kernels without CONFIG_DEPRECATED_SYSFS to work on etch. To my surprise, the cause for not booting on etch was not udev, but lvm2. With lvm2 2.02.39 (and the corresponding libdevmapper, 1.02.27-4) ported back from lenny to etch, my etch systems boot fine with CONFIG_DEPRECATED_SYSFS unset. udev can happily stay at etch’s version, 0.105-4etch1.

From etch to lenny to squeeze, the lvm2 package has evolved quite a bit. Since there is only one LVM flavour left, the lvm-common package vanished in the transition from etch to lenny, and libdevmapper still has its own source package in lenny, but is built from lvm2’s source package itself in squeeze. So, as a heads-up, there needs to be special handling for lvm-common when installing the backport on etch.

I decided to backport lvm2 from lenny to etch to allow this particular derivation from the distributions’s versions to vanish in reasonably short time when my last etch boxes get finally updated to lenny. And my dependency helper has been extended to now pull in the backported version of lvm2 to avoid nasty reboot surprises.

Bye bye KDE?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 05 Jul 2009 13:10:31 +0200

I have been using current KDE since most of my Linux time (having converted over from WindowMaker to KDE 2 back in 2002). But currently, I am seriously pondering to ditch KDE since KDE upstream seems to be wildly decided to kill KDE.

I have accidentally upgraded my desktop box to KDE4 because I missed putting KDE on hold before doing a major sid update after a couple of months. KDE4’s first regression immediately showed itself - the right display doesn’t get any attention from KDE. It just shows up in a grey checkerboard background, it doesn’t have a panel, it doesn’t have a menu, right click doesn’t work. It looks like the only thing one can do with it is dragging windows onto it.

With help of #debian-kde, I quickly found out about this bug in Upstream Bugzilla, which is referred from #529487 and which was marked as Duplicate of this bug in upstream bugzilla, which is one and a half years old and was marked as “severity wishlist”.

Despite the splendid job that the Debian KDE team has done to sort out the KDE4 mess, it looks like KDE upstream has managed to break Dual Head Setups for one and a half years and doesn’t seem to be too interested in providing KDE4 in a way that it can be compared with past versions. This is very sad and will have me shopping for a new desktop environment soon, I am afraid.

Maybe it was not a so good idea to take away KDE 3 so soon and it might have been better to keep KDE 3 in Debian. Maybe it’s time to re-introduce KDE 3 as co-installable packages? I would be willing to participate in this effort as a team member.

Which other Desktop Environments and/or Window Managers should I be shopping for? I’d like to have:

Dual-Head support (preferably with the possibility to switch desktops only on one display, but that’s something that even KDE 3 cannot do yet)
Shortcuts like “gg:search words” or “wp:search words” to immediately open google, wikipedia, the BTS or the PTS
Overlapping windows that are not automatically resized
A terminal like konsole which allows me to have different session in tabs and to send my input to all tabs
A clipboard handler that will automatically pop up a window asking me whether I want to open the URL that I just marked in a browser
Integration with the Debian menu system

synaptics and unstable?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 04 Jun 2009 23:30:30 +0200

Dear Lazyweb, I have just found out that ksynaptics has stopped working against the X in unstable, and that ksynaptics is not even in lenny, let alone in current testing and/or unstable. This currently leaves me with an unconfigured touchpad, which is a major nuisance since I have gotten accustomed to tap-dragging and touchpad border scrolling.

xserver-xorg-input-synaptics’ README.Debian dates back to 2004, so I suspect that the information given there in does not any more apply to today’s configfile-less X.

So, dear lazyweb, how do I get my touchpad back into the more intelligent mode? Clickable configuration preferred.

help needed for ATM support in ifupdown-scripts-zg2

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 16 Apr 2009 22:49:28 +0200

I haven’t been using ATM on Linux for some six years now. I neither have access to an ATM network any more nor do I have ATM hardware any more. Therefore, I plan to remove ATM support from ifupdown-scripts-zg2 in the next release which will be done in the next few weeks.

If anybody does still use ATM on Linux in conjunction with my scripts, you might want to offer help with the package if you want to have continued ATM support in ifdown-scripts-zg2. I cannot test the code any more and therefore cannot maintain it in the future.

LV naming, UUIDs, file systems labels

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 02 Apr 2009 11:04:12 +0200

In the last few weeks, I spent quite some time wondering about how to arrange the hard disk layout of my productive systems in the future. This article outlines my thoughts and would like to ask the lazyweb for comments.

I try to keep my Debian servers as identically as possible, making it possible to talk non-linux persons remotely through the system without having to worry about this particular box’ configuration.

I have been especially worrying about:

(h1) root FS location (/etc/fstab, grub/menu.lst)
(h2) LVM volume naming (/etc/fstab)

On my current systems, I usually have the root file system on /dev/hda1, with /dev/hda2 being a PV which is the only PV of a VG vg0, which in turn has LVs named home, var and usr.

This setup has a bunch of disadvantages.

It is necessary to derive from the standard setup, when RAID or crypto is used. In these cases, the root fs needs to be in LVM as well, and hda1 is /boot.
LVM setup breaks in recovery and/or migration scenarios, when the disks from one server are connected to another one due to two VGs named vg0 being present. These situations are solveable via lvrename per UUID though.
Migration to libata is painful since the dreaded “hda” string lurks in half a dozen places, and Debian grub does not really cleanly support having different kernels that need different root= clauses on their command line.

Thankfully, there is a number of possible solutions:

(l1) Mount the root fs with UUID
- - UUID needs to be adapted in /etc/fstab and grub/menu.lst if file system is rebuilt.
- - mount-per-UUID is a function of the Debian initrd, mechanism nonportable, initrd needed
- + no conflicts when a server can access disks of another system, as UUID are unique.
(l2) Mount root fs with label (all root fsses have the same label)
- - Conflicts when disks are moved between servers, making it possible to boot the wrong system.
(l3) Mount root fs with a host-specific label
- - When the system (and the root fs) is renamed, /etc/fstab and grub/menu.lst need to be adapted.
- + no conflicts when disks of more than one server are plugged in.
(l4) VG is named identically on all servers
- - Manual intervention is necessary (see above) if another server’s disks are placed into one server.
- + Backup and other disk related scripts can be configured identically in all systems.
(l5) VG is called like the server
- - Attention needed when renaming a system (/etc/fstab needs to be adjusted).
- - Backup and other disk related scripts need to be configured differently on each system, no standard config possible.
- + no conflicts in the “more than one set of disks in a server” case.

I am pondering about a solution, but suspect that this is totally overengineered.

(l1) Root fs is mounted via label, so that /boot/grub/menu.lst only needs to be edited once during syste installation. After migration to grub 2, a hook script (if grub2’s update-grub finally supports hooks), the root FS label can be automatically generated. molly-guard refuses to boot the system when the root FS label from the boot manager configuration is not identical to the currently mounted root fs’ label, thus forcing to boot with the current root fs or not to boot at all. Do I need to call blkid -g in that case?
(l2) /etc/fstab is identical on all systems and has entries like
- /dev/disk/localhost/usr /usr ext3 defaults
The symlinks in /dev/disk/localhost are generated by a run level S (27) init script (or can this be accomplished by udev?) from /dev/mapper/$(uname -n)--usr, so that the VG is always named like the host. Renaming the VG needs a rescue system anyway, so that’s not a real loss.

Did I miss something? Is this a realistic solution? How do you handle this issue? Comments to this article will be open for quite a while.

nVidia and current Kernels II

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 07 Jan 2009 15:08:24 +0100

A few months, I blogged about the pains I had with my nVidia FX 5200 graphics card, Debian and current kernels.

I have solved the issue in the mean time and would like to document what I did. This has been updated to reflect driver 173.14.20 from July 2009.

Currently, the package nvidia-graphics-drivers has its version 173.14.09 in Testing and Unstable; and 177.82 in Experimental. There is also a package nvidia-graphics-drivers-legacy from 2006 in stable.

177.82 does build with recent kernels, but doesn’t support my old FX card. 173.14.09 supports my FX card, but doesn’t build with recent kernels. I didn’t try the legacy stuff because of its old age.

The actual solution was easy: The current “legacy beta” driver that can be downloaded from the nVidia ftp server has 173.14.20, which happens to build with a recent kernel and supports my FX card, as kju pointed out in a comment to my original blog entry. I then took the 173.14.09 diff from Debian unstable, put it over the pkg0.run and pkg2.run archives from nvidia (i386 and amd64), modified debian/upstream_info and built. This first failed because some Debian patches didn’t apply correctly, but since the file name patches/xen.patch suggested that it was only needed for xen systems, I dared to remove it. Leaving the patches/ directory empty made the build system topple, so I touched an empty file into patches and the build went fine.

Out of the resulting nvidia-kernel-source, I was able to compile kernel modules against 2.6.30, and am now back in business even with a recent kernel.

How to pin lenny?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 22 Dec 2008 18:57:02 +0100

Dear lazyweb, how do I pin lenny now and have that pin hold after lenny’s release?

Codename lenny doesn’t work, apt cannot do this (#433624, 18 months old, without any reaction yet)
Version 5.0 doesn’t work, lenny’s Release file doesn’t have a Version field yet
Suite testing will match lenny now and then track squeeze once squeeze is testing

Is there any method that will get me testing lenny now and stable lenny later and not testing squeeze?

kbd seems to be the way to go

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sat, 21 Jun 2008 15:48:35 +0200

This is just a small reminder (for me and others) that Debian is currently migrating from console-tools to kbd (back again, yes, those who have been around for a few years remember).

This information is obviously a closely-guarded secret. Console-tools is still Priority: important, and kbd is still Priority: extra. However, kbd seems to be much better maintained (current uploads happening, while console-log has seen its last maintainer upload two years ago), and unfortunately, neither package description suggests which package is the way to go. And Debian-installer still installs console-tools by default.

However, a few bugs were filed a year ago by the console-tools maintainer to drop console-tools from depends as console-tools is going away. So I guess that he knows what he’s doing...

Before I get around to adding console-tools back to console-log’s depends (as I almost did accidentally), I’ll better blog this to remind people of console-log going away. Maybe we’ll get the Priorities changed just in time for lenny.

Does Debian need the local host name in /etc/hosts for IPv6?

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 31 Mar 2008 16:51:39 +0200

This article was updated, and the issue seems solved. Please look at the last paragraph before adding comments.

Exim has the habit of trying to find out about its host names and IP addresses when it starts up. This has, in the past, been an issue for the Debian packages, since a Debian system might be on a dial-on-demand modem line with expensive costs and thus should not do unnecessary DNS lookup when the MTA is started.

This article tries to describe the issue and which countermeasures debian took, and asks for tips how to solve this in the case of IPv6, where our past measures unfortunately do not directly apply.

I’d like to solicit opinions from people who are more experienced than me with Unix, the local resolver library including /etc/hosts and /etc/nsswitch.conf, DNS, and - especially - the customs that apply on a system running IPv6.

To avoid the extra DNS lookups, the Exim packages have a Debconf option to configure exim for “minimal DNS usage”, which hardcodes the hostname into Exim’s configuration at package configuration time. This was necessary since - without this option - exim looks up its own host name in the DNS even when a completely local operation is invoked.

In some cases, exim still looks up its IP address when a listening daemon starts up. This is why the Debian installer configures 127.0.1.1 (not 127.0.0.1) for the local hostname on installation, yielding /etc/hosts files like

127.0.0.1       localhost
127.0.1.1       myfoo.localdomain   myfoo

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

However, in the last few weeks I have heard a few cases where exim does IPv6 AAAA lookups when a listening daemon starts up. An strace shows a gethostbyname2 call for AF_INET6, and if we want to continue the line we went in the past, we’d need an IPv6 address for myfoo.localdomain in /etc/hosts as well.

I am now wondering how this could be implemented. In IPv4, we have 127.0.0.0/8 available for the local host and could arbitrarily choose 127.0.1.1 to configure the local host name on. In IPv6, there is only ::1, which is a single address. Would it be possible to choose an arbitrary “link local” address on lo, the loopback interface? Or is there any better way?

This being said, I consider the entire 127.0.1.1 business a horrible hack which is one of the most ugly things I have ever seen. Do we have a chance to implement this in a more cleaner way, or is it still the way to go for the distribution, where we don’t know zilch about the environment where an installed system is going to be used?

This issue leads to people adding their local host name to ::1 in /etc/hosts, which might re-introduce other issues that we experienced in a phase when we did the same for 127.0.0.1, eventually ending up with 127.0.1.1, or to disabling IPv6 altogether, which is a bad thing in a time where IPv6 should be enabled, not disabled. So I’d like to find a clean solution which could then be implemented in whatever part of Debian might be responsible.

I tried asking this question in other places, including Usenet, before pestering my Blog to ask the Lazyweb, but obviously the people I asked before do not care for the special environment that a Linux distribution has to take care of. The only answers I got were like “that would be the local administrator’s task to fix” and “this should be taken care of in the local DNS server/setup (maybe even on the local box being installed)”. A quite frustrating experience.

Update 2008-04-15

The issue seems solved. To avoid the extra DNS lookups, the Debian Exim packages have a Debconf option to configure exim for “minimal DNS usage”, which hardcodes the hostname into Exim’s configuration at package configuration time. This - silently - doesn’t happen if hostname --fqdn does not return a fully qualified name (#476249).

I am inclined to solve this issue by having update-exim4.conf print a warning if hostname --fqdn does only return a single-component name and leave the rest to the local admin.

Universal boot stick for Debian, grml and the Debian installer

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 19 Mar 2008 23:27:00 +0100

For various reasons, I have the kernel and the initrd that my notebook needs to boot Linux on an USB stick. I recently added the Debian Installer and grml to the stick to allow additional uses of the stick.

Usually, USB sticks are formated with FAT32 and when they’re used to boot Linux, Syslinux or some derivative is used.

I do it differently on my boot stick, most prominently because I’d like to have Unixoid privileges on the stick, and because I’d like to continue using grub. So, my stick is formatted as ext3, and feels like an additional hard disk.

Booting from an USB stick is sometimes tricky. I have made the best experiences with formatting the USB stick as an USB ZIP, which basically means having 64 heads, 32 sectors and a single partition in the fourth primary partition slot. This can be done using mkdiskimage and is documented on Debian in /usr/share/doc/syslinux/usbkey.doc. Partitioning and generation of the file system is as straightforward as is installing grub using the standard, documented methods for hard disks.

I tried using grub 2, but have found it not sufficiently well-documented and stable to be used in this kind of critical environment. I am therefore still using grub-legacy despite the fact that the grub maintainers have ceased fixing grub-legacy bugs some months ago, refering to the pending release of grub 2.

I use unison to keep /boot on the stick in sync with /boot of the Linux system, which is on a crypted filesystem on the hard disk and thus unuseable until the system has booted. The hard disk /boot thus serves only as installation target and sync source so that the stick does not need to be plugged in during upgrades. update-grub is configured so that running it creates a menu.lst which can be used from the stick. This concludes booting the production system from the stick.

For the other systems, I have decided not to put them in the “default” boot menu from menu.lst, but instead include foo.lst files to the root of the stick, and when I need them, shell out from the grub menu to a command line by pressing “c” and then pulling in the new grub config file with the “configfile /foo.lst” command.

grml is my favorite rescue system. I use it all the time once a system starts acting up. One of its biggest advantages is its extremely flexible bootup process. That made it predestined to be the rescue system on my USB boot stick. grml is currently making a transition to a new build environment, which has had the side effect that the boot process has changed in some details. grml-small, the 60 MB variant that I had been using before, has been discontinued and replaced by grml-medium, a 170 MB variant which does definetely not fit any more on a business card CD, but 128 MB USB sticks have become relatively seldom.

For both grml flavours, all one needs to do is mount the .iso file loopback, copy the file’s contents to a subdirectory of the boot stick, and to drop this menu file to the stick:


title           grml-small
root            (hd0,3)
kernel          /grml-small/boot/isolinux/linux26 toram grml_dir=/grml-small/GRML/ grml_name=GRML ramdisk_size=100000
init=/etc/init lang=us BOOT_IMAGE=grml
initrd          /grml-small/boot/isolinux/minirt26.gz

title           grml-medium
root            (hd0,3)
kernel          /grml-medium/boot/grmlmedium/linux26 live-media-path=/grml-medium/live/ toram=grml-medium.squashfs
lang=us boot=live noeject noprompt keyboard=de
initrd          /grml-medium/boot/grmlmedium/initrd.gz

Since grml-medium works reasonably well, I do not expect to need grml-small very often any more.

The Debian Installer guys have published an initrd which can browse nearly arbitrary media for an debian-installer .iso file, mount it and install from that image. I have made use of that feature to allow Debian to be installed from my boot stick. /d-i holds a current debian-testing-i386-netinst.iso, and vmlinux and initrd.gz from http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/current/images/hd-media/. With that, this d-i.lst:


title debian installer
root (hd0,3)
kernel /d-i/vmlinuz
initrd /d-i/initrd.gz

does the trick and boots up the Installer, ready to start.

I guess that it would be easily possible to include these grub config stanzas to the default menu.lst, including grml and the Installer into the main grub menu, but I deliberately decided not to have these options directly in the menu for the time being.

It is always amazing how flexible today’s systems have become when it comes to boot Linux. For both rescue and installation, this is needed, and the respective authors have done a remarkable job.