Bug 34440 - join unsuccesful during installation with latest 3.2-1 amd64 ISO
join unsuccesful during installation with latest 3.2-1 amd64 ISO
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 3.2
Other Linux
: P5 normal (vote)
: UCS 3.2-2
Assigned To: Arvid Requate
Stefan Gohmann
:
Depends on:
Blocks: 34836 34784
  Show dependency treegraph
 
Reported: 2014-04-01 20:56 CEST by Dirk Ahrnke
Modified: 2014-05-20 07:53 CEST (History)
3 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments
installer logs, profile (63.70 KB, application/x-gzip)
2014-04-01 20:56 CEST, Dirk Ahrnke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Ahrnke 2014-04-01 20:56:52 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.
Comment 1 Stefan Gohmann univentionstaff 2014-04-02 05:52:12 CEST
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.
Comment 2 Philipp Hahn univentionstaff 2014-04-02 08:28:31 CEST
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
Comment 3 Stefan Gohmann univentionstaff 2014-04-02 08:59:25 CEST
(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?
Comment 4 Dirk Ahrnke 2014-04-02 09:56:36 CEST
(In reply to Stefan Gohmann from comment #3)

> Does "udm users/user list" work after the reboot?

Yes. 5 DNs including Administrator are listed.
Comment 5 Stefan Gohmann univentionstaff 2014-04-22 10:23:23 CEST
(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.
Comment 6 Stefan Gohmann univentionstaff 2014-04-22 10:58:22 CEST
@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
Comment 7 Dirk Ahrnke 2014-04-22 13:57:11 CEST
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
Comment 8 Stefan Gohmann univentionstaff 2014-04-22 14:40:15 CEST
(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?
Comment 9 Dirk Ahrnke 2014-04-22 16:42:35 CEST
The first time I have seen the problem was on real hardware, all other tests have been done in a virtualized environment.
Comment 10 Arvid Requate univentionstaff 2014-05-07 19:31:51 CEST
* 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.
Comment 11 Arvid Requate univentionstaff 2014-05-08 10:11:37 CEST
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.
Comment 12 Stefan Gohmann univentionstaff 2014-05-08 21:51:55 CEST
Move to LDAP
Comment 13 Stefan Gohmann univentionstaff 2014-05-15 06:37:24 CEST
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.
Comment 14 Stefan Gohmann univentionstaff 2014-05-15 06:45:10 CEST
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.
Comment 15 Stefan Gohmann univentionstaff 2014-05-20 07:53:31 CEST
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".