On Thu, Jan 25, 2018 at 2:02 PM, Rob Crittenden via FreeIPA-devel <
> Levin Stanislav via FreeIPA-devel wrote:
> > Hello All.
> > There are several good NTP servers/clients. And different Linux
> > distributions
> > use them (not only ntpd or chronyd). But FreeIPA chose ntpd strictly. It
> > is a
> > bottleneck for a platform porting. Perhaps, FreeIPA should allow to
> > administrator which one to use and should support it (like install and
> > work).
> Administrators can do that now with the -N option (don't enable NTP).
If IPA will not drop any NTP service configuration I believe this, Stanislav,
is what you would need, to have another service running.
I think there is no way IPA could support all of possible NTP daemons as
> The problem is two-fold:
> 1. NTP was added because proper time is so critical to Kerberos and
> 389-ds replication and it was clear early on in IPA that virtually
> nobody had it properly working. Some still struggle.
> 2. Providing too many knobs increases support and development costs in
> time and effort. Each server has its own config and idiosyncrasies and
> they can change over time so keeping up has cost.
> We didn't pick ntpd as the winner. It was the only game in town at the
> time, and given it worked and since then we've had much bigger fish to
> fry there has been no real drive to replace it (at least not so much
> that someone provided patches to do so).
> > Thank you.
> > 24.01.2018 18:57, Simo Sorce via FreeIPA-devel пишет:
> >> On Wed, 2018-01-24 at 16:25 +0100, Tibor Dudlák via FreeIPA-devel
> >> wrote:
> >>> Hello FreeIPA-devel list fellow beings!
> >>> I would like to continue the discussion started in , and find its
> >>> solution.
> >>> While using the Single-Sign-on authentication provided via an MIT
> >>> KDC there must not be any significant clock skew between server and
> >>> clients so a time synchronization service is required.
> >>> Red Hat Enterprise Linux is about to deprecate ntpd service and will
> >>> support chronyd instead. This will happen in release 8 and by this
> time we
> >>> should agree on some changes in IPA - whether to remove or replace the
> >>> used ntpd service. I would like to sum up this change in a design page
> >>> there should be an agreement first.
> >>> IPA, as is, checks the system configuration and if there is an NTP
> >>> configured and running then it forces ntpd, meaning it disables any
> >>> NTP service. It also alters its configuration, and restarts the NTP
> >>> instance.
> >>> We may now want to consider, as the time sync service change is
> >>> to NOT configure a service that is not a part of the identity
> >>> such as NTP, and leave it to system/IPA administrators.
> >> Let me explain why we do this:
> >> As you noted above kerberos will fail to work properly if clocks drift
> >> too much, so we wanted to provide a simple way to keep the whole domain
> >> in sync. We also had plans to keep the domain in sync *securely* as an
> >> attacker could create Denial pf Service attacks by subtly drifting
> >> different machines clocks.
> >> ntpd was the only one that offered hooks to sign NTP packets (which
> >> were used by Samba only at the time and required compile time changes
> >> when we started) using kerberos keys, so the original plan was to
> >> eventually get there. Unfortunately we never prioritized this work.
> >> So given the above we initially decided to make IPA servers also ntp
> >> servers and configure client to use IPA server as time sources.
Not configuring NTP service but still requiting it might be way to give
freedom of choice to IPA administrator to set one they prefer before
installing IPA. :)
> >> This is just to give an overview of the reasons behind choosing ntpd
> >> specifically and why it was overriding ntp config on servers/clients
> >>> IPA install script may only check wheter there is an NTP service
> >>> and if not, it would ask the administrator to configure it before the
> >>> installation.
> >> I do not think we need this strictly for the first server, these days
> >> time keeping is more important in general and servers tend to be
> >> already kept in sync, either via virt devices, or ntp.
> >> however what we may want to do is, instead, to check the time
> >> synchronization on clients (and therefore future ipa replicas, as ipa
> >> client install is always done fist now), by dissecting a kerberos reply
> >> from the server that carries the server time (I think this information
> >> is actually stored in the ccache after a successful kinit, so we could
> >> just inspect the ccache as well).
> >> If we detect a drift bigger than X (where X < 5 min), we could fail the
> >> install and ask the admin to check the client and server time are
> >> synchronized.
> >>> Upgrade of IPA might be more complicated because there will be the ntpd
> >>> service entry in LDAP, and the service will be up and running. I would
> >>> suggest that we do not remove any working ntpd service already
> >>> but only disown it from IPA's LDAP tree.
> >> Why would we need to disown it ?
> >> I think it is ok to proposed that in new installs (even in an existing
> >> domain) new servers will stop configuring ntp by default, but I see no
> >> reason to touch existing servers.
> >> however I think we should *retain* the option to install and configure
> >> ntpd, it is very convenient for tests and custom installs/pocs, where
> >> you want to minimize the amount of prepping to do, and want something
> >> that "just works".
> >> If ntpd is dropped from a distribution I would assume we'll use the
> >> platform portability code to replace ntpd with whatever other
> >> NTP/timesync server/client is appropriate for the platform when the
> >> option to install NTP is requested.
So should we only replace ntpd with chronyd and have option to not
configure NTP service (chronyd) as it is now if administrator wants to use
other than chronyd?
> >> HTH,
> >> Simo.
> >>> I will be glad for any input from you people and hopefully there will
> be an
> >>> acceptable solution for this soon :)
> >>> Thanks!
> >>> 
> >>> https://www.redhat.com/archives/freeipa-devel/2016-
> >>> _______________________________________________
> >>> FreeIPA-devel mailing list -- email@example.com
> >>> To unsubscribe send an email to freeipa-devel-leave@lists.
> > _______________________________________________
> > FreeIPA-devel mailing list -- firstname.lastname@example.org
> > To unsubscribe send an email to freeipa-devel-leave@lists.
> FreeIPA-devel mailing list -- email@example.com
> To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
Identity management - freeIPA
Brno, TPB-C, 2C407
FreeIPA-devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org