[linux-l] Virtualisierung

[Volker Grabsch]

On Fri, Jun 02, 2006 at 12:45:54AM +0200, Thomas Schmidt wrote:
> Vielen Dank an Volker für die ausführliche Mail.
> Nach Besuchen Deiner Webseite und dem Auffinden eines Angebotes für
> kostenpflichtige Beratung habe ich nicht mehr zu hoffen gewagt, dass Du
> Dir so detailiert Gedanken machst.

Allein die Tatsache, dass ich in dieser Mailingliste aktiv bin, sollte
eigentlich zeigen, dass ich nicht zu denjenigen gehöre, die ihr Wissen
für so einmalig und wertvoll halten, dass sie nur gegen Barzahlung den
Mund aufmachen. (... wie in schlechten Krimifilmen ;-))

Davon abgesehen verstehe ich unter Beratung doch ein wenig mehr als
die 3 Mails, die das hier vielleicht werden.

> Vorweg: Wenn ich von Kunden spreche, meine ich keine zahlende
> Kundschaft. Es geht mir darum, den steigenden Bedarf an "schnell mal ne
> Mailadresse" und "Webspace für unser Projekt" von Freunden und
> Uniangelegenheiten zu managen.

Das hättest du sagen müssen, das ist ein wichtiger Punkt. Es bedeutet,
dass du den Benutzern mehr Vorgaben machen kannst, aber auch, dass du
mit mehr Sonderwünschen konfrontiert wirst. Du bist in einer stärkeren
Position als jemand mit zahlenden Benutzern, das solltest du nutzen, um
dir unnötige Arbeit zu ersparen. Kurz: KISS

> Von den etwa 20 Domains auf meinem Server wird keine jemals Gewinn abwerfen.

Bei uns ist Hosting auch nichts, das Gewinn abwirft. Ich glaube, heutzutage
kann keiner mehr mit Hosting Gewinn machen. Vielleicht in Kombination mit
Webdesign, Pflege der Seiten, etc., sodass das Hosting zum Service
dazugehört. Aber solch ein Glück hatten wir (die NJH) bisher nicht. Aber
was soll's. Die Server wollten wir sowieso, allein für unsere eigenen
Projekte. Außerdem bleibt man so "in Form", wenn man regelmäßig mit
einem laufenden Server zu tun hat. Eines Tages finanzieren sich die Server
vielleicht wirklich selbst.

> >Wenn du Debian als Hauptsystem und auch in den VServern haben willst, 
>> kann wir auf jeden Fall meine bereits erwähnte Howto weiterhelfen.
> Die habe ich nun schon zweimal gelesen. Eine Aktualisierung wäre wunderbar.

Okay, ich werde mich dransetzen. Die Aktualisierung wird die aktuellen
Sarge-Pakete und den Kernel-2.6 besprechen.

> >>Die zweite Frage: Gibt es Webhostingserver fertig?
> Damit meinte ich ein Script, das alle 100 benötigten Pakete in Debian
> installiert und mit brauchbarem Konzept konfiguriert. Aber so
> installiere ich wenigstens, was mir gefällt.

Ich weiß nicht, wie du dir das vorstellst, aber so viele sind das nicht.
Vielleicht bei PHP und anderen Programmiersprache jeweils 10-20 Pakete,
aber Webserver und Mailserver werden jeweils ca. 3 Pakete sein.
Außerdem hast du die große Wahlfreiheit. Die würde dir ein Script
nehmen.

Eher denkbar wäre eine Howto, die noch verschiedene Optionen beinhaltet,
und Hinweise, an welchen Stellen von noch selbst "schrauben" sollte,
wenn's klemmt.

Konzepte gibt's auch viele.

> >>-Webseiten mit unterschiedlicher Programmiererlaubnis
> >>~/htdocs, für eingeschränkte Kunden unbeschreibbare .htaccess
> >>Für die Subdomain kann man eine Regel schreiben. Aber:
> >>Wie kommen die eigenen Domains auf den Webspace?
> >Du machst es IMHO zu kompliziert. "unbeschreibbare .htaccess"?
> >Warum nicht gleich entsprechende Einträge in die httpd.conf, und
> >für den VHost ein "AllowOverride None"?
> Ich ging davon aus, auf VHosts in Apache zu verzichten. Aber das ist
> wahrscheinlich auch wegen der Logdateien Quatsch.

