[Samba] AD DC in a container: NTP
Viktor Trojanovic
viktor at troja.ch
Tue Jan 8 18:30:13 UTC 2019
Hi Louis,
In general, this sounds like the solution I was looking for. But I’m still a bit unclear about the practical implementation.
So, the DC can be setup without ntpd as it will work based on the system clock which, in turn, is actually being updated by the container host using NTP. Which means we’ve got the DC itself covered. But if ntpd is not installed, then how can the DC serve time to other hosts? How can “Windows PC’s get time over the AD” if the AD DC isn’t offering a time service?
I’m also not sure about what you mean when you say that member servers should be pointed to the same source as the “other hosts”. Which other hosts?
Viktor
From: L.P.H. van Belle via samba
Sent: Dienstag, 8. Januar 2019 14:58
To: samba at lists.samba.org
Subject: Re: [Samba] AD DC in a container: NTP
Hai Viktor,
I've seen some answers already and all are correct.
What i would do different here, when running in a container..
apt-get remove --purge ntpd ;-)
The hosts that are running AD DC containers these need all up to use the same time source.
And you dont install ntpd, you still have the same time in you AD.
NTPD is not obligated to setup AD DC's. Its obligated to have good time sources.
The windows PC's get the time over the AD.
AD DC gets time from the host.
The host get the time from a time source.
Member servers should be pointed to the same time source as the other hosts.
See: https://docs.microsoft.com/nl-nl/windows-server/networking/windows-time-service/how-the-windows-time-service-works#domain-hierarchy-based-synchronization
And think in that picture that the external NTP server is your host running NTPD.
Greetz,
Louis
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens
> Viktor Trojanovic via samba
> Verzonden: dinsdag 8 januari 2019 14:33
> Aan: samba
> Onderwerp: [Samba] AD DC in a container: NTP
>
> I’m currently trying to install a new (primary) AD DC in a
> Linux container. It seems to me that being in a container,
> the DC is easier to maintain and backup than on bare metal,
> and I prefer a container over a VM for performance reasons.
> If the container setup will prove to be too much of hassle,
> I’ll switch to a VM, though.
>
> The first issue I’m facing is time synchronization. An
> container cannot set its time independent of the main kernel,
> and for obvious reasons it cannot manipulate the kernel time.
>
> If I understand correctly, and do correct me if I’m wrong, it
> is not possible to run a Samba DC without running a time
> server. So it’s not possible to entirely disable ntpd in the
> container.
>
> Which would mean that on the DC, I need ntp to not act as a
> client but still to act as a time server for domain members.
>
> To achieve this, I changed /etc/ntp.conf to look as follows:
>
>
> # Local clock. Note that is not the "localhost" address!
> server 127.127.1.0
> #fudge 127.127.1.0 stratum 10
> fudge 127.127.1.0 stratum 0
>
> # Where to retrieve the time from
> # server 0.pool.ntp.org iburst prefer
> # server 1.pool.ntp.org iburst prefer
> # server 2.pool.ntp.org iburst prefer
>
> driftfile /var/lib/ntp/ntp.drift
> logfile /var/log/ntp
> ntpsigndsocket /usr/local/samba/var/lib/ntp_signd/
>
> # Access control
> # Default restriction: Allow clients only to query the time
> restrict default kod nomodify notrap nopeer mssntp
>
> # No restrictions for "localhost"
> restrict 127.0.0.1
>
> # Enable the time sources to only provide time to this host
> # restrict 0.pool.ntp.org mask 255.255.255.255 nomodify
> notrap nopeer noquery
> # restrict 1.pool.ntp.org mask 255.255.255.255 nomodify
> notrap nopeer noquery
> # restrict 2.pool.ntp.org mask 255.255.255.255 nomodify
> notrap nopeer noquery
> tinker panic 0
>
> However, ntpd is still trying to change/adjust the system
> time, leading to a couple of errors in the syslog:
>
> start_kern_loop: ntp_loopfilter.c line 1119: ntp_adjtime:
> Operation not permitted
> set_freq: ntp_loopfilter.c line 1082: ntp_adjtime: Operation
> not permitted
>
> I’d assume I could just ignore those but before continuing,
> I’d appreciate some comments from the team. Do you see any
> major issues in my approach, and what would you do differently?
>
> Thanks,
> Viktor
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
More information about the samba
mailing list