Knutsens Blog - Beruf

VBS: Kontrollierter Reboot v. Windows-Systemen

nospam@example.com (Knutsen) — Wed, 03 Jun 2009 11:16:54 +0200

Die meisten Anwender an den 105 Workstations, die zu administrieren ich bei uns im Klinikum die Ehre habe, gehen nicht gerade pfleglich mit dem System um. Dazu gehört auch ein kontrollierter täglicher Reboot bei Windows-Systemen, einfach um viele Klippen zu umschiffen. Ich habe mittlerweile schon die krudesten Fehler gesehen, die daraus resultieren, daß ein System einfach eine Woche durchgelaufen ist (und in der Zeit exzessiv damit gearbeitet wurde). Die Ursachen müssen in den meisten Fällen nicht einmal Memory Holes im Windows-OS sein. Beispielsweise werden im Rahmen von Softwareverteilungen viele Updates bei Anwendungen durch Reboots bzw. bei Neuanmeldung eines Benutzers am System ausgelöst. Und wenn ein System niemals rebootet, bekommt es auch niemals Updates.

Aus diesem Grund habe ich mir ein kleines VBS gebastelt, welches folgende Aufgabe erledigt: Prüfe die aktuelle Uhrzeit des Systems und die Uptime. Liegt ersteres zwischen 00 und 06 Uhr und ist letzteres bei größer als 24 Stunden, so frage den Anwender, ob rebootet werden darf. Klickt der Anwender auf 'Nein' (weil er z.B. gerade bei einem sehr wichtigen Arbeitsschritt ist), so ~~nerve~~ frage ihn in Abständen von zehn Minuten immer wieder (auch wenn inzwischen 12 Uhr sein sollte). Sollte der Anwender die Dialogbox für 15 Minuten nicht beantworten, so reboote eigenständig.
Ist der Zeitpunkt oder die Uptime nicht wie oben angegeben, so soll natürlich nichts gemacht werden.
Die Reboot-Vorgang macht dasselbe wie ein "forced" Reboot, wie er z.B. nach Windows-Updates ausgelöst wird, wenn man sagt "Jetzt neu starten". Ein "unforced" Reboot hängt sich sehr oft noch an offenen Programmen auf.

Ich habe vorher im Netz geschaut, ob es schon vorhandene Scripts zu diesem Thema gibt, aber scheinbar wird dieses Problem immer durch Zusatzprogramme, die sich in die TrayBar legen, gelöst. Für mich ist jede zusätzliche Anwendung ein zusätzlicher Fehlerfall, darum vermeide ich dies am liebsten. Außerdem wird auf diesem Weg kein Speicher benötigt.
Apropos Speicher: Die regelmäßige Überprüfung geschieht aus Speicherspargründen per ~~Cronjob~~ Scheduled Task. Den Befehl, um diesen Taks zu erstellen, hänge ich unten mit an. Man kann natürlich auch dem Script eine Endlosschleife verpassen, und die Überprüfung auch so abfackeln. Aber bei meinem Arbeitsrechner benötigt die wscript-Umgebung 7 MB im Speicher, und bei einer Workstation mit 4 GB Memory sogar satte 100 MB (Warum?!).
"VBS: Kontrollierter Reboot v. Windows-Systemen" vollständig lesen

Morgenstund' hat Gold im Mund...

nospam@example.com (Ennonymous) — Mon, 04 Feb 2008 08:09:24 +0100

Ein notorischer Langschläfer - das ist es, was ich eigentlich bin. Trotz der offensichtlichen Vorteile, die Frühaufsteher genießen. Nun, heute konnte ich einen davon am eigenen Leib erfahren: die Aussicht um 8 Uhr aus meinem Bürofenster:

Sonst kenne ich solche Sonnenaufgänge nur von meinem Desktop-Hintergrund... Ich glaub' ich mach das öfter.

Cacti: Graphen

nospam@example.com (Knutsen) — Sun, 03 Feb 2008 18:01:15 +0100

Ennonymous hat neulich über Cacti geschrieben, da dachte ich, ich streu mal noch etwas motivierenden Zucker, was man so alles damit machen kann. Die Graphen bitte anklicken, um sie in ihrer korrekten Größe zu sehen.

Hier ist sehr gut der Verlauf bei einem Authentifizierungs-Server zu sehen. Wie man sieht liegt die Hauptarbeitszeit der Nutzer in der Mitte des Tages, also ca. um 12:00 Uhr. Der 26. und 27. waren Wochenendtage, wo nur leichte Anstiege zu verzeichnen sind.
"Cacti: Graphen" vollständig lesen

Vorsicht, heiß - oder: Wie man seinen Montag abend sinnvoll mit Linux vertrödeln kann

nospam@example.com (Ennonymous) — Mon, 28 Jan 2008 22:27:12 +0100

Zeit für einen Gastauftritt.

Ich habe gerade an meinem Heim-Server in kleinlichster Sisyphusarbeit die Sensordaten der Hardwareüberwachung lm_sensors in eine dauerhafte Statistik (über das Tool Cacti) übernommen. Dazu gehören neben CPU- und Systemtemperatur sowie Lüfterdrehzahl auch die Spannungswerte der Stromversorgung. So kann ich (hoffentlich) ziemlich genau sehen, wenn sich Schwächeanfälle anbahnen... und außerdem ist es irgendwie cool. Zumindest für Menschen ohne Leben wie mich.

Da es schon spät ist und ich meinen Hintern schon seit drei Stunden in mein Sofa bohre, gibt's nur eine Kurzversion - ich hoffe, dass sie trotzdem für jemanden nützlich sein kann. Sie ist auch ein schönes Beispiel dafür, wie man mit wenig Aufwand und ein paar UNIX-Bordmitteln schnell eine brauchbare Lösung häkeln kann.
"Vorsicht, heiß - oder: Wie man seinen Montag abend sinnvoll mit Linux vertrödeln kann" vollständig lesen

Hardwaregewühle

nospam@example.com (Knutsen) — Mon, 19 Nov 2007 21:59:32 +0100

Die insgesamt 120 Workstation, die später die Clients für das PACS spielen werden und an denen unter anderem die Radiologen dann die Röntgen-, CT-, MRT- oder andere Bilder befunden werden, sind getrennt von den Grafikkarten angeliefert worden. Da jede Workstation bis zu fünf (meistens aber zwei oder drei) Displays zur Ausgabe bekommt, heißt das ordentlich Grafikkartenstöpselei. Der Müll, der bei so etwas anfällt, sei im folgenden präsentiert:

Das ist die Hälfte des Haufens für Lübeck.

Eine anstrengende Woche...

nospam@example.com (Knutsen) — Sun, 18 Nov 2007 18:48:11 +0100

Dieses Blog muss reaktiviert werden. Diese Maxime habe ich mir auf die Fahnen geschrieben. Den Anfang soll ein knapper Artikel über die momentane Arbeitssituation bei mir in der Firma machen.

Bedingt durch das aktuelle Großprojekt ist die Stimmung im Büro allgemein sehr gehetzt und gestresst. Am 2.1.08 soll das neue Krankenhaus-Informations-System online gehen. Zur Verdeutlichung: Ein komplettes Krankenhaus, verteilt auf zwei große Campi in zwei Städten, mit ungefähr 10.000 Mitarbeitern stellt die gesamte EDV um. Einige Systeme bleiben zwar bestehen, werden aber an das neue KIS angebunden, weswegen man von 'komplett' guten Gewissens sprechen kann.

Da es keine nennenswerten Neueinstellungen gab, müssen alle Mitarbeiter (rund 80) in der IT nun neben dem Routinejob auch die Installation, Konfiguration und Vorbereitung des neuen Systems mit erledigen. Glücklicherweise leistet die Firma, die das System anbietet, den Löwenanteil. Jedoch genügt die Restarbeit, um alle zum Schwitzen zu bringen.

