Ich habe die ganze letzte Woche damit verbracht, eine neue Hosting-Umgebung für unser System zu entwickeln. Die Anforderungen waren nicht gerade klein:
#) Apache 2.2.*
#) PHP als Modul (inkl. Wechsel der Version ohne Verzögerung)
#) Vhosts im MySQL-Backend
#) Logging auf zentralen MySQL-Server
#) div. PHP-Einstellungen live änderbar (ohne Apache graceful oder restart)
Einige der Punkte habe ich bereits vor ca 2 Jahren im alten System umgesetzt, so dass sich folgender Ist-Zustand ergeben hat:
#) Apache 1.3.*
#) PHP als Module (wechsel der Version nur alle 5 Minuten möglich)
#) Vhosts im MySQL-Backend
#) Logging auf zentralen MySQL-Server
#) div. PHP-Einstellungen live änderbar (wurden aber erst nach Apache graceful oder restart übernommen)
Die Aufgabe der letzten Woche war es also, das alte System im Apache 2.2.* abzubilden. Logging und PHP als Modul waren da nur das kleinste Übel. Viel Arbeit hatte ich mit der Suche eines passenden Moduls für die Vhosts. Dazu muss man sagen: etliche Modul-Seiten die in der Apache-Modul-Suche aufgelistet werden, sind schon seit Jahren down und nur noch über archive.org zu erreichen.
Für die Vhosts verwende ich eine angepasste Version von mod_vhs, welche auch den Wechsel der PHP-Version zulässt. Für das Logging wird das Modul mod_log_sql verwendet – auch hier kommt wieder eine angepasste Version zum Einsatz, welche je nach Domain-Kategorie eine eigene Datenbank ansprechen kann.
Alles andere ist dann eigentlich eine reine MySQL-Geschichte, welche ich hauptsächlich mit VIEWs (und dahinterliegenden, sauber getrennten, Tabellen) gelöst habe – da ich Blob- und Text-Felder in Tabellen als Tabu abstemple 
.
Bei einer getesteten Vhost-Lösung für Apache 1.3.* (welche auch live funktioniert) gab es immer wieder das Problem, das es bei der Zuweisung des open_basedir zu einer Segmentation fault des Apache Childs kam – der bearbeitende Prozess starb also – es wurde nur eine weiße Seite ausgegeben.
In den nächsten 2 Wochen ist es also soweit: es erfolgt der Umstieg auf die neue Hosting-Lösung mit Apache 2.2.* als MPM-Worker und die aktuelle PHP5 sowie PHP4-Version.
o.O
Mehr kann ich dazu nicht sagen…
Wie darf ich das verstehen?
Überrascht, dass hinter einem Klicki-Bunti Webadmin mehr, als nur ein PHP-Skript steckt?
Klar, wir dachten immer das MS Frontpage dein Lieblingsprogramm ist und für das Layout Word genutzt hast *fg*
ich versteh nur bahnhof, macht aber auch nix
hauptsach’ das werkl rennt
Bahnhof is wohl noch milde ausgedrückt…Ich versuch es gar ned zu lesen, da ich mir vorkomme, als wär ich irgendwo in Spanien oder so…dort würd ich nämlich auch kein Wort verstehen.
Scheint ja n haufen Arbeit zu sein.
Aber du schaffst das schon
Ich könnte da nur als Aussenstehender etwas zu sagen, da mir *irgendjemand* immer noch keinen Account eingerichtet hat.
Naja, ich weiss so ungefähr was mit anzufangen. Wobei der zweite und letztere Punkt (denke ich mal) der für uns User praktischere Teil ist. Der rest ist einfach nur im Hintergrund, wie der Server arbeitet und mit Dingen umgeht. (siehe Performance, logik und Übersichtlichkeit)
Wenn ich mich nicht irre hattest du doch einen bis du ihn gelöscht hast, irgendwer wird sich denken: Strafe muss sein
Du hast doch sicher nicht als letzter von dem “Supporters Club”
erfahren, oder?
@Marco Bei one war das Ganze etwas komplizierter – sein Account lag auf dem Server chief, welcher derzeit bei mir Daheim im Esszimmer liegt
.
Och schaade .. musste Apache Update sein? Fand die 1.3.37 Version irgendwie lustig!!
Falls ihr euch nicht erinnert:
http://metal_alf.uttx.net/1337.jpg
Es kommt noch viel Schlimmer: der Umstieg auf den 2.2. Damit wir auch mal wirklich die Power aus der Kiste kratzen können
.
Der Server liegt vielleicht im deinem Esszimmer, meine Daten habe ich jedoch vor dem Umzug gelöscht. Also eigentlich brauche ich nur einen neuen Account oder sowas.
Frage.
wie hast du das mit dem dynamischen Wechsel ohne restart hinbekommen?
Du meinst den Wechsel des PHP-Moduls? Das bleibt mein kleines aber feines Geheimnis
. Fakt ist: für den User erfolgt der Umstieg zu 100% transparent und ohne Zeitverzögerung.
Lass mich raten: Du änderst einfach den Dateihandler für *.php Dateien, damit nicht PHP4 sondern PHP5 anspringt (oder umgekehrt), gell? Denn auf die gleiche Art machen das auch die großen Hoster, so können sie User es sogar selbst per htaccess Eintrag ändern
MfG Christian
Pingback (Kurzfassung): /dev/blog von Jürgen Jaritsch » Blog Archiv » Apache, dynamisches Hosting und viel Entwicklungszeit …
@killerbees19 Ich muss dich enttäuschen – bei mir wird nicht gepfuscht und die User müssen auch keine verwunderlichen .htaccess-Einträge erstellen. Wenn ich so ein Feature anbiete, dann ist es bequem per Weboberfläche zu steuern
. Aber wieder du sicherlich schon gelesen hast, habe ich PHP4 über Board geworfen.