From hd.kirmse at gmx.de  Sun Dec  6 15:51:49 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Sun, 06 Dec 2009 15:51:49 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
Message-ID: <4B1BC505.6040506@gmx.de>

Hallo,

ich habe (erstmal) eine eher theoretische Frage: kann ich Apache 2 mal
starten? Ich meine nicht, dass der Apache 2 mehrere Prozesse belegt, das
macht er doch sowieso, sondern ich möchte, dass der Apache mit 2
verschiedenen Konfigurationen und was noch wichtiger ist, unter 2
verschiedenen UID gestartet werden kann. Momentan läuft bei mir der
Apache unter der UID www-data. Ich verwende ein Debian Lenny.

Hintergrund dieser Überlegung ist, dass die Administration weitestgehend
per Webinterface stattfinden soll. Andererseits wird jedem User auch ein
html_public-Verzeichnis bereitgestellt, wo PHP verfügbar ist. Anzahl der
Accounts > 500.

Nun ist es ja so, wenn ich Webmin nutzen würde, dann würde die
Administration ja auf einem anderen Webserver und damit auch unter einer
anderen UID ablaufen. Damit hätte die User keine Chance, z.B. mittels
eigener PHP-Scripte irgendetwas unter der UID des 2. Webservers
auszuführen, weil dann sudo unterscheiden könnte. Nun steht bei uns aber
Webmin als 2. Webserver nicht zur Debatte, sondern da wir uns nur
(leidlich) mit Apache auskennen, sollte es (wenn möglich) ein 2. Apache
sein.

Meine Frage: kann mir/uns da jemand weiterhelfen?

Ich würde mich über Antworten sehr freuen.

Mit freundlichen Grüßen aus Saalfeld
Hans-Dietrich



From ml-tlug at vdazone.org  Sun Dec  6 21:01:31 2009
From: ml-tlug at vdazone.org (Mario Lorenz)
Date: Sun, 6 Dec 2009 21:01:31 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B1BC505.6040506@gmx.de>
References: <4B1BC505.6040506@gmx.de>
Message-ID: <20091206200130.GB17492@whitebox.dl5mlo.de>

Am 06. Dec 2009, um 15:51:49 schrieb Hans-Dietrich Kirmse:
> Hallo,
> 
> ich habe (erstmal) eine eher theoretische Frage: kann ich Apache 2 mal
> starten? Ich meine nicht, dass der Apache 2 mehrere Prozesse belegt, das
> macht er doch sowieso, sondern ich möchte, dass der Apache mit 2
> verschiedenen Konfigurationen und was noch wichtiger ist, unter 2
> verschiedenen UID gestartet werden kann. Momentan läuft bei mir der
> Apache unter der UID www-data. Ich verwende ein Debian Lenny.

Du kannst pro User einen Apache starten, kein Problem. Separate Log-Dirs,
separate Config-Dirs und vor allem: Jede Instanz muss eine eigene IP
haben (Sonst weiss Linux nicht, an welchen Prozess die Daten gehen soll...)
Das ist idR. so das K.O.-Kriterium.

Ausserdem, bei > 500 Accounts sind das dann aber 500 * anzWorker Prozesse,
das wird dann ggf. auch speichertechnisch schon etwas unangenehm.

Ich hab mal überlegt, das IP-Problem mittels eines Reverse-Proxies zu lösen,
aber die vielen Prozesse waren mir dann doch zu heftig, so das ich lieber auf mod_php
verzichtet habe.

> 
> Hintergrund dieser Überlegung ist, dass die Administration weitestgehend
> per Webinterface stattfinden soll. Andererseits wird jedem User auch ein
> html_public-Verzeichnis bereitgestellt, wo PHP verfügbar ist. Anzahl der
> Accounts > 500.

Das grundlegende Problem ist wohl nicht php, sondern eher mod_php,
bzw. - generell - mod_*

Versuch es mit CGI, und nimm suexec. Für alles andere hab ich noch keine
funktionierende, ressourcenschonende, sichere Lösung gesehen.
(pick any two).

Mario
-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
Trust the computer industry to shorten "Year 2000" to Y2K.  It was this kind
of thinking that caused the problem in the first place.

From hd.kirmse at gmx.de  Sun Dec  6 21:40:23 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Sun, 06 Dec 2009 21:40:23 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <20091206200130.GB17492@whitebox.dl5mlo.de>
References: <4B1BC505.6040506@gmx.de>
	<20091206200130.GB17492@whitebox.dl5mlo.de>
Message-ID: <4B1C16B7.3080007@gmx.de>

Hallo Mario,

danke für deine (aus meiner Sicht sehr erfreuliche) Antwort.

Mario Lorenz schrieb:

>> ich habe (erstmal) eine eher theoretische Frage: kann ich Apache 2 mal
>> starten? ...
> 
> Du kannst pro User einen Apache starten, kein Problem. Separate Log-Dirs,
> separate Config-Dirs und vor allem: Jede Instanz muss eine eigene IP
> haben (Sonst weiss Linux nicht, an welchen Prozess die Daten gehen soll...)
> Das ist idR. so das K.O.-Kriterium.

da es um einen eigenen (Schul-)Server geht, stehen uns alle
Konfigurationsoptionen offen, einschließlich der Verwendung/Vergabe von
IPs.

> Ausserdem, bei > 500 Accounts sind das dann aber 500 * anzWorker Prozesse,
> das wird dann ggf. auch speichertechnisch schon etwas unangenehm.

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.

>> Hintergrund dieser Überlegung ist, dass die Administration weitestgehend
>> per Webinterface stattfinden soll. Andererseits wird jedem User auch ein
>> html_public-Verzeichnis bereitgestellt, wo PHP verfügbar ist. Anzahl der
>> Accounts > 500.
> 
> Das grundlegende Problem ist wohl nicht php, sondern eher mod_php,
> bzw. - generell - mod_*

ja.

> Versuch es mit CGI, und nimm suexec. 

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.

> Für alles andere hab ich noch keine
> funktionierende, ressourcenschonende, sichere Lösung gesehen.

Es geht ums 2 Instanzen. Sicher wird der 2. Apache mehr Ressourcen
schlucken als z.B. ein Webmin-Server (standalone betrieben), aber es
sollte für hinreichend neue Server-Hardware vertretbar sein. Der
Sicherheitsgewinn eines speziellen Servers für ein webbasiertes
Administrationsinterface ist m.E. sehr hoch.

Aber jetzt steht die Frage, wie installiert man einen 2. Apache und wie
richtet man den ein? Habe es gerade probiert, bei einem 2. Aufruf von
   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?

Würde mich über weitere Ideen/Vorschläge freuen.

Mit freundlichen Grüßen
Hans-Dietrich




From ml-tlug at vdazone.org  Sun Dec  6 22:48:19 2009
From: ml-tlug at vdazone.org (Mario Lorenz)
Date: Sun, 6 Dec 2009 22:48:19 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B1C16B7.3080007@gmx.de>
References: <4B1BC505.6040506@gmx.de>
	<20091206200130.GB17492@whitebox.dl5mlo.de>
	<4B1C16B7.3080007@gmx.de>
Message-ID: <20091206214818.GA17642@whitebox.dl5mlo.de>

Am 06. Dec 2009, um 21:40:23 schrieb Hans-Dietrich Kirmse:

Hallo Hans-Dietrich,

> >>ich habe (erstmal) eine eher theoretische Frage: kann ich Apache 2 mal
> >>starten? ...
> >
> >Du kannst pro User einen Apache starten, kein Problem. Separate Log-Dirs,
> >separate Config-Dirs und vor allem: Jede Instanz muss eine eigene IP
> >haben (Sonst weiss Linux nicht, an welchen Prozess die Daten gehen soll...)
> >Das ist idR. so das K.O.-Kriterium.
> 
> da es um einen eigenen (Schul-)Server geht, stehen uns alle
> Konfigurationsoptionen offen, einschließlich der Verwendung/Vergabe von
> IPs.

In der Regel ist man da hardware-limitiert :)

> 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.

> 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. 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.
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...


>   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.

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

Wenn das zufriedenstellend läuft, machst Dus mit einem zweiten /etc/init.d/apache-Script
(was die Kommandozeilenargumente enthält...)

Mario
-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
* This virus needs Windows95 to run!

From hd.kirmse at gmx.de  Mon Dec  7 00:02:27 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 00:02:27 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <20091206214818.GA17642@whitebox.dl5mlo.de>
References: <4B1BC505.6040506@gmx.de>	<20091206200130.GB17492@whitebox.dl5mlo.de>	<4B1C16B7.3080007@gmx.de>
	<20091206214818.GA17642@whitebox.dl5mlo.de>
Message-ID: <4B1C3803.5010703@gmx.de>

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



From linux at eichsfeld.net  Mon Dec  7 07:29:21 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Mon,  7 Dec 2009 07:29:21 +0100
Subject: WG: AW: 2 Instanzen von Apache - geht das, wenn ja - wie?
Message-ID: <T1JHlWwV2s5l.Wtv0Nq1q@syndicat.com>

...und die zweite auch noch:

-- Urspr. Mitt. --
Betreff: AW: 2 Instanzen von Apache - geht das, wenn ja - wie?
Von: "Niels Dettenbach" <nd at syndicat.com>
Datum: 06.12.2009 17:17

...achja,

wahrscheinlich / eventuell möchtest Du auch den Server-Root mit
	-d /pfad/zum/ServerRoot/1

mitgeben.

Wenn Du aber "ganz sicher" gehen willst, baust Du Dir zwei verschiedene Apache mit jeweils nur den "passenden" Funktionen (Module, Features & Co.).

Bei Debian wirst Du da um etwas Handarbeit nicht herumkommen bzw. musst Du Dich um künftige Updates des Apache und "Drumherums" (PHP usw.) selbst kümmern - per Hand oder selbstgebauten "Paketen".

Cheers,

Niels.


From linux at eichsfeld.net  Mon Dec  7 07:34:04 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Mon,  7 Dec 2009 07:34:04 +0100
Subject: WG: AW: 2 Instanzen von Apache - geht das, wenn ja - wie?
Message-ID: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com>

...sorry, die ist gestern wohl nicht über die Liste gegangen:

-- Urspr. Mitt. --
Betreff: AW: 2 Instanzen von Apache - geht das, wenn ja - wie?
Von: "Niels Dettenbach" <nd at syndicat.com>
Datum: 06.12.2009 17:09

Hallo Hans,

sorry für das schräge Quoting - macht mein Telefon leider so.

Ja,
natürlich kann man einen Apache(2) httpd auch mehrfach - mit verschiedenen Konfigurationen und sicher auch verschiedenen Usern - starten.

Fraglich ist nur, ob Du hierzu Deine eigenen Apaches kompilieren musst. Soweit ich sehe betrifft dies nur die betr. Default-Einstellungen - d.h. Du müsstes wohl alle von Dir aufgezählten Dinge auch ohne speziell übersetzes HTTPD binary (d.h. mit Konfigurationsdatei und/oder shell optionen) realisieren können. Ev. macht es aber dennoch Sinn, hier Deinen eigenen httpd zu kompilieren...

Dein Freund dürfte in jedem Fall erstmal:
	man httpd
	man httpd.conf
sein.

Mit -f kannst Du einen relativen (ServerRoot - wohl wie in httpd einkompiliert) oder stattdessen absoluten Pfad zur Konfiguration angeben.

Benutzer und Gruppe gibt man dann in der Konfig per
User www-user1
Group www-group1
an.

Ebenso gilt dies auch für Ports und Interfaces (siehe "Listen").

Allerdings:
Soweit ich webmin kenne, bringt es doch einen eigenen HTTP-Service mit - läuft auf einem eigenen Port (z.B. Default 10000) und hat mit Deinem Apache nix am Hut. Kann natürlich sein, das Du allen Webmin-Traffic zusätzlich durch einen Apache schleifen willst...

Je nach Sicherheitsempfinden lassen sich weitgehend ähnliche Sicherheitsbedingungen aber auch mit allein einem httpd - natürlich entsprechend durchdachter Konfiguration - realisieren. Das aber ist sicher Geschmacksache.

Wenn ich richtig verstehe, planst Du statt z.B. webmin / usermin eine eigene Admin-Anwendung (a la "Confixx", "Plesk" & Co.) für z.B. Deine "Hosting-Anwender" / "-Kunden". Wie "sicher" diese letztendlich ist, hängt wohl hauptsächlich von deren Programmierung / Implementierung selbst ab und was man "sicher" haben möchte. 

Der die Anwendung "treibende" httpd dürfte da weniger das (Sicherheits-)Problem sein - so zumindest einige Erfahrungen mit derart Lösungen.

Wenn Du z.B. einen Großteil der Benutzerkonfigurationen und -Rechte (sagen wir mal AAA) über LDAP bzw. eine SQL-Datenbank regelst, benötigt der betr. httpd für das Management nur "minimale" Rechte (muß aber immerhin Zugriff auf die DB bzw. LDAP bekommen...).

Leider habe ich lange nicht alle ./configure Optionen für den aktuellen Apache im Kopf, aber zur "Maximierung" der Sicherheit in Deinem Sinne macht es ev. Sinn, möglichst viele unnötige Features gar nicht erst einzukompilieren oder (wo möglich) einige "feste" Vorgaben einzubauen - möglicherweise auch einen chroot zu verwenden. Ob und wo das Sinn macht, hängt sehr von Deinem Konzept ab, das wir natürlich alle nicht im Detail kennen. 

Eine letzte Option wäre auch, das Management wie (auch) die "Benutzerkonfigurationen" /"-rechte" (AAA) je auf einem eigenen Server - physikalisch oder virtualisiert halt - zu bringen.

Viel Glück soweit.
hth
Cheers,

Niels.
---
Niels Dettenbach
http://www.syndicat.com

-- Urspr. Mitt. --
Betreff: 2 Instanzen von Apache - geht das, wenn ja - wie?
Von: Hans-Dietrich Kirmse <hd.kirmse at gmx.de>
Datum: 06.12.2009 15:52

Hallo,

ich habe (erstmal) eine eher theoretische Frage: kann ich Apache 2 mal
starten? Ich meine nicht, dass der Apache 2 mehrere Prozesse belegt, das
macht er doch sowieso, sondern ich möchte, dass der Apache mit 2
verschiedenen Konfigurationen und was noch wichtiger ist, unter 2
verschiedenen UID gestartet werden kann. Momentan läuft bei mir der
Apache unter der UID www-data. Ich verwende ein Debian Lenny.

Hintergrund dieser Überlegung ist, dass die Administration weitestgehend
per Webinterface stattfinden soll. Andererseits wird jedem User auch ein
html_public-Verzeichnis bereitgestellt, wo PHP verfügbar ist. Anzahl der
Accounts > 500.

Nun ist es ja so, wenn ich Webmin nutzen würde, dann würde die
Administration ja auf einem anderen Webserver und damit auch unter einer
anderen UID ablaufen. Damit hätte die User keine Chance, z.B. mittels
eigener PHP-Scripte irgendetwas unter der UID des 2. Webservers
auszuführen, weil dann sudo unterscheiden könnte. Nun steht bei uns aber
Webmin als 2. Webserver nicht zur Debatte, sondern da wir uns nur
(leidlich) mit Apache auskennen, sollte es (wenn möglich) ein 2. Apache
sein.

Meine Frage: kann mir/uns da jemand weiterhelfen?

Ich würde mich über Antworten sehr freuen.

Mit freundlichen Grüßen aus Saalfeld
Hans-Dietrich




From david.schueler at tel-billig.de  Mon Dec  7 11:22:52 2009
From: david.schueler at tel-billig.de (David Schueler)
Date: Mon, 7 Dec 2009 11:22:52 +0100
Subject: Antwort: 2 Instanzen von Apache - geht das, wenn ja - wie?
Message-ID: <OF5EA6213E.3735BD22-ONC1257685.00390309-C1257685.0038F772@tel-billig.de>

tlug_allgemein-bounces at tlug.de wrote on 12.06.2009 03:51:49 PM:

> Hallo,
> 
> ... Apache 2 Mal ...
> ... Admin Interface ...
> ... Schulserver ...
> 
> Mit freundlichen Grüßen aus Saalfeld
> Hans-Dietrich 

Sorry wenn ich mich etwas unbeholfen einmische.

Wenn Du nur für Admin-Zwecke ein Interface brauchst und probleme hast 
Apache zum "doppellauf" zu bewegen warum nutzt du für diesen 
Verwaltungszweck nicht einfach einen anderen, kleineren, schlankeren 
Webserver wie z.B. lighttpd? Die Vorteile liegen meines Erachtens auf der 
Hand:
- kein großer Konfigurationsaufwand
- problemlos auch unter einer anderen UID startbar
- unabhänig von der Apache-config, -basepath, -php_modules etc.
- unabhängig von einer zweiten IP (einach auf einem anderen Port [81?] 
lauschen lassen)

Meiner Meinung nach ist das die sicherere Alternative. Anyone?

David.

From chorn at fluxcoil.net  Mon Dec  7 11:32:17 2009
From: chorn at fluxcoil.net (Christian Horn)
Date: Mon, 7 Dec 2009 11:32:17 +0100
Subject: Antwort: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <OF5EA6213E.3735BD22-ONC1257685.00390309-C1257685.0038F772@tel-billig.de>
References: <OF5EA6213E.3735BD22-ONC1257685.00390309-C1257685.0038F772@tel-billig.de>
Message-ID: <20091207103217.GA29994@fluxcoil.net>

