Bug 35600 - Samba AD DC provision failed due to winbind(3) installed and running.
Samba AD DC provision failed due to winbind(3) installed and running.
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Samba4
UCS 3.2
Other Linux
: P5 normal (vote)
: UCS 3.2-3-errata
Assigned To: Erik Damrose
Arvid Requate
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-08-12 12:25 CEST by Arvid Requate
Modified: 2014-08-14 11:54 CEST (History)
4 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:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate univentionstaff 2014-08-12 12:25:23 CEST
Internally we just had one case where the installation of a UCS-3.2-3 release candidate failed to provision Samba4, probably due to running winbind daemon which could not be stopped via "/etc/init.d/winbind stop".

The strace of the samba-tool domain provision showed it repeatedly timing out reading from a winbind socket. There where four winbind processes running with one of the childs refusing to die on a normal SIGTERM. After cleaning up this mess and killing the shocked provision process it was possible to successfully run the provision manually again. So there is strong evidence that the winbind process was the culprit. Which brings us to the central question:

Why was a winbind process running in a samba4 machine? Ok, it was running because it's started in winbind.postinst and the samba4 joinscript has set winbind/autostart=no but it failed to stop it (The cause in this case may have been a network configuration messup due to a mixture of DHCP and static IP config).

The winbind package should not be installed at all. It's not working with samba-ad-dc (yet), and samba-ad-dc forks his own implementation of this service.
The dependency of univention-samba4 on winbind was accidentally introduced during the update to Samba 4.1 (ucs_3.2-0) and should be removed.
Comment 1 Arvid Requate univentionstaff 2014-08-12 12:27:07 CEST
This is how it sould be:

root@ucsmaster:~# samba-tool processes | grep winbind
winbind_server         15706
Comment 2 Erik Damrose univentionstaff 2014-08-12 17:22:52 CEST
It just happened again. After executing
$ killall winbindd
the provisioning continued and the join finished successfully. Everything seemed to work fine in a quick test (kinit, univention-s4sesarch, smbclient -k \\fqdn\sysvol)
Comment 3 Arvid Requate univentionstaff 2014-08-12 18:05:40 CEST
This now occured 3 times today, always with appliance mode, so we might want to fix this before releasing the new appliance images. Just saying. User experience.
Comment 4 Erik Damrose univentionstaff 2014-08-13 12:33:08 CEST
The winbind initscript does not stop winbind. The fix adjusts the joinscript to really stop all winbind processes. The fix for UCS 4 will adjust the winbind initscript.

r52686 univention-samba4 3.0.39-33.586.201408131223
r52687 staging/2014-08-12-univention-samba4.yaml
Comment 5 Arvid Requate univentionstaff 2014-08-13 15:48:27 CEST
I think it would be better to use start-stop-daemon like it's done in the winbind init script. pkill doesn't ensure that the process is really gone.

start-stop-daemon --stop --quiet --retry 2 --exec /usr/sbin/winbindd
Comment 6 Erik Damrose univentionstaff 2014-08-13 16:04:21 CEST
Use start-stop-daemon instead of pkill
r52700 univention-samba4 3.0.39-34.587.201408131600
r52701 yaml
Comment 7 Arvid Requate univentionstaff 2014-08-13 16:52:57 CEST
Verified and advisory is Ok.
Comment 8 Janek Walkenhorst univentionstaff 2014-08-14 11:54:18 CEST
http://errata.univention.de/ucs/3.2/180.html