Linux

Heute war mal wieder so ein Tag wo ich mir dachte was das eigentlich soll.
Durch einen Zufall habe ich mitbekommen, dass dstat - ein eigentlich überaus nützliches Tool, aus dem aktuellen Verzeichnis den Ordner Plugins lesen will.
Wie der Zufall es halt wollte, führte ich dstat in einem Verzeichnis aus, das ich in einer anderen SSH-Session schon gelöscht hatte und bekam eine Fehlermeldung..

Ein kurzer Blick in den Sourcecode brachte dann die Erklärung:


Weiter unten im Code stand dann endgültig fest, dass diese dstat-Version aus dem aktuellen Verzeichnis Code nachlädt und ausführt. Ein kleiner Check und der Demo-Exploit wurde einem Kollegen auf seinem System vorgeführt (so schnell bekommt man Root-Rechte auf einem Server...). Wie oft kommt es schon mal vor, dass man als root dstat in /tmp oder anderen Verzeichnissen ausführt


Dann began die Suche, ob nicht schon jemand diesen eklatanten Bug gefunden hat. In der Tat wurde schon Ende 2009 Debian über ein Advisory auf diese Lücke aufmerksam gemacht. Man liest weiter und ich jedenfalls staune nicht schlecht, dass diese Lücke nur in unstable gefixt wurde, aber weder in stable noch in oldstable.

dstat (PTS)
etch 0.6.3-2 vulnerable
lenny 0.6.7-1 vulnerable
squeeze, sid 0.7.2-1 fixed

Also: warten auf das Update und solange dstat vorsichtig benutzen.. Natürlich ist es klar, dass man kein Versionssprung einbringen will, aber der Fix gegen die verwendete Version ist nun wirklich trivial. Ich befürchte eher, dass irgendwo im Patch-Prozess der Bug aufgrund der neuen Version in unstable zu schnell geschlossen wurde und dann nicht die Schritte für ein Fix in stable angegangen wurden

Gerade habe ich mal wieder festgestellt wie schön früher die Server mit eigener, dedizierter Management-Netzwerkkarte waren. Halt echtes Out-Of-Band Management (OOB) - solange Strom da war, konnte man sich einloggen und den Server verwalten (was mit IPMI so alles machbar ist, findet man z.B. hier: "Managing Dell PowerEdge Servers using IPMItool").

Heutzutage haben die Server die ich benutze (Dell) ein IPMI-Modul, das über die die normale onBoard-Netzwerkkarte angesteuert wird. Nachdem der alte Treiber im 2.6.26er Kernel Probleme mit dem IPMI hatte, klappte nach einiger Zeit alles unter 2.6.32.

Nun wollte ich noch beide Netzwerkkarten bündeln - da ich nicht mehr vor dem Rechner stand, war natürlich die Überlegung dies über die IPMI Serial over LAN (SOL) Schnittstelle zu tun. Im Hinterkopf hatte ich: da kann ich ja die Netzwerkdevices runterfahren, weiterarbeiten und wieder als Linux-Bonding hochfahren.

Also SOL geöffnet:

ipmitool -I lanplus -a -U root -H sol activate

und angefangen zu arbeiten..

Leider war der Traum zu schön:

ifconfig eth0 down

... und der Server war nicht mehr erreichbar - inkl. IPMI SOL


Scheinbar fährt der Treiber bzw. Linux-Kernel die Netzwerkkarte so runter, dass kein IPMI mehr geht. Ein eingstelltes Failover auf die zweite NIC scheitert auch offensichtlich...


So arbeite ich dann erst morgen am Server weiter

Redundanz klingt gut. Failover noch besser.
Aber egal was man macht oder testet - es gibt immer einen Fall den man nicht bedacht hat und der die schöne Verfügbarkeit kaputt macht.

Gestern nacht ist ein Server gestorben. Na ja, zur Hälfte - eine der beiden onboard Netzwerkkarten verweigerte ihren Dienst. Zuständig war dieser Server für DHCP (ca. 30 Subnets) und Radius. Während der DHCP-Dienst durch ein Failover-Setup weiterlief, verlief es mit dem Radius-Server nicht so gut. Auf der zweiten Netzwerkkarte lauschte immer noch der Freeradius-Daemon und wurde somit von den Switches im Gebäude erreicht. Allerdings kann Freeradius ohne Default-Gateway die LDAP-Server nicht erreichen. Ohne Benutzerdatenbank keine erfolgreiche Authentifikation - aber leider dennoch erreichbar. Somit kam es, dass kein Switch auf die anderen Fallback-Radiusserver umschwenkte. Ohne Radius kein 802.1x und somit stehende Rechner am Morgen


Dennoch gibt es ein paar Faktoren, die das Problem minimiert oder bei der Analyse geholfen haben:

• Örtliche Zuordnung - jedes Gebäude hat ihren eigenen Radius-Server mit der höchsten Priorität eingetragen. Somit war das Problem lokal begrenzt und legte nicht gleich mehrere Gebäude lahm.


• Überwachung - es war somit schnell klar, dass der Server nicht erreichbar ist und wann er ausgefallen war. Allerdings zeigte sich, dass nicht jeder die Mail erhalten hat und unser Nagios zur Zeit zuviele Warn-E-Mails schickt.


• Tools - ein Webinterface zum Abschalten der Authentifikation ist in solchen Fällen sehr hilfreich.


• Redundanz - immerhin hat es der DHCP-Dienst geschafft

"Wie installiere ich alle meine Rechner neu?" Diese oder ähnliche Fragen stellt sich jeder Administrator mal. Während bei kleinen Rechnerparks noch der Turnschuhadmin von Rechner zu Rechner rennt, ist ab einer gewissen Anzahl eine automatische Installation angebracht.
Je nach Betriebssystem gibt es diverse Namen für eigentlich immer ähnliche Techniken. Sei es nun FAI (Fully Automated Installation) oder WDS (Windows Deployment Services). Natürlich gibt es auch reine Image-Software wie z.B. Norton Ghost.
Alle Installationsarten haben eine Gemeinsamkeit: der Rechner kann vom Netzwerk booten und bekommt danach über das Netzwerk die Installationsdateien. Dieser Netzwerkboot per PXE hat den angenehmen Vorteil: man muss nicht von Rechner zu Rechner wandern sondern quasi auf Knopfdruck ein Image ausrollen. Sollte beispielsweise der Rechner gerade aus sein, kann man per Wake On Lan diesen booten.


