IPA's NTP service

[Tibor Dudlák]

Hello FreeIPA-devel list fellow beings!

I would like to continue the discussion started in [1], and find its
solution.

While using the Single-Sign-on authentication provided via an MIT Kerberos
KDC  there must not be any significant clock skew between server and
clients so a time synchronization service is required.

Red Hat Enterprise Linux is about to deprecate ntpd service and will
support chronyd instead. This will happen in release 8 and by this time we
should agree on some changes in IPA - whether to remove or replace the already
used ntpd service. I would like to sum up this change in a design page but
there should be an agreement first.

IPA, as is, checks the system configuration and if there is an NTP service
configured and running then it forces ntpd, meaning it disables any other
NTP service. It also alters its configuration, and restarts the NTP service
instance.

We may now want to consider, as the time sync service change is required,
to NOT configure a service that is not a part of the identity management
such as NTP, and leave it to system/IPA administrators.

IPA install script may only check wheter there is an NTP service running
and if not, it would ask the administrator to configure it before the IPA
installation.

Upgrade of IPA might be more complicated because there will be the ntpd
service entry in LDAP, and the service will be up and running. I would
suggest that we do not remove any working ntpd service already configured
but only disown it from IPA's LDAP tree.

I will be glad for any input from you people and hopefully there will be an
acceptable solution for this soon :)

Thanks!

[1]
https://www.redhat.com/archives/freeipa-devel/2016-November/msg00807.html

-- 
Tibor Dudlák
Identity management - FreeIPA
Brno, TPB-C, 2C407
Red Hat

[Simo Sorce]

On Wed, 2018-01-24 at 16:25 +0100, Tibor Dudlák via FreeIPA-devel
wrote:
>  Hello FreeIPA-devel list fellow beings!
>  
>  I would like to continue the discussion started in [1], and find its
>  solution.
>  
>  While using the Single-Sign-on authentication provided via an MIT Kerberos
>  KDC  there must not be any significant clock skew between server and
>  clients so a time synchronization service is required.
>  
>  Red Hat Enterprise Linux is about to deprecate ntpd service and will
>  support chronyd instead. This will happen in release 8 and by this time we
>  should agree on some changes in IPA - whether to remove or replace the already
>  used ntpd service. I would like to sum up this change in a design page but
>  there should be an agreement first.
>  
>  IPA, as is, checks the system configuration and if there is an NTP service
>  configured and running then it forces ntpd, meaning it disables any other
>  NTP service. It also alters its configuration, and restarts the NTP service
>  instance.
>  
>  We may now want to consider, as the time sync service change is required,
>  to NOT configure a service that is not a part of the identity management
>  such as NTP, and leave it to system/IPA administrators. 
Let me explain why we do this:
As you noted above kerberos will fail to work properly if clocks drift
too much, so we wanted to provide a simple way to keep the whole domain
in sync. We also had plans to keep the domain in sync *securely* as an
attacker could create Denial pf Service attacks by subtly drifting
different machines clocks.

ntpd was the only one that offered hooks to sign NTP packets (which
were used by Samba only at the time and required compile time changes
when we started) using kerberos keys, so the original plan was to
eventually get there. Unfortunately we never prioritized this work.

So given the above we initially decided to make IPA servers also ntp
servers and configure client to use IPA server as time sources.

This is just to give an overview of the reasons behind choosing ntpd
specifically and why it was overriding ntp config on servers/clients

>  IPA install script may only check wheter there is an NTP service
> running
>  and if not, it would ask the administrator to configure it before the IPA
>  installation. 
I do not think we need this strictly for the first server, these days
time keeping is more important in general and servers tend to be
already kept in sync, either via virt devices, or ntp.
however what we may want to do is, instead, to check the time
synchronization on clients (and therefore future ipa replicas, as ipa
client install is always done fist now), by dissecting a kerberos reply
from the server that carries the server time (I think this information
is actually stored in the ccache after a successful kinit, so we could
just inspect the ccache as well).

If we detect a drift bigger than X (where X < 5 min), we could fail the
install and ask the admin to check the client and server time are
synchronized.

>  Upgrade of IPA might be more complicated because there will be the
> ntpd
>  service entry in LDAP, and the service will be up and running. I would
>  suggest that we do not remove any working ntpd service already configured
>  but only disown it from IPA's LDAP tree. 
Why would we need to disown it ?
I think it is ok to proposed that in new installs (even in an existing
domain) new servers will stop configuring ntp by default, but I see no
reason to touch existing servers.

