Admins Log

Die mir übergeordnete IT-Abteilung scheint diverse Ports auf externen Servern unerreichbar zu machen.
So zumindest meine Vermutung, da ich heute für einen Repositoryserver keinen rsync auf einen offiziellen Debian-, bzw. Ubuntumirror machen konnte. Der Server, der Spiegel spielen soll, steht in einem internen Netz und soll für interne Server die Pakete bereitstellen, was natürlich unsere externe Anbindung entlastet. Wie gesagt: rsync ging nicht und es gab Timeouts.
Da ich aber nicht ganz so blöd bin, habe ich einen Squid-Proxy auf einem anderen Server geprüft und siehe da: Der kann Port 873 extern erreichen. Also fix RSYNC_PROXY korrekt auf dem Reposerver gesetzt, rsync gestartet und siehe da: Die Dateien kamen nur so angeflogen.

Wie war das noch mal mit der Zensur? Lässt sich alles umgehen, man muss nur wissen wie!

Die Migration eines unserer Server von reinem OpenVZ auf Proxmox hat heute Morgen erstaunlich gut geklappt. Eine Sache jedoch war etwas verwunderlich: Bei intensiver Nutzung von IPv6 unter Kernel 2.6.24-10-pve stürzte mir das IPv6 Modul ab. Ich habe daraufhin erst einmal 2.6.18-2-pve installiert, um auf der sicheren Seite zu sein.

Aber jetzt läuft der Server in einem Proxmoxcluster und das ist - ehrlich gesagt - eine richtige Wohlfühlatmosphäre! Die Templates erstelle ich auf dem Mastersystem und automagisch werden diese an die Nodes im Cluster verteilt. Zudem gibt es eine recht gute und übersichtliche Weboberfläche.

Das Upgrade von PostgreSQL von Version 7.4 auf eine 8er Version lief hier leider nicht so reibungslos, da ich Depp vergessen hatte, vorher einen Dump zu machen. Da ich nicht mehr an die alte Version via aptitude rankam, musste ich mir PostgreSQL 7 erst einmal runterladen und fix selbst compilieren.
So kam ich dann auch an meinen Datenbankdump und konnte den dann dem 8er Server vorwerfen. Dass das geklappt hat, sieht man an diesem Blog, der wieder funktioniert.

Ich habe heute - als Vorbereitung für das Upgrade auf Lenny - auf diesem Server erst einmal einen aktuellen Kernel installiert. Wie meistens ging das völlig reibungslos.

Hui, das ist mir gar nicht aufgefallen: Der Server, auf dem auch der Blog hier läuft, ist gar nicht zu 100% auf Etch umgestellt. Einige Kleinigkeiten fehlen, die wichtigste Software ist aber aktuell.
Aufgefallen ist mir das, weil ich von Etch auf Lenny umstellen wollte und mir aptitude einige unaufgelöste Abhängigkeiten signalisierte. Da ich wegen des morgigen Eishockeyspieles und der damit per Telefon übertragenen Radiosendung keine Experimente starten wollte, habe ich das Upgrade erst einmal verschoben.

Eigentlich sollte ich mal fragen, ob ich eine Zusatzprämie für gelaufene Kilometer in der Firma bekomme. Heute war ich den ganzen Tag im Gebäude unterwegs und das nur, weil ein Laptop mit einem bekannten Closed-Source Spielestartsystem andauernd rumzickte. Da der Laptop in einem Konferenzraum aber gebraucht wurde, konnte ich mir den nicht einfach unter den Arm klemmen. Nun ja, das Ding wird spätestens Anfang nächster Woche wieder in die USA geschickt.

Ausserdem habe ich mal nach unserem Storagesystem geguckt und dummerweise hat Linux die neuen Platten (doch) nicht erkannt, was evtl. daran liegt, dass der eingebaute RAID-Controller nicht richtig konfiguriert ist. Bei dem System muss ich mal gucken, wie ich das geregelt bekomme. Das kann ich ggf. auch  ganz bequem per KVM-Switch erledigen.

Die nächsten Tage können eigentlich nur noch besser werden.

Wir haben in der Firma an einem dicken PowerEdge Server eine PowerVault Storageeinheit angeklemmt, um viele Daten speichern zu können, die meine Kollegen benötigen. Nun soll die Storageeinheit durch zwei 500 GB Platten vergrössert werden, die im Software-RAID laufen sollen.

Dummerweise kam bei der Erstellung des RAIDs immer die Meldung "/dev/sdc resource busy" (oder so ähnlich...jedenfalls busy), sodass ich kein RAID erzeugen konnte.

Ein wenig Rumsucherei im Web brachte dann zu Tage, dass ein im Server verbauter Hardware-RAID-Controller, bzw. die Module dm_* dafür sorgen, dass ich kein RAID anlegen konnte. Ergo müssen die Module raus.
Also die Module in die Blacklist eingetragen, einen neue initrd gebaut und per at-Job dafür gesorgt, dass die Kiste um Mitternacht bootet.

Ob das alles geklappt hat und ich morgen das RAID erzeugen kann, wird sich zeigen. Ich bin da guter Hoffnung!

Dumm gelaufen!

Mitten während einer Radioübertragung brach das Netzwerk auf unserem Heimserver Athene weg. Knappe 3 Stunden hat es gedauert (incl. diverser Tests), bis das System wieder lief.

Wenn ich Urlaub habe, werde ich mich da mal vernünftig drum kümmern. Wichtig ist, dass die Kiste wieder läuft.

Unser Heimserver Athene hat in der Nacht von gestern auf heute rumgezickt. Grund war natürlich mal wieder der Mensch: Durch einen Fehler beim Update, habe ich aus Versehen ein falsches Paket installiert und so das System mehr oder weniger unbrauchbar gemacht. Mit Hilfe einer Installations- und Rettungs-CD konnte ich das System aber wieder flott kriegen, ohne alles neu installieren zu müssen. Linux hat doch enorme Vorteile!

Ich habe heute unseren kleinen Linuxrouter von Ubuntu auf Debian "umgebaut".

Eigentlich war der Auslöser, dass bei Ubuntu die menu.lst immer mit den UUIDS erzeugt wurde, ich aber gerne die Devices der Platten haben will.

Also, liebe Ubuntuentwickler: Wenn ich die Datei ändere und kopt richtig setze, dann will ich dass das so bleibt, wie ich das eingetragen habe! Der Bug ist übrigens bekannt.