• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Apache2 Subdomains / besondere Konstellation

biertragl

Member
Servus zusammen.
Ich hab nen dedizierten Server im RZ stehen, darauf läuft ESXi mit einigen VM's. Auf einer VM läuft Debian mit Plesk - als Master DNS, heißt ich kann meine Domains da selbst verwalten (Artfiles ist auf Slave eingestellt). Nun habe ich eine weitere VM installiert (Debian 10) und habe da ohne Admin-Tool (wie Plesk etc.) OwnCloud und MariaDB mit PhpMyAdmin drauf laufen. Auf dem Hauptserver habe ich "cloud.domain.tld" und "sql.domain.tld" jeweils auf die IP der neuen VM verwiesen, der Aufruf von "cloud.domain.tld" funktioniert auch ohne Probleme. Um auf phpmyadmin zu kommen muss ich aber "cloud.domain.tld/phpmyadmin oder sql.domain.tld/phpmyadmin" aufrufen, ich hätte gerne dass cloud. auf owncloud verweist (tut es aktuell) und sql.domain.tld direkt auf phpmyadmin. Kann mir jemand sagen, wie ich dem Apachen das beibringe? Wegen mir auch auf ein VErzeichnis innerhalb /var/www mit html-Weiterleitung auf sql.domain.tld/phpmyadmin - ich würde die sql.domain.tld auch gerne via letsencrypt absichern. Hat für die cloud geklappt, für sql jedoch nicht :-(

Ich habe bereits in /sites-available/sql.domain.tld.conf mit folgendem Inhalt angelegt und via a2ensite aktiviert und den Apachen neu gestartet:

