Leider gibt es für autokey zur Zeit kein RPM-Paket für Fedora. Daher habe ich eine kurze Installationsanleitung für autokey auf Fedora zusammengestellt. Die Installation dauert etwa fünf Minuten und ist auf Fedora 11 und Fedora 13 getestet. MIt anderen Fedora-Versionen und CentOS sollte die Anleitung identisch durchführbar sein. Mit SuSE muss die Installation der Pakete über yast vorgenommen werden.

Hinweis: Die Anleitung kann zu großen Teilen per Copy’n'Paste in eine offene Shell übernommen werden. Die einzelnen Schritte sind für Linux-Einsteiger dabei ausführlich beschrieben.

1. Download der aktuellen Version von der autokey-Projektseite und abspeichern unter /tmp/autokey-xxx.tar.gz.
2. su - und Passwort für “root” eingeben (Zum Administrator werden.)
3. yum install python-xlib python-devel (Benötigte Python-Pakete installieren.)
4. cd /tmp (Nach /tmp wechseln)
5. tar -xzf autokey-xxx.tar.gz (Download entpacken; legt den Ordner “build” an.)
6. cd build (In den neu angelegten Ordner wechseln)
7. python setup.py install (Python Installer laufen lassen)
8. cp debian/autokey-common.init /etc/init.d/autokey (Init-Skript nach /etc/init.d kopieren.)
9. chmod 755 /etc/init.d/autokey (Rechte für das Init-Skript setzen.)
10. chkconfig autokey on (Init-Skript aktivieren)
11. /etc/init.d/autokey start (Init-Skript einmalig manuell starten)
12. cd ..; rm -r autokey-xxx.tar.gz build (Installationsdateien löschen)
13. exit (Administraor-Modus verlassen. Die Shell wird ggf. noch benötigt.)
14. Als Gnome-Anwender im Menü “Applications/Accessoires/Autokey (GTK)” oder in der Shell autokey-gtk aufrufen
15. Als KDE-Anwender im Menü “Autokey (QT)” oder in der Shell autokey-qt aufrufen

Anschließend können in autokey beliebige Kürzel definiert und mit Texten bzw. Skripten versehen werden.

Grund für die Probleme mit PHP 5.3 ist in den allermeisten Fällen das unsaubere Programmieren bzw. die Verwendung seit Jahren veralteter PHP-Funktionen im Quelltext der Webapplikation bei den jeweiligen Software-Projekten. Ein typisches Beispiel hierfür ist die Verwendung der PHP-Funktion eregi(), die schon seit Jahren besser nicht genutzt werden sollte, da sie als nicht “binary safe” bekannt ist.

Als Webhosting-Kunde können Sie selbst zwischen den bei uns verfügbaren PHP-Versionen wählen – wie dies funktioniert, ist in unserem Service-Bereich beschrieben. Sofern Ihre Webapplikation es zulässt, empfehlen wir immer den Einsatz der PHP-Version 5.3, da diese deutlich performanter und damit auch von uns als Standard für Ihren Webspace aktiviert ist.

Wenn Sie selbst Systeme mit Red Hat Enterprise Linux 5 (RHEL 5) bzw. einem Derivat wie CentOS 5 betreiben und PHP 5.3, das etwas ältere PHP 5.2 oder das noch ältere PHP 4.3 benötigen, so können Sie dafür die von uns gepflegten RPM-Pakete aus unserem ETES-Repository verwenden. Bitte beachten Sie, dass diese RPM-Pakete in einem separaten Zweig liegen und daher mittels der Direktive “etes-extras” in der Yum-Konfiguration explizit aktiviert werden müssen. Und vergessen Sie nicht zu bedenken, dass Sie an dieser Stelle absofort keine anderen binären RPM-Pakete für PHP z.B. aus EPEL oder CentOS Extras verwenden sollten, da PHP 5.1, 5.2 und 5.3 jeweils zueinander ABI-inkompatibel (d.h. nicht binärkompatibel) sind!

Über die Neuerungen und Verbesserungen in PHP 5.3 gibt es beispielsweise bei Heise weitere Informationen in deutscher Sprache, englischsprachige Details erhalten Sie natürlich auch direkt bei der PHP Group.

Sofern es eine Webapplikation zwingend erfordert, steht bis maximal Anfang 2012 zudem noch das ältere PHP 4.3 mit Sicherheitsupdates und Backports zur Verfügung. Beide PHP-Versionen können parallel genutzt werden, bei Fragen dazu wenden Sie sich bitte an unseren Webhosting-Support.