Es ist allgemein Quatsch, wenn du die VHosts gegen was Komplizierteres
ersetzt. Wenn du ein Tool drumherum baust, das letzten Endes doch wieder
alle Features bieten soll, kannst du gleich bei VHosts bleiben. Die sind
wenigstens sauber durchdacht, was bei einer selbstgestrickten Variante
eher unwahrscheinlich ist. (vielleicht nach dem 3. Neuschreiben oder so
:-))

> Sehe ich richtig, dass ich dann im Apache und Mail-Server gleichermaßen
> die Domains eintragen muß? Naja, so schlimm ist das nicht. Super wäre,
> wenn nur irgendwo steht, welche Domain welchem Benutzer gehört und der
> dann alles selbst konfiguriert.

Die meisten Mailserver können aus SQL- und LDAP-Datenbanken ihre Infos
herholen. Aber in deinem Fall sollte eine Konfigurationsdatei namens
"aliases" schon alles regeln können. :-)

Die Zuweisung der Domains willst du übrigens lieber als Administrator
machen, da bin ich mir sicher! Kontrolle abgeben ist nur bei Subdomains
sinnvoll.

Apache kann noch nicht wirklich aus anderen Datenbanken lesen. Es gibt
Module, mit denen kann man begrenzt VirtualHosts via LDAP anlegen. Aber
das ist totaler Humbug, weil der LDAP dann genau die Konfigurationsdatei
widerspiegelt. Eine Flexibilität wie bei Postfix oder Exim, wo du im
Prinzip eine beliebige LDAP-Struktur haben kannst, und die LDAP-Queries
in die Konfigurations-Datei schreibst, sowas gibt's für Apache nichtmal
ansatzweise, soweit ich weiß.

Auch RewriteRules sind an sich zwar praktisch, aber damit kannst du nur
primitive VirtualHosts nachbilden: Keine SuExec-Parameter, keine extra
Logfiles, u.s.w.  ... übrigens im Gegensatz zu der Authentifikation:
Die klappt nämlich sehr gut im Apache via LDAP. Aber das ist nur dann
sinnvoll, wenn du Webseiten hast, in die sich die Kunden einloggen
sollen, und du dafür HTTP-Auth nehmen willst. Und selbst dann ist es
nichts, was nicht dein CGI-Script auch erledigen könnte.

Man könnte höchstens regelmäßig die VirtualHost-Einträge des Apache per
Script generieren lassen. So würde ich es machen, wenn ich die Zeit dazu
hätte: Einen zentralen LDAP, der die Kunden und Domains enthält. Die
Mailserver (SMTP, IMAP, ..) greifen direkt darauf zu, der Apache kriegt
einen Teil seiner Konfiguration daraus generiert. Später würde ich
vielleicht ein Apache-Modul dafür schreiben.

> >Deshalb sehen einige VirtualHosts etwas "anders" aus: besondere 
> >RewriteRules, etc., ...
> Und darauf wollte ich auf dieser Installation gerade verzichten. Wobei,
> wenn es eh VHosts gibt, können die auch alle unterschiedlich sein.

Du solltest sie möglichst einheitlich gestalten, und nicht überfrachten.
Keine unnötige Extra-Wurst.

> >>-ein Mailpostfach, beliebig viele Adressen
> >>~/Mail, procmailrc
> >>Mailserver einstellen, dass seine Domains an den Kunden gehen
> >>Sehr schön wären mehrere Postfächer
> >Kannst du manuell verwalten. Soll der Kunde selbst Aliase anlegen
> >können, gibt es einige Webinterfaces.
> 
> Aliase gehen ja mit der procmailrc. Die macht nur leider keine
> Postfächer, auf die dann per IMAP zugegriffen werden kann.
> Wenn jeder Benutzer mehrere Postfächer hat, kann der Kundenname nicht
> der IMAP-Login sein, das erfordert wieder eine Datenbank. Also werde ich
> darauf verzichten müssen.

Ja, ist wohl besser so. Das ist der größte Teil der Arbeit, und eine
"never ending story". Viele Lösungsansätze, aber keiner hatte das Zeug,
ein wirklich durchschlagender Erfolg zu werden.

> Das gleiche Thema gilt für FTP-Benutzer. Hier sind allerdings mehrere
> Admins pro Kunde unbedingt notwendig.

