[Freeipa-devel] NTP in FreeIPA

[Petr Spacek]

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