On Mon, Dec 07, 2009 at 11:22:52AM +0100, David Schueler wrote:
> 
> Wenn Du nur für Admin-Zwecke ein Interface brauchst und probleme hast 
> Apache zum "doppellauf" zu bewegen warum nutzt du für diesen 
> Verwaltungszweck nicht einfach einen anderen, kleineren, schlankeren 
> Webserver wie z.B. lighttpd? Die Vorteile liegen meines Erachtens auf der 
> Hand:
> - kein großer Konfigurationsaufwand
> - problemlos auch unter einer anderen UID startbar
> - unabhänig von der Apache-config, -basepath, -php_modules etc.
> - unabhängig von einer zweiten IP (einach auf einem anderen Port [81?] 
> lauschen lassen)

Wenn man erfahrung mit dem Apachen hat ist das ein Argument 
diesen in 2 instanzen zu fahren.
Ich wuerde um 2 instanzen zu benutzen den apachen 2x aus sourcen
kompilieren mit unterschiedlichen prefixen:
  ./configure --prefix=/opt/apache1 [other options]
  ./configure --prefix=/opt/apache2 [other options]

Die nach installation vorgefundenen configs sind schon auf unab-
haengigen betrieb ausgerichtet, nach config verschiedener 'Listen'-
angaben in beiden httpd.conf duerften beide Instanzen schon laufen.

Externe module wie php muessten noch angebunden werden.
Aufwand zum beseitigen von sicherheitsproblemen bei apache/php 
waere auch hoeher; distributionsmittel wuerden hier ja nicht benutzt,
gefixte versionen waeren manuell zu installieren.


Christian

From hd.kirmse at gmx.de  Mon Dec  7 18:43:20 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 18:43:20 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com>
Message-ID: <4B1D3EB8.5020607@gmx.de>

Hallo Niels,

Niels Dettenbach schrieb:

> Ja, natürlich kann man einen Apache(2) httpd auch mehrfach - mit
> verschiedenen Konfigurationen und sicher auch verschiedenen Usern -
> starten.

ja, jetzt geht es nur noch darum, dass auch gebacken zu bekommen.

> Fraglich ist nur, ob Du hierzu Deine eigenen Apaches kompilieren
> musst.

dann würde diese Variante ohne Erbarmen gestrichen. Ich sehe mich
durchaus als Linux-Anfänger. Das ist einfach dadurch gekommen, dass ich
Arktur eingesetzt hatte und der hat nunmal eine so "lehrersichere"
Oberfläche, dass man im Gegensatz zu vielen anderen (Schul-)Server-
Lösungen sich nicht erst mit Linux auseinandersetzen muss, um diesen
Server zu betreuen. Dummerweise wird der Server nicht mehr geflegt. Da
es keine wirkliche Alternative gibt, hat sich eine kleine Gruppe
drangemacht, Arktur nachzubauen. - Nur, wir sind bis auf ganz wenige
Ausnahmen eben Laien. Deswegen, wir bleiben so nahe wie möglich am
Original und compilieren entfällt (selbst wenn wir es könnten).

> Dein Freund dürfte in jedem Fall erstmal: man httpd man httpd.conf 
> sein.

Hm. Hier schlagen meine mangelhaften Englischkenntnisse zu. Und mit über
50 Jahren will ich mir nicht auch noch Englisch antun. Deswegen bin ich
in deutschsprachigen Listen ;)

  :

> Wenn ich richtig verstehe, planst Du statt z.B. webmin / usermin eine
> eigene Admin-Anwendung (a la "Confixx", "Plesk" & Co.) 

im Prinzip ja. Ich erstelle (habe erstellt) die Scripte zur User- und
Rechnerverwaltung (Perl-Scripte) und ein anderer Kollege erstellt das
Webinterface dazu (in PHP), genauer gesagt portiert er (s)eine schon
vorhandene Lösung für Arktur 4 auf diesen neuen Server.

> für z.B. Deine
> "Hosting-Anwender" / "-Kunden". Wie "sicher" diese letztendlich ist,
> hängt wohl hauptsächlich von deren Programmierung / Implementierung
> selbst ab und was man "sicher" haben möchte.
> 
> Der die Anwendung "treibende" httpd dürfte da weniger das
> (Sicherheits-)Problem sein - so zumindest einige Erfahrungen mit
> derart Lösungen.

Das sehe ich ganz und gar nicht so. Das zu diskutieren wäre die Sache
wert, weil m.E. eine gute Argumentation dafür erst eine sinnvolle
Entscheidung für oder gegen diese Lösung (mit den 2 Apache-Instanzen)
ermöglicht.

> Wenn Du z.B. einen Großteil der Benutzerkonfigurationen und -Rechte
> (sagen wir mal AAA) über LDAP bzw. eine SQL-Datenbank regelst,
> benötigt der betr. httpd für das Management nur "minimale" Rechte
> (muß aber immerhin Zugriff auf die DB bzw. LDAP bekommen...).

und genau darum gehts. Dazu braucht man sudo. Und dann steht eben
in der sudoers sowas wie:

~~~~~

# Cmnd alias specification
Cmnd_Alias  DELIXS=/usr/local/sbin/delixs-userlist,\
                    /usr/local/sbin/delixs-useradd,\
                    /usr/local/sbin/delixs-userdel, ...

# User alias specification
root	    ALL=(ALL) ALL
www-data    ALL=NOPASSWD:DELIXS

~~~~~

Das bedeutet doch erstmal, dass www-data die Möglichkeit hat, Scripte
zur Userverwaltung mit root-Rechten auszuführen. Das User mit selbst
geschriebenen PHP-Scripten in den "Userdirs" damit prinzipiell auch
unter dieser UID auf diese Scripte zugreifen könnten wird doch nur durch
(hoffentlich korrekte) Konfiguration von PHP sichergestellt. Und da ist
die korrekte Kofniguration schon unter Experten recht strittig.
Umso schwerer wiegt die Tatsache, dass ein Admin bei der Installation
sehr leicht geneigt sein könnte, an dieser Konfiguration zu schrauben,
um irgendwelche PHP-Lösungen zum Laufen zu bringen. Und nicht zuletzt,
diesen ganzen Zinnober bekommen wir nochmal, wenn es um Python oder Java
(als Modul) geht.

Wenn aber www-data die UID des Apache ist, auf dem die nur das Admin-
Webinterface läuft und der Apache mit den Userdirs unter einer anderen
UID läuft, dann kann doch auch bei Fehlkonfiguration von PHP kein User
auf diese User-Scripte zugreifen. Das denke ich immernoch. Und m.E. ist
das ein sehr deutlicher Sicherheitsgewinn. - Wo denke ich da falsch?

MfG Hans-Dietrich



From hd.kirmse at gmx.de  Mon Dec  7 18:44:49 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 18:44:49 +0100
Subject: WG: AW: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <T1JHlWwV2s5l.Wtv0Nq1q@syndicat.com>
References: <T1JHlWwV2s5l.Wtv0Nq1q@syndicat.com>
Message-ID: <4B1D3F11.5050105@gmx.de>

Auch hierzu einen Kommentar:

Niels Dettenbach schrieb:

> Wenn Du aber "ganz sicher" gehen willst, baust Du Dir zwei
> verschiedene Apache mit jeweils nur den "passenden" Funktionen
> (Module, Features & Co.).

ja, dass würden wir (ich) dann auf jeden Fall machen.

> Bei Debian wirst Du da um etwas Handarbeit nicht herumkommen bzw.
> musst Du Dich um künftige Updates des Apache und "Drumherums" (PHP
> usw.) selbst kümmern - per Hand oder selbstgebauten "Paketen".

verstehe ich jetzt zwar nicht. Wenn ein Debian-Paket eingespielt (und
auch removed) wird, dann haben doch die Konfigurationsdateien nicht
angefasst zu werden, dachte ich bis jetzt. Die Binaries und Bibliotheken
von Apache können und sollen ja durch ein Update aktualisiert werden. Da
Apache ja nur einmal installiert wurde, sollten das Aktualisieren gehen.
Beim Löschen (purgen) sehe ich allerdings Probleme. - da müßte man dann
halt von Hand nachhelfen.

MfG Hans-Dietrich




From hd.kirmse at gmx.de  Mon Dec  7 18:45:48 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 18:45:48 +0100
Subject: Antwort: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <OF5EA6213E.3735BD22-ONC1257685.00390309-C1257685.0038F772@tel-billig.de>
References: <OF5EA6213E.3735BD22-ONC1257685.00390309-C1257685.0038F772@tel-billig.de>
Message-ID: <4B1D3F4C.6070704@gmx.de>

Hallo David,

David Schueler schrieb:

> Wenn Du nur für Admin-Zwecke ein Interface brauchst und probleme hast 
> Apache zum "doppellauf" zu bewegen warum nutzt du für diesen 
> Verwaltungszweck nicht einfach einen anderen, kleineren, schlankeren 
> Webserver wie z.B. lighttpd? Die Vorteile liegen meines Erachtens auf der 
> Hand:
> - kein großer Konfigurationsaufwand
> - problemlos auch unter einer anderen UID startbar
> - unabhänig von der Apache-config, -basepath, -php_modules etc.
> - unabhängig von einer zweiten IP (einach auf einem anderen Port [81?] 
> lauschen lassen)

prinzipiell richtig. Aber: ein neues System braucht Einarbeitungsaufwand
- überigens würde ich dafür nicht verantwortlich sein. Also
Arbeitsaufwand, den ich anderen zumuten würde. Und die Betreuung von 2
gleichen Lösungen hat (arbeitsmäßig) auch seine Vorteile.

Allerdings, wenn es (von mir) nicht hinzubekommen ist, dann wäre diese
Variante eine schon einkalkulierte Alternative.

> Meiner Meinung nach ist das die sicherere Alternative. Anyone?

Ich weiss nicht, warum diese Variante sicherer ist. Die Test-Basis von
Apache scheint mir deutlich höher zu sein.

MfG Hans-Dietrich



From hd.kirmse at gmx.de  Mon Dec  7 18:46:45 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 18:46:45 +0100
Subject: Antwort: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <20091207103217.GA29994@fluxcoil.net>
References: <OF5EA6213E.3735BD22-ONC1257685.00390309-C1257685.0038F772@tel-billig.de>
	<20091207103217.GA29994@fluxcoil.net>
Message-ID: <4B1D3F85.1070508@gmx.de>

Hallo Christian,

Christian Horn schrieb:

> Wenn man erfahrung mit dem Apachen hat ist das ein Argument 

dann werden wir in dieser Hinsicht die Erfahrungen sammeln ;)

> diesen in 2 instanzen zu fahren.
> Ich wuerde um 2 instanzen zu benutzen den apachen 2x aus sourcen
> kompilieren mit unterschiedlichen prefixen:
>   ./configure --prefix=/opt/apache1 [other options]
>   ./configure --prefix=/opt/apache2 [other options]

wie schon in der anderen Mail geschrieben - es geht um einen Nachfolger
von Arktur 4, also eine Schulserver-Distribution. Arktur4 soll abgelöst
werden, weil die Betreuung nicht mehr gewährleistet ist. Irgendwie muss
man auch die Lehren aus der Sache ziehen. Wenn wir (soweit
irgendmöglich) Debian stable so nehmen wie es bereitgestellt wird, dann
ist der Arbeits- und Pflegeaufwand minimiert. Letztlich wird bis auf die
schulspezifischen Erweiterungen der Support auf die Debian-Entwicklung
"abgewälzt". Kurz und gut: compilieren ist für uns tabu.

MfG Hans-Dietrich




From rob at rob-schulze.de  Mon Dec  7 19:12:53 2009
From: rob at rob-schulze.de (Robert Schulze)
Date: Mon, 07 Dec 2009 19:12:53 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B1D3EB8.5020607@gmx.de>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com> <4B1D3EB8.5020607@gmx.de>
Message-ID: <4B1D45A5.7050300@rob-schulze.de>

Hallo,

Hans-Dietrich Kirmse schrieb:
> 
> Das bedeutet doch erstmal, dass www-data die Möglichkeit hat, Scripte
> zur Userverwaltung mit root-Rechten auszuführen. Das User mit selbst
> geschriebenen PHP-Scripten in den "Userdirs" damit prinzipiell auch
> unter dieser UID auf diese Scripte zugreifen könnten wird doch nur durch
> (hoffentlich korrekte) Konfiguration von PHP sichergestellt. Und da ist
> die korrekte Kofniguration schon unter Experten recht strittig.

Fast unmöglich würde ich persönlich behaupten.
In PHP kommen immer wieder Sicherheitslücken raus, bei denen die
jeweilige Konfiguration umgangen werden kann.

Wie bereits am Anfang des Threads beschrieben: nimm suexec, dort läuft
der PHP-Prozess immer unter dem Kontext des Benutzers - er kann dies
nicht umgehen und sehr wenig kaputt machen.

Stichwörter wie "langsam" kannst du bequem ad acta legen, insbesondere
in so einem kleinen Setup. Sicherlich gibt es Anforderungsbereiche, in
denen mod_php angebracht ist, jedoch ist die sicherste und vor allem
stabilere (da PHP nicht im Webserver drinsteckt) Lösung die mit suexec.

Das hat auch nix damit zu tun, ob man nun noch auf eine DB zugreifen
will oder sonstwas. Hinsichtlich des Funktionsumfangs wird ein Skript
nicht beschnitten, wenn es als gesonderter Prozess läuft.


Beste Grüße,
Rob

From hd.kirmse at gmx.de  Mon Dec  7 20:25:06 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 20:25:06 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B1D45A5.7050300@rob-schulze.de>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com> <4B1D3EB8.5020607@gmx.de>
	<4B1D45A5.7050300@rob-schulze.de>
Message-ID: <4B1D5692.80100@gmx.de>

Hallo Robert,

Robert Schulze schrieb:
> Hallo,
> 
> Hans-Dietrich Kirmse schrieb:
>> Das bedeutet doch erstmal, dass www-data die Möglichkeit hat, Scripte
>> zur Userverwaltung mit root-Rechten auszuführen. Das User mit selbst
>> geschriebenen PHP-Scripten in den "Userdirs" damit prinzipiell auch
>> unter dieser UID auf diese Scripte zugreifen könnten wird doch nur durch
>> (hoffentlich korrekte) Konfiguration von PHP sichergestellt. Und da ist
>> die korrekte Kofniguration schon unter Experten recht strittig.
> 
> Fast unmöglich würde ich persönlich behaupten.
> In PHP kommen immer wieder Sicherheitslücken raus, bei denen die
> jeweilige Konfiguration umgangen werden kann.

und das bedeutet doch, wenn die Konfiguration (fast) keine rolle für die
Sicherheit mehr spielt, das es einen erheblichen Sicherheitsgewinn gibt
- oder?

> Wie bereits am Anfang des Threads beschrieben: nimm suexec, dort läuft
> der PHP-Prozess immer unter dem Kontext des Benutzers - er kann dies
> nicht umgehen und sehr wenig kaputt machen.

diese Argumentation gehe ich mit. Aber trotzdem werde ich das nicht
durchsetzen können. Ich bin der Perl-Programmierer und werde wohl kaum
den PHP-Programmierern ihre Konfiguration "madig" machen können. Zudem
hat sich diese in 10 Jahren Schulserverpraxis ja bewährt (was aber
hinsichtlich Sicherheit m.E. nichts zu sagen hat). Nur, ich werde so
nicht überzeugen können.

> Stichwörter wie "langsam" kannst du bequem ad acta legen, insbesondere
> in so einem kleinen Setup. Sicherlich gibt es Anforderungsbereiche, in
> denen mod_php angebracht ist, jedoch ist die sicherste und vor allem
> stabilere (da PHP nicht im Webserver drinsteckt) Lösung die mit suexec.
> 
> Das hat auch nix damit zu tun, ob man nun noch auf eine DB zugreifen
> will oder sonstwas. Hinsichtlich des Funktionsumfangs wird ein Skript
> nicht beschnitten, wenn es als gesonderter Prozess läuft.

alles okay, aber bei Teamarbeit ist eben auch zu beachten, das jeder für
seinen Bereich zuständig ist. die Lösung mit den 2 Instanzen ändert an
der eigentlichen Lösung nichts (allerdings muss sie funktionieren, was
sie momentan nicht macht).

Trotzdem nochmal auf dein Argument zurück zu kommen: angenommen es
werden neue Sicherheitslücken bekannt. Wie sieht bei dieser 2-Instanzen-
Lösung dann das Bedrohungsszenario aus? Ich denke, ob PHP als Modul oder
nicht, der Zugriff (mittels sudoers) auf Scripte die dann mit root-
Rechten ausgeführt werden, wäre nicht mehr möglich. Und genau das ist
der von mir angedachte/erhoffte Sicherheitsgewinn. - Nochmal meine
Frage: wo denke ich da falsch?

Mit freundlichen Grüßen
Hans-Dietrich




From linux at eichsfeld.net  Mon Dec  7 20:31:06 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Mon,  7 Dec 2009 20:31:06 +0100
Subject: AW: Re:  2 Instanzen von Apache - geht das, wenn ja - wie?
Message-ID: <RHK2KcDSnVGZ.h9VTy9xC@syndicat.com>

...hmmm,

hab zwar derzeit nur mit wenigen Debian Systemen eingehender zu tun, versuche aber mal Dir ein möglichst "einfaches" Setup vorzuschlagen / zu erklären:

Erstmal brauchst Du zwei verschiedene "ServerRoot" Verzeichnisse. Per Standard gibt Debian wohl /etc/apache vor.

Nehmen wir mal an, Du verwendest für Server1 die Standard-Konfiguration mit:
	ServerRoot /etc/apache
	DocumentRoot /var/www

Der Server läuft unter
	User www-data
	group www-data

Der Einfachheit halber verwenden wir den selben httpd wie die selben Module - du kannst ja per httpd.conf für jeden der Apaches festlegen, welcher er laden soll etc.

