12. April 2010
Immer mal wieder benötige ich eine Reihe neuer Passwörter. Da ich zu faul bin diese selbst zu generieren, lasse ich das besser machen. Dafür kann man z.B. makepasswd verwenden. Für die Bereiche wofür ich die Passwörter brauche reicht mir eine übliche Entropie völlig.
Da ich Gnome benutze habe ich mich gefragt, ob es nicht eine einigermaßen elegante Möglichkeit gibt, die generierten Passwörter “grafisch” auszugeben.
Gibt es: zenity ist ein Tool mit dem man von der Kommandozeile aus verschiedene Dialoge zur Interaktion mit Scripten etc. öffnen kann. So gibt es z.B. Messageboxen, Textabfragen etc. Eine gute Übersicht findet sich hier. Ich habe mich für die Listenansicht entschieden, da man dort einfach per Copy+Paste an den Text kommt. Hier das komplette Kommando:
makepasswd --count 24 | \
zenity --list --editable --title "Passwörter" --column Password --height 400
23. März 2010
Möchte man die Daten von Cluster-Nodes auf einem gemeinsamen Stand halten gibt es viele Möglichkeiten. Handelt es sich um eine Read-Only Anwendung werden die zugehörigen Dateien meist über einen Master gepflegt und von dort verteilt. Dafür kann man z.B. rsync nehmen – periodisch ausgeführt synchronisiert es zuverlässig die Nodes mit dem Master. Das Problem mit rsync: Die Synchronisation findet nur periodisch statt und nicht live. Außerdem ist bei größeren Datenmengen die Last während der Synchronisation recht hoch.
Warum also nicht nur das synchronisieren was auch synchronisiert werden muss? Genau dafür gibt die inotify-Schnittstelle am Linux-Kernel. Mit entsprechenden Tools überwacht es ganze Dateibäume auf Änderungen und führt bei Bedarf Aktionen aus.
Also habe ich mir ein Script gebastelt welches 1. ein bestimmtes Verzeichnis überwacht und 2. nur die geänderten Dateien/Verzeichnisse unmittelbar mittels ssh verteilt. Voraussetzungen: ssh, scp und inotifywait (enthalten bei den meisten Distributionen im Paket “inotify-tools”). SSH sollte über public keys authentifizieren. Im Kopf von inotifysync.sh müssen die Ziel-Nodes eingetragen werden (diese ändern sich wohl nicht so häufig). Alternativ kann auch eine Datei mit den Ziel-Nodes verwendet werden.
Download: inotifysync.sh
Folgendes Beispiel überwacht das Verzeichnis /home/cluster/htdocs auf Änderungen und synchronisiert diese in das Verzeichnis /var/www/cluster/htdocs auf dem jeweiligen Node:
./inotifysync.sh /home/cluster/htdocs /var/www/cluster/htdocs \
>> /home/cluster/log &
Die Logausgaben werden in die Datei /home/cluster/log geschrieben und das ganze mittels “&” in den Hintergrund geschickt.
Hinweis: Etwas bash Erfahrung sollte man beim Einsatz dieses Scripts schon haben. Einsatz erfolgt natürlich auf eigene Gefahr 
9. März 2010
In letzter Zeit habe ich das Mediawiki als zentrale Managementplatform entdeckt. Eigentlich war es bisher lediglich zu Dokumentationszwecken gedacht. Dadurch, dass es aber eine einfach zu nutzende XML-Exportfunktion bietet, lassen sich damit auch noch andere Dinge anstellen (oder Kombinieren). Man kann damit z.B. prima eine Nodeliste für OpenNMS verwalten (welche nicht durch autodiscovery erfasst werden). Oder gewisse Steuerungsdaten für Bash-Scripte. Oder was auch immer. Zumindest für Aufgaben wofür es sich nicht lohnt ein eigenes Interface zu stricken.
Bisher habe ich zentrale Einstellungen immer relativ mühsam in ein SVN gesichert. Zugriff für Änderungen war meist nur über die SSH Konsole möglich. Dokumentiert wurde da auch nicht viel…
Das schöne am Mediawiki ist, dass eine Versionierung schon eingebaut ist. Ausserdem lassen sich z.B. Dokumentationen oder Checklisten verlinken. Durch Kategorisierung lassen sich die Daten auch geordnet ablegen. SSL und Authentifizierung sollten natürlich selbstverständlich sein.
Per simplen wget in bash-scripten oder per curl in in perl/php ist der Zugriff in der Regel problemlos möglich. Das xml lässt sich prima mit dem Tool “xml2″ in Scripten verarbeiten…
Beispiel zum Einlesen einer Liste mit IP-Adressen:
wget -q -O - --http-user admin --http-passwd secret \
https://wiki.example.com/index.php/Spezial:Exportieren/IP_Plan \
| xml2 \
| awk '/(page\/revision\/text)*([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)/ {print $2}'
15. Dezember 2009
Autodiscovery in OpenNMS ist ein tolles Feature. Leider ist es nicht immer zu gebrauchen, da es derzeit nur begrenzt konfigurierbar ist. So möchte ich z.B. in einem bestimmten Netzbereich nur die jeweiligen Router der Teilnetze abfragen – und nicht alle Hosts auf Services scannen. Klar kann man auch Bereiche excluden bzw. includen – aber ich wollte ja Autodiscovery .
In der kommenden OpenNMS Version 1.8 sollen die Discovery bzw. die Capability-Checks (capsd) von einem neuen Daemon (“provisiond”) abgelöst werden welcher sich wohl auch besser an eigene Bedürfnisse anpassen lässt – z.B. ist als nettes Feature dann z.B. auch der Import von DNS-Zonen möglich. Dies aber nur Nebenbei.
Auf der Suche nach einem alternativen Import bin ich bei XML gelandet. Da die zu überwachenden Hosts in einem internen Wiki (Mediawiki) gepflegt werden, stehen diese über die eingebaute Export-Funktion auch als XML zur verfügung. So ist z.B. der OpenNMS Artikel bei Wikipedia auch als reines XML verfügbar: http://en.wikipedia.org/wiki/Special:Export/OpenNMS.
Ein cooles Tool zum verarbeiten von XML auf der Kommandozeile ist “xml2” (in vielen Distro-Repositories verfügbar). Kombiniert mit ein paar regulären Ausdrücken landen die richtigen IPs in einer Datei für den automatischen Import in OpenNMS:
wget -q -O - --http-user admin --http-passwd secret \
http://wiki.example.com/index.php/Spezial:Exportieren/IP_Plan \
| xml2 \
| awk '/(page\/revision\/text)*([0-9]+\.[0-9]+\.[0-9]+\.[0-9]+)*(NMS:host)/ {print $2}' \
> /opt/include-hosts Weiterlesen
8. Dezember 2009
Bei etlichen Routern die snmp-Community per telnet zu setzen kann mühsam werden. Ein Script muss her. Das telnet-Kommando ist anscheinend so nicht gut dafür geeignet um eingaben von STDIN zu verarbeiten. Durch google bin ich darauf gekommen, dass viele es mit “expect” lösen. Hier mein Script:
#!/bin/bash
for host in `cat /root/hosts` ; do
expect << EOF
spawn telnet $host
expect "Login: "
send "admin\r"
expect "Password: "
send "secret\r"
expect -exact "-->"
send "snmp set communityname xxx manager xxx\r"
expect -exact "-->"
send "user logout\r"
EOF
done;
Die Hosts stehen in der Datei /root/hosts. Je in einer Zeile.
12. September 2009
Nachdem ich meine Platten jetzt schlafenlegen kann, würde ich auch gerne wissen wann und ob dies erfolgt…
# Usage
Output state:
./check_hdd_spindown.sh /dev/sda /dev/sdb /dev/sdc
Log state into file:
./check_hdd_spindown.sh /dev/sda /dev/sdb /dev/sdc >> /var/log/spindown.log &
#!/bin/sh
while [ 1 ]
do
i=0
for DRIVE in $*
do
DATE=`date +"%Y-%m-%d %H:%M:%S"`
RESULT_OLD=${RESULT[i]}
RESULT[$i]=`hdparm -C $DRIVE | grep state`
if [ "$RESULT_OLD" != "${RESULT[i]}" ]
then echo $DATE $DRIVE ${RESULT[i]}
fi
i=$i+1
done
sleep 5
done
14. Mai 2009
Oh man, wie oft vergesse ich das noch…
Ersetzt “tabelle1″ durch “tabelle2″ in der Datei dump.sql:
sed -i -e 's/tabelle1/tabelle2/' dump.sql
Ersetzt in allen PHP-Dateien rekursiv den String “name1″ durch “name2″ – aber nur in den Zeilen wo der String “user” vorkommt:
find . -type f -name "*php" -exec sed -i -e '/user/ s/name1/name2/' {} \;
20. Februar 2009
Plesk kann seit Version 8.6 auch mit RIPE-Konformen Zonen-Serials umgehen. Um in einem Rutsch sämtliche Domains auch einem Server auf das neue Format umzustellen reichen folgende Befehle (vorher Backup anlegen!):
Neue Serial setzen (natürlich auf aktuelles Datum anpassen):
mysql -Ns -u admin -p`cat /etc/psa/.psa.shadow` -D psa \
-e "UPDATE dns_zone SET serial_format = 'YYYYMMDDNN', serial = '2009022000' "
Alle Zonen im Bind updaten:
mysql -Ns -u admin -p`cat /etc/psa/.psa.shadow` -D psa \
-e 'SELECT name FROM dns_zone' \
| awk '{print " /usr/local/psa/admin/sbin/dnsmng update " $1}' | shDen zweiten Befehl habe ich hier abgeleitet. Da einige Programme keine Argumente über die Standardeingabe (stdin) annehmen (oder mangels Dokumentation nicht klar ist, ob sie das tun) finde ich es eigentlich ganz elegant, das Kommando mittels awk zusammenzubauen und dann zeilenweise auszuführen.
10. Februar 2009
Auf Shared-Hosting Systemen werden Typo3-Installationen meist mittels Symlinks zu einer einzigen Typo3_src Installation verlinkt. Aus Kompatibilitätsgründen gibt es aber oft unterschiedliche Versionen parallel auf einem Server.
Aus aktuellem Anlass wollte ich herausfinden, welche Versionen noch auf dem Server laufen:
find /var/www -name typo3_src -type l \
-exec /bin/sh -c "ls -l {}" \; | awk '{printf "%35-s %s\n", $11, $9}'
PS. Den awk-Kram kann man auch weglassen – ich finde es aber so übersichtlicher.
7. Januar 2009
“find” ist noch mächtiger in Zusammenhang mit dem “-exec” Parameter – bisher war mir aber nicht klar wie man eine Pipe innerhalb des -exec Abschnitts benutzen kann:
find . -type f -exec sh -c 'cat {} | grep "hello world"' ;Der Trick ist eine Shell (in diesem Falle “sh”) aufzurufen. Das Kommando oben ist nur ein Beispiel und macht natürlich keinen Sinn .