3:18 p.m.
A PR to support multiple NTP servers was submitted in
https://github.com/freeipa/freeipa/pull/2169
This spawned a design at
https://www.freeipa.org/page/V4/NTP_Servers_Configuration
We need to discuss the design.
rob
1:18 p.m.
Rob Crittenden via FreeIPA-users wrote:
A PR to support multiple NTP servers was submitted in
https://github.com/freeipa/freeipa/pull/2169
This spawned a design at
https://www.freeipa.org/page/V4/NTP_Servers_Configuration
I realize that this design was created from an implementation but we
need to pull that design out for discussion. I think the design could
use some improvements.
There is no description about what the abstraction layer should be. What
basic functions are there for an NTP server and how does each server map
into that abstraction? What basic methods are required?
Do all servers support the options server and pool?
How will dependencies be managed? Is there a common way to do this with
both Fedora-like and Debian-like distributions?
Is it an error if no NTP servers are installed? Is this what is meant by
"default ntp configuration"? Is that functionally equivalent to "no NTP
service is configured"?
Could there be service-specific options that would need to be passed or set?
How will this impact testing? Will all possible options need to be
tested or is spot-checking or a single server adequate?
Will backup/restore need to be extended to pick up the service-specific
files?
Upon restore there will need to be some sort of check that the required
NTP service is installed which means that the service needs to be
recorded somewhere.
rob
2:29 a.m.
/->>There is no description about what the abstraction layer should be.
What basic functions are there for an NTP server and how does each
server map into that abstraction? What basic methods are required?/
An abstract module is the parent basentpconf module, which contains the
base ntp classes for the server and the client, from which ntpdlib,
ontpdlib, and chronylib are inherited. The parent client and server
classes contain methods for configuring, synchronizing, and restoring
the initial state of the ntp server. It uses common functions from
ntpmethods. As for ntpdlib, ontpdlib, and chronylib, they contain
classes for configuring their ntp server directly, inherited from
basentpconf, and override the desired properties.
/->>Do all servers support the options server and pool?/
All the ntp servers listed here support the server and pool options, the
values of which are written to the configuration file with the
appropriate field.
/->>How will dependencies be managed? Is there a common way to do this
with both Fedora-like and Debian-like distributions?/
Each package with freeipa ntp lib contains a dependency on the ntp
server that it uses. To use freeipa ntp lib, it is enough to install a
package with an appropriate ntp server.
/->>Is it an error if no NTP servers are installed? Is this what is
meant by "default ntp configuration"? Is that functionally equivalent to
"no NTP service is configured"?/
If the system does not detect the ntp server, and the user does not use
the option '--no-ntp', then the installation of freeipa will end with
information about this. If the ntp server or ntp pool options are not
specified by the user, then the ntp server is set by default, that is,
configured on the basis of the ntp server that was laid down.
/->>Could there be service-specific options that would need to be passed
or set?/
You can set options for the ntp service such as ntp pool and ntp server.
/->>How will this impact testing? Will all possible options need to be
tested or is spot-checking or a single server adequate?/
For testing, it is necessary to start the installation of freeipa both
with the --ntp-server and --ntp-pool options, and without them, on all
supported time servers.
/->>Will backup/restore need to be extended to pick up the
service-specific files?/
For backup and restore, standard freeipa methods are used, which are
used to preserve the original state of the service and the configuration
file. After freeipa is removed, the service is restored to its original
state. To do this, freeipa ntp using the createntp.uninstall_client and
createntp.uninstall_server methods for the client and server, respectively.
/->>Upon restore there will need to be some sort of check that the
required NTP service is installed which means that the service needs to
be recorded somewhere./
If another ntp service is installed, the service will not be restored,
since the required service will not be available in the system.
9:11 a.m.
Andrey Bychkov via FreeIPA-users wrote:
/->>There is no description about what the abstraction layer
should be.
What basic functions are there for an NTP server and how does each
server map into that abstraction? What basic methods are required?/
An abstract module is the parent basentpconf module, which contains the
base ntp classes for the server and the client, from which ntpdlib,
ontpdlib, and chronylib are inherited. The parent client and server
classes contain methods for configuring, synchronizing, and restoring
the initial state of the ntp server. It uses common functions from
ntpmethods. As for ntpdlib, ontpdlib, and chronylib, they contain
classes for configuring their ntp server directly, inherited from
basentpconf, and override the desired properties.
Right, so I realize we sort of backed into this Design document from a
PR. The purpose of the design review is to hash things out before they
are implemented so I'm commenting only on what is in the doc and not in
the PR. There are no details of this abstraction in the design.
/->>Do all servers support the options server and pool?/
All the ntp servers listed here support the server and pool options, the
values of which are written to the configuration file with the
appropriate field.
Ok cool.
/->>How will dependencies be managed? Is there a common way to do this
with both Fedora-like and Debian-like distributions?/
Each package with freeipa ntp lib contains a dependency on the ntp
server that it uses. To use freeipa ntp lib, it is enough to install a
package with an appropriate ntp server.
Right but using what mechanism? rpm has this weak dependencies thing
which I haven't had a chance to look at (and I don't know about other
distros). How is the appropriate time package going to be installed? Are
we relying on the end-user to install the time package they want, so if
they install none then there is no time sync?
/->>Is it an error if no NTP servers are installed? Is this
what is
meant by "default ntp configuration"? Is that functionally equivalent to
"no NTP service is configured"?/
If the system does not detect the ntp server, and the user does not use
the option '--no-ntp', then the installation of freeipa will end with
information about this. If the ntp server or ntp pool options are not
specified by the user, then the ntp server is set by default, that is,
configured on the basis of the ntp server that was laid down.
Ok, this is a change in current behavior. Right now just a warning is
displayed if there is no NTP server found.
/->>Could there be service-specific options that would need to be passed
or set?/
You can set options for the ntp service such as ntp pool and ntp server.
But there is no feature that one server provides that others don't, for
example? It's fine to limit it to only pools and servers, I'm just
trying to anticipate future RFEs.
/->>How will this impact testing? Will all possible options
need to be
tested or is spot-checking or a single server adequate?/
For testing, it is necessary to start the installation of freeipa both
with the --ntp-server and --ntp-pool options, and without them, on all
supported time servers.
What I mean is there will be say 3 NTP servers supported. Do all three
need to be tested or is it sufficient to test the abstraction?
/->>Will backup/restore need to be extended to pick up the
service-specific files?/
For backup and restore, standard freeipa methods are used, which are
used to preserve the original state of the service and the configuration
file. After freeipa is removed, the service is restored to its original
state. To do this, freeipa ntp using the createntp.uninstall_client and
createntp.uninstall_server methods for the client and server, respectively.
Yes but configuration files need to be baked in, for example. They don't
all share the same config file.
/->>Upon restore there will need to be some sort of check that
the
required NTP service is installed which means that the service needs to
be recorded somewhere./
If another ntp service is installed, the service will not be restored,
since the required service will not be available in the system.
Right, I think this needs to be spelled out in the design.
rob
9:27 a.m.
Hello, I fixed design page.
https://www.freeipa.org/page/V4/NTP_Servers_Configuration
19.10.2018 17:11, Rob Crittenden via FreeIPA-users пишет:
Andrey Bychkov via FreeIPA-users wrote:
> /->>There is no description about what the abstraction layer should be.
> What basic functions are there for an NTP server and how does each
> server map into that abstraction? What basic methods are required?/
>
> An abstract module is the parent basentpconf module, which contains the
> base ntp classes for the server and the client, from which ntpdlib,
> ontpdlib, and chronylib are inherited. The parent client and server
> classes contain methods for configuring, synchronizing, and restoring
> the initial state of the ntp server. It uses common functions from
> ntpmethods. As for ntpdlib, ontpdlib, and chronylib, they contain
> classes for configuring their ntp server directly, inherited from
> basentpconf, and override the desired properties.
Right, so I realize we sort of backed into this Design document from a
PR. The purpose of the design review is to hash things out before they
are implemented so I'm commenting only on what is in the doc and not in
the PR. There are no details of this abstraction in the design.
> /->>Do all servers support the options server and pool?/
>
> All the ntp servers listed here support the server and pool options, the
> values of which are written to the configuration file with the
> appropriate field.
Ok cool.
> /->>How will dependencies be managed? Is there a common way to do this
> with both Fedora-like and Debian-like distributions?/
>
> Each package with freeipa ntp lib contains a dependency on the ntp
> server that it uses. To use freeipa ntp lib, it is enough to install a
> package with an appropriate ntp server.
Right but using what mechanism? rpm has this weak dependencies thing
which I haven't had a chance to look at (and I don't know about other
distros). How is the appropriate time package going to be installed? Are
we relying on the end-user to install the time package they want, so if
they install none then there is no time sync?
> /->>Is it an error if no NTP servers are installed? Is this what is
> meant by "default ntp configuration"? Is that functionally equivalent to
> "no NTP service is configured"?/
>
> If the system does not detect the ntp server, and the user does not use
> the option '--no-ntp', then the installation of freeipa will end with
> information about this. If the ntp server or ntp pool options are not
> specified by the user, then the ntp server is set by default, that is,
> configured on the basis of the ntp server that was laid down.
Ok, this is a change in current behavior. Right now just a warning is
displayed if there is no NTP server found.
> /->>Could there be service-specific options that would need to be passed
> or set?/
>
> You can set options for the ntp service such as ntp pool and ntp server.
But there is no feature that one server provides that others don't, for
example? It's fine to limit it to only pools and servers, I'm just
trying to anticipate future RFEs.
> /->>How will this impact testing? Will all possible options need to be
> tested or is spot-checking or a single server adequate?/
>
> For testing, it is necessary to start the installation of freeipa both
> with the --ntp-server and --ntp-pool options, and without them, on all
> supported time servers.
What I mean is there will be say 3 NTP servers supported. Do all three
need to be tested or is it sufficient to test the abstraction?
> /->>Will backup/restore need to be extended to pick up the
> service-specific files?/
>
> For backup and restore, standard freeipa methods are used, which are
> used to preserve the original state of the service and the configuration
> file. After freeipa is removed, the service is restored to its original
> state. To do this, freeipa ntp using the createntp.uninstall_client and
> createntp.uninstall_server methods for the client and server, respectively.
Yes but configuration files need to be baked in, for example. They don't
all share the same config file.
> /->>Upon restore there will need to be some sort of check that the
> required NTP service is installed which means that the service needs to
> be recorded somewhere./
>
> If another ntp service is installed, the service will not be restored,
> since the required service will not be available in the system.
Right, I think this needs to be spelled out in the design.
rob
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
3:47 p.m.
Andrey Bychkov via FreeIPA-users wrote:
Hello, I fixed design page.
https://www.freeipa.org/page/V4/NTP_Servers_Configuration
Tibor, do you have any input on this?
As I read this it will be up to the end-user to install their favorite
NTP client package, right? Otherwise installation is going to fail if
none of the supported NTP client packages are installed? Similar to how
DNS is detected?
With 4.7.0 we just got out of the business of running an NTP server on
an IPA master. Is it necessary to add that back?
rob
19.10.2018 17:11, Rob Crittenden via FreeIPA-users пишет:
> Andrey Bychkov via FreeIPA-users wrote:
>> /->>There is no description about what the abstraction layer should be.
>> What basic functions are there for an NTP server and how does each
>> server map into that abstraction? What basic methods are required?/
>>
>> An abstract module is the parent basentpconf module, which contains the
>> base ntp classes for the server and the client, from which ntpdlib,
>> ontpdlib, and chronylib are inherited. The parent client and server
>> classes contain methods for configuring, synchronizing, and restoring
>> the initial state of the ntp server. It uses common functions from
>> ntpmethods. As for ntpdlib, ontpdlib, and chronylib, they contain
>> classes for configuring their ntp server directly, inherited from
>> basentpconf, and override the desired properties.
> Right, so I realize we sort of backed into this Design document from a
> PR. The purpose of the design review is to hash things out before they
> are implemented so I'm commenting only on what is in the doc and not in
> the PR. There are no details of this abstraction in the design.
>
>> /->>Do all servers support the options server and pool?/
>>
>> All the ntp servers listed here support the server and pool options, the
>> values of which are written to the configuration file with the
>> appropriate field.
> Ok cool.
>
>> /->>How will dependencies be managed? Is there a common way to do this
>> with both Fedora-like and Debian-like distributions?/
>>
>> Each package with freeipa ntp lib contains a dependency on the ntp
>> server that it uses. To use freeipa ntp lib, it is enough to install a
>> package with an appropriate ntp server.
> Right but using what mechanism? rpm has this weak dependencies thing
> which I haven't had a chance to look at (and I don't know about other
> distros). How is the appropriate time package going to be installed? Are
> we relying on the end-user to install the time package they want, so if
> they install none then there is no time sync?
>
>> /->>Is it an error if no NTP servers are installed? Is this what is
>> meant by "default ntp configuration"? Is that functionally equivalent
to
>> "no NTP service is configured"?/
>>
>> If the system does not detect the ntp server, and the user does not use
>> the option '--no-ntp', then the installation of freeipa will end with
>> information about this. If the ntp server or ntp pool options are not
>> specified by the user, then the ntp server is set by default, that is,
>> configured on the basis of the ntp server that was laid down.
> Ok, this is a change in current behavior. Right now just a warning is
> displayed if there is no NTP server found.
>
>> /->>Could there be service-specific options that would need to be passed
>> or set?/
>>
>> You can set options for the ntp service such as ntp pool and ntp server.
> But there is no feature that one server provides that others don't, for
> example? It's fine to limit it to only pools and servers, I'm just
> trying to anticipate future RFEs.
>
>> /->>How will this impact testing? Will all possible options need to be
>> tested or is spot-checking or a single server adequate?/
>>
>> For testing, it is necessary to start the installation of freeipa both
>> with the --ntp-server and --ntp-pool options, and without them, on all
>> supported time servers.
> What I mean is there will be say 3 NTP servers supported. Do all three
> need to be tested or is it sufficient to test the abstraction?
>
>> /->>Will backup/restore need to be extended to pick up the
>> service-specific files?/
>>
>> For backup and restore, standard freeipa methods are used, which are
>> used to preserve the original state of the service and the configuration
>> file. After freeipa is removed, the service is restored to its original
>> state. To do this, freeipa ntp using the createntp.uninstall_client and
>> createntp.uninstall_server methods for the client and server, respectively.
> Yes but configuration files need to be baked in, for example. They don't
> all share the same config file.
>
>> /->>Upon restore there will need to be some sort of check that the
>> required NTP service is installed which means that the service needs to
>> be recorded somewhere./
>>
>> If another ntp service is installed, the service will not be restored,
>> since the required service will not be available in the system.
> Right, I think this needs to be spelled out in the design.
>
> rob
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
1:06 a.m.
On ke, 24 loka 2018, Rob Crittenden via FreeIPA-users wrote:
Andrey Bychkov via FreeIPA-users wrote:
> Hello, I fixed design page.
>
> https://www.freeipa.org/page/V4/NTP_Servers_Configuration
Tibor, do you have any input on this?
As I read this it will be up to the end-user to install their favorite
NTP client package, right? Otherwise installation is going to fail if
none of the supported NTP client packages are installed? Similar to how
DNS is detected?
With 4.7.0 we just got out of the business of running an NTP server on
an IPA master. Is it necessary to add that back?
My five cents on it: I think
Andrey's proposal is to make it fully
configurable and it is implemented already, so why not to enable that.
The only missing part (correct me if I wrong) is to have a choice to
completely disable options for NTP server on the master at a platform
level so that we can continue shipping this default in
Fedora/RHEL/CentOS.
Packagers per platform could decide whether to have NTP server support
enabled or not. And if it would be enabled, they would need to make
dependencies right in their packages.
For those who want to override this, it could be achieved with
/etc/ipa/installer.conf (this is the context used by ipa-server-install
and ipa-replica-install). It is initialized way after options parsed but
I guess we could live with that since NTP server installation could be
done after a bootstrap and force changes to options.
If admins chose to override the platform decision with
/etc/ipa/installer.conf, they would be responsible for providing all required
packages themselves. This could be written in the man pages for
ipa-server-install and ipa-replica-install.
rob
>
>
> 19.10.2018 17:11, Rob Crittenden via FreeIPA-users пишет:
>> Andrey Bychkov via FreeIPA-users wrote:
>>> /->>There is no description about what the abstraction layer should
be.
>>> What basic functions are there for an NTP server and how does each
>>> server map into that abstraction? What basic methods are required?/
>>>
>>> An abstract module is the parent basentpconf module, which contains the
>>> base ntp classes for the server and the client, from which ntpdlib,
>>> ontpdlib, and chronylib are inherited. The parent client and server
>>> classes contain methods for configuring, synchronizing, and restoring
>>> the initial state of the ntp server. It uses common functions from
>>> ntpmethods. As for ntpdlib, ontpdlib, and chronylib, they contain
>>> classes for configuring their ntp server directly, inherited from
>>> basentpconf, and override the desired properties.
>> Right, so I realize we sort of backed into this Design document from a
>> PR. The purpose of the design review is to hash things out before they
>> are implemented so I'm commenting only on what is in the doc and not in
>> the PR. There are no details of this abstraction in the design.
>>
>>> /->>Do all servers support the options server and pool?/
>>>
>>> All the ntp servers listed here support the server and pool options, the
>>> values of which are written to the configuration file with the
>>> appropriate field.
>> Ok cool.
>>
>>> /->>How will dependencies be managed? Is there a common way to do this
>>> with both Fedora-like and Debian-like distributions?/
>>>
>>> Each package with freeipa ntp lib contains a dependency on the ntp
>>> server that it uses. To use freeipa ntp lib, it is enough to install a
>>> package with an appropriate ntp server.
>> Right but using what mechanism? rpm has this weak dependencies thing
>> which I haven't had a chance to look at (and I don't know about other
>> distros). How is the appropriate time package going to be installed? Are
>> we relying on the end-user to install the time package they want, so if
>> they install none then there is no time sync?
>>
>>> /->>Is it an error if no NTP servers are installed? Is this what is
>>> meant by "default ntp configuration"? Is that functionally
equivalent to
>>> "no NTP service is configured"?/
>>>
>>> If the system does not detect the ntp server, and the user does not use
>>> the option '--no-ntp', then the installation of freeipa will end
with
>>> information about this. If the ntp server or ntp pool options are not
>>> specified by the user, then the ntp server is set by default, that is,
>>> configured on the basis of the ntp server that was laid down.
>> Ok, this is a change in current behavior. Right now just a warning is
>> displayed if there is no NTP server found.
>>
>>> /->>Could there be service-specific options that would need to be
passed
>>> or set?/
>>>
>>> You can set options for the ntp service such as ntp pool and ntp server.
>> But there is no feature that one server provides that others don't, for
>> example? It's fine to limit it to only pools and servers, I'm just
>> trying to anticipate future RFEs.
>>
>>> /->>How will this impact testing? Will all possible options need to be
>>> tested or is spot-checking or a single server adequate?/
>>>
>>> For testing, it is necessary to start the installation of freeipa both
>>> with the --ntp-server and --ntp-pool options, and without them, on all
>>> supported time servers.
>> What I mean is there will be say 3 NTP servers supported. Do all three
>> need to be tested or is it sufficient to test the abstraction?
>>
>>> /->>Will backup/restore need to be extended to pick up the
>>> service-specific files?/
>>>
>>> For backup and restore, standard freeipa methods are used, which are
>>> used to preserve the original state of the service and the configuration
>>> file. After freeipa is removed, the service is restored to its original
>>> state. To do this, freeipa ntp using the createntp.uninstall_client and
>>> createntp.uninstall_server methods for the client and server, respectively.
>> Yes but configuration files need to be baked in, for example. They don't
>> all share the same config file.
>>
>>> /->>Upon restore there will need to be some sort of check that the
>>> required NTP service is installed which means that the service needs to
>>> be recorded somewhere./
>>>
>>> If another ntp service is installed, the service will not be restored,
>>> since the required service will not be available in the system.
>> Right, I think this needs to be spelled out in the design.
>>
>> rob
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
7:13 a.m.
Alexander Bokovoy wrote:
On ke, 24 loka 2018, Rob Crittenden via FreeIPA-users wrote:
> Andrey Bychkov via FreeIPA-users wrote:
>> Hello, I fixed design page.
>>
>> https://www.freeipa.org/page/V4/NTP_Servers_Configuration
>
> Tibor, do you have any input on this?
>
> As I read this it will be up to the end-user to install their favorite
> NTP client package, right? Otherwise installation is going to fail if
> none of the supported NTP client packages are installed? Similar to how
> DNS is detected?
>
> With 4.7.0 we just got out of the business of running an NTP server on
> an IPA master. Is it necessary to add that back?
My five cents on it: I think Andrey's proposal is to make it fully
configurable and it is implemented already, so why not to enable that.
It is implemented but there are a bunch of holes in it so rather than
picking it apart in a PR I asked that this quite major change in time
handling go through our standard process.
The only missing part (correct me if I wrong) is to have a choice to
completely disable options for NTP server on the master at a platform
level so that we can continue shipping this default in
Fedora/RHEL/CentOS.
IMHO there is still too much hand waving around what packages must be
installed, how available packages are detected, etc.
Packagers per platform could decide whether to have NTP server
support
enabled or not. And if it would be enabled, they would need to make
dependencies right in their packages.
Right, he needs to say that in his design so it can be handled somewhere.
There also needs to be some sort of ordering so that one package is
preferred over another, or if some are disallowed for some reason.
It also needs to be decided if NO client is allowed (the equivalent of -N).
I'm not necessarily weighing in on the final answers, just trying to get
the design into shape so these things are considered and not forgotten
once folks start digging into specific code changes.
For those who want to override this, it could be achieved with
/etc/ipa/installer.conf (this is the context used by ipa-server-install
and ipa-replica-install). It is initialized way after options parsed but
I guess we could live with that since NTP server installation could be
done after a bootstrap and force changes to options.
If admins chose to override the platform decision with
/etc/ipa/installer.conf, they would be responsible for providing all
required
packages themselves. This could be written in the man pages for
ipa-server-install and ipa-replica-install.
>
> rob
>
>>
>>
>> 19.10.2018 17:11, Rob Crittenden via FreeIPA-users пишет:
>>> Andrey Bychkov via FreeIPA-users wrote:
>>>> /->>There is no description about what the abstraction layer
should
>>>> be.
>>>> What basic functions are there for an NTP server and how does each
>>>> server map into that abstraction? What basic methods are required?/
>>>>
>>>> An abstract module is the parent basentpconf module, which contains
>>>> the
>>>> base ntp classes for the server and the client, from which ntpdlib,
>>>> ontpdlib, and chronylib are inherited. The parent client and server
>>>> classes contain methods for configuring, synchronizing, and restoring
>>>> the initial state of the ntp server. It uses common functions from
>>>> ntpmethods. As for ntpdlib, ontpdlib, and chronylib, they contain
>>>> classes for configuring their ntp server directly, inherited from
>>>> basentpconf, and override the desired properties.
>>> Right, so I realize we sort of backed into this Design document from a
>>> PR. The purpose of the design review is to hash things out before they
>>> are implemented so I'm commenting only on what is in the doc and not in
>>> the PR. There are no details of this abstraction in the design.
>>>
>>>> /->>Do all servers support the options server and pool?/
>>>>
>>>> All the ntp servers listed here support the server and pool
>>>> options, the
>>>> values of which are written to the configuration file with the
>>>> appropriate field.
>>> Ok cool.
>>>
>>>> /->>How will dependencies be managed? Is there a common way to do
this
>>>> with both Fedora-like and Debian-like distributions?/
>>>>
>>>> Each package with freeipa ntp lib contains a dependency on the ntp
>>>> server that it uses. To use freeipa ntp lib, it is enough to install a
>>>> package with an appropriate ntp server.
>>> Right but using what mechanism? rpm has this weak dependencies thing
>>> which I haven't had a chance to look at (and I don't know about
other
>>> distros). How is the appropriate time package going to be installed?
>>> Are
>>> we relying on the end-user to install the time package they want, so if
>>> they install none then there is no time sync?
>>>
>>>> /->>Is it an error if no NTP servers are installed? Is this what
is
>>>> meant by "default ntp configuration"? Is that functionally
>>>> equivalent to
>>>> "no NTP service is configured"?/
>>>>
>>>> If the system does not detect the ntp server, and the user does not
>>>> use
>>>> the option '--no-ntp', then the installation of freeipa will end
with
>>>> information about this. If the ntp server or ntp pool options are not
>>>> specified by the user, then the ntp server is set by default, that is,
>>>> configured on the basis of the ntp server that was laid down.
>>> Ok, this is a change in current behavior. Right now just a warning is
>>> displayed if there is no NTP server found.
>>>
>>>> /->>Could there be service-specific options that would need to be
>>>> passed
>>>> or set?/
>>>>
>>>> You can set options for the ntp service such as ntp pool and ntp
>>>> server.
>>> But there is no feature that one server provides that others don't, for
>>> example? It's fine to limit it to only pools and servers, I'm just
>>> trying to anticipate future RFEs.
>>>
>>>> /->>How will this impact testing? Will all possible options need to
be
>>>> tested or is spot-checking or a single server adequate?/
>>>>
>>>> For testing, it is necessary to start the installation of freeipa both
>>>> with the --ntp-server and --ntp-pool options, and without them, on all
>>>> supported time servers.
>>> What I mean is there will be say 3 NTP servers supported. Do all three
>>> need to be tested or is it sufficient to test the abstraction?
>>>
>>>> /->>Will backup/restore need to be extended to pick up the
>>>> service-specific files?/
>>>>
>>>> For backup and restore, standard freeipa methods are used, which are
>>>> used to preserve the original state of the service and the
>>>> configuration
>>>> file. After freeipa is removed, the service is restored to its
>>>> original
>>>> state. To do this, freeipa ntp using the createntp.uninstall_client
>>>> and
>>>> createntp.uninstall_server methods for the client and server,
>>>> respectively.
>>> Yes but configuration files need to be baked in, for example. They
>>> don't
>>> all share the same config file.
>>>
>>>> /->>Upon restore there will need to be some sort of check that the
>>>> required NTP service is installed which means that the service
>>>> needs to
>>>> be recorded somewhere./
>>>>
>>>> If another ntp service is installed, the service will not be restored,
>>>> since the required service will not be available in the system.
>>> Right, I think this needs to be spelled out in the design.
>>>
>>> rob
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> freeipa-users-leave(a)lists.fedorahosted.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>
>>
>>
>>
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>
>>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
7:24 a.m.
On to, 25 loka 2018, Rob Crittenden wrote:
Alexander Bokovoy wrote:
> On ke, 24 loka 2018, Rob Crittenden via FreeIPA-users wrote:
>> Andrey Bychkov via FreeIPA-users wrote:
>>> Hello, I fixed design page.
>>>
>>> https://www.freeipa.org/page/V4/NTP_Servers_Configuration
>>
>> Tibor, do you have any input on this?
>>
>> As I read this it will be up to the end-user to install their favorite
>> NTP client package, right? Otherwise installation is going to fail if
>> none of the supported NTP client packages are installed? Similar to how
>> DNS is detected?
>>
>> With 4.7.0 we just got out of the business of running an NTP server on
>> an IPA master. Is it necessary to add that back?
> My five cents on it: I think Andrey's proposal is to make it fully
> configurable and it is implemented already, so why not to enable that.
It is implemented but there are a bunch of holes in it so rather than
picking it apart in a PR I asked that this quite major change in time
handling go through our standard process.
> The only missing part (correct me if I wrong) is to have a choice to
> completely disable options for NTP server on the master at a platform
> level so that we can continue shipping this default in
> Fedora/RHEL/CentOS.
IMHO there is still too much hand waving around what packages must be
installed, how available packages are detected, etc.
> Packagers per platform could decide whether to have NTP server support
> enabled or not. And if it would be enabled, they would need to make
> dependencies right in their packages.
Right, he needs to say that in his design so it can be handled somewhere.
There also needs to be some sort of ordering so that one package is
preferred over another, or if some are disallowed for some reason.
It also needs to be decided if NO client is allowed (the equivalent of -N).
I'm not necessarily weighing in on the final answers, just trying to get
the design into shape so these things are considered and not forgotten
once folks start digging into specific code changes.
Yep. All good comments.
Andrey, could you please address them in the design page?
> For those who want to override this, it could be achieved with
> /etc/ipa/installer.conf (this is the context used by ipa-server-install
> and ipa-replica-install). It is initialized way after options parsed but
> I guess we could live with that since NTP server installation could be
> done after a bootstrap and force changes to options.
>
> If admins chose to override the platform decision with
> /etc/ipa/installer.conf, they would be responsible for providing all
> required
> packages themselves. This could be written in the man pages for
> ipa-server-install and ipa-replica-install.
>
>
>>
>> rob
>>
>>>
>>>
>>> 19.10.2018 17:11, Rob Crittenden via FreeIPA-users пишет:
>>>> Andrey Bychkov via FreeIPA-users wrote:
>>>>> /->>There is no description about what the abstraction layer
should
>>>>> be.
>>>>> What basic functions are there for an NTP server and how does each
>>>>> server map into that abstraction? What basic methods are required?/
>>>>>
>>>>> An abstract module is the parent basentpconf module, which contains
>>>>> the
>>>>> base ntp classes for the server and the client, from which ntpdlib,
>>>>> ontpdlib, and chronylib are inherited. The parent client and server
>>>>> classes contain methods for configuring, synchronizing, and
restoring
>>>>> the initial state of the ntp server. It uses common functions from
>>>>> ntpmethods. As for ntpdlib, ontpdlib, and chronylib, they contain
>>>>> classes for configuring their ntp server directly, inherited from
>>>>> basentpconf, and override the desired properties.
>>>> Right, so I realize we sort of backed into this Design document from a
>>>> PR. The purpose of the design review is to hash things out before they
>>>> are implemented so I'm commenting only on what is in the doc and not
in
>>>> the PR. There are no details of this abstraction in the design.
>>>>
>>>>> /->>Do all servers support the options server and pool?/
>>>>>
>>>>> All the ntp servers listed here support the server and pool
>>>>> options, the
>>>>> values of which are written to the configuration file with the
>>>>> appropriate field.
>>>> Ok cool.
>>>>
>>>>> /->>How will dependencies be managed? Is there a common way to
do this
>>>>> with both Fedora-like and Debian-like distributions?/
>>>>>
>>>>> Each package with freeipa ntp lib contains a dependency on the ntp
>>>>> server that it uses. To use freeipa ntp lib, it is enough to install
a
>>>>> package with an appropriate ntp server.
>>>> Right but using what mechanism? rpm has this weak dependencies thing
>>>> which I haven't had a chance to look at (and I don't know about
other
>>>> distros). How is the appropriate time package going to be installed?
>>>> Are
>>>> we relying on the end-user to install the time package they want, so if
>>>> they install none then there is no time sync?
>>>>
>>>>> /->>Is it an error if no NTP servers are installed? Is this
what is
>>>>> meant by "default ntp configuration"? Is that functionally
>>>>> equivalent to
>>>>> "no NTP service is configured"?/
>>>>>
>>>>> If the system does not detect the ntp server, and the user does not
>>>>> use
>>>>> the option '--no-ntp', then the installation of freeipa will
end with
>>>>> information about this. If the ntp server or ntp pool options are
not
>>>>> specified by the user, then the ntp server is set by default, that
is,
>>>>> configured on the basis of the ntp server that was laid down.
>>>> Ok, this is a change in current behavior. Right now just a warning is
>>>> displayed if there is no NTP server found.
>>>>
>>>>> /->>Could there be service-specific options that would need to
be
>>>>> passed
>>>>> or set?/
>>>>>
>>>>> You can set options for the ntp service such as ntp pool and ntp
>>>>> server.
>>>> But there is no feature that one server provides that others don't,
for
>>>> example? It's fine to limit it to only pools and servers, I'm
just
>>>> trying to anticipate future RFEs.
>>>>
>>>>> /->>How will this impact testing? Will all possible options
need to be
>>>>> tested or is spot-checking or a single server adequate?/
>>>>>
>>>>> For testing, it is necessary to start the installation of freeipa
both
>>>>> with the --ntp-server and --ntp-pool options, and without them, on
all
>>>>> supported time servers.
>>>> What I mean is there will be say 3 NTP servers supported. Do all three
>>>> need to be tested or is it sufficient to test the abstraction?
>>>>
>>>>> /->>Will backup/restore need to be extended to pick up the
>>>>> service-specific files?/
>>>>>
>>>>> For backup and restore, standard freeipa methods are used, which are
>>>>> used to preserve the original state of the service and the
>>>>> configuration
>>>>> file. After freeipa is removed, the service is restored to its
>>>>> original
>>>>> state. To do this, freeipa ntp using the createntp.uninstall_client
>>>>> and
>>>>> createntp.uninstall_server methods for the client and server,
>>>>> respectively.
>>>> Yes but configuration files need to be baked in, for example. They
>>>> don't
>>>> all share the same config file.
>>>>
>>>>> /->>Upon restore there will need to be some sort of check that
the
>>>>> required NTP service is installed which means that the service
>>>>> needs to
>>>>> be recorded somewhere./
>>>>>
>>>>> If another ntp service is installed, the service will not be
restored,
>>>>> since the required service will not be available in the system.
>>>> Right, I think this needs to be spelled out in the design.
>>>>
>>>> rob
>>>> _______________________________________________
>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>> To unsubscribe send an email to
>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>> List Archives:
>>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to
>>> freeipa-users-leave(a)lists.fedorahosted.org
>>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives:
>>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>
>>>
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to
>> freeipa-users-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives:
>>
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>
>
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
3:09 a.m.
I offer two packages for configuring ntp service. One for IPA server and
next for IPA client. Each package contains all supported ipa ntp modules
for the server and client, respectively. These packages do not dependen
on specific ntp services, so their installation will be successful. The
only condition for installation is the presence of IPA server or IPA
client in the system. If the system does not have any ntp services, the
user can add the option "-N" and all settings associated with time
synchronization will be ignored and the installation of freeipa will
continue.
The user has to choose whether to install the package with the ipa ntp
modules or not. As you see the setting is quite flexible.
As I already wrote, the user can refuse and completely ignore the ntp
configuration using the "-N" option. The priority of choosing the ntp
service is the following: chrony, ntpd, openntpd.
Added missing parts to my design page.
3:24 a.m.
Hey Andrey,
I like it! Will jump on review ASAP.
On Mon, Oct 29, 2018 at 9:10 AM Andrey Bychkov via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
I offer two packages for configuring ntp service. One for IPA server
and
next for IPA client. Each package contains all supported ipa ntp modules
for the server and client, respectively. These packages do not dependen
on specific ntp services, so their installation will be successful. The
only condition for installation is the presence of IPA server or IPA
client in the system. If the system does not have any ntp services, the
user can add the option "-N" and all settings associated with time
synchronization will be ignored and the installation of freeipa will
continue.
The user has to choose whether to install the package with the ipa ntp
modules or not. As you see the setting is quite flexible.
As I already wrote, the user can refuse and completely ignore the ntp
configuration using the "-N" option. The priority of choosing the ntp
service is the following: chrony, ntpd, openntpd.
Added missing parts to my design page.
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
--
Tibor Dudlák
Identity management - FreeIPA
Brno, TPB-C, 2C407
Red Hat
9:45 a.m.
Andrey Bychkov via FreeIPA-users wrote:
Hello! Can I fix my PR according with discussion?
Just one final clarification.
If I read the patch and page correctly the idea is that the packager
chooses the default NTP package (if any). So if no NTP server package is
installed them no server will be configured.
If a user decides they want a different but supported NTP server they
just have to install it and it will be available for configuration.
Am I right? If so can you add this to the design page? With that you
have my +1.
thanks
rob
6:24 a.m.
Yes, you are right. Ipa ntp lib does not depend on the specific ntp
server, ipa will be configured with the ntp server that is installed in
system. If there is no ntp server in the system, or if the user does not
wish to synchronize the time, user can use the "-N" flag, ipa will be
set ignoring the settings and ntp synchronization. Also, if you wish,
you can specify a hard dependency on the specific ntp server in the
specfile at ntplib package.
12:30 a.m.
Hello! Wouldn't it be nice to have tests for this change? What is the
best way to implement them?
1928
days inactive
2031
days old
freeipa-users@lists.fedorahosted.org
15 comments
5 participants
participants (5)
-
Alexander Bokovoy -
Andrew Bychkov -
Andrey Bychkov
-
Rob Crittenden -
Tibor Dudlák