[linux-l] Virtualisierung

[Volker Grabsch]

On Thu, Jun 01, 2006 at 08:44:27PM +0200, Thomas Schmidt wrote:
> Ich habe mir nun überlegt, meinen Server folgendermaßen aufzuteilen:
> -Leeres Grundsystem (nur SSH für mich)
> -Emulierter/Virtualisierter/Whatever Server mit Projekt A
> -Emulierter/Virtualisierter/Whatever Server mit Projekt B
> -Emulierter/Virtualisierter/Whatever Server für Webhosting
> Alle mit eigener IP.
> 
> Die erste Frage: VServer oder VMware? Oder was?
> apt-get install vserver sieht für mich besser aus als ein Script für Suse.
> Suse oder RedHat möchte ich eigentlich nicht einsetzen.

Ich persönlich glaube, VServer sollten dafür reichen. Zumindest setzen
wir unser System so ähnlich wie du ein, und haben gute Erfahrungen
damit. Wenn du Debian als Hauptsystem und auch in den VServern haben
willst, kann wir auf jeden Fall meine bereits erwähnte Howto weiterhelfen.

Wenn du dich also wirklich für VServer entscheidest, sag mir bescheid,
dann aktualisiere ich die Howto nochmal. Das wollte ich eh machen, aber
ich hab genug anderes zu tun, also lass ich mich bitten. :-)

> Die zweite Frage: Gibt es Webhostingserver fertig?

Jein. Klar gibt es sowas wie Plesk und so, was du bei jedem Root-Server
hinterhergeworfen kriegst (meist aber in Verbindung mit SuSE), aber ein
wirklich freies System gibt's nicht "fertig". Selbst wenn, was nützt es?
Es müsste auf den aktuellen Stand gehalten werden, wäre also letztlich
ne eigene Distribution. (bzw. ne Sub-Distribution von z.B. Debian)
Und mal ehrlich: Wer würde sich die Mühe machen, eine freie Distribution
zu bauen, speziell für Webhoster?

Da müssten sich schon mehrere Hoster zusammentun, um gemeinsam sowas auf
die Beine zu stellen. Der Markt dafür ist sicher da, selbst
"festgefahrene", unflexible Strukturen wie Confixx und Plesk boomen,
nicht auszudenken, was da ein flexibles System leisten könnte.
Andererseits ist für kleinere Hoster der Aufwandt zu groß, und große
Hoster haben eh ihre eigene Entwicklungs-Abteilung dafür.
(bzw. ihre Admins :-))

Aber letztlich braucht es eine Konfigurations-Datei, eine Art Howto
für Hosting-Umgebungen. Denn die Pakete sind ja alle da: Man installiere
sich ein minimales Debian mit Apache, MySQL, einigen PHP-Paketen,
OpenSSH, und fertig.

(Eventuell noch exim/postfix/sendmail, Courier und slapd)

> Was ich brauche und wie ich mir die Umsetzung vorstellen könnte:
> -10 Kunden
> Einzelne Benutzer in /etc/passwd
> 
> -Für jeden eine Subdomain kunde.netAction.de, außerdem beliebig viele 
> eigene Domains.

So ungefähr läuft das bei uns, der NotJustHosting GbR, ebenfalls.
Außer dass wir noch ein Mailsystem haben, dies aber natürlich auf Basis
einer LDAP-Datenbank.

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

Bei uns hat jeder Kunde ein Hauptverzeichnis für die Webseiten,
und dabei für jede Webseite ein extra Unterverzeichnis.

Das heißt, nach Absprache auch etwas komplexere Sachen. Wenn wir
es schaffen, vom Kunden genug Infos zu bekommen, dass wir genau
sagen wissen, was er braucht, dann kriegt er auch das. Deshalb
sehen einige VirtualHosts etwas "anders" aus: besondere RewriteRules,
etc., ...

> -Webseiten-Logdateien mit Auswertung
> ~/log/access.log und error.log
> Auswerten von einem zentralen awstats.

AWstats ist in der Vergangenheit durch Sicherheitslücken aufgefallen,
die von keinem guten Programmierstil zeugen. Ich rate daher dringend,
nur statische Seiten erzeugen zu lassen (z.B. als Cronjob jede Stunde).
Wenn jemand wirklich AWstats als CGI will, soll er es sich selbst in
seinen Webspace installieren.

Meine Meinung, natürlich musst du dich an den Kundenwünschen
orientieren. Wenn jeder scharf auf den "Update"-Button von AWstats
ist, lohnt es wohl, ein paar Cents mehr zu verlangen und AWstats mit
Adleraugen im Blick zu behalten. Oder das Debian-Paket von AWstats
nehmen, das ist aber nicht so aktuell, daran könnten auch einige
Kunden stören.

> -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. Aber nichts, was ich empfehlen
könnte. Vielleicht hat ja jemand anderes gute Erfahrungen mit
irgendeinem Tool gemacht, würde mich interessieren.