however I think we should *retain* the option to install and configure
ntpd, it is very convenient for tests and custom installs/pocs, where
you want to minimize the amount of prepping to do, and want something
that "just works".

If ntpd is dropped from a distribution I would assume we'll use the
platform portability code to replace ntpd with whatever other
NTP/timesync server/client is appropriate for the platform when the
option to install NTP is requested.

HTH,
Simo.

>  I will be glad for any input from you people and hopefully there will
> be an
>  acceptable solution for this soon :)
>  
>  Thanks!
>  
>  [1]
>  https://www.redhat.com/archives/freeipa-devel/2016-November/msg00807.html
>  
>  _______________________________________________
>  FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorahosted.org 
-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

[Levin Stanislav]

Hello All.


There are several good NTP servers/clients. And different Linux
distributions

use them (not only ntpd or chronyd). But FreeIPA chose ntpd strictly. It
is a

bottleneck for a platform porting. Perhaps, FreeIPA should allow to select

administrator which one to use and should support it (like install and
work).


Thank you.



24.01.2018 18:57, Simo Sorce via FreeIPA-devel пишет:
>  On Wed, 2018-01-24 at 16:25 +0100, Tibor Dudlák via FreeIPA-devel
>  wrote:
> > Hello FreeIPA-devel list fellow beings!
> >
> > I would like to continue the discussion started in [1], and find its
> > solution.
> >
> > While using the Single-Sign-on authentication provided via an MIT Kerberos
> > KDC  there must not be any significant clock skew between server and
> > clients so a time synchronization service is required.
> >
> > Red Hat Enterprise Linux is about to deprecate ntpd service and will
> > support chronyd instead. This will happen in release 8 and by this time we
> > should agree on some changes in IPA - whether to remove or replace the already
> > used ntpd service. I would like to sum up this change in a design page but
> > there should be an agreement first.
> >
> > IPA, as is, checks the system configuration and if there is an NTP service
> > configured and running then it forces ntpd, meaning it disables any other
> > NTP service. It also alters its configuration, and restarts the NTP service
> > instance.
> >
> > We may now want to consider, as the time sync service change is required,
> > to NOT configure a service that is not a part of the identity management
> > such as NTP, and leave it to system/IPA administrators.
>  Let me explain why we do this:
>  As you noted above kerberos will fail to work properly if clocks drift
>  too much, so we wanted to provide a simple way to keep the whole domain
>  in sync. We also had plans to keep the domain in sync *securely* as an
>  attacker could create Denial pf Service attacks by subtly drifting
>  different machines clocks.
>
>  ntpd was the only one that offered hooks to sign NTP packets (which
>  were used by Samba only at the time and required compile time changes
>  when we started) using kerberos keys, so the original plan was to
>  eventually get there. Unfortunately we never prioritized this work.
>
>  So given the above we initially decided to make IPA servers also ntp
>  servers and configure client to use IPA server as time sources.
>
>  This is just to give an overview of the reasons behind choosing ntpd
>  specifically and why it was overriding ntp config on servers/clients
>
> > IPA install script may only check wheter there is an NTP service running
> > and if not, it would ask the administrator to configure it before the IPA
> > installation.
>  I do not think we need this strictly for the first server, these days
>  time keeping is more important in general and servers tend to be
>  already kept in sync, either via virt devices, or ntp.
>  however what we may want to do is, instead, to check the time
>  synchronization on clients (and therefore future ipa replicas, as ipa
>  client install is always done fist now), by dissecting a kerberos reply
>  from the server that carries the server time (I think this information
>  is actually stored in the ccache after a successful kinit, so we could
>  just inspect the ccache as well).
>
>  If we detect a drift bigger than X (where X < 5 min), we could fail the
>  install and ask the admin to check the client and server time are
>  synchronized.
>
> > Upgrade of IPA might be more complicated because there will be the ntpd
> > service entry in LDAP, and the service will be up and running. I would
> > suggest that we do not remove any working ntpd service already configured
> > but only disown it from IPA's LDAP tree.
>  Why would we need to disown it ?
>  I think it is ok to proposed that in new installs (even in an existing
>  domain) new servers will stop configuring ntp by default, but I see no
>  reason to touch existing servers.
>
>  however I think we should *retain* the option to install and configure
>  ntpd, it is very convenient for tests and custom installs/pocs, where
>  you want to minimize the amount of prepping to do, and want something
>  that "just works".
>
>  If ntpd is dropped from a distribution I would assume we'll use the
>  platform portability code to replace ntpd with whatever other
>  NTP/timesync server/client is appropriate for the platform when the
>  option to install NTP is requested.
>
>  HTH,
>  Simo.
>
> > I will be glad for any input from you people and hopefully there will be an
> > acceptable solution for this soon :)
> >
> > Thanks!
> >
> > [1]
> > https://www.redhat.com/archives/freeipa-devel/2016-November/msg00807.html
> >
> > _______________________________________________
> > FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorahosted.org