Wenn Sie selbst Systeme mit Red Hat Enterprise Linux 5 (RHEL 5) bzw. einem Derivat wie CentOS 5 betreiben und PHP 5.3 bzw. das ältere PHP 4.3 benötigen, so können Sie dafür die von uns gepflegten RPM-Pakete aus unserem ETES-Repository verwenden. Bitte beachten Sie, dass diese RPM-Pakete in einem separaten Zweig liegen und daher mittels der Direktive “etes-extras” in der Yum-Konfiguration explizit aktiviert werden müssen. Und vergessen Sie nicht zu bedenken, dass Sie an dieser Stelle absofort keine anderen binären RPM-Pakete für PHP z.B. aus EPEL oder CentOS Extras verwenden sollten, da PHP 5.1 und PHP 5.3 zueinander ABI-inkompatibel (d.h. nicht binärkompatibel) sind!

Das vermeintliche Protokoll des Angriffs zeigt einen SSH-Login auf ein aktuelles Red Hat Enterprise Linux 5.3-System über den standardmäßig von SSH verwendeten Port 22.

Auf Anfrage eines Mitarbeiters von Red Hat hat sich der OpenSSH-Entwickler Damien Miller auf der OpenSSH-Mailingliste dazu geäußert, jedoch liegen ihm keine geheimen Informationen vor, noch sieht er genügend Beweise für die Existenz einer solchen Sicherheitslücke, vielmehr geht er von einer simplen Brute-Force-Attacke aus. Auch das SANS-Institut sieht ebenfalls noch keinen Beweis für den angeblichen Zero-Day-Exploit, obwohl mittlerweile Hinweise über die Existenz der unbekannten Sicherheitslücke eingegangen sind. Ein weiterer kürzlich von SANS veröffentlichter Artikel lässt jedoch vermuten, dass es sich doch um eine simple Brute-Force-Attacke statt um eine Sicherheitslücke in OpenSSH handeln dürfte.

Als Mitwirkender beim Fedora Project habe ich mit Leuten des Fedora Sicherheitsteams gesprochen, die gleichzeitig im Red Hat Security Response Team arbeiten: Bislang wurden Red Hat keinerlei Einbrüche über eine OpenSSH-Sicherheitslücke auf Kunden-Systeme mit Red Hat Enterprise Linux gemeldet. Der Support von Red Hat steht auch im Kontakt mit den Kunden, um bei Bedarf proaktiv helfen und unterstützen zu können. Zudem konnte Red Hat bei den bislang von Kunden gemeldeten Verdachtsfällen keinen Hinweis für eine OpenSSH-Sicherheitslücke entdecken.

Zusätzlich hat sich ein Team bei Red Hat mit den Unterschieden zwischen OpenSSH 4.3 und der aktuellen Version 5.2 beschäftigt und konnte bei einer Quellcode-Analyse der beiden Versionen keine neuen bzw. korrigierten Sicherheitslücken finden.

Weiter verweist das Red Hat Security Response Team darauf, dass es vermutlich lediglich einen einzigen bekannten Angriff auf eine Webhosting-Firma gab und keine Angriffe auf größere bzw. interessantere Ziele, wie Banken oder Firmen, bei denen geheime Informationen erlangt und verwendet werden könnten. Wäre soetwas der Fall gewesen, hätte Red Hat darüber bereits Kenntnis erlangt und Administratoren würden diese Probleme auf Security-Mailinglisten wie Vendor-Sec oder bei diversen CERTs melden und beschreiben.

Scheinbar plant Red Hat in der nächsten Zeit eine offizielle Stellungnahme zu abzugeben, da trotz diverser investierter Ressourcen und Zeit keinerlei Anhaltspunkte für eine OpenSSH-Sicherheitslücke entdeckt werden konnten. Sollten widererwartend doch mehr Informationen und vor allem technische Details bekannt werden, wird Red Hat entsprechend reagieren. Laut Hinweisen die das SANS-Institut erhalten hat, sollen die Details zur Lücke auf der Ende Juli in Las Vegas stattfindenden Black-Hat-Sicherheitskonferenz öffentlich gemacht werden…

Edit am 1.6.2010: Toter Link zum Protokoll gelöscht.

Compilation failed: support for \P, \p, and \X has not been compiled

fehl. Bei Red Hat Enterprise Linux 5 und damit bei CentOS 5 ist diese Option standardmäßig nicht aktiviert, da der Einsatz erst in späteren Versionen von PCRE durch die Entwickler empfohlen worden ist. Man kann dieses Problem lösen, indem man PCRE beim Kompilieren um das Parameter --enable-unicode-properties erweitert, sofern PHP dynamisch gegen die PCRE-Bibliothek gelinkt ist (was bei RHEL 5 und CentOS 5 der Fall ist).

