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
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
/->>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.
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
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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
Andrey Bychkov via FreeIPA-users wrote:
Hello, I fixed design page.
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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
On ke, 24 loka 2018, Rob Crittenden via FreeIPA-users wrote:
Andrey Bychkov via FreeIPA-users wrote:
Hello, I fixed design page.
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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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.
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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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.
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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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.
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@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@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@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.fedorahoste...
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
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.
Hello! Wouldn't it be nice to have tests for this change? What is the best way to implement them?
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Andrew Bychkov -
Andrey Bychkov
-
Rob Crittenden -
Tibor Dudlák