Kategorie: Indianer, Kater und andere Serverbewohner

Was für eine beschissene Software. Wer Volldepp kommt auf die Idee, einen Deinstaller so zu programmieren, dass auch mit deaktivierter „Sicherheitsüberprüfung“ (die Deppenarschlöcher meinen damit wohl so etwas wie einen Dependency-Check) ein nicht funktionierendes Modul nicht einfach dateimäßig aus dem System gekickt werden kann?

Die Servermigration haben wir von einem Berater durchführen lassen, hätte ich doch mal drauf bestanden, auch die Workstation-Neuinstallationen durch diesen machen zu lassen: Ich weiß jetzt schon, dass ich den letzten Bus verpasse.

Diesen Dreck nie wieder anfassen zu müssen ist einer der größten Vorteile meines Arbeitgeberwechsels.

Das ganze Hardware-Drama die letzte Zeit hat mich dazu bewogen, etwas anzufangen, was ich mir eigentlich schon seit (beinahe :)) drei Jahren wünsche: Ein zeitgemäßes Servermonitoring bei $AG.

Hängengeblieben bin ich dann bei Zabbix, die Inbetriebnahme war so weit so schmerzlos (fertige Pakete in den Repos von Debian Etch und Lenny sowie CentOS 5.3), die grundsätzliche Konfiguration ist recht simpel und straightforward**, wobei ich bei weitem noch nicht die Möglichkeiten der Software ausnutze, an sich teste ich nur ob sich ein Server in die ewigen Jagdgründe verabschiedet hat und generiere daraus Panikbenachrichtigungen***. Sicher wäre das schneller mit einer Handvoll selbstgestrickten Skripten gegangen, aber ich wollte eine Lösung einführen, auf die ich langfristig aufbauen kann. NICHTS hält länger als ein Provisorium…

Das einzige wirklich fehlende war dann noch die Überwachung vom Überwachungsserver selbst – das ganze Ding soll dazu dienen, dass ich seit Wochen mal wieder in Ruhe schlafen kann ohne mich in Albträumen über abkackende Server zu stürzen; somit ist klar, dass ich auch den Wächter überwachen muß.

Prinzipiell lassen sich Zabbix-Server-Instanzen auch kaskadieren, aber für meine kaum 3 Dutzend Server wäre es absoluter Overkill, gleich zwei Zabbixe zu betreiben (und dann immer noch nicht mitkriegen, wenn der Strom ausfällt…), damit mußte etwas einfacheres her.

Was ich jetzt habe ist ein dreistufiges Monitoring:
1. Zabbix überwacht aktiv alle internen Server (entweder über den Agent-Dienst auf den Servern oder – wenn der nicht installierbar ist – ganz simpel von außen über Ping und offene Ports)
2. Auf dem Mailserver (auch im internen Netz) läuft per cron ein simples Skript, das den Zabbix-Agent auf dem Zabbix-Server abfragt (sinnigerweise nach der Anzahl laufender zabbix_server-Prozesse :)), Herzstück des ganzen ist das:

echo -e „proc.num[zabbix_server]“\n\n; sleep 5) | telnet [Zabbix-Server] 10050 2>&- | cut -s -d D -f 2 | cut -b 9-

Damit wird nur per Telnet auf dem Port 10050 (der Default bei Zabbix Agents) ein Item abgefragt, in diesem Fall die Anzahl laufender Prozesse mit dem Name „zabbix_server“. Der Rest dient nur dazu, die Ausgabe vom Zabbix-Agent in nutzbare Form zu bringen, die Ausgabe vom Telnet-Teil sieht ungefähr so aus:

Trying [IP-Adress]…
Connected to [Zabbix-Server].
Escape character is ‚^]‘.
ZBXD[ein paar Byte Binärschlonz]23

Das erste cut wirft die ersten 3 Zeilen raus (der Trenner „D“ ist ja nicht vorhanden) und splittet die vierte Zeile, Ergebnis ist dann [Binärschlonz]23. Das zweite cut erlöst mich dann noch von dem Zabbix-Protokoll-eigenen paar Bytes nichtdruckbare Zeichen und ich habe ein einfache Integerzahl. Und mit der lässt sich in einem Skript schon einiges anstellen :) Meine Benachrichtigungen habe ich dann so definiert, dass alles von >0 gut ist, kriege ich als Ergebnis eine 0 (kein laufender Zabbix-Server-Prozess) oder irgendwas anderes (ein leeres Ergebnis heißt, dass keine Verbindung aufgebaut werden konnte beispielsweise) stimmt was nicht und die Paniknachricht wird generiert.
3. Auf einem angemieteten Server bei $großemHostingAnbieter haben wir noch einen root-Server laufen, der fragt dann über ein ähnlich simplen Bash-Skript ab, ob Port 25 (=smtp) auf der externen Adresse von unserem Netz erreichbar ist.

