Sie sind hier: Zentrale | Servereinrichtung | Arbeitsplatz und Server unter Windows XP
Unterthemen:
 Harry Boeck - Heimserver

Arbeitsplatz und Server unter Windows XP

Erlebnisbericht

Auch wenn mittlerweile der Nachfolger "Vista" längst raus ist - XP bietet alles, was das Herz eines Windows-Benutzers begehren könnte - von der Raserei bis zum Infarkt.

Die Umstellung auf XP war EIGENTLICH als Maßnamhe zur zügigen und effektiven Erhöhung der Sicherheit gegenüber seinem Vorgänger Windows 98 gedacht. Tatsächlich wurde sie zu einem Trip ins Chaos.
Andererseits führte das Verfahren natürlich auch zu einigen Erkenntnissen, die es zwar in Bezug auf die investierte Zeit nicht wert waren, wenn sie in meinem Privatbesitz bleiben, aber andererseits in verschiedenen Situationen ganz nützlich sein können - angefangen von umwerfenden Erfahrung in Bezug auf Firewalls und dabei insbesondere in Bezug auf die "gute alte" Kerio Personal Firewall über die fast absolute Dichtmachung des Systems gegen Viren und Würmer unter Beibehaltung bequemer Arbeitsmöglichkeiten und eines funktionsfähigen Aktualisierungssystems bis zu Scherzen von fehlerhaften DirectX-Paketen, die einhergingen mit der Verweigerung von Installationen.

Für alles gibt es bislang Antworten, nicht immer unbedingt erbaulich und befriedigend, aber immerhin soweit, daß das ursprüngliche Ziel erreicht werden kann. Einige sind allerdings immer noch offen.

Anlaß zum Umstieg

Auslöser der Aktion war der Month-of-the-PHP-Bugs und dabei eine Klasse von sperrangelweit offen stehenden Einbruchstoren, die ich spielend am eigenen System nachvollziehen, jedoch absolut NICHTS ohne größere Installationsorgie dagegen unternehmen konnte. Und das gemeine daran war:
  1. Die Patches "Suhosin" bzw. "Hardened PHP" beziehen sich auf selbstcompilierte PHP-Engines - was bei mir momentan (noch) nicht geht. Vor allem hatte ich nicht mehr vor, das extrem veraltete MSVC 4 nochmal in Betrieb zu nehmen. Schon gar nicht unter dem jetzt ebenfalls effektiv veraltendem Windows 98 (ich finde immer häufiger benötigte Software, die nur noch unter Windows XP oder Linux läuft).

  2. Andere von außen einsetzbare Filter gegen diese Einbruchstore müßten zwingend auf Apache-Ebene oder gar auf der noch weiter außen liegenden Firewall-Ebene eingesetzt werden.

  3. Filter für die Firewall gehen zumindest momentan bei mir nicht einzusetzen.

  4. Die betreffenden Filter für den Apache setzen eine aktuellere Version des Apache voraus, als die letzte, die ich für Windows 98 finden konnte.

Serverausfall

Also habe ich mich entschlossen, einen ohnehin demnächst anstehenden Systemwechsel jetzt sofort durchzuführen. Eigentlich sollte erst noch der Server auf dem alten Zweitrechner in Betrieb gehen, aber die PHP-Einfallstore führten dann doch zu einigem Druck, so daß ich den durchgehenden Serverbetrieb in seiner Priorität herabstufte auf unterhalb eines hinreichend sicheren Systems.

Der Server ging damit am 04.03.2007 11:00 (Sonntag) vom Netz.
Nach Möglichkeit sollte er noch am selben Abend wieder dran sein, aber das war weit an den tatsächlich noch zu lösenden Problemen vorbeigeschätzt.
Ich hatte zwar von meiner Arbeit her jede Menge Erfahrungen und vorbereitete Konfigurationen, aber während ich dort von der Prämisse ausgehe, daß Dinge, für die ich (gegebenenfalls trotz Empfehlen und Drängen) keinen Auftrag bekomme, nicht in meiner Verantwortung liegen und ich deshalb ruhigen Gewissens gewisse Dinge auf die leichte Schulter nehmen kann, war ja der erklärte Grund für den Umstieg im Privatbereich ausdrücklich die Wiederherstellung der regelrecht eingestürzten Sicherheit gegen Einbrüche.

Folgende Themen waren vor jeder weiteren Arbeit zwingend abzuhandeln:
Folgende Themen waren vor jeder Verbindung mit dem Netz vollständig abzuarbeiten:
Anschließend war vor Einrichtung von öffentlichen Diensten erstmal die elementare innere Sicherheit des Systems herzustellen:
Letztendlich konnte ich endlich dazu übergehen, die Internet-Projekte vom alten System zu übernehmen, die Konfigurationen auf die aktuellen Server zu aktualisieren, die Konten für die Dienste einzurichten, Zugriffsrechte einzustellen und das ganze zum Laufen zu bringen:
Zwischendurch wiederholte sich ein Drama, das ich nun schon dermaßen auswendig kenne, daß es mir bis dorthinaus zum Halse heraushängt:
Windows XP erwies sich bei mir als instabiler als es Windows 3.x zu seinen seeligen Zeiten jemals fertiggebracht hätte.
Es stellt sich allmählich die Frage: Will ich mir DAS weiter antun?...

Grundinstallation des Systems

Hier gab es erste Anlaufschwierigkeiten ähnlich denen, die ich jedesmal bei einem neuen Versuch mit Linux erlebe: Von den ersten Klicks geht mindestens irgendeiner schon bei der Definition der Datenträgerformatierung daneben, ohne daß es einem zunächst auffällt, weil man sich auf ganz andere Dinge konzentriert. Allein die Partitionierung habe ich dreimal ausgeführt.

