Es gibt eine Menge nützliches Handwerkszeug für den Admin. Hier wird es nicht um die unverzichtbaren „physischen“ Tools wie Gaffatape, Leatherman oder LART gehen, sondern um Software – auf dem eigenen Rechner über Software auf den Servern bis hin zu Monitoringsystemen. Die Auswahl ist groß, aber ein paar Klassiker haben sich bewährt. Hier eine Übersicht der verschiedene Faktoren, die man dabei bedenken muss.
Auf dem eigenen Rechner braucht man an sich nicht viel. Einen guten Passwortmanager (der am besten im Browser arbeitet, aber auch Datenbank-Logins und ähnliches verwalten kann), ein Terminal und einen Browser. Auf Letzteren werde ich nicht näher eingehen, da ich mit Opera immer recht alleine da stehe. Das System der Wahl ist für mich OS X, also beziehen sich alle Empfehlungen auch darauf. Viele der angesprochenen Tools stehen jedoch auch auf der Linux- oder Windows-Plattform zur Verfügung.
Passwortmanager für OS X
Beim Passwortmanager setze ich auf 1Passwort von Agile Web Solutions. Neben dem Plugin für alle gängigen Browser kann er Kreditkarteninformationen, Sql-Logins u.Ä. speichern und mit 1Password auf dem iPhone oder iPad synchronisieren. Auch die Zahlenschlosskombinationen von Racks oder ähnlichem kann man damit gut verwalten, sichere Notizen kann man ebenso anlegen. Bei mir sind inzwischen gut 1.000 Logins drin, die wären im Kopf nicht mehr zu managen. Schon gar nicht zu merken – denn es empfiehlt sich, die sichere Passwortgenerierung von 1passwort zu nutzen.
Terminal für OS X
Nachdem ich viele Terminals ausprobiert hatte, bin ich bei iTerm hängen geblieben. Damit hatte ich keine Encodingprobleme und es beherrscht Tabs, Profile, Bookmarks und vieles mehr.
Konsolenprogramme
Ob lokal oder auf dem Server: Die Wahl der richtigen Shell ist nicht immer einfach. Ich benutze nach wie vor bash, weil ich sie gut kenne. Mein Kollege schwört auf zsh, so sind die Geschmäcker verschieden. Meine Shell ist bunt und zeigt die Uhrzeit an, damit ich z.b. im Screen weiß, wann die letzte Aktion war. Dazu in der .bashrc einfach die folgende Zeile fürs Prompt wählen:
PS1='\t \[\033[01;36m\]\h \[\033[01;33m\]\w \[\033[01;35m\]\$ \[\033[00m\]'
Im Screen habe ich auch gerne Zeit und Datum in der Statuszeile, dazu die Fensternamen und die lokale Load. Gerade wenn man lokal einen Screen startet und darin die Screens der einzelnen Server, hilft diese Konfiguration dabei, nicht den Überblick zu verlieren. Die .screenrc dazu ist
hardstatus alwayslastline
hardstatus string "%{Yb}%-w%{} %{kr} %n %f %t %{-} %+w %=%H %{kg} %l %{-} %Y/%m/%d %c:%s "
nethack on
defnonblock 1
Beim Schachteln muss man ein ^a voranstellen, um die nächste Screen-Ebene zu erreichen. In diesem Beispiel läuft der eine Screen lokal auf „powermoo“, der zweite remote auf „heaven“. Um auf „heaven“ ein Fenster hinzuzufügen, muss ich also ^a a c eingeben und kann es mit ^a a n umbenennen.
Im Screen sieht man htop, eine etwas gefälligere top Version, welche die aktuelle Auslastung der Systemressourcen und laufende Prozesse ganz gut darstellt. Aber eben nur den aktuellen Stand, womit wir beim nächsten Punkt wären.
Monitoring
Um zu sehen, warum ein System gehangen hat, hilft natürlich ein Blick in die Logs. Ebenso hilfreich als die eigentliche Log-Analyse ist es, die Ereignisse im Kontext, verglichen mit anderen Servern sowie grafisch aufbereitet zu sehen. Dabei hilft zum Beispiel Cacti, welches per snmp Daten von den Servern holt und diese mittels RRDTool aufbereitet. Man sieht in dieser Grafik, wie die Lastprobleme begannen, als ein Projekt auf den Webserver gezogen wurde, und wie sie endeten, als es wieder vom Server entfernt wurde.
Wir überwachen bei allen Server load, cpu usage, RAM usage und Traffic pro Interface, dazu noch serverspezifische Daten. Auf Webservern sind das beispielsweise noch Hits/s und thread usage.
Um gewarnt zu werden, wenn etwas passiert, nutzen wir Nagios. Das etwas betagte Monitoringsystem tut gute Dienste und ich weiß, wie es funktioniert. Aber alleine eine Jabber-Benachrichtigung muss man beispielsweise mit ein paar Scripten einbinden. Die Configs sind nicht selbsterklärend und am Anfang flucht man etwas. Inziwschen gibt es einige vielversprechende Projekte, welche ich nur getestet und noch nicht produktiv verwendet habe, zum Beispiel zabbix.
Werkzeuge
Zu guter Letzt kommen dann noch die allgemeinen Werkzeuge – Scriptsprache nach Wahl (Bash und Perl sind immer eine gute Wahl 😉 ). Ansonsten sollte man awk, grep, sed, man, netstat, fuser und kill kennen. Irgendwann findet man dann in Scripten historisch gewachsene Zeilen wie
netstat -ant|grep SYN_RECV |awk '{split($5,a,":"); print a[1]}'|sort|uniq -c|awk '{print ($1";"$2)}'
In diesem Fall wird nachgesehen, von welchen IP-Adressen ein Synflood ausgeht. Die Ausgabe kann ein anderes Script direkt parsen und in die iptables werfen.
