[Freeipa-devel] NTP in FreeIPA

Gabe Alford redhatrises at gmail.com
Thu Nov 24 19:31:18 UTC 2016


On Thu, Nov 24, 2016 at 9:14 AM, Martin Basti <mbasti at redhat.com> wrote:

>
>
> On 24.11.2016 16:11, Gabe Alford wrote:
>
> On Thu, Nov 24, 2016 at 1:29 AM, Martin Basti <mbasti at redhat.com> wrote:
>
>>
>>
>> On 24.11.2016 07:06, 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
>>>
>>
> Why not have NTP look at a _srv_records?
>
>
> Do ntpclients support this natively?  I just found some ugly hacks for
> chrony, i.e extra service that is dynamically changing config file.
> But yes this may be way too, but dirty.
>
>
You are right. It is an ugly. I wonder if we can push to make it not so
ugly so that _srv_ is used for both Chrony and NTP which IMO makes those
two products better. If not and the desire is truly to get rid of
chrony/ntp configuration on the client side, what about adding Chrony and
NTP configuration to ipa-advise?


>
>
>> 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.
>>>
>>>
>> This can be resolved by DHCP configured NTP. When NTP server changed, you
>> just change DHCPd config and hosts conf will be synced.
>> We may keep NTP on IPA server side configured, but I'm voting for
>> removing it from clients and document+endorse people to use DHCP (anyway
>> distros have always enabled some time synchronization so it should
>> naturally work without even in small deployments)
>>
>
> If NTP is still configured on the IPA server, this may be less of an
> issue. Not everyone has/is/will be using ansible. Also in secure
> environments, DHCP
> is not allowed/used at all.
>
>
>
>> Also NTP is somehow incompatible with containers, usually containers have
>> time synchronized from host, and by default IPA client container don't do
>> NTP configuration.
>>
>
> Isn't that what the --no-ntp option in the client is for anyway?
>
>
>>
>> Let deprecate it in 4.5
>>
>> Martin^2
>>
>>
>>
>>
>>>> On Tue, Nov 22, 2016 at 7:05 AM, Jan Cholasta <jcholast at redhat.com>
>>>> wrote:
>>>>
>>>> On 22.11.2016 13:06, Petr Spacek wrote:
>>>>>
>>>>> On 22.11.2016 12:15, David Kupka wrote:
>>>>>>
>>>>>> Hello everyone!
>>>>>>>
>>>>>>> Is it worth to keep configuring NTP in FreeIPA?
>>>>>>>
>>>>>>> In usual environment there're no special requirements for time
>>>>>>> synchronization
>>>>>>> and the distribution default (be it ntpd, chrony or anything else)
>>>>>>> will
>>>>>>> just
>>>>>>> work. Any tampering with the configuration can't make it any better.
>>>>>>>
>>>>>>> In environment with special requirements (network disconnected from
>>>>>>> public
>>>>>>> internet, nodes disconnected from topology for longer time, ...) time
>>>>>>> synchronization must be taken care of accordingly by system
>>>>>>> administrator and
>>>>>>> FreeIPA simply can't help here.
>>>>>>>
>>>>>>> Also there are problems and weird behavior with the current FreeIPA
>>>>>>> installers:
>>>>>>>
>>>>>>> * ipa-client-install replaces all servers in /etc/ntp.conf with the
>>>>>>> ones
>>>>>>> specified by user or resolved from DNS. If none were provided nor
>>>>>>> resolved the
>>>>>>> FreeIPA server specified/resolved during installation it used. This
>>>>>>> leads in
>>>>>>> just single server in the configuration and no time synchronization
>>>>>>> when
>>>>>>> this
>>>>>>> server is down/decommissioned.
>>>>>>>
>>>>>>> * ipa-client-install replaces the NTP configuration. If there was any
>>>>>>> parts
>>>>>>> previously edited by system administrator it's lost.
>>>>>>>
>>>>>>> * ipa-server-install adds {0-4}.$PLATFORM.pool.ntp.org to
>>>>>>> /etc/ntp.conf.
>>>>>>> What's the point in doing that? These servers're already in the
>>>>>>> configuration
>>>>>>> file installed with ntp package.
>>>>>>>
>>>>>>> I have NTP-related WIP patches that solve some of the issues but in
>>>>>>> general I
>>>>>>> would prefer to remove the whole thing together with documenting
>>>>>>> "Please
>>>>>>> make
>>>>>>> sure that time on all FreeIPA servers and clients is synchronized. On
>>>>>>> most
>>>>>>> distributions this was already done during system installation."
>>>>>>>
>>>>>>> Can we mark NTP options deprecated in 4.5 and remove them and stop
>>>>>>> touching
>>>>>>> any time syncing service in 4.6?
>>>>>>>
>>>>>>>
>>>>>> Considering that default config is just fine for normal cases, and
>>>>>> given
>>>>>> how
>>>>>> poorly integrated it is into FreeIPA, I agree with David. FreeIPA
>>>>>> should
>>>>>> get
>>>>>> out of configuration management business.
>>>>>>
>>>>>>
>>>>> +1
>>>>>
>>>>> --
>>>>> Jan Cholasta
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20161124/d8579a5e/attachment.htm>


More information about the Freeipa-devel mailing list