[Rob Crittenden]

Levin Stanislav via FreeIPA-devel wrote:
>  Hello All.
>  
>  
>  There are several good NTP servers/clients. And different Linux
>  distributions
>  
>  use them (not only ntpd or chronyd). But FreeIPA chose ntpd strictly. It
>  is a
>  
>  bottleneck for a platform porting. Perhaps, FreeIPA should allow to select
>  
>  administrator which one to use and should support it (like install and
>  work). 
Administrators can do that now with the -N option (don't enable NTP).

The problem is two-fold:

1. NTP was added because proper time is so critical to Kerberos and
389-ds replication and it was clear early on in IPA that virtually
nobody had it properly working. Some still struggle.
2. Providing too many knobs increases support and development costs in
time and effort. Each server has its own config and idiosyncrasies and
they can change over time so keeping up has cost.

We didn't pick ntpd as the winner. It was the only game in town at the
time, and given it worked and since then we've had much bigger fish to
fry there has been no real drive to replace it (at least not so much
that someone provided patches to do so).

rob

>  
>  
>  Thank you.
>  
>  
>  
>  24.01.2018 18:57, Simo Sorce via FreeIPA-devel пишет:
> > On Wed, 2018-01-24 at 16:25 +0100, Tibor Dudlák via FreeIPA-devel
> > wrote:
> >> Hello FreeIPA-devel list fellow beings!
> >>
> >> I would like to continue the discussion started in [1], and find its
> >> solution.
> >>
> >> While using the Single-Sign-on authentication provided via an MIT Kerberos
> >> KDC  there must not be any significant clock skew between server and
> >> clients so a time synchronization service is required.
> >>
> >> Red Hat Enterprise Linux is about to deprecate ntpd service and will
> >> support chronyd instead. This will happen in release 8 and by this time we
> >> should agree on some changes in IPA - whether to remove or replace the already
> >> used ntpd service. I would like to sum up this change in a design page but
> >> there should be an agreement first.
> >>
> >> IPA, as is, checks the system configuration and if there is an NTP service
> >> configured and running then it forces ntpd, meaning it disables any other
> >> NTP service. It also alters its configuration, and restarts the NTP service
> >> instance.
> >>
> >> We may now want to consider, as the time sync service change is required,
> >> to NOT configure a service that is not a part of the identity management
> >> such as NTP, and leave it to system/IPA administrators.
> > Let me explain why we do this:
> > As you noted above kerberos will fail to work properly if clocks drift
> > too much, so we wanted to provide a simple way to keep the whole domain
> > in sync. We also had plans to keep the domain in sync *securely* as an
> > attacker could create Denial pf Service attacks by subtly drifting
> > different machines clocks.
> >
> > ntpd was the only one that offered hooks to sign NTP packets (which
> > were used by Samba only at the time and required compile time changes
> > when we started) using kerberos keys, so the original plan was to
> > eventually get there. Unfortunately we never prioritized this work.
> >
> > So given the above we initially decided to make IPA servers also ntp
> > servers and configure client to use IPA server as time sources.
> >
> > This is just to give an overview of the reasons behind choosing ntpd
> > specifically and why it was overriding ntp config on servers/clients
> >
> >> IPA install script may only check wheter there is an NTP service running
> >> and if not, it would ask the administrator to configure it before the IPA
> >> installation.
> > I do not think we need this strictly for the first server, these days
> > time keeping is more important in general and servers tend to be
> > already kept in sync, either via virt devices, or ntp.
> > however what we may want to do is, instead, to check the time
> > synchronization on clients (and therefore future ipa replicas, as ipa
> > client install is always done fist now), by dissecting a kerberos reply
> > from the server that carries the server time (I think this information
> > is actually stored in the ccache after a successful kinit, so we could
> > just inspect the ccache as well).
> >
> > If we detect a drift bigger than X (where X < 5 min), we could fail the
> > install and ask the admin to check the client and server time are
> > synchronized.
> >
> >> Upgrade of IPA might be more complicated because there will be the ntpd
> >> service entry in LDAP, and the service will be up and running. I would
> >> suggest that we do not remove any working ntpd service already configured
> >> but only disown it from IPA's LDAP tree.
> > Why would we need to disown it ?
> > I think it is ok to proposed that in new installs (even in an existing
> > domain) new servers will stop configuring ntp by default, but I see no
> > reason to touch existing servers.
> >
> > however I think we should *retain* the option to install and configure
> > ntpd, it is very convenient for tests and custom installs/pocs, where
> > you want to minimize the amount of prepping to do, and want something
> > that "just works".
> >
> > If ntpd is dropped from a distribution I would assume we'll use the
> > platform portability code to replace ntpd with whatever other
> > NTP/timesync server/client is appropriate for the platform when the
> > option to install NTP is requested.
> >
> > HTH,
> > Simo.
> >
> >> I will be glad for any input from you people and hopefully there will be an
> >> acceptable solution for this soon :)
> >>
> >> Thanks!
> >>
> >> [1]
> >> https://www.redhat.com/archives/freeipa-devel/2016-November/msg00807.html
> >>
> >> _______________________________________________
> >> FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
> >> To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorahosted.org
>  
>  _______________________________________________
>  FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorahosted.org
>

