Posts Tagged ‘MD5’

Sonntag, 9. Juni 2013

SNMP unter Mac OS X 10.8 Mountain Lion aktivieren

Mac OS X 10.8 (Mountain Lion) bringt Out-of-the-box alles mit, um einen SNMP-Server bereitzustellen. In Verbindung mit cacti zeichne ich so in Echtzeit Systeminformationen meines Mac minis, MacBook Airs und Stephanies Mac mini auf.

Wer Rechner ausschliesslich in seinem heimischen LAN betreibt, kann nachfolgende Minimal-Konfiguration einrichten, damit cacti auf einem Drittserver per SNMP v1 und ohne Passwort darauf zurückgreifen kann:

/etc/snmp/snmpd.conf (Desktop-Rechner)

sysContact  Vorname Nachname 
sysLocation Strasse Strassennummer, PLZ Ort

rocommunity public

includeAllDisks 10%
load    30 10 5

Auf einem portablen Gerät würde ich SNMP abriegeln und den Zugriff nur mittels Benutzernamen und Passwort zugänglich machen. Verwendet man obige Lösung, kann im Flughafen-WiFi oder im Uni-WiFi jedes Script-Kiddie mit nmap-Portscans auf den SNMP-Server aufmerksam werden und mehr oder weniger sensitive Informationen abrufen.

Hierzu eignet sich folgende Konfiguration:

/etc/snmp/snmpd.conf (portabler Rechner)

createUser <username>     MD5 "<password>" DES "<secret>"
authuser   read -s usm  <username> priv  .1

sysContact  Vorname Nachname 
sysLocation Strasse Strassennummer, PLZ Ort

includeAllDisks 10%
load    30 10 5

Sowohl password als auch secret können frei gewählt werden (alphanumerische Zeichenfolge).

Quelle: Setup SNMP V3 USM with encryption.

Daemon (neu) starten

Nach der Konfigurationsanpassung heisst es, den SNMP-Server (neu) zu starten. Dies habe ich mit folgendem Script automatisiert:

#!/bin/sh

echo "Stopping SNMP daemon ..."
sudo launchctl unload /System/Library/LaunchDaemons/org.net-snmp.snmpd.plist

echo "Starting SNMP daemon ..."
sudo launchctl load -w /System/Library/LaunchDaemons/org.net-snmp.snmpd.plist

exit 0

Daemon bei jedem Neustart von Mac OS X laden

Hierzu habe ich die von Apple mitgelieferte plist-Datei /System/Library/LaunchDaemons/org.net-snmp.snmpd.plist angepasst:

	<key>Disabled</key>
	<false/>

Tags: , , , , , , ,
Labels: Linux, Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 22. Mai 2013

Konkurrenz-Probleme in PHP

In den letzten Wochen habe ich intensiv an meinem Raspberry Pi-Dashboard für unser Apartment geschraubt und gebastelt. Verschiedene Tiles werden mittels AJAX-Requests, welche über jQuery abgesetzt werden, mit Inhalten versorgt — und dies regelmässig alle paar Minuten.

Ein mysteriöser Bug machte mir in den letzten Tagen das Leben schwer: Es konnte vorkommen, dass zwei Tiles mit den Aktienkursen desselben Unternehmens gefüllt wurden, obwohl die Tile-IDs unterschiedliche ISINs trug.

Nach einigen Minuten Debugging schwante mir dann plötzlich, was das Problem war: Der auf dem Server lokal zwischengespeicherte HTML-Cache war zwar in Dateien mit der richtigen ISIN im Dateinamen abgelegt — der Inhalt war aber identisch. Konkret enthielt die HTML-Datei über das Unternehmen AAPL die Daten für das Unternehmen GOOG.

Wie sich heraustellte, hatte ich mein Script nicht dermassen intelligent programmiert, dass es mit mehreren, nur wenige Millisekunden auseinanderliegenden Requests ordnungsgemäss umging. Um nämlich den Aktienkurs einer ISIN abzufragen, muss dieser zuerst über einen HTTP-Request an ein Suchscript meines unfreiwilligen Kursanbieters in eine vom Anbieter intern verwendete NOTATION_ID umgewandelt werden (was wissbegierigen Lesern dieses Blogs einen Hinweis gibt, von welcher Web-Site ich die Kursdaten beziehe). Erst danach kann ich die Informationsseite des auf dem Aktienmarkt gehandelten Unternehmens aufrufen, herunterladen und im lokalen Dateisystem ablegen.

Konkret war mein Fehler, dass ich die Suchergebnisse zur Umwandlung der ISIN in die NOTATION_ID in eine Cache-Datei mit statischem Dateinamen ablegte. Da die Requests mit wenigen Millisekunden Versatz beim Server ankamen, war die Cache-Datei manchmal bereits von einem späteren Request überschrieben worden, als ich den HTML-Code endlich in PHP einlesen wollte (ich denke, dass wir hier von einigen wenigen hundert Millisekunden sprechen). Dies führte dazu, dass ich einer ISIN fälschlicherweise die NOTATION_ID des nachfolgenden Requests zuwies und diese plötzlich für zwei Kursanbieter galt. Da ich dieses Mapping aus Performance-Gründen ebenfalls serialisiert in einer Cache-Datei ablegte, wurden ab diesem Zeitpunkt zwei Tiles mit identischen Inhalten befüllt.

Die erste Lösung, dem Dateinamen einen sich ständig ändernden Wert einzupflegen, scheiterte grandios, weil ich time() verwendete. Da die Requests innerhalb der selben Sekunde auf dem Server eintreffen konnten, konnte die Cache-Datei im schlimmsten Fall weiterhin vom nachfolgenden Request überschrieben werden. Die zweite Lösung war deshalb, durch das Einfügen einer mittels rand(1000,9999) definierten Zufallszahl einen wahrlich zufälligen Wert in den Dateinamen einzuschleusen. Die Chancen, einen identischen Cache-Namen zu erwischen, ist hier 1:10000 — good enough, würde ich sagen.

Natürlich hätte ich auch einfach die ISIN in den Namen der Cache-Datei aufnehmen können. Hier hegte ich aber Zweifel, weil ich nicht wollte, dass bei einem Downloadfehler einfach unbemerkt die bestehenden, veralteten Daten eingelesen würden.

Tags: , , , , , , ,
Labels: Programmierung

1 Kommentar | neuen Kommentar verfassen