Beim ersten mal hatte ich versehentlich nicht die Schnellformatierung eingeschaltet gelassen. Das war ein fataler Fehler bei hunderten Gigabyte Datenträgerplatz.
Beim nächsten Anlauf hatte ich Reserveplatz für ein Backup-System vergessen und außerdem die Systempartition viel zu groß angelegt, so daß ich die ganze anderthalbstündige Prozedur des Dateien kopierens nach diesen Stunden (und außerdem erst nachdem mir klar wurde, DASS ich da etwas vergessen hatte) nochmal machen konnte.

Erst beim dritten Anlauf landete alles so, daß ich zufrienden sein konnte: Es hat eine große neue Partition für alle von mir bzw. meinen Familienmitgliedern definierten Inhalten gegeben, auf die auch gleich sämtliche Daten des alten Systems kopiert wurden, und eine nach heutigen Maßstäben winzig kleine Systempartition von 2 Gigabyte, auf die alles kommt, was nach Meinung von Bill Gates zwingend notwendig ist, um die Verwaltung einer Handvoll Prozesse und Hardwareteile in den Griff zu kriegen...

Alles in allem dauerte diese Prozedur etwa 8 Stunden, während derer ich zugegebenerweise im wesentlichen Romane vom Dunkelelfen Drizzt Do'Urden aus den Forgotten Realms (Wikipedia) lesen oder mich um den Haushalt kümmern konnte.

Einrichtung einer Arbeitsumgebung

Wie überlegen Programme, die OHNE Installationsprozedur funktionieren und sich an möglichst stabile Schnittstellen halten, gegenüber dem von Microsoft so vehement beschworenen Installations-Boliden mit jeweils mindestens hunderten tief vernetzten und zwingend notwendigen Einträgen in der Registry sind, merkt man besonders bei einem Umzug auf einen ganz neuen Rechner, bei dem so einiges anders eingerichtet werden soll.

Es gibt davon aber dennoch eine ganze Menge. Einige wenige sogar aus dem Hause Microsoft selbst.

Zwingend notwendig sind ein ANSTÄNDIGER Dateimanager und ein ebensolcher Texteditor. Dazu ein paar Systemverwaltungswerkzeuge wie die von sysinternals.

Ohne diese Werkzeuge wäre das Abarbeiten der nachfolgenden Punkte eine Qual bzw. dermaßen uneffektiv, daß es praktisch unmöglich wäre. Einige Dinge wie das entschlüsseln von Passwort-Archiven oder Mails von der Arbeitsstelle wären zunächst ganz unmöglich.

Daneben wird für zügiges Arbeiten einschließlich halbwegs anständiger Trefferchancen bei der Benutzung der Maus zwingend die Abschaltung all des hirnrissigen GUI-Schnickschnacks benötigt!

Die Einrichtung setzt entweder manuelles Durchackern der Einrichtungsdialoge oder manuelles (aber Editor- und Ersetzen-gestütztes) Durchackern von Windows-Registry-Dateien. Ich habe letzteres vorgezogen, wei ich seit jeher solche von jedem Programm anlege, wo es mir sinnvoller erscheint als die Installation neu durchzugehen.

Aufwand insgesamt: etwa 4 Stunden.
(Dateiverwaltung, Editoren, Systemverwaltung, Archivierer, Browser, Acrobat Reader, TweakUI, GPG)

Minimierung der Systemdienste

Dies wurde zunächst nach ausreichend vorliegenden Erfahrungen ausgeführt. Einige wenige Punkte kenne ich allerdings immer noch nicht auswendig. Günstige Anlaufstellen dafür im Internet sind zum Beispiel:

http://www.ntsvcfg.de/
http://www.microsoft.com/germany/technet/sicherheit/topics/serversecurity/tcg/tcgch07n.mspx

Gesamtaufwand samt Recherche hier etwa 1 Stunde

Einrichtung einer Firewall

Zur Anwendung kommt momentan die Kerio Personal Firewall in der letzten Version, die für den privaten Betrieb kostenlos war (2.1.5).

Die Firewall mußte nicht nur eingerichtet werden. Es mußte auch sichergestellt werden, daß sie gegen mögliche Untertunnelungen durch Windows-Systemkomponenten ausreichend gefeit ist, indem sie zumindest rechtzeitig (vor allen eventuell aufs Netz zugreifenden Komponenten) geladen wird und bei Dichtmachung keinerlei Netzverkehr mehr nachweisbar ist.

Da ich auf diesem Gebiet noch keine hinreichend tiefgreifenden Erfahrungen sammeln konnte, war dies ausgiebig zu testen. Gegebenenfalls hätte ich mir nochmal eine andere Firewall suchen müssen.

Danach war die detaillierte Einrichtung der Regeln dran, wobei ich leider nicht auf die bereits vorhandenen Regelsätze aus anderen Systemen zurückgreifen konnte, wo ich dies bereits mehrfach hinter mich gebracht hatte. Entweder entsprach die Version der Firewall nicht der aktuell verwendeten oder die Regeln unterschieden sich so stark, daß eine Übernahme keinen Sinn machte. Gegenüber dem Windows 98 habe ich nämlich die Struktur des Dateisystems gründlich überarbeitet.

Grundsatz für die Regeleinrichtung ist:
Für die Regeleinrichtung ist zwingend die Inanspruchnahme des Internet Voraussetzung (anders können Notwendigkeiten nicht vom Absaugen von Privatsphäre unterschieden werden). An dieser Stelle war die Existenz des Zweitrechners mit bereits eingerichtetem Windows XP essentiell, so daß ich dadurch nicht mit dem frischen System ins Internet brauchte.
Als Anlaufstelle für die Verifizierung von Verbindungswünschen habe ich die whois-abfrage beim Heise benuzt.

