Zugschlusbeobachtungen

Und da waren es nur noch drei. Pelle hat in seinem achtzehnten Lebensjahr seine Augen für immer geschlossen. Damit hat er Jahre länger gelebt als Ärzte und “Fachleute” ihm gegeben hatten. Er war seit 2008 diagnostizierter insulinpflichtiger Diabetiker, aber das hatten wir bis zum Schluß eigentlich ganz gut im Griff. Letztendlich waren es altersbedingte Stoffwechselstörungen, die dafür gesorgt haben, dass er immer weniger gefressen hat, ständig nach etwas zu essen gesucht hat aber dann nichts gegessen hat. Selbst Leckerli wollte er keine mehr. So wurde aus dem ehemals stattlichen Sechskilokater ein nicht einmal mehr drei Kilo wiegendes bisschen Katz, das eigentlich nur noch aus Haut und Knochen bestand.

Pelle war ein unglaublich kluger Kater, mit dem man sich richtig unterhalten konnte. Er hat einem zugehört, war sehr auf seine Menschen fixiert, war nahezu immer in der Nähe, aber nur selten aufdringlich. Keine Katze meines Lebens hatte den Begriff “Teddy” mehr verdient als Pelle. Er war mit Kindern unglaublich geduldig, hat sich in Ruhe quer durch Haus und Wohnung schleppen lassen und ist schlicht verschwunden wenn er nicht mehr wollte. Er war immer eher mürrisch und tat gerne genervt, aber die Aufmerksamkeit seiner Menschen war ihm trotzdem wichtig. Und er war unglaublich liebevoll zu seinen Menschen. Gegenüber den anderen Katzen war er eher der unnahbare und bis zum Schluß der unangefochtene Chef. Lag eine andere Katze auf seinem Lieblingsplatz und erkletterte er den Kratzbaum, ist die andere ohne zu zögern aufgestanden und hat seinen Platz ohne zu Murren und vor allen Dingen ohne Aufforderung freigeräumt. Diese Situationen wird es nun nicht mehr geben. Er wird uns sehr, sehr fehlen.

Pelle saß auf meinem Schoß, als die Tierärztin ihr Zeug vorbereitete. Und als sie so weit war, und ihn angeschaut hat, ist er aufgestanden und zu ihr gegangen. Als ob er wusste, dass seine Zeit gekommen ist. Ich habe ihn zehn Jahre lang gekannt, aber mit dieser seiner letzten Aktion hat er mich dann doch nochmal verblüfft und gerührt auf einmal.

Gestern hat Heise geschrieben, was die Communications Electronics Security Group (CESG), eine Abteilung des britischen Nachrichtendiensts GCHQ, empfiehlt, und was ich schon seit gefühlt 1847 predige: Der Zwang zur regelmäßigen Änderung von Passworten erweist der IT-Sicherheit nicht selten einen Bärendienst.

Nutzer, die einerseits zu immer komplexeren Passworten gezwungen werden, und diese andererseits dreimal in der Woche ändern müssen, neigen - für viele IT-Abteilungen völlig überrschend - dazu, diese Passworte aufzuschreiben, sie überall zu verwenden und sie bei erzwungenen Änderungen nur minimal zu ändern. So findet sich in meinen AD-Passwörtern diesen Monat die Zeichenkette 416, man darf raten woher sie kommt.

Ich bin ja ein großer Fan von Systemen, die den Benutzer für ein komplexes Passwort loben (“Dieses Passwort bekommt auf einer Skala von 1 bis 10 eine 8, wobei die Ähnlichkeit zum alten Passwort zur Abwertung geführt hat”) und ihn vielleicht sogar dafür belohnen (“Dieses Passwort ist so herrlich komplex und unterscheidet sich so signifikant von Deinem alten Passwort, dass Du es jetzt 18 Monate behalten darfst”). Ich frage mich, warum sowas heutzutage so selten implementiert wird. Ich hab sowas zwar schonmal gesehen, aber das ist fünfzehn Jahre her, und seitdem nie wieder. Dabei ist diese Idee so nahe liegend.

Ach ja, das Blog gibt es noch. Ich plane seit Monaten, es auf einen neuen Server zu migrieren und dann auch wieder mit Inhalten zu bestücken. Nachdem wir jetzt auch schon bald zwei Jahre in unserem Haus leben, könnte ich langsam mal anfangen, die Baustellen-Highlights zu verbloggen.

Vor vier Jahren und etwas mehr drei Wochen musste ich den letzten Nachruf auf einen Kater schreiben. Damals war es unerwartet, denn Paulchen war eigentlich nach einer Operation schon auf dem Wege der Besserung.

Bei Murphy war es anders. Er hat schon seit einigen Wochen immer mehr gehustet, so dass wir dann irgendwann doch zum Tierarzt gegangen sind. Nach einer leichten Cortison- und Antibiotikatherapie stellte sich eine deutliche Besserung ein, so dass wir der Meinung waren, die leichte Lungenentzündung wäre überstanden. Dann wurde der Husten wieder schlimmer, sein Wesen veränderte sich, er zog sich immer mehr zurück. Schließlich ging es dann doch wieder in die Tierklinik.