[Tibor Dudlák]

On Thu, Jan 25, 2018 at 2:02 PM, Rob Crittenden via FreeIPA-devel <
freeipa-devel(a)lists.fedorahosted.org&gt; wrote:

>  Levin Stanislav via FreeIPA-devel wrote:
>  > Hello All.
>  >
>  >
>  > There are several good NTP servers/clients. And different Linux
>  > distributions
>  >
>  > use them (not only ntpd or chronyd). But FreeIPA chose ntpd strictly. It
>  > is a
>  >
>  > bottleneck for a platform porting. Perhaps, FreeIPA should allow to
>  select
>  >
>  > administrator which one to use and should support it (like install and
>  > work).
>
>  Administrators can do that now with the -N option (don't enable NTP).
>  
If IPA will not drop any NTP service configuration I believe this, Stanislav,
is what you would need, to have another service running.
I think there is no way IPA could support all of possible NTP daemons as
Rob said.


>  The problem is two-fold:
>
>  1. NTP was added because proper time is so critical to Kerberos and
>  389-ds replication and it was clear early on in IPA that virtually
>  nobody had it properly working. Some still struggle.
>  2. Providing too many knobs increases support and development costs in
>  time and effort. Each server has its own config and idiosyncrasies and
>  they can change over time so keeping up has cost.
>
>  We didn't pick ntpd as the winner. It was the only game in town at the
>  time, and given it worked and since then we've had much bigger fish to
>  fry there has been no real drive to replace it (at least not so much
>  that someone provided patches to do so).
>
>  rob
>
>  >
>  >
>  > Thank you.
>  >
>  >
>  >
>  > 24.01.2018 18:57, Simo Sorce via FreeIPA-devel пишет:
>  >> On Wed, 2018-01-24 at 16:25 +0100, Tibor Dudlák via FreeIPA-devel
>  >> wrote:
>  >>> Hello FreeIPA-devel list fellow beings!
>  >>>
>  >>> I would like to continue the discussion started in [1], and find its
>  >>> solution.
>  >>>
>  >>> While using the Single-Sign-on authentication provided via an MIT
>  Kerberos
>  >>> KDC  there must not be any significant clock skew between server and
>  >>> clients so a time synchronization service is required.
>  >>>
>  >>> Red Hat Enterprise Linux is about to deprecate ntpd service and will
>  >>> support chronyd instead. This will happen in release 8 and by this
>  time we
>  >>> should agree on some changes in IPA - whether to remove or replace the
>  already
>  >>> used ntpd service. I would like to sum up this change in a design page
>  but
>  >>> there should be an agreement first.
>  >>>
>  >>> IPA, as is, checks the system configuration and if there is an NTP
>  service
>  >>> configured and running then it forces ntpd, meaning it disables any
>  other
>  >>> NTP service. It also alters its configuration, and restarts the NTP
>  service
>  >>> instance.
>  >>>
>  >>> We may now want to consider, as the time sync service change is
>  required,
>  >>> to NOT configure a service that is not a part of the identity
>  management
>  >>> such as NTP, and leave it to system/IPA administrators.
>  >> Let me explain why we do this:
>  >> As you noted above kerberos will fail to work properly if clocks drift
>  >> too much, so we wanted to provide a simple way to keep the whole domain
>  >> in sync. We also had plans to keep the domain in sync *securely* as an
>  >> attacker could create Denial pf Service attacks by subtly drifting
>  >> different machines clocks.
>  >>
>  >> ntpd was the only one that offered hooks to sign NTP packets (which
>  >> were used by Samba only at the time and required compile time changes
>  >> when we started) using kerberos keys, so the original plan was to
>  >> eventually get there. Unfortunately we never prioritized this work.
>  >>
>  >> So given the above we initially decided to make IPA servers also ntp
>  >> servers and configure client to use IPA server as time sources.
>  
Not configuring NTP service but still requiting it might be way to give
freedom of choice to IPA administrator to set one they prefer before
installing IPA. :)