Für den zweiten server gehst Du in etwa wie folgt vor:

User und Gruppe für den 2. Server anlegen - z.B:
	User www-admin
	Group www-admin

dann kopierst Du z.B. die Standard-Konfig für den neuen Server:
	cp -Rpv /etc/apache /etc/apache-admin
	
(d.h. deinen zweiten Webserver konfigurierst Du in /etc/apache-admin)
Dann legst Du das DocumentRoot für Deinen zweiten Server an - z.B:
	mkdir /var/www-admin
	chgrp www-admin /var/www-admin
	chmod g+rx /var/www-admin

Dorthinein packst Du dann z.B. Deine index.html oder anderen Web-Stoff, den Du per dem Apache anbieten willst.

Dann wechselst Du in das neue Konfig-Verzeichnis /etc/apache-admin
und passt die httpd.conf Deinen Vorstellungen für den zweiten Apache an - wichtig dabei sind auf jeden Fall:
	ServerRoot /etc/apache-admin
	DocumentRoot /var/www-admin
	User www-admin
	Group www-admin
mit
	Listen 8888
lässt Du den Apache (statt an Standard 80- der ist ja schon vom 1. Apache belegt) Port 8888 lauschen (an allen IPs / Interfaces). Alternativ kannst Du auch mehrere IP-Adressen am ethernet-Port Deiner Maschine festlegen (aliase) und jeden der Server nur auf eine der IPs flanschen:
	Listen 10.10.11.2:80

Die Pfade für ev. Logfiles solltest Du auch ändern - z.B. nach /var/log/apache-admin (der Ordner sollte zuvor ggf. mit 
	mkdir /var/log/apache-admin 
angelegt und ggf. mit 
	chmod g+rwx /var/log/apache-admin
	chgrp www-admin /var/log/apache-admin
dem neuen Apache zugänglich gemacht werden).

Dann brauchst Du nur noch für den Start des zweiten Servers sorgen - das sollte mit
	apache2 -d /etc/apache-admin
bzw. 
	httpd -d /etc/apache-admin

erledigt sein.

Der Apache liest damit Deine Konfig aus /etc/apache-admin/httpd.conf . Alles weitere konfigurierst Du halt dort.

Sollte sich nochwas ungewollt überschneiden / blockieren, sollte es Fehlermeldungen geben (macht deshalb wohl Sinn, den ersten Apache schon mal laufen zu haben).

Die Debian-Startscripte hab ich nicht zur Hand, möglicherweise kannst Du das Standard-Init-Script /etc/init.d/apache2 nach z.B. /etc/init.d/apache2-admin kopieren  und auf die betr. Pfade Deines zweiten Servers umschreiben.

Vielleicht helfen Dir ja diese paar Zeilen etwas weiter - auf jeden Fall viel Glück!
Cheers,

Btw:
Aus meiner persönlichen Erfahrung kann ich Gentoo Linux als das wohl "ultimative Lern- und Anwendersystem" für Ein- oder Umsteiger, die langsam aber sukzessive Linux lernen - dabei aber von Beginn an damit arbeiten / es anwenden wollen - empfehlen. 

Es ist ebenso flexibel wie gut (vom kleinen Taschen Livesystem über Desktops, Server(-Farmen) bis hin zu komplexesten Netzwerken) - in verschiedensten Projekten und Wikis - dokumentiert (auch auf deutsch ;). Natürlich ist alles irgendwie Geschmacksache - aber als echtes "Lernsystem" taugt es sicher allemal mehr, als die meisten heutigen Distris. Was man lernt, kann man so auch ähnlich unter anderen Unixoiden (*BSDs, MAC OSX) / Linuxen (z.B. pkgsrc, pkgsrc-wip) anwenden bzw. wiederfinden. 

Schon das Standard-Installationshandbuch ist wie ein Linux-Grundkurs aufgebaut (dennoch beim ersten mal binnen 0,5-3h zu durchlaufen) - Und: ganz OHNE Lernen geht es sicher nie - egal welches System man warum und wie weit zu administrieren hat. Fraglich ist halt Zeit und Aufwand, die man investieren kann oder möchte - und dafür dauerhaft behalten möchte. Was man aber einmal weiß, kann man nicht mehr wegnehmen... ;)

Niels.
---
http://www.syndicat.com


From hd.kirmse at gmx.de  Mon Dec  7 20:32:16 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 20:32:16 +0100
Subject: apache
Message-ID: <4B1D5840.1010600@gmx.de>

Hi,

da ich die 2. Instanz des apache einfach nicht zum Starten bekomme, mal
die Frage: wie kann man herausbekommen, welche Einstellungen in den
Apache eincompiliert sind?

MfG Hans-Dietrich




From linux at eichsfeld.net  Mon Dec  7 20:54:15 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Mon,  7 Dec 2009 20:54:15 +0100
Subject: AW: Re: 2 Instanzen von Apache - geht das, wenn ja - wie?
Message-ID: <s1NF13NfxbtZ.nctyK5wR@syndicat.com>

...nur mal ein kleiner, genereller Hinweis:

Wozu brauchen die Admin-Scripte am Webserver (PHP) überhaupt irgendwo irgendwelche Root-Rechte (z.B. sudo)? Die Gefahren sind immerhin enorm - und auch Schüler lernen irgendwann mal was (dazu). ;)

Die geläufigen Berechtigungen und die meisten damit verbundenen Komfigurationen kann man - soweit ich überlegen kann - auch ohne Root / Sudo realisieren. Z.B. kann man seine Benutzerdaten / -rechte gut und gern in eine SQL-DB legen oder mit LDAP realisieren. Die Admin-Anwendung braucht dann zwar Zugriff auf die (damit kritische) DB oder LDAP, aber am drunterliegenden System selbst (was davon getrennt arbeiten kann) keinerlei sonderliche Rechte. 

Mit einem (unter root o.ä.) laufenden Daemon kann man dann - wenn noch nötig - automatisiert z.B. "Home-"Verzeichnisse erzeugen oder wegräumen lassen. Der Daemon bedient sich dazu aus der Datenbank und / oder wird vom Admin-GUI lediglich "angestoßen" o.ä. Ob man aber überhaupt User zu System-Usern machen muß, bleibt für die meisten Anwendungen dahingestellt. PHP ist da eine leidige Ausnahme...

Ggf. macht es in Eurem Setup auch Sinn, die Nutzerapplikationen / Daten in einen / mehrere virtualisierte Hosts oder wenigstens in eine chroot zu packen - die Administration also in eine andere.

Unter FreeBSD erinnere ich mich an eine Konfig bei einem Provider, der mehrere hundert "virtuelle Server" in Form von Jails auf einer Servermaschine (einige Jahre her!) betrieben hat - mit brauchbarer Performance für solcherart Zwecke. Jeder Jail hatte eine eigene IP - jeder Kunde SSH-Zugang zu "seinem" Server etc. Vor allem mit PHP könnte das allerdings allerdings speicherintensiv werden... Zu der Zeit war noch CGI mit Perl üblich...


From linux at eichsfeld.net  Mon Dec  7 21:03:28 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Mon,  7 Dec 2009 21:03:28 +0100
Subject: AW: apache
Message-ID: <Kcpc8srXfXHb.nQJFx5zb@syndicat.com>

Hallo Hans,


das ist eigentlich unwichtig, da:
 - Du alle Einstellungen per ServerRoot (-d pfad) und 
 - der darin liegenden httpd.conf machst

was für eine Fehlermeldung bekommst Du denn?

apache2 -h
ist Dein Freund.

Z.B. zeigt Dir:
	httpd -V
die einkompilierten Settings oder
	apache -l 
die Module usw.

Ich bin mir aber sicher, das Du hier in der Konfigugartion etwas "verbockt" hast. Natürlich kann man einiges aus der Konfig auch mit Übersetzungsoptionen einstellen, aber das muß dann ebenso auch in der Konfig gehen (was ja eigentlich viel leichter / schneller auszuprobieren geht)...

Beste Grüße,

Niels.
---
Niels Dettenbach
http://www.syndicat.com

-- Urspr. Mitt. --
Betreff: apache
Von: Hans-Dietrich Kirmse <hd.kirmse at gmx.de>
Datum: 07.12.2009 20:32

Hi,

da ich die 2. Instanz des apache einfach nicht zum Starten bekomme, mal
die Frage: wie kann man herausbekommen, welche Einstellungen in den
Apache eincompiliert sind?

MfG Hans-Dietrich





From hd.kirmse at gmx.de  Mon Dec  7 21:34:08 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 21:34:08 +0100
Subject: AW: apache
In-Reply-To: <Kcpc8srXfXHb.nQJFx5zb@syndicat.com>
References: <Kcpc8srXfXHb.nQJFx5zb@syndicat.com>
Message-ID: <4B1D66C0.4000709@gmx.de>

Hallo Niels,

Niels Dettenbach schrieb:
> Hallo Hans,
> 
> 
> das ist eigentlich unwichtig, da: - Du alle Einstellungen per
> ServerRoot (-d pfad) und - der darin liegenden httpd.conf machst
> 
> was für eine Fehlermeldung bekommst Du denn?

apache2: bad user name ${APACHE_RUN_USER}


> 
> apache2 -h ist Dein Freund.
> 
> Z.B. zeigt Dir: httpd -V die einkompilierten Settings oder apache -l
>  die Module usw.
> 
> Ich bin mir aber sicher, das Du hier in der Konfigugartion etwas
> "verbockt" hast. 

ich bin gerade dabei, das Setup nochmal zu machen. ich hatte 22
Änderungen vorgenommen. da ich die dokumentiere, dauert das etwas ;)

Ich melde mich heute auf jeden Fall dazu nochmal, egal wie das Ergebnis ist.

MfG Hans-Dietrich




From linux at eichsfeld.net  Mon Dec  7 22:58:01 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Mon,  7 Dec 2009 22:58:01 +0100
Subject: AW: Re: AW: apache
Message-ID: <PJXyY8DmtpbS.SYQmtqnf@syndicat.com>

> bad user name
Demnach gibt es den Usernamen und / oder Gruppe noch nicht.

Bitte nochmal beide angelegten User / Gruppe prüfen - ev nochmal neueinloggen. Klappt das auch nicht, was ist wenn Du andee / bestehende User / Gruppen im httpd,conf angibst?

Achja,
	apache2 -d ....

muß als root user gestartet werden-, damit der Apache den betr. Benutzer annehmen kann.

Cheers,


Niels.



From hd.kirmse at gmx.de  Mon Dec  7 22:53:26 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 22:53:26 +0100
Subject: AW: apache
In-Reply-To: <4B1D66C0.4000709@gmx.de>
References: <Kcpc8srXfXHb.nQJFx5zb@syndicat.com> <4B1D66C0.4000709@gmx.de>
Message-ID: <4B1D7956.30005@gmx.de>

Hans-Dietrich Kirmse schrieb:

>> Ich bin mir aber sicher, das Du hier in der Konfigugartion etwas
>> "verbockt" hast. 
> 
> ich bin gerade dabei, das Setup nochmal zu machen. ich hatte 22
> Änderungen vorgenommen. da ich die dokumentiere, dauert das etwas ;)
> 
> Ich melde mich heute auf jeden Fall dazu nochmal, egal wie das Ergebnis 
> ist.

leider mit demselben Ergebnis. Im Prinzip hatte ich es ja so gemacht, 
nur die Rechte auf die Verzeichnisse hatte ich nicht gesetzt. Allerdings 
den Knackpunkt für dieses Problem habe ich noch nicht gefunden.

Morgen ist auch noch ein Tag.

MfG Hans-Dietrich



From hd.kirmse at gmx.de  Mon Dec  7 22:55:55 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 22:55:55 +0100
Subject: AW: Re: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <s1NF13NfxbtZ.nctyK5wR@syndicat.com>
References: <s1NF13NfxbtZ.nctyK5wR@syndicat.com>
Message-ID: <4B1D79EB.6070603@gmx.de>

und auch dazu noch eine Antwort bzw. Frage. (kann den Standpunkt
leider nicht teilen - oder ich werde hier sehr viel dazulernen)

Niels Dettenbach schrieb:
> ...nur mal ein kleiner, genereller Hinweis:
> 
> Wozu brauchen die Admin-Scripte am Webserver (PHP) überhaupt irgendwo
> irgendwelche Root-Rechte (z.B. sudo)? 

z.B. damit sie in den LDAP schreiben können.

> Die Gefahren sind immerhin
> enorm - und auch Schüler lernen irgendwann mal was (dazu). ;)

ich denke, wenn die Lösung einmal steht, dann haben die Schüler auch mit
noch so viel Lernen keine wirkliche Chance.

> Die geläufigen Berechtigungen und die meisten damit verbundenen
> Komfigurationen kann man - soweit ich überlegen kann - auch ohne Root
> / Sudo realisieren. 

das bezweifel ich (derzeit noch)

> Z.B. kann man seine Benutzerdaten / -rechte gut
> und gern in eine SQL-DB legen oder mit LDAP realisieren. 

hm, ganz dumme Situation. die Daten um die es hier geht (User, Gruppen,
(win-)Rechner, DHCP) sind im LDAP. Und die (Perl-)Scripte, die in den
LDAP schreiben, die habe ich erstellt. Und dazu brauche ich (zumindest
momentan noch) root-Rechte. d.h. aber auch, die PHP-Scripte des
Webinterface müssen mit sudo root-Rechte bekommen.

> Die
> Admin-Anwendung braucht dann zwar Zugriff auf die (damit kritische)
> DB oder LDAP, 

genauso ist es. man braucht ein Passwort, um im LDAP arbeiten zu können.
Dieses Passwort bei uns für "cn=admin,dc=delixs-schule,dc=de" liegt im
Entry dieses Users im LDAP. Damit die Scripte schreiben können, müssen
die sich am LDAP anmelden, mit diesem Account und brauchen dessen
Passwort. Und das muss irgendwo sehr sicher hinterlegt werden.

Das Passwort für den LDAP-Admin, ist bei uns aber nicht in der
slapd.conf hinterlegt. Irgendwo muss ich das Passwort aber herholen,
wenn ich es nicht in jedem Script hinterlegen will (was ja noch
schlimmer wäre). Also hole ich es mir einfach aus der
/etc/pam_ldap.secret, und dazu brauche ich root-Rechte!

für jede bessere Lösung (Idee) wäre ich sehr dankbar!

> aber am drunterliegenden System selbst (was davon
> getrennt arbeiten kann) keinerlei sonderliche Rechte.

naja, wenn ich klassenweise User anlege, dann brauche ich auch
root-Rechte, oder wie geht das sonst? (noch nutze ich die smbldap-tools)

> Mit einem (unter root o.ä.) laufenden Daemon kann man dann - wenn
> noch nötig - automatisiert z.B. "Home-"Verzeichnisse erzeugen oder
> wegräumen lassen. 

wie soll das aussehen? Wenn ich richtig im Bilde bin, da macht es
Skolelinux so, dass ein Cronjob (in der nacht?) die Homeverzeichnisse
anlegt. Das sollte diesem Ansatz so ungefähr entsprechen.

Aber auch da muss der Cronjob das mit root-Rechten aufrufen. Notfalls
auch über sudo. Wo da der Gewinn an Sicherheit ist, kann ich noch nicht
erkennen. Und so richtig sexy ist die Lösung auch nicht, wenn man erst
am nächsten Tag weiss, ob alles korrekt gelaufen ist.

> Der Daemon bedient sich dazu aus der Datenbank und
> / oder wird vom Admin-GUI lediglich "angestoßen" o.ä. 

und auch zu dem Anstoßen braucht man die notwendigen Rechte
(root-Rechte). Oder wie funktioniert dieses Anstoßen?


Bitte alles als Frage verstehen. Ich weiss, dass ich kaum Ahnung habe.
Für jeden konstruktiven Vorschlag bzw. Hinweis, der möglicherweise eine
Verbesserung der Lösung bewirken würde wäre ich sehr dankbar.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Falls es notwendig/sinnvoll ist, sich von der Lösung ein Bild zu machen,
hier die relevanten Links:

zur LDAP- (und Samba-)Installation:

http://www.delixs.de/dwiki/index.php/Entwicklungsumgebung/LDAP
http://www.delixs.de/dwiki/index.php/Entwicklungsumgebung/Samba
http://www.delixs.de/dwiki/index.php/Entwicklungsumgebung/LDAP_Einrichtung


zu diesen (Perl-)Sripten:

https://trac.delixs.de/trac/browser/delixs-scripts/trunk


zur Apache-Installation (nur obere Hälfte):

http://www.delixs.de/dwiki/index.php/Entwicklungsumgebung/Apache


Mit freundlichen Grüßen
Hans-Dietrich





From hd.kirmse at gmx.de  Mon Dec  7 23:18:39 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Mon, 07 Dec 2009 23:18:39 +0100
Subject: AW: Re: AW: apache
In-Reply-To: <PJXyY8DmtpbS.SYQmtqnf@syndicat.com>
References: <PJXyY8DmtpbS.SYQmtqnf@syndicat.com>
Message-ID: <4B1D7F3F.1020707@gmx.de>

Niels Dettenbach schrieb:
>> bad user name
> Demnach gibt es den Usernamen und / oder Gruppe noch nicht.
> 
> Bitte nochmal beide angelegten User / Gruppe prüfen - ev nochmal
> neueinloggen. 

keine Änderung

> Klappt das auch nicht, was ist wenn Du andee /
> bestehende User / Gruppen im httpd,conf angibst?

auch dann nicht. Immer dieselbe Fehlermeldung.

> 
> Achja, apache2 -d ....

klar.

> muß als root user gestartet werden-, damit der Apache den betr.
> Benutzer annehmen kann.