Drei Röntgenbilder später war die schreckliche Diagnose klar: Ein Tumor an der Stelle, wo die Luftröhre in die Bronchien übergeht, drückt ihm buchstäblich die Luft ab. An eine Operation oder anderweitige Therapie an dieser Stelle ist nicht zu denken. Es ging also nur noch darum, ihm die verbleibenden Wochen so wenig unangenehm wie möglich zu machen. Cortison ist das einzige, was man ihm hätte verabreichen können.

Aber auch nach der ersten Cortisonspritze stellte sich keine Verbesserung ein. Er lag nur noch herum, konnte wohl auch nicht mehr schnurren, so dass wir schließlich schweren Herzens den Tierarzt zum letzten Hausbesuch bitten mussten.

Murphy durfte auf meinem Schoß friedlich und ruhig einschlafen. Seine Schwester Kira stand verständnislos daneben und versuchte ihn noch zu schmusen, als er schon nicht mehr in der Lage war zu reagieren.

Und da waren es nur noch zwei.

When one discusses advantages and disadvantages of some distributions over the other, it is a frequent beef against Debian that on Debian, network services get started immediately after the package was installed. On a package not driven by debconf, this includes the service getting started with some default configuration. On upgrades, services get stopped before the update and started automatically after the update was done. This might be useful with services that run with the default configuration, and is important with services that fork and re-read the configuration in the forked-off process. However, in some circumstances, it might be desireable to keep the old version of the service running until the new version is ready to start. I have always thought that this was written down in Debian policy, but I didn’t find the place in the document, and asking on various IRC channels also resulted in no pointer. For now, I have to assume that this is “only” best practice in Deban and not mandatory in any case.

Debian is frequently bashed for this default, and the canonical answer is to use the policy framework delivered with sysv-rc to avoid services from being started. Since this mechanism is frequently misunderstood, I am writing this article to bring some more additional confusion to this matter.

Updated 2013-09-01: Default behavior controllable by init script headers.

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.

Wie Ihr vielleicht wisst, war Professor Heinz Haber, der in den 1960ern, 1970er, und 1980ern im Deutschen Fernsehen zum Thema Wissenschaft sehr präsent war und der sogar ein paar Bestseller geschrieben hat, mein Vater.

Am 15. Mai 1913 geboren, wäre er heute einhundert Jahre alt geworden. Anlässlich dieses Jubiläums gibt es im Planetarium Mannheim eine kleine Ausstellung mit Gegenständen aus seinem Nachlass. Diese Ausstellung wurde gestern festlich im Beisein von Bürgermeister Grötsch, dem Chefredaktur von bild der wissenschaft, Wolfgang Hess, und etlichen meiner Verwandten, festlich eröffnet.

Heute abend ist im Karl-Friedrich-Gymnasium Mannheim, wo mein Vater sein Abitur gemacht hat, ebenfalls eine Veranstaltung zum Gedenken an meinen Vater.

Während meine Schwester Cathleen heute abend im KFG ein paar private Worte sagen wird, hatte ich gestern abend die Ehre, im Kuppelsaal des Mannheimer Planetariums ein paar Geschichten über meinen Vater erzählen zu dürfen.

Wer sich dafür interessiert, was ich gestern gesagt habe, darf auf “Weiter” klicken und mein Manuskript lesen. Ich habe mich während der Veranstaltung ein bisschen kürzer gefasst als geplant, aber hier veröffentliche ich das, was ich sagen wollte.

In Stuttgart Hbf hat es - mal wieder - gekracht. Der aktuelle Fall hat aber nach den vorliegenden Informationen nur wenig mit dem zu tun, was Mitte 2012 passiert ist. Dort waren Reisezüge bei der Ausfahrt bzw. bei Testfahrten entgleist, und man diskutiert darüber, ob man bei den Vorbereitungsarbeiten am Gleisvorfeld des Hauptbahnhofs für die Stuttgart-21-Bauarbeiten vielleicht ein bisschen zu sportlich bei der Planung der Gleisgeometrie war.

Dazu möchte ich mich aber hier genau so wenig äußern wie über die Sinnhaftig- oder -losigkeit des gesamten Bahnprojekts Stuttgart 21, zu dem ich eine klare, aber auch differenzierte Meinung habe.

Das was heute sehr wahrscheinlich passiert ist, kommt aber aus einer völlig anderen Kiste und zeigt nur, dass die Sicherheitstechnik der Eisenbahn auch dann funktioniert, wenn Menschen einen Fehler machen, und dass das System Bahn im Zweifel zur sicheren Seite versagt. Und auch wenn es komisch klingt: Eine im Dreck stehende Rangierlok ist eine sichere Rangierlok.

Heute vor fünf Wochen lag ich auf dem Operationstisch in der Tagesklinik in Koblenz. Und wie es da hin kam und wie es mir nachdem ergangen ist, erzähle ich Euch heute.

Gestern schrieb ich Euch, wie ich zu meiner 33 Gramm schweren Brille mit 20 Prismendioptrien Basis Außen gekommen bin, und dass mich das Tragen der Brille schon ein wenig genervt hat.