Ob nun ein echtes Image oder die Installationsdateien verwendet werden - beides hat einen entscheidenen Nachteil: das Netzwerk wird belastet. Aus schlechten Erfahrungen in der Vergangenheit werden heutzutage nicht mehr alle Rechner in ein Netzwerk gesetzt sondern per Firewall sauber getrennt. Was Würmer an der Verbreitung hindert, hat aber Nachteile: oft ist die Firewall-Appliance nicht stark genug ausgelegt um eine gleichzeitige Installation dutzender von Rechnern zu verkraften.

Im folgenden möchte ich eine kleine Lösung für dieses Problem vorstellen. Die grundsätzliche Idee ist einfach: das Aufrüsten der Firewall ist zu kostspielig. Ein einfacher Linuxserver mit zwei Netzwerkkarten ist schnell genug, aber wir wollen und können damit nicht die Appliance mit den ganzen Funktionen ersetzen.
Also stellen wir neben die Firewall eine zweite die nur während des Deployment-Prozesses tätig ist.

Die eigentliche Aufgabe besteht nun darin eine Fallunterscheidung zu treffen. Während beim normalen Boot alles wie gewohnt ablaufen soll, muss beim Booten über's Netzwerk alles über den neuen Linux-Server laufen. Das ganze klappt wunderbar wenn ein paar Rahmenbedingungen erfüllt sind - am wichtigsten ist hierbei die Verwendung eines passenden DHCP-Servers.

Zuerst einmal brauchen wir ein neues IP-Segment für die Image-Verteilung. Da öffentliche Adressen Mangelware sind, begnügen wir hier uns mit einem privatem Segment. Da wie schon gesagt, mehrere Netzbereiche versorgt werden sollen, nehmen wir hier ein 10er Bereich und unterteilen ein /16 in 255 Segmente.



Durch die Allow-Zeile wird dieser DHCP-Pool nur verwendet wenn tatsächlich über das Netzwerk gebooted wird. Das Erkennen eines Netzwerkboots erfolgt über die Angabe des Herstellers im DHCP-Request. Neben dem "pxe-kernel" welches über den nicht dokumentierten Kernelparameter dhcpclass gesetzt wurde, forderte der Kernel trotzdem auch noch als "Linux ipconfig" eine IP an.


Der ping-check erwies sich als nötig, da der Linux-Kernel eine IP-Adresse anfragt und gleichzeitig die alte noch in Benutzung ist. Der DHCP-Server pingt also die alte Adresse an und stellt fest, dass er sie nicht vergeben kann, da sie scheinbar noch in Verwendung ist. Was also normalerweise das Netzwerk vor der doppelten Vergabe einer IP schützt, ist hier kontraproduktiv.

Nun fehlt nur noch ein DHCP-Relayagent auf dem Linux-Server und die Rechner bekommen eine DHCP-Adresse. Bleibt aber ein Problem: je nachdem welcher Agent schneller antwortet bekommt der Rechner eine Adresse aus dem regulärem Pool oder aus dem neuen Deployment Pool.
Hier hilft ein explizites Verbieten - leider können wir die Gruppendefinition nicht verwenden, wenn die Rechner per statischen Host-Eintrag mit einer festen IP-Adresse versorgt werden. Hier hilft folgende Zeile im alten Segment für das Netzwerk:


Wieder haben wir die oben schon verwendete Fallunterscheidung. Diesmal wird jedoch die grundsätzliche DHCP-Funktion ein- oder ausgeschaltet. Die Benennung des Parameters booting ist ein wenig unglücklich - hier ist nicht das Booten des Rechners gemeint sondern das Zuweisen einer Adresse per DHCP.


Jetzt fehlen nur noch ein paar Kleinigkeiten. Unter anderem müssen die DHCP-Server eine Rückroute zum 10.10.0.0/16 Segment haben. Auch die beim Deployment beteiligten Rechner brauchen eine solche Route. Damit nicht jeder Server angefasst werden muss, werden alle anderen Netzwerkzugriffe per NAT auf eine bekannte Adresse gemappt. Damit die neue Firewall kein Sicherheitsloch aufreisst, sorgen noch ein paar iptables-Regeln dafür, dass nur die benötigten Dienste erreichbar sind.

Das Ergebnis kann sich sehen lassen: die Installation mehrerer Rechner geschieht jetzt völlig unabhängig von der Firewall. Jetzt bremsen nur noch die Netzwerkanbindung vom Linux-Server sowie natürlich die Anbindung vom Deployment-Server und dessen Festplatten. Aber gerade die Netzwerkanbindung kann man leicht skalieren. Eine Server-Netzwerkkarte gibt es im unteren dreistelligen Bereich. Die Edge-Switche kann man durch einfache Portaggregation schneller an die Core-Switche anbinden. Erst wenn die Backbone aufgerüstet werden muss, wird es wiederrum teuer. Aber 10 Gigabit-Ethernet ist ja im kommen.

Bei meinem Arbeitgeber haben wir ein redundantes OpenLDAP-System aufgebaut.
Klar - wenn der LDAP-Dienst nicht verfügbar ist, wäre quasi das gesamte Netzwerk lahmgelegt. Angefangen von auf der Hand liegenden Diensten wie Mailserver, Webserver, Anmelden an vielen Rechnern usw. hängen noch weitere Dienste am LDAP - zum Beispiel DHCP.

Dank der Replikation und DNS Round-Robin Einträge eigentlich kein Problem.
Nur beim letzten Ausfall zeigte sich mal wieder Murphy. Alle LDAP-Server waren online und reagierten noch auf TCP-Verbindungen - nur reagierten nicht auf das LDAP-Protokoll...

Die Ursache war recht trivial - der zentrale Syslog-Server war ausgefallen. Nachdem auf allen Servern der lokale Zwischenspeicher vollgelaufen ist, hingen alle Prozesse beim Schreiben von Lognachrichten...

