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

[Hans-Dietrich Kirmse]

Hallo Mario,

Mario Lorenz schrieb:
> Am 07. Dec 2009, um 00:02:27 schrieb Hans-Dietrich Kirmse:
>> Hallo Mario,
>>
>> Danke auch für diese Antwort. Etwas weiter bin ja schon, aber der 2.
>> Apache läuft leider noch nicht.
> 
> .. und ich bin mal zwei Tage nicht da und auf der Liste geht eine Diskussion los
> wie das ganze letzte Jahr nicht :)

Für mich ist schön, dass mein gestellte Problem eigentlich geklärt ist.

Ich nutze mal diese Gelegenheit an meinen letzte Frage zu erinnern:
29.10.2009 16:21 ff.  Betreff: Browser als Oberfläche
Das was hier diskutiert wurde, ist von 2 anderen Mitstreitern weiter
überarbeitet und dann in unsere Lösung (Delixs) eingebaut worden.
http://www.delixs.de/dwiki/index.php/Entwicklungsumgebung/Sysadm

  :

>> 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.
> 
> Ja. Wenn die Scripte unter der UID von www-data laufen. Das tun sie, wenn
> Du mit mod_p* arbeitest. Wahrscheinlich kannst Du die Leute auf ihr eigenes
> Home-Verzeichnis per php.ini irgendwie einsperren, aber offensichtlich
> 
>> 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 ???
> 
> willst Du Dich nicht drauf verlassen...

genau so ist es.

> Damit bleibt Dir, andere User-IDs zu verwenden.
> 
> also, nimm den einen apache (und vergiss zusätzliche instanzen, selbstcompilieren
> etc, das macht Dir in der Wartung nur Arbeit hinterher...).
> 
> - Richte einen VHOST ein.
>   schalte dort mod_php ab. (php_engine off oder so ähnlich)
> 
> - Schalte Suexec ein, mittels der Direktive SuexecUserGroup  admuser admgrp
>   (admuser und admgrp seien neu definiert User + Gruppen)
> 
> - Schalte für das Admin-Verzeichnis CGI ein. Zum Beispiel über eine ScriptAlias-Direktive,
>   oder über Option ExecCGI und Dateiendung .cgi für alle Scripte.
>   Die Scripte müssen ausführbare Programme sein (mit #!/usr/bin/php als erste Zeile falls PHP,
>   kann aber auch was anderes sein) und admuser/admgrp gehören
> 
> - Versuche die Scripte auszuführen. Fehlermeldungen von suexec werden protokolliert und sagen Dir
>   was noch falsch ist. Suexec ist - weil sicherheitsrelevant- sehr pingelig.
> 
> - Die Scripte sollten lt. SuexecUserGroup als admuser/admgrp laufen. Du kannst jetzt mittels
>   sudo admuser (und nicht www-data) die Root-Rechte einräumen
>   Da die auf diesem vhost die User keine Scripte laufen lassen können, können sie kein admuser und damit
>   kein root werden.
>   Die Scripte der Schüler laufen weiter unter anderem vhost, unter von mir aus modphp, als www-data,
>   oder auch ohne modphp auch mit suexec und anderer ID...

diese Option hatte ich bisher außer Acht gelassen.

Das lag daran, weil ich ja erstmal das Problem verstehen mußte.
Und als nächstes, dass es dafür eine (m.E. sichere) Lösung gibt. Und ich
bin eben darauf gekommen, dass dieses Problem bei Webmin nicht auftritt.
Aber da Webmin in unserem Projekt nicht als Lösung in Frage kommt,
habe ich einfach überlegt, wie ich den Webmin-Server ersetzen kann. Und
da landet man dann bei lighttpd oder eben bei einer 2. Instanz von Apache.

Aber statt für die Admin-Scripte auf einen 2. Server zu wechseln, nur
auf einen 2. vhost auszuweichen, dass ist natürlich auch zu überdenken.
Und (nur) für die Admin-Scripte ist CGI aus meiner Sicht durchaus
akzeptabel. Allerdings ist meine Sicht bei unserem Projekt natürlich
nicht allein entscheidend. Deswegen geht es mir auch ums Verständnis und
gute Argumente.

  :

>> 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}
> 
> which apache2
> Bzw, schau mal mit dpgk -L apache2 nach wie der indiander bei debian
> genau heisst. Ich glaub jedoch er liegt in /usr/sbin. Und es muss
> apache2 -d /etc/apache2b heissen, -f ist für -f /etc/apache2b/httpd.conf
> (oder so ähnlich)

die Lösung läuft ja inzwischen bei mir. Auch ein lighttpd ist inzwischen
zum Vergleich installiert und läuft. (wobei ich deswegen den Apache
ausgeschaltet habe)

mehr in den nächsten Mails.

MfG Hans-Dietrich