[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Konzepte fuer Admins unter Etch



Hallo,

ich habe mir vor zwei Wochen einen neuen VServer mit Debian Etch
gemietet. Mein letzter Debian Server war noch Sarge und die Ein-
richtung ist schon länger her.

Unter den Linuxen ist Debian mein Favorit; da ich es aber selten
nutze, komme ich doch immer wieder ins Schleudern, insbesondere
auch weil ich zwischen den Systemen häufig hin und her wechsle
je nach Bedarf. Ansonsten habe ich oft mit MacOS X und FreeBSD
samt ports zu tun und bin mit den Konzepten und Bugs dort ver-
traut; bei RedHat bekomme ich immer die Kraetze.

Mein aktuelles Problem dreht sich um die Doku von Debian. Ich
nehme an, dies ist kein neues Thema. Ich habe natuerlich die
Liste der Buecher, die Howtos und die Referenz durchkaemmt,
das Wiki und Sites wie debian-administration.org. (Macht auf
mich alles den Eindruck von Baustellen, unkooridiniert.) Und
sicher, /usr/share/doc/paketname sehe ich auch jeweils durch.
Klar, auf alioth habe ich auch gestoebert.

Wonach ich suche sind weniger HowTos, eher Konzepte. Was haben
sich die Package-Maintainer dabei gedacht, wenn sie ihre Pakete
so strukturiert haben, wie sie sind? Wie kann ich vorhandene
Utilities im Sinne der Maintainer nutzen, sodass ich mit meinen
eigenen Anpassungen der Konfigurationen keine Probleme bei
spaeteren Upgrades provoziere? Also wie ist der Debian Weg,
die Dinge anzupacken?

Mir geht es explizit nicht um die Grundlagen der Installation.
Wie gesagt habe ich einen VServer mit einem fertigen Image
und installiere weitere Pakete mit aptitude. Der Server dient
dem persoenlichen Gebrauch und zum Lernen, Testen, Spielen.
Deshalb tendiere ich jeweils zur Wahl des neuesten und gross-
artigsten im Rahmen von stable und ggf. testing.

Ein paar Beispiele fuer Fragen, die ich mir stelle:  Als Web-
server habe ich das apache2 Paket gewaehlt. Dieses ist ziem-
lich anders strukturiert als das apache-Paket unter sarge,
z.B. ist die Variante mit SSL-Unterstuetzung nicht in einem
separaten, gebrauchsfertigen Paket untergebracht, die Konfi-
guration ist in Einzelteile zerlegt, aehnlich exim. Das ist
schoen aber nicht vollstaendig selbsterklaerend und es bleibt
unklar, ab welchem Punkt ich mich besser an die upstream Doku
halte oder wo ich mit diesem Vorgehen Hilfestellungen kaputt
mache, mit denen mir Debian eigentlich das Leben erleichtern
moechte.

Die HowTos, die ich allenthalben finde, beziehen sich alle auf
selbstsignierte Zertifikate, benutzen z.T Skripte zur Erzeugung
derselben, die es unter etch nicht gibt, verwenden unterschied-
liche Pfade, kopieren die erforderlichen Verzeichnisse mal von
Hand nach sites-enabled, mal symlinken sie und mal wird a2ensite
benutzt. Einige legen Daten unter /home/paketname_kein_nutzername
an, andere unter /var/www/lib, aber nicht unter /var/www/opt, wo
ich es logisch faende. Aber wie sich die Maintainer selber die
Sache vorgestellt haben, das finde ich nirgends. Ich habe mein
Zertifikat per CaCert erstellt und brauche daher im Virtualhost
Eintrag neben SSLCertificateFile noch ein SSLCertificateKeyFile.
Dabei ist mir aufgefallen, dass die Beispiele fuer sites-avai-
lable eine andere Struktur besitzen als ich sie kenne, z.B.
ohne IfDef Statements fuer die SSLEngine, mit NameVirtualHost
vorangestellt usw. Da frage ich mich natuerlich ist das Absicht
oder Nachlaessigkeit und falle ich damit gleich nach der naechs-
ten Ecke auf die Nase. Obgleich ich den hostname mit dem gleich-
namigen Befehl gesetzt habe, meckert der apache bei jedem
reload darueber, dass er diesen Namen nicht verifizieren
koenne (ein DNS-Eintrag liegt vor) und ich sehe den Fehler
nicht.

Dies sind jetzt nur mal einige Punkte aus dem apache-Bereich;
ich koennte jetzt beliebig mit subversion, twiki, usw. fort-
fahren. Auch in Bereichen, in denen ich mich noch nicht so gut
auskenne haette ich gerne eine implizite Empfehlung nach dem
Motto "wenn Du keine Sonderwuensche hast, dann probier es erst
mal mit diesem Paket", so wie dies beim Mailserver ist (auch
wenn mir exim weniger sympatisch ist als postfix nehme ich ihn
erst mal in der Annahme, dass ich dann eine geteste Loesung
habe fuer alle Pakete, die einen mailserver brauchen). Es ist
natuerlich toll, wenn es ein Dutzend verschiedene Authentifi-
zierungsloesungen samt Verwaltungstools gibt, aber der Witz
ist doch, dass sowas mit moeglichst vielen Paketen zusammen
arbeiten soll von denen ich jetzt noch gar nicht weiss, dass
ich sie vielleicht mal installiere.

Also, durch die konkret angesprochenen Punkte werde ich mich
selber durchwursteln. Was ich mir von diesem Beitrag erhoffe
sind eher Hinweise darauf, wie ich im Allgemeinen vorgehen
sollte und wie ich die Gedanken der jeweiligen Paketverwalter
am besten lesen kann.

Gruss, Christian



Reply to: