7 Tage zuvor: Spezialist
Eigentlich sollte es ja Certified Linux Administrator heißen, aber Data Center Technical Specialist klingt auch gut:
20 Tage zuvor: Virtuelles ganz physisch
Im Rahmen eines neuerlichen ASUG Florida Chapter Meeting gab es heute eine zutiefst interessante Rechenzentrums-Tour zu sehen: Bei Terremark direkt hier in Miami. Kannte ich das Unternehmen bis vor ein paar Tagen selbst noch nicht, bin ich nun umso mehr von dem beeindruckt, was in ihren Wänden statt findet.
Als Tier-IV Knoten des Internets laufen hier, in Wurfweite der American Airlines Arena die Unterseekabel von circa 160 Telekommunikationsunternehmen zusammen. Die Deutsche Telekom landet hier genauso an wie der Rest Europas. Oder komplett Südamerika. Daher stehen hier auch einige von Verisigns Rootserver für die .com und .net Domains sowie einige der ICANN-Rootserver für .gov und .edu. Und, das muss man durchaus so sagen: Sie sehen verdammt gut aus! Ist der normale Server dazu verdammt sein Dasein in einer anonymen grauen Kiste in einem dunklen Raum zu fristen, sind die Rootserver hübsch angestrahlt und hinter Glasscheiben zur Schau gestellt. Inklusive Status-Monitor mit aktueller Anzahl an DNS-Abfragen pro Sekunde.
Allerdings stelle ich mir jetzt doch noch die Frage, warum meine Verbindungen gen Deutschland nicht über Miami direkt nach Deutschland geroutet werden, sondern den Umweg über Washington gehen:
Tracing route to www.t-online.de [62.153.159.92]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms shar.selune [172.16.0.8]
2 8 ms 12 ms 9 ms 10.156.0.1
3 10 ms 22 ms 12 ms 172.23.80.81
4 14 ms 10 ms 9 ms 172.23.80.1
5 25 ms 25 ms 24 ms xe-5-0-0.edge2.Miami1.Level3.net [4.59.84.49]
6 31 ms 32 ms 36 ms ae-32-52.ebr2.Miami1.Level3.net [4.69.138.126]
7 28 ms 58 ms 30 ms ae-2-2.ebr2.Atlanta2.Level3.net [4.69.140.142]
8 * * 45 ms ae-63-60.ebr3.Atlanta2.Level3.net [4.69.138.4]
9 55 ms 55 ms 67 ms ae-2-2.ebr1.Washington1.Level3.net [4.69.132.86]
10 57 ms 77 ms 48 ms ae-61-61.csw1.Washington1.Level3.net [4.69.134.1
30]
11 44 ms 60 ms 47 ms ae-14-69.car4.Washington1.Level3.net [4.68.17.6]
12 63 ms 50 ms 41 ms 62.156.139.129
13 148 ms 135 ms 140 ms ulm-ea3-i.ULM.DE.NET.DTAG.DE [62.154.58.125]
14 152 ms 139 ms 137 ms 80.156.161.42
15 162 ms 155 ms 138 ms www.t-online.de [62.153.159.92]
Trace complete.
Auf der anderen Seite gibt es hier aber auch einen der drastischsten Gegensätze, die ich bislang sehen musste. Findet in den Wänden diese dedizierten Internet-Knotenpunkts Hightech aus aller Herren Ländern Verwendung, ist also sozusagen die Inkarnation der ersten Welt dort zu Hause, ist an der Rückseite des Gebäudes der Treffpunkt der ärmsten der Armen, die Miami zu bieten hat. Zwischen den den Überresten ihrer Existenz sitzen sie dort zu Dutzenden und harren mit ihrem Schicksal. Ein merkwürdiges Gefühl.
25 Tage zuvor: PHP füttern
Vor geraumer Zeit hatte ich schon mal eine RSS-Reader Klasse in PHP vorgestellt. Wie ich mittlerweile gelernt habe, ist es mit PHP5 nicht mehr nötig selbst dem Code auszulesen und zu interpretieren. Es gibt dort die schöne Klasse DOMDocument, die einem diese Arbeit abnimmt. Und das auch noch recht elegant:
$reader->load($url) || die('Could not read Feed');
foreach($reader->getElementsByTagName('entry') as $item)
$data[] = $item->getElementsByTagName('title')->item(0)->childNodes->item(0)->nodeValue;
Et voilà, man hat alle Titel eines RSS-Feed in seinem Array versammelt. Praktisch! Gedacht ist die Klasse für XML, daher kann man damit noch sehr viel mehr anstellen. Zum Beispiel SOAP. Aber dazu später mehr.
31 Tage zuvor: Vorwärts nach weit
Ein Bild sagt ja angeblich mehr als tausend Worte. Nun, wie verhält es sich da wohl mit Videos?
42 Tage zuvor: Geschmackslehre
Immer wieder lustig:
“Endlich was zu essen!” “Was ist das denn…?”
43 Tage zuvor: GeoIP-Lookup in GeoRSS umwandeln
Um die Frage zu beantworten wie ich denn IP-Adressen in eine Google-Karte bekommen habe: Mittels geoip, GeoRSS und (logisch) Google-Maps. Und zwar folgendermaßen.
geoiplookup <IP> >> geolookup.txtspeichert die Ausgabe in einer Datei.- Mit regulären Ausdrücken extrahiert man die Längen- und Breitenangaben.
- Diese legt man als GeoRSS-Feed ab.
- Den Feed wiederum kann man in Google-Maps importieren.
Fertig ist die Karte. Wer es ein wenig einfacher haben will, kann auch folgendes PHP-Script zum umwandeln der geoip-Ausgabe in einen GeoRSS-Feed nutzen.
// Check for Data
if(!$_POST['geoiplookup']){
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head></head>
<body>
<form method="post" action="<?= $_SERVER['PHP_SELF'] ?>">
<textarea rows="20" cols="50" name="geoiplookup"></textarea><br />
<input type="submit" />
</form>
</body>
</html>
<?php
die();
}
// Setup Variables
$regex = "/^.+Rev 1: ([^,]+), ([^,]+), ([^,]+), ([^,]+), ([0-9\.\-]+), ([0-9\.\-]+), [^,]+, [^,]+$/";
$geodata['line'] = "<entry><title>%s, %s, %s</title><georss:point>%s %s</georss:point></entry>\n";
$geodata['points'] = array();
$geodata['rawdata'] = explode("\n", $_POST['geoiplookup']);
// XML-Special Characters-Function (alonso05 at gmail dot com)
function xml_character_encode($string, $trans=''){
$trans = (is_array($trans)) ? $trans : get_html_translation_table(HTML_ENTITIES, ENT_QUOTES);
foreach ($trans as $k=>$v)
$trans[$k]= "&#".ord($k).";";
return strtr($string, $trans);
}
// Parse input
foreach($geodata['rawdata'] as $data)
if(preg_match_all($regex, $data, $results))
$geodata['points'][] = array(
xml_character_encode(htmlentities($results[3][0])),
xml_character_encode(htmlentities($results[2][0])),
xml_character_encode(htmlentities($results[1][0])),
$results[5][0],
$results[6][0]
);
// Create GeoRSS-Feed
header('Content-type: application/xml');
echo('<?xml version="1.0" encoding="utf-8"?>');
echo('<feed xmlns="http://www.w3.org/2005/Atom" xmlns:georss="http://www.georss.org/georss">');
foreach($geodata['points'] as $point)
vprintf($geodata['line'], $point);
echo('</feed>');
?>
44 Tage zuvor: Digitales Anklopfen
Dass das Internet voller böser Menschen ist, bezweifelt ja mittlerweile niemand mehr. Gestern Abend bin ich zufällig auf einen neuerlichen Ansturm dieser Gruppe gestoßen. Eher zufällig, denn beim begutachten einer kleinen Bandbreiten-Statistik habe ich festgestellt, dass viele (sehr viele) Daten fließen obwohl kein Rechner an ist.
Vorgestern gegen 20:00h hat es angefangen – und erst gegen Mitternacht aufgehört. Nur um dann 14 Stunden später wieder anzufangen und bis dato nicht mehr auf zu hören. Das dazugehörige Verbindungsprotokoll weist die unterschiedlichsten Ports auf, aber man scheint sich von unten nach oben durch-zuarbeiten. Die Vermutung liegt nah, dass es sich dabei um einen Portscan mittels Botnet handelt – wohl dem, der eine Firewall hat! Hier ein kleiner Auszug:
P SHost SPort DHost DPort QoS UDP 98.243.114.146 44698 my_host (vlan1) 13989 Low UDP 86.99.40.148 34185 my_host (vlan1) 13989 Low TCP 71.68.96.135 60260 my_host (vlan1) 61456 Low UDP 98.148.62.215 36126 my_host (vlan1) 13989 Low TCP 64.12.24.34 5190 my_host (vlan1) 49261 Low UDP 189.60.13.108 5620 my_host (vlan1) 13989 Low UDP 208.114.36.253 47502 my_host (vlan1) 13989 Low UDP 71.57.211.118 15711 my_host (vlan1) 13989 Low TCP 64.12.8.93 5190 my_host (vlan1) 49258 Low TCP 68.81.125.25 6415 my_host (vlan1) 61294 Low UDP 65.55.158.116 3544 my_host (vlan1) 53283 Low TCP 24.79.8.42 3701 my_host (vlan1) 56033 Low TCP 69.235.134.90 9585 my_host (vlan1) 56001 Low UDP 90.203.190.82 2800 my_host (vlan1) 13989 Low UDP 67.82.27.105 8224 my_host (vlan1) 13989 Low UDP 82.243.61.53 34095 my_host (vlan1) 13989 Low UDP 69.144.216.97 25070 my_host (vlan1) 13989 Low TCP 65.54.81.24 80 my_host (vlan1) 57724 High UDP 24.144.203.229 32643 my_host (vlan1) 13989 Low TCP 98.110.25.129 34278 my_host (vlan1) 56022 Low TCP 65.55.182.111 80 my_host (vlan1) 56040 High TCP 68.173.253.21 51024 my_host (vlan1) 55996 Low
Oder ein wenig graphischer:
View Scanners in a larger map
45 Tage zuvor: Fern-Fernsehen
Nachdem das ZDF seine Mediathek umgestaltet hat, funktionierte mein schöner Fern-Fernseher leider nicht mehr richtig. Das entsprechende Plug-In wurde nämlich leider nicht auf die neue Struktur umgestellt. Doch wie meinte mein alter Abteilungsleiter (streng genommen war es seine Frau) doch gleich? Darfst kein Depp sein. Ergo, selbst ist der Mann:
d=`date +%y%m%d`
j="/media/public/heute_journal_$d.asx"
h="/media/public/heute_$d.asx"
s="/media/public/heuteshow$d.asx"
rm /media/public/heute_*.asx
wget -qO $j "http://wstreaming.zdf.de/zdf/veryhigh/"$d"_hjo.asx"
[ "$?" -ne "0" ] && \
rm $j
wget -qO $h "http://wstreaming.zdf.de/zdf/veryhigh/"$d"_h19.asx"
[ "$?" -ne "0" ] && \
rm $h
wget -qO $s "http://wstreaming.zdf.de/zdf/veryhigh/"$d"_heuteshow_hsh.asx"
[ "$?" -ne "0" ] && \
rm $s
Das kleine Script läuft bei mir täglich um 18:00h (Mitternacht deutscher Zeit) und lädt die kleinen Streaming-Links herunter. Die wiederum kann XBMC problemlos abspielen. Leider bekommt man so nur die Auslands-Fassung mit (aus rechtlichen Gründen) weniger Beiträgen und an manchen Stellen ohne Bild. Aber immerhin.
46 Tage zuvor: Munin und Tomato
Munin ist eine System-Überwachung für Linux und, nachdem ich meinen Homeserver “neu aufsetzen” durfte, auch meine neue Lösung zur Überwachung des Heim-Netzwerks. Da Munin schön modular aufgebaut ist und den Status mehrerer Systeme zentral zusammenfasst, lag es nur nah auch den Router, der unter Tomato läuft, mit in die Überwachung zu integrieren.
Da es keine Möglichkeit gibt eine Munin-Node nativ unter Tomato laufen zu lassen, muss man auf SNMP zurückgreifen. Denn einen SNMPd gibt es mit integrierten Bibliotheken in kompakter Form bereits fertig zum Download. Nachdem er einmal entpackt ist, kopiert man ihn (über eine CIFS-Freigabe) auf den Router – oder lässt ihn direkt von der Freigabe aus laufen, je nach belieben. In meinem Fall wollte ich ihn auf dem verbleibenden JFFS-Speicherbereich laufen lassen. Dazu muss unter dem JFFS-Punkt Execute when Mounted folgender Aufruf hinterlegt werden:
/jffs/snmpd -c /jffs/snmpd.conf &
Der SNMP-Dienst sollte jetzt laufen. Ein beliebiger SNMP-Client sollte jetzt Daten auslesen können. Eben auch Munin, für das jedoch zunächst die SNMP-Plugins auf dem überwachenden Rechner entsprechend eingerichtet werden müssen. Zunächst legt man eine virtuelle Node in /etc/munin/munin.conf an:
[abeir.selune]
address 127.0.0.1
use_node_name yes
[shar.selune]
address 127.0.0.1
use_node_name no
Anschließend kann man sich mit munin-node-configure --snmp shar.selune --snmpversion 2c --snmpcommunity public die notwendigen Links generieren lassen – einfach die Ausgabe kopieren und entsprechend ausführen. Startet man noch den Munin-Dienst neu (/etc/init.d/munin-node restart) braucht man nur noch ein wenig zu warten und die ersten Daten fließen in die Auswertung mit ein:
53 Tage zuvor: Tages-Planung
Vor nicht allzu langer Zeit erwähnte ich, dass der HP DreamScreen eine tolle Sache sei. Denn er bietet die Möglichkeit Bilder (und Musik) über die integrierte WiFi-Schnittstelle nachzuladen. Soweit, so gut.
Nachdem ich mir Ende November günstig einen zugelegt habe, konnte ich die letzten Tage auch endlich ein wenig intensiver Zeit investieren um ihn für das zu nutzen, für das er gedacht war. Nämlich morgendlich eine Übersicht über all jenes anzuzeigen, was den Tag über so los ist. Ist heute etwas geplant? Was macht Mami? Wer kommt zu Besuch? Wie wird das Wetter? Was ist über Nacht in der Welt passiert?
Das Programm um ein entsprechendes Bild aus diversen Feeds zu erstellen war auch recht zügig geschrieben. Allerdings sind die Grenzen des DreamScreen ein wenig zu eng gesteckt, um das Ziel zu erreichen. Denn es gibt zwar die Möglichkeit Daten drahtlos abzugleichen und Musik direkt aus dem Netzwerk abzuspielen (auch wenn man dazu den Windows Media Player installiert haben muss). Man ist dabei jedoch leider auf Pull-Dienste angewiesen, sprich man muss manuell am DreamScreen die Daten abfragen – eine Push-Möglichkeit, bei der ein Programm ein Bild zur Anzeige an den Bilderrahmen schickt, gibt es nicht.
Damit ist das Projekt also frühzeitig gescheitert. An einer unzureichenden Software-Implementation seitens HP. Auch ein SDK um gegebenenfalls eine eigene Lösung dafür zu entwickeln, gibt es nicht. Dabei läuft der DreamScreen auf einer Embedded Linux Plattform und bietet daher theoretisch alle Funktionalitäten um das gewünschte Verhalten problemlos zu bieten. Zwar offenbarte ein Netzwerk-Sniffer das die Daten mittels SOAP abgeglichen werden, man auf diese Weise vermutlich auch automatisch Bilder hochladen könnte, allerdings fehlen damit immer noch Steuerungsfunktionen wie zum Beispiel ein bestimmtes Bild anzeigen zu lassen.
Bleibt nur zu hoffen, dass HP seine angeblichen Pläne umsetzt und in der Tat grosses aus der ansonsten guten Hardware macht – oder zumindest jemand es schafft Zugang zu dem Linux-System zu erhalten.