Ich jedenfalls habe noch keines gesehen. Unser Mail-Administration-
Webinterface für die Kunden ist daher selbstgestrickt.

> -beliebig viele FTP-Zugänge mit einstellbarem chroot-Dir für Webmaster
> Umsetzung: ?
> 
> -ein paar Datenbanken
> Umsetzung: ?
> 
> -Cronjobs (kann ich auch individuell von Hand einrichten)
> Umsetzung: ?

Für alles gibt es verschiedene Wege. Und ich muss sagen, ich finde
es reichlich unverschämt, die BeLUG zu bitten, dir ein Konzept für
deinen Hosting-Server zu erarbeiten. Mach dir einen Kopf, biete
Lösungen an, nicht nur "?", dann sag ich (und viele andere hier
sicherlich auch) dir gern meine Meinung dazu. Ich meine, das Design
des Systems unterscheidet sich von Hostinganbieter zu Hostinganbieter,
je nach Größe und Art des Kundenstamms. Dein System gut zu planen und
einzurichten, mensch, genau dafür wirst du schließlich (u.a.)
bezahlt! Ein Hosting-Anbieter ist ein wenig mehr, als bloß jemand,
der die Mietkosten des Servers auf seine Kunden umlegt.

Außerdem geht es auch technisch gar nicht, dass wir dir hier ein
Konzept für deinen Server aufstellen, weil hier niemand die
Ansprüche deiner Kunden kennt. Zum Beispiel habe ich all unsere
Kunden dazu "erziehen" können, dass sie nicht nur das allerprimitvste
Dateitransfer-Protokoll kennen (FTP), sondern auch SFTP. Ist letztlich
nur ein anderes Programm, das sie benutzen. Aber ich hab's auch
schon erlebt, dass Leute partout nicht von ihrem FTP weg wollen,
wahrscheinlich weil sie das zuerst gelernt haben, und was der Bauer
nicht kennt, ... ihr wisst schon. Außerdem hat jeder Kunden bei uns
(als Service) einen Shell-Zugang, musste sehen, ob du das willst.
Interessante Datenbanken sind MySQL und PostgreSQL, ich persönlich
mag PostgreSQL lieber, aber die Kunden haben nunmal ihre verd***
PHP-Scripte, die auf MySQL-Datenbanken festgedongelt sind. Hätte ich
PostgreSQL, würde ich IDENT-Authentifikation machen, statt die Kunden
bescheuerte Datenbank-Passwörter in ihre Scripte eintragen zu
lassen. Cronjobs kann jeder bei uns einrichten, aber erfahrungsgemäß
nutzt es keiner. Es sei denn, er hat ne Monster-Applikation, aber solche
Kunden haben AFAIK auch nen eigenen Server, für diese arbeitet die NJH
nicht als Hoster, sondern als Administrator. :-)  Und dann noch das Rechte-
Problem. Wenn PHP nicht als CGI, sondern als Apache-Modul läuft, rennen
die Scripte als User "www-data" (selbst mit SuExec), während der User als
"$user" auftritt, und bei Cronjob gestartete Scripte auch als "$user"
arbeiten. Auch hier gibt es viele Lösungen, jenachdem in welche Richtung
du tendierst auf dem schmalen Grat zwischen Komfort, Performance und
Sicherheit. Außerdem können bei uns Kunden Subdomains ihrer Domains
anlegen, ohne ein Webinterface dafür zu benötigen: Einfach durch Anlegen
entsprechender Unterverzeichnisse. Aber auch das ist nicht ohne, und es
ist noch kein "Kochrezept": Die Details variieren von Kunde zu Kunde.

> Über ein paar Tipps würde ich mich sehr freuen.

Gut ein paar Tipps hab ich dir gegeben. Aber wenn du *wirkliche*
Antworten suchst, musst du schon einiges mehr an Vorarbeit bringen.
Diese Denkleistung kann dir niemand abnehmen, aber die eigenen Kunden
können einem dabei sehr helfen, wenn man ihnen zuhört.


Ich gehöre übrigens schon drei kleineren Gruppen an (die auch irgendwie
zusammenhängen :-)), die sich dieses Problem auf die Fahne geschrieben
haben: Eine universelle Hosting-Architektur. Herausgekommen ist aber
bisher nur wenig. Das Problem ist einfach, dass wir 1) das Problem für
unsere Zwecke jeweils bereits gelöst haben, also keine echte Notwendigkeit
besteht, und dass wir 2) ohnehin zu wenig Freizeit haben, in der wir
natürlich andere Dingen tun, als unsere Server-Strukturen zu optimieren.
In der Größenordnung von 10 Kunden ist Handarbeit an den Konfigurations-
dateien immer noch am effizientesten. (Ausnahme: Subdomains und
Mail-Konfiguraton)


Viele Grüße,

    Volker

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