>  >>
>  >> This is just to give an overview of the reasons behind choosing ntpd
>  >> specifically and why it was overriding ntp config on servers/clients
>  >>
>  >>> IPA install script may only check wheter there is an NTP service
>  running
>  >>> and if not, it would ask the administrator to configure it before the
>  IPA
>  >>> installation.
>  >> I do not think we need this strictly for the first server, these days
>  >> time keeping is more important in general and servers tend to be
>  >> already kept in sync, either via virt devices, or ntp.
>  >> however what we may want to do is, instead, to check the time
>  >> synchronization on clients (and therefore future ipa replicas, as ipa
>  >> client install is always done fist now), by dissecting a kerberos reply
>  >> from the server that carries the server time (I think this information
>  >> is actually stored in the ccache after a successful kinit, so we could
>  >> just inspect the ccache as well).
>  >>
>  >> If we detect a drift bigger than X (where X < 5 min), we could fail the
>  >> install and ask the admin to check the client and server time are
>  >> synchronized.
>  >>
>  >>> Upgrade of IPA might be more complicated because there will be the ntpd
>  >>> service entry in LDAP, and the service will be up and running. I would
>  >>> suggest that we do not remove any working ntpd service already
>  configured
>  >>> but only disown it from IPA's LDAP tree.
>  >> Why would we need to disown it ?
>  >> I think it is ok to proposed that in new installs (even in an existing
>  >> domain) new servers will stop configuring ntp by default, but I see no
>  >> reason to touch existing servers.
>  >>
>  >> however I think we should *retain* the option to install and configure
>  >> ntpd, it is very convenient for tests and custom installs/pocs, where
>  >> you want to minimize the amount of prepping to do, and want something
>  >> that "just works".
>  >>
>  >> If ntpd is dropped from a distribution I would assume we'll use the
>  >> platform portability code to replace ntpd with whatever other
>  >> NTP/timesync server/client is appropriate for the platform when the
>  >> option to install NTP is requested.
>  >>
>  
So should we only replace ntpd with chronyd and have option to not
configure NTP service (chronyd) as it is now if administrator wants to use
other than chronyd?


>  >> HTH,
>  >> Simo.
>  >>
>  >>> I will be glad for any input from you people and hopefully there will
>  be an
>  >>> acceptable solution for this soon :)
>  >>>
>  >>> Thanks!
>  >>>
>  >>> [1]
>  >>> https://www.redhat.com/archives/freeipa-devel/2016-
>  November/msg00807.html
>  >>>
>  >>> _______________________________________________
>  >>> FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
>  >>> To unsubscribe send an email to freeipa-devel-leave@lists.
>  fedorahosted.org
>  >
>  > _______________________________________________
>  > FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
>  > To unsubscribe send an email to freeipa-devel-leave@lists.
>  fedorahosted.org
>  >
>  _______________________________________________
>  FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorahosted.org
>  
Thanks!

-- 
Tibor Dudlák
Identity management - freeIPA
Brno, TPB-C, 2C407
Red Hat