Die Einrichtung geht über zwei Phasen hinweg und ist dabei mit der Einrichtung der Netzwerktreiber verzahnt:

Zu Anfang - solange der Rechner noch nicht wieder an ein Netz gestöpselt ist, gibt es kaum unerwünschte Verbindungsversuche. Was in diese Phase insbesondere an lokalen Verbindungen (also innerhalb des Operationssystems) zum Zwecke von Interprozeß-Kommunikation aufgebaut wird, ist in aller Regel vertrauenswürdig. Abgeschlossen wird dies mit der Verleihung einer festen Netzwerkadresse (Voraussetzung, um Firewall-Regeln auch innerhalb des LAN definieren zu können) samt Netzmaske, jedoch noch ohne Gateway(!), so daß unliebsame Komponenten in der nächsten Phase noch keinen Unfug anstellen können.

Mit dem Anstöpseln ans LAN beginnen die Berichterstattungen und die Anpreisungen der nach der Säuberung der Diensteliste übriggebliebenen Dienste im LAN, von denen Microsoft meint, daß sie zwingend notwendig wären, um den ahnungslosen User glücklich zu machen. Die lassen sich in dieser Phase, in der noch kein Gateway definiert ist, geruhsam und sicher zupflastern.

Zum Schluß kommt die Definition eines Gateways ins Internet hinzu und die Installation bzw. Einrichtung der wichtigsten benötigten Internet-Werkzeuge wie Browser und Mailer.

Insgesamt benötigte die Einrichtung der Firewall und der Test ihrer Zuverlässigkeit allein etwa so um 8 Stunden herum.

Registrierung und Einspielung von Updates

Nach Einrichtung der Firewall konnte das Registrieren und Updaten bei Microsoft beginnen. Die Grundinstallation wächst so Pi mal Daumen auf das anderthalbfache an. Während vorher etwas über 1 Gigabyte von hunderten Programmodulen belegt waren, die ich zu 90% nicht haben will und nie (willentlich) benutzen werde, wurden daraus nach der ersten Update-Welle über 1,5 Gigabyte, wobei das System erstmals in die Knie ging, weil ich die Systempartition auf 2 Giabyte begrenzt habe (damit Backups erträglich über die Bühne gehen können).

Damit war es notwendig, zunächst eine Bereinigung des Systems um nicht benötigte Dateien einzuschieben.

Die Einspielung der Updates ließ ich über Nacht laufen einschließlch der automatischen Neustarts, soweit die zwingend notwendig waren und ohne Anmeldung drchgeführt werden konnten.

Vermutlich hat die ganze Prozedur allerdings nicht mehr als 2...3 Stunden in Anspruch genommen.

Bereinigung des Systems

Dies ist noch lange nicht abgeschlossen. Es wurde aber wegen geringerer Priorität nur soweit wie unbedingt notwendig durchgeführt und ansonsten zurückgestellt.

Der Papierkorb ist das bei Updates am schnellsten wachsende Element des Dateisystems. Wenn man extrem unterschiedlich ausgestattete Partitionen hat, solte man den Papierkorb individuell an die Datenträger anpassen.

Die "Softwareverwaltung" von Microsoft bringt nicht wirklich irgendeinen spürbaren Platzgewinn - zumindest nicht in ihrer Standardnutzung. Wo man dort das Häkchen wegnimmt, werden die Dateien dennoch installiert samt aller unerwünschter Nebeneffekte (zum Beispiel in Bezug auf Dateiverknüpfungen). Ich bin mir sicher, im Internet vielfach über Stellen gestolpert zu sein, wo beschrieben steht, wie man diesem Verwaltungsinstrument beibringt, den Schrott tatsächlich rauszuschmeißen und jede Menge davon anzuzeigen, der standardmäßig ausgeblendet ist.
Erstmal ist das jedoch zurückgestellt, weil es einfach zu aufwendig ist.

Was sich lohnt, ist das Entfernen nicht benötigter Dateikopien... Gute Anlaufstellen für die Systembereinigung findet man im Internet zu Hauf. Eine ganz extrem gute (vollständig und systematisch) aus einer Uni, die wohl eigentlich nicht für die Öffentlichkeit gedacht war, war wenige Stunden, nachdem ich sie gezogen hatte, wieder aus der Öffentlichkeit verschwunden. Aber es gibt ausreichend viele alternative Stellen.

Die Bereinigung des Systems nahm soweit samt Dokumentesuche und -Studium etwa um 4 Stunden in Anspruch.

Parallelinstallation für Systembackup

Vor diesem Schritt war allerdings noch eine Prüfung des aktuellen Systems auf alle Funktionen hin angesagt, die mir in Zukunft wichtig sein werden. Dazu gehörte die Übernahme des Startmenüs aus Windows 98 und das Anschmeißen und funktionelle Prüfen aller Systemkomponenten, die soweit in das bewährte Nutzungs-Schema passen. Das lief hier zur Zufriedenheit ab.

LAN-Stecker ziehen nicht vergessen!

Leider bemeckert die Parallelinstallation gleich nach ihrer Einrichtung, daß sie registriert werden will. Dabei ist es beruhigend zu lesen, daß die Parallelinstallation auf demselben Rechner zum Zwecke von Backups ausdrücklich von der Microsoft-Lizenz gedeckt wird. Es fehlt allerdings die Möglichkeit, einem solchen Backup-System zu erzählen, daß es sich gefälligst die Lizenzdaten aus der unmittelbar nebenan - nur wenige Bytes entfernt - liegenden Installation saugen soll!
Na ja, jedenfalls läuft die Sache erstmal. Solange bei einem derartigen Backup das Netzwerk getrennt bleibt, brauche ich keinerlei Arbeit in Systemupdates oder sonstige Sicherheitsmaßnahmen investieren. WinRar unterstützt die Speicherung und Wiederherstellung von Zugriffsrechten, was mir SEHR entgegenkommt. Damit kann ich mit minimalem Aufwand ein Komplett-Backup der gesamten Systempartition einrichten. Lieber wäre mir zwar eine Binärkopie auf Ebene des Datenträgers (statt auf Ebene des Dateisystems), aber das muß noch warten, bis ich Linux eingerichtet habe oder mir was passendes über den Weg gelaufen ist...

Die Parallelinstallation samt Backup dauerte etwa 4 Stunden

Minimierung der Benutzerrechte

Vor allen weiteren Aktivitäten, wozu eine sophistische Einstellung von Zugriffsrechten auf Ebene der Datei- und Prozeßverwaltung, vor allem aber jede Menge Experimente auch mit Netzwerk-Werkzeugen gehören sollte, war sicherzustellen, daß ein Grundzustand halbwegs vertrauenswürdiger Rechtevergaben existierte.

Anschließend ist das Einrichten von Benutzerkonten für die Familienmitglieder dran.

Schließlich werden sämtliche Einstellungen auf Korrektheit und Benutzbarkeit getestet, in die Konten der Familienmitglieder eingestiegen und die wichtigsten Programme angeschmissen und getestet. Wo notwendig wird mittels "Progmon" von sysinternals die Ursache für die Nichtfunktion aufgespührt und mittels feiner individueller Korrekturen beseitigt.

Alles in allem dauerte diese Einrichtung samt Suchen/Studium im Internet, Testen der Korrektheit der Einstellungen und Korrekturen von Programm-Einstellungen und Zugriffsrechten etwa 2 Tage (um 16 Stunden).

Übernahme der Webserver-Konfigurationen

Auf meiner Arbeit bin ich inzwischen bezüglich sophistischer Konfigurationen sehr viel weiter gewesen als zu Hause. Das ergab sich allein aus den zeitlichen Verhältnissen. Nichts lag also näher als die Erfahrungen aus dem Beruf nachzunutzen. Dazu gehörten nicht nur eine Reihe von Konfigurationsdateien, sondern ebenso Shell-Scripte und Einrichtungsprotokolle.

Allerdings ist das alles zumindest teilweise Eigentum meines Arbeitgebers (soweit ich dies auf Arbeit entwickelt hatte) und also nicht für die Öffentlichkeit zugelassen. Das Senden per GPG war kein Problem, aber auf dem aktuellen System war GPG nicht so einfach so zu konfigurieren, daß es einen Schlüsselbund für alle Familienmitglieder und einen optionalen für jeden einzelnen verwaltete. Zwischendurch zerschoß mir das Ding sogar einmal mein Schlüsselbund, nachdem ich gerade erst aufgrund einer Versionsaktualisierung von GPG möglich gewordene Änderungen von Chiffrierverfahren eingetragen hatte. (Die Schlüsselbunde wurden einfach gelöscht und durch leere ersetzt). Glücklicherweise hatte ich die alten ja noch in vielen Backups und konnte die Änderungen schnell wieder vom Keyserver ziehen. Aber gekostet hat allein dieses Experimentieren mit GPG, dessen Konfigurationsdialogen und den Rechteeinstellungen im Dateisystem so etwa einen halben Tag (4 Stunden).

Anschließend mußten die Scripte ud Konfigurationsdateien von meiner Arbeit mit dem zusammengeschnitten werden, was vorher auf meinem alten Heimserver gelaufen ist, und zwar so, daß sie auf das neue System passen. Dabei waren größere Umstellungen im Apache zu berücksichtigen, die mit dem Versionssprung von 2.0.x auf 2.1.x kamen. Außerdem eine Einrichtung des Dateisystems, die nun vollkommen von beiden Quellsystemen abweicht (was kaum anders zu erwarten war).
Es half nichts: Ich mußte mich einmal durchwühlen.
Gesamtaufwand mitsamt Recherchen hier etwa um 12 Stunden.

Einrichtung der Konten und Rechte

Nach Möglichkeit jeder Dienst, der nach außen mit dem WWW in Kontakt tritt, hat einen eigenen Kontext mit eigenem Konto, drastisch beschnittenen Zugriffsrechten und minimalen Rechten gegenüber dem Rest des Systems zu bekommen.

Die Einrichtung der Konten und Zugriffsrechte wurde wie auf Arbeit komplett automatisiert (in Scripte verpackt).
Nachteil dieses Verfahrens ist der gegenüber einer Konfiguration übers GUI beim ersten Mal wesentlich höhere Aufwand zur Einrichtung der Scripte.
Unschlagbarer Vorteil dagegen ist, daß bei einer Fehleinstellung diese systematisch nachgewiesen und nachhaltig eliminiert werden kann, ohne darauf angewiesen zu sein, das Thema für alle Zeiten im Gedächtnis zu behalten.
Und bei einer Wiederholung oder wenn es nur um geringfügige Anpassungen wie das Kopieren bereits vorhandener Einstellungen auf einen ähnlichen Dienst geht, sind die Scripte nicht zu ersetzen.

Alle als Server fungierenden Benutzerkonten wurden in eine extra Benutzer-Gruppe aufgenommen, die auf weiten Teilen des Dateisystems kompettes Zugriffsverbot hat.

Der Apache zum Beispiel hat jetzt ein Konto, mit dem er außer lesend auf seine eigenen (und öffentlichen) ausführbaren Dateien und einige wenige Dateien im Windows-Ordner nur noch auf das public-Verzeichnis alias document_root zugreifen kann.
DAMIT kann ich erstmal für den Moment relativ beruhigt selbst einen angreifbaren PHP-Interpreter laufen lassen, ohne die Kompromittierung aller persönlichen Daten einschließlich meines Bankkontos befürchten zu müssen.

noch in Arbeit.

Gesamtaufwand bisher: etwa 4 Stunden.

Einrichtung der Dienste SSH und VNC

Diese beiden Dienste und auch bzw. gerade die Firewall wollte ich eigentlich so einrichten, daß sie unter eigenen extrem beschnittenen Benutzerkonten laufen. Leider ist es unter Windows XP zwingend notwendig, Dienste, die ein Icon in der Taskleiste pllazieren sollen bzw. wollen, unter dem Systemkonto laufen zu lassen. Mitunter kann man solche Dienste trotzdem in Benutzung nehmen, hat aber keine direkte Steuermöglichkeit.

Bei der Firewall fällt das extrem negativ ins Gewicht: Solange die noch hin und wieder konfiguriert werden muß, ist es zwingend notwendig, daß sie im Userspace sichtbare Meldungen über Verbindungsanfragen einblenden kann. Zwar tut sie das tatsächlich über ganz eigenständige Module, die auch noch ganz sinnig über Netzwerk-Pipes miteinander kommunizieren. Aber nichtsdestotrotz werden diese Dialoge nicht sichtbar, wenn die Kerio Firewall nicht im Systemkonto läuft. Es ginge auch viel besser, wenn ein winziger Programmstumpf im Userspace im Hintergrund laufen würde, der auf Meldungen der Firewall-Engine wartet. Aber das haben die Entwickler von Kerio halt nicht so gewollt.

Genauso unangenehm ist das bei den anderen beiden Diensten SSH und VNC. Auch die haben EIGENTLICH extra Progrämmchen bzw. können mit dem Prozeß, der im Hintergrund als Dienst arbeitet, kommunizieren, haben dies aber nicht für die Meldung von Ereignissen an einen winzigen Programmstumpf, sondern nur für das Polling von Ereignissen bei einem Vollfenster-Start implementiert.

Schade.

Bei allen drei Diensten muß ich entweder auf die Möglichkeit verzichten, den aktuellen Status gemeldet zu bekommen und gegebenenfalls unkompliziert Einfluß nehmen zu können (und bei allen dreien ist mir das schon sehr wichtig), oder den Dienst halt unter Systemkonto und damit das System sehr viel höher gefährdend laufen zu lassen.

Ich habe mich momentan für letzteres entschieden, aber die Rechte von System beschnitten (und denke dies noch sehr viel weiter zu tn). Letztlich will ich (falls ich beim Systemkonto und der Anzeige der Tray-Icons bleibe) dahin kommen, daß "System" im Alltagsbetrieb nur noch auf seine Logdateien, die Registry und ein paar wenige Ordner für die Systemupdate-Steuerung schreibenden Zugriff hat und selbst der Lesezugriff weitgehend eingeschränkt ist. Erweitert wird dieses Recht dann nur noch für kurze Perioden bei der Einspielung von Systemupdates, nachdem diese angemeldet wurden, und das unter explziter Gewährung dieser Rechte durch den Administrator.

Gesamtaufwand der Experimente und Recherchen: etwa 4 Stunden

Blue Screens

Am 22.03.2007, kurz nachdem ich den Server endlich wieder in Betrieb hatte und mich eigentlich an die Beseitigung der letzten Fehler (wie zum Beispiel mit Umlauten) macen wollte, wurde zunächst ein ungefragtes Update für den Firefox eingespielt, obwohl ich vorher solches für alle Nutzer verboten hatte, und dann fängt das System an, alle paar zig Minuten einen Blue Screen zu schmeißen, sofern das Internet benutzt wird.

Der zunächst vermutete Zusammenhang mit dem Firefox-Update trifft aber offenbar nicht zu: Nach Zurückstellen auf den Vorzustand bleiben die Blue Screens erhalten.

Firefox wird am laufenden Band von der Firewall als in der Checksumme geändert bemeckert. Mir kommt das Ding (und das automatisch ausgeführte Update, obwohl manuelles solches eingestellt war) nach wie vor suspekt vor, auch wenn die Blue Screens nicht direkt mit der Versionsänderung zusammenhängen.

Ist hier ein Trojaner eingedrungen?
Oder hat hier jemand Links durcheinandergebracht?
-> Ich notiere die Prüfsummen von Firefox explizit und programmiere ein Batchprogrämmchen zum Anlegen von eigenen Signaturen über Verzeichnisbäume (GPG unterstützt ja leider von Haus aus nur einzelne Dateien)...

Die Blue Screens erzählen grundsätzlich etwas von "fwdrv.sys" - der Kerio Personal Firewall. Das GLAUBE ich einfach nicht: Diese Firewall läuft jetzt seit Jahren und ja nicht nur auf meinem Rechner, sondern in der ganzen Verwandschaft und Bekanntschaft, soweit ich dort Rechner einrichte. Und von Windows 98 über Windows 2000 bis Windows XP. Sie hat noch NIE solches Verhalten gezeigt.