So ist im großen und ganzen eine lückenlose Überwachung möglich, der Zabbix-Server selbst überwacht alle meine internen Boxen, der Mailserver hat ein Auge auf die Zabbix-Box und ein Rechner draußen in der Wolke bewacht den Mailserver. Nicht 100%ig valide, aber für die SLAs von uns (und meinem Schlaf :)) reicht das erst mal.

*) sorry wenn jemand was politisches erwartet hat, aber was sollte ich dem noch hinzufügen können?
**) im großen und ganzen, allerdings scheint sich das Übertragungsformat zwischen V 1.1.4 (bei Etch) und V 1.4.6 (Lenny) ziemlich geändert zu haben, für ein paar obskurere Monitoring-Sachen auf einigen Servern war ich gezwungen das Source-DEB von Lenny unter Etch neu zu backen
***) auch die sind so simpel wie möglich gestrickt: Es werden Mails an $großenFreemailProvider generiert und von da aus per Filter auf Absender und Betreff per SMS-Benachrichtigung an mich weitergeleitet

Nachdem dieses Drama so ziemlich ausgestanden ist und auf der neuen Kiste jetzt CentOS läuft schlage ich mich mit sendmail rum – dem Default-MTA von RHEL und im großen und ganzen unmöglich zu konfigurieren.

Ich möchte, dass sendmail alle lokalen Mails über den zentralen MTA verschickt, der als Smart Host für alle meine Systeme dient – und alle Mails sollen maskiert werden, also nicht verschickt unter dem eigentlichen Servername (bei mir dann @blablubb.dmz.firma.tld) sondern eben als @firma.tld. Prinzipiell ja recht einfach, dafür gibt es ja in der sendmail.mc die ganzen Masquerade-Settings (beschrieben z.B. da) – ABER Mails vom Benutzer root werden standardmäßig nie maskiert, weshalb die mein MTA immer gedropt hat, und Interesse daran, meine ganze Mail-Domain-Struktur wegen einem dämlichen sendmail anzupassen hatte ich dann doch nicht. Dieses ganze Feature läuft dann unter dem Schlagwort „exposed“ und hat die – prinzipiell nicht dummer – Idee, root-Mails nie zu maskieren, um die Herkunft zweifelsfrei einem Host zuordnen zu können.

