Viele Server updaten 2

Vor einigen Tagen hatte ich kurz ueber die Problematik geschrieben, wie man mehrere Debian-Server mit einem Befehl updaten kann. Ich hatte das mit einer kurze for-Schleife in bash gemacht die mir da ausreichte und gesagt ich wuerde mir onall noch einmal genauer angucken.

Heute nacht gabs nun von Debian wieder ein update, libxml2, und mein Nagios blinkte rot. Das hab ich zum Anlass genommen um nun eine „richtige“ Loesung zu implementieren. Es fiel nicht auf onall sondern auf pssh. Der Grund ist ganz einfach, dass pssh bei mir im portage-Tree ist, und onall nicht ;-)

Kurz 2-3 Ueberlegungen vorweg. Ich habe eine ssh-Key Infrastruktur ohne Passwort aufgebaut dafuer. Das ist natuerlich ein Sicherheitsrisiko. Ich empfinde es dennoch als sicher, da die Rechner alle nur in privaten Netzwerken sind bzw., wenn Sie feste IPs haben, via iptables beschraenkt sind. Bei den wichtigsten Servern ist darueber noch der standart SSH-Port veraendert und natuerlich ist der Zugriff ueberall noch per AllowUsers oder AllowGroups (man sshd_config) geregelt… Auch kann ich nur von einem bestimmten Rechner ohne Passwort mit dem entsprechenden Key zugreifen und der ist sicher ;-)

Nun zur eigentlichen Einrichtung:

  • pssh installieren
  • SSH-Key generieren -> ssh-keygen -t dsa -f ~./ssh/myKey
  • den Inhalt von ~./ssh/myKey.pub auf den remote Hosts in ~./ssh/authorized_keys kopieren
  • remote in der ~./ssh/authorized_keys vor den Key einfuegen from=“11.22.33.22″ um den Zugang auf diese IP zu beschraenken
  • remote die /etc/sudoers editieren und folgende Zeile einfuegen:
    USERNAME  HOSTNAME =  NOPASSWD: /usr/bin/aptitude
    wobei USERNAME der Benutzername mit dem key ist und HOSTNAME der hostname des Rechners ist. NOPASSWD muss so als solches stehenbleiben.

Jetzt kann man das ganze einmal testen ob es geklappt hat. Mit ssh USER@IP sollte man sich nun mit dem entsprechenden User auf dem entsprechenden Host ohne Passwort einloggen koennen. Wenn das geklappt hat kann man ausprobieren ob man sudo aptitude upgrade ausfuehren kann ohne Fehlermeldung das man nicht root sei. Geht das beides ohne Probleme nun zu pssh.

Von dem Rechner aus von dem ich nun die Verbindungen zu meinen Servern aufbauen kann muss nun noch einige Kleinigkeiten erledigt werden. Als erstes brauche ich eine Textdatei in der alle hosts drinstehen zu der ich eine Verbindung aufnehmen moechte. Fuer jede IP eine Zeile und bei Bedarf hinter die IP noch mit Doppelpunkt den Port dahinter. Bsp:

11.22.33.44
11.22.33.55:82
11.22.33:66
11.22.33.77:89

Ich habe die Datei einfach in ~/arbeit.ips bzw. eine zweite ~/privsv.ips abgespeichert. Bevor wir nun mit pssh testen koennen ob alles funktioniert bzw. die Updates ausfuehren muss noch der ssh-agent geladen werden mit unserem key. Dafuer einfach in der bash ssh-agent ausfuehren und anschliessend ssh-add. Beides sollte keine Fehlermeldungen ergeben.

Nun ist es soweit. Mit dem Befehl:

pssh -h arbeit.ips -o /tmp/psshtest uptime

koennen wir nun gucken ob alles funktioniert. Es sollte eine Ausgabe kommen ungefaehr so:

me@hostname ~/ $ pssh -h arbeit.ips -o /tmp/psshtest uptime
[1] 09:30:03 [SUCCESS] 11.22.33.44
[2] 09:30:03 [SUCCESS] 11.22.33.55 82
[3] 09:30:03 [SUCCESS] 11.22.33.66
[4] 09:30:03 [SUCCESS] 11.22.33.77 89
me@hostname ~/ $

Der Output des Befehls befindet sich in /tmp/psshtest/11.22.33.* Wenn alles weitere geklappt hat dann happy:

pssh -h arbeit.ips -o /tmp/psshout sudo aptitude upgrade -y

Einige koennen nun ankommen und sagen, dass das doch viel zu kompliziert sei. Mit Sicherheit argumentieren, oder auch damit, dass es doch viel einfachere Tools fuer Debian wie z.B. cron-apt, mit dem ich die Systeme doch auch up-tod-date halten koennte. Meine Antwort darauf ist: Ja, weiss ich. Ja kenne ich. Ich moechte aber immer noch die Updates per Hand einspielen um zu wissen was ich da einspiele.

