Re: Konzepte fuer Admins unter Etch
Hi Christian,
Christian Voelker wrote:
> 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.
[...]
> 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.
wie meinst Du das mit 'in Einzelteile zerlegt'?
In Etch ist das apache 2.2 Paket enthalten und dieses Paket kann
von Hause aus direkt SSL sprechen.
> 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,
Du meinst wahrscheinlich den Skript apache2-ssl-certificate.
Denn gibt es unter Etch anscheinend nicht mehr, Du kannst aber den
von Sarge verwenden (ich selbst verwende meist CA.sh).
> verwenden unterschied-
> liche Pfade, kopieren die erforderlichen Verzeichnisse mal von
> Hand nach sites-enabled, mal symlinken sie und mal wird a2ensite
> benutzt.
a2ensite gibt es immer noch und ist imho 'The Debian way'.
> 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.
hmm, bei mir tut er es.
> 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
Reinhold
Reply to: