Update-Nachwehen
Nach einem Debian-Update tut es an manchen Stellen mehr, und an manchen anderen Stellen weniger weh. Ich fasse zusammen, wo ich mir bei den bisherigen Updates in den Fuß geschossen habe.
Wie ich hier, hier und hier bereits schrieb, mache ich derzeit Updates von Debian woody auf Debian sarge. Und dabei hab ich mir an einigen Stellen nachhaltig geschadet.
- popper auf port TCP/112. Den auf mailboxen arbeitenden qpopper auf q.bofh.de habe ich vor Urzeiten auf Port TCP/112 geschoben, damit TCP/110 frei für den lange geplanten, auf maildir arbeitenden neuen Popper (früher geplant: courier, jetzt geplant: dovecot) wird. Beim Update ist die /etc/services geplättet worden, der inetd hat den Service pop-3a nicht mehr gefunden, und aus war die Maus. Die Benutzer waren natürlich zu schlau und sind gleich wieder auf Port TCP/110 zurückmigriert.
- FileCache.pm ist in perl 5.8.4 subtil kaputt (siehe Debian Bug 318580 und meine Notiz, dass dieses Drecksmodul einen Sighandler für SIGCHLD installiert und keine Möglichkeit gibt, diesen sauber wieder loszuwerden). Das lässt mein lokales Debian-Repository königlich auf die Schnauze fallen, und ich hab' jetzt ein lokales mhFileCache.pm. In neueren perls (z.B. 5.8.7 aus unstable) sind die Issues gefixt.
- Vor Urzeiten habe ich wegen des kaputten ssh in woody (PermitRootLogin ForcedCommandsOnly wegen Theos Lieblingskind "privilege separation" broken) einen Automatismus etabliert, der zuerst guckt, ob auf der Gegenseite ein kaputtes oder ein nicht kaputtes ssh lauscht und davon abhängig den Backup-Prozess als root $KOMMANDO oder als zgadmin sudo $KOMMANDO startet. Und natürlich ist passiert, dass nach dem Update die Maschinen sauber als "nicht kaputtes ssh" erkannt wurden, aber in /root/.ssh/authorizedkeys die Keys nicht standen - denn die stehen ja in /home/zgadmin/.ssh/authorizedkeys. Und ich wunder mich tagelang, warum das Backup zickt.
- In dem Kernel 2.6, den ich im Zuge des Updates auf alle Maschinen (bis auf die, die dot1q auf tg3-Interfaces machen sollen, aber das ist eine andere Herausforderung) ausrollen, ist wegen news1.tnib.de ipv6 aktiv. Nun scheint from="217.151.83.5" in authorized_keys files nicht mehr zu greifen - nein, es muss jetzt from=":ffff:217.151.83.5” heißen.
Darauf muss man mal kommen. Hoffentlich haben nicht auch noch andere Daemons diese eigenwillige Idee, sonst wird die
schleichende Einführung von ipv6 ein schleichendes Drama.
Comments
Display comments as Linear | Threaded