Univention Bugzilla – Bug 34440
join unsuccesful during installation with latest 3.2-1 amd64 ISO
Last modified: 2014-05-20 07:53:31 CEST
Created attachment 5846 [details] installer logs, profile Steps to reproduce: Install a new Master using UCS_3.2-1-amd64.iso (MD5: e971784265e357646df56e84f2eb8e99) Select "Samba 4" to be installed (for further installation options see attached logs). Once the installation is complete a warning occurs: "This system has not been joined yet!.." It turns out that 97univention-s4-connector.inst has failed. After a reboot univention-run-join-scripts executes this script without errors, but is is still not possible to login as Administrator, as the same behaviour as #34197 occurs.
From the logfile: Waiting for file /usr/share/pyshared/univention/admin/handlers/container/msgpo.py: OK Terminating running univention-cli-server processes. E: Can`t connect daemon after 30 seconds.
Probably caused by Bug #34421, as msgpo.py is a udm_module extension stored in LDAP: # udm settings/udm_module list --filter filename=container/msgpo.py | grep ^DN DN: cn=container/msgpo,cn=udm_module,cn=univention,dc=phahn,dc=dev
(In reply to Dirk Ahrnke from comment #0) > After a reboot univention-run-join-scripts executes this script without > errors, but is is still not possible to login as Administrator, as the same > behaviour as #34197 occurs. Does "udm users/user list" work after the reboot?
(In reply to Stefan Gohmann from comment #3) > Does "udm users/user list" work after the reboot? Yes. 5 DNs including Administrator are listed.
(In reply to Philipp Hahn from comment #2) > Probably caused by Bug #34421, as msgpo.py is a udm_module extension stored > in LDAP: > # udm settings/udm_module list --filter filename=container/msgpo.py | grep > ^DN > DN: cn=container/msgpo,cn=udm_module,cn=univention,dc=phahn,dc=dev No, otherwise the module would be available after the reboot.
@Dirk, I'm unable to reproduce this issue. If you are able to reproduce it, could you execute the following steps before you reboot: * ALT-F2 # switch to the second console * chroot instmnt * /usr/share/univention-directory-manager-tools/univention-cli-server
I was also not able to reproduce it on first attempt, but when using a comparable environment the setup fails every time. It seems to be essential that I changed the LDAP base dn and used the suggested Windows domain name. hostname: test1.demo.it25.de LDAP base dn: dc=it25,dc=de windows domain: DEMO Running univention-cli-server as suggested in #c6 doesnt not show a difference to me. It is possible to install the environment mentioned above with the 3.2-0 ISO
(In reply to Dirk Ahrnke from comment #7) > I was also not able to reproduce it on first attempt, but when using a > comparable environment the setup fails every time. > > It seems to be essential that I changed the LDAP base dn and used the > suggested Windows domain name. > hostname: test1.demo.it25.de > LDAP base dn: dc=it25,dc=de > windows domain: DEMO > > Running univention-cli-server as suggested in #c6 doesnt not show a > difference to me. > > It is possible to install the environment mentioned above with the 3.2-0 ISO I'm still unable to reproduce it, even if I use the same settings. It seems to be a timing issue. Is the hardware or the virtual machine extra slow or fast?
The first time I have seen the problem was on real hardware, all other tests have been done in a virtualized environment.
* I adjusted slapd.conf in UCS 3.2-2 to configure "gentlehup on". With that I now see in syslog at debug level -1: Apr 15 22:08:20 ucsmaster slapd[16261]: slapd gentle shutdown * As a second step the slapd init script was adjusted to make start-stop-daemon calls more reliable and to ensure that graceful-stop, stop and force-stop really don't leave a running slapd behind. The check for a running slapd was improved as well. * Additionally db_stat output is logged to syslog in of the case the message "Could not determine BDB version", this might help to understand the db_stat in the future.
Two glitches in my last commit have been fixed: * Don't use killall to avoid killing the init script itself * Don't pgrep by name to avoid detecting the init script itself * Additionally I tracked down the cause of the long standing error message: db4.8_stat: DB_ENV->open: /var/lib/univention-ldap/ldap: No such file or directory This happens when db4.8_recover was run before, as db4.8_recover removes the "environment" files by default. The option "-e" avoids this. According to the man-page it is explicitely targeted at cases where a DB_CONFIG file is used, as in our case.
Move to LDAP
Changelog has been added: r50270 (In reply to Arvid Requate from comment #10) > * I adjusted slapd.conf in UCS 3.2-2 to configure "gentlehup on". With that > I now see in syslog at debug level -1: To make the bug complete. You have reverted that because we had a lot of trouble in this case.
I think the main reasons for the unsuccessful join are Bug #34800 and Bug #34784. But in any case, a revised slapd init script helps in debugging situations. Verified.
UCS 3.2-2 has been released: http://docs.univention.de/release-notes-3.2-2-en.html http://docs.univention.de/release-notes-3.2-2-de.html If this error occurs again, please use "Clone This Bug".