Zugschlusbeobachtungen

In meinem Seminarraum habe ich die Multimedia- und auch die Netzwerkverbindungen teilweise mit Keystone-Modulen realisiert. Keystones haben den Vorteil, dass es sie für fast alle physikalisch in den 14x16-mm-Formfaktor passenden Verbinder verfügbar sind und es eine breite Auswahl an "Frontblenden" gibt, in die man die Keystone-Module einrasten kann.

"Frontblenden" gibt es sowohl in verschiedenen "Lochanzahlen" als Aufputz-Gehäuse und 19-Zoll-Einbaublenden sowie in Einzel- und Doppelvarianten für normale Unterputzdosen und BR-Kanäle. Ich habe in meiner Umgebung Keystones für RJ45, Cinch, Toslink und (bald, ist bestellt) USB im Einsatz.

Zugschlus plaudert aus dem Nähkästchen.

Es ist schon eine Weile her. Bei einem langjährigen Kunden, der mich immer mal wieder mit haarigen Debuggingaufgaben oder komplexen Planungen inklusive Migration beauftragt hat. Einem so langjährigen Kunden, dass ich dort nahezu alle Leute duzen durfte und ein- und ausgehen durfte wie mir gerade zumute war.

Ich komme also im Office des Kunden an und suche mir einen freien Schreibtisch in einer Ecke des Großraumbüros mit für mein Tagewerk genug freien Netzwerkports. Zwei Tischreihen weiter stehen drei Mitarbeiter des Kunden aus dem Bereich Clientmanagement ratlos um einen PC herum. ich schnappe Unterhaltungsbrocken auf, und bekomme mit, dass das Softwareverteilungssystem für Windows-Clients sich nicht in der Lage sieht, das Redmond-Betriebssystem auf diesem Rechner zu installieren. Ich werde neugierig.

Ich habe mir nach langer Abstinenz mal wieder einen Server bei Hetzner gemietet. In der Serverbörse verschachert der Anbieter ältere Geräte als Einzelstücke, die von ihrem bisherigen Mieter zurückgegeben wurden und die teilweise aufgrund individueller Ausstattung nicht in den Mainstream hineinpassen. Dabei kann man als Kunde auch richtige Schnäppchen machen.

So bin ich seit zwei Wochen stolzer Mieter eines Hetzner-Servers mit Core i7-Vierkerner der Bloomfield-Generation mit Hyperthreading mit stolzen 48 GB RAM. Die Miete liegt bei unter 40 Euro im Monat und lässt den ähnlich alten, zum Mai gekündigten 1&1 Rootserver, der mit nur 4 GB RAM ähnlich viel Geld kostet, ziemlich alt aussehen.

Aber so ein Schnäppchen hat natürlich auch Nachteile. So gibt es nur eine einzige IPv4-Adresse, und IPv6-Adressraum, der über das standardmäßig dazugehörende einzelne /64 hinausgeht, lässt sich der Anbieter mit einer Einrichtungsgebühr in der Größenordnung von zwei Monatsmieten relativ fürstlich bezahlen. Und es gibt keine serielle Konsole. Man kann sich für einen bestimmten Zeitraum ein KVM-over-IP-Gerät anschließen lassen und die ersten x Stunden sind sogar inklusive, aber das ist natürlich nur ein magerer Ersatz. Die vom Anbieter angepriesene vnc-Installation funktioniert freilich nur für die von ihm vorbereiteten Systeme; bei näherer Betrachtung liegt das aber auch auf der Hand: Wie soll das sonst ohne Spezialhardware gehen.

In diesem Artikel soll es darum gehen, wie ich mein zgserver-Debian "blind" auf die Maschine bekommen habe.

Die gute alte Dame SMTP, das Simple Mail Transfer Protocol, hätte sich zu Zeiten seiner Definition 1982 kaum vorstellen können, wie häufig es in den 35 Jahren erweitert und für neue Anwendungen missbraucht werden würde.

