Ich habe entweder noch alte 1.3.6(*pschht*) oder 2er und will eigentlich alles auf 2 haben - gefällt mir besser. Aber zurück:
Sicherheit:
Da Du eine ganz normale standard Apacheinstallation machst, ist das auch von der Sicherheit eben genau das: eine Standasrdinstallation. Durch das öftere kompilieren ändert sich (fast s.u. )nichts am Endergebnis: Standardinstallation.
Duch den monolytischen Apache ändert sich schon etwas: mit modulen kann nicht getampert werden. Das ist aber etwas umstritten: überall, wo ich hin sehe, setzen sich modulare Ansätze durch. Aber die Diskussion werden wir hier nicht entscheiden können. Bei Dir relativiert sich der Sicherheitsgewinn durch monolytischen Ansatz jedoch nochmal, weil Du Deine verschieden compilierten Apache selber als (sehr große) Module verwendest, die Du nach Bedarf lädst.
Der Sicherheitsgewinn relativiert sich nochmal. Du bekommst ein sehr heterogenes System. Etwas, bei dem die meisten Admins die Hände über den Kopf zusammenschlagen. Zu jedem einzelnen Apache, den Du Compilierst mußt Du ein eigenes Changelog und Buglog anlegen, bei Problemen jedesmal das richtige raussuchen und nachschauen, was Du da hast. -> Das ist dann nicht einfach Dein Apache, dessen Macken Du schon kennst sondern x verschiedene Apache mit ganz unterschiedlichen Macken. Ist Aufwand.
Noch ein Aspekt, der mit dem letzten zusammenhängt, den ich von Dir nicht addressiert sehe. Das Problem ist nicht nur einen Apache durch einen anderen zu ersetzen und eine stabiles Binary zu erstellen. Der mußt selbstredent konfigurieren werden - eben z.B. wie Du sagst einmal mit CGI und dann ohne. In den Konfigurationen finden sich oft die Fehler, wie Du hier im Forum auch sehen kannst. Daher ist imho bei einem Konzept sehr entscheidend, wie einfach ein System zu warten und Konfigurieren ist - je einfacher, desto besser(KISS Prinzip gilt) Je mehr verschiedene apache Du hast, desto komplexer wird das ganze aber.
Systemanforderungen, die sich vielleicht unterscheiden wurden nicht adressiert.
Abgrenzung der Apache gegeneinander wurde nicht adressiert.
Insofern schätze ich den Sichheitsgewinn gegenüber einer getesteten stabilen Apachekonfiguration, die mehrfach mit möglichst geringen Abwandlungen eingesetzt wird, eher gering ein.
Eine Möglichkeit ist es sicher, es gilt was immer gilt, mach es wie Du willst, aber richtig. Soll heißen wenn Du Dein Changelogs, Buglogs und Konfiglogs ordentlich führst und auch verwendest, die Zeit hast so etwas zu verwalten, dann kann das ein sehr sicheres System sein, sicherer als anders. Wenn nicht, ist es Errorprone.
PS: ich habe auch noch nie einen monolytischen Apache gesehen. bzw wenn ich nachdenke ganz früher war da mal was - glaube ich. Aber das waren meine Fingerübungen und ist wenn auch eher Historie(vor schießmichtod 10 Jahren).
Konzeptidee - Frage der Umsetzung (mehrere Indianer, 1 PHP-Instanz) (Update #1)
-
djcrackman
- Posts: 207
- Joined: 2005-06-02 11:58
- Contact:
Re: Konzeptidee - Frage der Umsetzung (mehrere Indianer, 1 PHP-Instanz) (Update #1)
Wie es um die Sicherheit steht ist mir soweit klar und ich bin trotz massivem Abuse mancher User mit den bisherigen Restriktionen sehr gut ausgekommen.
Das mit der Einzelkonfiguration pro Instanz ist mir durchaus bewusst - und auch beabsichtigt, da ich ab und an Spezialisten drauf habe, die der Ansicht sind, sie werden jetzt auf Teufel komm raus ein Monster CMS testen etc. Mein persönliches Work-Logging führe ich selbstverständlich - bei 10k Usern wäre ich da sonst schon lange verzweifelt ;).
Und ich steh auf monolytische Geschichten - wenn schon ein Modul laden, dann PHP und sonst nichts ;).
Das mit der Einzelkonfiguration pro Instanz ist mir durchaus bewusst - und auch beabsichtigt, da ich ab und an Spezialisten drauf habe, die der Ansicht sind, sie werden jetzt auf Teufel komm raus ein Monster CMS testen etc. Mein persönliches Work-Logging führe ich selbstverständlich - bei 10k Usern wäre ich da sonst schon lange verzweifelt ;).
Und ich steh auf monolytische Geschichten - wenn schon ein Modul laden, dann PHP und sonst nichts ;).