Wenn man selber schon CGI-Skripte geschrieben hat, dann weiß man, wie schwierig es sein kann, den Fehler zu finden, wenn das Skript nicht so funktioniert, wie es soll.
Das Problem dabei ist, dass man die Ausgabe- bzw. Fehlermeldungen eines CGI-Skripts beim Zugriff nicht zu sehen bekommt.
Es wird einem nur die Fehlermeldung des Apachen präsentiert, häufig ein nichtsagender Error 500.
Hier kann uns das Apache-Modul mod_cgi weiterhelfen.
Mit der Direktive ScriptLog kann man die Ausgabe von CGI-Skripten protokollieren, die nicht korrekt ausgeführt werden.
Dabei werden immer die folgenden Zeilen im Logfile ausgegeben:

%% [time] request-line
%% HTTP-status CGI-script-filename

Je nach Art des Fehlers sind im Logfile noch folgende Einträge zu finden:

%request
All HTTP request headers received
POST or PUT entity (if any)
%response
All headers output by the CGI script
%stdout
CGI standard output
%stderr
CGI standard error

oder:

%%error
error-message

Passend zur ScriptLog Direktive existieren noch ScriptLogBuffer und ScriptLogLength.
Mit diesen beiden Direktiven lässt sich Größe des Logfiles begrenzen, da bei CGI-Skripten oft große Datenmengen anfallen können, besonders wenn die HTTP-Methoden PUT oder POST benutzt werden.

Beispiel:

ScriptLog logs/cgilog
ScriptLogLength 2097152
ScriptLogBuffer 2048

ScriptLogLength 2097152 - begrenzt das Logfile auf 2MB Größe
ScriptLogBuffer 2048 - nur die ersten 2048 Byte der Anfrage werden in das Logfile aufgenommen

tags: CGI Skript, debuggen

Wer schonmal mit den Virtual Hosts beim Apachen rumgespielt hat, weiß wie lästig es ab einer bestimmten Anzahl von Virtual Hosts wird, die httpd.conf für jeden neuen Eintrag abzuändern und den Webserver jedesmal neu zu starten.
Besonders lästig ist das wohl für Webhosting-Anbieter, die mit einer großen Anzahl gleichartiger virtueller Hosts hantieren müssen.
Bei einer hohen Anzahl von namensbasierten virtuellen Hosts leidet zudem die Performance, da bei jedem Aufruf immer die Liste Hostnamen durchgegangen werden muss.

Hier bietet sich der Einsatz des Apache-Modusl mod_vhost_alias an.
Die Hauptvorteile beim Einsatz von mod_vhost_alias sind:

• Die Konfigurationsdatei ist kürzer und der Webserver startet schneller und benötigt weniger Hauptspeicher.
• Zusätzliche virtuelle Hosts können durch einfaches erzeugen neuer Verzeichnisse im Dateisystem und Einträgen im DNS Server erstellt werden.
• Der Apache Webserver muss nach dem Hinzufügen neuer virtueller Hosts nicht mehr neugestartet werden.

Einen Nachteil hat die Sache aber auch:
Man kann für die einzelnen virtuellen Hosts keine getrennten Logfiles anlegen.

Die Idee hinter diesem Modul besteht darin, den Hostnamen nicht in die Serverkonfiguration aufzunehmen, sondern auf das Dateisystem auszulagern.
In der Serverkonfiguration wird der Ort angegeben, an dem die einzelnen virtuellen Hosts liegen.
Beispielsweise im Verzeichnis /vhosts/
Innerhalb dieses Verzeichnisses werden dann einfach die jeweiligen Verzeichnisse für die virtuellen Hosts angelegt, z.B /vhosts/www.domain.tld/ und /vhosts/www.anderedomain.tld.
Diese Domains müssen dann nur noch im DNS Server eingetragen werden.

Windows Beispiel:

UseCanonicalName Off
VirtualDocumentRoot "F:/Apache/Apache2/vhosts/%0"
<Location /cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Location>

Linux Beispiel:

UseCanonicalName Off
VirtualDocumentRoot /usr/local/apache/vhosts/%0
<Location /cgi-bin>
Options ExecCGI
SetHandler cgi-script
</Location>

<Location /cgi-bin> wird nur dann benötigt, wenn die virtuellen Hosts auch eigene CGI-Anwendungen ausführen dürfen.
Dafür muss dann innerhalb der virtuellen Host Verzeichnisse ein cgi-bin Verzeichnis bereitgestellt werden, bzw. vorhanden sein.

tags: Mass Virtual Hosting

Hotlinking, bzw. Traffic-Diebstahl, was ist das?
Wenn jemand z.B. eine Grafik, die auf einem fremden Webspace liegt so in seine Homepage einbaut, dass die Grafik beim Aufruf dieser Homepage sichtbar wird, dann nennt man das Hotlinking.
Traffic-Diebstahl ist das, weil beim Aufruf der Grafik Traffic auf dem fremden Webserver erzeugt wird.
Besonders oft ist dies in diversen Foren anzutreffen, wo einige User hemmungslos lustige Bildchen und Icons von Fremdservern einbinden.
Gerne wird ausser auf Bilder auch auf Musik- und Videodateien verlinkt.
Man kann dies aber Serverseitig unterbinden, mod_rewrite sei Dank.
Das kann man in der httpd.conf erledigen, oder mit Hilfe der .htaccess Datei.

<FilesMatch "\.(gif|jpe?g|png|bmp|pdf|zip|rar|mp3|js)$">
RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^$ 
RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.td [NC] 
RewriteRule .*\.(gif|jpe?g|png|bmp|pdf|zip|rar|mp3|js)$ - [F] 
</FilesMatch>

Die FilesMatch Direktive kann um die gewünschten zu verbietenden Dateien ergänzt werden.
Alle Seiten, denen es ausdrücklich erlaubt sein soll zu verlinken, müssen mit jeweils einer eigenen Rewrite Condition eingetragen werden.

Statt den Hotlinkern ein Forbidden unterzuschieben, kann es auch ganz lustig sein, statt der vom Hotlinker erwarteten Datei etwas ganz anderes auszuliefern, z.B. ein kompromitierendes Bildchen oder eine komplette Linux-Distribution als DVD iso-image :-)
Diese Methode dürfte besonders in Foren seine Wirksamkeit entfalten.

<FilesMatch "\.(gif|jpe?g|png|bmp|pdf|zip|rar|mp3|js)$"> 
RewriteEngine on 
RewriteCond %{HTTP_REFERER} !^$ 
RewriteCond %{HTTP_REFERER} !^http://(www\.)?domain.td [NC] 
RewriteCond %{REQUEST_FILENAME} !dieb.gif$ 
RewriteRule .*\.(gif|jpe?g|png|bmp|pdf|zip|rar|mp3|js)$ http://domain.td/dieb.gif [R]
</FilesMatch>

tags: Hotlinking, Traffic Klau