In diesem Artikel geht es darum, SMTP dazu zu benutzen, um von einem Mailclient ohne eigene Serverfunktionalität Mail bei einem Smarthost einzuliefern. Eigentlich ein gelöstes und alltägliches Problem, möchte man meinen.

Oftmals hat man die Aufgabe, einen maschinenübergreifenden Zugriff automatisiert stattfinden zu lassen, ohne dass man der einen Seite gleich "vollwertige" Credentials für einen interaktiven Login auf der anderen Seite geben möchte. Wenn der Zugriff automatisiert stattfinden soll, fällt auch noch die Sicherheitsstufe eines ssh passphrases weg, da niemand da ist um diesen einzugeben.

ssh forced commands bieten eine Möglichkeit, einen solchen Zugriff zu erlauben, ohne gleich die Büchse der Pandora zu öffnen. Selbst ein automatischer Zugriff mit root-Rechten ist auf diese Weise "reasonably secure" realisierbar.

Yes, You Should Not discard cached ssh host keys without looking. An unexpected change of an ssh host key is always a reason to step back from the keyboard and think. However, there are situations when you know that a systems' ssh host key has changed, for example when the system reachable under this host name has been redeployed, which happens increasingly often proportionally to the devopsness of your environment, or for example in test environments.

Later versions of ssh offer you the ssh-keygen -R command line to paste from the error message, so that you can abort the connection attempt, paste the command and reconnect again. This will still ask for confirmation of the new host key though.

Almost every sysadmin has an alias or wrapper to make handling of this situation easier. Solutions range from using "StrictHostKeyChecking no" and/or "UserKnownHostsFile /dev/null", turning off this layer of securit altogether either globally or usually too broadly, to more-or-less sophisticated solutions that involve turning off know-host file hashing, parsing client output and/or grep-sed-awk magic. grml even comes with an insecssh script that is rather neat and that I used until I developed my own.

Starting with OpenSSH 7.2, a new "restrict" option for authorized_keys lines has become available. It sets all available restrictions that the current OpenSSH version can do (like no-agent-forwarding, no-x11-forwarding etc). One can individually turn on those features again by corresponding new options.

This saves one from sorrows when a new capability of OpenSSH is introduced through an update which is enabled by default, since one has to remember that restricted authorized_keys lines are in unse and then to manually add the restrictions.

On the downside, Debian jessie and CentOS 7 don't have a recent enough OpenSSH. So we'll have to continue worrying about new features being inadvertendly enabled for a while.

P.S.: Yes, I haven't blogged about Linux and Debian in English in a while.

I have just uploaded PowerDNS 3.3-1~exp1 to Debian experimental. This new upstream version has introduced its own include directive, so Debian was able to drop its patch. Hence, our conffiles had to grow a .conf extension, which most of them didn't have in previous version.

If anybody wants to test updates from PowerDNS 3.1 to the new 3.3-1~exp1 in Debian unstable, please go ahead and report bugs in the Debian BTS. The package is known to not offer seamless DNSSEC, I'll work on that before I upload to unstable.

While we're at it: I would appreciate help with the PostgreSQL backend. Myself, I use mainly MySQL and am not too proficient in PostgreSQL. I'll accept both patches and more formal co-maintenance.

Migrating a Debian installation between architectures has always been difficult. The recommended way to "crossgrade" an i386 Debian to amd64 Debian is to reinstall the system, move over data and configuration. For the more brave, in-place crossgrades usually involved chroots, rescue CDs, a lot of ar p | tar xf - data.tar.gz and luck.

I have never been brave when it comes to system administration, have done a lot of architecture migrations with reinstallation, and have always taken the opportunity to clear out the contamination that accumulates itself when a system is running for a long time. I would even recommend doing this to most people even now. However, I have a few very ugly systems in place that are still on i386 because I didn't dare going the reinstallation path.

Doing in-place crossgrades has become a lot easier since wheezy's release, since once now can have both i386 and amd64 libraries installed in parallel, which allows to replace foo:i386 with foo:amd64 without influencing the other parts of the system. The process is still full of pitfalls:

