samba - Jul 2018 - ntp_signd/socket multiple samba dcs on a single box

Hello,
I have multiple samba DC for different domains running on a single box.
I read a little bit up on time synchronisation and now configured it. It
seems to work. My question is, what happens when multiple DCs go to the
same ntp_signd/socket, will it work? Or should I configure one socket
per DC instance?

Cheers,
        Thomas

On Sat, 21 Jul 2018 22:19:36 +0200
Thomas Glanzmann via samba <samba at lists.samba.org> wrote:
> Hello,
> I have multiple samba DC for different domains running on a single
> box. I read a little bit up on time synchronisation and now
> configured it. It seems to work. My question is, what happens when
> multiple DCs go to the same ntp_signd/socket, will it work? Or should
> I configure one socket per DC instance?
> 
> Cheers,
>         Thomas
> 
Just like you set a time server on each DC, you also a ntp_signed
socket on each DC, running 'samba -b' will show you wher Samba expects
it to be ;-)

Rowland

On Sat, 2018-07-21 at 22:19 +0200, Thomas Glanzmann via samba
wrote:
> Hello,
> I have multiple samba DC for different domains running on a single box.
> I read a little bit up on time synchronisation and now configured it. It
> seems to work. My question is, what happens when multiple DCs go to the
> same ntp_signd/socket, will it work? Or should I configure one socket
> per DC instance?
I would use distinct containers or VMs for this, as otherwise you also
can't use nss_winbindd for each domain.  However if you must, then you
would have to set up multiple ntpd instances bound to each IP and
pointing to the correct Samba.

Finally, in general I suggest avoiding 'neat hacks' because while it is
amazing to create a special snowfake, it is also delicate and more
likely to get broken by some upstream change that never expected your
environment. 

You are saved a little by the fact that Samba's selftest system does
essentially this (but uses nss_wrapper to get around the one
nsswitch.conf issue). 

Andrew Bartlett
-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba

Hello Andrew,

* Andrew Bartlett <abartlet at samba.org> [2018-07-24
09:55]:
> I would use distinct containers or VMs for this, as otherwise you also
> can't use nss_winbindd for each domain.
I'm not using nss_winbindd and don't plan to do so.
> However if you must, then you would have to set up multiple ntpd
> instances bound to each IP and pointing to the correct Samba.
I see. I thought so, so this is what I'm going to do.
> Finally, in general I suggest avoiding 'neat hacks' because while
it
> is amazing to create a special snowfake, it is also delicate and more
> likely to get broken by some upstream change that never expected your
> environment. 
I get the idea. But on the other hand I'm quiet amazed how fast I now
can setup an active directory. This week runs the first class with 13
people on SAMBA AD. And so far everything is working and stable. I'm
even integrating with a third party product (vRealize Automation).
The only real issue that I have is that sysprep domain join does not
work as soon as I go dual stack. But with IPv4 only everything is fine.
When I have some spare time to kill, I'll track it down.
> You are saved a little by the fact that Samba's selftest system does
> essentially this (but uses nss_wrapper to get around the one
> nsswitch.conf issue). 
That's good to know. But I'll simply follow the upstream release cycle
closely and start screaming if it breaks. If all goes wrong I still can
setup a windows ad in a VM in 10 minutes. But setting up an AD in 10
seconds is really neat. And I'm very happy with the work you have done
to make this possible. Thank you very much.

Cheers,
        Thomas