On 29.11.2016 16:02, Rob Crittenden wrote: > Petr Spacek wrote: >> On 29.11.2016 09:11, Jan Cholasta wrote: >>> On 28.11.2016 20:57, Rob Crittenden wrote: >>>> David Kupka wrote: >>>>> On 22/11/16 23:15, Gabe Alford wrote: >>>>>> I would say that it is worth keeping in FreeIPA. I know myself and some >>>>>> customers use its functionality by having the clients sync to the IPA >>>>>> servers and have the servers sync to the NTP source. This way if the NTP >>>>>> source ever gets disrupted for long periods of time (which has >>>>>> happened in >>>>>> my environment) the client time drifts with the authentication source. >>>>>> This >>>>>> is the way that AD often works and is configured. >>>>> >>>>> Hello Gabe, >>>>> I agree that it's common practice to synchronize all nodes in network >>>>> with single source in order to have the same time and save bandwidth. >>>>> Also I understand that it's comfortable to let FreeIPA installer take >>>>> care of it. >>>>> But I don't think FreeIPA should do it IMO this is job for Ansible or >>>>> similar tool. Also the problem is that in some situations FreeIPA >>>>> installer makes it worse. >>>>> >>>>> Example: >>>>> >>>>> 1. Install FreeIPA server (ipa1.example.org) >>>>> 2. Install FreeIPA client on all nodes in network >>>>> 3. Install replica (ipa2.example.org) of FreeIPA server to increase >>>>> redundancy >>>>> >>>>> Now all the clients have ipa1.example.org as the only server in >>>>> /etc/ntp.conf. If the first FreeIPA server becomes unreachable all >>>>> clients will be able to contact KDC on the other server thanks to DNS >>>>> autodiscovery in libkrb5 but will be unable to synchronize time. >>>> >>>> Remember that the goal of IPA was to herd together a bunch of software >>>> to make hard things easier. This included dealing with the 5-minute >>>> Kerberos window so ntp was configured on the client and server (which is >>>> less of any issue now). >>>> >>>> When making changes you have to ask yourself who are you making this >>>> easier for: you or the user. >>>> >>>> Yes, getting NTP right is hard, but does it meet the 80/20 rule in terms >>>> of success? I'd think so. I >>>> >>>> If someone wants to configure it using Ansible they can use the >>>> --no-ntp. If they want to use different time servers they can pass in >>>> --ntp-server. But by default IMHO it should do something sane to give a >>>> good experience. >>> >>> I think to do something sane is exactly the point of this, and the sanest >>> thing we can do is to not touch NTP configuration at all: >>> >>> * if the NTP configuration obtained via DHCP works, we can't make it any >>> better by touching it, only worse, >>> * if the default NTP configuration shipped with the distribution works, we >>> again can't make it any better by touching it, >>> * if we are running inside container, time is synchronized by other means >>> and we should not touch NTP configuration at all, >>> * if neither the default NTP configuration nor the NTP configuration >>> obtained via DHCP works and we are not running inside container, we may >>> attempt to fix the configuration, but it will not be permanent and will work >>> only for this specific host. >>> >>> I think the first 3 points cover 99% of real-life deployments, and yet we >>> are >>> optimized towards the remaining 1%, with the potential of breaking the >>> configuration for the 99%. This is far from sane IMHO. >> >> +1 for Honza's point. >> >> Current NTP code is works only for initial setup and silently breaks >> synchronization later on. Most importantly it breaks synchronization as soon >> as admin removes old replicas and replaces them with new ones - there is no >> mechanism to update the records in the client configuration (and SRV >> discovery >> is not supported by clients). >> >> I.e. when admin decommission replicas which were around at the time of client >> installation, the NTP on client will silently break. This would not happen if >> you did not touch it. >> >> (This also implicitly means that IPA-configured NTP is broken on all clients >> in topologies which were completely migrated from RHEL 6 to RHEL 7.) >> >> Either DHCP or default distro config would solve the problem better. > > That's fair but where are the huge pile of bugs, tickets and user > e-mails complaining about time? Or has nobody noticed yet?
Hard to say. There might be multiple reasons for this. E.g. - Starting with Fedora 16, there is Chronyd installed by default. IPA client installer does not configure Chronyd by default so there is nothing to break. - DHCP integration still modifies IPA-generated ntp.conf. - Users who care might use configuration management tool. > I'm just wondering whether dropping it altogether is the right choice or > if enhancing the time clients to say, support SRV records is a > preferable option. > > There is a real advantage in having the IPA clients using the same time > source as the IPA masters (in this case the masters themselves). > > Like Simo I have mixed feelings about this and won't push on it anymore > but completely dropping features should be well-considered and a last > resort IMHO. +1 We should carefully consider the change and document it so we have something to start with in future, when things need to be changed again. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code