Meine Vermutungen zunächst zu den möglichen Schuldigen:
Glücklicherweise sind die System-Logdateien groß genug bemessen, daß ich von den "Anwendungen" und vom "System" eine vollständige Liste seit Beginn der Installationsorgie habe. Bei der Durchsicht ergibt sich:
Die Rechtebeschneidungen erweisen sich als nicht korrelierend.
An Installationen kommen ausschließlich in Frage:
Letztlich lasse ich mich von den Fehlermeldungsinhalten verführen und suche nach Anhaltspunkten für Fehler in der Firewall oder im Firewalltreiber.
Eine der Theorien: Falls der Firewalltreiber eventuell (versehentlich?) so programmiert ist, daß seine Speicherseiten verworfen werden dürfen (wer weiß - vielleicht kann man das ja) und diese dann während der Ausführung eines Interrupts des Apache angefordert werden und dazu vom Festplatten-Image gelesen werden müssen - was sicherlich vom "System" auszuführen wäre - das "System" zu diesem Zeitpunkt aber keinen ausreichenden Zugriff auf die Treiberdatei hätte (man kennt das ja von hunderten anderen Gelegenheiten, wo man die Rechte nachstellen muß, damit irgendwelche falsch programmierten Module zum Laufen gebracht werden können) - DANN zum Beispiel wäre solch ein Absturz ohne weiteres einleuchtend.

Alle Rechnerchen führen aber zu keiner sinnvollen Alternative, und der daneben stehende Alt-Rechner, auf dem ein Test-Windows-XP nun schon fast zwei Monate ununterbrochen läuft - mit exakt derselben Firewall und exakt denselben Spielereien mit Rechtebeschränkungen und Dienstestutzungen, bringt mich letztlich zur Überzeugung, daß ich hier einem Phantom aufsitzen muß.

Auch das etappenweise Herausnehmen von Apache, SSH, VNC und aller Windows- Automatismen einschließlich Updates bringt keinerlei Änderung am Fakt der regelmäßigen Blue Screens!

Fazit soweit: Das GIBT ES NICHT, was es hier gibt!

Um wenigstens halbwegs mit dem als Server laufenden Rechner überleben zu können, stelle ich ab dem 26.03. von Blue Screens auf automatisces Reboot um. So bleibt wenigstens der Webserver erreichbar...

kippende Bits

Einen Tag später (27.03.) haut's mir schon wieder den Firefox als angeblich geändert um die Ohren! Vergleich der Prüfsummen ergibt: Er wurde tatsächlich geändert. Binärvergleich mit der korrekten Vergleichsdatei ergibt:
Ein einzelnes gekipptes Bit!

Ab sofort ist Alarmzustand ausgerufen.
Was einzelne gekippte Bits mit einem Rechner im Laufe der Zeit anstellen können, habe ich mittlerweile schon so oft mit unterschiedlichen Systemen erlebt, daß ich wirklich keine Lust habe, das NOCHMAL genießen zu dürfen!

Vermutungen: Erinnerungen an die vielen Horror-Erfahrungen aus früheren Tagen werden wach...

Ich schreibe eine Batchdatei zum gründlichen Testen des Systems auf Stabilität von Datetransfers. Eine Testdatei wird angelegt mit der Größe vom RAM und Zufallsdaten über openssl.
Ich starte Testreihen, um Zusammenhänge der Fehlerhäufigkeit mit IRGENDWAS festzustellen. Es stellt sich heraus, daß alle meine Vermutungen soweit keinerlei Korrelation der Fehlerhäufigkeit bringen:
Ich vermute Zusammenhänge mit der Leitungsführung der Stromversorgungsleitungen im PC und ähnliche Mysterien.

Da wird das Chaos mit einem Mal noch viel bunter als je zuvor...

Lüfter-Crash und Motherboard-Streik

Am 27.03. zerlegt sich das Lüfterrad des CPU-Lüfters nach eine Kontakt mit einer zurechtgebogenen Stromleitung.

Ersatz-Lüfter gebastelt.
Mit Windkanal. Von Groß auf Mini.
Leider ohne Drehzahlfühler.

Motherboard läuft ein paar Sekunden, piept dann und schaltet sich ab.

Ich vermute, daß es an dem fehlenden Drehzahlfühler liegt.
Dämliche, kindische Impulsleitung! Konnten die nicht wenigstens das Booten ins BIOS-Setup frei von dem Keks lassen? Da läuft die CPU doch eh gedrosselt!
OK: Batterie raus, CMOS zurückgesetzt.

Motherboard piept und schaltet sich ab.

Lüfter neu gekauft: Langsam drehend, damit der Lärm etwas erträglicher wird. Und das Vieh vielleicht etwas länger hält, bevor er zu dröhnen anfängt... Zusammen mit neuem Kühlkörper. DER sieht nicht danach aus, daß er viel mehr aushalten könnte. Ganz im Gegenteil. Werde also die Temperatur prüfen müssen...

Motherboard piept und schaltet sich ab.

Pip-Codes im Internet erschnüffelt:
Es gibt Pip-Codes von allen BIOS-Herstellern und zusätzlich unter Umständen Dreingaben von Motherboard-Herstellern. Ausgerechnet von Asus finde ich kein Bit mehr unter den mir bekannten Links. Aber ich habe ja - wenn ich das richtig in Erinnerung habe - ein Award-BIOS. Einmal Pipen soll Probleme mit dem RAM darstellen.

Hmmmm, der war doch aber so ganz und gar nicht an diese Aktion beteiligt, oder? Andererseits: Da sich der Pip-Code ändert, wenn ich den RAM rausnehme, vermute ich mal, daß der ja SO kaputt gar nicht sein kann: Immerhin wird er als existent erkannt und beeinflußt die Reaktion des Systems.
Trotzdem: RAM raus, alte Bausteine von der Halde rein.

Motherboard piept und schaltet sich ab.

Alle Baugruppen abgeklemmt, nur noch Motherboard, CPU und RAM:

Motherboard piept und schaltet sich ab.

RAM raus:

Motherboard piept unendlich, und schaltet sich nicht ab.

Hmmmm.... RAM unterschiedlichster Sorten rein:

Motherboard piept und schaltet sich ab.

Lüfter/Kühlkörper/CPU raus, kontrolliert, gereinigt; RAM raus, kontrolliert, gereinigt; ganzes Motherboard gründlich beleuchtet, gereinigt...

