Re: [Freeipa-devel] NTP in FreeIPA

[Jan Cholasta]

On 30.11.2016 16:09, Rob Crittenden wrote:

David Kupka wrote:

On 29/11/16 18:10, Alexander Bokovoy wrote:

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.


For argument's sake, let's say NTP configuration in the client is
dropped and managed by the OS or other administrators.

What implication does this have for configuring NTP server on masters?
Would that be stopped as well? What about existing installs?


I think there should be no implication, the server is a completely 
different thing.


The only thing I would maybe do is to detect if there is an existing NTP 
server configuration and if there is, do not touch it.




I don't believe there is a precedence for removing a service from IPA.

rob




--
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

Re: [Freeipa-devel] NTP in FreeIPA

[Simo Sorce]

On Wed, 2016-11-30 at 16:57 +0100, David Kupka wrote:
> Upgrades to 4.x will revert configuration if done by FreeIPA.

Why would you revert a perfectly valid configuration ?
I can understand that you wan to stop managing the server, but I do not
see why you should un-configure it.

> I think it's actually that simple. The only hard part is reaching the 
> agreement.

I still think we need to offer the NTP option even if not on by default,
so on upgrade we would have to keep maintaining it.

Keep in mind that NTP is extremely important, still, in virtualized
environment and PoC environment where you must assure, with your own
means, that clocks are synchronized. Testing environments are often very
broken, reason why we also offer a DNS server.
And a testing environment generally give you the first impression, so if
it breaks horrible (as it does when clocks are not in sync then people
just stop caring and do not move to production.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
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

Re: [Freeipa-devel] NTP in FreeIPA

[David Kupka]

On 30/11/16 16:09, Rob Crittenden wrote:

David Kupka wrote:

On 29/11/16 18:10, Alexander Bokovoy wrote:

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.


For argument's sake, let's say NTP configuration in the client is
dropped and managed by the OS or other administrators.

What implication does this have for configuring NTP server on masters?
Would that be stopped as well? What about existing installs?

I don't believe there is a precedence for removing a service from IPA.

rob



Well, everything was done for the first time at some point in history.

I would prefer removing it from server too.

I imagine it this way:
0. We agree that NTP as FreeIPA service will be dropped in 4.x
1. We add big fat warning to nearest release (currently 4.5) that 
FreeIPA will stop supporting NTP as its service on server and client and 
if NTP was configured by FreeIPA (we can tell from sysrestore) upgrade 
will revert those changes.
2. New installations of 4.x will not configure NTP on server nor client. 
Upgrades to 4.x will revert configuration if done by FreeIPA.


I think it's actually that simple. The only hard part is reaching the 
agreement.


While I understand that the value of FreeIPA is entirely in taking care 
of non-trivial services and orchestrating them in a way most comfortable 
for the administrator I think configuring NTP is:

 * reasonably easy (<5 lines on client, <10 lines on server),
 * unnecessary in most cases (distributions defaults or 
DHCP+NetworkManager just work)

and so not worth keeping in 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

Re: [Freeipa-devel] NTP in FreeIPA

[Alexander Bokovoy]

On ke, 30 marras 2016, Rob Crittenden wrote:

David Kupka wrote:

On 29/11/16 18:10, Alexander Bokovoy wrote:

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.


For argument's sake, let's say NTP configuration in the client is
dropped and managed by the OS or other administrators.

What implication does this have for configuring NTP server on masters?
Would that be stopped as well? What about existing installs?

Here is the problem: in Kerberos realm services must have time
synchronized with KDC. The patches from StefW which added ability to
record a time skew between the Kerberos client and KDC do not apply to
Kerberos client - Kerberos service communication.

Given that IPA clients can host Kerberos services (at the very least,
SSH is such a service), this practically means they need to have a time
source that is synchronized with the KDC(s) they are talking to.

To me this means we should not really remove NTP configuration but
instead expand ntpd support to cover chronyd as well.



I don't believe there is a precedence for removing a service from IPA.

Neither do I.

--
/ Alexander Bokovoy

--
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

Re: [Freeipa-devel] NTP in FreeIPA

[Rob Crittenden]

David Kupka wrote:
> On 29/11/16 18:10, Alexander Bokovoy wrote:
>> 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.

For argument's sake, let's say NTP configuration in the client is
dropped and managed by the OS or other administrators.

What implication does this have for configuring NTP server on masters?
Would that be stopped as well? What about existing installs?

I don't believe there is a precedence for removing a service from IPA.

rob

-- 
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

Re: [Freeipa-devel] NTP in FreeIPA

[David Kupka]

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 

Re: [Freeipa-devel] NTP in FreeIPA

[Alexander Bokovoy]

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.

--
/ Alexander Bokovoy

--
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

Re: [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 

Re: [Freeipa-devel] NTP in FreeIPA

[Rob Crittenden]

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?

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.

rob

-- 
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

Re: [Freeipa-devel] NTP in FreeIPA

[Petr Spacek]

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.

Petr^2 Spacek


>> There don't seem to be a ton of NTP tickets and I don't recall a lot of
>> user's pressing for it to go away (the reverse, many times their
>> problems revolve around time not being synced). I wonder if a survey on
>> freeipa-users would be in order to see how hot an issue this really is.

-- 
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

Re: [Freeipa-devel] NTP in FreeIPA

[Jan Cholasta]

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.




There don't seem to be a ton of NTP tickets and I don't recall a lot of
user's pressing for it to go away (the reverse, many times their
problems revolve around time not being synced). I wonder if a survey on
freeipa-users would be in order to see how hot an issue this really is.