Aber warum ist es nicht möglich, dieses Setting per m4 (und eine eigene Skriptsprache nur zum erzeugen einer Conf finde ich schon recht weird…) zu überschreiben? Umgekehrt geht das, mit EXPOSED_USER(`usernames‘) lassen sich weitere Benutzer aus dem Masquerading ausklammern, aber ich will ja eben exakt die Gruppe C{E} (die alle exposed users beinhaltet) aus der sendmail.cf kleiner machen.

Mir ist dazu nichts eingefallen, jetzt konfiguriere ich eben sendmail doch direkt in der sendmail.cf und ignoriere diese tollen m4-Makros. Narf.

MS-Patchday mal wieder – an sich kein Problem und eben auch zu meinen Aufgaben gehörend, den Blödsinn zeitnah auf den Terminalservern aufzuspielen.

Aber heute hat sich Microsoft selbst übertroffen, das .net-Update hat eine Größe von über 200mb!?! Das ist ein beschissesene Anwendungsframework, was zum Geier ist da drin? Porn? Der Source von Windows 7? Ein Posix-Emulator, damit das Zeug in einer stabilen Umgebung laufen kann?

*) Titel bei Peter’s Blog geklaut, den Link dazu gab mir Matthias

Ich habe heute die Groupware-Datenbanken auf einen neuaufgesetzten Debian-4rc3-Server mit mysql 5 und innodb als Backend geworfen.

Drückt mir die Daumen, dass dies die massiven Performanceprobleme behebt…

Heute abend dann Crash um den ganzen Blödsinn zu vergessen – wer Lust?

mysql> show databases;
+----------+
| Database |
+----------+
| mysql    |
+----------+
1 row in set (0.00 sec)
mysql>

so und nicht anders hat ein Datenbankserver auszusehen – jetzt muß mein Kollege nächste Woche nur noch seinen Java-Web-Start-HTTP-Schlonz vom Server kratzen und ich kann die Drecksbox endlich töten und neuaufsetzen.

Das will ich eigentlich seit 18 Monaten tun, so langsam wird es Zeit…

*Narf*, ich hätte nicht erwartet, dass ich mich in meinem Leben mal mit obskuren Ausnahmeregelunge von HTTP herumschlagen muß. Das ganze geht immer noch um dieses Proxy-Problem und ich habe inzwischen zumindestens mal die Fehlerursache herausgefunden.

Unser Client baut eine HTTP-Verbindung zum Server auf – diese nach der Protokollversion 1.1 persistent , das heißt, das die Verbindung nicht geschlossen wird, sondern über die gesamte Sitzungsdauer offen bleibt. Anders als bei V 1.0 ist eine persistente Verbindung in 1.1 default und kann nur noch explizit _nicht_ angefordert werden, und da begann dann das Problem…

Unser Client versucht also einen Verbindungsaufbau, in der Annahme, dass natürlich die Verbindung offen bleibt, was aber dieser spezielle Proxy nicht unterstützt und daher den Request (gültig) beantwortet und dann ein Connection: Close in den Header klatscht, was wir nicht abfangen.

In der RFC 2616 liest sich das dann so:

8.1.1 HTTP implementations SHOULD implement persistent connections.

14.10 HTTP/1.1 applications that do not support persistent connections MUST include the „close“ connection option in every message.

Die wichtigen Wörter sind dann auch schon groß geschrieben – should und must. Der Proxy verhält sich (leider) standardkonform, nutzt aber eine Ausnahmeregelung, an die wohl keiner unserer Coder gedacht hatte.

Na dann, zurück an’s Zeichenbrettzur IDE.

Samstag ist mir noch eine Exception auf unserem Java6-Test-Tomcat aufgefallen, irgendwas mit Logging und ähnlichem. Da der Server prinzipiell lief, habe ich das dann erst mal verschoben.

Kern des Problems war die fehlende Berechtigung auf „logging.properties“ zuzugreifen – eine Konfigurationsdatei, die wir weder haben noch brauchen. Es liegt dann übrigens daran, dass der Tomcat-Container zwingend Leserecht darauf braucht, um festzustellen, dass die Datei nicht existiert um dann ohne zusätzliche Konfiguration für den in Tomcat 5.5 neu eingeführten Logger JULI weiterzumachen.

Wer denkt sich denn so was aus?

Not listening Juli – Geile Zeit

Klassischerweise wird eine Race Condition ja vor allem in der Programmierung zum Problem (auch wenn ich in der englischen Wikipedia eine deutlich weitere Definition vorgefunden habe), doch ich habe hier ein schönes Beispiel für eine sehr langandauerende, die ich niemand vorenthalten möchte:

1. Bugmeldung, dass Attachments mit Umlauten nicht mehr korrekt in die Mails gepackt werden
2. Parallel zum Groupware-Upgrade Fehlersuche, dabei unter anderem an den locales rumdrehen
3. Irgendwann merken, dass ein Folgebug aus einem Hotfix das Problem verursachte
4. Tage später kurz vor Weihnachten schmiert der Server ab (Xen mit Windows-Virtualisierung ist einfach nicht produktionsreif – aber egal…)
5. Wieder etliche Zeit später poppt der Umlaut-Fehler wieder hoch
6. Verzweiflung, Programmiere verrückt machen, Testcases basteln, im Source wühlen, … -> vollen Programm eben

Was war passiert?

Bei dem parallelen Fehlereingrenzen und Update einspielen wurde der Tomcat gestartet, als locales zeitweise wieder auf UTF-8 stand, anschließend änderte ich dann das System auf ISO-8859-15, was dem Tomcat im Betrieb aber egal ist – er nutzt weiterhin UTF-8 als Charset.

Als dann die Box abschmierte wurde beim Reboot der Tomcat mit ISO-Codierung angestartet, was vom Fehlerbild her identisch zu dem durch den Fix verursachten Bug aussah – und es hat ziemlich lange gedauert, bis ich das Knäuel der gemachten Änderungen entwirrt hatte, vor allem weil sich der ganze Vorgang über insgesamt 20 Tage erstreckte und dazwischen auch mein Urlaub lag.

Memo an mich: Nicht zu sehr parallelisieren, ich bin doch einfach nur Single-Task-fähig…

So, heute war mal wieder Abschalttag.

Gestern habe ich die Kompilierung unserer Groupware auf einen anderen Server migriert – so wildes Bash- und Ant-Gepfuschel. Die spaßeshalber von mir kompilierte Kombination aus Client und Server lief einwandfrei, daher hatte ich keine großen Bedenken mit dem zügigen abschießen des alten Systems (braucht wer ’ne 1-HE-Pizzabox mit unterirdischen Leistungsdaten? Der Gruseleffekt ist euch sicher, wenn ihr das irgendjemand zeigt…).

Heute morgen um halb drei (sic) hat ein Coder eine neue Version der Groupware rausgeschickt – und was war? Sie lief nach dem kompilieren natürlich nicht… Nachdem ich ewig nach dem Fehler in meinen Kompilaten gesucht habe hat er dann zugegeben, im Delivery-Package einen Fehler eingebaut zu haben – der Mensch sollte, wenn er schon morgens um halb drei irgendwas verschickt, doch sein Zeug wenigstens testen.

Wie dem auch sei: Die Kiste ist jetzt tot, was meine Quote anhebt auf 8 abgeschaltete und 3 neu in Betrieb genommene – von ursprünglich mal 16 Systemen.