Umbau auf das eigene Subnetz
2005-08-20 16:13Es geht vorwärts. Nachdem mir Portunity gestern nachmittag, innerhalb weniger Stunden einen DSL-Zugang eingerichtet und ein /29er Subnetz delegiert hat – obwohl ich doch extra (Freitag ab eins macht jeder seins) erst spät ein Auftragsfax rausgesandt habe – sah ich mich gezwungen, etwas zu arbeiten. Ich sah recht schnell Probleme bei der Namensfindung und Netzstrukturierung auf mich zu kommen. Das Gröbste ist geschafft, der Primary-DNS steht nun im Home-Office.
Der Reihe nach: nach meiner eigenen Konvention haben alle Rechner, die speziell als Server arbeiten, Namen von Nadelbäumen zu tragen, alle Workstations, die z.B. nur für die Entwicklung dienen, einen Laubbaumnamen. Diese Konvention hatte schon den Hintergegdanken, dass es recht wenige Nadelbaumarten gibt, so dass es mit meinen Workstations knapp werden könnte. Ein weiteres strukturelles Problem ergab sich bei der Definition, da ja nun ein Rechner als Server permanent am Internet angeschlossen ist und damit eigentlich ein Nadelbaum ist, dieser aber auch direkt aus dem LAN geroutet wird – er ist also ein Zwitter und müsste wenigstens den Namen Laerche (die ja bekanntlich im Winter ihre Nadeln abwirft) erhalten. Laerche ist jedoch schon belegt. :(
Nun, was hätten wir jetzt also.
Douglasie ist und bleibt dieser Server, located im berliner Strato-RZ .
Laerche und Fichte stehen bei 1und1 und werden in den kommenden Wochen eliminiert und durch die neuen IPs Kiefer und Eibe abgelöst, was Linde ist (eben dieser Zwitter-Rechner). Domains, die mehr Bandbreite benötigen, werden auf Douglasie transferiert. Tanne heißt der DSL-Router. Die Workstations werden über Eiche geroutet, die eigentlich auch ein Zwitter ist, aber wenigstens über zwei NICs verfügt und die auf dem externen Interface Zeder heißt. Dann ist demnächst wieder Laerche und Fichte als Name verfügbar. Für die Netzwerk und Broadcast-Adresse sind mir die Nadelbäume ausgegangen, so dass ich auf die Laubbäume Erle und Robinie zurückgreifen musste. Dann wird das Subnetz auf eine IP gerouted, die auch einen Namen verdient – Kastanie fiel mir hier ein. An LAN-IPs gibt es neben oben erwähnter Linde und Eiche noch Buche, Birke, Esche und Ahorn. Kastanie, Erle und Robinie sind wie beschrieben mißbräuchlich genutzt – so langsam wird es knapp mit Namen. Ich sollte auch langsam einen Netzplan anfertigen, sonst verliere ich den Überblick.
Relocated ist neben dem Master-DNS nun auch schon ftp.tobus.org – Das anonymous-FTP war ja kein Problem, aber es gibt auch einen virtuellen vHost-Eintrag für den HTTP-Zugang, und das war etwas knifflich, weil ein AddType text/plain .php
nicht funktioniert, wenn mod_suphp aktiviert ist. Und darauf soll nun einer kommen. Ich sollte mir mal die hoffentlich vorhandene Dokumentation zu mod_suphp zu Gemüte führen. Eigentlich soll dieses Modul ja nur dazu nützlich sein, PHP-Skripte im Context des Owners auszuführen, dem diese gehören – und eben nicht als user des Webservers. Es mag wohl aber nicht akzeptieren, dass PHP-Skripte in bestimmten Verzeichnissen gar nicht ausgeführt werden sollen und parsed sie munter drauf los. Ein bösesTM Modul.
August 20th, 2005 at 17:30
Richtig konfiguriert ist SuPHP eine feine Sache. Du kannst übrigens in einem beliebigen Location- oder Directory-Kontext angeben, ob und wie die PHP-Skripte geparsed werden sollen. Also kein Problem eigentlich. Du solltest vielleicht auch beachten, dass es neben AddHandler von Apache auch SuPHP_AddHander von mod_suphp gibt. ;)
August 20th, 2005 at 18:23
Hmm, zumindest die in den Debian-Paketen enthaltenen Informationen sind nicht sehr ausführlich, man 8 suphp sagt eigentlich gar nichts und das Readme von mod_suphp spricht zumindest von Problemen,
Soll mich aber alles nicht weiter interessieren, Aufgabe war, mod_suphp global zu aktivieren (es tat) und in einem speziellen vhost – und dort in einer directory-Direktive den AddType für .php und .inc wieder auf text/plain zu setzen, also für diese Verzeichnisse sämtliches PHP-Parsen auszuschalten. Das tut es bei mod_php einwandfrei.
Mit mod_suphp bleibt laut config-Readme nur, die „Engine“ für den kompletten vHost auszuschalten. Das dies für directory-Direktiven gelten würde, kann ich der Doku nicht entnehmen. Aber probieren geht bekanntlich über studieren – ich werd’s bei Gelegenheit mal testen.