Zugschlusbeobachtungen (Entries tagged as linux)

btrfs gegen ext4, ein unerwarteter Sieger

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 20 May 2012 10:39:57 +0200

Alle Leute sagen, btrfs sei die Zukunft. Es gibt Leute, die einen schon mitleidig angucken, wenn man ihnen sagt, dass man immer noch ext4 einsetzt, wie ich das tue. Aber ich hatte neulich einen Grund, btrfs auszuprobieren. Mit btrfs kann man nämlich Snapshots innerhalb einer verschlüsselten LV einsetzen. Mit ext4 muss man vom Cryptodevice einen Snapshot machen und dann den Snapshot gesondert aufschließen. Damit ist schroot derzeit noch überfordert (#639105).

Also habe ich mal btrfs ausprobiert und musste feststellen, dass es mindestens beim Anlegen eines chroot massiv langsamer ist als ext4. Hier meine Messergebnisse für das Anlegen eines sid-chroot mit debootstrap mit und ohne eatmydata:

fs	eatmydata	Laufzeit
ext4	nein	4:40
ext4	ja	4:17
btrfs	nein	8:50
btrfs	ja	8:46

Ich muss sagen, ich bin entsetzt. Sowohl darüber, dass btrfs so viel langsamer ist, als auch darüber, dass eatmydata so gut wie nix bringt. Habe ich etwas falsch gemacht? Braucht btrfs beim Erstellen des Dateisystems bzw. beim Einhängen desselben irgend eine magische Option, um in die gleiche Performanceregion wie ext4 zu kommen?

Testumgebung war Debian GNU/Linux sid auf einer KVM VM.

letzte netfilter-init Installation ausser Betrieb

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 19 Feb 2012 17:02:35 +0100

Im Jahr 1999 habe ich im Rahmen meiner Diplomarbeit ein Framework entwickelt, das flexibel und leistungsfähig die Erstellung von - damals noch - ipfwadm-basierten Firewalls erlaubte. Irgendwann wurde es dann auf iptables aktualisiert und war insgesamt zwölf Jahre lang in zahlreichen Installationen im produktiven Betrieb.

Eben habe ich die letzten zwei Instanzen abgeschaltet. Und ich bin froh darüber.

Als ich netfilter-init schrieb, war es Stand der Technik, in einem Script zunächst das komplette Regelwerk zu löschen und dann durch explizit geschrieben Aufrufe von ipfwadm neu aufzubauen. Abhängig davon, wieviel Mühe man sich dabei gab, war die Firewall während dieses Aufbauprozesses für einige Zeit komplett offen oder komplett zu, was auf der einen Seite ein Sicherheitsrisiko ist und auf der andren Seite im Falle eines fatalen Tippfehlers den ssh-Zugriff auf die Firewall unterbindet, wenn der Aufbau des Regelwerks abbricht, bevor die Regeln etabliert sind, die den ssh-Zugriff erlauben.

Mit netfilter-init war ein Konglomerat verschiedener Shellscripts. Das Haupt-Regelwerk war dabei in eigenen Rules versteckt, die nach dem Bau des Regelwerks mit einer atomaren iptables --replace Regel aktiviert wurden. Auf diese Weise war das alte Regelwerk bis zum erfolgreichen Bau des neuen Regelwerks aktiv. Außerdem hatte ich ein Verfahren implementiert, mit dem man Kreuzprodukte schreiben konnte: --src { 192.168.0.0/24 , 192.168.10.0/24 } --dst { 172.16.0.0/24 , 172.17.0.0/24 } erzeugte vier Regeln.

Mit dem Einbau von netfilter-init in das Firewall-Produkt meines damaligen Arbeitgebers bekam netfilter-init kommerzielle exposure und zeigte recht schnell seine Grenzen: Besonders die Expansion der Kreuzprodukte und die Einbindung der aktuellen Netzwerkkonfiguration des Gerätes waren viel zu langsam, so dass die stringintensiven Operationen relativ schnell in einige kurze C++-Programme ausgelagert wurden. perl wollte ich damals vermeiden, weil meine Vision war, ein minimales Firewall-System ohne perl installieren zu können. Leider entwickelte sich Debian in die andere Richtung, und es ist heute richtig schwer, ein Debian ohne perl und ohne python zu betreiben.

Parallel dazu gab es den Versuch, einen in C geschriebenen Konverter zu etablieren, der mir erlauben sollte, dieselben Scripts zum Regelwerkbau zu verwenden wie vorhanden, nur nicht für jede Regel einen eigenen iptables-Aufruf absetzt, sondern die Regeln im Speicher zusammenbaut, um sie dann zum Schluß atomar via iptables-restore in den Kernel zu schieben. So weit kam es dann nicht mehr, weil ich den Arbeitgeber wechselte.

netfilter-init wurde von mir nie wirklich ernsthaft veröffentlicht, weil zu dem Zeitpunkt, zu dem die nötige Reife erreicht war, andere Lösungen wie shorewall etc da waren, die den Job besser gemacht haben. Ich habe nur lange gebraucht, bis ich eine Lösung fand, die auch meine Wünsche erfüllt.

Währenddessen schrumpfte die Installationsbasis von netfilter-init immer weiter, während die großen Installationen so langsam auf unzumutbare Arbeitsgeschwindigkeiten kamen. Dies lag zum Schluß nichtmal mehr an den Shellscripts, sondern an iptables, bei dem es signifikant Zeit dauert, 16000 Regeln aus dem Kernel auszulesen und dann 16001 Regeln wieder in den Kernel zurückzuschreiben. Meine größte Installation hat schließlich 15 Minuten gebraucht, um das Regelwerk neu zu bauen, was besonders beim Booten, wo kein “altes” Regelwerk zur Verfügung stand, unangenehm war.

Schließlich entdeckte ich ferm und arbeitete lange daran, “meine” Spezialitäten auch in einem mit ferm gebauten Paketfilter unterzubringen. Dies gipfelte in einigen kleinen Patches gegen den ferm-Code selbst und einem inzwischen ganz gut ausgefeilten “Drumrum”. Das eigentliche Regelwerk wird auf einem Managementsystem gebaut und das daraus entstehende iptables-restore-taugliche File per scp auf die eigentliche Firewall geschoben. Bevor das neue Regelwerk dort etabliert wird, gibt es einen at-job, der das alte Regelwerk wieder aktiviert, wenn nicht innerhalb von 30 Sekunden ein neuer erfolgreicher Login vom Management-System erfolgt und somit nachgewiesen ist, dass auch das neue Regelwerk den Management-Zugang erlaubt. Versionskontrolle in git rundet die ganze Aktion ab.

Heute habe ich jetzt die beiden letzten, kleinen netfilter-init-Installationen von lenny auf squeeze gehoben und den Bau des Regelwerks auf mein ferm-Framework umgestellt. Damit endet für mich eine Ära. Wenn man mir 1999 gesagt hätte, dass diese Software zwölf Jahre lang leben wird - ich hätte es nicht geglaubt.

In diesem Sinne: netfilter-init ist tot, es lebe ferm.

What are interface labels for

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 11 Mar 2011 19:28:55 +0100

Dear Lazyweb, for a long time I have been using iproute2’s label feature to assign arbitrary labels to IP addresses configured on Interfaces:

40: int152@dotqa: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
link/ether 00:25:b3:01:e5:6c brd ff:ff:ff:ff:ff:ff
inet 10.1.152.254/24 brd 10.1.152.255 scope global int152:98fe8

Recently, this has shown to at least confuse both isc-dhcp-relay (#617258) and dhcp-helper (#617264).

As I have never seen interfaces labels used outside my firewalls (which happen to use ifupdown-scripts-zg2 (Debian PTS)) and ifupdown’s rather twisted handling of multiple IP addresses per interface (using Alias Interfaces), I’d like to know whether my usage is a legitimate one and whether there are other uses for interface labels.

At the moment, I’m tempted to remove label support from ifupdown-scripts-zg2 in the next release, or to make it optional. Please comment if you have an opinion.

Block devices in KVM guests

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Fri, 22 Jan 2010 14:08:00 +0100

In the last few days, I found the time to spend some with KVM and libvirt. Unfortunately, there is a subject that I haven’t yet found a satisfying solution: Naming of block devices in guest instances.

This is surely a common issue, but solutions are rare. Neither an article on Usenet (in German) nor the German version of this blog article has found solutions for the main question. I should have written this in English in the first place and am thus translating from German to english, hoping that there will be some answers and suggestions.

KVM is quite inflexible when it coms to configure block devices. It is possible to define on the host, which files or whole devices from the host should be visible in the guest. The documentation suggests that devices should be brought into the guest with the virtio model, which needs suppport in the guest kernel. Importing a device as emulated ATA or SCSI device brings a performance penalty.

The devices brought into the guest via virtio appear in the guest’s dev as /dev/vd<x> and do also have their corresponding entries in /dev/disk/by-uuid and /dev/disk/by-path. The vd<x> node is simply numbered in consecutive order as hd<x> and sd<x>. /dev/disk/by-uuid is the correct UUID of the file system found on the device, at least if it’s a block device partitioned inside the guest and formatted with ext3 (I didn’t try anything else yet). The terminology of the /dev/disk/by-path node is not yet understood, and I am somewhat reluctant to assume the PCI paths of emulated hardware as stable.

Looks like I am forced to configure inside the guest when I have changed the host’s mass storage system (for example, after migration to a different file system or after new block devices have been added) to accommodate for the new order of the /dev/vd<x> or to have the UUID correctly configured. This is like calling for configuration errors.

This is a reincarnation of the same issue that has been killed by LVM on Linuxes running on “bare metal”: The block device itself has a mnemonic name which is constant even in migration and copy actions. This works without file-system specific stuff like UUID or label, and wouldn’t even be possible with a UUID (which won’t be unique in this case). The mnemonic names of LVs are also available when the data is directly written to the raw device such as a CNFS buffer of a news server.

I would love to have something like a “paravirtualized device mapper interface” which would allow to say in the host’s configuration which of the host’s LVs should be visible in the guest with which name in /dev/mapper. That way, the guest’s configuration could remain stable during data wrangling operations on the host.

One solution is to have a single LV for each guest and import this LV as /dev/vda into the guest. /dev/vda would then be partitioned like a real disk and have its own LVM installation. This would however need kpartx if one wants to access the data from the host, and loses flexibility when resizing file systems.

These issues appear in every installation of KVM virtualization, and I would expect that there are gazillions of other possible solutions. I am interested in knowing how other people have tackled this issue and whether there are more possiblity that I haven’t thought of before. Maybe there is a solution that doesn’t leave me with the feeling of having implemented something ugly. Does the interface between the host’s KVM and the guest’s device mapper that I have been dreaming of maybe exist. Or is there any other possibility of configuring the device node’s name in the guest Linux on the host side?

Pushing a packet back and forth between Linux subsystems

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 10 May 2009 10:01:04 +0200

Linux policy routing is still incredibly painful if one wants to have more sophisticated routing than just “take source and destination IP address for the routing decision”. The mechanisms that have been in use seven years ago still work though, and I didn’t find any possibility to do it any easier. In this article, I’ll try to explain the “old” mechanisms and hope that somebody from lazyweb will comment and say “it can be done so much easier”.

This is a translation of the Usenet article <gu48cs$rul$1@news1.tnib.de> in de.comp.os.unix.networking.misc in the hope that the english-speaking blogosphere can give additional insights.

Given a Linux-based router with one internal network (int0), one perimeter network (per0) and two Internet connections (ext0, ext1) with one IP address each. We need to do source NAT to deliver Internet to the internal and perimeter networks. The internet connection on ext0 will be used for http and https, while all other traffic needs to go out on ext1. The perimeter network is reachable from the outside via destination NAT.

1: ext0:  mtu 1500 qdisc noqueue
    inet 10.81.221.145/29 brd 10.1.221.151 scope global ext0
2: ext1:  mtu 1500 qdisc noqueue
    inet 10.82.83.225/29 brd 10.82.83.231 scope global ext1
3: per0:  mtu 1500 qdisc noqueue
    inet 172.16.1.254/24 brd 172.16.1.255 scope global per0
4: int0:  mtu 1500 qdisc noqueue
    inet 192.168.8.254/24 brd 192.168.8.255 scope global int0

We have the following routing rules:

0:      from all lookup 255
10:     from all lookup main
32:     from all fwmark 0x12e lookup to_ext0
32:     from all fwmark 0x12f lookup to_ext1
32000:  from all lookup defaultroute
32000:  from all lookup defaultroute
32766:  from all lookup main
32767:  from all lookup default

Table main contains all rules for the directly connected networks, but no default route. Both to_ tables have one default route each, pointing to the respective ISP, and the table defaultroute has once more a default gateway pointing to ext1’s gateway.

The PREROUTING chain of the mangle table has these rules:

iptables --protocol tcp --dport 80 --in-int int+ --set-mark 0x12e
iptables --protocol tcp --dport 443 --in-int int+ --set-mark 0x12e
iptables --in-int int+ --set-mark 0x12f

and the POSTROUTING chain of the nat table has these:

iptables --match mark --mark 0x12e --out-int ext0 --jump SNAT --to-source 10.81.221.145
iptables --match mark --mark 0x12f --out-int ext1 --jump SNAT --to-source 10.82.83.225

If now somebody from the internal network accesses a web server on the Internet. The outgoig packet will first be marked in the PREROUTING chain, then the routing rules will use the firewall mark to consult the correct routing table and pass the packet back to the packet filter, where the POSTROUTING chain will use the outgoing interface and the firewall mark to SNAT the packet to the correct source IP so that the answer will actually reach us.

Has a less ugly way available way to do this become available in the last five years? Or is it still necessary to have the different parts of the networking subsystems play ping-pong with the packet? I particularly dislike that someone not familiar with policy routing will not see any default route in the routing table printed by “route” or “ip route”, which will probably be very confusing.

Is there any possibility to interact with the routing code without firewall marks, maybe by directly setting a gateway from a firewall rule?

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.

nVidia and current Kernels

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Sun, 23 Nov 2008 00:33:55 +0100

My home workplace is slowly and steadily mutating into a never ending story. I do not remember blogging every aspect of it, but after three graphics cards, an even older mainboard and two DVB-S-Cards, my home workplace PC currently does what I expect it to do: Run Debian unstable, drive two 20 inch DVI TFT monitors with 1600x1200 pixels each and receiving DVB-S transmissions. I do not think that these are exaggerated expectations, but it took over three months to find a combination of hardware which will actually do what I want.

The hardest part was finding a AGP graphics card which can drive two DVI monitors with 1600x1200 pixels each. After failing with two different Matrox cards (the G550 not being able to do 1600x1200 pixels if the monitors are connected via DVI), I finally settled on a used GeForce FX 5200. In the beginning, the binary nVidia module didn’t hurt as much as I expected. Unfortunately, this rapidly changed with the 2.6.27 Linux kernel.

Unfortunately, the Linux kernel changed its interface with 2.6.27, which stopped the nvidia-kernel-source 173.14.09 from sid from compiling. Contrary to what is told in #500285, the driver doesn’t compile on my system even when I clean out /usr/src/modules/nvidia-kernel prior to unpacking the driver .tar.gz.

I already thought that my problem was solved when I noticed nvidia-kernel-source 177.80 in Experimental. The module compiles just fine against kernel 2.6.27, but...

Nov 21 17:30:53 weave kernel: NVRM: The NVIDIA GeForce FX 5200 GPU installed in this system is
Nov 21 17:30:53 weave kernel: NVRM:  supported through the NVIDIA 173.14.xx Legacy drivers. Please
Nov 21 17:30:53 weave kernel: NVRM:  visit http://www.nvidia.com/object/unix.html for more
Nov 21 17:30:53 weave kernel: NVRM:  information.  The 177.80 NVIDIA driver will ignore
Nov 21 17:30:53 weave kernel: NVRM:  this GPU.  Continuing probe...
Nov 21 17:30:53 weave kernel: NVRM: No NVIDIA graphics adapter found!

Don’t closed source binary-only drivers just suck? I mean, granted, the FX 5200 is a five year old design, but it does its basic office job just fine. So I currently can choose to stick with a legacy kernel of the 2.6.26 series to be able to run the legacy nVidia driver, or can shell out money for a new graphics card and a new mainboard, a new CPU and new memory (since current graphics cards aren’t available for AGP any more). Just fine. Sucks.

If I get around to buying a new box, which graphics card manufacturer is to be trusted these days? nVidia is out of the question after my current experiences, Intel doesn’t make graphics cards as far as I know, and ATI/AMD? I hear that they have recently seen the light, but are their open source drivers mature enough so that ATI/AMD products can already drive high resolution dual DVI setup? I currently do not care about 3D performance, I just want to push around windows on a flat KDE desktop and to some serious work. All I want is screen real estate and a picture of decent quality. I’d appreciate any hints and comments, and surely hope that there will be some kind of upstream support for the 2.6.26 kernels until I have refitted my home workplace hardware.

Das war gar nicht HSO einfach

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Thu, 23 Oct 2008 23:29:43 +0200

Das Schicksal des Usenet-Teilnehmers hat einen T-Mobile Web’n’Walk-Stick (das schwarze Modell) in der nicht gesimlockten Version in meine Hände gespült. Auf sowas war ich ja immer schon scharf, weil ich mir von dem per USB angebundenen Gerät einen etwas stabileren Betrieb erhofft hatte als von meiner jetzt doch schon etwas älteren, nicht HSDPA-fähigen PCMCIA-Karte gewohnt bin. Aber das Ding unter Linux zum Laufen zu bringen war dann doch nicht so einfach wie gedacht.

Unter dem schwarzen Gehäuse verbirgt sich ein Option Icon 225, der leider ein wenig zu groß ist, um direkt auf einen der beiden etwas versenkt angebrachten USB-Ports meines Notebooks aufgesteckt zu werden. Dafür ist ein Clip für die Befestigung am Displaydeckel und ein etwa 20 cm langes USB-Kabel enthalten, das mir ermöglicht, den Stick dort festzuklemmen, wo ich vorher die externe Antenne der PCMCIA-Karte angeklemmt habe, wenn die funktechnische Umgebung für die Benutzung der eingebauten Antenne der PCMCIA-Karte nicht ausreichte - also besonders im Zug und in Frankfurter Bürogebäuden.

Eigentlich hätte ich erwartet, dass sich auch dieses Gerät wie die früheren UMTS-Dingens als per USB angebundenes serielles Modem zeigt, das man mit AT-Befehlen steuert und dann PPP spricht. Ganz so ist es eher nicht. Vorher schon hatte ich gewusst, dass die neueren Dinger die Installation unter Windows einfacher machen dadurch, dass sie sich als USB-CDROM zeigen, von dem die Treiber installiert werden können. Unter Linux ist sowas ja eher hinderlich, weil die benötigten Treiber ja eh nicht auf der “CD” drauf sind. Nun denn.

Für den Option-Stick gibt es einen Linux-Treiber namens HSO, der seltsamerweise über ein Webforum veröffentlicht wird. Da er noch nicht für Debian paketiert ist, freue ich mich darüber, dass ich in den Release-Notes für Kernel 2.6.27 lese, dass der HSO-Treiber jetzt im Mainline-Kernel enthalten ist. An anderer Stelle lerne ich sogar, dass die Entwicklung des HSO-Treibers von Option offiziell unterstützt wird - schön, dass wieder ein Hersteller das Licht gesehen hat.

Für den Wechsel von 2.6.26 auf 2.6.27 geht wieder der übliche Kampf mit den kommerziellen Modul-Lieferanten los, den ich endlich für den Wechsel von VMware zu Virtualbox OSE nutze - die schleppende Unterstützung neuer Kernel-Releases von VMware geht mir schon seit Jahren auf den Zeiger, und vmware-any-any wird in den letzten Monaten auch eher schlecht als recht gepflegt. Aber darüber blogge ich in einem anderen Artikel.

Nachdem auf meinem Notebook endlich die Voraussetzungen für die Installation von Linux 2.6.27 geschaffen sind (meine virtuellen Maschinen sind mir wichtiger als UMTS), gehen die Experimente mit dem neuen UMTS-Stick los. Ich lerne, dass man den Stick mit einem Userspace-Programm vom CD-ROM-Modus in den Modus für die eigentliche Benutzung umschalten muss, versuche mich ein paarmal mit dem überall empfohlenen rezero (was mir nicht nur einen Komplettabsturz des Notebooks beschert) und lande schließlich beim neueren ozerocdoff, das zusammen mit dem im Tarball enthaltenen 51-hso-udev.rules (was aufgrund seiner Unterstützung für eine lange Liste von Devices und allen möglichen udev-Versionen zu lang zum hier reinpasten ist) dafür sorgt, dass der Stick nach dem Einstecken automatisch in den richtigen Modus gelangt und man neben den drei erwarteten seriellen Devices auch ein weiteres Netzinterface hso0 im System sieht.

wtf? Ein Netzwerkinterface? Nun, das wird man doch sicher links liegen lassen können. Also schnell die PPP-Konfiguration an den neuen Interfacenamen angepasst und “pon umts-icon”. Was passiert? Nichts. der Verbindungeaufbau bleibt dort stehen, wo die PPP-Verhandlung beginnt. Alle drei seriellen Geräte durchprobiert, nichts. Also doch mal die Doku lesen.

Naja, die Doku ist zwiespaltig und besteht hauptsächlich aus Einträgen in Webforen von webforumsüblicher Qualität. Die Hilfe kommt mal wieder aus dem Pharscape-Forum, wo ein Anonymous seine Scripts veröffentlicht hat. Das ist zwar eine üble Kombination aus Chat- und Shellscripts, aber immerhin sieht man, wie der Icon bedient werden will: Die seriellen Devices dienen der Konfiguration des Sticks mit Hilfe von AT-Befehlen, der Datentransfer geht über das Netzinterface. Man konfiguriert den Stick wie die alten Karten, gibt ihm dann mit einem neuen Befehl die Anweisung zum Verbindungsaufbau, liest dann mit einem weiteren Befehl die Verbindungsparameter (hauptsächlich IP-Adresse und DNS-Server) aus und setzt sie dann mit ifconfig auf das Netzwerkinterface und los geht’s. Das ganze wird über /etc/network/interfaces so bedient, dass ein ifup hso0 die Verbindung aufbaut und ifdown hso0 die Verbindung wieder abbaut. Ein bisschen Überlegung erklärt auch, warum diese Perversion der Implementierung gewählt wurde: Bis zu 7.2 Mbit/s über eine (virtuelle) serielle Schnittstelle zu übertragen hat man sich dann wohl doch nicht mehr getraut.

Da ich chat(1) abgrundtief hasse und die Shellscripts aus dem Pharscape-Forum außerdem manche Debian-Mechanismen (allen voran resolvconf) ignorieren, entschließe ich mich, das ganze in Perl neuzuschreiben, unter Verwendung des Device::Modem-Moduls. Men Script findet Ihr hier - entgegen meiner sonstigen Gewohnheit nicht mit -T laufend, da Device::Modem im Tainted-Modus nur auf die Schnauze fliegt. Die Konfigurationsdatei sieht so aus:

<umts>
        provider vodafone-websessions
        controldevice /dev/wctrl0
        <default>
                pin xyzw
        </default>
        <simyo>
                apn internet.eplus.de
        </simyo>
        <vodafone-websessions>
                apn event.vodafone.de
        </vodafone-websessions>
</umts>

Zusammen noch mit dem /e/n/i-Eintrag

iface hso0 inet manual
        pre-up /usr/local/stow/hso/share/hso/hso-script
        post-up /usr/local/stow/hso/share/hso/hso-script
        pre-down /usr/local/stow/hso/share/hso/hso-script
        post-down /usr/local/stow/hso/share/hso/hso-script

kann die Verbindung dann manuell oder mit einem “allow-hotplug hso0” schon beim Einstecken des Sticks automatisch aufgebaut werden.

Kurz ausprobiert, geht. Ein bisschen gepingt, geht.

Am nächsten Tag im Zug dann die unangenehme Überraschung: Die Verbindung hält nur wenige Minuten und bleibt dann stehen. Im Log steht dann was von USB-Reset und einem fehlenden Callback im Treiber und “Tx timeout”. Das war’s dann bis zum Ausstöpseln des Sticks.

Kurzes Betrachten des Kernel-Quellcodes zeigt, dass im Kernel 2.6.27 hso.c 1.2 enthalten ist. Das Pharscape-Forum ist aber schon bei 1.6. Daniel Baumann, der inzwischen den HSO-Treiber für Debian paketieren möchte, ist noch bie 1.3 und sagt auch, dass er lieber bei den offiziell bei Option veröffentlichten Treibern bleiben würde. So im Regen stehend, suche ich nach einer anderen Lösung und kopiere schließlich das hso.c von Pharscape kurzerhand in meinen 2.6.27-Kernel-Tree und baue neu. Glücklicherweise ist der Treiber stabil genug, dass diese Kombination prima baut und auch läuft. Und sogar stabil.

Auf der Rückfahrt aus Hannover bin ich (online mit einer Vodafone Websession) ganz begeistert: Der neue Stick funkt trotz kleinerer Antenne auch im ICE ganz prima, bucht sich stabil und schnell zwischen UMTS und GPRS hin und her und selbst nach der Durchfahrt durch den Distelrasentunnel bei Schlüchtern kommt die Verbindung sauber wieder auf die Beine. Hier war sonst mit der alten PCMCIA-Karte verlässlich ein Neuaufbau der Verbindung fällig. Auch die sporadischen Hänger des Interfaces, bei denen sich die Karte auf den seriellen Devices tot stellt und nur durch ziehen und wieder einstecken wiederzubeleben ist, treten mit dem USB-Stick nicht auf. Entweder funkt der Icon 225 massivst besser als die alte Option Datacard 3G, oder ich hab nur einen ICE mit einem außerordentlich gut funktionierenden Repeater in Wagen 3 erwischt. Auf der knapp dreistündigen Fahrt habe ich nur einen Hänger, der das Ziehen der USB-Verbindung notwendig macht. Das ist eine bessere Bilanz als ich sie mit der alten PCMCIA-Karte je gehabt habe. Auf der nächsten Fahrt nach Berlin nächste Woche werde ich es mal mit der halb so teuren Tagesflatrate von Fonic probieren, die mit der alten PCMCIA-Karte im Zug reproduzierbar mehr Auszeiten als nutzbare Zeit produziert. Wir werden sehen.

LVM regelt verschärft

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 27 May 2008 15:00:00 +0200

Ich glaube, ich erwähnte es schon, aber LVM ist einfach cool. Ich bereue keinen Meter, schon seit 2002 LVM grundsätzlich auf jedem Linux-System das ich installiere einzusetzen. Damals war ich hauptsächlich scharf darauf, Festplattenpartitionen mit “sprechenden” Namen zu haben, die obendrein auch noch unabhängig davon sind, mit welcher Schnittstelle eine Platte an das System angebunden ist.

Aber auch Snapshots und die Möglichkeit zum Resize haben mir inzwischen schon öfter ~~den Arsch gerettet~~die Arbeit erleichtert.

Im Zuge meiner aktuellen Hardwarebasteleien hatte ich die Aufgabe, ein System von einer SATA-Platte auf eine PATA-Platte umziehen zu lassen. Das hätte man zwar natürlich auch mit einer tar | tar-Pipe oder rsync machen können, aber mit LVM ist es doch viel cooler (und man kann kein --numeric-owner und/oder --numeric-ids vergessen, was mein Lieblingsfehler ist).

Man fahre das System herunter, um die Zielplatte dazuzuhängen. Dann partitioniere man die Zielplatte, lege eine PV an und erweitere die VG des existierenden Systems um die neue PV (vgextend vg0 /dev/hdc1, zum Beispiel). Als nächstes weise man das System an, alle Daten von der “alten” PV herunterzuschieben (im Falle, dass die alte PV /dev/sda1 ist, zum Beispiel mit pvmove /dev/sda1). Das dauert eine Weile, also möchte man den pvmove-Aufruf eventuell mit --interval 30 garnieren, um alle 30 Sekunden darüber informiert zu werden, wie weit der Plattenshredder inzwischen fortgeschritten ist.

Während der gesamten Aktion kann das System, dessen Installation oder dessen Daten da gerade verschoben werden, im vollständigen Produktivbetrieb laufen, was natürlich für einen Server mit wichtigen Aufgaben sehr, sehr praktisch ist. Hat man Hardware, mit der Hotplugging von Festplatten möglich ist, geht die Migration auf eine neue Platte komplett ohne Betriebsunterbrechung. Natürlich bleiben Dateiattribute und sogar die Inode-Nummern unverändert, was bei einer hostbasierten intrusion detection die Menge der nach der Migration erzeugten Fehlalarme deutlich übersichtlicher macht.

Ist das pvmove abgeschlossen, entfernt man die “gehende” PV aus der Volume Group (vgreduce vg0 /dev/sda1, das ist wichtig. Unvollständige VGs mag der LVM auch dann nicht, wenn dort keine Daten mehr drauf liegen) und kann dann die alte Platte aus dem System entfernen.

Wo so viel Licht ist, ist natürlich auch Schatten: pvmove heißt pvmove und nicht pvcopy. Das bedeutet insbesondere, dass man die Daten wieder zurückverschieben muss, wenn sich herausstellt, dass man die neue Platte verkehrt partitioniert hat. Beim konventionellen Arbeiten würde man einfach die Kopieraktion wiederholen und hätte die Daten nur zweimal und nicht dreimal über die Schnittstelle geschlenzt.

Außerdem tun sich Linuxe etwas schwer mit dem Booten von LVM-basierten Systemen. Ich hatte jahrelang eine ausgeprägte initrd-Phobie, was mich dazu zwingt, das root-Filesystem mit typischerweise 200 MB Größe außerhalb des LVM liegen zu haben. Damit ist der Traum, auf hotplug-fähiger Hardware zum Plattenwechsel komplett ohne Downtime auszukommen, ausgeträumt, denn mindestens zum klassischen Umkopieren des Root-FS muss gebootet werden, außerdem macht man diese Kopieraktion am besten aus einem Rettungssystem. Aber da ich zeitlebens noch kein System mit hotplugfähigen Platten (außer USB, aber da hab ich das auch noch nie probiert) in den Fingern hatte kann ich damit auch leben.

Wenn man mutig ist und mit einer initrd booten kann, braucht man nur /boot außerhalb des LVM. Dann geht die Migration komplett ohne Downtime, denn /boot aushängen und kopieren kann man auch im laufenden Produktivsystem. Allerdings will man vermutlich dann auch mal booten, um zu gucken, ob man auch alles richtig gemacht hat - im Zweifelsfall ist sonst der nächste Boot in einer Streßsituation und man darf dann auch noch mit den Fehlern kämpfen, die man beim Umkopieren gemacht hat.

Grub2 kann dem Vernehmen nach auch aus einem LVM booten; sollte Grub2 wider erwarten in diesem Leben nochmal benutzbar werden, kann man sich auch das außerhalb des LVM liegende /boot sparen. Aber ich fürchte, bis dahin wird noch eine Menge Wasser durch die Neckarschleusen fließen.

Noch zwei Worte zum Thema initrd-Phobie: Die war weitgehend unbegründet. Debians initrd-Tools sind in Form von initramfs-tools inzwischen so flexibel und ausgereift, dass der Spaß erstaunlich schmerzarm abläuft und man im Normalbetrieb keine Fußangeln vorfindet. Das funktioniert einfach. Aber bis ich meine Standard-Server-Installation auf initrd umstelle, muss noch etwas Zeit vergehen.

Weird networking MTU issue

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 11 Oct 2006 15:17:00 +0200

Given a simple, switched LAN with Debian Linux (sid, iputils-ping) and Microsoft Windows XP (Service Pack 2, with the Windows Firewall disabled). A user complains about the network being slow (meaning his Windows notebook). I quickly find out that I can ping the box from my Linux notebook if my -s parameter is < 1393 or > 1472. If it’s between 1393 and 1472, no replies are received.

I spend the next hour with debugging this not so interesting phenomenon.

Consulting with my Windows colleagues, they quickly find out that “it must be a Linux issue”, since if it’s a Windows box issueing the ICMP echo request, everything is fine.

Unfortunately, this issue cannot be reproduced with most of the test Windows boxes we have available. After finally finding an available test box which shows the issue, I install Wireshark on the Windows box, which is a rather pleasing experience since Wireshark has a clickable .exe installer that also takes care of installing the winpacap library. This is a lot less painful than it was with Ethereal two years ago.

Looking at the packet trace, the issue is quickly explained.

iputils-ping sends out the ICMP echo request packets with the “don’t fragment” bit set.
Windows’ ping allows fragmentation by keeping the “don’t fragment” unset.
If the echo request is smaller than 1393 bytes, everything is fine. The Windows box answers as it is supposed to. It doesn’t matter whether the request is from Linux or from Windows since fragmentation does not play a role here.
If the echo request is bigger than 1472 data bytes, the request needs to be fragmented as the Linux box’ MTU is 1500. In this case, iputils-ping - of course - does not set the DF bit, and the Windows box sends back a properly fragmented echo reply. Same thing happens - of course - with the Windows-generated ping since Windows’ ping never sets DF.
Now, if the Linux-generated echo request (thus having DF set) is within the size range mentioned above, Windows does not answer at all.
If the Windows-generated echo request (not having DF set) is within the appropriate size range, the request fits in a single frame. Windows fragments the reply with the first fragment being 1434 bytes long.

I now place the hypothesis that some of our Windows boxes operate with a MTU of 1434. Thus, it is not supposed to answer the Linux-generated echo request (with DF set) if it cannot send back the answer unfragmented. It is, however, IMO, supposed to send back a “host unreachable, fragmentation needed but DF set” ICMP error packet. It doesn’t do that, which causes the behavior observed.

The Windows boxes in question do not have an “MTU” option in the advanced settings of the network interface as other boxes have, and the appropriate Registry key setting the MTU is missing in the adapter settings.

I am now wondering whether my reasoning is wrong, or Windows is indeed buggy. Or misconfigured.

Any ideas?

Linux ARPs too much

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Mon, 28 Aug 2006 14:53:41 +0200

~~Playing~~Experimenting with arping, I found the following behavior:

$ sudo arping -c 1 10.202.202.254
ARPING 10.202.202.254
60 bytes from 00:0f:20:d4:07:e0 (10.202.202.254): index=0 time=196.934 usec

--- 10.202.202.254 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered
$ sudo arping -c 1 10.101.2.1
ARPING 10.101.2.1
60 bytes from 00:0f:20:d4:07:e0 (10.101.2.1): index=0 time=168.085 usec

--- 10.101.2.1 statistics ---
1 packets transmitted, 1 packets received,   0% unanswered
$

wtf? 10.101.2.1 is my default gateway (running a recent Linux 2.6 kernel), so it is ok to answer ARP requests. 10.202.202.254 is bound on the same box, but on a different interface, so I don’t think it is ok to answer ARP requests for that IP address on “my” interface, as it confuses some “what network segment am I on today” mechanisms.

Is there some /proc setting where I can disable this rather generous ARP behavior?

No more sl-modem-modules for me

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Wed, 21 Jun 2006 10:29:15 +0200

A few months ago, I have reported about getting the winmodem in my hp compaq nc 8000 to work.

Aside from the abysmally slow performance, the dependency on out-of-tree, non-free modules has been cause of grief since it has almost constantly forced me to keep an outdated kernel version around just in case that I would need the modem.

Fortunately, this is over now since more recent kernel versions (I suspect somewhere in the 2.6.16 era) support my winmodem natively without out-of-tree modules. All I need to get only on a POTS line is sl-modem-daemon, which is reasonably painless.

s9y als Partylog gescheitert

mh+blog-zugschlus-de@zugschlus.de (Marc 'Zugschlus' Haber) — Tue, 20 Jun 2006 13:00:00 +0200

Letztes Wochenende war ich auf dem d.t.r.-Treffen in Röhrenspring im schönen Sauerland. Abgesehen davon, dass an dieser Location kein Mobilfunknetz verfügbar war, empfand ich das lange Wochenende als wunderschön.

Traditionell wird auf dtr-Parties ein Partylog geschrieben. Was ursprünglich ein Notebook mit offenem Editor war, ist inzwischen eine von Stefan geschriebene kleine PHP-Anwendung, die den Inhalt einer TEXTAREA direkt in ein Textfile schreibt - was einmal geschrieben ist, kann nicht mehr geändert werden.

Da Stefan diesmal erst später dazustößt, habe ich mir ein paar Gedanken gemacht und ein Notebook vorbereitet, das als Partylog dienen soll. Dabei hatte ich die Idee, aus dem Partylog ein Partyblog zu machen, und habe s9y eingesetzt.

Die Idee finde ich immer noch klasse, aber sie wurde nicht akzeptiert.

Auf einem in der Firma requirierten Notebook (Compaq Armada M700) habe ich mit dem Debian-Installer ein LAMP-System unter Debian etch installiert. Der Installer ist inzwischen verdammt gut geworden. Ich bin wirklich begeistert.

Da es sich ja um ein offline-System ohne “wichtige” Daten handelt, kann ich hier schlusen: serendipity läuft im Apache-Modul als www-data, benutzt den mySQL-Root-Account. Auf dieser Basis ist s9y schnell eingerichtet.

Mit passenden Plugins ist s9y so konfiguriert, dass sich jeder Benutzer direkt selbst einen Account einrichten kann, und für die ganz faulen ist gleich ein Dumpfbackenaccount angelegt. Dann noch etwas an der Optik feilen, testen, tut. Danke, s9y ist auch hierfür geeignet.

Als nächstes gilt es, das KDE so zuzunageln, dass kein großer Schaden angerichtet werden kann. Dank Kiosk-Konfiguration ist das relativ simpel: Über ein GUI kann der Administrator Profile festlegen, in denen man einstellen kann, welche Einstellungen aus /etc/kde-profile geladen werden und welche dieser Einstellungen der Benutzer für sich überschreiben kann. Zusätzlich wird dann jedem Kiosk-Account ein Profil zugeordnet und fertig ist die Laube.

Damit ich administrieren kann, wird KDE so eingestellt, dass ich per User Switching (das man IIRC nur im Kontrollzentrum aktivieren muss) eine zweite, nicht zugenagelte, Session mit meinen Userrechten starten kann, ohne dass die Kiosksession geschlossen werden muss.

Im kdm kann man einstellen, dass der Login für einzelne Benutzer ohne Passwort durch Klick möglich ist. Diese Möglichkeit nutze ich für den Kiosk-User, und konfiguriere zusätzlich einen Autologin für diesen Benutzer. Somit ist der passwortlose Login nur dann notwendig, wenn jemand aus Versehen die Session beendet hat. Innerhalb des Kiosk-Users wird sofort ein Konqueror mit dem Blog-URL gestartet.

Bei der Einrichtung des Partyblogs habe ich viel gelernt. Nur: Genutzt haben es in den ersten zwei Tagen exakt zwei Leute, und beide haben den vorgekauten Dumpfbackenaccount verwendet. Nachdem Stefans Partylog da war, hat sich niemand mehr für das Blog interessiert. Schade drum, ich hab’ das dann schon am Freitag abend abgebaut und weggepackt. Dafür muss ich echt kein wertvolles Notebook offen rumstehen lassen.

Wenn ich bei der Einrichtung nicht so viel gelernt hätte und einen Installation-Report für den Debian-Installer liefern (und dabei auch einen Bug entdecken) konnte, hätte ich mich über die mangelnde Beteiligung geärgert. Aber man kann die Leute halt nicht zu ihrem Glück zwingen, und ich gewöhne mich irgendwann bestimmt daran, nicht mehr grundsätzlich der konservative Bremser, sondern auch mal der innovative Promoter neuer Techniken zu sein. Auch wenn - oder gerade weil - sie nicht unbedingt gewünscht sind.