Für meine Person heißt das neue System: An der Einrichtung von 10-15 neuen Servern beteiligt zu sein, und die Aufstellung von 120 Clients auf zwei Campi (ergo in zwei Städten, ergo viele Diestreisen) zu managen, von der Installation bis zur Aufstellung. Was das im Detail heißt, möchte ich in den folgenen Artikeln noch näher erläutern.

Es genügt für den Moment zu sagen: Dank Telefon-(Hotline-)Dienst diese Woche habe ich insgesamt 57 Arbeitsstunden abgeleistet. Angenehm ist was anderes. Aber es ist all-in-all durchaus spannend.

Mobil bei Arbeit, Sport & Spiel

nospam@example.com (Knutsen) — Mon, 02 Jul 2007 23:07:37 +0200

Die letzten Wochen bersteten vor privaten Aktivitäten und Terminchen, und auch auf der Arbeit ist momentan reichlich zu tun. Zur Erinnerung: Das Krankenhaus, in dem ich arbeite, will zum Jahreswechsel ein komplett neues Informationssystem für all ihre Patientendaten, etc. einführen. Ein echtes Mammutprojekt, in das ungefähr 100 Personen direkt durch die Einrichtung und Inbetriebnahme und tausende Angestellte indirekt als Anwender involviert sind. Und mittlerweile habe auch ich als Hardware-Administrator des neuen PACS, des Teils des Systems, das Bilddaten aus CTs, MRTs, etc. speichert, die erste Hardware vor der Bürotür stehen. Davor haben aber die Götter die Routine gesetzt: Das alte System wurde vorletzte Woche noch einmal upgedated, was zu einem abendlichen Ausfall und zu vermehrten Überstunden bei der EDV-Belegschaft führte. Da ich an diesem Tag Frühdienst hatte, war ich satte 16 Stunden auf der Arbeit, von 6:15 bis 22:30 Uhr. An dem Abend war ich mehr als erledigt.
"Mobil bei Arbeit, Sport & Spiel" vollständig lesen

DICOM-Schulung

nospam@example.com (Knutsen) — Fri, 16 Feb 2007 17:33:38 +0100

Montag und Dienstag diese Woche befand ich mich in Oldenburg auf einer Schulung, was mir wieder eine gute Ausrede verschafft, warum ich länger nichts geschrieben habe. Die Vorträge waren höchst interessant, und ich fühlte mich in die Zeit meines Studiums versetzt, als ich noch die ganze Woche das Glück hatte, dersolchen zu lauschen. So waren die zwei Tage auch trotz des frühen Aufstehens um 04:30 Uhr am Montag fast wie Urlaub: Gemütlich im Vorlesungsraum sitzen, Abends ein wenig durch eine fremde Stadt schlendern und dann im Hotel abhängen. Und am nächsten Morgen ein reichhaltiges Frühstück.

In der Schulung selbst ging es um den Bereich DICOM. Dabei handelt es sich um eine Art Protokollsprache zwischen Modalitäten wie CTs oder MRTs und dem Bildarchivierungssystem PACS. Wie man sich leicht vorstellen kann, benötigt es eines vernünftigen (Quasi-)Standards, damit die zahlreichen Modalitäten verschiedenster Hersteller und die verschiedenen PACS-Systeme miteinander komunizieren können. Der DICOM-Standard liefert diese Funktionalität.