auch das habe ich so gemacht.

Wie schon gesagt, morgen ist auch noch ein Tag.
Danke für deine Unterstützung und deine Geduld.

MfG Hans-Dietrich




From linux at eichsfeld.net  Tue Dec  8 13:02:19 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Tue, 8 Dec 2009 13:02:19 +0100
Subject: AW: Re: AW: apache
In-Reply-To: <4B1D7F3F.1020707@gmx.de>
References: <PJXyY8DmtpbS.SYQmtqnf@syndicat.com> <4B1D7F3F.1020707@gmx.de>
Message-ID: <200912081302.19203.linux@eichsfeld.net>

....also,

hab das - weil's mich mal interessiert hat - soeben nochmal testweise mit 
einem Debian Apache2 ausprobiert und habe da auf den zweiten Blick noch ein 
paar Dinge, die Du beachten solltest - gefunden.

statt
	apache2 -d/etc/apache-admin 

möchte er offenbar nur mit
	apache2 -d/etc/apache-admin  -f /etc/apache-admin/apache2.conf

auch die eigene Konfiguration lesen.

Damit sich beide Apache nicht ins Gehege kommen, musst Du zusätzlich alle 
Pfade wie:
	LockFile /tmp/accept.lock
	PidFile /tmp/apache2.pid

(/tmp ist hier nur ein schlechtes Beispiel und produktiv nicht geeignet - zum 
Ausprobieren aber gut) auf abweichende Pfade bzw. Namen ändern (bitte IN der 
Konfigurationsdatei - nicht in /etc/apache2/envvars!).

Aber auch für die Logausgaben solltest Du eigene Festlegungen treffen - z.B:
	ErrorLog /tmp/error.log 
        CustomLog /tmp/access.log combined

Mit den Maßnahmen hat es zumindest auf meiner Debian-Testumgebung gut 
funktioniert.

Nun zu Deinem gestrigen Problem:
On Monday 07 December 2009 23:18:39 Hans-Dietrich Kirmse wrote:
> Niels Dettenbach schrieb:
> >> bad user name
> >
> > Demnach gibt es den Usernamen und / oder Gruppe noch nicht.
> >
> > Bitte nochmal beide angelegten User / Gruppe prüfen - ev nochmal
> > neueinloggen. 
> keine Änderung

Debian scheint in der Konfiguration normalerweise auf /etc/apache2/envvars
zurückzugreifen, die mit dem Debian Init-Script /etc/init.d/apache2 gelesen 
und ausgewertet wird.

In Deiner Konfigurationsdatei solltest Du deshalb haben:
	        User www-admin
        	Group www-admin
		PidFile /tmp/apache2.pid

(nicht aber die ehem. Variablennamen wie: "User ${APACHE_RUN_USER}" oder 
"Group ${APACHE_RUN_GROUP}" - es sei denn Du schreibst Dir das passende Init-
Script für Deinen Apache dazu - z.B. aus dem Standard-Script 
/etc/init.d/apache2 als "Vorlage"...).

Ich bin kein Freund solcher "verzweigten" Konfigurationen (z.B. auch unter 
Ubuntu "Unsitte") - scheint aber gerade modern zu sein.

Viel Glück!
Beste Grüße,


Niels.

-- 
  Niels Dettenbach
  ---
  Eichsfelder Linux/UNIX Stammtisch (EICLUSt)
  http://linux.eichsfeld.net
  ---
  business: Syndicat IT&Internet - http://www.syndicat.com
  Heilbad Heiligenstadt / Erbil / Cape Town
  ---
  Kryptoinfo: 
  PGP public key ID 651CA20D
  Fingerprint: 55E0 4DCD B04C 4A49 1586  88AE 54DC 4465 651C A20D
  https://syndicat.com/pub_key.asc
  ---

From hd.kirmse at gmx.de  Tue Dec  8 19:16:30 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Tue, 08 Dec 2009 19:16:30 +0100
Subject: apache
In-Reply-To: <200912081302.19203.linux@eichsfeld.net>
References: <PJXyY8DmtpbS.SYQmtqnf@syndicat.com> <4B1D7F3F.1020707@gmx.de>
	<200912081302.19203.linux@eichsfeld.net>
Message-ID: <4B1E97FE.6040001@gmx.de>

Hallo Niels,

Niels Dettenbach schrieb:
> ....also,
> 
> hab das - weil's mich mal interessiert hat - soeben nochmal testweise mit 
> einem Debian Apache2 ausprobiert und habe da auf den zweiten Blick noch ein 
> paar Dinge, die Du beachten solltest - gefunden.
> 
> statt
> 	apache2 -d/etc/apache-admin 
> 
> möchte er offenbar nur mit
> 	apache2 -d/etc/apache-admin  -f /etc/apache-admin/apache2.conf
> 
> auch die eigene Konfiguration lesen.
> 
> Damit sich beide Apache nicht ins Gehege kommen, musst Du zusätzlich alle 
> Pfade wie:
> 	LockFile /tmp/accept.lock
> 	PidFile /tmp/apache2.pid
> 
> (/tmp ist hier nur ein schlechtes Beispiel und produktiv nicht geeignet - zum 
> Ausprobieren aber gut) auf abweichende Pfade bzw. Namen ändern (bitte IN der 
> Konfigurationsdatei - nicht in /etc/apache2/envvars!).
> 
> Aber auch für die Logausgaben solltest Du eigene Festlegungen treffen - z.B:
> 	ErrorLog /tmp/error.log 
>         CustomLog /tmp/access.log combined
> 
> Mit den Maßnahmen hat es zumindest auf meiner Debian-Testumgebung gut 
> funktioniert.
> 
> Nun zu Deinem gestrigen Problem:
> On Monday 07 December 2009 23:18:39 Hans-Dietrich Kirmse wrote:
>> Niels Dettenbach schrieb:
>>>> bad user name
>>> Demnach gibt es den Usernamen und / oder Gruppe noch nicht.
>>>
>>> Bitte nochmal beide angelegten User / Gruppe prüfen - ev nochmal
>>> neueinloggen. 
>> keine Änderung
> 
> Debian scheint in der Konfiguration normalerweise auf /etc/apache2/envvars
> zurückzugreifen, die mit dem Debian Init-Script /etc/init.d/apache2 gelesen 
> und ausgewertet wird.
> 
> In Deiner Konfigurationsdatei solltest Du deshalb haben:
> 	        User www-admin
>         	Group www-admin
> 		PidFile /tmp/apache2.pid

für User und Group hatte ich das schon gemacht, nicht aber für das
PidFile. Danke für diesen Hinweis.

Danach bekam ich eine andere Fehlermeldung, dass ich User und Group aus
der virtualhost-Sektion rausnehmen sollte (da hatte ich es auch
eingetragen). Und dann meckerte er nur noch das fehlende Verzeichnis für
das errorlog an - dann lief es endlich auch bei mir. Auch ein Test mit
einem Client und einer geänderten Startseite verlief auf Anhieb.

Soweit ja das eigentliche Anliegen erfüllt. - Also für deine
Unterstützung meinen herzlichen Dank, auch an alle anderen, die sich an
der Diskussion beteiligt haben. (auch wenn diese Lösung nicht übernommen
werden sollte, wird diese im delixs-Wiki dokumentiert werden, damit es
für andere auch zur Verfügung steht.)

Aber es ist so, dass jetzt schon von mir Begehrlichkeiten entstanden
sind. Wie kann ich diesen Apache wieder ausschalten, außer dass ich den
Server runter fahre und beim nächsten Booten nicht wieder starte(?).

> (nicht aber die ehem. Variablennamen wie: "User ${APACHE_RUN_USER}" oder 
> "Group ${APACHE_RUN_GROUP}" - es sei denn Du schreibst Dir das passende Init-
> Script für Deinen Apache dazu - z.B. aus dem Standard-Script 
> /etc/init.d/apache2 als "Vorlage"...).

wie schon geschrieben, ich kann kein Linux, will sagen, ich kann damit
auch kein Shell-Scripting und damit wäre das Anpassen des Init-Scripts
durch mich vergebliche Mühe. (Ich kann nur Perl)

Werde mich aber in unserer kleinen Gruppe umhören, ob das einer
übernimmt - davon gehe ich aus. Damit wäre dann auch das Problem weg,
wie man diesen 2. Apachen stoppen kann. Aber vielleicht gehts ja auch
anders.

Aber eine 2. Frage hätte ich doch noch, nämlich: wie kann ich den
Ressourcen-Bedarf für diese 2. Instanz zumindest grob erfassen? Das ist
sicher auch eine Frage, die zur Entscheidung für bzw. gegen diese Lösung
herangezogen werden sollte.


Unabhängig von diesen beiden Fragen: danke für die Unterstützung.

Mit freundlichen Grüßen
Hans-Dietrich




From linux at eichsfeld.net  Tue Dec  8 19:50:57 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Tue,  8 Dec 2009 19:50:57 +0100
Subject: AW: Re: apache
Message-ID: <WpJKl0Fm89P9.dBlhJ51L@syndicat.com>

Hallo Hans,

freut mich, das ich soweit helfen konnte.

1.)
Um Deinen laufenden Server Wieder zu beenden, kannst Du z.B:

- mit 
	cat /pfad/zu/pidfile
die aktuelle Prozessnummer auslesen, dann mit
 	kill PID
(PID ist die ausgelesene Prozessnummer)
herunterfahren bzw. töten.

Es gibt eine Reihe Standard-Init-Scripte für Unixe / Linuxe, daneben kannst Du auch das Standard-Init-Script von Apache - Debian kopieren - z.B:
	cp -pv /etc/init.d/apache2 /etc/init.d/apache2-admin

und die Kopie Deinen Bedürfnissen anpassen. Im Prinzip musst Du "nur" die im Script auftretenden Pfade auf den zweiten Server anpassen - wo nötig (PID, Konfiguration o.ä.).

D.h. dann kannst Du auch Deinen zweiten Apache mit:
	/etc/init.d/apache2-admin start
starten bzw. mit "stop" stoppen usw.

Bekommst Du das nicht hin, lässt Du den Apache (mit dem besprochenen Kommando) beim Systemstart starten und beim Herunterfahren einfach (also ohne extra Script oder Kommando) sterben. Das System macht ihn dann schon von allein tot... ;)

2.) was meinst Du mit "Ressourcen"?
Die gängigen Tools wie:
	ps afux
	top
Sollten Dir die im laufenden Betrieb benötigten Ressourcen auf einfache Weise zeigen. Manche Anfänger bevorzugen auch "htop" (muß extra installiert werden).

Die Software selbst belegt auf der Platte keinen weiteren Speicher, da Du ja den selben Server nur verschieden konfiguriert startest.

Den Plattenbedarf der Konfiguration ermittelst Du z.B mit:
	du -sh /etc/apache-admin
(also dem ServerRoot Verzeichnis).

Wenn der zweite Apache eh nur für Konfigurationszwekce einzelner User gedacht ist, reicht es auch wenn Du die Zahl der vorgestarteten Prozesse auf einen bzw. einzelne reduzierst, um so der RAM-Bedarf zu minimieren. Wieviele Prozesse Dein Apache von sich aus im "Ruhebetrieb" startet, siehst Du per top oder ps afux.

hth
Viel Glück!
Beste Grüße,

Niels.
---
Niels Dettenbach
http://www.syndicat.com

-- Urspr. Mitt. --
Betreff: Re: apache
Von: Hans-Dietrich Kirmse <hd.kirmse at gmx.de>
Datum: 08.12.2009 19:18

Hallo Niels,

Niels Dettenbach schrieb:
> ....also,
> 
> hab das - weil's mich mal interessiert hat - soeben nochmal testweise mit 
> einem Debian Apache2 ausprobiert und habe da auf den zweiten Blick noch ein 
> paar Dinge, die Du beachten solltest - gefunden.
> 
> statt
> 	apache2 -d/etc/apache-admin 
> 
> möchte er offenbar nur mit
> 	apache2 -d/etc/apache-admin  -f /etc/apache-admin/apache2.conf
> 
> auch die eigene Konfiguration lesen.
> 
> Damit sich beide Apache nicht ins Gehege kommen, musst Du zusätzlich alle 
> Pfade wie:
> 	LockFile /tmp/accept.lock
> 	PidFile /tmp/apache2.pid
> 
> (/tmp ist hier nur ein schlechtes Beispiel und produktiv nicht geeignet - zum 
> Ausprobieren aber gut) auf abweichende Pfade bzw. Namen ändern (bitte IN der 
> Konfigurationsdatei - nicht in /etc/apache2/envvars!).
> 
> Aber auch für die Logausgaben solltest Du eigene Festlegungen treffen - z.B:
> 	ErrorLog /tmp/error.log 
>         CustomLog /tmp/access.log combined
> 
> Mit den Maßnahmen hat es zumindest auf meiner Debian-Testumgebung gut 
> funktioniert.
> 
> Nun zu Deinem gestrigen Problem:
> On Monday 07 December 2009 23:18:39 Hans-Dietrich Kirmse wrote:
>> Niels Dettenbach schrieb:
>>>> bad user name
>>> Demnach gibt es den Usernamen und / oder Gruppe noch nicht.
>>>
>>> Bitte nochmal beide angelegten User / Gruppe prüfen - ev nochmal
>>> neueinloggen. 
>> keine Änderung
> 
> Debian scheint in der Konfiguration normalerweise auf /etc/apache2/envvars
> zurückzugreifen, die mit dem Debian Init-Script /etc/init.d/apache2 gelesen 
> und ausgewertet wird.
> 
> In Deiner Konfigurationsdatei solltest Du deshalb haben:
> 	        User www-admin
>         	Group www-admin
> 		PidFile /tmp/apache2.pid

für User und Group hatte ich das schon gemacht, nicht aber für das
PidFile. Danke für diesen Hinweis.

Danach bekam ich eine andere Fehlermeldung, dass ich User und Group aus
der virtualhost-Sektion rausnehmen sollte (da hatte ich es auch
eingetragen). Und dann meckerte er nur noch das fehlende Verzeichnis für
das errorlog an - dann lief es endlich auch bei mir. Auch ein Test mit
einem Client und einer geänderten Startseite verlief auf Anhieb.

Soweit ja das eigentliche Anliegen erfüllt. - Also für deine
Unterstützung meinen herzlichen Dank, auch an alle anderen, die sich an
der Diskussion beteiligt haben. (auch wenn diese Lösung nicht übernommen
werden sollte, wird diese im delixs-Wiki dokumentiert werden, damit es
für andere auch zur Verfügung steht.)

Aber es ist so, dass jetzt schon von mir Begehrlichkeiten entstanden
sind. Wie kann ich diesen Apache wieder ausschalten, außer dass ich den
Server runter fahre und beim nächsten Booten nicht wieder starte(?).

> (nicht aber die ehem. Variablennamen wie: "User ${APACHE_RUN_USER}" oder 
> "Group ${APACHE_RUN_GROUP}" - es sei denn Du schreibst Dir das passende Init-
> Script für Deinen Apache dazu - z.B. aus dem Standard-Script 
> /etc/init.d/apache2 als "Vorlage"...).

wie schon geschrieben, ich kann kein Linux, will sagen, ich kann damit
auch kein Shell-Scripting und damit wäre das Anpassen des Init-Scripts
durch mich vergebliche Mühe. (Ich kann nur Perl)

Werde mich aber in unserer kleinen Gruppe umhören, ob das einer
übernimmt - davon gehe ich aus. Damit wäre dann auch das Problem weg,
wie man diesen 2. Apachen stoppen kann. Aber vielleicht gehts ja auch
anders.

Aber eine 2. Frage hätte ich doch noch, nämlich: wie kann ich den
Ressourcen-Bedarf für diese 2. Instanz zumindest grob erfassen? Das ist
sicher auch eine Frage, die zur Entscheidung für bzw. gegen diese Lösung
herangezogen werden sollte.


Unabhängig von diesen beiden Fragen: danke für die Unterstützung.

Mit freundlichen Grüßen
Hans-Dietrich





From hd.kirmse at gmx.de  Tue Dec  8 20:43:38 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Tue, 08 Dec 2009 20:43:38 +0100
Subject: apache
In-Reply-To: <WpJKl0Fm89P9.dBlhJ51L@syndicat.com>
References: <WpJKl0Fm89P9.dBlhJ51L@syndicat.com>
Message-ID: <4B1EAC6A.2050705@gmx.de>

Niels Dettenbach schrieb:
> Hallo Hans, 
> 
> freut mich, das ich soweit helfen konnte.
> 
> 1.) Um Deinen laufenden Server Wieder zu beenden, kannst Du z.B:
> 
> - mit cat /pfad/zu/pidfile die aktuelle Prozessnummer auslesen, dann
> mit kill PID (PID ist die ausgelesene Prozessnummer) herunterfahren
> bzw. töten.

klappt prima.

> 
> Es gibt eine Reihe Standard-Init-Scripte für Unixe / Linuxe, daneben
> kannst Du auch das Standard-Init-Script von Apache - Debian kopieren
> - z.B: cp -pv /etc/init.d/apache2 /etc/init.d/apache2-admin
> 
> und die Kopie Deinen Bedürfnissen anpassen. Im Prinzip musst Du "nur"
> die im Script auftretenden Pfade auf den zweiten Server anpassen - wo
> nötig (PID, Konfiguration o.ä.).
> 
> D.h. dann kannst Du auch Deinen zweiten Apache mit: 
> /etc/init.d/apache2-admin start starten bzw. mit "stop" stoppen usw.
> 
> Bekommst Du das nicht hin, lässt Du den Apache (mit dem besprochenen
> Kommando) beim Systemstart starten und beim Herunterfahren einfach
> (also ohne extra Script oder Kommando) sterben. Das System macht ihn
> dann schon von allein tot... ;)