Da PCRE gelegentlich Sicherheitslücken aufweist, sollte man die Bibliothek jedoch nicht von Hand kompilieren, da sonst mögliche Sicherheitsupdates von Red Hat dies überschreiben bzw. je nach Pfad bleiben später eventuell die Sicherheitslücken von PCRE aus der eigenen Übersetzung der Bibliothek vorhanden und machen das System leicht verwundbar. Der richtige Weg ist es daher, das RPM-Paket mit der richtigen Option selbst neu zu bauen und auch selbst zu pflegen.

Um dies zu vereinfachen, haben wir unser ETES-Repository mit einem angepassten RPM-Paket der PCRE-Bibliothek erweitert; dort wurde der Parameter --enable-unicode-properties beim Kompilieren verwendet. Diese Aktualisierung ist in unserem ETES-Repository für die für den Unternehmenseinsatz optimierte Linux-Distribution Red Hat Enterprise Linux bzw. CentOS in Version 5 verfügbar.

Aktiviert wird das ETES-Repository durch die Installation des RPM-Pakets etes-release (rpm -Uvh etes-release-version.arch.rpm), welches sich im entsprechenden Unterverzeichnis, also z.B. /centos/5/i386/ für CentOS 5 mit 32 Bit oder /centos/5/x86_64/ für CentOS 5 mit 64 Bit, der oben angegebenen Adresse findet. Da sich die Paketnamen ändern können, ist hier bewusst keine direkte URL zu den RPM-Paketen verlinkt. Ist das ETES-Repository aktiviert, funktioniert die Aktualisierung wie folgt:

• yum update pcre
• service httpd restart

Der Neustart des Apache Webservers wird benötigt, damit die PHP-Umgebung mit den zugehörigen Bibliotheken neu in den Speicher geladen wird. Anschließend kann die Suchmaschinen-Funktionalität von Contao (vormals TYPOlight) ohne Fehlermeldungen verwendet werden.

Red Hat behandelt dieses Problem aktuell im Bugreport 457064 und schätzt, dass dieses Problem möglicherweise für Red Hat Enterprise Linux 5.4 (und damit auch CentOS 5.4) beseitigt werden kann…

Um dies zu vereinfachen, haben wir unser ETES-Repository mit zusätzlichen RPM-Paketen für das ESS erweitert. Diese enthalten jedoch nicht das gesamte ESS, lediglich die Abhängigkeiten zu Software-Paketen, die die jeweilige Generation des ESS benötigt. Aktuell gibt es Pakete für ESS 6.0.0.x, 6.0.2.x, 6.0.4.x und 6.0.6.x. Unser ETES-Repository gibt es zur Zeit für die für den Unternehmenseinsatz optimierte Linux-Distribution Red Hat Enterprise Linux bzw. CentOS in Version 4 und 5, sowie für den Vorreiter in Sachen Open Source Software, nämlich Fedora in Version 8, 9 und 10.

Aktiviert wird das ETES-Repository durch die Installation des RPM-Pakets etes-release (rpm -Uvh etes-release-version.arch.rpm), welches sich im entsprechenden Unterverzeichnis der oben angegebenen Adresse findet. Da sich die Paketnamen ändern können, ist hier bewusst keine direkte URL zu den RPM-Paketen verlinkt. Anschließend funktioniert die Installation wie folgt:

• ESS 6.0.6.x: yum install ess-606x
• ESS 6.0.4.x: yum install ess-604x
• ESS 6.0.2.x: yum install ess-602x
• ESS 6.0.0.x: yum install ess-600x

Kurze Zeit später fragt yum nach, ob die benötigten RPM-Pakete wirklich installiert werden sollen. Dies muss natürlich bestätigt werden und eine danach gestartete Installation des ESS funktioniert ohne die händische Nachinstallation weiterer Software-Pakete!

Selbstverständlich gibt es eine Alternative zum derzeit fast überall eingesetzten Master Boot Record (MBR), diese Alternative heißt GUID Partition Table (GPT). Nun ist das Problem, dass die Unterstützung für GPT sowohl im BIOS als auch beim Bootmanager (z.B. Grub) vorhanden sein muss. Auf x86-basierenden Systemen (üblicherweise als x86, IA32, x86_64, AMD64, EM64T bekannt) ist eine Unterstützung von GPT bislang allgemein recht selten und aktuell unterstützt keine für den Unternehmenseinsatz optimierte Linux-Distribution die GPT von Haus aus.