Code:
<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName sql.domain.tld
    ServerAlias www.sql.domain.tld
    DocumentRoot /usr/share/phpmyadmin
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Leider komme ich beim Aufruf von sql.domain.tld auf die owncloud-site.. :-(
 
einen direkten Virtualhost gibt's dafür leider nicht...
ich pinne hier mal die 3 "Seiten" an.

1572454487951.png


000-default.conf
Apache config:
<VirtualHost *:80>
    # The ServerName directive sets the request scheme, hostname and port that
    # the server uses to identify itself. This is used when creating
    # redirection URLs. In the context of virtual hosts, the ServerName
    # specifies what hostname must appear in the request's Host: header to
    # match this virtual host. For the default virtual host (this file) this
    # value is not decisive as it is used as a last resort host regardless.
    # However, you must set it for any further virtual host explicitly.

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html
    
    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet

000-default-le-ssl.conf

Apache config:
<IfModule mod_ssl.c>
<VirtualHost *:443>
    # The ServerName directive sets the request scheme, hostname and port that
    # the server uses to identify itself. This is used when creating
    # redirection URLs. In the context of virtual hosts, the ServerName
    # specifies what hostname must appear in the request's Host: header to
    # match this virtual host. For the default virtual host (this file) this
    # value is not decisive as it is used as a last resort host regardless.
    # However, you must set it for any further virtual host explicitly.
    #ServerName www.example.com

    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/html

    # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
    # error, crit, alert, emerg.
    # It is also possible to configure the loglevel for particular
    # modules, e.g.
    #LogLevel info ssl:warn

    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    # For most configuration files from conf-available/, which are
    # enabled or disabled at a global level, it is possible to
    # include a line for only one particular virtual host. For example the
    # following line enables the CGI configuration for this host only
    # after it has been globally disabled with "a2disconf".
    #Include conf-available/serve-cgi-bin.conf


ServerName cloud.gs-server.de
SSLCertificateFile /etc/letsencrypt/live/cloud.gs-server.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/cloud.gs-server.de/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>
</IfModule>

owncloud.conf
Apache config:
Alias / "/var/www/owncloud/"

<Directory /var/www/owncloud/>
  Options +FollowSymlinks
  AllowOverride All

 <IfModule mod_dav.c>
  Dav off
 </IfModule>

 SetEnv HOME /var/www/owncloud
 SetEnv HTTP_HOME /var/www/owncloud

</Directory>
 
Der Sinn deiner owncloud.conf erschließt sich mir überhaupt nicht. In der aktuellen Form muss sie weg.
Erstelle einen Virtual Host für deine cloud.domain.tld, die alles für Owncloud enthält (passender Webroot, TLS-Konfiguration, ggfl. für Owncloud notwendige Sonderkonfigurationen usw.)
Den Default-Eintrag so knapp wie möglich halten, der soll nur die Einträge abfangen, für die es keinen dedizierten vHost gibt (besteht bei mir nur aus zwei Zeilen:
Code:
<VirtualHost *:80>
        ServerAdmin webmaster@domain.tld
        RedirectPermanent / https://www.domain.tld/
</VirtualHost>
Der soll ja nur die ungewollten Sachen abfangen wie z.B. Aufruf über die IP-Adresse oder Subdomains, die man nicht für Webseiten nutzt, wie z.B. ftp.domain.tld o.ä.
 
Da die owncloud.conf nicht in einem <VirtualHost...> eingebettet ist, sind die darin enthaltenen Optionen für alle VHosts gültig, insbesondere der Alias. Hinzu kommt, dass die *.conf alphabetisch aufsteigend eingebunden werden und die owncloud.conf somiit als letzte *.conf und da Apache alle Optionen sequentiell (sprich von oben nach unten) mit last match wins abarbeitet, werden alle vorherigen Optionen für / immer durch den Alias/Directory in der owncloud.conf überschrieben.

Aber das steht auch Alles in der offiziellen Dokumentation zum Apache, man muss sie nur mal lesen, bevor man glaubt root spielen zu können...
 
Da die owncloud.conf nicht in einem <VirtualHost...> eingebettet ist, sind die darin enthaltenen Optionen für alle VHosts gültig, insbesondere der Alias. Hinzu kommt, dass die *.conf alphabetisch aufsteigend eingebunden werden und die owncloud.conf somiit als letzte *.conf und da Apache alle Optionen sequentiell (sprich von oben nach unten) mit last match wins abarbeitet, werden alle vorherigen Optionen für / immer durch den Alias/Directory in der owncloud.conf überschrieben.

Aber das steht auch Alles in der offiziellen Dokumentation zum Apache, man muss sie nur mal lesen, bevor man glaubt root spielen zu können...

Danke für die Rückmeldung. Ich benutze Rootserver schon seit einigen Jahren, hatte bisher nur nie selbst mit dem Apachen großartig zu tun, weil das immer Tools für mich erledigt haben. Irgendwann ist immer der Anfang und ich habe hier nicht behauptet damit spielen zu können! Es war für mich der einfachere und schnellere Weg hier bei erfahrenen Usern eine Antwort zu erhalten, bevor ich alles andere durchackere. Dennoch danke, ich probier mich mal an der "umconfigurierung", damit alles sauber läuft so wie ich das möchte.
 
Apache sortiert alphabetisch - daher macht es Sinn, die Datei mit dem default-Vhost z.B. mit 00 anzufangen (also 00-default.conf) - macht meines Wissens z.B. Debian so bei der mitgelieferten Konfig.
 
Hab jetzt alles in die 000-default gepackt, mit LetsEncrypt verschlüsselt und alles läuft wie es soll.
Danke für die Tipps!
 
Hab jetzt alles in die 000-default gepackt, mit LetsEncrypt verschlüsselt und alles läuft wie es soll.
Dann hast du das Prinzip dahinter aber immer noch nicht ganz verstanden...
Der default-VHost heißt nicht umsonst so...da drin haben die user-/domainspezifischen Konfigurationen nichts verloren. Dafür legt man eigene Konfigurationen an.
 
Naja, prinzipiell ist es erst mal egal, in welche Datei man was von der Apache-Konfiguration reinschreibt. Man kann auch alles in die apache2.conf reinschreiben und sich die ganzen anderen Dateien sparen. Funktioniert erst mal genauso gut. Will man aber was ändern, würde man sich bei dem Ansatz mit nur einer Datei mit u.U. mehreren hundert Zeilen zu Tode suchen.
Daher macht es Sinn, das ganze auszuteilen. Ich verwende für jede (Sub-)Domain, die eine Webseite hat, eine eigene Datein in sites-available, die dann i.d.R. zwei vHost-Einträge hat (einmal unverschlüsselt auf Port 80 - meist nur ein Dreizeiler, der auf die verschlüsselte weiterleitet - und einer verschlüsselt auf Port 443). In der 000-default.conf steht nur der o.g. Vierzeiler drin, der alle anderen Zugriffe (z.B. direkt über die IP-Adresse oder eine Subdomain, die nicht für Webseiten verwendet wird) auf eine bestimmte Webseite weiterleitet - dass kann ja sogar eine auf einem anderen Server sein.
 
auf den Server kommen nur die 2 Subdomains, sonst nichts. ruft man die haupt-domain oder eine andere subdomain der hauptdomain auf, dann landet man auch auf dem Hauptserver. Ruft man die IP-Adresse selbst im Browser auf, wird man auch auf den Hautpserver umgeleitet. Von daher ist für mich alles Tutti und es läuft wie es soll. Das mit den Aufteilungen habe ich schon verstanden, ist aber meines Erachtens nach nicht nötig bei nur 2 Subdomains.
 
Wenn dann noch mal ein Server kommt, der mehr als nur zwei Subdomains hat, wirst du den Sinn verstehen, dass auch schon bei nur zweien zu machen. Der Grund ist, dass dann alle Server einheitlich konfiguriert sind. Ich habe mir einige Scripte geschrieben, um Sachen zu automatisieren, die ich so teilweise direkt ohne Änderung auf anderen Servern verwenden kann. So viele Besonderheiten wie nötig, so wenige wie möglich.
 
zudem kommt so eine 000-default.conf oft auch mit dem Paketmangement und wird ggf. auch mal über ein Update angepasst. Dann darf man die Änderungen manuell nachpflegen, weil meist die Paketverwaltung feststellt, daß da dran rumgespielt wurde und damit die Datei nicht aktualisiert.
 
zudem kommt so eine 000-default.conf oft auch mit dem Paketmangement und wird ggf. auch mal über ein Update angepasst. Dann darf man die Änderungen manuell nachpflegen, weil meist die Paketverwaltung feststellt, daß da dran rumgespielt wurde und damit die Datei nicht aktualisiert.
was aber nicht schlimm wäre - was sollen da großartig für änderungen kommen? die anderen configs sind ja unberührt.. wie gesagt, mir reicht das so - der hauptserver läuft mit plesk und hier kommen nur die beiden subdomains drauf, weitere server wird es nicht geben
 
In diesem Fall sehe ich eher das umgekehrte Problem: Durch einen Fehler im Paket ober bei der Aktualisierung deinerseits wird die Datei durch die Maintainer-Version ersetzt und deine ganze Einstellungen sind erstmal weg. Natürlich sollte es kein Problem sein, da es ja (hoffentlich) ein Backup gibt - aber separate Dateien statt der 000-default.conf zu verwenden, ist eine einfache Methode, sowas zu vermeiden.
Im übrigen bieten auch andere Programme die Möglichkeit, Konfigurationsmöglichkeiten über mehrere Dateien zu verteilen. Sofern möglich sollte man dies auch nutzen, denn es schützt auch die eigenen Einstellungen.
 
Back
Top