Vielen dürfte bekannt sein (aus Beobachtungen oder aus eigener Erfahrung), daß mit zunehmendem Blutalkoholspiegel die Fähigkeit zum Programmieren nachläßt. Weniger bekannt ist aber die Tatsache, daß bei 1,3 Promille eine fast singuläre Steigerung der Leistungsfähigkeit eintritt … Näheres dazu im neuen Eintrag auf xkcd.com.
Via: Linux an der HHU
Die Installation von ionCube ist sehr einfach und geht recht schnell.
Als erstes muss man sich die Sourcen von hier besorgen und entpacken.
cd /usr/local/
wget http://downloads2.ioncube.com/loader_downloads/ioncube_loaders_lin_XXX.tar.gz
tar -xvzf ioncube_loaders_lin_XXX.tar.gz
Nun müssen wir PHP nur noch sagen, dass es das ionCube-Modul auch laden und nutzen soll. Dazu hängt man die folgende Zeilen an die php.ini an. Die befindet sich z. B. unter Debian in /etc/apache2/php5/php.ini
zend_extension = /usr/local/ioncuce_loaders_lin_XXX/ioncube_loader_lin_5.2.so
Nun nur den Apache-Dienst neustarten und ionCube wird verwendet. Fertig!
Achtung: Der Include von ionCube muss in der php.ini vor allen anderen zend_extension stehen.
Nachdem ich die Tage eAccelerator installiert habe viel mir dann einige Zeit später auf das phpMyAdmin nicht mehr funktioniert. Um herauszufinden ob es wirklich an eAccelerator liegt, habe ich diese Extension in der php.ini wieder deaktiviert. Wola phpMyAdmin funktioniert wieder und ich hatte also mit meiner Vermutung recht. In der Doku zu eAccelerator habe ich dann entdeckt das man die Extension für bestimmte Verzeichnisse oder vhost deaktivieren kann. Hier der entsprechende Part:
Apache: How can i disable eaccelerator on a particular virtualhost?
Just put php_flag eaccelerator.enable 0 and php_flag eaccelerator.optimizer 0 in a .htaccess file in the document root of the virtualhost or directly inside <Virtualhost> apache section.
Die weit verbreitete Programmiersprache PHP kündigt offiziell das Lebensende der Version 4 an: Ab 31.12.2007 wird nur noch PHP5 weiterentwickelt.
Regelmäßige Updates und Sicherheitsbereinigungen gibt es derzeit sowohl für PHP4 als auch für PHP5. Jetzt kündigt das Open Source Projekt an, dass die 4er Versionslinie zum Ende des Jahres offiziell aus dem Support genommen wird. Von diesem Zeitpunkt an werden funktionale Bugs in keinem Fall mehr behoben. Auch bei Sicherheitslücken sieht es dann duster aus: In besonderen Einzelfällen werden man noch Updates bereitstellen, heißt es. Im Umkehrschluß bedeutet dies, dass normalerweise auch mit Security Fixes nicht mehr zu rechnen ist. Endgültig das Leben aushauchen wird PHP4 dann am 08.08.2008.
Webmaster und Entwickler tun sich gut daran, bereits jetzt die Migration ihrer Anwendungen auf die Version 5 einzuleiten. Diese ist in weiten Teilen problemlos, einige spezielle Bereiche erfordern allerdings eine Überarbeitung des existierenden Codes - mit ein Grund warum immer noch viele Anwendungen nur unter PHP4 laufen. Für alle Entwickler hat die PHP-Community auch einen Online Migrationsleitfaden für den Umstieg auf die Version 5 bereitgestellt.
Quelle: WHL
SelfHTML hatte einen 
Spendenaufruf für gestartet. Inzwischen sind 17k Euro zusammen gekommen.
Das Projekt hat einen Spendenaufruf für neue Hardware gestartet. Wenn ich mir das Guthaben auf dem Spendenkonto so ansehe, muss die Aktion ja schon etwas länger laufen.
Es gibt spezielle Spider, die das Web nach Email-Adressen durchsuchen und dese Speichern. Die meisten Email-Adressen werden dann zu Spamzwecken erkauft. Wie man seine Emailadresse gegenüber solchen Spidern schützen, kann man hier nachlesen.
Eine Technik, die die Spider bisher noch nicht erkennen, ist das Verschlüsseln der Zeichen durch die Verwendung des UniCodes.
Dabei werden die Zeichen einer Emailadresse in die des UniCodes umgewandelt.
Wichtig ist, das auch das “mailto:” mit umgewandelt wird, damit der
Spider nicht einmal erkennt, was das für ein Link ist.
Das “mailto:” sieht standardmäßig so aus: mailto:
Kommenden Donnerstag, den 17.7.2003 bestreitet Max auf Fritz wieder einmal einen Bluemoon, diesmal zum Thema Webseiten bauen. Für alle die wie ich nicht in Berlin oder Brandenburg wohnen gibt es einen Realstream.
Hier gibt es einen Generator mit dem man eine Config für SpamAssassin 2.5x erzeugen kann. Sehr praktisch!
So, und damit ich nicht irgendwann ein Opfer vom Traffic-Klau werde, habe ich dies jetzt direkt einmal unterbunden. Von Traffic-Klau spricht man, wenn jemand z.B. eine Grafik, die auf einer fremden Homepage liegt, so in seine eigene Homepage einbaut, dass die Grafik beim Seitenaufruf sichtbar wird. Auf der Seite, woher man die Grafik hat, wird somit Traffic (Datentransfer) erzeugt. Dieser Zugriff auf fremde Datensätze ist in den meisten Fällen vom Homepagebesitzer, wo das Ursprungsbild liegt, nicht gewollt. Somit wird er ungefragt “bestohlen”, ohne dass er selber einen Nutzen davon hat. Auch unberechtigte Zugriffe auf Downloadlinks, Musikstücke, Fotos etc. stellen einen “Diebstahl” am Serviceangebot eines Anderen dar.
Um diesen Diebstahl zu unterbinden habe ich meine .htaccess-Datei um folgende Zeilen erweitert:
RewriteCond %{HTTP_REFERER} !^http://wh-og.fh-niederrhein.de
RewriteCond %{HTTP_REFERER} !^http://www.wh-og.fh-niederrhein.de
RewriteCond %{HTTP_REFERER} !^http://wh-og.hs-niederrhein.de
RewriteCond %{HTTP_REFERER} !^http://www.wh-og.hs-niederrhein.de
RewriteCond %{HTTP_REFERER} !^http://wh-og.fhn.de
RewriteCond %{HTTP_REFERER} !^http://www.wh-og.fhn.de
RewriteCond %{HTTP_REFERER} !^http://wh-og.hsnr.de
RewriteCond %{HTTP_REFERER} !^http://www.wh-og.hsnr.de
RewriteCond %{HTTP_REFERER} !^http://berta
RewriteCond %{REQUEST_URI} !^.+ban_image.+$
RewriteRule ^.+\.(gif|GIF|jpg|JPG|jpeg|JPEG)$ http://www.wh-og.hs-niederrhein.de/~docx/blog/images/stop.gif [redirect,last]
stop.gif wird eingezeigt wenn eine Einbindung von extern erfolgt ist.
Mir ist aufgefallen, dass Google und andere Suchmaschinen mein Blog nicht vollständig indizieren können. Dies kommt daher, weil Suchmaschinen Seiten, die irgendwie nach dynamisch aussehen, ignorieren. Dies machen sie daran fest, dass GET-Parameter an die URLs angehängt werden. Sunlog arbeitet standardmässig so, die Inhalte sind per se aber nicht dynamisch, wegen den GET-Parametern macht es aber dennoch den Anschein. Also gilt es diese Parameter zu verstecken.
Die einfachste Methode ist das benutzen von mod_rewrite, einem Modul für Apache Webservers. Es ermöglicht, URLs intern “umzuschreiben” (rewrite). Heißt im Klartext: der Surfer greift auf eine (nicht real existierende) URL zu, der Apache verarbeitet diese anhand bestimmter Regeln, greift dann mit Hilfe des modifizierten Pfades auf eine Datei zu und schickt sie an den Browser. Der Client merkt davon nichts, kann davon gar nichts merken.
Ich habe eine .htaccess-Datei angelegt, welche den Webserver anweist, die Rewrite-Engine zu starten und die URLs nach einem festgelegtem Schema umzuschreiben.
RewriteEngine on
RewriteRule ^item(.*)\.php$ /~docx/blog/entry.php?id=$1
RewriteRule ^month(.*)\.php$ /~docx/blog/archiv.php?month=$1
RewriteRule ^cat-(.*)\.php$ /~docx/blog/index.php?cat=$1
Diese Anweisungen sorgen dafür, dass jeder Link auf entry.php?id=xxxxx in itemxxxxx.php umgeschrieben wird. Etwas ähnliches wird mit Verweisen auf die archiv.php und die index.php?cat=catname gemacht. Folglich werden die Seiten nun von Suchmaschinen in den Index aufgenommen.