Alles wieder zusammengebaut:

Motherboard piept und schaltet sich ab.

Nochmal im Internet geschnüffelt (welch ein Heidenglück, daß ich den Ersatz-PC noch einsatzfähig habe...):

Asus hatte sich nur geschickt verkrochen (komisch: andere reißen sich Beine aus, um im Zentrum der Aufmerksamkeit zu stehen; Asus scheint das Gegenteil zu wollen...). Und sie haben sogar mal eine FAQ-Ecke, die exakt das bei mir vorliegende Problem enthält:

Langsam laufender oder gar geregelter Lüfter == Tod für Asus-Motherboards.

Es gibt aber einen Ausweg: Man muß einen ANDEREN ALTEN Schrott-Lüfter auftreiben, den man zumindest für einmal Booten als Fake an die Lüfterklemme hängen kann, um dem startenden BIOS einen schnellaufenden Schrott-Lüfter auf der CPU vorzugaukeln, damit man DANN im BIOS die Lüfter-Kontrolle abschalten kann...

Nun ja: Einen alten Lüfter, aber mit Drehzahlfühler, habe ich gerade noch so im Ersatz-PC.

-> Ausgebaut, im Arbeits-PC rein, Startversuch: Motherboard startet und piept wegen Grafikkarte.
Ahmen!

Alles wieder zusammenbauen mit Mini-Spurti-Lüfter noch dran, um nicht gleich wieder vor verschlossener Tür zu stehen (wie einfach wäre es eigentlich gewesen, einen Jumper zum niederhalten dieses Quarks einzubauen?)...

Übrigens stellt sich heraus, daß bei mir längst die Lüfter-Kontrolle abgeschaltet gewesen war: Ich hatte schon früher (vor Jahren...) mit dem ekelhaft schnarrenden und vorübergehend bis in die Gegend von 1000 U/min langsamen Schnelläufer Startprobleme gehabt und ihn damals aus der Kontrolle genommen. Später hatte sich das zwar durch regelmäßiges Ölen erledigt, aber im BIOS hatte ich ihn dennoch ignoriert gelassen.

Trotzdem hatte sich das BIOS jetzt geweigert, zu booten. Es weigert sich momentan außerdem, wegen einer zu hohen -5V-Spannung mit dem Booten fortzufahren. Die muß ich also auch noch rausnehmen.

-> Motherboard bootet, Windows bootet...

kippende Bits - Fortsetzung

...Was ja nun mitnichten bedeutet, daß das System wieder benutzbar wäre...


Obwohl RAM-Tests (MemTest von Linux-CD) wiederholt kein einziges fehlerhaftes Bit zeigen, stürzt Windows insgesamt munter ab: mit Auto-Reboot und mittlerweile korrekt geschriebenen Mini-Dumps im Log-Verzeichnis; durchschnittlich etwa alle 8 Stunden einmal, aber abhängig von der Benutzung gehäuft - was sich mit der momentanen Vermutung deckt, daß irgendwas auf dem Motherboard oder in der CPU oder im RAM in Abhängigkeit von der Benutzung Bits kippen läßt.

Ein weit hergeholt ähnliches Verhalten hatte ich bei der Inbetriebnahme des Systems im Jahr 2000 schon mal: Da war das Analogsignal-Kabel vom CDROM-Laufwerk zur Soundkarte dran schuld, weshalb ich seither Musik nur noch digital spielen lasse (und nur noch durch WinAmp). Damals waren die Auswirkungen ziemlich identisch: mit zufällig gekippten Bits auf den Festplattenleitungen.

Noch eine Ähnlichkeit (noch weiter hergeholt) gibt es mit einem Verhalten in einem älteren System um 1997/98 herum, als der Übergang in den Gigabyte-Bereich bei den Festplatten erfolgte: Damals gab es eine Unverträglichkeit zwischen den Festplatten bis 256 MByte und denen ab 512 MByte aufwärts vom Hersteller Maxtor. Das führte zu zufällig gekippten Bits nicht nur in Daten, sondern auch in Befehlssequenzen, wodurch eine der Platten immer wieder mal in einen Modus überging, in dem 512-Byte-Sektoren um 256 Byte versetzt geschrieben wurden, was mir mehrere Totalzersetzungen des Systems einbrachte.

Der momentane Zustand ist unhaltbar: Anwendungen wie auch das Gesamtsystem stürzen immer häufiger ab. Es ist abzusehen, daß das System unbenutzbar wird. Der Firefox hat seine komplette Konfiguration unter zwei Benutzerkonten zerschossen und dies durch Löschung aller Einstellungen "korrigiert".

Ich gehe dazu über, die BIOS-Einstellungen im Chipsatzbereich zu korrigieren:
Fakt ist, daß ich sie seinerzeit (am 04.03.2007) bei der Ersteinrichtung von diesem Windows XP ohne Änderung vom Windows 98 übernommen hatte. Und daß das Windows 98 ein ganzes Jahr fast ununterbrochen gelaufen ist (mit nur gewollten Restarts, weil die Energieverwaltung zwischendurch immer wieder mal gemeine Dinge z.B. mit den CDROM-Laufwerken angestellt hatte).

Zwischendurch mit dem Lüfter-Crash hatte ich aber das BIOS-EPROM zurückgesetzt, so daß "sichere" Standard-Einstellungen eingestellt waren. DIE allerdings sind in keinster Weise URSÄCHLICH für irgendwelche Bit-Kippungen.

Da ich nun aber auf den Bereich von Motherboard, CPU und RAM und bezüglich letzterem auf "nur unter Windows XP" zurückgedrängt wurde, bleibt nichts anderes übrig, als mit den BIOS-Einstellungen zu spielen...