Die Fortsetzung des Artikels von gestern

Aufgabe: Transportiere Daten von einem Host auf den anderen über eine ssh-Verbindung. Dafür kann man scp oder sftp verwenden, wenn der eigene Account auf der anderen Seite die Daten lesen darf:

myuser@$TRGHOST$ scp $SRCHOST:$PATH/file .

Interessanter wird das dann, wenn die Daten auf der anderen Seite vom eigenen Account nicht gelesen werden können, man also erst einmal sudo bemühen muss, um die Daten lesen zu können. An dieser Stelle versagt scp bereits - es sei denn, man kann sich auf der anderen Seite als anderer User einloggen:

myuser@$TRGHOST$ scp $ANDERER_USER@$SRCHOST:$PATH/file .

Nur, das scheitert oft daran, dass man das Passwort von $ANDERER_USER nicht kennt, nicht neu setzen kann und/oder seinen ssh-Key nicht in $ANDERER_USER/.ssh/authorized_keys fallen lassen kann oder darf.

Bei einer meiner letzten Serverstörungen kam zusammen mit der Nachricht, man hätte die Hardware getauscht und es würde nun alles wieder gehen der Hinweis, ich solle doch mal wieder bloggen. Das möchte ich hiermit tun - allerdings vorerst nicht vom Thema Bau. Ich bin Euch aber noch schuldig, wie es mit meiner Winkelfehlsichtigkeit und meiner Brille weitergegangen ist. Der Link führt zu den entsprechend getaggten Artikel, wenn man also nachlesen mag, sei man herzlich eingeladen.

Kurze Zusammenfassung der Vorgeschichte: Ich hatte seit meinen Teenagerjahren regelmäßig Kopfschmerzen, die ich von meinem Vater geerbt hatte. Das waren keine Migräne, sondern nach der Literatur eher dem Spannungskopfschmerz zuzuordnen, und beeinträchtigten meine Lebensqualität schon erheblich: Mehrmals im Monat hatte ich solche Kopfweh, dass ich eigentlich nur noch Radio hörend im Bett liegen konnte. Auf Hälfte der Uni habe ich dann eine Brille verschrieben bekommen, weil ich mich darüber beklagt hatte, dass es beim Hochgucken vom Heft zur Tafel immer ein paar Sekunden brauchte, um das Tafelbild scharf zu sehen. Ich hätte damals schon stutzen sollen, als ich eine Brille mit Plus-Werten, also für Weitsichtige verschrieben bekam. Fielmann hat aber die Werte vom Augenarzt auch nie hinterfragt, sondern ohne nachzumessen die Werte in die Brille reingemacht, die der Augenarzt aufgeschrieben hatte.

Als ich schließlich Sandra kennenlernte, hat ihr Chef bei mir eine Winkelfehlsichtkeit gemessen und ich habe, damals noch ganz an die Schulmedizin glaubend, entgegen des Rats aller Augenärzte mit großem Magengrimmen eine Prismenbrille gekauft. Und schwupps, war ich mitten im Krieg zwischen Augenoptik und Schulmedizin, denn die Meß- und Korrekturmethode nach Haase ist nicht unumstritten.

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.

Bert Hubert hat geblogged. Und zwar darüber, worauf man achten muss, wenn man seine Applikation IPv6 kompatibel machen möchte. Bei der IPv6isierung von PowerDNS ist er wohl in einige Fallen getappt und hat das, was er dabei gelernt hat, öffentlich gemacht. Das Ding ist auch kurz genug, um es auch dann zu lesen, wenn man eigentlich kein Entwickler ist.

http://bert-hubert.blogspot.co.uk/2012/08/a-few-quick-notes-on-making-application.html

Ich habe zu lange nicht mehr über unseren Bau berichtet. Das liegt dummerweise unter anderem daran, dass der Hausanbieter, der schlußendlich bereit zu sein scheint, unser Haus zu bauen, mir einen Internetmaulkorb verpasst hat. Ich muss also höllisch aufpassen, was ich schreibe, denn da hängt ein doch erhebliches Kostenrisiko dran. Doch dazu vielleicht in einem späteren Artikel mehr, und in einem anderen Artikel werde ich Euch schreiben, was passiert, wenn Baugeld billig ist, die Auftragsbücher der Hausanbieter platzen und sie sich somit aussuchen können, welche Kunden die Ehre eines Hauses bekommen und welche nicht. Da wünscht man sich echt höhere Zinsen.

Aber was ich euch eigentlich heute schreiben möchte ist, dass man vorsichtig sein muss, wenn man nicht mit dem zukünftigen Vertragspartner (dem Anbieter), sondern mit einem Handelsvertreter des Anbieters verhandelt. Das ist für den Kunden nämlich eine außerordentlich ungeschickte Konstellation, die dem Anbieter zahlreiche Möglichkeiten gibt, die Konkurrenz aus dem Rennen zu schießen und den Kunden ein wenig mehr über den Tisch zu ziehen. Mehr dazu nach dem Klick.