Ein Beispiel: Ein Tomographiegerät soll eine ganze Serie von Bildern liefern, da ein Patient sich den Arm gebrochen hat. Zuerst werden daher die Patientendaten eingeben, was entweder per Hand an der Modalität geschehen kann (wohl kaum noch) oder auf digitalem Wege durch ein Informationssystem, vielleicht ein RIS (Radiologie-IS). Die MTA positioniert den Patienten im Tomographen und stößt die Untersuchung an. Das Gerät erkennt dann die Position und schießt eine ganze Serie von Bildern, die es danach auf bestimmte Weise im DICOM-Format kodiert. Entweder werden die unkomprimierten Pixeldaten einfach so mit den Patientendaten, Aufnahmezeitpunkt, Modalitätsname, etc.pp. im Header verknüpft oder die Bilder werden noch vorher beispielsweise in JPEGs komprimiert, was verlustfrei (z.B. Lauflängenkodierung) oder verlustbehaftet (näheres in JPEG) geschehen kann. Der Bilderstrom wird schließlich über das LAN ans PACS geschickt.

Dummerweise ist der Standard DICOM ein ziemlich weicher Standard. DICOM selbst deckt nämlich extrem viele Funktionalitäten in Form von sogenannten Diensten ab. Und nicht jedes Gerät, das sich DICOM-Konformität auf die Fahnen schreibt, muss wirklich alle Dienste beherrschen, um DICOM-konform zu sein. Ist ja auch sinnvoll: So muß eine Modalität kaum den DICOM-Druckdienst anbieten, wenn sie nicht drucken kann. Jedoch gibt es auch innerhalb der Header-Segmente innerhalb der DICOM-Klassen bestimmte Segmente, die Modalitäten nicht implementieren müssen. Einzig vorgeschrieben ist daher, daß jedes Gerät, das sich DICOM-konform nennt, ein sogenanntes "Conformance Statement" mitführt. Dies ist ein Paper von ungefähr zwanzig Seiten Länge, wo genau aufgeführt ist, was an DICOM-Diensten und Header-Segmenten unterstützt wird und was nicht. Und wenn man selbst als Firma beispielsweise ein neues PACS einführt, muß man selbst genau darauf achten, ob das PACS sich auch mit allen Modalitäten unterhalten kann. Ergo: Haufenweise Conformance Statements wühlen.

EventLogs: So einfach kann es sein

nospam@example.com (Knutsen) — Sun, 11 Feb 2007 12:07:12 +0100

Neulich hatte ich über den LogParser berichtet und mich am Ende darüber geärgert, daß meine Versuche, EventLogs von anderen Computern auszulesen, (verständlicherweise) auf Grund fehlender Rechte fehlschlugen. Am Tag darauf habe ich dann doch noch eine Lösung, sogar in Form eines fertigen Scripts, entdeckt. Auf dieser Unterseite findet man es unter der Überschrift "Pulling Event Logs". Erfreulich an der Geschichte ist, daß ich damit auf den Servern gar nichts mehr installieren muß. Auf dem Client MySQL starten, einen Server sowie einen darauf befindlichen User-Account incl. Passwort mit den entsprechenden Rechten angeben und fertig. Als nächstes werde ich mir noch ein schönes Tool bauen, das mir Warnungen und Fehler übersichtlich präsentiert.

VBS, LogParser, EventLogs und WMI

nospam@example.com (Knutsen) — Wed, 07 Feb 2007 19:04:27 +0100

Momentan bin ich dabei, mich in das Scripting unter Windows mit VBScript einzufuchsen. Bis zu Beginn der Woche hatte ich mit VBScripten höchstens in Form von nervigen eMail-Anhängen zu tun, insofern also manches aufzuholen. Mit Visual Basic hatte ich mal in grauer Vorzeit was programmiert, aber das war sogar noch vor dem Studium gewesen; und richtig vergleichen kann man beides auch nicht miteinander. Begeistert bin ich von der Syntax der VBScripte nicht; für mich als Java/C++/php-Erfahrener eher gewöhnungsbedürftig. Aber gut, in Perl habe ich mich auch irgendwie eingefuchst, dann sollte VBScript wohl ein Kinkerlitzchen dagegen sein.