• In wheezy, many library packages are multiarch capable. This means that you can have those library packages installed for more than one architecture. This is a technical must for this way of crossgrade, so never use that for an older-than-wheezy system. It won't work, it needs at least Debian wheezy. Unfortunately, not all libraries in wheezy are multiarch capable. This makes the process harder and a lot less predictable, since a crosscrade including such packages is going to spew incomprehensible and misleading apt error messages. In my experience, for example the libaprutil-1-dbd-* packages and libonig2 are of this kind.
• apt removes a package before it reinstalls its new counterpart. This results in apt calling dpkg to remove dpkg, and then calling dpkg again to install dpkg. Guess which operation fails and the state of the system after this failure. Same applies to coreutils, which leaves the system without rm, which in turn dpkg of either architecture doesn't like. Using apt-get --download-only install to resolve dependencies and downloading the debs, followed by a traditional dpkg --install solves this issue since multiarch dpkg will replace a package with another one without deinstalling the first one first.
• At least for the process, you need a kernel that can run both 32bit and 64bit binaries for the i386 architecture. AFAIR, setting CONFIG_64BIT, CONFIG_X86_64 and CONFIG_IA32_EMULATION in the kernel configuration takes care of this.
• During the process, apt will temporary go into a badly broken state where it will refuse most operations. Be aware that you might need to manually download packages from the Internet. Be sure to have wget, curl, or a browser (maybe a text based one like elinks) available. dget is not going to help you here since it will only downloda packages for the native arch.
• During the process, apt wants to remove the better part of your system. It is important to not let it do this, as it wants to deinstall essential packages as well.
• Watch what your system does. During some steps, it might remove packages you might need. Keep track of the packages that were removed during the process and re-install them manually after finishing the crossgrade. Be sure not to purge packages that you might still need.
• It looks like the process is not always exactly reproducible. During the first tries, I found myself without an initrd at all, with an initrd that lacked the ext[234].ko kernel modules, without working e2fstools and in a number of other undesireable states of the system.

I have only tried this yet with a freshly installed minimal wheezy server system. Trying the process with "real life" systems has shown to be full of more surprises. I will document other pitfalls I have fallen into here at a later time. My minimal wheezy system was running in a KVM VM with its virtual disk as a LVM LV in the host system. I took a snapshot before beginning and used lvconvert --merge numerous time to return my LV to the original state. Be aware that lvconvert --merge removes the snapshot after merging it, so you'll need to re-create the snapshot before trying again.

The process is absolutely not for the faint of the heart, and intimate knowlegde of Debian mechanisms is required at many points in the process. Please seriously consider a reinstall+migrate approach instead of using this process, and be sure to practice it on a working copy of your system before touching the live system. And always have a backup.

During the process, I discussed things with Paul Tagliamonte, who has done this before, but on a live system and with a slightly more invasive approach. He has blogged about this. Thank you very much, your hints were very helpful.

Aus aktuellem Anlass hier ein aus den wegen dummer Software derzeit unerreichbaren "Zugschlus' manchmal nützlichen Antworten" schnell reingepasteter Artikel

Ungenaue Terminologie wird im Internet oft von Leuten verwendet, die zwar ungefähr wissen, wie die Dinge funktionieren, sich aber nicht im hinreichenden Maße mit den Hintergründen beschäftigt haben. Dies erschwert die Kommunikation und ist oft dafür verantwortlich, dass ein Auftragnehmer nicht das ausführt, was sein Auftraggeber eigentlich möchte.

Ein besonders von diesem Problem geplagter Bereich der Internet-Technik ist der Domain Name Service (DNS), da hier in besonderem Maße die Kommunikation zwischen verschiedenen Leistungsträgern in unterschiedlichen Unternehmen notwendig ist.

Mit diesem Text will ich versuchen, etwas Klarheit in die Terminologie zu bringen.

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.

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.

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.

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.

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.