2 Instanzen von Apache - geht das, wenn ja - wie?

Hans-Dietrich Kirmse hd.kirmse at gmx.de
Mo Dez 7 00:02:27 CET 2009


Hallo Mario,

Danke auch für diese Antwort. Etwas weiter bin ja schon, aber der 2.
Apache läuft leider noch nicht.

Mario Lorenz schrieb:

>> So war das nicht gedacht. Es geht einfach nur darum, dass der eine
>> Apache die lokalen Webseiten einschließlich der Seiten der User (also
>> ~/html_public) bereitstellt und die andere Instanz eben als Webserver
>> für das Admin-Interface dient. Es sollen also die Scripte zur User- und
>> Rechnerverwaltung auf den einen Rechner ausgeführt werden (quasi der
>> "Webmin-Ersatz") und alles andere auf den "Standard-Apache". Wobei ich
>> mir noch keine Überlegungung dazu angestellt habe, auf welchen der
>> beiden Server das Wiki, das CMS und Moodle laufen sollte.
> 
> Mit zwei Instanzen ist das natürlich kein Problem.
> Aber ich sehe den großen Sicherheitsgewinn noch nicht.

Es ist bei uns so: das Webinterface für die Admin-Scripte laufen unter
der UID von www-data. über sudo bekommt www-data das Recht, diese
auszuführen (in vielen bzw. den meisten Fällen root-Rechte).

Wenn die Schüler in ihren html_public-Verzeichnissen PHP-Scripte ablegen
und diese werden aufgerufen, dann werden die natürlich vom Apache
ausgeführt unter der UID von www-data. Und www-data hat per Eintrag in
der sudoers nunmal besondere Rechte, um z.B. die Scripte zur User- und
Rechnerverwaltung auszuführen.

Das die User mit ihren PHP-Scripten nicht auf dieses Scripte zugreifen
können, dass muss durch entsprechende Konfiguration des Apachen und von
PHP abgesichert werden. Aber ob das (von uns) perfekt gemacht wird, dass
kann zumindest ich nicht sagen. Und ich kann auch nicht dafür gerade
stehen, das die Admins vor Ort (wohlgemeinte) Änderungen vornehmen und
dadurch vielleicht den Zugriff vom html_public-Verzeichnis auf die User-
verwaltungsscripte ermöglichen oder auch durch bisher nicht gefundene
Sicherheitslecks kann das doch (zumindest theoretisch) möglich sein.

Wenn aber nur für den User für den einen Apache, wo das Webinterface
läuft der Eintrag in der sudoers ist, dann besteht (zumindest aus meiner
Sicht) keine Möglichkeit für Scripte, die auf dem anderen Apache
ausgeführt werden, eben über diesen Eintrag root-Rechte zu bekommen. Im
Normalfall auch bei Fehlkonfiguration des Apache nicht. Insofern sehe
ich das schon als großen Sicherheitsgewinn. (Ach ja: diese Admin-Scripte
werden per https aufgerufen und authentifiziere gegen den LDAP. Die
Schwachstelle ist m.E. nur noch die UID des Apache).

>> geht nicht. Es geht um einen Schulserver (Nachfolger von Arktur4).
>> Schüler sollen auch PHP-Scripte erstellen und bereitstellen/nutzen
>> können. Will sagen, in den html_public-Verzeichnissen soll für die
>> Schüler PHP wie bei Arktur (dort zudem auch Python) *standardmäßig* zur
>> Verfügung stehen. Mit CGI schieß ich mir m.E. aus mehreren Gründen ein
>> Eigentor.
> 
> Die Gründe würden mich interessieren... CGI saugt etwas Performance,
> und hat keine persistenten DB-Verbindungen. 

langsam ;)

Es geht um einen Schulserver. Ich unterrichte Informatik (auch im
Leistungsfach), aber CGI war da bis auf eine Ausnahme noch kein Thema.
Wohl aber wird Programmierung verlangt. Und ein paar PHP-Seiten zu
erstellen, dazu gibt es genügend Anleitungen im Netz, die aber von PHP
als Apache-Modul ausgehen. Und falls man zu Datenbankprogrammierung
kommen sollte (in Hessen kommen die so weit im Unterricht), dann wäre
CGI ein Pferdefuss. Aber es zählt auch, dass der Server (www.delixs.de)
der Nachfolger von Arktur4 werden soll. Eine solche Änderung wird nicht
gewünscht und wäre m.E. auch (in der Entwicklergruppe) nicht durchsetzbar.

> In Summe bedeutet es, dass
> man umfangreichere PHP-Apps (CMSe etc.) nicht vernünftig betreiben kann.
> Schüler-Programmierübungen kann man lässig mit CGI und suexec abfangen.

abfangen ja, aber didaktisch ist das m.E. nicht wirklich sinnvoll.

> Das ist sogar der sinnvolle weg, weil dann die Programme jeweils unter der
> Userid des Schülers laufen. (Dein Konzept mit 500 Usern auf einem zweiten
> Apache bedeutet zwar eine Absicherung des Admins, aber 500 User deren
> Programme unter der selben UID laufen, was bei "Fortgeschrittenen"
> für eher viel Spass sorgen dürfte...

Es ist ja nicht so, dass man die PHP-Scripte nicht auf das betreffende
Homeverzeichnis einschränken kann. Nur ob man da alles richtig macht ???


> 
> 
>>   aptitude -R install apache2-mpm-prefork
>> sagt mir das System, dass er 2 Pakete aktualisieren will. Ich will aber,
>> dass ein 2. Apache zur Verfügung gestellt wird. so gehts also nicht
>> (wobei mir das eigentlich auch logisch ist), aber wie macht man es dann?
> 
> Du installierst Apache einmal.
> 
> Du legst einen zweiten Satz Config-Files bzw. eine zweite Serverroot an.

habe ich gemacht. (unter /etc/apache2b )

> 
> Die zweite Apache-Instanz startest Du einfach manuell mit httpd -d <zweites serverroot>
> bzw -f <zweites configfile>

meldet er mir, dass er den Befehl "httpd" nicht kennt.
ein Aufruf von "apache2 -f /etc/apache2b"  liefert mir:
apache2: bad user name ${APACHE_RUN_USER}

ich hatte eine Systemgruppe www-data2 und einen Systemuser www-data2
angelegt und das in /etc/apache2b/envvars  eingetragen.
Auch ein User/Gruppe  www-xxx:www-xxx  änderte daran nichts.

wie könnte ich einen guten Namen vergeben? Oder ist diese Fehlermeldung
nur falsch bzw. nichtssagend?

MfG Hans-Dietrich