Das wäre natürlich nicht passiert wenn man die Syslog-Nachrichten einfach per UDP ohne Zuverlässigkeit an den zentralen Syslog-Server schicken würde - aber wer will schon Syslog-Nachrichten verlieren?


Dennoch bin ich irritiert, dass wir mit syslog-ng soviele Probleme haben. Immer mal wieder hängt der syslog-ng Prozess auf einzelnen Servern. Wenn es dann mal den zentralen Server erwischt, wird es unangenehm...

Gerade waren wir am Umstellen der großen Xen-Kiste von Gentoo auf Debian.
Das Ganze verlief gut bis wir bemerkten, dass uns einige LVM-Partitionen fehlten.
Schnell stellte sich heraus, dass kein /dev/sdb1 existierte. Das ist gerade schlimm, weil es sich hierbei um die große 2,2 TB Partition handelte - auf der sind alle Daten der Fachschaft, Mails der Studierenden, alle studentischen SVN-Repos.

Der Blick mit parted zeigte schnell den Fehler:

Error: /dev/sdb: unrecognised disk label

Da war dann erstmal ein wenig Panik - aber schnell stelle sich heraus, dass die eigentlichen Daten noch da sind:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001c0  01 00 ee fe ff ff 01 00  00 00 ff ff ff ff 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  4c 41 42 45 4c 4f 4e 45  01 00 00 00 00 00 00 00  |LABELONE........|
00000410  b5 48 47 99 20 00 00 00  4c 56 4d 32 20 30 30 31  |.HG. ...LVM2 001|
00000420  79 39 4a 56 38 51 36 66  31 66 49 73 6f 57 43 55  |y9JV8Q6f1fIsoWCU|
00000430  4f 59 66 47 74 6f 4f 5a  4e 69 42 54 56 69 53 6e  |OYfGtoOZNiBTViSn|
00000440  00 fe fc ff ff 01 00 00  00 00 03 00 00 00 00 00  |................|
00000450  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000460  00 00 00 00 00 00 00 00  00 10 00 00 00 00 00 00  |................|
00000470  00 f0 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000480  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001200  cc 10 b7 e2 20 4c 56 4d  32 20 78 5b 35 41 25 72  |.... LVM2 x[5A%r|
00001210  30 4e 2a 3e 01 00 00 00  00 10 00 00 00 00 00 00  |0N*>............|
00001220  00 f0 02 00 00 00 00 00  00 44 00 00 00 00 00 00  |.........D......|
00001230  d5 08 00 00 00 00 00 00  b3 a6 a9 50 00 00 00 00  |...........P....|
00001240  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001400  76 67 44 61 74 61 20 7b  0a 69 64 20 3d 20 22 67  |vgData {.id = "g|
00001410  57 65 75 6d 76 2d 63 67  50 52 2d 43 55 75 33 2d  |Weumv-cgPR-CUu3-|
00001420  6c 63 6b 30 2d 67 75 51  34 2d 77 57 47 6f 2d 5a  |lck0-guQ4-wWGo-Z|
00001430  59 79 56 73 71 22 0a 73  65 71 6e 6f 20 3d 20 31  |YyVsq".seqno = 1|
00001440  0a 73 74 61 74 75 73 20  3d 20 5b 22 52 45 53 49  |.status = ["RESI|
00001450  5a 45 41 42 4c 45 22 2c  20 22 52 45 41 44 22 2c  |ZEABLE", "READ",|
00001460  20 22 57 52 49 54 45 22  5d 0a 65 78 74 65 6e 74  | "WRITE"].extent|
00001470  5f 73 69 7a 65 20 3d 20  38 31 39 32 0a 6d 61 78  |_size = 8192.max|
00001480  5f 6c 76 20 3d 20 30 0a  6d 61 78 5f 70 76 20 3d  |_lv = 0.max_pv =|

Nebem dem LVM2-Header sieht man auch direkt die Volume Group. Allerdings fehlt komplett die EFI-Tabelle (erkennbar am fehlenden "EFI PART". Dank Wikipedia zum Thema GPT wussten wir aber:

GPT also provides redundancy. The GPT header and partition table are written at both the beginning and the end of the disk.

Schnell kam aber die Ernüchterung: da ist überhaupt nicht genug Platz für eine standardkonforme Partitionstabelle. Interessanterweise konnte der alte Kernel (2.6.20-xen-r6) diese Partition trotzdem erkennen und zur Verfügung stellen. Alle anderen weigerten sich die ungültige GPT-Partitionstabelle zu erkennen.

Ursache ist wohl der fehlende EFI-Support im Kernel:

Symbol: EFI_PARTITION [=n]                                                                            
  Prompt: EFI GUID Partition support                                                                    
    Defined at fs/partitions/Kconfig:232                                                                
    Depends on: BLOCK && PARTITION_ADVANCED                                                             
    Location:                                                                                           
      -> File systems                                                                                   
        -> Partition Types                                                                              
          -> Advanced partition selection (PARTITION_ADVANCED [=n]) 

Der ist natürlich bei allen anderen, modernen Kernel-Versionen mittlerweile drin...


Jetzt läuft erstmal ein bytegenaues Backup der einzelnen LVMs und dann wird die komplette HDD neu partitioniert

Mir ist gerade aufgefallen, dass ich mein Notebook seit einem Jahr alle Kernel-Nachrichten loggen lasse (vor einem Jahr habe ich das Notebook bekommen).

Neben der Ärgernis, dass somit 1,2GB Festplatten-Platz belegt wird, hat man auch was spaßiges: man kann Auswertungen machen. Hier zum Beispiel welchen Kernel ich innerhalb eines Jahres wie oft gebootet habe:

2.6.27 [1]
2.6.27-gentoo [25]
2.6.27-gentoo-r8 [2]
2.6.28 [34]
2.6.28-11-generic [3]
2.6.28-rc1 [21]
2.6.28-rc2 [24]
2.6.28-rc3 [24]
2.6.28-rc4 [13]
2.6.28-rc4-00333-g56988df [5]
2.6.28-rc5 [9]
2.6.28-rc5-00117-g7f0f598 [2]
2.6.28-rc6 [3]
2.6.28-rc6-00286-gfd04afe-dirty [2]
2.6.28-rc6-00303-ge95a829 [6]
2.6.28-rc7 [7]
2.6.28-rc7-00452-gf134688 [4]
2.6.28-rc7-00452-gf134688-dirty [1]
2.6.28-rc8 [4]
2.6.29 [1]
2.6.29-03321-gbe0ea69 [1]
2.6.29-03652-g5d80f8e [1]
2.6.29-03652-g5d80f8e-dirty [17]
2.6.29-rc7 [33]
2.6.29-rc7-00188-gebdcc81 [25]
2.6.29-rc8-00241-g65c2449 [12]
2.6.29-rc8-00257-g59fcbdd [7]
2.6.29-rc8-00301-gd56ffd3 [2]
2.6.30 [55]
2.6.30-rc2 [15]
2.6.30-rc3 [22]
2.6.30-rc4 [23]
2.6.30-rc5 [15]
2.6.30-rc6 [23]
2.6.30-rc6-git7 [1]
2.6.30-rc7-00079-gcd86a53 [12]
2.6.30-rc7-00149-g3218911 [18]
2.6.30-rc8 [19]
2.6.31-rc5 [31]
2.6.31-rc7-00094-g9c93768 [12]
2.6.31-rc9 [16]
2.6.27.6 [2]
2.6.27.9 [2]
2.6.28.7 [23]
2.6.29.1 [24]
2.6.30.1 [39]
2.6.31.1 [21]

Weiterhin habe ich das System 664-mal aus dem Standby aufgeweckt und 66-mal aus einem Hibernate. Das bedeutet ich mache mindestens zweimal am Tag ein Standby und alle fünf Jahre ein Hibernate

In den letzten zwei Monaten habe ich am Fachbereich die Infrastruktur überarbeitet.
Insbesondere im LDAP-Bereich hat sich viel getan. Mehrere LDAP-Server wurden zu einem zusammengefasst und der Fachbereichs-LDAP ist nun mehrfach redundant. Zwar nur ein Master-Slave Setup mit mehreren Slaves, aber das genügt den Ansprüchen.
Gerade im Bereich Sicherheit gab es große Änderungen: Passwörter werden nur noch per SSHA sowie NTLM gespeichert. Natürlich wird die Übertragung per TLS abgesichert

Gleichzeitig ist der LDAP-Server die zentrale Instanz geworden. Sogar die DHCP-Config wird im LDAP verwaltet. Als Administrationsoberfläche für alle gibt es GOsa und für die echten Admins auch phpldapadmin
Auch wenn GOsa recht gut ist, muss ich sagen, dass mich so einige Bugs geärgert haben. Einige sind mittlerweile gefixt (wenn auch nur im SVN), einige müssen noch reportet werden.
Beispielsweise gibt es ein LDAP Sizelimit für Auflistungen. Während bei Benutzern, Gruppen, Computern etc GOsa beim Überschreiten eine Warnung anzeigt, wurde diese beim DHCP verschluckt. Ich wunderte mich dann warum einige Hosts und Subnetze fehlten.
Ärgerlich war auch die externe SI-Komponente: hier stolperte ein Regexp über unsere Domain. Ich finde es grundsätzlich gut wenn externer Input validiert wird - in diesem Fall ein Rechnername als FQDN. Nur leider berücksichtigte die Regexp kein Minus - dumm bei h-da.de

Nur leider ist mein alter OpenLDAP-Bug immer noch offen und es ist scheinbar nichts geschehen
Da die Fachschaft einen eigenständigen LDAP-Server betreibt, brauchen wir das Feature.

Wer mich kennt, weiß ich bin kein Freund von Macs.
Gestern und heute habe ich mich bemüht ein paar Mac Minis in das Fachbereichsnetzwerk zu integrieren. Was unter Windows (Samba) und Linux (OpenLDAP und NFSv4) kein Problem war, bereitete erstmal einigen Ärger.

Zuerst einmal klappte die Verbindung mit TLS bzw. SSL nicht. Sobald man es im grafischen Client verwendet, kann man nur noch manuell fortfahren. Die Ursache: obwohl SSL aktiv ist, wird die Option "LDAP-Port" auf 389 eingestellt. Sobald man auf den TLS-Port 635 wechselt, klappt alles (oder auch einfach die Option benutzerspezifischer Port ausschaltet).
Dann muss man noch das Schema anpassen - default sucht der Client nach objectclass=apple-user..
Das ist aber alles kein Problem - nur es klappt erstmal nicht. Ursache ist scheinbar das Zertifikat für den LDAP-Server. Obwohl die Root-CA im System-Schlüsselbund als trusted eingetragen ist, klappt der Verbindungsaufbau nicht.
Sucht man ein wenig im Netz findet man den Hinweis TLS_REQCERT einfach auf never zu schalten. Dann klappt es auch, nur der Client prüft das Zertifikat vom Server nicht mehr - nicht schön. Die Lösung die ich nun gefunden hab: root-Zertifikat im PEM-Format runterladen und per TLS_CACERT den Pfad dorthin angeben. Dann klappt auch die Zertifikatsvalidierung...
Warum klappt das nicht direkt? Und warum muss ich auf BSD-Level die Anpassung machen wenn ich doch eine grafische Oberfläche zur Administration habe? Bei Apple findet man in der Knowledge-Base nur einen Tipp in Bezug auf self-signed Certificates.. Nicht wirklich passend weil ich ja gerade eine CA-Chain habe. Eine Beschreibung wie es mit "echten" Zertifikaten geht, gibt es nicht.
Gleichzeitig fällt dann noch auf, dass das Testtool "dirt" das eingegebene Passwort im Klartext auf der Konsole ausgibt - also darf man nur im einsamen Büro die Verbindung sowie die Authentifizierung darüber testen..

Danach sollte das Dateisystem für die Benutzer eingebunden werden. Bei allen Linux-Distros (auch ältere wie Fedora Core klappte es auf Anhieb. Jetzt musste ich feststellen, dass Leopard keine Unterstützung für nfsv4 hat.
Wenn man es doch probiert mit

kommt:

mount_nfs: sorry, you must specify vers=4.0alpha to use the alpha-quality NFSv4 support

Das bedeutet konkret: kein idmapd-Support (also sind alle Besitzer aller Dateien inkorrekt). Es gibt ein Google Code Projekt, dass jetzt ausprobiert wird - aber das mach ich nicht mehr...

Muss man sich Sorgen machen wenn man mit 200 Prozessen pro Benutzer sich vor Forkbomben schützen wollte aber dann selber beim normalen Arbeiten darüber stolpert?
bash: fork: Resource temporarily unavailable

Na ja, erstmal habe ich das Limit erhöht

Nachdem mich die ganze Zeit am etwas trägen Xorg mit dem Intel-Treiber gestört habe, habe ich nun umgestellt.

Dank 2.6.29 gibt es KMS - hinter dieser Abk. verbirgt sich Kernel Mode Setting. Das bedeutet, dass das Display schon beim Booten vom Kernel eingestellt wird. Neben den kleinen Nebeneffekt, dass ich einen 1920er Framebuffer bekomme, bringt es einen weiteren Vorteil: keine Umschaltpause zwischen Console und X mehr!

Dank DRI2, UXA und einigen weiteren Neuerungen ist jetzt die Grafikausgabe endlich beschleunigt. Auch 3D-Anwendungen wie Googleearth laufen endlich.

Der einzige Nachteil: man benötigt einige Komponenten aus SVN. Dank dem x11-Overlay ist das unter Gentoo aber kein Problem. Insgesamt musste ich neben dem Kernel von Kernel.org folgende Packages freischalten:

Es war wohl nur eine Frage der Zeit bis MD5 rausfliegt.

Heute habe ich mein Notebook geupdated und in dem Zug werden jetzt Passwörter in /etc/shadow nicht mehr als md5 sondern als sha512 gespeichert. Einzige Bedingung: man muss seine Passwörter einmal ändern.

In der letzten Nacht habe ich den Umstieg auf ext4 vollzogen.
Damit das ganze sauber wird, habe ich mich für die Neuformatierung entschieden.
Also Backup, mkfs.ext4 und Wiederherstellen.

Da ich kein seperates /boot habe, war ein Grub-Update fällig.
Die neuste Grub-Version aus SVN hat coole Features wie Video-Modus mit 1600er Auflösung. Die native Displayauflösung wird leider nicht unterstützt

Das einzige Problem ist nun, dass ich nur noch Recovery-CDs mit ext4 Unterstützung nutzen kann - und die sind noch recht selten. Zumal ich AMD64 benötige..


Jetzt steht noch ein Upgrade auf KDE 4.2 vor der Tür.

Ich habe Anfang 2008 einen kleinen Server aufgesetzt. Aufgrund des beschränkten Budgets und dem Anspruch vier Netzwerkinterfaces zu haben, fiel die Wahl auf ein Asus P5BP-E/4L. Eigentlich ein sehr nettes Board. Da ich mich auf Festplatten nicht mehr verlasse, verwendete ich ein RAID aus zwei Festplatten. Es bot sich die Raid-Funktionialität des Intel ICH7R Chipsatzes an.
Die Installation war ein wenig umständlicher (initrd-Image nötig), aber irgendwann lief es dann.

Am Freitag kamen dann die Nagios-Meldungen: eine Platte ist ausgefallen und die Load schoss auf über 200 - der Server war nicht mehr erreichbar. Vor Ort erstmal per Sysrq einen halbwegs sauberen Reboot ausgelöst und über die Bios-Meldung gewundert: die RAIDs auf den zwei Platten sollten angeblich ok sein. Ein Boot funktionierte dann auch aber ein anschliendes Auslesen der HDD mit dd führte zu einem erneuten Crash. Also stand fest, dass die Platte kaputt ist und sie wurde ausgebaut. Mangels direktem Ersatz sollte der Server erstmal wieder online gehen. Das Bios meldete korrekterweise, dass das RAID1 degraded ist und das RAID 0 nicht verfügbar - kein Problem da auf dem RAID 0 nur Temp-Directories und der Squid-Cache liegt.
Allerdings kam der Boot nicht weit - direkt im initrd wurde das Mapper-Device nicht gefunden. Mit der Shell fand ich dann schnell heraus, dass dmraid Probleme hatte:

ERROR: isw: unsupported map state 0x2 on /dev/sda for System

Fazit: Intel Software-Raid ist jetzt nach Promise auf meiner persönlichen Blackliste - jedenfalls was Linux angeht. Der Controller ist jetzt auf AHCI runterstuft und demnächst kommt da ein Linux Software-RAID drauf..

Bei mir steht mal wieder ein Betriebssystemwechsel an. Über ein dreiviertel Jahr nutze nun ich ein Gentoo Linux als Hauptsystem auf meinem Notebook (dem alten und dem neuen).

Nachdem ich nun längere Zeit damit gekämpft habe, dass E6500 einigermaßen perfekt zum Laufen zu bekommen, ist jetzt ein wenig die Resignation da.
Es sind soviele Kleinigkeiten aber auch ein paar große Probleme die mich nerven. Wenigstens funktioniert mittlerweile die Grafikausgabe fast perfekt.

Bei der Geschwindigkeit gibt es aber eigentlich nichts zu Meckern. Nur die Bootzeiten könnten besser sein und der Acrobat Reader startet beim ersten Mal sehr langsam. Ob das nun an der x86-Emulation oder am Reader selber liegt weiß ich nicht.

Beim Sound fängt es damit an, dass die Kopfhörer nicht korrekt funktionieren. Wenn ein Kopfhörer beim Laden des Moduls angeschlossen ist, dann funktioniert die Ausgabe darauf, aber nicht mehr auf den Hauptlautsprechern.
Power Save vom Soundtreiber funktioniert zwar, aber bei jedem Abschalten gibt es einen Knacksen. Seitdem 2.6.28 raus gekommen ist, wird der Bug scheinbar nicht mehr behandelt. Nervig ist auch, dass die Lautstärkesteuerung über die Tasten nur in 10% Sprüngen funktioniert, die Soundkarte aber nur im Bereich 70-100% eine sinnvolle Lautstärke hat.

Seit kurzem gibt es ein Flash-Plugin für Mozilla unter x64. Damit verschwinden wenigstens die ganzen Probleme mit dem nspluginwrapper aber es gibt neue. Beispielsweise, dass der Firefox über Stunden 100% eines Cores auslastet.
Ein strace gegen firefox brachte lustige Ergebnisse. Mal hing sich das gesamte X auf und nur das Killen von strace auf einer Textkonsole (wenn dann das Umschalten geklappt hat) brachte wieder alles in Ordnung. Ein anderes Mal wurde strace durch einen Segfault einfach beendet. Nach einem Suspend oder langer Laufzeit muss ich meinen Firefox erstmal wieder neustarten damit Flash-Videos ruckelfrei bzw. überhaupt funktionieren.

Dank neuen Grafikkartentreibern, Xorg etc laufen wenigstens Videos und Flash ruckelfrei. Bei 3D-Spielen gibt es aber noch regelmäßig Probleme (ok, derzeit kein Problem da ich auf dem Notebook nicht zocke). Und da denkt man mit Intel hat man guten Treibersupport. Aber das liegt auch einfach daran, dass die alte Memory-Methode aus dem Treiber geworfen wurde bevor die Neue fertig ist. Das führt dann zu Ausgabe wie "Failed to initialize TTM buffer manager. Falling back to classic.". Außerdem hat EXA Probleme gemacht (siehe Bugreport). Von Hardwarebeschleunigung mittels xvmc will ich gar nicht erst anfangen.
Auch bei der DPI-Erkennung musste man dem X erstmal auf die Sprünge helfen.
Ab und zu passiert es, dass beim Umschalten von X auf andere Konsolen sich die Grafikausgabe nicht mehr fängt und mir ein bewegtes Bild auf das Display zaubert. Dasselbe passiert ab und zu auch beim Runterfahren.
Wenigstens klappt mit xrandr das Umschalten auf den externen Ausgang endlich problemlos (im Gegensatz zu früher mit anderen Grafikchips).

Wenigstens die Netzwerktreiber machen keine Probleme (mehr). Das Problem, dass die WLAN-Karte für ein paar Millisekunden den gesamten Kernel blockiert wurde behoben (iwlwifi causes latency), taucht aber ab und zu nochmal auf. Das Ärgerliche daran ist, dass dadurch andere Treiber in Mitleidenschaft gezogen werden. Das Touchpad verliert den Sync und wird neu initialisiert. Leider erkennt der X das Device danach nur noch als PS/2 Mouse - d.h. kein Scrollen am Rand, kein Tappen etc.

Da ich meine Projekte mit SVN koordiniere, ist mir ein solcher Support sehr wichtig. Natürlich will man nicht immer über die Kommandozeile arbeiten, so dass die grafische Einbindung mir recht wichtig ist. Mein Favorit für die beste Einbindung ist unter Windows TortoiseSVN.
In Konqueror bindet sich gut kdesvn ein. Das Plugin kann eigentlich alles was ich will, integriert sich aber in ein Untermenü. D.h. jedesmal ein recht hoher Aufwand die gewünschte Aktion zu bekommen. Wie man das Menü ändern kann, ist mir unklar...

Die Usability ist aber grundsätzlich nicht so toll - außer man greift auf die Konsole zurück. Schnell mal eine Zip-Datei erstellen oder auspacken klappt nicht. Erst Ark öffnen und dann dort auf Entpacken klicken... Das erinnert mich an Zeiten wo man unter Windows noch Winzip o.a. installieren musste...

Die mir bekannten Cron-Daemons sind meiner Meinung nach nicht mehr auf einem sinnvollen Technikstand. Gerade für Notebooks wo Faktoren wie Akkulaufzeit etc. hinzukommen, würde ich mir wünschen diverse Aufgaben eventgetriggert starten und stoppen zu können. Also beispielsweise Prelink ausführen wenn ich gerade am Stromnetz hänge und keine Last vorhanden ist. Aber dann auch wieder stoppt oder wenigstens anhält wenn das Notebook auf Akkubetrieb geht. "Moderne" Techniken wie ionice fehlen hier auch irgendwie - muss man das unbedingt immer selber ins Skript schreiben!?
Fcron kommt den Anforderungen noch am nächsten.

Weil mich der Standard Networkmanager von KDE genervt hat (Netzwerkverbindungen über WLAN waren nur nach dem Login in KDE verfügbar), habe ich mich nach Alternativen umgesehen und Wicd gefunden. Simpel, einfach zu bedienen und dank der WPA-Supplicant Templates dennoch mächtig. Nach einigen Updates (Entwicklung ist z.Z. recht aktiv) waren auch ein paar nervige Bugs raus. Insbesondere das Verhalten nach einem Standby war nervig. Das Problem ist aber, dass der wicd-Daemon deutlich an der Akkulaufzeit knabbert. Selbst wenn ich per LAN online bin und das WLAN nicht nutze, führt das reine Starten des Daemons zu über 150 Wakeups per second (erkennbar mit powertop).
Warum nach einem Standby weiterhin die Devices oben sind und alle Programme (vor allem ICQ und Jabber) noch denken sie wären online ist mir auch unklar. Zumal wenigstens PSI die Option hat einen Standby zu erkennen...
Warum die Manager es nicht zulassen, dass man gleichzeitig per WLAN und LAN eingeloggt ist, kann ich mir auch nur damit erklären, dass das der Use-Case für einen Standardanwender ist.
Weiterhin können beide kein 802.1x auf LAN-Basis.

Am Cups-Drucksystem stört mich leider auch so einiges. Zwar klappt das eigentliche Drucken wunderbar (ok, ich habe nur Netzwerkdrucker mit PCL/PS), aber die Integration externer CUPS-Server ist echt lachhaft. Wenn man sich am CUPS-Server authentifizieren muss, ist die einzige Möglichkeit Benutzer+Passwort im Klartext in die printers.conf einzutragen (siehe Anleitung bei uns im Fachschaftswiki). Wenn dann ein Drucker mal nicht erreichbar ist, dann wird der Drucker im lokalen CUPS gestoppt. Wenn man im Webinterface auf Start Printer klicken will, wird der Befehl aber an den entfernten CUPS gesendet. Das ganze natürlich wohlgemerkt per http ohne Verschlüsslung mit Benutzer+Passwort. Weiterhin kommen bei manchen Links von Firefox Meldungen wie

You are about to log in to the site "printer.fbihome.de" with the username "myusername", but the website does not require authentication. This may be an attempt to trick you. Is "myusername" the site you want to visit?

Das die Druckeinstellungen in jedem Programm anders sind und sich Änderungen nicht immer merken, nervt besonders. Warum mein CUPS auf einem Drucker ab und zu meine DIN-A4 Seiten auf DIN-A3 ausdruckt, konnte ich auch nicht herausfinden.

Toll ist auch das i8k Modul. Jedem KDE-Benutzer kann ich nur abraten es in den Kernel einzubauen wenn er ein aktuelles Notebook hat. Das Auslesen von Service-Tag etc geht mittlerweile mit anderen Tools leichter (sys-libs/libsmbios) und kmilo versucht andauernd das i8k Modul zu pollen (und protokolliert das jedes Mal in .xsession-errors, die dann schnell anwächst).

Am schlimmsten empfand ich jedoch den Versuch auf KDE 4.1 umzusteigen. Nachdem man erstmal die nicht korrekt eingetragenen Dependencies nachgetragen hat (Kopete braucht glib in qt-core) konnte ich die Bibliotheken und Programm ohne Probleme bauen. Um die Migration einfacher zu machen, habe ich ~/.kde* erstmal umbenannt, so dass KDE mit einem frischen Profil starten sollte. Nachdem Login allerdings bekam ich eine recht buggy KDE-Installation zu Gesicht. Das Systray hatte fehlerhafte Symbole (zu groß und ein Symbol für drei Programme), Konqueror war überhaupt nicht zu überreden zu starten und die Schriftgröße war viel zu groß (siehe oben für DPI-Problem). Nach einem Tag mit dem neuen KDE bin ich wieder auf meine alte Installation zurück. Dort durfte ich dann feststellen, dass die Installation der anderen KDE-Instanz ein kleines Chaos hinterlassen hat. Viele Programme sind jetzt doppelt in meinem Startmenü, die Links wie Home oder System auf dem Desktop funktionieren nicht mehr weil sie mit Dolphin geöffnet werden sollen, obwohl ich überhaupt kein Dolphin installiert habe. Weiterhin fehlten bei PSI auf einmal die Texte (auch in einer alten KDE-Session). Nur die Shortcuts (unterstrichene Buchstaben) wurden überhaupt angezeigt.

Bei der Aktion von Codeweavers habe ich mir CrossOver für die Office-Programme geholt. Aber damit kann man nicht ernsthaft mit Office 2007 arbeiten: die Geschwindigkeit ist wahrhaft grottenschlecht. Bei einer Präsentation ist mir dann PowerPoint zweimal abgestürzt.

Was ich jetzt so runtergeschrieben habe, waren erstmal nur die gröberen Sachen. Auf kosmetische Kleinigkeiten wie die fehlerhafte Anzeige des Backslashes in SSH bei der motd oder die immer noch vorhandenen Sonderzeichen-Probleme in SSH lass ich einfach mal unter den Tisch fallen.

Na ja, wenigstens ist Abwechslung (ich schreibe jetzt extra nicht Rettung) in Sicht: in einer Woche bekomme ich Windows 7 als erste Beta. Und damit beginnt mein anti-zyklischer Wechsel von Linux zu Windows und zurück. Sobald ein Betriebssystem stabil wird und die Kleinigkeiten anfangen zu nerven, wechsle ich. Je nach Stimmung komplett oder in der Form eines Dual-Boots. Wahrscheinlich würde ich auch mal ein OS X ausprobieren wenn man nicht dafür in die elitäre Gruppe der Besitzer passenden Hardware wechseln müsste. Ein Gedanke zum Ende: wenn man sich schon spezielle Hardware kaufen muss, kann man dann noch zugeben, dass die Software schlecht ist?

Die vergangene Woche habe ich mich ein wenig mit OpenLDAP beschäftigt. Das ganze unter Debian.
Angefangen hat es mit einem Sarge-System und somit stand erstmal ein Upgrade auf etch an.
Bis auf ein paar Dependencies sah das dist-upgrade gut aus, allerdings scheiterte das Upgrade beim Wiedereinspielen des OpenLDAP-Backups (dies passiert automatisch):

Nach einigem Suchen war dann klar, dass hier das Backup nicht korrekt erstellt wurde. Hier ein Beispiel:

Ursache waren die zwei Minuszeichen bei der Telefonnummer...
Weil der LDAP sowieso gerade gewartet wurde, wurde gleich noch das Standard-Passworthash-Format auf SSHA geändert (Salted SHA). Es hat ein wenig gebraucht, bis ich begriffen hab, dass das Salt nicht pro Server ist (wie es manche Anwendungen machen) sondern pro Passwort. Ab da war das Umsetzen kein Problem - jetzt müssen nur noch die Benutzer das Passwort ändern und unsichere Hashes wie md5 oder bei manchen Benutzern noch crypt sind vergangen.

Somit verlängerte sich die Downtime auf fast zwei Stunden. Damit ist schon klar, warum der nächste geplante Schritt die redundante Auslegung des LDAP-Servers war. Nach einigem Lesen von Anleitungen stand dann am zweiten Abend die Push-Replikation vom Publisher zum Consumer mit syncprov. Änderungen können an beide Server geschickt werden, allerdings verweist der Consumer dann einfach auf den Publisher. Das DNS dann auf Round Robin umzustellen war eine Kleinigkeit
Am nächsten Morgen kamen dann die Beschwerden: einige Benutzer konnten sich nicht mehr einloggen. Schnell war klar, dass die betroffenen Benutzer alle auf einem anderen LDAP-Server liegen. Eingebunden wurde dieser Server über ein Referral. Das Problem ist aber, dass der Consumer-LDAP-Server versucht das Referral zu verfolgen. Dies klappt natürlich nicht, da die Zugangsdaten für die Replikation nur auf dem Publisher-LDAP-Server gültig sind. Davon war aber nichts in den Logdateien zu finden (eingestellt auf Loglevel sync). Dennoch setzt der Consumer die Replikation fort und steht dann auch komplett zur Verfügung - es fehlt halt nur eine OU...
Bislang habe ich dafür keine Lösung außer von Hand das Referral auf dem Consumer in die Datenbank zu schreiben und dem Replikationsbenutzer alle Rechte auf den Referraleintrag beim Publisher zu entziehen.

Mit dem Referraleintrag hatte ich aber noch mehr Spaß. Nächster Schritt war die Einrichtung von Samba. Komischerweise führte das Starten von Samba oder Benutzer von "net getlocalsid" zu einer Verzögerung. Erst ein erhöhtes Debugging-Level brachte an Licht, dass Samba im Referral-OU nach seinen Einträgen suchen will. Und wieder wird der konfigurierte Benutzer verwendet sich am anderen LDAP-Server anzumelden - was natürlich immer noch nicht klappt. Auch hier war wieder die Lösung dem Samba-Benutzer die Rechte auf das Referral zu entziehen.
Da kann man sich doch nur fragen wie selten ein Setup ist, bei denen ein LDAP-Server auf einen anderen verweist ohne das die LDAP-Server vom selben Administrator eingerichtet und gewartet werden?


Wer schonmal Samba aufgesetzt hat, kennt das Passwort-Problem: Samba braucht eine eigene Passwortverwaltung. Eigentlich kein Problem - immerhin sieht das Samba-Schema im LDAP ja die passenden Felder dazu vor. Nur müsste so der Benutzer zwei Passwörter pflegen bzw. darf nicht mehr passwd auf den Linux-Servern benutzen sondern nur noch smbpasswd. Aber dafür gibt es eine Lösung: ein OpenLDAP-Modul namens smbk5pwd was automatisch bei der Passwortänderung auch die Samba-Felder updatet. Eigentlich sollte das Verwenden kein Problem sein. Das Modul besteht aus drei Dateien: Makefile, README sowie die eigentliche Sourcecode-Datei. Da das Modul gegen die entsprechende Serverversion gebaut werden muss, habe ich per apt-get source slapd mir die Sources des Debian-Pakets geholt und wollte das Modul bauen. Nachdem ich erstmal die Makefile angepasst hatte, ging es an die Compile-Fehler. Mit Hilfe einer aktuelleren Version konnte ich alles ändern und bekam schließlich das Modul. Nur leider ließ es sich nicht fehlerfrei einbinden:


Ich gebe also auf die Passwörter über das OpenLDAP-Modul auf gleichen Stand zu halten und werde eine andere Lösung suchen. Wahrscheinlich einfach auf dem Shell-Server für die Benutzer den Zugriff auf passwd auf smbpasswd verbiegen.

Ich habe heute meinen Abend (neben dem TV-Programm) damit verbracht, den Vanilla-Kernel als Xen domU laufen zu lassen. Eigentlich dachte ich das kann doch kein Problem sein: nur einen neuen Kernel bauen, Xen domU neu anlegen und fertig. Aber weit gefehlt.
Das erste Problem war, dass der Kernel nicht booten wollte: das boot device wurde nicht gefunden ("VFS: Unable to mount root fs"). Aber immerhin gibt es eine Liste der gefundenen Devices: xvda1 sowie ein paar mehr.
Also erstmal das root-Device in der domU-config geändert und die fstab angepasst. Nächstes Problem: die Devices xvda1, xvda2 und xvda3 existieren nicht (ja, ich verwende kein udev für domUs). Also per mknod angelegt und schon konnte das System wieder booten. Nur blieb die Ausgabe einfach nach dem Start der Daemons stehen - kein Loginprompt und auch keine Reaktion auf Sysrq-Befehle (Strg+O). Nach einiger Suche (und einigen Fehlinfos zum Thema xencons) war dann klar: das Konsolendevice ist hvc0. Dies muss erstmal wieder per mknod angelegt werden und dann noch in inittab und securetty eingetragen werden (danke an ganto für den Hinweis/Anleitung).

Warum ich das ganze trotzdem machen will: die Xen-Sources von Gentoo sind hoffnungslos veraltet. Weiterhin kann ich so die GRSec-Patches verwenden.

Ich weiß nicht welche Drogen die Cups-Entwickler da genommen haben, aber man kann doch nicht etwas zuerst dokumentieren und erst in einer sehr viel späteren Version implementieren!?

Als gültige Option für BrowseProtocols (sowie BrowseLocalProtocols und BrowseRemoteProtocols) ist in der Dokumentation dns-sd angegeben.

Ein Grep auf den Source-Code von Debian-Stable zeigt aber, dass das nirgendwo implementiert ist:


Im Changelog findet man dann für Version 1.3:


Da kann ich lange per querylog/tcpdump drauf warten, dass sich der Cups im DNS registriert

Ich habe gerade eine Stunde damit verbracht herauszubekommen warum ich mit Grub keinen Bootsektor auf meine neue Hardware schreiben konnte.

Als Fehlermeldung bei setup (hd0) kam immer nur


Ansonsten wurde alles richtig erkannt (also hd0,0 als ext3 etc).

Die Ursache ist eigentlich trivial, aber wohl bislang nicht so verbreitet im Netz.
Erst bei Ubuntu in der Bug-Database fand ich einen Hinweis (ID 20700):

From http://sidux.com/Article416.html :
"...
- e2fsprogs ≥ 1.40.5 creates ext3 filesystems with 256 byte large inodes by default (in contrast to 128 byte used before), to accommodate for further ext4 related changes ( http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.5 )
...

Grub ist bei Gentoo noch nicht aktuell genug - dort ist der Patch zwar schon vorhanden, aber die Version 0.97-r5 ist immer noch maskiert:

*grub-0.97-r5 (25 Mar 2008)

25 Mar 2008; Robin H. Johnson +grub-0.97-r5.ebuild:
New version of the Gentoo grub patchset. Provides support for 256-byte
ext3 inodes per bug #214563. Fixes unhide bugs with GPT patch per bug
#211584. Long commandlines per bug #183443. Xen memorysize fix per bug
#188312.

Lösung: entweder die neuste Grub-Version nehmen (unmask der Version 0.97-r5) oder einfach beim Anlegen der (Boot-)Partition den Parameter -I nutzen:
mkfs.ext3 -I 128 /dev/[bootdevice]

Wer einen schnellen Mirror für Ubuntu sucht:
ftp://ftp.fbihome.de und http://ftp.fbihome.de

Der Server taucht nicht in der offiziellen Liste auf ist aber sehr schnell angebunden.