Suche
Kategorien
Getaggte Artikel
Blog abonnieren
Impressum
FeM e.V.
Max-Planck-Ring 6d
98693 Ilmenau
Tel./Fax: +49 3677 691929
info@fem.tu-ilmenau.de
www.fem.tu-ilmenau.de
Vertretungs-
berechtigter Vorstand:
Vorsitzender:
Adrian Schollmeyer
Stellvertretender Vorsitzender:
Robin Lehmann
Schatzmeisterin:
Anna Brede
Stellvertretender Schatzmeister:
Maximilian Klook
Registergericht:
Amtsgericht Ilmenau
Registernummer: 120483
Datenschutzerklärung
Max-Planck-Ring 6d
98693 Ilmenau
Tel./Fax: +49 3677 691929
info@fem.tu-ilmenau.de
www.fem.tu-ilmenau.de
Vertretungs-
berechtigter Vorstand:
Vorsitzender:
Adrian Schollmeyer
Stellvertretender Vorsitzender:
Robin Lehmann
Schatzmeisterin:
Anna Brede
Stellvertretender Schatzmeister:
Maximilian Klook
Registergericht:
Amtsgericht Ilmenau
Registernummer: 120483
Datenschutzerklärung
Verwaltung des Blogs
Tuesday, 3. April 2007
April, April - Oder: Wie FeM einen steifen Hals bekam
Zum 1. April tut man ja alles, um seinen Mitmenschen einen Streich zu spielen. Nun sind im FeM-Net sehr viele Mitmenschen, aber wie spielt man denn nun allen einen Streich? Ganz einfach. Man sorgt dafür, dass alle Bilder auf allen Web-Sites auf dem Kopf stehen. Und das ist gaaanz einfach, denn unser Proxy kann die Bilder noch fix drehen bevor er sie ausliefert. Und so haben wir es gemacht.
Man schreibt sich ein Perl-Script, welches in jedem Link nach Bild-Dateien sucht und den Download dieser übernimmt. Diese Bilder werden dann auf einem Webserver gespeichert und dieser neue Bild-Link wird an den Proxy zurück geschickt. So einfach.
Aber da wir viele roots waren und natürlich jeder seine Fähigkeiten beisteuern wollte, war es damit natürlich nicht getan. Also haben wir aus dem auch sonst völlig überlasteten Proxy einen transparenten Proxy gemacht und den ganzen HTTP-Traffic über diesen Rechner geleitet. Dazu musste im DHCP ein neuer Router ausgegeben werden. Der neue Router war Hexagon der normalerweise unsere IPv6-Netze routet. Dieser hat dann alle HTTP-Requests an den Proxy weitergeleitet.
Leider haben wir keine genaueren Statistiken wieviele Requests der Proxy bearbeiten musste aber ein Load von 4-10 beim Flip und 20-40 beim Umrechnen in schwarz/weiss sprechen für sich. Die Kiste hat geglüht wie das Space-Shuttle beim Wiedereintritt.
Leider haben wir natürlich auch einige Fehler gemacht. Am Anfang fehlte noch ein Block in der Konfiguration und ein Block ging gar nicht weil der Proxy im selben Subnet stand und seine Antworten direkt zum Client schickte und nicht über den Gateway. Aber wir geloben natürlich Besserung und schließlich machen wir sowas nicht alle Tage.
An dieser Stelle noch mal vielen Dank an die zahlreichen Leute die Humor zeigten und es doch witzig fanden.
Man schreibt sich ein Perl-Script, welches in jedem Link nach Bild-Dateien sucht und den Download dieser übernimmt. Diese Bilder werden dann auf einem Webserver gespeichert und dieser neue Bild-Link wird an den Proxy zurück geschickt. So einfach.
Aber da wir viele roots waren und natürlich jeder seine Fähigkeiten beisteuern wollte, war es damit natürlich nicht getan. Also haben wir aus dem auch sonst völlig überlasteten Proxy einen transparenten Proxy gemacht und den ganzen HTTP-Traffic über diesen Rechner geleitet. Dazu musste im DHCP ein neuer Router ausgegeben werden. Der neue Router war Hexagon der normalerweise unsere IPv6-Netze routet. Dieser hat dann alle HTTP-Requests an den Proxy weitergeleitet.
Der FeM-Proxyserver im Betriebsraum des Blocks I
Leider haben wir natürlich auch einige Fehler gemacht. Am Anfang fehlte noch ein Block in der Konfiguration und ein Block ging gar nicht weil der Proxy im selben Subnet stand und seine Antworten direkt zum Client schickte und nicht über den Gateway. Aber wir geloben natürlich Besserung und schließlich machen wir sowas nicht alle Tage.
An dieser Stelle noch mal vielen Dank an die zahlreichen Leute die Humor zeigten und es doch witzig fanden.
Und nun die Details...
Hier erst einmal das Orginal mit Screenshots
Das Orginal
Die etwas optimierte Version vermeidet doppeltes Umrechnen gleicher Bilder und spart eine Menge externe Programmaufrufe ein. So wird das ganze nochmal deutlich leistungsfähiger.
Das Perl-Script:
Angepasste Routing-Tabelle
Anpassung an der squid.conf:
redirect_program /usr/local/bin/1.april.pl
redirect_children 60
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Was hätte man besser machen können?
Sehr viel. Man hätte es schneller machen können, natürlich bräuchte man dazu mehr Rechner. Ich denke da an eine Art Netzwerk-Message-Bus welcher Komandos an andere Rechner schickt. Diese holen die Bilder aus dem Netz und rechnen diese dann um danach legen sie dieses Bild auf ihren Webserver und schicken den Link zurück an den Squid. Nebenbei übermitteln sie evtl. per Multicast(falls man mehrere Squids betreibt) ihren aktuellen Load damit der/die Squid(s) besser die Last verteilen können.
Hier erst einmal das Orginal mit Screenshots
Das Orginal
Die etwas optimierte Version vermeidet doppeltes Umrechnen gleicher Bilder und spart eine Menge externe Programmaufrufe ein. So wird das ganze nochmal deutlich leistungsfähiger.
Das Perl-Script:
#!/usr/bin/perl
use LWP::Simple;
use Image::Magick;
use Digest::MD5 qw(md5_hex);
use strict;
my $OUT_PATH = "/var/www/localhost/images/";
my $OUT_IP = "141.24.53.249";
$|=1;
while (<>) {
chomp $_;
if ($_ =~ /(.*\.jpg)/i) {
my $url = $1;
my $digest = md5_hex($url);
get_and_convert($url, $digest, "jpg");
print "http://$OUT_IP/images/$digest.jpg\n";
}
elsif ($_ =~ /(.*\.gif)/i) {
my $url = $1;
my $digest = md5_hex($url);
get_and_convert($url, $digest, "gif");
print "http://$OUT_IP/images/$digest.gif\n";
}
# leider ein Fehler/Bug? im ImageMagick
# elsif ($_ =~ /(.*\.png)/i) {
# my $url = $1;
# my $digest = md5_hex($url);
# get_and_convert($url, $digest, "png");
# print "http://$OUT_IP/images/$digest.png\n";
# }
else {
print "$_\n";;
}
}
sub get_and_convert {
my $url = shift;
my $filename = shift;
my $format = shift;
# schauen ob dieser Link bereits berechnet wurde
if ( open(FILE, "$OUT_PATH/$filename.$format")) {
close(FILE);
return;
}
# kann man verbessern in dem man nicht speichert
# sondern direkt an an $image->Read() weiterreicht
mirror($url, "$OUT_PATH/$filename.$format");
my $image = Image::Magick->new;
$image->Read( filename => "$OUT_PATH/$filename.$format");
# $image->Quantize(colorspace=>'gray'); # in schwarz/weiss weiterreichen
$image->Flip();
my $x = $image->Write("$OUT_PATH/$filename.$format");
warn $x if $x;
undef($image);
# nicht optimal geht besser
system("/bin/chmod", "a+r","$OUT_PATH/$filename.$format");
# return;
}
Angepasste Routing-Tabelle
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
141.24.45.254 0.0.0.0 255.255.255.255 UH 0 0 0 br1
141.24.53.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
141.24.48.0 141.24.53.252 255.255.248.0 UG 0 0 0 br0
141.24.40.0 141.24.53.252 255.255.248.0 UG 0 0 0 br0
10.42.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0.81
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
224.0.0.0 0.0.0.0 224.0.0.0 U 0 0 0 br0
0.0.0.0 141.24.45.254 0.0.0.0 UG 0 0 0 br1
Anpassung an der squid.conf:
redirect_program /usr/local/bin/1.april.pl
redirect_children 60
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
Was hätte man besser machen können?
Sehr viel. Man hätte es schneller machen können, natürlich bräuchte man dazu mehr Rechner. Ich denke da an eine Art Netzwerk-Message-Bus welcher Komandos an andere Rechner schickt. Diese holen die Bilder aus dem Netz und rechnen diese dann um danach legen sie dieses Bild auf ihren Webserver und schicken den Link zurück an den Squid. Nebenbei übermitteln sie evtl. per Multicast(falls man mehrere Squids betreibt) ihren aktuellen Load damit der/die Squid(s) besser die Last verteilen können.
Trackbacks
Wieder mal ist der erste April rum und so einige sind auf die diversen Scherze reingefallen. Ed hat in ihrem Blog ein paar witzige Gadgets verlinkt die jeden Informatiker Spaß machen würden Nicht zu vergessen sei auch die Kühlung von CPUs durch "Gege
Aufgenommen: Apr 01, 17:33