ich möchte aus Speicherplatzgründen gerne mehrere eGW-Installationen in einer Installation zusammenführen, die dann mehrere Instanzen hat.
Bisher ist jede Installation über eine eigene Subdomain ansprechbar. Dies möchte ich auch bei der Installation mit mehreren Instanzen erreichen.
Zur Verdeutlichung:
Die eine Installation liegt unter /root/adressen
Die bisherige Subdomain adressen.domain.de weist auf den Ordner.
Die zweite Installation liegt unter root/adressen-2
Die bisherige Subdomain adressen-2.domain.de weist auf den Ordner.
In der eGW-Installation (unter roo/adressen) mit den jetzt zwei Instanzen sind jetzt für beide Instanzen die entsprechenden Subdomains eingetragen. Wenn ich aber adresse-2.domain.de aufrufe, wird jetzt direkt auf adressen.domain.de umgeschaltet.
Gibt es eine Möglichkeit, es so einzustellen, dass die Subdomain direkt auf “ihre Instanz” springt?
Also vollständig unterstützt, dh. alles funktioniert, werden ausschließlich Instanzen mit unterschiedlichen (Sub-)Domains!
Dh. Du rufst das Setup über den unteren Login auf, und legst dort für den Domainnamen eine neue Instanz an. Die reagiert automatisch auf ihre Domain und wird auch von dem Container Update mit upgedated.
Nach dem Speichern des Headers muss diese im oberen Login installiert werden. Danach werden wie üblich bei einer Migration die Backups und Files Verzeichnisse nach /var/lib/egroupware/$domain kopiert und das Backup zurück gespielt.
Ich habe ja zwei unterschiedliche Subdomains (adressen.domain.de sowie adressen-2.domain.de ).
Diese verweisen dann also beide auf den Installationsordner, und je nachdem, von welcher Subdomain ich aufrufe, wird dann die “spezifische” Anmeldeseite aufgerufen?
In eGW sind die beiden Instanzen mit ihren Datenbanken etc. bereits eingerichtet.
Beim Aufruf von der “zweiten Domain” kommt folgende Fehlermeldung. Von der ersten Domain aus funktioniert der Zugang.
Habe ich da einen Denkfehler?
Neue Erkenntnisse:
Es ist möglich, durch Eingabe von login-name@adressen-2 in der Maske auf der Subdomain adressen.domain.de “umzuschalten”, so dass dann auch der Aufruf von adressen-2.domain.de funktioniert und die Eingabemaske erscheint und man sich mit “normaler” Kennung, also ohne “@adresse-2” einloggen kann.
Zukünftig erscheint die vorgenannte Fehlermeldung jedoch dann bei Aufruf von adressen.domain.de
Also: es funktioniert leider noch nicht.
Habe ich das denn richtig verstanden, dass es wie in meinem Anwendungsfall funktionieren müsste? Oder ist mit “unterschiedlichen (Sub)domains” etwas anderes gemeint?
So, mit ein bisschen probieren habe ich jetzt glaube verstanden, was falsch war.
Als Instanznamen müssen in der header.inc.php exakt die (Sub)Domain eingetragen werden (also nicht nur irgendein Stichwort, woran man die Instanz erkennt).
In meinem Fall tatsächlich: adressen.domain.de und adressen-2.domain.de
Dann funktioniert sowohl der Aufruf der Website, direkt mit der “eigenen” Anmeldemaske, als auch die Synchronisierung über caldav/carddav (in Thunderbird).
Hallo Ralf, Hallo Leute
das bedeutet aber dann wohl dass es grundsätzlich funktionieren sollte auch in der CommunitiyVersion?
Habe nämlich auf einem Testsystem versucht ein zweite Instanz, mit SubDomain zu installieren.
Dabei sind einige für mich nicht nachvollziehbare Verhaltensweisen aufgetreten - mal abgesehen davon das es nicht funktioniert hat und die ganze Installtion danach nicht mehr erreichbar war.
Also falls es eigentlich funktionieren sollte werde ich gerne meine Schritte und die Ergebnisse dokumentieren.
Danke erstmal, LG Hagen
Bei uns ist es die Community-Version, und es funktioniert wunderbar.
Und das nicht nur bei “echten Subdomains”, sondern auch, wenn völlig andere Domains eingetragen und auf den egw-Ordner gelinkt sind.
Wir haben also in einer Installation mehrere Datenbanken: sub1.domain1.de sub2.domain1.de sub3.domain2.de
Jede Instanz wird da mit der eigenen Domain eingetragen (also
"vollständig", aber ohne https://), und braucht natürlich eine eigene
Datenbank-Anbindung etc.
Beim Provider richtet man die entsprechenden Domains bzw. Subdomains
dann auch ein und lässt sie alle auf den egw-Ordner verweisen (man muss
ja zuweisen, was angezeigt werden soll, wenn die Domain aufgerufen wird).
Dann wird beim Aufruf der jeweiligen URL die zugehörigen Instanz
aufgerufen, wo man sich dann einloggen kann.
Ok, das hatte ich erledigt. Subdomains auch. Mein Testsystem liegt auf einem Virtuellen Server. Die Haupt/Erstinstanz funktioniert indem ich ihre Subdomain per DNS Eintrag auf die Server IP verweisen lasse.
Selbiges tat ich auch mit der zweiten Instanz sprich Subdomain - was zu keinem funktionierenden Ergebnis führte. Das ganze ist eine Docker installation, jetzt muss ich wohl rausfinden wie ich die zweit Instanz auf die egw-Ordner verweisen lasse…
Danke erstmal, Grüße Hagen
Sprich bei einer Docker Instanz muss nur der verwendete DNS Name auf den Host mit dem Docker verweisen. Der Reverse-Proxy (Nginx oder Apache2 auf dem Host) gibt den Hostnamen an den Nginx der EGroupware weiter und diese wertet den dann aus um automatisch die passende Instanz zu verwenden.
Falls das nicht nur ein einfacher Linux Host ist, sondern Plesk oder irgendein Hosting Paket, musst Du dafür sorgen, dass die keinen weitern vHost, sondern den gleichen wie bei der ersten Instanz verwenden!
Hatte ich auch genau so gemacht, danach konnte ich das Setup oberer Teil aufrufen, Domain auswählen, anmelden, Datenbank Daten eingeben, danach bleibts hängen (ohne Fehlermeldung) und es wird keine neue Datenbank angelegt. Wenn die Datenbank und den Benutzer händisch anlege wie es in der var/lib/egroupware/header.inc.php eintragen ist, funktioniert es trotzdem nicht. Zugriff mit phpmyadmin getestet. Vielleicht ist es besser wenn ich mal meine Schritte und die Ergebnisse dokumentiere, dann ist die Fehlersuche denke ich einfacher.
Danke, Grüße, Hagen
Habe meine Fehler gefunden: Im Setup unterer Login ist mir erst heute aufgefallen das der Datenbank-Host “db” und nicht “localhost” heißen muss. Das war der Grund weswegen der Zugriff auf die Datenbank scheiterte.
Bei anderen vorherigen Versuchen hatte ich sicher nicht die komplette (ohne https…) Sub Domain eingetragen, was wohl dazu führte das keine Instanz mehr erreichbar war.
So, jetzt laufen also 2 Instanzen - Trotzdem ist mir aufgefallen dass die default-Instanz bei ihrer Umbenennung erhalten bleibt und eine zweite mit dem neuen Namen entsteht. Die default-Instanz lässt sich danach löschen und es funktioniert weiterhin - trotzdem entspricht dies Verhalten nicht meiner Erwartung beim Umbenennen der default-Instanz.
Ausserdem ist mir aufgefallen, dass “db_pass” von “db_user=egroupware” in der header.inc.php anders lautet als in der egroupware-docker-install.log. Ist das normal? (unter /var/lib/egroupware)
Danke fürs mitdenken,
LG Hagen
- Trotzdem ist mir aufgefallen dass die default-Instanz bei ihrer Umbenennung erhalten bleibt und eine zweite mit dem neuen Namen entsteht. Die default-Instanz lässt sich danach löschen und es funktioniert weiterhin - trotzdem entspricht dies Verhalten nicht meiner Erwartung beim Umbenennen der default-Instanz. 