Virus im Netz / rogue DHCP

Bei uns im Wohnheim machte sich heute ein Virus breit der auch Rechner von Internettutoren infizierte. Der Virus sah so aus, dass man auf einmal falsche DNS-Servereintraege hatte. Die IPs waren dann auf einmal: 85.255.122.36, 85.255.122.41, oder 85.255.122.60. Server aus der Ukraine.

Verschiedenen Internettutoren war das Problem aufgefallen und es wurden dann auch schnell Massnamen ergriffen. Die betreffenden IP-Adressen wurden bei uns in der Firewall gesperrt und nach einer weiteren Diagnose war auch der entsprechende Rogue-DHCP gefunden. Ich war auf der Arbeit leider mit anderen Dingen beschaeftigt und konnte deswegen im Wohnheim nicht „akut“ an der Suche / Diagnose teilnehmen und helfen, aber danke an Alex und Matthias, es hat alles ein gutes Ende genommen.

Mich interessiert nun aber vielmehr: Wie kann ich bei uns im Netzwerk ungewollte DHCP-Server erkennen? Wie kann ich erkennen, wenn ein DHCP-Server unser Netz stoert?

Nach entsprechendem suchen im Internet bin ich dann auf folgendes gestossen:

  1. Rogue DHCP Detection Plugin for Nagios on RedHat
  2. Rouge Detect

Das Nagios Skript ist auf ein englischsprachiges RedHat Linux determiniert, es wird dann an dieser Stelle bald eines geben was auch mit Debian Linux funktioniert. Stay tuned…

Dell Poweredge 2950 – Debian – Perc 6/i – DRAC5

So, mal eben zum festhalten…

  • Dell Open Manage Server Administratior Tools, auch kurz OMSA gibt es fuer Debian dankenswerter Weise von den Leuten von sara.nl ; die direkte Seite dafuer lautet: https://subtrac.sara.nl/oss/omsa_2_deb
  • Eine gute Anleitung zum installieren von den OMSA-Tools gibt es unter http://www.ubergeek.co.uk/blog/2008/05/dell-openmanage-on-linux-debian/
  • Fuer den Perc 6/i integrated RAID/SAS Controler gibt es ein Firmware Update auf 6.1.1-0047, das einige Fehler behebt und erhebliche Performanceverbesserungen verspricht, fuer Linux self-extracting binary gibts da -> http://ftp.us.dell.com/SAS-RAID/RAID_FRMW_LX_R201071.BIN
  • Der megaraid_sas Kerneltreiber unter Debian etch ist fuer zu alt fuer die OMSA-Tools. Deswegen zeigt omreport storage controler den Fehler an, das die der Controler State: Degraded ist. Das betrifft aber nur den Controler und seine Managementoptionen unter diesem Kernel, nicht aber das RAID und dessen Funktionalitaet.
  • Was mich bei den DRAC5 Karten schon immer gestoert hat, ist, dass der WebKVM nur mit dem Internet Explorer ging weil es ueber ein ActiveX Modul realisiert wurde. Bei der DRAC4 wars Java-Applet und damit Platform unabhaengig.
    Inzwischen gibt es ein Firmware Update fuer die DRAC5-Karte auf die Firmware 1.40 das dieses Manko behebt. In der Konfiguration fuer die Konsoleumleitung gibt es nun die Option „Java-Applet“ und es funktioniert wunderbar. Das Firmware Upgrade fuer die Karte gibt es unter http://ftp.us.dell.com/sysman/RAC_FRMW_LX_R197962.BIN

Viele Server updaten

Wer mehr als zwei oder drei Server betreut, den kennt sicherlich das Problem, dass man den Ueberblick ueber den aktuellen Updatestatus der Systeme verliert. Damit mir das nicht passiert nutze ich Nagios mit dem schoenen Plugin check_debian_packages.

Wenn es jetzt ein Update gibt, dann hab ich mich bisher auf jeder Maschine von Hand per SSH eingeloggt und dann die Updates installiert. Ab einem gewissen Zeitpunkt eine sehr zeitaufwendige Geschichte. Zu Zeitaufwendig ab einer gewissen Anzahl zu betreuender Server.

Die Nutzung von Tools wie pssh, cluster ssh, oder onall waere jetzt sicherlich eine Loesung aber da ich keine bestehende ssh-key-infrastruktur zu allen Servern habe und es auch erstmal eine „schnelle“ Loesung tut heute erstmal eine for-Schleife in bash was seine Dienste aber fuer mich erstmal erledigt. onall finde ich interessant und dazu gibts dann spaeter mal was ;-)

#!/bin/bash
SERVERS=“1.1.1.1 2.2.2.2 3.3.3.3″
USR=“USERNAME“

for host in $SERVERS
do
ssh $USR@$host ’sudo aptitude upgrade‘
done