Gestern Nachmittag, gegen 15:00-16:00 Uhr konnte aus irgendwelchen gründen google.de weder über die root noch die Provider DNS-Server aufgelöst werden. Entweder wurde die Domain mal wieder irgendwohin delegiert oder die DNS-Server des Anbieters waren nicht erreichbar. Die US DNS-Server (die übrigens auf andere Server zeigen) haben noch tadellos funktioniert. Auch ein Aufruf über die IP war noch problemlos möglich. Was mich nur immer wieder wundert, es gibt doch ziemlich viele Menschen die das Internet (eigentlich ja ein weltweites IP-Netz) af google (Anbieter verschiedener L5 Dienste) reduzieren. Komisch auch das das Problem scheinbar nur in Deutschland auftrat. Mal sehen was die Presse in den nächsten Stunden/Tagen dazu schreibt.
Category Archives: Bugs
Wenn das Design die Lesbarkeit unmöglich macht …
Eventuell ist diese Website unter Windows ja sogar noch zu lesen, aber mein Firefox unter Linux streikt genau wie mein Konqueror oder der Internet Explorer6 (wine). Er scheint die Inhalte in mehrere Ebenen gelegt zu haben und diese untereinander so verschachtelt das nichts mehr lesbar ist. In den Zeiten vorgefertigter Blogsysteme sollte man wissen was man ändert, wenn man etwas ändert.
Da das Gästebuch unbenutzbar und ich gerade mit Mühe die Trackback-URL gefunden habe, hoffe ich das dieser Beitrag in diesem Blog ankommt und etwas bewirkt.
Problem mit IP-Konfiguration nach installation des Windows-Hotfix KB941644 auf HP ProLiant DL360G4 Servern
Nach der Installation des HotFixes KB941644 kommt es zu Problemen mit dem HP NicTeaming Treiber. Wenn im HP NetworkTool ein Team konfiguriert wurde und das Interface mit einer statischen IP konfiguriert wurde, verwirft Windows nach dem Neustart die statische Konfiguration und versucht vergeblich eine IP-Konfiguration per DHCP. Die deaktivierung des DHCPclient Dienstes umgeht das Problem. Tatsächlich beheben lässt es sich nur, wenn das Hotfix wieder deinstalliert wird.
Problembeschreibung:
Das Problem wurde wie folgt nachgestellt:
Windows Server 2003R2 wurde auf einem DL360G4P neu installiert, anschließend das aktuelle ProLiant SupportPack im ExpressModus installiert. Nach dem anschließendem Neustart wurde Teaming für die beiden OnBoard NICs im 802.3ad Modus aktiviert, eine statische IP konfiguration erstellt und das System mit dem Netzwerk verbunden. Anschließend wurde die Netzwerkkonfiguration sowie die LACP aushandlung erfolgreich geprüft und Windows aktiviert. Nun wurden die aktuellen Hotfixes über WindowsUpdate eingespielt. Nach dem Neustart tritt das Problem auf. In den Reiter “Status” des “HP Network team” Interfaces ist keine IP-Konfiguration vorhanden (IP: 0.0.0.0) und das System versucht über DHCP eine Konfiguration zu erhalten. Wenn man allerdings Eingenschaften von TCP/IP aufruft um eine statische Konfiguration zu hinterlegen, ist diese noch vorhanden. Der Befehl ipconfig /all zeigt das selbe Ergebnis. Löst man das NetzworkTeam auf und konfiguriert eines der Interfaces statisch, wird die Konfiguration übernommen.
Ursache:
Nach der Installation des Hotfixes KB941644 werden komponenten der TCP/IP Protokolltreiber ausgetausch. Diese neuere Version funktioniert warscheinlich nicht richtig mit dem HP NicTeaming Treiber und verursacht das Problem.
Auswirkungen:
Der Server ist nicht mehr über seine statische IP erreichbar. Es scheint als ob das Interface auf DHCP konfiguriert wurde und keine IP erhält. Selbst wenn ein DHCP-Server im Netzsegment vorhanden ist, bekommt das Interface keine IP. Auch die LACP Aushandlung am Switch schlägt nach einspielen des Patches fehl.
Umgebung:
Windows Server 2003R2 ServicePack 2 inkl. aller Hotfixes bis 01.01.2008 sowie aller zusätzlichen Updates (IE7, XML Services usw.). Die aktuelle Version des ProLiant SupportPacks ist installiert. Eine neuere Version des Netzwerktreibers ist nicht verfügbar.
Lösung:
Nach der Deinstallation des HotFixes KB941644 ist das Problem vorerst behoben wurden. Allerdings ist die Sicherheitsanfälligkeit die mit diesem Hotfix behoben wurde wieder vorhanden. Der Workarround des Bulletins funktioniert und schließt die Lücke ohne die Konfiguration des Interfaces zu beschädigen.
Bulletin: Vulnerabilities in Windows TCP/IP Could Allow Remote Code Execution (941644)
Vorsicht beim BIOS-Update auf Acer-Laptops
Am Wochenende habe ich den Acer Aspire 7520 eines bekannten mit Vista Home Premium neu installiert um altlasten wie NIS, O2K7 und andere sauber loszuwerden und das Gerät gleich grundlegend sauber einzurichten. Vista und alle Treiber waren installiert, die üblichen Probleme behoben, die erforderliche Software installiert und eingerichtet doch das Gerät hatte immernoch leichte Probleme auf dem suspend2disk aufzuwachen. Eine kurze suche im Netz brachte auch die Lösung des Problems. Ein neueres BIOS (v1.30) sollte das Problem beheben. Nichts leicher als das, dachte ich (BIOS-Updates sind eigentlich nichts besonderes) und so habe ich die aktuelle Version inkl. Winflash von der Acer Website heruntergeladen und geflasht. Winflash meldete keinerlei fehler, alles verlief wie man es von phoenix-bios kennt. Nach einem Neustart lief das System auch noch, ein bisher aufgetretener E/A fehler war verschwunden. Also, herunterfahren und einpacken. Ca. 30 Minuten später wollte ich das Gerät noch einmal booten um einige Dateien zurückzukopieren, aber der Bildschirb blieb dunkel. Was nun? Ich habe eine Mail an Acer mit der bitte mir die weitere vorgehensweise mitzuteilen gesendet. Bisher ohne Antwort (laut website 2-3 Werktage). Mal sehen wie lange es dauert und ob es eine wie bei anderen Herstellern übliche Notfallmethode gibt, das BIOS cold zu flashen. Die suche in Foren ergab, das man ein USB-Floppy anschließen solle, akku entfernen, das Gerät vom netz trennen, die Tasten FN+ESC gedrückt halten und das Gerät einschalten solle um einen notfall-flash auszulösen. Am Montag besorge ich mir ein USB-Floppy und werde diese vorgehensweise probieren. Es macht mir aber trotzdem etwas angst das ein Original BIOS-Update von der Acer-Website solche Probleme verursacht. Mehr dazu (mit evt. wiederherstellungsanleitung) im laufe der kommenden Woche.
Bug in groupmems (sys-apps/shadow)
Normalerweise sollte man durch ein “groupmems -a USER -g GRUPPE einen Benutzer einer Gruppe hinzufügen können. Da ich sonst eigentlich immer die User in /etc/groups eingetragen habe, habe ich das nie bemerkt. Nun wollte ich es allerdings einmal über groupmems eintragen und siehe da, ein BUG.
groupmems -a USER -g GROUP
[ 3296.300794] groupmems[10192]: segfault at 0000000c eip 080497ed esp bfe6a6d0 error 4
Das passiert auch wenn die Gruppe nicht existiert. Das das einen Segfault verursacht, kann ja nicht im Sinn des Erfinders sein. Ich bin leider kein Entwickler und kann das Problem weder Lokalisieren noch beheben. Ich habe es auf 3 Systemen mit unterschiedlichen Architekturen (Via-C3, AMD64, Prescott, i586) getestet, überall das selbe. Scheint tatsächlich ein Bug zu sein.
