On 29/11/16 18:10, Alexander Bokovoy wrote:
On ti, 29 marras 2016, Petr Spacek wrote:
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.
Still, bug reports and users' complaints is the only external measure we
have. There are close to nothing in complaints about NTP functionality,
other than requests to support chronyd and a better discover of existing
NTP setups. I don't think that requires dramatic action like removal of
NTP support at all.
As Petr already pointed out, since Fedora 16 chronyd is enabled by
default and ipa-client-install doesn't configure time synchronization
when chronyd is enabled.
I believe that majority of users haven't used '--force-ntpd' and since
it still worked they haven't filed any ticket.
IMO in this case no bug reports means no users rather than no bugs or
requests.
Unfortunately, this is just my guess and AFAIK we don't have any data
from users showing how they use FreeIPA.
--
David Kupka
--
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
