Und die Scripte wie a2enmod, a2ensite usw. verschleiern mir zu sehr, was da wirklich passiert.
Naja. Das (a2enmod, a2enconf, a2ensite) sind zwar große Perl-Skripte, aber im Kern (wenn man all die für gute Fehlermeldungen gemachten Untersuchungen weglässt) legen die doch nur die erforderlichen symbolischen Links von /etc/apache2/[mods|conf|sites]-available/ nach /etc/apache2/[mods|conf|sites]-enabled/ und zeigen dann an, ob man den Apache nur neu laden oder neu starten muss, damit das wirksam wird.
Die Skripte (a2dismod, a2disconf, a2dissite) entfernen diese Links und zeigen dann an, ob man den Apache nur neu laden oder neu starten muss, damit das wirksam wird.
Praktisch: Diese Skripte arbeiten auch mit eigenen Conf-Dateien in den gezeigten Ordnern - man muss die nur korrekt ablegen.
Das ist viel einfacher und klarer, als sich mit einem Editor durch 2000 Zeilen einer monolitischen Config durchzugraben. Und vor allem ist das schneller gemacht, was sich besonders im Fehlerfall als krasser Riesenvorteil erweist.
Außerdem kann so für jedes der Apache-Module (Versuche mal apt list libapache2*
... ) die *load bzw. *conf-Datei einfach im Installations-Paket des Moduls geliefert und mit 2 Befehlen aktiviert werden. Dto. die conf-Dateien und die für die „sites", a.k.a. „virtual hosts“.
Einfacher, bequemer und zugleich offensichtlicher und durchsichtiger geht es doch kaum...
(Rolf2, von weiter oben)
Im IIS klickt man das mit 5-10 Mausklicks im IIS Verwaltungstool zusammen und ist fertig
Die Anforderungen an die Plausibilität und Erkennbarkeit mancher Vorgänge sind offensichtlich sehr unterschiedlich...