Was heisst “solche setups” ? Dieser Server ist nun wirklich nichts Exotisches… EGW 17.1 läuft neben den anderen Sachen wie eine 1 - seit Jahren - nur halt ohne Docker ^^
Was soll es mir bringen einen zusätzlichen Server zu mieten ?
Zum IP Problem: Das ist offenbar in der root@webqa1:/etc/egroupware-docker/apache.conf begründet. Das scheint nämlich eine “ganz normale” und dockerunabhängige Konfigurationsdatei zu sein, die den Wirt beeinflusst und nicht den Gast. Schließlich ist Docker doch eine Art virtuelle Maschine (also Gast), die gleichzeitig als Reverse Proxy die Ergebnisse an den Wirt weiter gibt, der diese dann zum anfragenden Client zurück schubst.
Soweit so gut. Nun ist diese apache.conf aber global ausgerichtet - steht ja auch da:
cat apache.conf
#################################################
(#) Reverse proxy for EGroupware Docker container #
#################################################
(#)Please note:
(#)
(#)This proxy configuration is currently included at global level in
(#)/etc/apache2/conf.d/egroupware-docker.conf and used for all vhosts.
(#)
(#) You can comment it out there and include it only in a certain vhost:
(#)
(#) <VirtualHost *:80>
(#) include /etc/egroupware-docker/apache.conf
(#)
[…]
Die dort besagte etc/apache2/conf.d/egroupware-docker.conf gibt es aber offenbar nicht:
cat: /etc/apache2/conf.d/egroupware-docker.conf:
No such file or directory
Es ist also völlig logisch, daß er nicht weiss, welche Domain. Daher reagiert er nur auf die IP. Wahrscheinlich würde er auch auf localhost reagieren. Um aber EGW über eine bereits aufgesetzte und mit SSL gehärtete Domain abzurufen, müssen diese Direktiven auch dort hin - also in die jeweilige Hostdatei schreiben.
Oder, in meinem Fall, in das ISPC Konfigurationsmodul einer gehosteten Domain:
RewriteEngine on
RewriteCond %{HTTP:Upgrade} websocket [NC]
RewriteCond %{HTTP:Connection} upgrade [NC]
RewriteRule /egroupware/push ws://127.0.0.1:8090/egroupware/push [P]
ProxyPass /egroupware/ http://127.0.0.1:8090/egroupware/ timeout=4000 connectiontimeout=600 acquire=3000 retry=6
ProxyPassReverse /egroupware/ http://127.0.0.1:8090/egroupware/
ProxyPass /Microsoft-Server-ActiveSync http://127.0.0.1:8090/Microsoft-Server-ActiveSync timeout=4000 connectiontimeout=600 acquire=3000 retry=6
ProxyPassReverse /Microsoft-Server-ActiveSync http://127.0.0.1:8090/Microsoft-Server-ActiveSync
RedirectMatch ^/.well-known/(caldav|carddav)$ /egroupware/groupdav.php/
RedirectMatch ^(/principals/users/.*)$ /egroupware/groupdav.php$1
RedirectMatch ^/$ /egroupware/index.php
RedirectMatch ^/egroupware$ /egroupware/index.php
Und siehe da - EGW ist über die Domain mit SSL erreichbar. Damit sich die EGW Dirtektiven nicht mit der CALdav/Carddav Synchronization von Nextcloud beissen, müssen die Direktiven in der besagten Datei /etc/apache2/conf.d/egroupware-docker.conf auskommentiuert werden - schließlich läuft das Groupdav von Nextcloud ja existenzberechtigt auf der gleichen Maschine. Daher diese Dinge immer schön pro Domain und nicht global.
Zack - auch behoben 
Bleibt noch das phpMyAdmin- Problem. Das wird sicher etwas kniffliger. Irgendwie muss das phpmyadmin des Gastes einen anderen Port des Wirtes reagieren - also nicht standard https://domain.local:443/phpmyadmin sondern vielleicht sowas wie https://domain.local:443/phpmyadmin_docker oder https://domain.local:8892/phpmyadmin…
Sicherlich wird auch das zu bewerkstelligen sein …