[Simo Sorce]

On Mon, 2018-01-29 at 14:54 +0100, Tibor Dudlák wrote:

[...]

>  > > > So given the above we initially decided to make IPA
> servers also ntp
>  > > > servers and configure client to use IPA server as time sources.
>  
>  Not configuring NTP service but still requiting it might be way to give
>  freedom of choice to IPA administrator to set one they prefer before
>  installing IPA. :) 
I think this is the worst of the possible outcomes, as now you need to
add one more manual step to the configuration of the system.
The point of ipa-server-install is to simplify installation and
configure everything that is *required* except the Operating System.
Requiring something and not installing it would be a net regression.

[...]

>  So should we only replace ntpd with chronyd and have option to not
>  configure NTP service (chronyd) as it is now if administrator wants to use
>  other than chronyd? 
This is certainly an option, but we would then require to have code for
both ntpd and chronyd upstream, because some older distros use NTP.
Not that this is too difficult, we already have the platform
absraction, so it is a simply a matter of adding chronyd w/o removing
ntpd.

HTH,
Simo.

[Tibor Dudlák]

On Mon, Jan 29, 2018 at 3:09 PM, Simo Sorce <ssorce(a)redhat.com&gt; wrote:

>  On Mon, 2018-01-29 at 14:54 +0100, Tibor Dudlák wrote:
>
>  [...]
>
>  > > > > So given the above we initially decided to make IPA servers also
>  ntp
>  > > > > servers and configure client to use IPA server as time sources.
>  >
>  > Not configuring NTP service but still requiting it might be way to give
>  > freedom of choice to IPA administrator to set one they prefer before
>  > installing IPA. :)
>
>  I think this is the worst of the possible outcomes, as now you need to
>  add one more manual step to the configuration of the system.
>  The point of ipa-server-install is to simplify installation and
>  configure everything that is *required* except the Operating System.
>  Requiring something and not installing it would be a net regression.
>
>  [...]
>
>  > So should we only replace ntpd with chronyd and have option to not
>  > configure NTP service (chronyd) as it is now if administrator wants to
>  use
>  > other than chronyd?
>
>  This is certainly an option, but we would then require to have code for
>  both ntpd and chronyd upstream, because some older distros use NTP.
>  Not that this is too difficult, we already have the platform
>  absraction, so it is a simply a matter of adding chronyd w/o removing
>  ntpd.
>
>  HTH,
>  Simo.
>  
Thanks for input Simo.

-- 
Tibor Dudlák
Identity management - freeIPA
Brno, TPB-C, 2C407
Red Hat

[Levin Stanislav]

Hello.

I have several suggestions:

1) make an optional requires of server/client packages to ntpd, because
last could conflict with another NTP server/client (based to platform);

2) make an abstract NTP module to easy change basic operations (like
read/write configuration, time sync);

3) based on above each Linux distribution team can contribute easily
(e.g. from ALTLinux - openntpd ;-) );

4) Of course manual steps(not by installers) are error
prone(misconfiguration, wrong configuration, etc.).

But IPA controls NTP configuration upon installation only (not at
runtime or start time) as far as i know.

May be add time syncing check?


Thank you.



29.01.2018 17:57, Tibor Dudlák via FreeIPA-devel пишет:
>  On Mon, Jan 29, 2018 at 3:09 PM, Simo Sorce <ssorce(a)redhat.com
>  <mailto:[e-mail]>> wrote:
>
>      On Mon, 2018-01-29 at 14:54 +0100, Tibor Dudlák wrote:
>
>      [...]
>
>      > > > > So given the above we initially decided to make IPA
>      servers also ntp
>      > > > > servers and configure client to use IPA server as time
>      sources.
>      >
>      > Not configuring NTP service but still requiting it might be way
>      to give
>      > freedom of choice to IPA administrator to set one they prefer before
>      > installing IPA. :)
>
>      I think this is the worst of the possible outcomes, as now you need to
>      add one more manual step to the configuration of the system.
>      The point of ipa-server-install is to simplify installation and
>      configure everything that is *required* except the Operating System.
>      Requiring something and not installing it would be a net regression.
>
>      [...]
>
>      > So should we only replace ntpd with chronyd and have option to not
>      > configure NTP service (chronyd) as it is now if administrator
>      wants to use
>      > other than chronyd?
>
>      This is certainly an option, but we would then require to have
>      code for
>      both ntpd and chronyd upstream, because some older distros use NTP.
>      Not that this is too difficult, we already have the platform
>      absraction, so it is a simply a matter of adding chronyd w/o removing
>      ntpd.
>
>      HTH,
>      Simo.
>
>
>  Thanks for input Simo.
>
>  -- 
>  Tibor Dudlák
>  Identity management - freeIPA
>  Brno, TPB-C, 2C407
>  Red Hat
>
>
>  _______________________________________________
>  FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorahosted.org