schon klar, aber das wird schon sauber hinzubekommen sein. Wobei die
Init-Scripte von apache-Lenny schon ganz schön wild aussehen.

> 2.) was meinst Du mit "Ressourcen"? Die gängigen Tools wie: ps afux 
> top Sollten Dir die im laufenden Betrieb benötigten Ressourcen auf
> einfache Weise zeigen. 

Ich meinte in erster Linie den Ram.

mit top ergibt sich bei mir, dass beim Starten bzw. Stoppen dieser 2.
Instanz ca. 1.500k an Ram genommen bzw. wieder freigegeben werden.
Vorhanden sind bei mir 2 GB an Ram, also 2.000.000k. Wenn ich den ersten
Apache kille bzw. wieder starte, dann wird der gleiche Ram frei bzw.
angefordert, was ja auch so sein sollte ;)

  :

> Wenn der zweite Apache eh nur für Konfigurationszwekce einzelner User
> gedacht ist, reicht es auch wenn Du die Zahl der vorgestarteten
> Prozesse auf einen bzw. einzelne reduzierst, um so der RAM-Bedarf zu
> minimieren. 

Das habe ich auch probiert. Damit reduzierte sich der belegte Ram auf
ca. 1.200k, also auf ca. 80% (hätte ich mit größerer Einsparung gerechnet).

  :

> hth Viel Glück! Beste Grüße,

sieht alles sehr gut aus. Meine Fragen sind beantwortet. - super. Danke!

Mit freundlichen Grüßen
Hans-Dietrich




From linux at eichsfeld.net  Wed Dec  9 07:30:31 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Wed,  9 Dec 2009 07:30:31 +0100
Subject: AW: Re: apache
Message-ID: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com>

Hallo Hans,


Die Einsparungen sind u.a. gering(er), da Apache ja (auch) mit sog. "Threads" (so nennt man die sog "leichten Prozesse") operiert.

Wenn Du nennenswert mehr sparen willst, hast Du z.B. noch folgende Optionen:
  - Bereinigen der Konfigurationen und dafür sorgen, das nur die benötigten Module geladen werden 
und/oder
  - Dir einen passenden Apache aus den Quellen bauen, der nur die gewünschten Funktionalitäten bietet

Sehr viel wird aber auch das nicht bringen. Wenn man wenig Platz hat, verwendet man daher (wie schon angeregt hier) einen leichten / kleinen Webserver a la lighthttpd (deren Konfiguration i.d.R. auch schneller erlernbar ist).

Allerdings betrachtest Du ja bisher nur den Webserver selbst. Der eigentliche RAM / Ressourcenbedarf entsteht erst dann, wenn Deine Admin-Software (oder halt die PHP Scripte der Anwender) "dahinter" läuft - also wenn diese gerade (vom Webserver "gestartet") einen Web-Request bearbeitet.

Wenn diese z.B. wiederum irgendwelche Datenbankoperationen macht, fällt auch dort Arbeit an.

Viel Spaß damit.
Beste Grüße,

Niels.
---
Niels Dettenbach
http://www.syndicat.com

-- Urspr. Mitt. --
Betreff: Re: apache
Von: Hans-Dietrich Kirmse <hd.kirmse at gmx.de>
Datum: 08.12.2009 20:44

Niels Dettenbach schrieb:
> Hallo Hans, 
> 
> freut mich, das ich soweit helfen konnte.
> 
> 1.) Um Deinen laufenden Server Wieder zu beenden, kannst Du z.B:
> 
> - mit cat /pfad/zu/pidfile die aktuelle Prozessnummer auslesen, dann
> mit kill PID (PID ist die ausgelesene Prozessnummer) herunterfahren
> bzw. töten.

klappt prima.

> 
> Es gibt eine Reihe Standard-Init-Scripte für Unixe / Linuxe, daneben
> kannst Du auch das Standard-Init-Script von Apache - Debian kopieren
> - z.B: cp -pv /etc/init.d/apache2 /etc/init.d/apache2-admin
> 
> und die Kopie Deinen Bedürfnissen anpassen. Im Prinzip musst Du "nur"
> die im Script auftretenden Pfade auf den zweiten Server anpassen - wo
> nötig (PID, Konfiguration o.ä.).
> 
> D.h. dann kannst Du auch Deinen zweiten Apache mit: 
> /etc/init.d/apache2-admin start starten bzw. mit "stop" stoppen usw.
> 
> Bekommst Du das nicht hin, lässt Du den Apache (mit dem besprochenen
> Kommando) beim Systemstart starten und beim Herunterfahren einfach
> (also ohne extra Script oder Kommando) sterben. Das System macht ihn
> dann schon von allein tot... ;)

schon klar, aber das wird schon sauber hinzubekommen sein. Wobei die
Init-Scripte von apache-Lenny schon ganz schön wild aussehen.

> 2.) was meinst Du mit "Ressourcen"? Die gängigen Tools wie: ps afux 
> top Sollten Dir die im laufenden Betrieb benötigten Ressourcen auf
> einfache Weise zeigen. 

Ich meinte in erster Linie den Ram.

mit top ergibt sich bei mir, dass beim Starten bzw. Stoppen dieser 2.
Instanz ca. 1.500k an Ram genommen bzw. wieder freigegeben werden.
Vorhanden sind bei mir 2 GB an Ram, also 2.000.000k. Wenn ich den ersten
Apache kille bzw. wieder starte, dann wird der gleiche Ram frei bzw.
angefordert, was ja auch so sein sollte ;)

  :

> Wenn der zweite Apache eh nur für Konfigurationszwekce einzelner User
> gedacht ist, reicht es auch wenn Du die Zahl der vorgestarteten
> Prozesse auf einen bzw. einzelne reduzierst, um so der RAM-Bedarf zu
> minimieren. 

Das habe ich auch probiert. Damit reduzierte sich der belegte Ram auf
ca. 1.200k, also auf ca. 80% (hätte ich mit größerer Einsparung gerechnet).

  :

> hth Viel Glück! Beste Grüße,

sieht alles sehr gut aus. Meine Fragen sind beantwortet. - super. Danke!

Mit freundlichen Grüßen
Hans-Dietrich





From rob at rob-schulze.de  Wed Dec  9 18:55:05 2009
From: rob at rob-schulze.de (Robert Schulze)
Date: Wed, 09 Dec 2009 18:55:05 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B1D5692.80100@gmx.de>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com>
	<4B1D3EB8.5020607@gmx.de>	<4B1D45A5.7050300@rob-schulze.de>
	<4B1D5692.80100@gmx.de>
Message-ID: <4B1FE479.2050908@rob-schulze.de>

Hi,

Hans-Dietrich Kirmse schrieb:
> Trotzdem nochmal auf dein Argument zurück zu kommen: angenommen es
> werden neue Sicherheitslücken bekannt. Wie sieht bei dieser 2-Instanzen-
> Lösung dann das Bedrohungsszenario aus? Ich denke, ob PHP als Modul oder
> nicht, der Zugriff (mittels sudoers) auf Scripte die dann mit root-
> Rechten ausgeführt werden, wäre nicht mehr möglich. Und genau das ist
> der von mir angedachte/erhoffte Sicherheitsgewinn. - Nochmal meine
> Frage: wo denke ich da falsch?

Ja ist ja richtig, wenn du die zwei Instanzen entsprechend
konfigurierst, sodass nur eine Instanz den Zugriff auf die
höherpriviligierten Skripte hat.

Trotzdem ist suexec hier einfacher anzuwenden und bringt nebenbei _noch_
mehr Sicherheit zumindest für die Schüler untereinander. Die
Konfiguration des PHP würde dabei identisch sein.


Rob

From hd.kirmse at gmx.de  Wed Dec  9 20:33:30 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Wed, 09 Dec 2009 20:33:30 +0100
Subject: AW: Re: apache
In-Reply-To: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com>
References: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com>
Message-ID: <4B1FFB8A.4090505@gmx.de>

Hallo Niels,

Niels Dettenbach schrieb:
> Hallo Hans,
> 
> 
> Die Einsparungen sind u.a. gering(er), da Apache ja (auch) mit sog.
> "Threads" (so nennt man die sog "leichten Prozesse") operiert.
> 
> Wenn Du nennenswert mehr sparen willst, hast Du z.B. noch folgende
> Optionen: - Bereinigen der Konfigurationen und dafür sorgen, das nur
> die benötigten Module geladen werden und/oder

das ist klar, dass beide Instanzen entsprechend ihres Verwendungszwecks
optimal konfiguriert werden. Bedeutet natürlich, auch nur die Module,
die gebraucht werden.

> - Dir einen passenden Apache aus den Quellen bauen, der nur die
> gewünschten Funktionalitäten bietet

entfällt definitiv.

> Sehr viel wird aber auch das nicht bringen. Wenn man wenig Platz hat,
> verwendet man daher (wie schon angeregt hier) einen leichten /
> kleinen Webserver a la lighthttpd (deren Konfiguration i.d.R. auch
> schneller erlernbar ist).

habe ich gerade installiert nach folgender Anleitung:
http://debian.asconix.com/lighttpd-php5-mysql-debian-lenny-howto

Eine Ermittlung des Ram-Bedarfs mit top, also genauso wie beim Apache
gemacht ergab: 3 MB, also mehr als das Doppelte vom Apache! Ich habe das
mehrfach wiederholt. DAs steht im Widerspruch zu den Aussagen, dass der
lighttpdwenig Ressourcen schluckt. Ich kann mir das nur erklären,d ass
dann das fast-cgi-Modul dafür verantwortlich ist. Aber PHP muss nunmal
sein. also ist zumindest wegen der Ressourcen der lighttpd keine
alternative. Und 2 verschiedene Systeme wenn es mit einer Varainte auch
geht und zudem deutlich ressourcenschonender - hier ist also diese
Variante m.E. geklärt.

> Allerdings betrachtest Du ja bisher nur den Webserver selbst. 

ja.

> Der
> eigentliche RAM / Ressourcenbedarf entsteht erst dann, wenn Deine
> Admin-Software (oder halt die PHP Scripte der Anwender) "dahinter"
> läuft - also wenn diese gerade (vom Webserver "gestartet") einen
> Web-Request bearbeitet.

stimmt schon, aber es dürfte in erster Näherung (hoffentlich) der
zusätzliche Bedarf gleich sein, wenn die gleichen Scripte aufgerufen
werden. Es interessiert m.E. deshalb wirklich der Ram-Bedarf, der durch
diese Installation/Konfiguration eben dauernd in Anspruch genommen wird.

> Wenn diese z.B. wiederum irgendwelche Datenbankoperationen macht,
> fällt auch dort Arbeit an.
> 
> Viel Spaß damit. Beste Grüße,

ja, mir gefällt das Ergebis immer besser ;)


MfG Hans-Dietrich



From hd.kirmse at gmx.de  Wed Dec  9 20:37:26 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Wed, 09 Dec 2009 20:37:26 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B1FE479.2050908@rob-schulze.de>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com>	<4B1D3EB8.5020607@gmx.de>	<4B1D45A5.7050300@rob-schulze.de>	<4B1D5692.80100@gmx.de>
	<4B1FE479.2050908@rob-schulze.de>
Message-ID: <4B1FFC76.1050009@gmx.de>

Hallo Robert,

danke auch für deine Antwort.

Robert Schulze schrieb:
> Hi,
> 
> Hans-Dietrich Kirmse schrieb:
>> Trotzdem nochmal auf dein Argument zurück zu kommen: angenommen es
>> werden neue Sicherheitslücken bekannt. Wie sieht bei dieser 2-Instanzen-
>> Lösung dann das Bedrohungsszenario aus? Ich denke, ob PHP als Modul oder
>> nicht, der Zugriff (mittels sudoers) auf Scripte die dann mit root-
>> Rechten ausgeführt werden, wäre nicht mehr möglich. Und genau das ist
>> der von mir angedachte/erhoffte Sicherheitsgewinn. - Nochmal meine
>> Frage: wo denke ich da falsch?
> 
> Ja ist ja richtig, wenn du die zwei Instanzen entsprechend
> konfigurierst, sodass nur eine Instanz den Zugriff auf die
> höherpriviligierten Skripte hat.

Das ist das erste Mal, dass diese Überlegung positiv gewertet wurde. Das
ist keineswegs selbstverständlich für mich, denn ich habe im
deutschsprachigen WWW keine Anleitung dafür gefunden und ich habe sehr
lange danach gesucht. Und ich verstehe auch nicht, dass man an mehreren
Stellen vor solchen Gefahren bei den Userdirs warnt und diese
Alternative nicht aufzeigt, geschweige denn erwähnt. Zudem, in der
Skolelinuxliste gibt es wirklich Leute die Ahnung haben, aber auch die
haben (2003 bzw. 2004) einfach die html_public-Verzeichnisse
"verworfen". Da wird man schon unsicher => exotische Lösung(?)!

> Trotzdem ist suexec hier einfacher anzuwenden und bringt nebenbei _noch_
> mehr Sicherheit zumindest für die Schüler untereinander. Die
> Konfiguration des PHP würde dabei identisch sein.

Verstehe ich dich richtig - du meinst einen Apache, statt PHP als Modul
eben alles auf CGI-Basis über suexec aufgerufen?

Dann müssen aber doch auch die Programme wie Wiki (hier Mediawiki - wird
für Schule gebraucht wegen Teamarbeit) und fürs CMS als Schulportal
(hier Contenido - zur Bereitstellung von Bildern über Berichte von
Veranstaltungen ...) und nicht zuletzt eines LMS (hier Moodle - habe ich
keine Erfahrung damit, steht aber schon bereit) - dass muss doch dann
alles auch per CGI und suexec aufgerufen werden. Oder irre ich mich da?

Ich sehe hier echte Performance-Probleme. (ist aber einfach "aus dem
Bauch heraus" - ich weiss es nicht wirklich) Zudem: wir sind nunmal eine
Gruppe. Der Stand ist so, dass nur noch wenige Dienste und die
Erstellung des ISOs fehlen. Das jetzt nochmal in Frage zu stellen ohne
zwingenden(?) Grund - da sehe ich kaum Chancen. Bei dieser 2-
Instanzen-Lösung für den Apache würde sich nur sehr wenig ändern. Aber
das Anliegen, eben die Sicherheit trotz PHP in den Userdirs zu
gewährleisten, wäre aus meiner Sicht erreicht.

Will sagen, ich kann mir das unter diese Situation nicht vorstellen,
komplett auf suexec umzustellen, sofern ich dich überhaupt richtig
verstanden habe.

MfG Hans-Dietrich



From hd.kirmse at gmx.de  Wed Dec  9 22:30:54 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Wed, 09 Dec 2009 22:30:54 +0100
Subject: apache - Fehler :(
In-Reply-To: <4B1FFB8A.4090505@gmx.de>
References: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com> <4B1FFB8A.4090505@gmx.de>
Message-ID: <4B20170E.4060201@gmx.de>

ich schrieb:

>> - Dir einen passenden Apache aus den Quellen bauen, der nur die
>> gewünschten Funktionalitäten bietet
> 
> entfällt definitiv.

Das war natürlich ein Schnellschuß (passiert mir leider sehr oft).
Natürlich war das, was ich wegen Compilieren für unser Schulserver-
projekt geschrieben habe, so gemeint. Will sagen, irgendwelche Pakete
selbst compilieren ist (eigentlich) tabu. Mein Fehler war jetzt, dass
ich damit auch gleich für mich das Erstellen aus den Quellen
ausgeschlossen habe. Aber ich habe auch noch nie unter Linux irgendein
Paket compiliert. (habe ja schon angegeben, dass ich Laie bin.)

Aber ich habe über die Init-Scripte nachgedacht, wie ich die erstellen
kann, dass da keine Fehler passieren und zudem möglichst noch mit
minimalen Aufwand - und ohne das ich mich mit diesen Shell-Scripten
abgeben muss. Meine Überlegung: wenn man beim Compilieren die Daten
mitgeben kann, die die zweite Instanz von der ersten Instanz unter-
scheidet, dann müßte doch beim Compilieren auch das passende Init-Script
erstellt werden. Mehr noch, die gesamte Verzeichnisstruktur z.B. wegen
den Logs, auch alle Konfigurationsdateien sollten entsprechend angepasst
sein. Wenn das so gehen würde, wie ich mir das jetzt so vorstelle, dann
wird für mich das Compilieren eines Apache sehr attraktiv. Nur dass ich
den eigentlichen Apache dann verwerfe und eben nur die Initscripte und
Konfigurationen nutze.

Meine Frage: sind meine Überlegungen richtig und würde das gehen? (Dann
würde es sich für mich echt lohnen, mich mit dem Compilieren zu
beschäftigen - wie gesagt, noch nie gemacht)

Mit freundlichen Grüßen
Hans-Dietrich




From ml-tlug at vdazone.org  Thu Dec 10 00:28:18 2009
From: ml-tlug at vdazone.org (Mario Lorenz)
Date: Thu, 10 Dec 2009 00:28:18 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B1C3803.5010703@gmx.de>
References: <4B1BC505.6040506@gmx.de>
	<20091206200130.GB17492@whitebox.dl5mlo.de>
	<4B1C16B7.3080007@gmx.de>
	<20091206214818.GA17642@whitebox.dl5mlo.de>
	<4B1C3803.5010703@gmx.de>
Message-ID: <20091209232818.GC2996@whitebox.dl5mlo.de>

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 :)

> 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).

Ja, das ist mir wohl bewusst :)

> 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...

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... 
> >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.
> 