Setzen des SDRAM-Timings von "per SPD" auf "manuell" mit den langsamsten Einstellungen führt dazu, daß Windows nur noch zum Anmeldebildschirm kommt. Jede Anmeldung führt nach wenigen Sekunden zum Soft-Reboot. Einmal hängt das System im Anmeldebildschirm.

Zurücksetzen auf "per SPD" führt zum normalen Betriebsverhalten zurück.

-> Die Vermutung zwingt sich auf, daß Windows XP das Timing des SDRAMS nach eigenem Gutdünken verändert. Und daß es im Falle der "per SPD"-Einstellung nur mehr oder weniger zufällig gerade so funktioniert.

Ich versuche, das System herunterzutakten. Und zwar zunächst gezielt nur den allgemeinen Bus zwischen CPU und Motherboard. Ich stelle 100 MHz Bustakt (die langsamst mögliche Einstellung) und CPU-Takt-Multiplier von 14 (damit die CPU erstmal als Einfluß außen vor bleibt) ein.

Das System bootet nicht mehr. Nicht mal mehr ins BIOS-Setup.

Das legt ein Reset des BIOS-EPROMS nahe. Dann allerdings würde das System nur noch wieder mit dem Ausbau eines anderen Lüfters zu starten sein. Was momentan nicht möglich ist, weil der besetzt ist. Es gibt aber noch die Möglichkeit, die beiden Parameter mit Jumpern auf dem Motherboard einzustellen. Danach startet es wieder. Anschließend tut mir das BIOS den Gefallen, die Jumper-Einstellungen zu übernehmen.

Testlauf mit 100 MHz Bus- / 1GHz CPU-Takt: Fehler sind immer noch da.
Sicherheitshalber Wiederholung: 2 Fehler in 12 Durchgängen.

Testlauf mit 100 MHz Bus- / 1GHz CPU-Takt / manuelle RAM-Waitstates auf Maximum:
Fehler sind immer noch da (3 Fehler/8 Durchgänge).

02.04. - Ich habe mich nochmal aufgerappelt, eine weitere Versuchsreihe zu starten. Und dabei so weit wie irgend möglich alle Unterschiede zur vorherigen Einstellung unter Windows 98 zu beseitigen.

Das einzige, was mir noch aufgefallen war, war die Taktung des RAMS, die wohl (so vermutete ich zumindest zu Anfang) von den Ereignissen um den Lüftercrash herum auf "per SPD" (also BIOS-default-Einstellung) umgestellt worden war.

Fakt ist, daß ich in den vorangegangenen Testläufen das System mit bis zu der langsamsten Einstellung (und damit nach Adam Ries und in Gottes Namen SICHERSTEN - sicher zumindest gegen Bitfehler durch zu schnelle Signalwechsel, solange halbwegs überschaubare physikalische Zusammenhänge gelten sollten) laufen ließ, mit der es noch zu starten in der Lage war.

Damit war Null komme Nichts an irgendeiner Veränderung in irgendeiner Abhängigkeit feststellbar. Die Fehler blieben absolut konstant: Exakt 1 Bitfehler in einer 512 MByte (== RAM-Größe) großen Datei in etwa 1/4 aller Fälle.

Ein wenig ins Grübeln war ich geraten, als Windows sich beim Login-Bildschirm wiederholt und systematisch aufgehängt hatte, nachdem ich nur die RAM-Taktung von "per SPD" mit "3-3-3" Wartezyklen auf "manuell" mit "3-3-3" Wartezyklen umgestellt hatte. Was ja bei jedem hirngefüllten Wesen in diesem Teil der Welt zur Schlußfolgerung führen sollte, daß sich da überhaupt nichts hätte ändern dürfen!

Heute nun die Überraschung:

Testlauf mit Einstellung "manuell" bei "3-2-2" Wartezyklen, was vor Jahren mal unter Windows 98 in einer längeren Testreihe als oberer (!) Grenzwert ermittelt worden war: Kein Fehler nach jetzt etwa 40 Testläufen!

Das ist jetzt also gleichzeitig der untere und obere Grenzwert, ja? Wenn ich dieses Motherboard also exakt an der Grenze zu Bitfehlern wegen zu hoher Geschwindigkeit betreibe, erhalte ich gerade so keine Fehler!
Tolle Technik! Das muß man erstmal rauskriegen! Und Windows XP scheint hier sein Möglichstes zu geben, das Chaos zu maximieren, indem es die Taktung gegen den Willen des Eigentümers nach Gutdünken des Herrn Bill Gates manipuliert!

Fazit: ERSTMAL und ENDLICH WIEDER ein halbwegs stabil arbeitendes Grundsystem. ENDLICH kann ich mal wieder an die eigentliche Arbeit gehen und vorsichtig beginnen, das Ding für was sinnvolles zu verwenden...

Instabiles System

Nun heißt das Ende der kippenden Bits ja mitnichten, daß das System, so wie es jetzt vor mir liegt, wieder stabil laufen würde. Wahrscheinlich haben sich mindestens seit der Zeit um den 20.03. herum, wahrscheinlicher aber schon seit Beginn der Installationsorgie am 04.03., die Bitfehler im ganzen System allmählich akkumuliert.
Zu merken ist das an zunehmenden Fehlerlogs im Windows-Verzeichnis und im System-Log, an nicht mehr ausgeführtem Windows-Update (wegen angeblich nicht ausgeführtem Kryptographie-Dienst) und an weiter erfolgenden, wenn auch zumindest scheinbar selteneren Abstürzen.

Jetzt ist eine Kontrolle des Systems gegenüber dem letzten als halbwegs stabil in Erinnerung gebliebenen Backup dran und dann - abhängig von dem Ergebnis - möglicherweise eine komplette Neuinstallation.