Lieber Ralf!
Danke für Deine Antwort und Unterstützung!
Hallo Michael,
Das die 1.8 die stabilste Version war die wir je hatten wage ich zu
bezweifeln, allerdings hat sicher eine neu releaste Version wie die 16.1
noch mehr Instabilitäten als eine schon lange draußen ist.
Zuerst einmal: Als Wiener muss ich raunzen (http://www.duden.de/rechtschreibung/raunzen). Da kann ich nichts dagegen machen: Das ist genetisch bedingt.
Also bei der Version 1.8.007 funktioniert im Großen und Ganzen alles was wir verwenden, das kann ich über alle Nachfolger (die ich bislang getestet habe) nicht behaupten.
Fehler:
An error happened
Kann Benutzerkonten-Objekt für LDAP nicht instanziieren
Ok, das Problem ist gefunden und behoben:
https://github.com/EGroupware/egroupware/commit/6f63dddcf74a58514dc88c0f1de1a6490b882ff2
Bitte mal die folgende Datei bei Dir unter
/usr/share/egroupware/setup/inc/ speichern:
https://raw.githubusercontent.com/EGroupware/egroupware/16.1/setup/inc/class.setup_cmd_ldap.inc.php
nochmal versuchen und Feedback geben.
Diese Datei habe ich jetzt NICHT heruntergeladen, da ich heute ja bereits die neue Maintenance
Release installiert vorgefunden habe. Da meine Versuche mit “doc/rpm-build/post_install.php” erfolglos waren (s.u.) habe ich es bei folgenden Voraussetzungen noch einmal probiert:
- in der header.inc.php ist die neue Domäne angelegt
- Datenbank ist angelegt
- im LDAP ist der virtualDomain-Eintrag und die Untereinträge “ou=accounts”, “ou=contacts” und “ou=groups” vorhanden
- Installieren Alle Anwendungen
- Gegenwärtige Konfiguration überarbeiten:
- LDAP konfigurieren, speichern
- Migration zwischen versch. Orten zur Speicherung von EGroupware Benutzern: Dialog ist da! Super!
Ich habe da dann nicht weiter gemacht, weil ich noch Deine Reaktion zu “doc/rpm-build/post_install.php” abwarten möchte (bevor ich wieder händisch alle GIDs und UIDs anpasse).
Danke das Du den Fehler gemeldet hast 
Bitte gerne. 
Zu Deiner Vorgehensweise eine weitere LDAP Installation anzulegen. Der
Schritt 2 ist gut gemeint, hilft aber nicht!
Falls in dem LDAP schon die gleichen nummerischen IDs verwenden werden,
wird die Migration fehlschlagen.
Der richtige Weg ist die Installation gleich mit LDAP zu machen, da dann
ein eigenes Minimum für die nummerischen IDs vorgegeben werden kann und
alle Defaults auch entsprechend gesetzt werden.
Dazu musst Du die Installation auf der Komandozeile starten:
cd /usr/share/egroupware
doc/rpm-build/post_install.php --help
Das gibt eine Usage für den Komandozeilen Installer, der kann direkt
nach LDAP installieren.
Das ist was die rpm/deb Pakete ausführen und so wird zB. für UCS direkt
eine LDAP Installation erstellt.
Danke, das ist ein wichtiger Befehl, der mir schon früher einiges an Arbeit (Anpassung der GIDs und UIDs in allen möglichen Tabellen, Verschieben der Daten aus der Datenbank nach LDAP) erspart hätte, wenn ich ihn zum laufen bringen würde:
- Bei gelöschter Datenbank und leerem LDAP-Teilbaum war mein erster Ansatz (auch ohne Anführungszeichen probiert, alle Werte in spitzen Klammern sind Platzhalter):
doc/rpm-build/post_install.php --domain „test.domain“ --config_passwd "“ --db_name „testdomain“ --db_pass “” --db_root_pw “” --admin_user “” --admin_passwd “” --admin_email “” --lang “de” --account-auth “ldap” --account_min_id “13000” --ldap_suffix “” --ldap_host “ldapi:///” --ldap_admin_pw “” --ldap_base “virtualDomain=test.domain,$suffix” --ldap_root_dn “cn=,$suffix” --ldap_root_pw “” --ldap_encryption_type “plain”
Die Auswirkungen dieses Befehls sind:
- “EGroupware successful updated”
- Das [‘header_admin_password’] wird zerschossen (es ist keines der oben angegebenen)
- Es wird KEIN Eintrag für die neue Domäne in der header.inc.php angelegt
- Es wird KEINE Datenbank angelegt
- Es werden KEINE Eintragungen in LDAP angelegt
Apaches error_log zeigt auch nur die Meldungen des Apache Stop und Start:
[Sun Jul 17 16:30:46.907033 2016] [mpm_prefork:notice] [pid 6037] AH00169: caught SIGTERM, shutting down
[Sun Jul 17 16:30:48.453227 2016] [mpm_prefork:notice] [pid 21492] AH00163: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured – resuming normal operations
[Sun Jul 17 16:30:48.453734 2016] [core:notice] [pid 21492] AH00094: Command line: ‘/usr/sbin/apache2’
- Versuch: in der header.inc.php wird die neue Domäne angelegt, Datenbank wird angelegt (ohne Tabellen), im LDAP wird der virtualDomain-Eintrag angelegt, dann:
doc/rpm-build/post_install.php … (wie oben)
Ergebnis:
- “Your database is working, but you don’t have any applications installed (mysqli://…). Use --install to install EGroupware”, sowie “Installation failed --> exiting!”
- Das [‘header_admin_password’] wird zerschossen (es ist keines der oben angegebenen)
- Es werden KEINE Tabellen in der Datenbank angelegt
- Es werden KEINE Eintragungen in LDAP angelegt
- Apaches error_log zeigt KEINE Meldungen
- Versuch wie oben, jedoch mit:
doc/rpm-build/post_install.php … (wie oben) --install
Ergebnis:
- Unknown argument ‘–install’
- Versuch: in der header.inc.php wird die neue Domäne angelegt, Datenbank wird angelegt, Installieren Alle Anwendungen, im LDAP wird der virtualDomain-Eintrag und die Untereinträge “ou=accounts”, “ou=contacts” und “ou=groups” angelegt, dann:
doc/rpm-build/post_install.php … (wie oben)
Ergebnis:
- “EGroupware successful updated”
- Das [‘header_admin_password’] wird zerschossen (es ist keines der oben angegebenen)
- Es werden KEINE Eintragungen in LDAP angelegt
Apaches error_log zeigt auch nur die Meldungen des Apache Stop und Start:
[Sun Jul 17 17:25:21.870239 2016] [mpm_prefork:notice] [pid 23309] AH00169: caught SIGTERM, shutting down
[Sun Jul 17 17:25:23.341477 2016] [mpm_prefork:notice] [pid 25813] AH00163: Apache/2.4.10 (Debian) OpenSSL/1.0.1t configured – resuming normal operations
[Sun Jul 17 17:25:23.341939 2016] [core:notice] [pid 25813] AH00094: Command line: ‘/usr/sbin/apache2’
Also nach Stunden des Testens bin ich jetzt am Ende meiner Weisheit. Natürlich könnte ich jetzt noch die verwendeten Optionen durchpermutieren, oder andere Kombinationen der Voraussetzungen probieren, aber die Chancen auf eine so erreichte Lösung erscheinen mir gering.
Ansonsten wird es heute gegen Abend auch noch ein neues Maintenance
Release geben.
Da ich erst heute wieder zum Testen gekommen bin, habe ich diese bereits aktiv und daher die Datei aus dem GIT nicht installiert (s.o.).
Apropos Update: Der Output sieht bei mir so aus (man beachte 2 x “sh: 1: hash: git: not found”):
…
Setting up libgd3:amd64 (2.1.0-5+deb8u4) …
Setting up egroupware-epl-core (16.1.20160715) …
Installing new version of config file /etc/cron.d/egroupware …
Setting up egroupware-epl-vendor (16.1.20160715) …
Setting up egroupware-epl-esync (16.1.20160715) …
Setting up egroupware-epl-bookmarks (16.1.20160715) …
Setting up egroupware-epl-infolog (16.1.20160715) …
Setting up egroupware-epl-notifications (16.1.20160715) …
Setting up egroupware-epl-calendar (16.1.20160715) …
Setting up egroupware-epl-mail (16.1.20160715) …
Setting up egroupware-epl-filemanager (16.1.20160715) …
Setting up egroupware-epl-importexport (16.1.20160715) …
Setting up egroupware-epl-news-admin (16.1.20160715) …
Setting up egroupware-epl-projectmanager (16.1.20160715) …
Setting up egroupware-epl-registration (16.1.20160715) …
Setting up egroupware-epl-resources (16.1.20160715) …
Setting up egroupware-epl-timesheet (16.1.20160715) …
Setting up egroupware-epl-tracker (16.1.20160715) …
Setting up egroupware-epl (16.1.20160715) …
sh: 1: hash: git: not found
sh: 1: hash: git: not found
EGroupware successful updated
EGroupware install log saved to /root/egroupware-epl-install.log
Setting up egroupware-epl-compat (16.1.20160715) …
EGroupware successful updated
EGroupware successful updated
Setting up egroupware-epl-jdots (16.1.20160715) …
Setting up egroupware-epl-phpbrain (16.1.20160715) …
EGroupware successful updated
Setting up egroupware-epl-phpfreechat (16.1.20160715) …
EGroupware successful updated
Setting up egroupware-epl-sambaadmin (16.1.20160715) …
EGroupware successful updated
Setting up egroupware-epl-sitemgr (16.1.20160715) …
EGroupware successful updated
Setting up egroupware-epl-wiki (16.1.20160715) …
EGroupware successful updated
Processing triggers for libc-bin (2.19-18+deb8u4) …
Was mir sonst noch so aufgefallen ist:
In der Header-Verwaltung werden Änderungen in den Domänen (komplett neu angelegte header.inc.php) nicht geschrieben, nur die Allgemeinen Parameter lassen sich ändern. Domänen kann man aber neu anlegen und löschen.
Vielleicht hat das ja etwas damit zu tun. Bei Speichern erhalte ich drei mal (vermutlich weil es drei Domänen gibt):
[Sun Jul 17 17:28:00.638518 2016] [:error] [pid 25925] [client 10.203.1.141:53241] PHP Warning: Invalid argument supplied for foreach() in /usr/share/egroupware/setup/manageheader.php on line 187, referer: https:////setup/manageheader.php
[Sun Jul 17 17:28:00.639303 2016] [:error] [pid 25925] [client 10.203.1.141:53241] #1 /usr/share/egroupware/setup/manageheader.php(89): check_header_form(), referer: https:////setup/manageheader.php
[Sun Jul 17 17:28:00.639653 2016] [:error] [pid 25925] [client 10.203.1.141:53241] #2 {main}, referer: https:////setup/manageheader.php
[Sun Jul 17 17:28:00.640152 2016] [:error] [pid 25925] [client 10.203.1.141:53241] # Instance=, User=, Request=POST https:////setup/manageheader.php, User-agent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/601.6.17 (KHTML, like Gecko) Version/9.1.1 Safari/601.6.17, referer: https:////setup/manageheader.php
Abschließend heische ich noch um etwas Verständnis für meine Raunzerei: Du siehst, was es alleine für Probleme bei den Basics gibt, da rede ich noch gar nicht von den Problemen im Betrieb. Das ist der Grund warum ich die Zeiten der 1.8.007 so schmerzlich vermisse.
Davon unberührt ist meine wirkliche Hochachtung und Wertschätzung Eurer Bemühungen das Produkt stetig zu verbessern und hier auch eine tolle Unterstützung zu geben. Danke!!!
Liebe Grüße
Michael
–
S/MIME bevorzugt / preferred –– PGP vorhanden / available
S/MIME MD5: 23 15 29 81 75 3C E6 72 15 3E C4 48 E9 4B 00 18
PGP Schlüssel-ID / PGP Key ID: D62623BE61E569E8