Jain. CGI heist, grob gesagt: Anstelle einer Datei, die vom Webserver gelesen und ausgeliefert wird,
wird ein Programm gestartet, welches auf stdout das erzeugt, was der Webbrowser für eine Datei hält.
Ich weiss nicht, ob man dieses Konzept vermitteln kann, aber wenn ja, ist das ein sehr leistungsfähiges
Konzept. Es ist m.e. sogar sauberer als das was meistens mit php gemacht wird, wo HTML geschrieben wird
und dann irgendwo dazwischen Programmcode embedded wird.


> 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)

 
> 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?

Kannst Du mit su www-data2
in diesen Usercontext wechseln ?

Gruesse,

Mario
-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
* This virus needs Windows95 to run!

From linux at eichsfeld.net  Thu Dec 10 09:55:39 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Thu, 10 Dec 2009 09:55:39 +0100
Subject: apache - Fehler :(
In-Reply-To: <4B20170E.4060201@gmx.de>
References: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com> <4B1FFB8A.4090505@gmx.de>
	<4B20170E.4060201@gmx.de>
Message-ID: <200912100955.39132.linux@eichsfeld.net>

On Wednesday 09 December 2009 22:30:54 Hans-Dietrich Kirmse wrote:
> Aber ich habe über die Init-Scripte nachgedacht, wie ich die erstellen
> kann, dass da keine Fehler passieren und zudem möglichst noch mit
> minimalen Aufwand - und ohne das ich mich mit diesen Shell-Scripten
> abgeben muss. Meine Überlegung: wenn man beim Compilieren die Daten
> mitgeben kann, die die zweite Instanz von der ersten Instanz unter-
> scheidet, dann müßte doch beim Compilieren auch das passende Init-Script
> erstellt werden. Mehr noch, die gesamte Verzeichnisstruktur z.B. wegen
> den Logs, auch alle Konfigurationsdateien sollten entsprechend angepasst
> sein. Wenn das so gehen würde, wie ich mir das jetzt so vorstelle, dann
> wird für mich das Compilieren eines Apache sehr attraktiv. Nur dass ich
> den eigentlichen Apache dann verwerfe und eben nur die Initscripte und
> Konfigurationen nutze.
Ich nehme an, das das so nicht funktioniert. I.d.R. liegt den Sourcen von 
"Serverprogrammen" zwar ein passendes Init-Script bei, aber in vielen Fällen 
wird dies beim Kompilieren nicht mit an die (abweichend) konfigurierte 
Umgebung "angepasst".

Dazu kommt, das nahezu jede Distribution eigene Init-Scripte verwendet, die an 
die "Spezialitäten" des jeweiligen Systems angepasst sind. Um also eine 
"normale" Debian-Funktionalität zu bekommen, benötigst Du ein angepasstes 
Apache2 Init Script von / für Debian (z.B. eine Kopie von /etc/init.d/apache2 
in der alle nötigen Pfade angepasst werden). Leider sind die Debian-Apache 
Scripte für den Apache2 recht komplex, so das Du noch weitere Anpassungen am 
System vornehmen müsstest (z.B. eine zweite envvars Datei...) - ich denke 
damit bist Du "überfordert".

Am einfachsten (dafür nicht gant sauber) wäre wohl, das Kommando zum Rufen 
Deines zweiten Apaches in /etc/rc.local einfügst. Damit wird Dein zweiter 
Apache am Ende des Hochfahrens automatisch gestartet. 

Du musst allerdings auch hier den kompletten Pfad zum apache2 angeben - also 
z.B:
/usr/sbin/apache2 -d ... -f ...

(nur "-d" allein will mit dem Debian Apache offenbar nicht).

Wenn Du Dir etwas mehr zutraust, kannst Du auch aus z.B. dieser Vorlage:
http://mythwiki.de/index.php?title=HOWTO_Debian_init_script

ein einfacheres, aber auch passendes, Init-Script basteln.


> Meine Frage: sind meine Überlegungen richtig und würde das gehen? (Dann
> würde es sich für mich echt lohnen, mich mit dem Compilieren zu
> beschäftigen - wie gesagt, noch nie gemacht)
> 
Es lohnt sich eigentlich immer - vor allem um den Bau eines eigenen Kernels 
kommt man irgendwann meist nicht mehr herum. Zudem lernt man viel dabei.. ;)

Unter Debian gibt es i.d.R. zwei Wege um Software selbst zu kompilieren:
 - mit dem Paketmanager - z.B. apt-get -b und/oder dpkg)
 - der "generische" Weg für alle Linuxe / Unixe:
  ./configure && make && make install

ersteres hat den Vorteil, das die resultierende Software "ordentlich" in der 
Paketverwaltung verwendet werden kann - zweiteres, das es auch mit 
Softwarequellen funktioniert, für die es sonst kein Debian-(Source)-Paket 
gibt.

hth
Beste Grüße,


Niels.
-- 
  Niels Dettenbach
  ---
  Eichsfelder Linux/UNIX Stammtisch (EICLUSt)
  http://linux.eichsfeld.net
  ---
  business: Syndicat IT&Internet - http://www.syndicat.com
  Heilbad Heiligenstadt / Erbil / Cape Town
  ---
  Kryptoinfo: 
  PGP public key ID 651CA20D
  Fingerprint: 55E0 4DCD B04C 4A49 1586  88AE 54DC 4465 651C A20D
  https://syndicat.com/pub_key.asc
  ---

From ml-tlug at vdazone.org  Thu Dec 10 13:05:44 2009
From: ml-tlug at vdazone.org (Mario Lorenz)
Date: Thu, 10 Dec 2009 13:05:44 +0100
Subject: apache - Fehler :(
In-Reply-To: <200912100955.39132.linux@eichsfeld.net>
References: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com> <4B1FFB8A.4090505@gmx.de>
	<4B20170E.4060201@gmx.de> <200912100955.39132.linux@eichsfeld.net>
Message-ID: <20091210120544.GA6174@whitebox.dl5mlo.de>

Moin,

> > Meine Frage: sind meine Überlegungen richtig und würde das gehen? (Dann
> > würde es sich für mich echt lohnen, mich mit dem Compilieren zu
> > beschäftigen - wie gesagt, noch nie gemacht)
> > 
> Es lohnt sich eigentlich immer - vor allem um den Bau eines eigenen Kernels 
> kommt man irgendwann meist nicht mehr herum. Zudem lernt man viel dabei.. ;)

Nein. Es ist schön, die Möglichkeit zu haben, wenn man wirklich etwas
spezielles braucht. Aber es lohnt sich praktisch nie, etwas selbst zu bauen,
wenn es was gleich gutes in einer Distribution gibt.

Begründung:

Wenn Du etwas selbst gebaut hast, musst Du es selbst supporten. Zum Beispiel
zeitnah das System neu bauen, wenn ein Sicherheitsloch gefunden wurde.
Das passiert *immer* ungeplant, und Du wirst die Zeit dafür in der Regel nicht
haben. Beim Verwenden des Distri-Paketes ist es in der Regel
apt-get update && apt-get upgrade und fertig.
(und in Mission-Critical-Fällen ist das Wartungsfenster dafür schon 
schwer genug zu kriegen...)

Profitiere von Backports, Q&A etc. der Gemeinschaft (=Distribution) und
stecke die gesparte Zeit lieber in ein OpenSource-Projekt...

Besonders krasser Fall dafür ist übrigends der Linux-Kernel, wo seit dem
neuen Entwicklungsmodell nur ein Distri-Kernel überhaupt lange genug gepflegt wird.

Mario

-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
"Your mouse has moved. Windows NT must be restarted
 for the change to take effect. Reboot now ?   [ OK ]"

From linux at eichsfeld.net  Thu Dec 10 15:04:56 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Thu, 10 Dec 2009 15:04:56 +0100
Subject: apache - Fehler :(
In-Reply-To: <20091210120544.GA6174@whitebox.dl5mlo.de>
References: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com>
	<200912100955.39132.linux@eichsfeld.net>
	<20091210120544.GA6174@whitebox.dl5mlo.de>
Message-ID: <200912101504.56990.linux@eichsfeld.net>

On Thursday 10 December 2009 13:05:44 Mario Lorenz wrote:
> Nein. Es ist schön, die Möglichkeit zu haben, wenn man wirklich etwas
> spezielles braucht. Aber es lohnt sich praktisch nie, etwas selbst zu
>  bauen, wenn es was gleich gutes in einer Distribution gibt.
> 
Ja,
leider stimmt das für viele Distributionen.

Leider gibt es meiner Erfahrung nach doch sehr viele Dinge, die aus 
standardisierten Distributionen nicht bzw. nur annähernd so gut (aber halt 
nicht "gleich gut") sind. Manche Dinge gibt es auch gar nicht....

Unter Debian hat mich (früher) immer geärgert, das ich das komplette System 
nicht ohne größeres Gefrickel oder Fehlermeldungen mal am Stück neu übersetzen 
kann (u.a. ein Grund, warum ich heute mehr mit Gentoo mache). Ob das heute 
noch so ist, kann ich nicht sagen - habe es nicht wieder probiert...

Aber ich bin da mittlerweile wohl schlicht von Gentoo und *BSDs zu "versaut" 
worden... ;)

Für den "Normalanwender" auf x86 PC & sog. "Servern" (mit Einschränkungen auch 
AMD64) mag Deine Aussage sicher weithin zutreffen. 

Aber auch solche kommen (so meine Erfahrung) irgendwann an Ihre Grenzen - z.B. 
wenn der für viel Geld hochzertifizierte "Red-Hat Administrator" sein WLAN 
Interface am Notebook nicht in Gang bekommt (und deshalb weiter Windows nutzen 
"muß"), weil er nicht gelernt hat wie man nen Kernel "per Hand" baut (denn 
Red-Hat hatte da gerade die passenden "Centrino-"(!)Treiber noch nicht als rpm 
im Repository...)...


Beste Grüße,


Niels.
-- 
  Niels Dettenbach
  ---
  Eichsfelder Linux/UNIX Stammtisch (EICLUSt)
  http://linux.eichsfeld.net
  ---
  business: Syndicat IT&Internet - http://www.syndicat.com
  Heilbad Heiligenstadt / Erbil / Cape Town
  ---
  Kryptoinfo: 
  PGP public key ID 651CA20D
  Fingerprint: 55E0 4DCD B04C 4A49 1586  88AE 54DC 4465 651C A20D
  https://syndicat.com/pub_key.asc
  ---

From rob at rob-schulze.de  Thu Dec 10 17:53:32 2009
From: rob at rob-schulze.de (Robert Schulze)
Date: Thu, 10 Dec 2009 17:53:32 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B1FFC76.1050009@gmx.de>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com>	<4B1D3EB8.5020607@gmx.de>	<4B1D45A5.7050300@rob-schulze.de>	<4B1D5692.80100@gmx.de>	<4B1FE479.2050908@rob-schulze.de>
	<4B1FFC76.1050009@gmx.de>
Message-ID: <4B21278C.9050703@rob-schulze.de>

Hi,

Hans-Dietrich Kirmse schrieb:

>> Trotzdem ist suexec hier einfacher anzuwenden und bringt nebenbei _noch_
>> mehr Sicherheit zumindest für die Schüler untereinander. Die
>> Konfiguration des PHP würde dabei identisch sein.
> 
> Verstehe ich dich richtig - du meinst einen Apache, statt PHP als Modul
> eben alles auf CGI-Basis über suexec aufgerufen?

ja.

> Dann müssen aber doch auch die Programme wie Wiki (hier Mediawiki - wird
> für Schule gebraucht wegen Teamarbeit) und fürs CMS als Schulportal
> (hier Contenido - zur Bereitstellung von Bildern über Berichte von
> Veranstaltungen ...) und nicht zuletzt eines LMS (hier Moodle - habe ich
> keine Erfahrung damit, steht aber schon bereit) - dass muss doch dann
> alles auch per CGI und suexec aufgerufen werden. Oder irre ich mich da?

Mediawiki/Contenido und Co. würden dann unter suexec laufen (naja: der
PHP-Interpreter läuft unter suexec und führt halt die Skripte aus).

