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
OpenNMS ist klasse. Man merkt an vielen Stellen, dass es von Anfang an für große Netze konzipiert wurde. Das hat den “Nachteil” dass einiges u.U. auf dem ersten Blick etwas umständlich wirkt. Ein Beispiel dafür sind z.B. die Filter. Anfangs habe ich diese nicht beachtet und diverse Parameter lieber händisch im Webinterface eingestellt oder viel mit IP-Ranges bei den Pollern gearbeitet.
Eines der Hauptprobleme war, dass OpenNMS immer alle Interfaces auf einem Server bei seinen Service-Checks einbezieht. Also z.B. den SSH-Dienst auf einem Webserver mit 30 virtuellen Interfaces auf jedem dieser Interfaces checkt. Das ist sinnlos. Beholfen habe ich mich damit, dass ich im Webinterface die ensprechenden Interfaces auf “unmanaged” gesetzt habe oder die IP-Ranges bei den Checks eingeschränkt habe. Wenig elegant.
Wie schön sind dagegen doch die Filter. Kennt man sich ein wenig mit SQL aus, hat man das Prinzip dahinter schnell erkannt. Hinter OpenNMS arbeitet eine PostgresSQL-Datenbank welche die Interfaces, Kategorien, Events etc. verwaltet. Mit den Filtern kann man prinzipiell jedes Feld in dieser Datenbank abfragen und so z.B. die zu pollenden Interfaces bestimmen.
Soeben wollte ich einen Windows-Server aus der Ferne rebooten weil ich per RDP nicht mehr dran kam. Hat man den Samba-Client installiert ist das über die Windows-RPC Schnittstelle kein Problem:
net rpc SHUTDOWN -r -f -I 192.168.1.3 -U Administrator
Jeder Entwickler baut sich wohl seinen eigenen Debug-Modus für seine Anwendungen. Bisher habe ich bei Webanwendungen meist GET Parameter verarbeitet. Mit den prinzipbedingten Nachteilen – z.B. Tracking über mehrere Seiten. Andere Variante ist per Config-Variable den Debugmodus einzuschalten. Oder abhängig von der Source-IP. Oder wie auch immer.
Eine andere Methode habe ich mir von Google abgeschaut: Setzen von Spezialmodi per Cookie über die Adressleiste des Browsers. Google hat schon des öfteren neue Funktionen zunächst nur für einen “eingeweihten” Nutzerkreis zugänglich gemacht. Eingeschaltet wurde die Funktion dann über ein spezielles Cookie. Gesetzt wurde dieses einfach über die Adressleiste des Browsers. So hat z.B. die folgende Eingabe in der Adressleiste auf google.com das “suggest” Feature eingeschaltet:
javascript:document.cookie= "PREF=ID=175eb54605c0202d:U=a14f58424228a2a5:LD=en: NR=10:CR=2:TM=1240146048:LM=1242596928:DV=AA:GM=1:IG=1:S=zW53HscJwnEL89bQ; path=/;domain=.google.com";void(0);
Mittlerweile verwende ich auch immer öfter dieses Verfahren:
javascript:document.cookie="xyz_debug=1";window.location.reload();
Das so gesetzte Cookie mit dem Namen “xyz_debug” kann man dann einfach mit bekannten Funktionen serverseitig auswerten (hier PHP):
if ($_COOKIE["xyz_debug"]) { var_dump($_POST); }
Natürlich sollte das verwendete Cookie nicht leicht zu erraten sein. Ich wüste gerne wie viele Debugausgaben in den weiten des Internets darauf warten über versteckte Zugänge, Parameter etc. abgerufen zu werden 
Wieder 2 Stunden bei der Fehlersuche verplempert…
$string = "X20"; echo (strpos("XYX20", $string) !== false) ? "JA" : "NEIN"; $string = 20; echo (strpos("XYX20", $string) !== false) ? "JA" : "NEIN";
Output:
JA NEIN
Erwartet hätte ich 2x “JA”. Leider habe ich nicht in die Doku zu strpos geschaut – hätte mir einiges an Zeit für die Fehlersuche erspart. Es ist aber immer so: Die Funktion strpos habe ich schon 1000 Mal verwendet und den Fehler definitiv nicht dort vermutet.
So geht’s:
$string = 20; echo (strpos("XYX20", (string)$string) !== false) ? "JA" : "NEIN";
Merke: gerade die viel gelobte/gehasste vermeintlich dynamische Typumwandlung von PHP stellt einem oft ein Bein.
Die neueste Version von Piwik (0.5.5) liefert jetzt ein Plugin (“AnonymizeIP”) für die Anonymisierung von IP-Adressen mit. Dieses muss nur in den Einstellungen aktiviert werden.
Die genaue Rechtslage zur Speicherung von kompletten IP-Adressen zu Statistikzwecken ist meines Wissens noch unklar. Der Düsseldorfer Kreis empfiehlt allerdings diese nicht zu speichern (siehe hier).
Für mein Blog habe ich jedenfalls Google-Analytics abgeschaltet und bei Piwik das entsprechende Plugin aktiviert… Ehrlich gesagt habe ich (für das Blog) eh nie in Google-Analytics reingeschaut und immer nur Piwik verwendet.
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
Fatal error: Maximum execution time of 30 seconds exceeded in C:\Inetpub\vhosts\xxxxxxx\httpdocs\cms\include\inc_front\front.func.inc.php(2365) : eval()’d code on line 7
Oben stehende Meldung kam soeben auf einer nicht allzu kleinen Webseite.
)