Natürlich könnte man einen Grub 2 (der sowieso noch Zukunftsmusik ist) selbst compilieren oder den bestehenden Grub 0.x mit einem Patch aufbohren, aber das muss hinterher selbst gepflegt sowie gewartet werden und bei Problemen ist man auf sich selbst gestellt.

Die Lösung ist nun bei einem RAID-Controller den RAID-Verbund anderst aufzubauen: Hat man z.B. nur Festplatten mit jeweils 1 TB, so plant man üblicherweise ein RAID 5 mit 5 Festplatten und einer Hotspare-Platte. Eine mögliche, funktionierende Lösung wäre ein RAID 1 aus 2 Festplatten, sowie ein RAID 5 aus 5 Festplatten und eine globale Hotspare-Festplatte. In diesem Fall müsste man einfach noch zwei weitere Festplatten dazukaufen, um die gleiche Nutzkapazität zu erreichen. Auf das RAID 1 wird das Betriebssystem mit einem MBR installiert, auf das RAID 5 wird eine GPT eingerichtet und anschließend hat man 4 TB für Nutzdaten. Und die globale Hotspare springt entweder für das RAID 1 oder das RAID 5 ein – je nach dem, wo sie bei Bedarf benötigt wird.

Bei Verwendung eines Red Hat Enterprise Linux 5 (RHEL) bzw. CentOS 5 kann eine ganz normale Installation auf dem RAID 1 durchgeführt werden. Anschließend wird das RAID 5 mit GPT eingerichtet wie folgt:

[root@tux ~]# parted /dev/sdb
GNU Parted 1.8.1
Using /dev/sdb
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt
(parted)
(parted) p

Model: DELL PERC 6/i (scsi)
Disk /dev/sdb: 3999GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End  Size  File system  Name  Flags

(parted)
(parted) mkpart
Partition name?  []? BACKUP
File system type?  [ext2]? ext3
Start? 0
End? -1
(parted)
(parted) p

Model: DELL PERC 6/i (scsi)
Disk /dev/sdb: 3999GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name    Flags
 1      17.4kB  3999GB  3999GB               BACKUP

(parted)
(parted) quit
Information: Don't forget to update /etc/fstab, if necessary.

[root@tux ~]#

Anschließend kann mit mkfs.ext3 ein Dateisystem angelegt werden. Wichtig ist noch, dass fdisk aktuell nur mit MBR-Partitionstabellen und nicht mit GPT umgehen kann. Somit muss in jedem Fall zu parted (GNU Parted) gegriffen werden. Übrigens, MBR-Partitionstabellen und Partitionen größer als 2 TB lassen sich problemlos anlegen, konfigurieren und selbst ein Dateisystem lässt sich darauf anlegen. Aber sobald Daten ins Spiel kommen, geht das ganze schief. Einige Leute beschreiben zudem, dass die Beschränkung sich lediglich auf Partitionen größer als 2 TB beziehen würde und Partitionstabellen größer als 2 TB möglich wären – dies habe ich so nicht nachvollziehen können: Egal ob Partition oder Partitionstabelle, sobald die 2 TB-Grenze erreicht war, gab es bei mir Probleme.

Bei RAID beziehe ich mich überall auf ein Hardware-RAID, da ein Software-RAID zum einen immer eine schlechtere Performance als ein Hardware-RAID liefert und zum anderen, da sich dieses Problem auch nicht mit einem Software-RAID lösen lässt.

Die Verwendung eines Logical Volume Managers (LVM) wäre sicherlich auch noch eine Möglichkeit, hätte es nicht im Linux-Kernel unter Verwendung von LVM2, wie er mit allen gängigen Enterprise-Distributionen mitgeliefert wird, bis vor kurze Zeit einen schwerwiegenden Fehler gegeben, der im Extremfall bei 100% Schreibgeschwindigkeit für lediglich 50% Lesegeschwindigkeit gesorgt hat. Das Problem wurde erst mit einer Testversion des Linux-Kernels in Version 2.6.27 behoben und wird aufgrund von Inkompatibilitäten vermutlich auch in keine bestehende Version einer Enterprise-Distribution zurückportiert werden. Red Hat behandelt dieses Problem aktuell im von mir geöffneten Bugreport 147679 und geht davon aus, es mit Red Hat Enterprise Linux 6 (und damit auch CentOS 6) zu beseitigen…