[Tibor Dudlák]

Hi!

To be more clear about what i do want to achieve, there is bugzilla:

    https://bugzilla.redhat.com/show_bug.cgi?id=1456863

I want to replace ntp configuration with script provided by Miroslav
Lichvar.
And if any administrator would like to have another time synchronization
service up and running they can still use option -N.

Thanks :)
<mlichvar(a)redhat.com&gt;


-- 
Tibor Dudlák
Identity management - freeIPA
Brno, TPB-C, 2C407
Red Hat

[Rob Crittenden]

Tibor Dudlák via FreeIPA-devel wrote:
>  Hello FreeIPA-devel listfellow beings!
>  
>  I would like to continue the discussion started in [1], and find
>  itssolution.
>  
>  While using the Single-Sign-on authentication provided via anMIT
>  Kerberos KDC  there must not be any significant clock skew between
>  server and clients so a time synchronization service is required.
>  
>  Red Hat Enterprise Linux is about to deprecate ntpd service and will
>  support chronyd instead. This will happen in release 8 and by this time
>  we should agree on some changes in IPA-whether to remove or replace the
>  already used ntpd service. I would like to sum up thischange in a design
>  page but there shouldbe an agreementfirst.
>  
>  IPA,as is,checks the system configuration and if there is anNTP service
>  configured and running then it forces ntpd, meaning it disablesany other
>  NTP service. It also altersits configuration, and restartsthe NTP
>  service instance. 
>  
>  We may now want to consider, as the time sync servicechange is required,
>  to NOT configureaservice that is not a part oftheidentity management
>  such as NTP, and leave it to system/IPA administrators. 
>  
>  IPA install script may only check wheterthere is an NTP service running
>  and if not, it wouldask the administrator to configure it before the IPA
>  installation.
>  
>  Upgrade of IPA might be more complicated because there will be thentpd
>  service entry in LDAP,and the service will be up and running. I would
>  suggest that we do not remove any working ntpd service already
>  configured but only disown it from IPA's LDAP tree.
>  
>  I will be glad for any input from you people and hopefully there will be
>  an acceptable solution for this soon :) 
>  
>  Thanks!
>  
>  [1]
>  https://www.redhat.com/archives/freeipa-devel/2016-November/msg00807.html 
A few comments on
https://www.freeipa.org/page/V4/ntpd_deprecation/chronyd_support

This is mostly off the top of my head so don't take verbatim please :-)

Time is also important for 389-ds replication.

"ntpd is being deprecated in Fedora28 therefore IPA should deprecate it
as well."

nit: add space between Fedora and 28
s/should/must

Drop "On the other hand " and "a"

Under Use Cases I think I'd expand on the text a bit.

The use of the IPA time service is optional. If the infrastructure
already has access to time, either internally or via the Internet, then
the -N option can be used if desired. This will disable the IPA NTP service.

IPA by default enables a time service and this is used by clients. The
benefits of this were seen as:

- Clients and the server will be in the same stratum so should avoid
issues (even if the time is wildly off otherwise).
- For closed networks this may be the only time service available

I don't understand the statement about -N and --force-ntp. I think you
mean that for a server install -N will not configure a time service?

I'm not sure what --force-ntp is supposed to do, isn't it force-ntpd? It
is mentioned later that it will be deprecated. If ntpd isn't available
then how can one force it?

Design

Are you sure that changes made via chronyc are written to configuration
files? I didn't get that impression from the man page.

You make a mention of other platforms but there is little mention of
where this will be abstracted. There is already some abstraction for
NTP_*, is that what you are talking about? Just continuing the use of that?

Strictly speaking, Fedora is not a Red Hat product.

CLI

Table looks nice!

I don't see that ipa-server-install or ipa-replica-install have a
force-ntp option.