Nutzen möchte ich VBScript momentan dafür, bestimmte Inhalte aus EventLogs von Servern unter Windows 2003 zu sammeln und an eine zentrale Stelle zu schicken, nämlich meinen Arbeits-PC. Auf diese Weise müßte ich mich nicht täglich auf x Servern einloggen, um dort nach dem Rechten zu sehen. Gut: Momentan sind es nur 2(3) Kisten, die ich beobachten muss, das geht noch fix. Aber wenn wir bald die neuen Systeme bekommen, wird sich die Anzahl drastisch erhöhen.

Zuerst hatte ich mir ein kleines Script geschrieben, das die EventLogs per WMI sozusagen händisch ausliest. Aber wie das so oft ist, habe ich kurz danach ein freies (unoffizielles) Tool von Microsoft entdeckt, das diese Aufgabe übernimmt und noch vieles mehr kann. LogParser kann Logs aus 15-20 verschiedenen Quellen (EventLog, CSV, Text-Dateien, ...), darüber einen SELECT fahren und das Ergebnis wiederum strukturiert einem Ziel übergeben, das z.B. auch eine SQL-Datenbank sein kann. Nun musste ich heute nur noch ein kleines Script zusammentackern, das per Scheduler und LogParser automatisch um 00:05 die EventLogs des letzten Tages ausliest, in eine CSV-Datei verpackt und meinem Arbeits-PC übergibt. Dort kümmert sich ein weiterer Task per LogParser darum, die Inhalte der CSV-Datei in die SQL-Datenbank zu hauen.

Theoretisch wäre es auch möglich gewesen, direkt auf dem Server per LogParser die Daten der SQL-Datenbank auf meinem PC zu übergeben. Aber um mit einer SQL-Datenbank kommunizieren zu können, benötigt LogParser einen ODBC-Treiber. Und den wollte ich nun doch nicht auf x Servern installieren, da ich nicht scharf auf etwaige Seiteneffekte bin. Die Anwendung auf den 3 genannten Servern ist nämlich nicht die stabilste. Aber vielleicht ist dies eine Option für die Zukunft.

Optimal wäre es gewesen, wenn ich die oben beschrieben Push-Variante (Push, weil der Server meinem PC die Daten übergibt, sie also sozusagen rüberschiebt) hätte sein lassen können. Aber die Pull-Variante, nämlich die direkte Abfrage der EventLogs von meinem Arbeits-PC, scheidet leider aus, weil das Windows auf den Servern die EventLogs teilweise sperrt. Verständlich: Die Server sind in einer eigenen Domäne und mein Arbeits-PC hat da nicht allzuviel zu melden.

gähn 2

nospam@example.com (Knutsen) — Fri, 02 Feb 2007 18:38:01 +0100

Nach der letzten Woche, in der ich auf der Arbeit Frühdienst in der Hotline (6:30 bis 12:30 Uhr) schieben durfte, kam diese Woche dann der Spätdienst dran. Von 12:30 bis 17:00 Uhr muss man da das Telefon hüten. Insgesamt lässt sich sagen, daß zu dieser Zeit weniger los ist als morgens, da morgens der gesamte Betrieb sozusagen "erwacht". Viele Rechner werden neu gestartet, die Stationen haben alle Hände voll zu tun und die Verwaltung hat ihre Hauptarbeitszeit. Nach dem Mittag geht dagegen alles etwas gemächlicher voran.

Den Vorteil der stressfreien Hotline wiegt allerdings die Rufbereitschaft mehr als auf, die man von 17:00 bis 6:30 Uhr am nächsten Morgen in Form eines Handys mit nach Hause bekommt. Zu jeder Zeit kann man damit an- und zur Not auch aus dem Schlaf geklingelt werden, wenn die Stationen auf Grund eines ausgefallenen Servers oder Problemen mit dem PC nicht mehr arbeiten können. Die erste Nacht konnte ich ziemlich schlecht schlafen, danach hatte ich mich an das Gefühl schon wenigstens etwas gewöhnt.

