Heute wurde mir wieder einmal mehr klar, warum ich OpenSuSE zwar auf dem Desktop, nicht aber auf dem Server einsetze. Aktueller Fall: proftpd läuft bei einem Kunden nicht im Standalone-Betrieb. Der Service forked nicht. Warum? Weil die OpenSuSE-Leute den Dienst tatsächlich mit --enable-devel=coredump,nodaemon,nofork übersetzt haben! Skuriler gehts nimmer.

Seit zwei Jahren ärgere ich mich ständig nach einem Kernelupdate mit VMware rum, weil VMware kein Kernelmodul gegen den neuen Kernel baut. Es ist mittlerweile schon lästige Routine geworden nach dem aktuellen, inoffiziellen „Any-Any-Patch“ zu suchen, den Petr Vandrovec, ein VMware-Mitarbeiter, erstellt hat, und den VMware-Installer damit zu patchen. Weiterlesen

Das Update von 10.3 auf OpenSuSE 11.0 war schmerzfrei und ging flott von der Hand. Neben Softwareaktualisierungen viele Verbesserungen im Detail. Bin recht angetan. Aaaber: warum hat es mir schon wieder den Bootsektor zerschossen? Warum musste ich selbst wieder Hand an grub legen?

Update: Man soll den Tag nicht vor dem Abend loben: postfix/master[17716]: fatal: 127.0.0.1:smtps: Servname not supported for ai_socktype Hab den Service erstmal auskommentiert (was eigentich nicht im Sinne des Erfinders ist… Ich benutzte ihn tatsächlich). Hat jemand eine Ahnung woran das liegen könnte?

Update (zehn Minuten später): Problem hat sich geklärt. SuSE hat die /etc/services aktualisiert. Unter 465/tcp steht jetzt urd statt smtps. Den Port beim Service in der master.cf mitzukonfigurieren oder den Eintrag in /etc/services zu ändern hilft.

Das Update war wie gewohnt relativ zeitaufwändig aufwändig, aber weitestgehend schmerzfrei. Ärgerlich: die Updateroutinen schafften es nicht grub ordentlich zu aktualisieren. Ergebnis: das System bootete nach dem Update der Pakete nicht mehr. Der Bootsektor mußte von mir über ein Rettungssystem umständlich von Hand angelegt werden. DAU-freundlich ist das nicht.

Nils und ich haben uns heute eine ganze Weile mit Debians Eigentümlichkeiten rumgeschlagen. Ausgangspunkt war die Frage, wie man Anpassungen bei dem Rotationsintervall von Standard-Logdateien, wie z.B. mail.log vornehmen könnte. Man sollte annehmen, dass ein paar simple Modifikationen an der logrotate Konfiguration reichen würden, aber weit gefehlt. Weiterlesen

Meine Glückssträhne hielt an. Das Update verlief zwar nicht gänzlich unkompliziert, aber das lag mehr daran, dass ich einige Bibliotheken der 10.1 gegen selbstgebaute ausgetauscht hatte und auch ansonsten einiges an Feinjustierungen und Erweiterungen vorgenommen habe. Ein ärgerliches Problem gab auch diesmal wieder: das Update zerschoß erneut die LDAP-Datenbank. Ich konnte mir mit einem aktuellen Backup (LDIF!) behelfen.