For -N I think it is more straightforward to say "IPA will not configure
a local time service"

--force-ntp is --force-ntpd on clients

Are any changes planned for --ntp-server?

Upgrades

I think IPA masters just need to restore the ntp files it changed on
install and disable the service. rpm -V will confirm that we got it
right except perhaps the time of the files.

I'm not sure I understand the last 2 steps. It will try to sync time and
if that fails setup chrony? What if it succeeds?

What differences will there be on client vs servers?

rob

[Florence Blanc-Renaud]

Hi,

* During client installation, the installer calls "/usr/bin/timeout ntpd 
-qgc <temp conf file>" in order to synchronize the clock with either
a/ one of the servers specified in --ntp-server
b/ a NTP server found in the DNS (_ntp._udp in the domain)
or
c/ the master

This command does not configure the NTP service but rather performs a 
one-time synchronization even if the offset is big. Did you check if 
chrony offers a similar option?

* In the design doc you mention calling a command line that will perform 
the config of chronyd but we have no information on this command line 
(which options, what does it do exactly...)

* For the upgrade, the plan is to remove ntpd service configuration. We 
should perform this only if ntp was configured by ipa-client-install (if 
the config was existing before client install and the client was 
installed with -N, then FreeIPA is not managing the time and the upgrade 
should not mess with it either).

* For the config of ntp, we were checking if chronyd was already 
configured and required --force-ntp to remove chronyd conf and configure 
ntpd instead. In the current proposal, the behavior is not identical 
because we do not offer --force-chrony. Is it on purpose?

* Test plan:
you can already add a few scenarii, like:
fresh install with -N and ntp already setup
fresh install with -N and chrony already setup
fresh install with -N and without any time conf

fresh install without any time option and ntp already setup
fresh install without any time option and chrony already setup
fresh install without any time option and without any time conf

upgrade on instance installed with -N and ntp already setup
upgrade on instance installed with -N and chrony already setup
upgrade on instance installed with -N and without any time conf

upgrade on instance installed without any time option and ntp already setup
upgrade on instance installed without any time option and chrony already 
setup
upgrade on instance installed without any time option and without any 
time conf

Flo

On 01/24/2018 04:25 PM, Tibor Dudlák via FreeIPA-devel wrote:
>  Hello FreeIPA-devel listfellow beings!
>  
>  I would like to continue the discussion started in [1], and find 
>  itssolution.
>  
>  While using the Single-Sign-on authentication provided via anMIT 
>  Kerberos KDC  there must not be any significant clock skew between 
>  server and clients so a time synchronization service is required.
>  
>  Red Hat Enterprise Linux is about to deprecate ntpd service and will 
>  support chronyd instead. This will happen in release 8 and by this time 
>  we should agree on some changes in IPA-whether to remove or replace the 
>  already used ntpd service. I would like to sum up thischange in a design 
>  page but there shouldbe an agreementfirst.
>  
>  IPA,as is,checks the system configuration and if there is anNTP service 
>  configured and running then it forces ntpd, meaning it disablesany other 
>  NTP service. It also altersits configuration, and restartsthe NTP 
>  service instance.
>  
>  We may now want to consider, as the time sync servicechange is required, 
>  to NOT configureaservice that is not a part oftheidentity management 
>  such as NTP, and leave it to system/IPA administrators.
>  
>  IPA install script may only check wheterthere is an NTP service running 
>  and if not, it wouldask the administrator to configure it before the IPA 
>  installation.
>  
>  Upgrade of IPA might be more complicated because there will be thentpd 
>  service entry in LDAP,and the service will be up and running. I would 
>  suggest that we do not remove any working ntpd service already 
>  configured but only disown it from IPA's LDAP tree.
>  
>  I will be glad for any input from you people and hopefully there will be 
>  an acceptable solution for this soon :)
>  
>  Thanks!
>  
>  [1] 
>  https://www.redhat.com/archives/freeipa-devel/2016-November/msg00807.html
>  
>  -- 
>  Tibor Dudlák
>  Identity management - FreeIPA
>  Brno, TPB-C, 2C407
>  Red Hat
>  
>  
>  _______________________________________________
>  FreeIPA-devel mailing list -- freeipa-devel(a)lists.fedorahosted.org
>  To unsubscribe send an email to freeipa-devel-leave(a)lists.fedorahosted.org
>