#hoopla

In order to perform a Typo3 update from 4.3.2 to 4.5 LTS, I updated to 4.4 and to 4.5 subsequently.

Before doing the first update step, I updated the extensions. The update process broke up with the error "Error: The extension MD5 sum could not be fetched from extensions.md5.Possible reasons: Network problems, allow_url_fopen is off, cURL is not enabled in the Install Tool". I checked allow_url_fopen in php.ini and whether PHP cURL was enabled. Both was correctly set. I found that the repository mirror link delivered a strange XML file that looked binary, although it's supposed to be XML. The existing repository URL was http://repositories.typo3.org/mirrors.xml.gz. After replacing it with http://typo3.org/mirrors.xml.gz everything worked fine.

Another issue occured when entering the install tool of Typo3 version 4.4: No CSS or images were loaded within the script. The apache log said "[alert] [client xyz] /xyz/typo3/contrib/.htaccess: ExpiresActive not allowed here, referer: http://xyz/typo3/install/index.php?TYPO3_INSTALL[type]=config" I changed the AllowOverride directive in the Apache vhost to All and it worked as expected.

On connecting the Android device with a USB cable, Nautilus showed two new drives with folders, but the containing files were not there. It didn't matter which connection method was used: neither MTP nor PTP did work.
After installing a GVFS-MTP backport as described in the link above, it works again.

After reinstalling my notebook (ThinkPad X201) from CD with a new SSD, I encountered random stops of the graphical system. I could still use open windows, but the window bars were not usable anymore. I could not close them or open new ones. I could switch to a console with Strg-Alt-Fx though. dmesg tells:
[10875.259009] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[10875.259018] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
[10877.255560] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
[10877.255775] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[10877.255779] [drm:i915_reset] *ERROR* Failed to reset chip.

I never had this error before, so I figured it is either connected to the SSD or a kernel update that I installed on the way. After deactivating an energy saving feature of the graphic chip, the problem does not occur anymore:

• Add i915.i915_enable_rc6=0 to /etc/default/grub at GRUB_CMDLINE_LINUX_DEFAULT=
• run update-grub
• reboot

UPDATE 01/31: After several days without hangs, they came back. dmesg provides the same output messages. Grub still has the RC6 energy saving feature deactivated. I noticed that the problem is only occuring when I have browsers (Chromium and Firefox) open with websites showing Flash videos. I deactivated hardware acceleration in both browsers and see what happens.

UPDATE 02/03: Again, it happened. This time, there was no Flash involved. I am using the Mono-based Tomboy program for making notes. The display driver hangs reproducible when I open one note...

UPDATE 02/07: I switched off hardware acceleration within Flash as well. I had one week without crashes - until now: The crash happened again when opening a PDF file in evince. I noticed that the window decoration (title bar etc.) vanishes after every crash. This decoration is rendered by compiz, which uses 3D rendering with hardware acceleration. Hardware acceleration cannot be turned off for compiz, but it is possible to use metacity instead of compiz. Metacity does not make use of the 3D stuff at all. It can be enabled from the command line by typing "metacity --replace", but this can have some side effects. It is better to choose "Ubuntu 2D" at the login screen: There is a dropdown selection if you click on the Ubuntu logo next to the login name. Let's see if it works now.

UPDATE 03/02: There are no crashes any more with Ubuntu 2D. The only thing that occasionally disappears is the left sidebar. It can easily be recovered by "metacity --replace".

Nehmen wir an, ein Benutzer hat ein Chroot in sshd_conf per:
Match User abc
ChrootDirectory /home/abc
ForceCommand internal-sftp
AllowTCPForwarding no
X11Forwarding no

Wenn er sich dann unter der Fehlermeldung fatal: bad ownership or modes for chroot directory "/home/abc" in /var/log/auth.log nicht anmelden kann, liegt das an den Rechten des Homeverzeichnisses: Dieses darf entgegen der Intuition nicht dem Benutzer und seiner Gruppe gehören, sondern root:root.

Gestern war es mal wieder soweit: Eine Festplatte in einem Workgroup-Server ist ausgestiegen. Kein Problem, eine Platte im Software-Raid darf kaputt gehen, der Server meldet kaputte Platten immer sofort per E-Mail und der Austausch der Platten im Array ist normalerweise problemlos mit mdadm.
Die Serverhardware hat keine Hotswap-Funktionalität, weshalb das Gerät für den Ersatz der defekten Platte neugestartet werden muss. Und da fing die Featuritis von Ubuntu an: Grub wird standardmäßig im grafischen Modus gestartet. Das führt auf jeder mir bisher bekannten Hardware dazu, dass angeschlossene Monitore den Dienst verweigern unter "out of sync". Ich hatte Grub eigentlich auf "console" zurückgestellt, aber anscheinend hat sich diese Einstellung durch ein Update verschlimmbessert.
Und mdadm weigert sich standardmäßig zu booten, wenn das Raid-Array degraded ist: Es ist eine Designentscheidung von Ubuntu, dass in dem Fall eine Rettungskonsole geöffnet wird. Dieses "Feature" könnte man beim Start innerhalb von Grub überschreiben durch den Kernel-Parameter "bootdegraded=true", wenn man denn von Grub etwas sehen würde... Und die Rettungskonsole sieht man aufgrund der grafischen Voreinstellung von Grub auch nicht.
Das ganze ist kein Beinbruch, weil man das Array auch einfach mit einer Live-CD regenerieren kann. Das blöde ist nur, dass man evtl. darauf warten muss, bis das Array wieder synchron ist: Ein Neustart des Systems, das auf dem Array liegt, ging zwischendurch schief. Grub meldete "invalid arch independent ELF magic". Erst nach der fertiggestellten Synchronisation per Live-CD bootete das System wieder wie gehabt.
Fazit: Die beiden Features "Grub im grafischen Modus" und "boote nicht von degraded Raid-Arrays" sind aus meiner Sicht unerwünscht. Auf einem Server braucht es kein grafisches Grub. Dass man von einem degraded Array booten möchte, ist in meinen Anwendungsszenarien selbstverständlich: Ich will eine Platte immer möglichst schnell ersetzen und dabei den Betrieb des Servers aufrechterhalten. Man sollte also vor etwaigen Festplattendefekten darauf achten, dass beide Sachen deaktiviert sind:

• Boot vom degraded Raid-Array
• Grub nicht grafisch, sondern in Konsole darstellen