Fixing fsck: buffer overflow detected

Wer einen Raspberry Pi einsetzt, der nicht ordentlich heruntergefahren wird (z.B. weil er über eine Zeitschaltuhr gesteuert wird), wird sicher schon mal an den Punkt gekommen sein, dass das Dateisystem korrupt ist. Linux schlägt hier logischerweise das Tool fsck vor.

In meinem Fall brach das Tool nach der Eingabe der Menüauswahl immer mit der Meldung ab:
*** buffer overflow detected ***: fsck.vfat terminated
Es scheint also Probleme mit dem Input zu geben. Die Lösung ist, fsck über folgenden Alias aufzurufen:
dosfsck -r /DEVICE
Danke an den Debian Bugtracker für diesen Workaround - warum auch immer er funktioniert... ;-)

Wer fummelt am System rum?

Ein kurzer Reminder an alle Admin-Einsteiger öfter mal folgende Befehle durchzuführen:
who
last
netstat -tanp
Auch wenn die Befehle jedem bekannt sein sollten, der einen Server mit Internetverbindung betreibt:
  • who zeigt aktuell eingeloggte User an. Wenn sich Benutzer am System angemeldet haben, die unbekannt sind oder nicht eingeloggt sein sollten, sollten sofort alle Alarmglocken klingeln.
  • last zeigt die zuletzt eingeloggten User an, bei Verbindungen über das Netzwerk auch die Quell-IP, mit der die Verbindung erfolgt ist. Auch hier gilt: Ungewöhnliche Aktivitäten sollten sofort weitere Maßnahmen auslösen.
  • netstat zeigt aktuelle Netzwerkverbindungen an. Wenn eine IP-Adresse hundertfach in der Liste auftaucht (am besten mit "grep" filtern) kann das auf einen Portscan schließen lassen.

Typo3 Migration von 4.x auf 6.2 mit Kodierungsproblemen

Wenn eine Typo3-Installation in Version 4.x von Server A nach Server B migriert werden soll kann es zu Problemen mit der Codierung kommen (latin1 vs. utf-8).

(Ein Update mit einem einfachen Weg zur Umcodierung am Ende der Seite!)

Symptome

  • Inhalte / Strings mit Umlauten wird nicht dargestellt, weder im Backend noch im Frontend (z.B. "Menüs", "Caches löschen")
  • Bilder im Frontend werden nicht angezeigt, wenn die page Umlaute beinhaltet (genauer: Die Bilder in typo3temp werden nicht generiert)
 

Ursache

Das Problem ist, dass die Inhalte in der Datenbank in latin1 / iso-8859-1 codiert sind und Typo3 utf-8 nutzt. Dies ist vermutlich aber erst ab einer gewissen PHP-Version >5.2 so, also betrifft vor allem Systeme, bei denen ein PHP-Upgrade durch die Migration verursacht wird.
Damit die Zeichen richtig ausgegeben werden müssen drei Faktoren stimmen:
  • Codierung mit der Typo3 arbeitet
  • Codierung der Datenbankverbindung
  • Codierung der Datenbankinhalte
 

Problemlösung

Die einfachste und zukunftssicherste Problemlösung ist alle Inhalte auf UTF-8 zu konvertieren, da Typo3 in neueren Versionen standardmäßig mit UTF-8 arbeitet.
  1. Exportieren der Datenbank per mysqldump mit der Option --default-character-set=utf8
  2. Manuelles Ersetzen aller Vorkommnisse von "latin1_" durch "utf8_" (z.B. mit vim: :%s/latin1_/utf8_/)
  3. Manuelles Ersetzen aller Vorkommnisse von "DEFAULT CHARSET=latin1" durch "DEFAULT CHARSET=utf8" (z.B. mit vim: :%s/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/)
  4. Einspielen des Dumpy mit der Option --default-character-set=utf8
  5. Ändern der localconf.php, folgende Einstellungen ändern:
    $TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;'; $TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
Danach sollte Typo3 wieder problemlos laufen und alle Strings richtig ausgeben.
 

Update!

