Admins Log

Wie jeden letzten Freitag im Juli ist heute Admin-Day!

Na, da klopfe ich mir doch mal selbst auf die Schulter und sende hiermit viele Grüsse an die Kollegen da draussen!

Ich habe mir in der Firma OTRS aufgesetzt, um einen besseren Überblick über Probleme und Aufgaben zu bekommen. Das hatte ich zwar schon einmal laufen, konnte ich aber wegen einer Umstrukturierung der IT nicht mehr nutzen.
Nach einem halben Jahr(!) habe ich also meinen Zugang bekommen, dennoch hat OTRS zunächst keine automatischen Benachrichtigungsmails versandt.
Grund war, dass das From im Envelope der Mails leer war und unser Mailserver solche Mails abweist. Also in den Einstellungen rumgesucht, eine Adresse eingetragen und schon klappt alles wunderbar.
Die ersten Tickets habe ich auch bereits erfolgreich aufgenommen.

Es ist zum Haare ausraufen!
In der ganzen Abteilung haben alle eine IPv6-Adresse automatisch vom radvd bekommen. Nur ein Rechner weigert sich, IPv6-Traffic zu senden oder anzunehmen! Routen stimmen, Modul ist geladen, Adresse manuell vergeben, Paketfilter ausgeschaltet, mit Wireshark gesnifft. Nix! Nada! Auf dem Interface kommt weder Traffic an, noch geht von dem Rechner Traffic raus.
Mit IPv4 ist alles bestens.

Nachdem ich da mal einige Zeit rumgesucht habe, habe ich dem Kollegen geraten, die Kiste mal neu zu starten. Dummerweise steuert sein Rechner aber diverse Testprogramme, so dass das nicht so ohne Weiteres möglich ist. In letzter Konsequenz habe ich ihm dann einen IPv6-over-IPv4-Tunnel gegraben. Jetzt kann er auch per IPv6 die (lokale) Welt erforschen!

Zu einem neuen Rack, gehört auch - zumindest bei uns - ein neuer Switch.
Vor einiger Zeit hatte ich daher einen DGS-3100 mit 48 Ports von D-Link ausgeguckt und bestellt. Heute nun habe ich das Teil per Post bekommen und auch gleich ins Rack geschraubt. Dann noch fix einen alten Rechner herbeigeschleppt, um mit dem Switch ein wenig rumzuspielen.
Nach der Konfiguration, die recht einfach war, konnte ich dann auch gleich loslegen. Den Switch habe ich deshalb ausgesucht, weil er für jeden Port die Bandbreite begrenzen kann, was für uns sehr wichtig ist und bisher mit Hilfe von tc auf einem Linuxrouter gemacht wurde.
Also habe ich mich auf dem Rechner, der an dem Switch hängt, eingeloggt und einen rsync von einem grösseren Verzeichnis auf einem unserer Server gestartet. Da ich den Zielrechner, bzw. dessen Traffic, per Cacti überwache, konnte ich dann auch sehen, wie sich der Durchsatz verhält. Auf dem Switch habe ich die gute alte ISDN-Geschwindigkeit von 64 kBit/s eingestellt.
Und die Daten tröpfelten. Und tröpfelten. Das nahm kein Ende, also 128 kBit/s eingestellt. Man mag es kaum glauben, dass man sich früher(tm) mal über die "Wahnsinnsgeschwindigkeit" von ISDN gefreut hat. Aber gut, man fängt immer klein an!

Wie dem auch sei, der Switch erfüllt seine Aufgabe. Einziges Manko: Aus irgendeinem Grund weigert sich mein Firefox, die Startseite des Switches beim ersten Aufruf darzustellen, obgleich HTML angekommen ist. Vielleicht liegt es auch an meinem Firefox. Nach einem Reload klappt es dann jedenfalls.

Lange Zeit nichts mehr gebloggt, weil irgendwie nichts passiert (zumindest im Bereich "Administration"). Heute aber bin ich einem kleinen Fehler auf die Spur gekommen. Was heisst Fehler...aber der Reihe nach:
Ich setze PowerDNS mit PostgreSQL als DNS Server in unserem Netz ein. Um die Ausfallsicherheit zu erhöhen, habe ich einen Bind 9 Server als Slave konfiguriert (vorher war der nur einfacher Forwarder). Nun hat der Bind aber bei der Änderung eines Records auf dem Master keine Benachrichtigung erhalten.
Nach Sucherei im Web, habe ich dann den entscheidenden Hinweis gefunden: Man muss definitiv eine Seriennummer im SOA Record eintragen! Da bietet sich natürlich der Timestamp an. Interessanterweise habe ich irgendwo gelesen, dass PowerDNS eine 0 als Serial automatisch erkennt und die richtigen Schlüsse daraus zieht, aber dem ist nicht so.
Also habe ich mir eine Stored Procedure mit einer Regexp-Ersetzung gebastelt, die mir den Job abnimmt.

Fazit: Kaum macht man es richtig, klappt es auch mit dem Notify an den Bind!

Heute ist unser neues Rack angeliefert worden!
Dann kann die Erweiterung unseres Serverraumes ja bald losgehen.

Wenn man virtuelle Maschinen unter Proxmox mit IPv6 betreiben und das Ganze via venet-Interfaces machen will, dann wird man feststellen, dass man aus den VEs nur bis zum darunterliegenden Host kommt.
Genau dieses Problem hatte ich in den vergangenen Tagen vor mir gehabt, was natürlich zur Folge hatte, dass keine VE per IPv6 von ausserhalb erreichbar war.

Das Problem lässt sich dadurch lösen, dass man ip -6 add proxy <ip der VE> für jede VE auf dem Host durchführt.
Die Automatisierung habe ich mit einem kleinen Skript-Hack erzielt, das per Cronjob gestartet wird. Die Infos kann man sich ja bequem aus den Konfigurationsdateien der jeweiligen VE rauskramen. Eine Erkennung, ob die Adresse nun v4 oder v6 ist, habe ich nicht gemacht, da der Aufruf von ip -6 bei einer v4-Adresse eh in einen Fehler läuft. Von daher ist mir auch egal, wie die Reihenfolge der Adressen in der Konfigurationsdatei ist.

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!

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.

Gestern und heute habe ich mich an eine Dell R210 gesetzt, die unser betagtes Gateway ablösen soll. Betriebssystem ist ein Debian Lenny. In der Kiste sind insgesamt vier Netzwerkinterfaces (Zwei on board, zwei auf einer Karte) eingebaut. Alle von Broadcom.

Witzigerweise funktionierten nur die Interfaces auf der Zusatzkarte, die eingebauten Interfaces waren nicht vorhanden. Ein gepflegtes "WTF!?" entsprang mir da doch.

Ich habe es mal mit dem tg3 Modul probiert, aber das war ebenso erfolglos und dann auf einmal kam mir der Zufall zu Hilfe: Nachdem ich das Modul bnx2 rausgeworfen und neu geladen hatte, funktionierten alle Interfaces. Von da an war es einfach: Das Modul habe ich aus der initrd rausgeworfen. Dazu habe ich alle Module in /etc/initramfs-tools/modules eingetragen und nur bnx2 weggelassen. Danach dann die initrd neu erstellt, einmal das System neugestartet und schon klappte alles. Übrigens habe ich in der Aliasdatei unter /etc/modprobe.d eth0 bis eth3 dem Modul bnx2 zugewiesen. Dann wird das Modul auch ordentlich geladen.