Wenn der Kunde seinen Leuten zum Teil nicht vertrauen kann, solltest du
ihn auch nicht hosten, schon gar nicht kostenlos.

Mehrere Admins, wo ist das Problem? Ein SSH-Zugang, mit oder ohne
Passwort, und jeder Admin trägt seinen SSH-Schlüssel in die
"authorized_keys" ein.

Andere Variante: Trage mehrere User ein, aber gib ihnen die gleiche UID
(und gleiches Homedir, etc.).
Müsste sogar vom "adduser"-Programm direkt unterstützt sein. Dann kannst
du jedem einen extra Username und Passwort geben, aber sie landen im
selben Verzeichnis.

Willst du alles ganz einheitlich haben, nimm einen LDAP oder ne
SQL-Tabelle, da stehen die User, Mailaccounts, etc. drin, und dann
richte PAM via LDAP ein.

> SSH wäre toll und kein Nachteil
> gegenüber FTP.

Nicht ganz, Shell-Zugang ist grundsätzlich riskanter als reiner Datei-
Zugriff. Aber nicht, wenn ohnehin CGI-Scripte laufen dürfen. :-)

> Eine chroot-Umgebung funktioniert nicht, weil dann jeder
> Admin sein eigenes Minilinux braucht, also ein /etc, /bin usw.
> Verzeichnis mitten im Webspace. Ohne chroot kann er voll auf alle Daten
> des Kunden zugreifen.

Ich weiß jetzt nicht, was für dich ein "Admin" und was ein "Kunde" ist.
Außerdem ist mir nicht klar, wieso diejenigen, die Webseiten hochladen,
überhaupt in verschiedene Gruppen eingeteil werden müssen.

Ich weiß, dass es Hosting-Anbieter gibt, wo jeder Kunde mehrere FTP-
Zugänge anlegen kann, die in verschiedene Unterverzeichnisse (z.B. für
bestimmte Subdomains) festgedongelt werden. Einen wirklichen Sinn darin
sah ich aber bisher nicht. Die Kunden, die diese Größenordnung haben,
dass sie derart strenge Aufgabentrennung vornehmen, holen sich eh ihren
eigenen Server ... und ein vernünftiges CMS statt FTP-Zugang für jeden
Teil-Autor. :-)

> Habe ich richtig verstanden, dass Du keinen FTP-Server laufen hast?

Nein, wir haben schon noch FTP, aber nur aus "politischen Gründen". Die
dämlichen Hosting-Anbieter-Vergleichs-Seiten kennen nur FTP, und es wäre
ein wichtiges Check-Häkchen weniger, wenn wir's nicht anbieten würden.

Wir raten aber jedem Kunden davon ab und empfehlen SFTP.

> Was machst Du denn, wenn der Kunde Logins für seine Admins braucht?

Dann administriere ich seinen Server, wiegesagt. ;-)

Hosting-Kunden mit meheren "Admins" haben wir nicht. Würde mich
interessieren, die ein nicht-kommerzielles Projekt auf diese Komplexität
kommt. Es ist mir unbegreiflich.

> Weboberflächen, bei denen man umständlich jeden Transfer einzeln machen muß?

Gott bewahre, nein! Das heißt, wer will, kann sich sowas installieren.
Ich bin sogar mal in Situationen gekommen, wo ich mir sowas gewünscht
hätte, ist aber nur ganz selten. Das mit dem FTP und SFTP, was ich
geschrieben habe, hast du irgendwie falsch verstanden, ich hoffe, das
ist nun geklärt.

> Meine Idee ist jetzt, die Kunden nicht als User, sondern als Gruppen
> anzulegen.

Das ist zu umständlich. KISS. s.o.

> Probleme: PHP könnte nicht im Safe-Mode laufen, weil Dateien
> gelesen werden müssen, die der Gruppe, aber nicht dem gleichen Benutzer
> gehören. Der Kunde kann nicht die Daten seiner Admins bearbeiten.

Das PHP-Rechte-Problem musst du dir sowieso noch genau ansehen,
wiegesagt. Schon Lösungsideen?

> Alles kompliziert, ich mache mir besser später noch einmal Gedanken dazu

Das musst du wohl. Da sind noch einige Lücken. Und schreib mal bitte
mehr konkret zu deinem Anwendungsfall. (schließlich gebe ich hier
ebenfalls - wenn auch völlig harmlose - Firmeninterna raus, um die
Sachen anschaulicher erklären zu können)


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR