[Samba] Samba4 on Ubuntu 18.04

[James Dingwall]

> Date: Tue, 8 May 2018 06:52:56 -0700
> From: Gregory Sloop <gregs at sloop.net>
> To: samba at lists.samba.org
> Subject: Re: [Samba] Samba4 on Ubuntu 18.04
> 
> A sort of digest reply...
> 
> RPvs> Not sure, what is a samba4/adc ???
> RPvs> Or do you mean a 'Has anybody joined a Samba DC on Ubuntu 18.04' ?
> Yes, doing an active directory controller [ADC] not just a workgroup-share.
> [Though, not "joining" a DC already in existance, but creating a new AD setup.]
> 
> RPvs> If so, then yes and it was hell
> What exactly was hellish about it? 
> Is it your opinion I should use something else, compile from source, or what?
> Did you get it to work satisfactorily eventually?
> 
> [I know you're a long-time list contributor, so I'm very interested in your thoughts.]

Just chipping in with my upgrade experience from Ubuntu 16.04 to 18.04 which wasn't entirely smooth.  I have two domain controllers which are only serving a small number of users/groups, they were previously using the default packages on 16.04 and now default on 
18.04.  The original 16.04 installation was a standard server install + a few extra packages.  What went wrong:

On the first system I upgraded there was a file collision with /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service (I didn't note which packages) which caused the do-release-upgrade program to die, I had to manually complete the install after that 
using apt commands.  On the second system I moved this file out of the way before starting and then cleaned it up at the end of the upgrade.

The dpkg --configure phase for some of the samba packages didn't like operating on an smb.conf configured for a domain controller, I added server role check:inhibit=yes to smb.conf to make this work.  The issue seemed to be systemd wanted to start smbd but that 
unit would check it wasn't a domain controller and then cause a failure.

systemd-resolved royally fubared DNS resolution and the DCs couldn't find each other.  Previously my resolv.conf entries were 127.0.0.1 and then the other DC.  Ensure that the systemd-resolved service is disabled before rebooting at the end of the upgrade.

Use testparm after upgrade and fix any issues with idmap configuration that are reported otherwise you will have problems if running winbind on the DC.  (I run nscd and winbind so both user and DOMAIN\user appear in the user/group databases, ensure auto-propagate 
= no is set in /etc/nscd.conf if you do that)

James