Jetzt werde ich noch das Wochenende abreißen müssen und dann habe ich ab Montag um 6:30 Uhr endlich wieder circa einen Monat Ruhe vom Hotline- und Rufbereitschaftsdienst. <Bullyparade>Hur-rah!</Bullyparade>

gähn

nospam@example.com (Knutsen) — Thu, 25 Jan 2007 17:50:18 +0100

Diese Woche war arbeitstechnisch wieder sehr intensiv. Zum ersten Mal war ich die gesamte Woche zum Frühdienst eingeteilt, ich war also von 6:30 bis 12:30 Uhr der erste Ansprechpartner im Betrieb für Hardware-Probleme. Daß da reichlich Neues auf mich zukam, war klar. Manchmal hat es mich aber doch noch etwas überrollt. Wobei ich die Woche allerdings nicht komplett Dienst schieben konnte. Montag und Dienstag war ab 9 Uhr wieder jeweils Terminalserver-Schulung, und heute haben ein Kollege und ich uns die Arbeit geteilt. Nichtsdestotrotz komme ich diese Woche bisher schon auf rund 41 Arbeitsstunden, also über 10 Stunden pro Tag (allerdings incl. Mittagspause). Gestern fiel ich vermutlich darum schon um 20 Uhr mit leichten Kopfschmerzen ins Bett.... ich weiß halt nicht, was gut ist.

Schulungen und Rufbereitschaft

nospam@example.com (Knutsen) — Sat, 20 Jan 2007 12:53:31 +0100

Nun habe ich schon wieder lange nicht geschrieben, aber diese Woche war die freie Zeit wieder knapp. Von Montag bis Mittwoch hatte ich auf der Arbeit mit fünf bis neun weiteren Kollegen eine Schulung im Terminalserver-Bereich, weswegen ich von 8:00 bis 18:00 Uhr auf der Arbeit war. Der Dozent referierte über die Einrichtung und Administration von Terminalservern unter Windows Server 2003. Der erste Tag ging für die Installation und erste Grundeinrichtung drauf, der zweite befasste sich mit Basiswissen zu Active Directory, Gruppenrichtlinien und Sicherheitsvorlagen und der dritte mit der Einrichtung von Applikationen. Für mich waren die Tage sehr lehrreich, da ich bisher natürlich noch nie mit Terminalservern im Speziellen zu tun hatte. Auch mein Wissen zu den tiefgehenden Windows-Elementen wie Sicherheitsvorlagen war selbstverständlich bei Null. Der Dozent trug auch sehr frei vor, es war zu keinem Zeitpunkt irgendwie einschläfernd. In der kommenden Woche werden dann noch einmal zwei Tage folgen.

Die restlichen Tage werde ich außerdem das erste Mal intensiv mit Telefondienst zu tun haben. Mittwoch bis Freitag bin ich für den Frühdienst von 6:30 bis 12:30 Uhr eingeteilt, wofür ich um kurz nach fünf aufstehen muss. Für einen Langschläfer wie mich eine echte Qual. Außerdem dürfte der Dienst echter Stress werden... naja, das Positive ist, daß ich dadurch gezwungenermaßen echte Einblicke in die Systeme bekomme, mit denen ich bisher nur am Rande zu tun hatte. Die Woche darauf kommt dann der echte Brocken: Spätdienst von 12:30 bis 17:00 Uhr und zusätzlich Bereitschaftsdienst per Handy in den Stunden von 17:00 Uhr bis nächsten Morgen um 06:30 Uhr. Zwar sind die Anrufe am Abend bzw. in der Nacht natürlich glücklicherweise sehr spärlich, da nur der stark reduzierte Spät- bzw. Nachtdienst (die Verwaltung ist da größtenteils z.B. komplett unbesetzt) auf den Stationen und den Service-Bereichen EDV-Probleme bekommen kann. Aber in der Nacht aus dem Schlaf geklingelt werden, ist natürlich nicht wirklich prickelnd. Meine Kollegen versichern mir allerdings, daß dies nur sehr selten vorkommt. Aber mal sehen... Sollte das wider Erwarten doch recht häufig vorkommen, kann ich ja meine Dienstzeit in den Spätdienst-Wochen auf 12:00 bis 20:00 Uhr verlagern, dann habe ich wenigstens von 06:30 bis 10:30 noch einige Stunden ungestörte Nachtruhe.