> Ich sehe hier echte Performance-Probleme. (ist aber einfach "aus dem
> Bauch heraus" - ich weiss es nicht wirklich) 

Wie gesagt: Humbug bei so einem kleinen Setup, das kann ich aus
Erfahrung behaupten. Du wirst da keinen Unterschied feststellen.

> Aber
> das Anliegen, eben die Sicherheit trotz PHP in den Userdirs zu
> gewährleisten, wäre aus meiner Sicht erreicht.

dann läuft PHP unter der UID des Apachen. Wenn kein Dateisystemzugriff
benötigt wird, also alles über eine Datenbankanbindung geschiet, dann
mag man dies noch verzeihen, weil der Apache dann keine
Schreibberchtigung in den Userdirs braucht. Wenn auch Dateizugriff über
PHP möglich sein soll, dann viel Spaß mit den Schülern, die sich
gegenseitig ihre Dateien weglöschen.

Rob

From weigelt at metux.de  Thu Dec 10 18:23:13 2009
From: weigelt at metux.de (Enrico Weigelt)
Date: Thu, 10 Dec 2009 18:23:13 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B1FFC76.1050009@gmx.de>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com> <4B1D3EB8.5020607@gmx.de>
	<4B1D45A5.7050300@rob-schulze.de> <4B1D5692.80100@gmx.de>
	<4B1FE479.2050908@rob-schulze.de> <4B1FFC76.1050009@gmx.de>
Message-ID: <20091210172310.GA16827@nibiru.local>

* Hans-Dietrich Kirmse <hd.kirmse at gmx.de> schrieb:

moin,

> >Trotzdem ist suexec hier einfacher anzuwenden und bringt nebenbei _noch_
> >mehr Sicherheit zumindest für die Schüler untereinander. Die
> >Konfiguration des PHP würde dabei identisch sein.
> 
> Verstehe ich dich richtig - du meinst einen Apache, statt PHP als Modul
> eben alles auf CGI-Basis über suexec aufgerufen?

vor vielen Jahren hatte ich ja mal das Multiplexer-MPM entwickelt, 
das vhosts unter eigener PID ermöglicht. Wurde dann aber mangels
Interesse irgentwann wieder eingestellt.

BTW: bin ich schon vor Jahren auf lighttpd umgestiegen ;-p

Was ich mir wirklich wüschen würde: ein Webserver (oder vielleicht
auch für verschiedene Protokolle), der verschiedenste Micro-Server
(die ggf. unter eigenen UIDs und Jails oder gar von anderen Hosts)
wie als Filesysteme mounted.

> Ich sehe hier echte Performance-Probleme. (ist aber einfach "aus dem
> Bauch heraus" - ich weiss es nicht wirklich) 

fcgi ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

From weigelt at metux.de  Thu Dec 10 18:25:09 2009
From: weigelt at metux.de (Enrico Weigelt)
Date: Thu, 10 Dec 2009 18:25:09 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B21278C.9050703@rob-schulze.de>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com> <4B1D3EB8.5020607@gmx.de>
	<4B1D45A5.7050300@rob-schulze.de> <4B1D5692.80100@gmx.de>
	<4B1FE479.2050908@rob-schulze.de> <4B1FFC76.1050009@gmx.de>
	<4B21278C.9050703@rob-schulze.de>
Message-ID: <20091210172506.GB16827@nibiru.local>

* Robert Schulze <rob at rob-schulze.de> schrieb:

hi,

> dann läuft PHP unter der UID des Apachen. Wenn kein Dateisystemzugriff
> benötigt wird, also alles über eine Datenbankanbindung geschiet, dann
> mag man dies noch verzeihen, weil der Apache dann keine
> Schreibberchtigung in den Userdirs braucht. Wenn auch Dateizugriff über
> PHP möglich sein soll, dann viel Spaß mit den Schülern, die sich
> gegenseitig ihre Dateien weglöschen.

Für die DB braucht man aber Zugangsdaten. Und die liegen im
Filesystem. Ergo kann ein Script eines Users auch auf die der
anderen Zugreifen und ggf. dort die DB-Zugangsdaten auslesen,
es sei denn man behilft sich mit Krücken wie safe_mode ;-o


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

From linux at eichsfeld.net  Thu Dec 10 20:30:37 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Thu, 10 Dec 2009 20:30:37 +0100
Subject: AW: Re: 2 Instanzen von Apache - geht das, wenn ja - wie?
Message-ID: <hfgX5FzT78wy.G0SgNMqm@syndicat.com>

> safe_mode ...
chroot?


Niels.


From hd.kirmse at gmx.de  Thu Dec 10 20:48:33 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Thu, 10 Dec 2009 20:48:33 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <20091209232818.GC2996@whitebox.dl5mlo.de>
References: <4B1BC505.6040506@gmx.de>	<20091206200130.GB17492@whitebox.dl5mlo.de>	<4B1C16B7.3080007@gmx.de>	<20091206214818.GA17642@whitebox.dl5mlo.de>	<4B1C3803.5010703@gmx.de>
	<20091209232818.GC2996@whitebox.dl5mlo.de>
Message-ID: <4B215091.3040107@gmx.de>

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




From hd.kirmse at gmx.de  Thu Dec 10 20:49:01 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Thu, 10 Dec 2009 20:49:01 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <4B21278C.9050703@rob-schulze.de>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com>	<4B1D3EB8.5020607@gmx.de>	<4B1D45A5.7050300@rob-schulze.de>	<4B1D5692.80100@gmx.de>	<4B1FE479.2050908@rob-schulze.de>	<4B1FFC76.1050009@gmx.de>
	<4B21278C.9050703@rob-schulze.de>
Message-ID: <4B2150AD.9000100@gmx.de>

Hallo Robert,

Robert Schulze schrieb:
> Hi,
> 
> Hans-Dietrich Kirmse schrieb:
> 
>>> Trotzdem ist suexec hier einfacher anzuwenden und bringt nebenbei _noch_
>>> mehr Sicherheit zumindest für die Schüler untereinander. Die
>>> Konfiguration des PHP würde dabei identisch sein.
>> Verstehe ich dich richtig - du meinst einen Apache, statt PHP als Modul
>> eben alles auf CGI-Basis über suexec aufgerufen?
> 
> ja.

okay.

>> Dann müssen aber doch auch die Programme wie Wiki (hier Mediawiki - wird
>> für Schule gebraucht wegen Teamarbeit) und fürs CMS als Schulportal
>> (hier Contenido - zur Bereitstellung von Bildern über Berichte von
>> Veranstaltungen ...) und nicht zuletzt eines LMS (hier Moodle - habe ich
>> keine Erfahrung damit, steht aber schon bereit) - dass muss doch dann
>> alles auch per CGI und suexec aufgerufen werden. Oder irre ich mich da?
> 
> Mediawiki/Contenido und Co. würden dann unter suexec laufen (naja: der
> PHP-Interpreter läuft unter suexec und führt halt die Skripte aus).

Kann ich mir nicht vorstellen, dass das beim Projektleiter auf
Gegenliebe stößt. Ausgerechnet er hat Contenido, Mediawiki und Moodle
bereitgestellt. (übrigens wird von ihm auch das gesamte Portal zu Delixs
bereitgestellt: www.delixs.de)

>> Ich sehe hier echte Performance-Probleme. (ist aber einfach "aus dem
>> Bauch heraus" - ich weiss es nicht wirklich) 
> 
> Wie gesagt: Humbug bei so einem kleinen Setup, das kann ich aus
> Erfahrung behaupten. Du wirst da keinen Unterschied feststellen.

ich weiss zwar nicht wie hier "klein" definiert ist. Aber Ich hatte vor
2 Jahren erst einen neuen Schulserver bekommen, weil der aus dem Jahre
2000 abgeraucht war. Und 6 bis 8 Jahre alte Schulerver - gerade in
Thüringen sind keine Seltenheit. Wenn dann auf denen Apache, Squid mit
Squidguard, Samba, LDAP, MySQL, Postfix, Dovecot, Webmail (Roundcube),
und eben Contenido, Mediawiki und Moodle laufen soll, dann ist das für
mich schon bedenklich. Zudem fehlen ja auch noch ein paar Dienste, die
aber noch kommen sollen, nämlich NFS und FTP und vor allem CUPS. Und
jetzt bitte beachten,  in der Schule ist es so: Stunde beginnt, der
lehrer gibt eine Aufgabe und dann gehen Zeitgleich 15 oder vielleicht
sogar 30 Rechner zeitgleich ans Netz und nutzen in der Regel auch die
gleichen Dienste. solche Probleme gibt es m.E in Firmen nicht.

Deswegen, klein ist m.E. relativ. Wir machen uns schon Gedanken wegen
der Ressourcen und der Performance.


>> Aber
>> das Anliegen, eben die Sicherheit trotz PHP in den Userdirs zu
>> gewährleisten, wäre aus meiner Sicht erreicht.
> 
> dann läuft PHP unter der UID des Apachen. Wenn kein Dateisystemzugriff
> benötigt wird, also alles über eine Datenbankanbindung geschiet, dann
> mag man dies noch verzeihen, weil der Apache dann keine
> Schreibberchtigung in den Userdirs braucht. Wenn auch Dateizugriff über
> PHP möglich sein soll, dann viel Spaß mit den Schülern, die sich
> gegenseitig ihre Dateien weglöschen.

geht nicht wegen safe_mode = on

siehe http://www.php-faq.de/q-konfiguration-safe-mode.html

"Wenn safe_mode aktiv ist, sind verschiedene PHP-Funktionen privilegiert
oder eingeschränkt. Zumeist gilt die safe_mode Einschränkung, dass auf
eine Datei oder ein Verzeichnis nur eingewirkt werden darf, wenn die
Datei oder das Verzeichnis denselben Eigentümer hat wie das Script."

MfG Hans-Dietrich

PS: ich traue der Sicherheit von PHP auch nicht. Aber so einfach ist es
doch nicht, das ein Schüler auf ein anderes Verzeichnis zugreifen kann.



From hd.kirmse at gmx.de  Thu Dec 10 20:52:10 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Thu, 10 Dec 2009 20:52:10 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <20091210172310.GA16827@nibiru.local>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com>
	<4B1D3EB8.5020607@gmx.de>	<4B1D45A5.7050300@rob-schulze.de>
	<4B1D5692.80100@gmx.de>	<4B1FE479.2050908@rob-schulze.de>
	<4B1FFC76.1050009@gmx.de> <20091210172310.GA16827@nibiru.local>
Message-ID: <4B21516A.1020305@gmx.de>

und auch dazu:

Enrico Weigelt schrieb:
> * Hans-Dietrich Kirmse <hd.kirmse at gmx.de> schrieb:
> 
> moin,
> 
>>> Trotzdem ist suexec hier einfacher anzuwenden und bringt nebenbei _noch_
>>> mehr Sicherheit zumindest für die Schüler untereinander. Die
>>> Konfiguration des PHP würde dabei identisch sein.
>> Verstehe ich dich richtig - du meinst einen Apache, statt PHP als Modul
>> eben alles auf CGI-Basis über suexec aufgerufen?
> 
> vor vielen Jahren hatte ich ja mal das Multiplexer-MPM entwickelt, 
> das vhosts unter eigener PID ermöglicht. Wurde dann aber mangels
> Interesse irgentwann wieder eingestellt.
> 
> BTW: bin ich schon vor Jahren auf lighttpd umgestiegen ;-p
> 
> Was ich mir wirklich wüschen würde: ein Webserver (oder vielleicht
> auch für verschiedene Protokolle), der verschiedenste Micro-Server
> (die ggf. unter eigenen UIDs und Jails oder gar von anderen Hosts)
> wie als Filesysteme mounted.
> 
>> Ich sehe hier echte Performance-Probleme. (ist aber einfach "aus dem
>> Bauch heraus" - ich weiss es nicht wirklich) 
> 
> fcgi ?

wie ich schon in der mail von 09.12.2009 20:33 geschrieben habe, braucht
der lighttpd mit fastcgi mehr als doppelt soviel Ram wie eine Instanz
des Apache. Wenn ich dann noch hinzurechne, dass 2 verschiedene Server
statt einem dann betreuet werden müssen (Einarbeitung, Dokumentation,
...) dann kann ich den Vorteil von lighttpd nicht wirklich erkennen.

MfG Hans-Dietrich



From hd.kirmse at gmx.de  Thu Dec 10 20:51:38 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Thu, 10 Dec 2009 20:51:38 +0100
Subject: 2 Instanzen von Apache - geht das, wenn ja - wie?
In-Reply-To: <20091210172506.GB16827@nibiru.local>
References: <cXgDCNQKwXvB.DdMDRdV5@syndicat.com>
	<4B1D3EB8.5020607@gmx.de>	<4B1D45A5.7050300@rob-schulze.de>
	<4B1D5692.80100@gmx.de>	<4B1FE479.2050908@rob-schulze.de>
	<4B1FFC76.1050009@gmx.de>	<4B21278C.9050703@rob-schulze.de>
	<20091210172506.GB16827@nibiru.local>
Message-ID: <4B21514A.9060801@gmx.de>

Hallo Enrico,

Enrico Weigelt schrieb:
> * Robert Schulze <rob at rob-schulze.de> schrieb:
> 
> hi,
> 
>> dann läuft PHP unter der UID des Apachen. Wenn kein Dateisystemzugriff
>> benötigt wird, also alles über eine Datenbankanbindung geschiet, dann
>> mag man dies noch verzeihen, weil der Apache dann keine
>> Schreibberchtigung in den Userdirs braucht. Wenn auch Dateizugriff über
>> PHP möglich sein soll, dann viel Spaß mit den Schülern, die sich
>> gegenseitig ihre Dateien weglöschen.
> 
> Für die DB braucht man aber Zugangsdaten. Und die liegen im
> Filesystem. Ergo kann ein Script eines Users auch auf die der
> anderen Zugreifen und ggf. dort die DB-Zugangsdaten auslesen,
> es sei denn man behilft sich mit Krücken wie safe_mode ;-o

Ich bin kein PHP-Fan. Aber warum ist safe_mode eine Krücke?
so ist es einfach nur eine (abfällige) Meinung. Aber ich hätte gern
Argumente.

MfG Hans-Dietrich






From hd.kirmse at gmx.de  Thu Dec 10 21:08:55 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Thu, 10 Dec 2009 21:08:55 +0100
Subject: apache - Fehler :(
In-Reply-To: <200912100955.39132.linux@eichsfeld.net>
References: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com>
	<4B1FFB8A.4090505@gmx.de>	<4B20170E.4060201@gmx.de>
	<200912100955.39132.linux@eichsfeld.net>
Message-ID: <4B215557.6050905@gmx.de>

Hallo Niels,

Niels Dettenbach schrieb:

> Ich nehme an, das das so nicht funktioniert. I.d.R. liegt den Sourcen von 
> "Serverprogrammen" zwar ein passendes Init-Script bei, aber in vielen Fällen 
> wird dies beim Kompilieren nicht mit an die (abweichend) konfigurierte 
> Umgebung "angepasst".

Danke für den Hinweis, hat mir sicher sehr viel Zeit gespart.


> Wenn Du Dir etwas mehr zutraust, kannst Du auch aus z.B. dieser Vorlage:
> http://mythwiki.de/index.php?title=HOWTO_Debian_init_script
> 
> ein einfacheres, aber auch passendes, Init-Script basteln.

oh ja, diese Vorlage ist sogar für mich verständlich und das bekomme
ich hin.

Danke auch für diesen Hinweis.

MfG Hans-Dietrich



From hd.kirmse at gmx.de  Thu Dec 10 21:12:16 2009
From: hd.kirmse at gmx.de (Hans-Dietrich Kirmse)
Date: Thu, 10 Dec 2009 21:12:16 +0100
Subject: apache - Fehler :(
In-Reply-To: <20091210120544.GA6174@whitebox.dl5mlo.de>
References: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com>
	<4B1FFB8A.4090505@gmx.de>	<4B20170E.4060201@gmx.de>
	<200912100955.39132.linux@eichsfeld.net>
	<20091210120544.GA6174@whitebox.dl5mlo.de>
Message-ID: <4B215620.7070502@gmx.de>

Hallo Mario,

Mario Lorenz schrieb:
> Moin,
> 
>>> Meine Frage: sind meine Überlegungen richtig und würde das gehen? (Dann
>>> würde es sich für mich echt lohnen, mich mit dem Compilieren zu
>>> beschäftigen - wie gesagt, noch nie gemacht)
>>>
>> Es lohnt sich eigentlich immer - vor allem um den Bau eines eigenen Kernels 
>> kommt man irgendwann meist nicht mehr herum. Zudem lernt man viel dabei.. ;)
> 
> Nein. Es ist schön, die Möglichkeit zu haben, wenn man wirklich etwas
> spezielles braucht. Aber es lohnt sich praktisch nie, etwas selbst zu bauen,
> wenn es was gleich gutes in einer Distribution gibt.

Sehe ich genauso und habe ich auch schon geschrieben, das wir uns (wenn
irgend möglich und sinnvoll) an die stable-Version von Debian (Lenny)
halten.

> Begründung:
> 
> Wenn Du etwas selbst gebaut hast, musst Du es selbst supporten. Zum Beispiel
> zeitnah das System neu bauen, wenn ein Sicherheitsloch gefunden wurde.
> Das passiert *immer* ungeplant, und Du wirst die Zeit dafür in der Regel nicht
> haben. Beim Verwenden des Distri-Paketes ist es in der Regel
> apt-get update && apt-get upgrade und fertig.

genau darum.

> (und in Mission-Critical-Fällen ist das Wartungsfenster dafür schon 
> schwer genug zu kriegen...)
> 
> Profitiere von Backports, Q&A etc. der Gemeinschaft (=Distribution) und
> stecke die gesparte Zeit lieber in ein OpenSource-Projekt...

Es geht um ein Opensource-Projekt, welches eine eigene Distribution
werden soll - eben der Nachfolger von Arktur4. Derzeit ist es noch nur
eine Anleitung zum händischen Erstellen eines Schulservers - leider.
Aber das wird sich ändern ;)

MfG Hans-Dietrich




From ml-tlug at vdazone.org  Thu Dec 10 23:02:44 2009
From: ml-tlug at vdazone.org (Mario Lorenz)
Date: Thu, 10 Dec 2009 23:02:44 +0100
Subject: apache - Fehler :(
In-Reply-To: <200912101504.56990.linux@eichsfeld.net>
References: <lZTQVxgC0pmq.RwPltTQJ@syndicat.com>
	<200912100955.39132.linux@eichsfeld.net>
	<20091210120544.GA6174@whitebox.dl5mlo.de>
	<200912101504.56990.linux@eichsfeld.net>
Message-ID: <20091210220244.GA8479@whitebox.dl5mlo.de>

Hallo Niels,

Am 10. Dec 2009, um 15:04:56 schrieb Niels Dettenbach:
> Unter Debian hat mich (früher) immer geärgert, das ich das komplette System 
> nicht ohne größeres Gefrickel oder Fehlermeldungen mal am Stück neu übersetzen 
> kann (u.a. ein Grund, warum ich heute mehr mit Gentoo mache). Ob das heute 
> noch so ist, kann ich nicht sagen - habe es nicht wieder probiert...

Jaa, Gentoo. Das hab ich einmal probiert, ist zugegeben eine Weile her.
Man warb damit, dass man n Stunden investieren soll, quasi in regelmäßigen Abständen, um
das System neu zu compilieren. Das habe den Vorteil, dass man prozessor- und systemspezifische
Optimierungen vornehmen könne und so ein höherperformantes System kriegen würde.
Nachdem dem emerge world lief ca. nichts mehr, inclusive des C-Compilers der mit Internal
Compiler Errors umsich warf. Wahrscheinlich hat irgendwas die Optimierungsoptionen nicht
vertragen. Jedenfalls durfte ich das System dann wegwerfen. Glücklicherweise wars nur
ne Spielumgebung.

Nein, sowas brauch ich nicht in Produktionsumgebungen.
Ich kompensier die 10% Performance-Gewinn lieber mit 10% mehr Rechenleistung,
und nehme die Binaries(!) die exakt identisch durch QA vieler Leute gegangen sind.

> Für den "Normalanwender" auf x86 PC & sog. "Servern" (mit Einschränkungen auch 
> AMD64) mag Deine Aussage sicher weithin zutreffen. 

Ok, die beschriebene Gruppe sind, äh, 99 oder 99.5% der Linux-Anwender?
Ich schrieb doch, das schöne ist, das man das dank der Sourcen selber kompilieren kann,
wenn man wirklich unbedingt muss...

> Aber auch solche kommen (so meine Erfahrung) irgendwann an Ihre Grenzen - z.B. 
> wenn der für viel Geld hochzertifizierte "Red-Hat Administrator" sein WLAN 
> Interface am Notebook nicht in Gang bekommt (und deshalb weiter Windows nutzen 
> "muß"), weil er nicht gelernt hat wie man nen Kernel "per Hand" baut (denn 
> Red-Hat hatte da gerade die passenden "Centrino-"(!)Treiber noch nicht als rpm 
> im Repository...)...

Der so teuer zertifzierte Red-Hat Administrator hat, wenn er sein Geld wert war,
vorher die HCL gecheckt und ein geeignetes Notebook ausgewählt. Jedenfalls hat
er *nicht* einen eigenen Kernel gebaut, weil dann nämlich das teure RHEL nicht
mehr zertifiziert ist. Und man kauft RHEL (und den dazugeörigen Administrator) nur,
wenn man auf die Zertifizierung Wert legt. (weil, sonst ist Windows billiger..)

Mario

-- 
Mario Lorenz                            Internet:    <ml at vdazone.org>
                                        Ham Radio:   DL5MLO at DB0ERF.#THR.DEU.EU
Trust the computer industry to shorten "Year 2000" to Y2K.  It was this kind
of thinking that caused the problem in the first place.

From linux at eichsfeld.net  Fri Dec 11 08:45:27 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Fri, 11 Dec 2009 08:45:27 +0100
Subject: AW: Re: apache - Fehler :(
Message-ID: <mjYGgVcbvWZ1.YM06HtBT@syndicat.com>

...ich kann dazu nicht viel sagen, denn ich verwende (aus guten Gründen) Gentoo auf dem Großteil der Produktionssysteme wie auch FreeBSD, NetBSD und zuweilen auch OpenBSD ("leider" alles Systemen, die zumindest einmal selbst übersetzt worden sind).

Während die Wartungsaufwendungen bei z.B. Debian bei selbst eingewartetem Code oder Binaries in ein System wie von Dir beschreiben, ist genau dieses Teil des Basiskonzeptes o.g. Systeme.

Die Performancegewinne und teils erheblichen Ressourceneinsparungen sind für mich lange nicht der Hauptpunkt, warum ich die Systeme (angepasst) verwende. Einen höheren Wartungsaufwand kann ich nicht erkennen, ganz im Gegenteil - vor allem wenn man mehr als z.N. nur nen Desktop mit Linux ausstatten will. 

Aber dafür gibt es ja wieder "bessere" Systeme a kla Ubuntu...

Wenn Dein emerge world sich derart verhielt, hast Du recht wahrscheinlich die falschen Optimierungen (Flags) verwendet oder die falsche Architektur gewählt.

Der Red-Hat Mann hatte sein Notebook schon früher mit dem gewohnten Windows betrieben (d.h. beim Kauf stand die Entscheidung Red-Hat darauf zu verwenden noch nicht an). Für einen Iraker ist die Auswahl möglicher Modelle weniger groß als z.B. für uns.

Immerhin bin ich der Meinung, das jeder Linux-Admin wenigstens irgendwann mal einen Kernel gebacken haben sollte oder wissen sollte, wie es geht. 

Beste Grüße,


Niels.


From announcements at tlug.de  Mon Dec 14 06:00:02 2009
From: announcements at tlug.de (announcements at tlug.de)
Date: Mon, 14 Dec 2009 06:00:02 +0100 (CET)
Subject: TLUG Termin: 2009-12-17 19:00:00 in Jena
Message-ID: <20091214050002.C826759E2D@tlug.de>

Naechster Termin der Thueringer Linux User Group:

 * 2009-12-17 19:00:00: Stammtisch in Jena

Viel Spass dabei!

-- 
- automatically generated, do NOT reply -

From Schwirz.Linux-AG at freenet.de  Tue Dec 15 23:46:37 2009
From: Schwirz.Linux-AG at freenet.de (Norman)
Date: Tue, 15 Dec 2009 23:46:37 +0100
Subject: (Offtopic) GPS-Logger =?ISO-8859-15?Q?f=FCr_Weihnachten_gesu?=
	=?ISO-8859-15?Q?cht?=
Message-ID: <4B2811CD.3040500@freenet.de>

Hallo allerseits!

Ich suche einen GPS-Logger, der hauptsächlich zum Geo-taggen von Fotos
verwendet werden soll. (Digikam, Openstreetmap etc.)

Hat jemand von euch Erfahrung damit und kann mir vielleicht das eine
oder andere Gerät empfehlen?

Danke schon mal im Voraus.
Norman


From chr.ordig at gmx.net  Wed Dec 16 14:51:34 2009
From: chr.ordig at gmx.net (Christian Ordig)
Date: Wed, 16 Dec 2009 14:51:34 +0100
Subject: (Offtopic) GPS-Logger =?iso-8859-1?Q?f?=
	=?iso-8859-1?Q?=FCr?= Weihnachten gesucht
In-Reply-To: <4B2811CD.3040500@freenet.de>
References: <4B2811CD.3040500@freenet.de>
Message-ID: <20091216135134.GA53317@tlug.de>

On Tue, Dec 15, 2009 at 11:46:37PM +0100, Norman wrote:
> Hallo allerseits!
> 
> Ich suche einen GPS-Logger, der hauptsächlich zum Geo-taggen von Fotos
> verwendet werden soll. (Digikam, Openstreetmap etc.)
> 
> Hat jemand von euch Erfahrung damit und kann mir vielleicht das eine
> oder andere Gerät empfehlen?
Hi Norman,

ich denke das geht etwas über die geplanten Möglichkeiten und evtl. 
auch über das geplante Budget hinaus, allerdings ist es vielleicht 
trotzdem interessant für Dich, wenn Du viel draußen unterwegs bist usw.

Ich nutze für sowas ein Garmin eTrex Vista HCx mit einer 4GB MicroSD-Karte.
Auf der Karte haben die Kartendaten und Unmengen an Logs platz. Ich 
nutze das Teil jetzt seit knapp einem Jahr und es passen immer noch 
Logs drauf. Ich kann einstellen ob er in regelmäßigen Zeit-Intervallen, 
Distanz-Deltas oder "automatisch" logt. Zeitintervalle und 
Distanz-Deltas sind einstellbar. Die Logs bekommt man als GPX-Dateien 
auf den Rechner (Massenspeicher-Gerät) und kann sie dort in jede 
Geotagging-Software kippen, die GPX versteht.

Grüße.

-- 
Christian Ordig
Germany
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 187 bytes
Beschreibung: nicht verfügbar
URL         : http://www.tlug.de/pipermail/tlug_allgemein/attachments/20091216/cab0b990/attachment.pgp 

From linux at eichsfeld.net  Wed Dec 16 15:33:15 2009
From: linux at eichsfeld.net (Niels Dettenbach)
Date: Wed, 16 Dec 2009 15:33:15 +0100
Subject: AW: Re: (Offtopic) GPS-Logger =?UTF-8?B?ZsO8cg==?= Weihnachten gesucht
Message-ID: <74X5XKgzZfMm.V2BHZpyY@syndicat.com>

Zum Taggen von Fotos an meinem Nokia Telefon (sambian 3rd - E90) verwende ich "Location Tagger" von Nokia, die es bei Nokia als freie (beta?) Software gibt.

Es kann als Service im Hintergrund laufen und versieht automatisch alle geschossenen Fotos mit Geokoordinaten. Der Stromverbrauch scheint marginal.

Extra Digicam hab ich nicht. GPS ist im Telefon (GPS per Buletooth geht aber auch).

Mag sein, das Du das gebrauchen kannst.

Niels.


From mailinglists at pennewiss.de  Wed Dec 16 15:57:28 2009
From: mailinglists at pennewiss.de (Marcel =?iso-8859-15?q?Pennewi=DF?=)
Date: Wed, 16 Dec 2009 15:57:28 +0100
Subject: (Offtopic) GPS-Logger =?iso-8859-15?q?f=FCr_Weihnachten?= gesucht
In-Reply-To: <4B2811CD.3040500@freenet.de>
References: <4B2811CD.3040500@freenet.de>
Message-ID: <200912161557.28325.mailinglists@pennewiss.de>

On Tuesday 15 December 2009 23:46:37 Norman wrote:
> Hallo allerseits!
> 
> Ich suche einen GPS-Logger, der hauptsächlich zum Geo-taggen von Fotos
> verwendet werden soll. (Digikam, Openstreetmap etc.)

iBlue 747A+ - GPS Recorder

Geht mit 2.6.29 und mtkbabel auch unter Linux. Kann Bluetooth oder selber 
loggen...
 
Quelle z.B. www.outdoortrends.de

Marcel
...gerade auch einen für Weihnachten bestellt habend

From Schwirz.Linux-AG at freenet.de  Thu Dec 17 22:32:09 2009
From: Schwirz.Linux-AG at freenet.de (Norman)
Date: Thu, 17 Dec 2009 22:32:09 +0100
Subject: (Offtopic) GPS-Logger =?ISO-8859-15?Q?f=FCr_Weihnachten_?=
	=?ISO-8859-15?Q?gesucht?=
In-Reply-To: <20091216135134.GA53317@tlug.de>
References: <4B2811CD.3040500@freenet.de> <20091216135134.GA53317@tlug.de>
Message-ID: <4B2AA359.609@freenet.de>

Am 16.12.2009 14:51, schrieb Christian Ordig:
> On Tue, Dec 15, 2009 at 11:46:37PM +0100, Norman wrote:
>> Hallo allerseits!
>>
>> Ich suche einen GPS-Logger, der hauptsächlich zum Geo-taggen von Fotos
>> verwendet werden soll. (Digikam, Openstreetmap etc.)
>>
>> Hat jemand von euch Erfahrung damit und kann mir vielleicht das eine
>> oder andere Gerät empfehlen?
> Hi Norman,
> 
> ich denke das geht etwas über die geplanten Möglichkeiten und evtl. 
> auch über das geplante Budget hinaus, allerdings ist es vielleicht 
> trotzdem interessant für Dich, wenn Du viel draußen unterwegs bist usw.
> 
> Ich nutze für sowas ein Garmin eTrex Vista HCx mit einer 4GB MicroSD-Karte.
> Auf der Karte haben die Kartendaten und Unmengen an Logs platz. Ich 
> nutze das Teil jetzt seit knapp einem Jahr und es passen immer noch 
> Logs drauf. Ich kann einstellen ob er in regelmäßigen Zeit-Intervallen, 
> Distanz-Deltas oder "automatisch" logt. Zeitintervalle und 
> Distanz-Deltas sind einstellbar. Die Logs bekommt man als GPX-Dateien 
> auf den Rechner (Massenspeicher-Gerät) und kann sie dort in jede 
> Geotagging-Software kippen, die GPX versteht.
> 
> Grüße.
> 

Danke für den Tipp,

aber ein einfacher Logger sollte es auch tun - Hauptsache das Ding is
bezahlbar.

Norman

From Schwirz.Linux-AG at freenet.de  Thu Dec 17 22:59:53 2009
From: Schwirz.Linux-AG at freenet.de (Norman)
Date: Thu, 17 Dec 2009 22:59:53 +0100
Subject: (Offtopic) GPS-Logger =?ISO-8859-15?Q?f=FCr_Weihnachten_?=
	=?ISO-8859-15?Q?gesucht?=
In-Reply-To: <200912161557.28325.mailinglists@pennewiss.de>
References: <4B2811CD.3040500@freenet.de>
	<200912161557.28325.mailinglists@pennewiss.de>
Message-ID: <4B2AA9D9.1020206@freenet.de>

Am 16.12.2009 15:57, schrieb Marcel Pennewiß:
> On Tuesday 15 December 2009 23:46:37 Norman wrote:
>> Hallo allerseits!
>>
>> Ich suche einen GPS-Logger, der hauptsächlich zum Geo-taggen von Fotos
>> verwendet werden soll. (Digikam, Openstreetmap etc.)
> 
> iBlue 747A+ - GPS Recorder
> 
> Geht mit 2.6.29 und mtkbabel auch unter Linux. Kann Bluetooth oder selber 
> loggen...
>  
> Quelle z.B. www.outdoortrends.de
> 
> Marcel
> ...gerade auch einen für Weihnachten bestellt habend

Hej, der sieht ja niedlich aus. Weiß vielleicht jemand wofür die drei
Lämpchen sind?
Nee, mal im Ernst. Marcel, du benutzt dieses Gerät also. Wie macht es
sich so?
Meinst du ob der auch mit 'nen 2.6.31iger Kernel (OpenSuse) arbeitet? :-)

Mal 'ne Anfängerfrage: Welche Funktionen der teureren Geräte sind
wirklich sinnvoll? (Lieber 10 Euro mehr bezahlt, als später drüber ärgern)


Norman

P.S.: Ich wünsch schon mal Frohe Weihnachten

From mailinglists at pennewiss.de  Fri Dec 18 16:22:24 2009
From: mailinglists at pennewiss.de (Marcel =?iso-8859-15?q?Pennewi=DF?=)
Date: Fri, 18 Dec 2009 16:22:24 +0100
Subject: (Offtopic) GPS-Logger =?iso-8859-15?q?f=FCr_Weihnachten?= gesucht
In-Reply-To: <4B2AA9D9.1020206@freenet.de>
References: <4B2811CD.3040500@freenet.de>
	<200912161557.28325.mailinglists@pennewiss.de>
	<4B2AA9D9.1020206@freenet.de>
Message-ID: <200912181622.24705.mailinglists@pennewiss.de>

On Thursday 17 December 2009 22:59:53 Norman wrote:
> Hej, der sieht ja niedlich aus. Weiß vielleicht jemand wofür die drei
> Lämpchen sind?

Bluetooth, GPS-Fix und Speicherzustand AFAIR.

> Nee, mal im Ernst. Marcel, du benutzt dieses Gerät also. 

Nein. Erst nach Weihnachten *g*

> Wie macht es sich so?

Ich hatte den Vorgänger I-blue 747 mal zum Test - ich hab ihn rein als Logger 
aber auch am XDA Neo (mit OpenStreetMap-Tool *Namevergessen* zum Taggen). Ging 
super. 
Der 747 hatte nen Standard-Nokia-Akku drin - der ist auch günstig zu ersetzen.

> Meinst du ob der auch mit 'nen 2.6.31iger Kernel (OpenSuse) arbeitet? :-)

Denk schon ;)
 
> Mal 'ne Anfängerfrage: Welche Funktionen der teureren Geräte sind
> wirklich sinnvoll? (Lieber 10 Euro mehr bezahlt, als später drüber ärgern)

Also ich brauche nur Loggen und Bluetooth. Das tat er anstandslos.

Marcel

From misk at gmx.net  Fri Dec 18 17:39:04 2009
From: misk at gmx.net (Christian Koerner)
Date: Fri, 18 Dec 2009 17:39:04 +0100
Subject: (Offtopic) GPS-Logger =?ISO-8859-15?Q?f=FCr_Weihnachten_?=
	=?ISO-8859-15?Q?gesucht?=
In-Reply-To: <4B2811CD.3040500@freenet.de>
References: <4B2811CD.3040500@freenet.de>
Message-ID: <4B2BB028.9040109@gmx.net>

Norman wrote:
> Ich suche einen GPS-Logger, der hauptsächlich zum Geo-taggen von Fotos
> verwendet werden soll. (Digikam, Openstreetmap etc.)
>
> Hat jemand von euch Erfahrung damit und kann mir vielleicht das eine
> oder andere Gerät empfehlen?
Servus Norman,

im Wiki von OpenStreetMap findest du die GPS-Reviews-Seite [1] mit einer 
Liste gaengiger GPS-Empfaenger und Datenloggern.
Als Datenlogger beliebt, sind die Geraete der Hersteller Transsystem, 
Royaltec, Wintec, Holux, (u.v.m.).

Zwei Geraete mit denen ich Erfahrungen gesammelt habe...
Fuer einfaches Aufzeichnen finde ich den Royaltek RGM-3800 im 
Preis-/Leistungsverhaeltnis guenstig.
Ein reiner GPS-Logger mit langer Laufzeit (wechselbaren AAA-Akkus) und 
grossen Trackspeicher.
Neben Zeit und Position koennen auch Hoehe (GPS), Geschwindigkeit, 
Distanz und - was fuer OpenStreetMap ganz gut ist -
die Empfangsqualitaet mit aufgezeichnet werden und das in einen 
einstellbaren Intervall (>= 1s mit neuer Firmware, vorher >= 5s).
Das Geraet gab es das Jahr ueber fuer 42 bis 48 Euro, momentan fuer 10 - 
15 Euro mehr.

Sein Bruder der Royaltek RGM-2300, ebenfalls in der Preislage zu haben, 
hat zusaetzlich Bluetooth, zeichnet ohne Firmwareupdate
mit 1 Hz auf, vermissen tue ich da nur die Aufzeichnung der DOP-Werte 
(Empfangsqualitaet) und ein Ladekabel fuer die Steckdose
(komt mit ein Ladestecker fuer den Zigarettenanzuender).
Betrieben wird er ueber ein Nokia Akku (720 mAh), Zweitakkus mit mehr 
Kapazitaet sind fuer 3 - 5 Euro (exkl. Versand) zu bekommen.

Die Empfangsqualitaet ist bei beiden Geraeten sehr gut, bei dem RGM-3800 
meines Erachtens etwas besser.

Einen guten Vergleich beider Geraete kannst du auf Skyberts Seite [2] 
finden.

Fuer 20 - 30 Euro bekommst du andere Logger die mit einen Knopf zum 
Speichern von Wegpunkten und event. ein Display zur Anzeige
von Status und Wegpunktnummer daher kommen .

Ciao,
Christian

-
[1] OpenStreetMap Wiki - GPS Reviews
http://wiki.openstreetmap.org/wiki/GPS_Reviews

[2] Skybert - Review GPS-Empfänger RoyalTek RBT-2300 & RGM-3800
http://www.skybert.de/navigation/royaltek.htm

From announcements at tlug.de  Sun Dec 20 06:00:01 2009
From: announcements at tlug.de (announcements at tlug.de)
Date: Sun, 20 Dec 2009 06:00:01 +0100 (CET)
Subject: TLUG Termin: 2009-12-23 19:00:00 in Gera
Message-ID: <20091220050001.E613F59CCE@tlug.de>

Naechster Termin der Thueringer Linux User Group:

 * 2009-12-23 19:00:00: Stammtisch in Gera

Viel Spass dabei!

-- 
- automatically generated, do NOT reply -

From announcements at tlug.de  Mon Dec 28 06:00:02 2009
From: announcements at tlug.de (announcements at tlug.de)
Date: Mon, 28 Dec 2009 06:00:02 +0100 (CET)
Subject: TLUG Termin: 2009-12-31 19:00:00 in Jena
Message-ID: <20091228050002.4A71159E40@tlug.de>

Naechster Termin der Thueringer Linux User Group:

 * 2009-12-31 19:00:00: Stammtisch in Jena

Viel Spass dabei!

-- 
- automatically generated, do NOT reply -

From lugjena at kubieziel.de  Mon Dec 28 11:20:22 2009
From: lugjena at kubieziel.de (Jens Kubieziel)
Date: Mon, 28 Dec 2009 11:20:22 +0100
Subject: TLUG Termin: 2009-12-31 19:00:00 in Jena
In-Reply-To: <20091228050002.4A71159E40@tlug.de>
References: <20091228050002.4A71159E40@tlug.de>
Message-ID: <20091228102022.GG9520@kubieziel.de>

* announcements at tlug.de schrieb am 2009-12-28 um 06:00 Uhr:
> Naechster Termin der Thueringer Linux User Group:
>  * 2009-12-31 19:00:00: Stammtisch in Jena

Die Quergasse in Jena hat an diesem Tag geschlossen. Die LUG Jena trifft
sich daher im Cafe Wagner und wird bei Dragons everywhere mitmachen.

Besten Gruß
-- 
Jens Kubieziel                                   http://www.kubieziel.de
Man kann aus jedem Gespräch, bei dem man selbst nicht dauernd redet,
sondern ganz einfach zuhört, unendlich viel erfahren und lernen. Professor.
Dr. Roman Herzog
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : nicht verfügbar
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : http://www.tlug.de/pipermail/tlug_allgemein/attachments/20091228/26ae65a0/attachment.pgp