Ein Arbeitskollege von mir, genauer gesagt der Certified Extension-Entwickler und Typo3-Association-Mitglied Torsten Schrade, hat einen weniger fummeligen Weg gefunden, das Ganze über die Bühne zu bringen:
  1. phpmyadmin aufrufen und eine leere DB mit Kollation latin1_general_ci erstellen
  2. Die Datenbank Einspielen als latin1:
    mysql -uXXX -pXXX - -default-character-set=latin1 DATENBANK < DUMP.sql
  3. Ausspielen als latin1/compatible (= ohne Kollationsinformationen):
    mysqldump -uroot -pvagrant - -default-character-set=latin1 - -compatible=mysql40 DATENBANK > DUMP.latin1.sql
  4. Konvertieren mit iconv:
    iconv -f ISO-8859-1 -t UTF-8 DUMP.latin1.sql > DUMP.utf8.sql
  5. DUMP.utf8.sql in bspw. in Textwrangler, vim o.ä. öffnen und darauf achten, dass die Datei in UTF8 angezeigt wird. Konkret also prüfen, ob die Umlaute korrekt dargestellt werden. Stimmen die Umlaute war die Konversion erfolgreich.
  6. Wenn alles stimmt: Bei der Tabellendeklaration im Dump TYPE=MyISAM in ENGINE=MyISAM (und ggf. das gleiche mit InnoDB) ändern und abspeichern, z.B. über "Suchen/Ersetzen".
  7. phpmyadmin aufrufen, alte Datenbank löschen und neu anlegen, diesmal aber mit Kollation utf8_general_ci
  8. Die konvertierte Datenbank einspielen:
    mysql -uroot -pvagrant --default-character-set=utf8 DB < DUMP.utf8.sql
  9. Fertig.
Im Endeffekt erspart einem das die Suchen/Ersetzen der ganzen Kollationsinformationen, da diese erst gar nicht mit exportiert werden.

Danke an Torsten für diesen Input ;-)

Debian will "rtl_nic/rt18168e-3.fw"

Der wohl einfachste "Fehler" überhaupt: Bei einer Debian-Installation mit einer Realtek-Karte möchte der Installer manchmal die non-free Firmware "rtl_nic/rt18168e-3.fw" installieren. Meistens handelt es sich dabei um die WLAN-Karte des Rechners.

Die Meldung kann man aber profihaft ignorieren, einfach "Nein wählen" und weiter installieren. Das Netzwerk funktioniert trotzdem. Später kann man dann die non-free Quelle in die sources.list eintragen und die Firmware (wenn noch benötigt) nachinstallieren.

Befehl hierfür wäre dann apt-get install firmware-realtek. Dadurch spart man sich das Chaos den Installer neu zusammenzustellen.

proFTPd hängt bei Usernamen, dann timeout -- und nur ohne TLS?

Ich bin neulich fast durchgedreht. Meine Debian-Server nutzen proFTPd mit TLS-Verschlüsselung. Für einen einzelnen Benutzer wollte ich nun TLSRequired auf "off" setzen, damit dieser auch ohne TLS eine Verbindung herstellen kann.

Die Verbindung mit TLS funktioniert problemlos.

Die Verbindung ohne TLS scheitert aber mit einem Timeout. Der FTP-Client sendet den Benutzernamen (z.B. "user testmensch") und ab dann passiert nichts mehr. Der Server reagiert nicht mehr und schlussendlich meldet der FTP Client einen Timeout.

Auch im proftpd.log und tls.log gab es keine besonderen Einträge, im Fall von "proftpd.log" sogar gar keine Einträge, außer dem Verbindungsaufbau.

Die Lösung ist unglaublich einfach. Ich bin überfolgenden Beitrag gestolpert. Und der hat mich auf die richtige Spur gebracht:

Unabhängig davon ob IPv6 in der Config aktiviert ist muss der eigene Host in die Hosts-Datei unter "/etc/hosts" eingegeben werden. Ansonsten befördert sich proFTPd in eine endlose Anfrage.

Der Eintrag in der hosts-Datei muss also etwa so aussehen:
::1     ip6-localhost ip6-loopback   localhost
Dann proFTP.d mit "/etc/init.d/proftpd restart" neu starten und die Verbindung funktioniert auch ohne TLS ;-)