Univention Bugzilla – Bug 30119
s4connector in appliance setup when changing from DHCP to a fixed IP addresss
Last modified: 2013-02-13 11:02:59 CET
The s4connector is not synchronizing new LDAP entries when booting in appliance mode and configuring a master system with Samba4 + changing the DHCP IP address to a fixed static address. strace shows that the s4connector hangs while reading from a socket. The problem is reproducible with the current UCS VMware image. This behaviour is possibly due to an open LDAP connection to the old DHCP IP address that gets invalidated after system setups cleanup (which is executed as soon as the user is confirming to continue booting). A restart of the s4connector in the appliance hooks, as well as a "nscd -i hosts" does not change this behaviour.
From the s4 connector strace: fstat(6, {st_mode=S_IFREG|0644, st_size=64512, ...}) = 0 fcntl(6, F_SETLK, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0 time(NULL) = 1358957387 write(7, "\27\3\1\0 =;\211S<\256\217\257\270+\36\303zg\320B2\200d\362\243\325y\312$'N"..., 138) = 138 poll([{fd=7, events=POLLIN|POLLPRI}], 1, -1 root@master541:~# ls -la /proc/9126/fd/7 lrwx------ 1 root root 64 23. Jan 17:11 /proc/9126/fd/7 -> socket:[42667] root@master541:~# netstat -tupen | grep -i 42667 tcp 0 138 169.254.179.113:36102 169.254.179.113:7389 VERBUNDEN 0 42667 9126/python2.6 The s4connector is connected to the slapd over the old ip address.
I've added a network script which will be executed if a network device was shutdown. This script restarts the connector only if the connector is running: /etc/network/if-down.d/univention-s4-connector Fixed in errata 3.1-0, 3.1-1 and ucc-integration. This erratum has to wait for Bug #29625.
*** Bug 30044 has been marked as a duplicate of this bug. ***
For the QA: - install an UCS appliance with S4 - change the IP during system setup - create an user via samba-tool samba-tool user add tester univention - search the user via univention-ldapsearch univention-ldapsearch uid=tester
The problem seems to be, that during system setup two addesses are registered for the host, which are either returned round robin or 1st always first: root@my:~# host my.server.de my.server.de has address 10.200.12.12 my.server.de has address 10.200.17.97 root@my:~# host my.server.de my.server.de has address 10.200.17.97 my.server.de has address 10.200.12.12 # while sleep 1; do pid=$(pgrep -f s4/main) && lsof -np $pid | grep TCP ; getent hosts my.server.de ; host my.server.de ; done I could not reproduce the hang without manual fiddeling, because the connecter always selected the right address in my initial tests. It might also be a problem of odering: When I switched the lines in /etc/hosts, the first address was chosen, which I used to force the wrong address. The patched version fixed the problem by forcing a s4-connector restart. Code: svn11335,11334,11333,38496 ChangeLog: svn16169 2013-01-24-univention-s4-connector.yaml: svn16168 Fixed wording (svn16303)
http://errata.univention.de/3.1-errata35.html