Porting Active Directory

nospam@example.com (Knutsen) — Thu, 11 Jan 2007 21:50:13 +0100

Mittwoch hab ich noch über ein Netzteil gejammert, das mir bei einem alten Server verreckt ist... vorgestern war es dann eine Festplatte, die den Geist aufgegeben hat. Naja. Dafür war nach dem Vormittag Microsoft Windows Server 2000 nach SP2, SP4 und haufenweise Patches mit grob geschätzt einer Handvoll Reboots endlich aktuell. ächz Heute konnte ich mich dann endlich um die Hauptsache kümmern: Vom alten Server das Active Directory exportieren und auf dem neuen gebrauchten wieder aufspielen.

Zuerst mußte der Server vom Netzwerk, denn der neue Server muß ja genauso heißen wie der alte und in derselben Domäne Domänen-Controller spielen, wenn er ihn komplett ersetzen soll. Ansonsten käme es natürlich zu Konflikten. Danach meckerte allerdings Active Directory, weil es ohne Netzwerk nicht installieren will. Für den Zweck mußte dann der "Microsoft Loopback Adapter" herhalten, der eine verbundene, Netzwerkkarte emuliert. Danach klappte es auch mit der Installation des Active Directory.

Der anschließende Import der alten Directory-Daten schlug allerdings fehl. Zahlreiche Attribute können nicht importiert werden, weil die Windows-Sicherheitskontenverwaltung das nicht erlaubt. Gut, zu diesem Zweck gäbe es noch Programme, die das erledigen könnten. Ein weiteres Problem ist aber, daß - egal mit welchen Mitteln auch immer - das Active Directory es nicht erlaubt, die Passwörter der Benutzer zu exportieren, was natürlich in einem anderen Kontext auch sinnvoll ist. Das bedeutet, man müßte auf dem neuen Server jedem Benutzer ein neues Passwort geben. Muss das mal mit meinem Kollegen nächste Woche besprechen....

Ein Server zum Spielen

nospam@example.com (Knutsen) — Wed, 10 Jan 2007 20:27:38 +0100

Seit gestern habe ich einen Server zur Einrichtung in meinem Büro. Es handelt sich dabei um einen "uralten", ungefähr sieben Jahre alten Proliant ML370 von Compaq. Ist schon lustig: Dieses Ding hat im Endeffekt weniger Leistung als mein Arbeits-PC, dröhnt mir aber in meinem 10m^2 - Büro die Ohren weg und wirbelt meine Unterlagen durch den Raum. Der Zahn der Zeit nagt außerdem an dem Gerät: Beim Anschließen ans Stromnetz verabschiedet sich gleich das erste Netzteil mit einem lauten Knall. Aber wer braucht schon drei Netzteile, zwei tun es auch. Vorerst... Der Schreck saß allerdings doch noch fünf Minuten in den Gliedern.

Warum ich das Teil zum Leben erwecken muss: Wir haben einen fast identischen Server seit einer kleinen Ewigkeit in Betrieb. Über die Jahre ist das System allerdings etwas aus den Fugen geraten. Deswegen soll ein neuer, gebrauchter Server als Ersatz sauber aufgesetzt werden. Danach werden die Anwendungsdaten vom alten Server portiert. Ich hoffe mal, ich schaffe das noch in den nächsten zwei Tagen nebenbei, denn die nächste Woche geht fast komplett für eine Schulung im Terminalserver-Bereich drauf.