Nextcloud Reverse Proxy ohne Unterverzeichnis /nextcloud

Hallo zusammen,

aktuell ist die Docker Instanz von Nextcloud über “https://server.domain.com/nextcloud/” erreichbar.
Ziel ist es, dass Nextcloud über “https://cloud.domain.com/” zu erreichen ist und zwar ohne “/nextcloud” Unterverzeichnis am Schluss.

Nun ist es so, dass der Nextcloud Dockercontainer bereits über einen Reverseproxy vom UCS Host aus wie es sich aus der apache2 default-ssl config ergibt:

ProxyPass /nextcloud/ http://127.0.0.1:40000/nextcloud/ retry=0 ProxyPassReverse /nextcloud/ http://127.0.0.1:40000/nextcloud/

Für den Alias “cloud.domain.com” habe ich einen entsprechenden separaten Virtual Host definiert.
Verwende ich die obige ProxyPass Regel klappt der Zugriff jedoch nur über “https://cloud.domain.com/nextcloud”.
Wenn ich nun die entsprechende Anpassung vornehme:

ProxyPass / http://127.0.0.1:40000/nextcloud/ retry=0 ProxyPassReverse / http://127.0.0.1:40000/nextcloud/

Erhalte ich keinen Zugriff mehr mit dem Verweis, dass die “/nextcloud/nextcloud/index.php” auf dem Server nicht existiert.

Wo habe ich hier den Denkfehler ?

Besten Dank.

Hi,

schau ml in die config.php der Netcloud-Installtion. Entweder dort oder in htaccess ist ein BasePath eingetragen, mag ich mich erinnern. Das musste ich zumindestens bei meiner nativen Installation umstellen.

Viele Grüße
Ulf

Hi,

danke für den Hinweis. In der config.php muss zusätzlich noch “‘overwritewebroot’ => '/nextcloud ',” nach “‘overwritewebroot’ => ‘/’,” geändert werden.

Dann funktioniert der Zugriff über “https://cloud.domain.com” ohne /nextcloud/.
Konsequenterweise ist dann der Zugriff über “https://server.domain.com/nextcloud” nicht mehr möglich. Gibt es eine Chance beides zu haben ?

Grüße.

Hi,

nur mit zwei separaten Nextcloud-Installationen/-Containern, die den selben data-Orner verwenden. Ob das bei zwei UCS-Containern auch funktioniert, kann ich nicht sagen, wäre aber interessant zu erfahren.

Viele Grüße
Ulf

Ist ja schon eine Weile her, aber da ich gerade dabei bin… Also bei mir funktioniert nun beides, d.h. Zugriff über https://cloud.domain.com und https://server.domain.com/nextcloud

Dazu habe ich den neuen vhost mit

        ProxyPass / http://127.0.0.1:<docker-port>/ retry=0
        ProxyPassReverse / http://127.0.0.1:<docker-port>/

angelegt. Die config.php habe ich so geändert:

  'overwrite.cli.url' => 'https://cloud.domain.com',
  'overwritewbroot' => '/',
  'htaccess.RewriteBase' => '/',

Grüße,
Bernd

Hallo.

Ich habe bei meinem Server genau das hier beschrieben durchgeführt, um für Nextcloud eine Subdomain zu haben.

Ich habe jedoch das Problem, dass ProxyPass offenbar auch für die normale Domain durchgeführt wird, also auch für domain.de und www.domain.de.
Um das zu ändern oder es überhaupt zu verstehen habe ich bereits einiges probiert, komme aber nicht dahinter wieso dies so ist.

Ich habe folgenden virtualhost erstellt.

Anzumerken ist, dass ich das in Post1 beschriebene Problem habe, trotz änderung in der config.php, weshalb ich /nextcloud/ beim ProxyPass entfernt habe. Kann das die Ursache für mein o.g. Problem sein?

Ich bin dabei gerade etwas ratlos.

<VirtualHost *:80>
ServerName cloud.domain.de
Redirect / https://cloud.domain.de/
</VirtualHost>

<IfModule mod_ssl.c>
<VirtualHost *:443>
        ServerAdmin admin@domain.de
        ServerName cloud.domain.de
        DocumentRoot /var/www
        <Directory /var/www>
	  Options +FollowSymlinks
          AllowOverride All
	 <IfModule mod_dav.c>
	  Dav off
	 </IfModule>

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

        </Directory>
        ProxyPass / http://127.0.0.1:40000/ retry=0
        ProxyPassReverse / http://127.0.0.1:40000/ retry=0
        SSLEngine on
        SSLProxyEngine on
        SSLProxyCheckPeerCN off
        SSLProxyCheckPeerName off
	SSLCertificateFile /etc/univention/letsencrypt/signed.crt
	SSLCertificateKeyFile /etc/univention/letsencrypt/domain.key
	SSLCACertificateFile /etc/univention/ssl/ucsCA/CAcert.pem
	SSLCertificateChainFile /etc/univention/letsencrypt/intermediate.pem
</VirtualHost>
</IfModule>

Huhu,

Apache schaut zuerst nach, ob es einen VirtualHost gibt, dessen ServerName oder ServerAlias exakt auf den angefragten Hostnamen zutrifft. Ist dies der Fall, so wird der erste VirtualHost genommen, für den das der Fall ist.

Gibt es hingegen keinen VirtualHost, bei dem ServerName oder ServerAlias passt, so wird schlicht der allererste VirtualHost in der Konfiguration genommen. Somit kann es gut sein, dass hier ein VirtualHost zum Zuge kommt, der eigentlich für eine ganz andere (Sub-)Domäne gedacht ist.

Dabei ist zu beachten, dass die Dateien in /etc/apache2/sites-enabled und /etc/apache2/conf-enabled in alphabetischer Reihenfolge ausgewertet werden.

Gruß
mosu

Danke für die Antwort.

Daran dachte ich auch schon. Es kommt aber alphabetisch gesehen noch eine andere conf danach (mail.domain.de).

Also müsste ich zur Abhilfe einen virtualhost für domain.de und www.domain.de erstellen? Dies hatte ich schon versucht, bin jedoch dabei gescheitert, weil ich bei den ganzen Konfigurationsdateien vom UCS den Überblick verloren habe.
Könnte mir hier vielleicht jemand einen Denkanstoß geben?

Beide Domains sollen eigentlich einfach wie Standard auf das Portal führen.

Huhu,

es sollte eigentlich genügen, wenn man seine eigenen Konfigurationsdateien für virtuelle Hosts alphabetisch ganz nach hinten schiebt, z.B. indem man ihre Dateinamen mit zzz- oder so präfixt. Natürlich anschließend ein Reload vom Apache.

Gruß
mosu

Mastodon