Eine etwas andere Suchmaschine ist TinyEye. Man lädt ein Foto hoch (oder gibt den Link zu selbigem an), und TinyEye sagt einem dann, wo genau dieses Bild noch auftaucht. Um mal eben zu checken, ob sich jemand mit fremden Fotos schmückt (Gerade in den Printmedien sehr beliebt – ich sag nur “Quelle: Internet”) eignet sich das Ding prima. Ca. 1,7Mrd. Bilder sind dort indiziert. Als Sahnehäubchen kann man tinyeye auch via REST-API ansprechen.
…für diese Zwecke haben sich die Redmonder Sadisten was ganz besonderes ausgedacht. Den RIS (Remote Installation Service).
Kurzbeschreibung:
- - Per DHCP wird dem Opfer eine IP zugewiesen und mitgeteilt das er doch bitte via PXE (Netboot) booten solle
- Ein TFTP Server hält dem Opfer-PC dann eine speziell präparierte WinXP-Installations-CD unter die Nase
- Von dieser muss das Opfer nun, ob es will oder nicht, booten, um anschliessend…
- … per SMB/CIFS das Elend (Win$uxx XPerience) zu installieren.
So weit die Theorie. Die Praxis sieht wie üblich bei KleinShit etwas anders aus. Weiterführende Informationen gibt Ihnen Ihr Psychiater, oder dieser Link hier…
Args !
Die Thickbox Library als solches ist ganz nett. Mit Hilfe des Frameworks, welches auf jquery aufsetzt, kann man wunderbare Layer-PopUps basteln (Ja, die braucht man auch schonmal ausserhalb der Werbebanner-Welt). Das Ding ist ziemlich ausgereift, und beisst sich auch nicht mit meinem CGI::Ajax Modul. Einzig der Superbrowser aus Redmond in der Version 6 (InternetEplorer 6 / IE6) macht, wie könnte es anders sein, Probleme !
Das Handling von Seitenbreite und Seitenhöhe dieser Browserwurst kommt nämlich bei dynamisch nachgeladenen Bildchen durcheinander. Soll heissen: Ist die Seite nach dem Laden eines img’s Breiter als vorher, dann behält der Internet Exploder 6 stur die alte Seitenbreite. Da nun Thickbox die PopUps aber immer mittig platzieren will (Mitte = Seitenbreite / 2) passt hier nun garnichts mehr.
Wenn man in der Thickbox.js die Funktion tb_position durch folgendes, mühsam erarbeitetes, Stückchen Kot ersetzt, dann klappts auch mit dem Internet Exploiter…
function tb_position() {
var scrolledX = $(document).scrollLeft()
if ( !(jQuery.browser.msie6)) { // take away IE6
$("#TB_window").css({marginTop: '-' + parseInt((TB_HEIGHT / 2),10) + 'px'});
$("#TB_window").css({marginLeft: '-' + parseInt(( (TB_WIDTH) / 2),10) + 'px', width: TB_WIDTH + 'px'});
} else { // Krankheit aus Redmond !!! Friss dieses:
$("#TB_window").css({marginLeft: parseInt(( (-1)*(TB_WIDTH) / 2)+scrolledX,10) + 'px', width: TB_WIDTH + 'px'});
}
}
… für Menschen denen selbst das Benutzen von Google zu kompliziert ist. Frage eingeben, Link kopieren, und beim nächsten mal kommen garantiert keine Fragen mehr
Guckst Du hier: http://lmgtfy.com/
Schade, bis vor ein paar Wochen konnte ich das KabelModem von Unitymedia noch per snmp auslesen und den Traffic dann per CACTI visualisieren. Anscheinend hat Unitymedia den SNMP-Port nach innen hin dichtgemacht…
Ansonsten könnte ich mir das nicht erklären:
router:~# snmpwalk -Os -c public -v 1 192.168.100.1
Timeout: No Response from 192.168.100.1
router:~# curl 192.168.100.1
[...]
Scientific-Atlanta Cable Modem
[...]
router:~#
Aufmerksam geworden durch diesen Artikel, mit dem ueber den Proxy geholte Webseiten (genauer gesagt werden alle Images einmal um 180 Grad gedreht) on the Fly manipuliert werden habe ich mir das ganze mal näher angesehen und optimiert.
Vorweg schonmal das Ergebnis (funktioniert TRANSPARENT mit allen JPGs, GIFs und PNGs). Transparent bedeutet in diesem Falle, dass der Anwender in keinerlei Weise mitbekommt, dass es sich hier um ein manipliertes Bild handelt. Die Requests werden quasi 1:1 durchgeleitet.
Wor moechten also alle Bilder, die aus dem LAN via Proxy angefordert werden, einmal um 180 Grad drehen. Folgende Ausgangssituation:
- Transparenter Squid auf einem Router
- Webserver auf einem etwas dickeren Rechner im LAN
in /etc/squid/squid.conf folgende Zeile einfügen:
url_rewrite_program /usr/bin/updwn.pl
url_rewrite_children 5
Das File /usr/bin/updwn.pl sollte wie folgt aussehen:
#!/usr/bin/perl
# Runs as proxy:proxy
# input - siehe unten (Array params)
# output - URL - transparent *invisble to Enduser
*
$|=1;
while (<>) {
chomp $_;
@params=split(/ /,$_);
# 0 = Request URL
# 1 = Requesting IP/-
# 2 = -
# 3 = Request Method
# 4 = myip= ?
# 5 = myport = ?
$url=$params[0];
if (!($params[1]=~/192\.168\.60\.200/)) { # Nicht rekursiv aufrufen (Boese !!)
$url='http://192.168.60.200/ppics/updwn.pl?u='.$url if ( ($url=~/gif/i) || ($url=~/jpg/i) || ($url=~/jpeg/i) || ($url=~/png/i));
}
print $url."\n";
$count++;
}
Wobei die 192.168.60.200 durch die IP des eigenen Webserver zu ersetzen waere. Die eigentliche “Magie” findet naemlich jetzt im updwn.pl auf dem Webserver statt. Das Ding benutzt, im gegensatz zu dem File, welches in dem Artikel beschrieben wurde, direkt die GD-Library und ruft keinerlei Executables mehr auf. Damit ist das Script ein wenig performanter
Hier der Inhalt von /var/www/ppics/updwn.pl:
use CGI qw/:standard/;
use LWP::UserAgent;
use GD;
binmode STDOUT;
$|=1;
my $url=param(“u”);
chomp $url;
my $ctype=”;
my $content=”;
get_content($url,\$ctype,\$content);
rotate(\$content,\$ctype) if ($ctype=~/image/i);
print “Content-Type: “.$ctype.”\n\n”;
print $content;
print “\n–magicalboundarystring\n” if ($ctype=~m/image/);
sub get_content {
my ($url,$ref_ctype,$ref_content)=@_;
my $ua = LWP::UserAgent->new;
$ua->agent(“MyApp/0.1 “);
my $req = HTTP::Request->new(GET => $url);
my $res = $ua->request($req);
$$ref_ctype=$res->content_type;
$$ref_content=$res->content;
}
sub rotate {
my ($ref_content,$ref_header)=@_;
my $image=undef;
$image=newFromPngData GD::Image($$ref_content) if ($$ref_header=~/png/i);
$image=newFromJpegData GD::Image($$ref_content) if ($$ref_header=~/jpeg/i);
$image=newFromGifData GD::Image($$ref_content) if ($$ref_header=~/gif/i);
$image->rotate180();
$$ref_header=’image/png’;
$$ref_content=$image->png();
}
Wichtig: Die URL sollte nicht aus dem Internet erreichbar sein. Ansonsten hat man einen selbstgebastelten offenen Proxy…
Mithilfe der Parameter des Files /usr/bin/updwn.pl kann man sich jetzt sogar lustige ACLs bauen. (Rotiere nur fuer bestimmte IP’s oder fuer bestimmte URLs, etc…) Der Phantasie sind da keine Grenzen gesetzt.
Wer soetwas in seinen Access Logs als Refrerrer sieht kann sich wundern, muss er aber nicht
http://127.0.0.1:4664/preview?event...
Der Referrer kommt naemlich von der Google-Desktop Suche. Also: Wieder schlauer geworden
Man kennt das. Gerade frisch einen Postfix aufgesetzt, eine Testmail losgelassen und Zaaack! – das Ding will nicht rausgehen. Jetzt dümpelt die Mail bis zum Timeout in der Queue herum. Abhilfe habe ich früher geschaffen in dem ich mir via mailq die Mail-ID herausgekramt habe und dann mühsam durch die spool Directories gegangen bin um ein File nach dem anderen zu löschen. Es geht eleganter:
mailq aufrufen um die Mail-ID zu bekommen
und anschliessend nur noch “postsuper -d <mail-id>” aufrufen um die Mail zu töten. Fertig….
Ja, die meisten werden es kennen. Nur so vergesse ICH das garantiert nicht mehr
Mit bind geht das schon lange. Man hat 2 Netze, mit jeweils zwei unterschiedlichen Nameservern die die privaten Adressen im jeweiligen LAN auflösen. Will man jetzt, z.B. via VPN beide Nameserver aus den jeweiligen LANs nutzen, so konfiguriert man den bind für die jeweiligen Netze als forwarder (Jeweils für das Netz mit seinem Nameserver einen Eintrag). Ein Beispiel:
Gegeben seien ein LAN mit der Domäne Intranet1.de und dem Nameserver 192.168.0.222, und das LAN mit der Domain intranet2.de welches seinen DNS auf 10.0.0.222 liegen hat. Natürlich gibts noch einen öffentlichen Nameserver, der hat in unserem Beispiel die 212.121.212.111 als IP.
In der named.conf sieht das dann so aus:
options {
directory “/var/named”;
forwarders { 212.121.212.111;};
};zone “intranet1.de” in {
type forward;
forwarders {192.168.0.222; };
forward only;
};zone “intranet2.de” in {
type forward;
forwarders {10.0.0.222; };
forward only;
};
Beim Mac ist das viel simpler. Man lege ein Directory /etc/resolver an und lege dort einfach pro Zone ein File ab. In diesem Beispiel wäre das dann /etc/resolver/intranet1.de mit dem Inhalt “nameserver 192.168.0.222″ und eine zweite Datei mit /etc/resolver/intranet2.de mit Inhalt “nameserver 10.0.0.222″. Fertig. Dumm nur das das ganze nicht persistent ist. Nach dem Neustart ist alles weg. Nicht so wenn man sich die Dateien per Shellscript aus der /etc/rc.common erstellen lässt. Funktioniert prima und ist simpel.
Lange hat es gedauert bis ich meinen ssh-daemon auf dem mit openwrt bestückten WRT54GL zur Key-Authentifizerung bewegen konnte. Hier die Anleitung für alle verzweifelten:
- id_dsa (Ja der Private-Key – es geht leider nicht anders) auf den openwrt unter /tmp/xy ablegen
- via ipkg install dropbearconvert das Konvertierungstool installieren
- dropbearconvert openssh dropbear /tmp/xy /root/id_dsa die Konvertierung anstossen
- dropbearkey -y -f /root/id_dsa >/etc/dropbear/authorized_keys das gewünschte Keyfile erzeugen.
- Nun noch die beiden privaten Files (/tmp/xy und /root/id_dsa) löschen (die wollen wir ja nicht auf dem router behalten) – Das dropbearconvert wird auch nicht mehr benötigt – per ipkg remove dropbearconvert kann man wieder wervollen Platz auf dem Router freigeben…
Jetzt sollte es funktionieren.
… das Teil kann einfach alles. Nämlich:
- Linux shell (incl. ssh daemon) direkt nach der installation
- Sämtliche Ports des Switches sind in vlans zerlegbar (Einsatz: Routing, Echte DMZ, Zweiter DSL-Anschluss als Fallback)
- Die einzelnen LEDs sind via /proc/diag/led/* ansteuerbar (nette Effekte, zB Visualisierung des Onlinezustandes etc…)
- Der “Button” auf der Frontseite kann ein Script unter Linux triggern (einfach ein 700er Shellscript unter /etc/hotplug.d/button anlegen – ggf. vorher das Directory erstellen)
- IPtables ist so gut vorkonfiguriert, dass man nur noch marginale Anpassungen auf Shellebene machen muss (per Webinterface kann man iptables zwar auch customizen, allerdings nur sehr oberflächlich)
- X-Wrt sollte man sich als openwrt-Distribution gönnen. Denn das Standart-Webinterface ist extrem kläglich.
So, der alte FVS338 ist jetzt rausgeflogen, mal schauen wo ich den noch einsetzen werde. Der WRT54 ist in jedem Falle sein Geld wert.
Wer so etwas auch haben möchte, kaufe sich einen Linksys WRT54GL (Kostenpunkt um die 60 Euro) und lese sich bei openwrt ein.
Dank Christian habe ich es nun auch mitbekommen. Ein weiteres Update für den FVS338 steht ins Haus. Wie üblich Downloadbar über die Netgear-Seiten. Das Changelog macht schon mal einen guten Eindruck. Wenn der Router innerhalb der nächsten 4 Wochen allerdings nicht das tut was ich möchte, fliegt er raus. Ich nehme schonmal Angebote entgegen
Gerade bei shiftzwei drauf aufmerksam geworden. Linux-Nutzer kennen es unter “iptraf”. Windows User kennen es garnicht und für den Mac heisst das Tool des Monats “iftop”.
Iftop zeigt den Netzwerktraffic ähnlich wie top im Terminal an. Nach installation des OSX-Packages befindet sich das Binary unter “/usr/local/sbin”. Zum entspannten benutzen, entweder /usr/local/sbin in den Pfad aufnehmen, oder das Tool in ein Diretory mit Suchpfad umkopieren…

Es gibt mal wieder ein Update für den Netgear-Router, diesmal auf die Version 2.0.0-141. Laut Changelog wurde aber lediglich an der Security des Webinterfaces herumgedreht. Ein Feature für das “nicht-löschen” der NAT-Tabellen nach einem Reconnect bei fester IP ist leider immer noch nicht implementiert… Schade aber auch