rob




--
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

Re: [Freeipa-devel] NTP in FreeIPA

[John Dennis]

On 11/28/2016 02:57 PM, 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.

There don't seem to be a ton of NTP tickets and I don't recall a lot of
user's pressing for it to go away (the reverse, many times their
problems revolve around time not being synced). I wonder if a survey on
freeipa-users would be in order to see how hot an issue this really is.


+1 Thanks Rob for taking the words out of my mouth.


--
John

--
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

Re: [Freeipa-devel] NTP in FreeIPA

[Rob Crittenden]

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.

There don't seem to be a ton of NTP tickets and I don't recall a lot of
user's pressing for it to go away (the reverse, many times their
problems revolve around time not being synced). I wonder if a survey on
freeipa-users would be in order to see how hot an issue this really is.

rob

-- 
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

Re: [Freeipa-devel] NTP in FreeIPA

[Martin Basti]

On 24.11.2016 20:31, Gabe Alford wrote:
On Thu, Nov 24, 2016 at 9:14 AM, Martin Basti > wrote:




On 24.11.2016 16:11, Gabe Alford wrote:

On Thu, Nov 24, 2016 at 1:29 AM, Martin Basti > 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?


And I realized that this may be applicable only if IPA is installed with 
integrated DNS, when IPA automatically updates system services DNS 
records. With external DNS we will bother admins to create SRV records, 
so it is the same as creating DHCP configuration.


we can add it to ipa-advise.

Martin^2


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
> 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 

Re: [Freeipa-devel] NTP in FreeIPA

[Gabe Alford]

On Thu, Nov 24, 2016 at 9:14 AM, Martin Basti  wrote:

>
>
> On 24.11.2016 16:11, Gabe Alford wrote:
>
> On Thu, Nov 24, 2016 at 1:29 AM, Martin Basti  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 
 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 

Re: [Freeipa-devel] NTP in FreeIPA

[Petr Spacek]

On 24.11.2016 17:14, Martin Basti wrote:
> 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.

If DHCP is not good enough for your environment then you *must not* use
standard NTP, otherwise you just broke all the security.

Standard NTP is not more secure than DHCP.

-- 
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

Re: [Freeipa-devel] NTP in FreeIPA

[Martin Basti]

On 24.11.2016 16:11, Gabe Alford wrote:
On Thu, Nov 24, 2016 at 1:29 AM, Martin Basti > 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.



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
> 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

Re: [Freeipa-devel] NTP in FreeIPA

[Martin Basti]

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


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)


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.


Let deprecate it in 4.5

Martin^2




On Tue, Nov 22, 2016 at 7:05 AM, Jan Cholasta  
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










--
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

Re: [Freeipa-devel] NTP in FreeIPA

[David Kupka]

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.




On Tue, Nov 22, 2016 at 7:05 AM, Jan Cholasta  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








--
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

Re: [Freeipa-devel] NTP in FreeIPA

[Gabe Alford]

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.

On Tue, Nov 22, 2016 at 7:05 AM, Jan Cholasta  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
>
-- 
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

Re: [Freeipa-devel] NTP in FreeIPA

[Jan Cholasta]

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

[Freeipa-devel] NTP in FreeIPA

[David Kupka]

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?


--
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