Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
Looking forward to your comments, Stanislav Láznička
Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
This makes sense to me.
I wonder if we should reflect the current CRL master in LDAP somehow, as a role perhaps. This way one could look to see whether one is assigned or not.
The downside is that this could easily get stale, for example if the CRL master server was lost in some way. But it would provide more visibility into which master is the CRL master and could be used to prevent/warn a user if they try to set multiple.
rob
On Thu, May 31, 2018 at 11:17:51AM -0400, Rob Crittenden via FreeIPA-devel wrote:
Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
This makes sense to me.
I wonder if we should reflect the current CRL master in LDAP somehow, as a role perhaps. This way one could look to see whether one is assigned or not.
The downside is that this could easily get stale, for example if the CRL master server was lost in some way. But it would provide more visibility into which master is the CRL master and could be used to prevent/warn a user if they try to set multiple.
rob
Unless Dogtag is actually configuring itself based on this hypothetical LDAP configuration, then it's still easy for the Dogtag configuration to get out of sync with what we have recorded about the CRL master.
There is a Dogtag ticket for moving CRL configuration into LDAP: https://pagure.io/dogtagpki/issue/1262. But the work has not been scheduled.
Cheers, Fraser
Fraser Tweedale via FreeIPA-devel wrote:
On Thu, May 31, 2018 at 11:17:51AM -0400, Rob Crittenden via FreeIPA-devel wrote:
Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
This makes sense to me.
I wonder if we should reflect the current CRL master in LDAP somehow, as a role perhaps. This way one could look to see whether one is assigned or not.
The downside is that this could easily get stale, for example if the CRL master server was lost in some way. But it would provide more visibility into which master is the CRL master and could be used to prevent/warn a user if they try to set multiple.
rob
Unless Dogtag is actually configuring itself based on this hypothetical LDAP configuration, then it's still easy for the Dogtag configuration to get out of sync with what we have recorded about the CRL master.
Absolutely right. I'm a bit torn if it is a good idea or not myself.
It would be a check on someone running the script on all masters though.
There is a risk of a false sense of security if no masters are generating a CRL but then again, if your masters aren't generating a CRL and you don't notice then you aren't using the CRL in the first place.
There is a Dogtag ticket for moving CRL configuration into LDAP: https://pagure.io/dogtagpki/issue/1262. But the work has not been scheduled.
Nice, good to know. Once agreed-upon this should be added to the design page on the wiki.
rob
On Thu, May 31, 2018 at 10:10:07PM -0400, Rob Crittenden via FreeIPA-devel wrote:
Fraser Tweedale via FreeIPA-devel wrote:
On Thu, May 31, 2018 at 11:17:51AM -0400, Rob Crittenden via FreeIPA-devel wrote:
Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
This makes sense to me.
I wonder if we should reflect the current CRL master in LDAP somehow, as a role perhaps. This way one could look to see whether one is assigned or not.
The downside is that this could easily get stale, for example if the CRL master server was lost in some way. But it would provide more visibility into which master is the CRL master and could be used to prevent/warn a user if they try to set multiple.
rob
Unless Dogtag is actually configuring itself based on this hypothetical LDAP configuration, then it's still easy for the Dogtag configuration to get out of sync with what we have recorded about the CRL master.
Absolutely right. I'm a bit torn if it is a good idea or not myself.
It would be a check on someone running the script on all masters though.
There is a risk of a false sense of security if no masters are generating a CRL but then again, if your masters aren't generating a CRL and you don't notice then you aren't using the CRL in the first place.
There is a Dogtag ticket for moving CRL configuration into LDAP: https://pagure.io/dogtagpki/issue/1262. But the work has not been scheduled.
Nice, good to know. Once agreed-upon this should be added to the design page on the wiki.
It's part of a broader desire to move configuration into the DB. There are several related tickets (see https://pagure.io/dogtagpki/issue/2586 for a list). If/when it happens it will probably be a big effort with collaborative design, of which the CRL configuration will just be one use case.
Cheers, Fraser
On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
Looking forward to your comments, Stanislav Láznička
-- Standa Láznička A Red Hat person PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
# CRL master reassignment draft
## Rationale
Changing the CRL master of the FreeIPA system feels complex for the users and is thus rather error prone from the experience of the support engineers.
We should provide a more automatic way of handling this process.
## Design
While FreeIPA framework offers an API to define a server role, the framework itself counts with all the necessary information to be available in the backend database. Assigning an IPA server as a CRL master requires access to the filesystem [freeipa.org:Promote CA to Renewal and CRL Master]( https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) and therefore the framework should not be used, at least not until PKI allows us to change this configuration aspect of the system based on the values stored in the database. Instead, we will use the capabilities of the `ipa-advise` tool. Creating a separate Python script would also be an option but creating a script for every possible action in IPA seems like an unfortunate decision to make as it would only generate a bunch of binaries that would be hard getting rid of when a proper solution for that certain problem appears.
## Implementation A new `ipa-advise` plugin is created - `crl_master.py`. This plugin will provide the user with a script that will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master. The script will be based on the steps in the aforementioned HOWTO page.
## FEature management - CLI | Command | Arguments | | :---: | :---: | | ipa-advise | set-crl-master |
Thanks for the design, Standa. One comment:
We already have `ipa-csreplica-manage set-renewal-master`. IMO configuring CRLs is in the same ball park, so why not make new subcommand(s), e.g.:
ipa-csreplica-manage [un]configure-crl-generation
If/when we support LDAP-based CRL configuration in Dogtag, we can enhance these subcommands to work with the new configuration system.
Regardless of where we put the behaviour, 100% agree with having a command to automate this for admins!
Cheers, Fraser
On 06/01/2018 03:08 AM, Fraser Tweedale via FreeIPA-devel wrote:
On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
Looking forward to your comments, Stanislav Láznička
-- Standa Láznička A Red Hat person PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
# CRL master reassignment draft
## Rationale
Changing the CRL master of the FreeIPA system feels complex for the users and is thus rather error prone from the experience of the support engineers.
We should provide a more automatic way of handling this process.
## Design
While FreeIPA framework offers an API to define a server role, the framework itself counts with all the necessary information to be available in the backend database. Assigning an IPA server as a CRL master requires access to the filesystem [freeipa.org:Promote CA to Renewal and CRL Master]( https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) and therefore the framework should not be used, at least not until PKI allows us to change this configuration aspect of the system based on the values stored in the database. Instead, we will use the capabilities of the `ipa-advise` tool. Creating a separate Python script would also be an option but creating a script for every possible action in IPA seems like an unfortunate decision to make as it would only generate a bunch of binaries that would be hard getting rid of when a proper solution for that certain problem appears.
## Implementation A new `ipa-advise` plugin is created - `crl_master.py`. This plugin will provide the user with a script that will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master. The script will be based on the steps in the aforementioned HOWTO page.
## FEature management - CLI | Command | Arguments | | :---: | :---: | | ipa-advise | set-crl-master |
Hi Standa,
thanks for the design.
I was thinking as Rob and Fraser about storing the CRL generation master in LDAP, and came to the following question. Currently we always configure the CA renewal and CRL generation on the same host. Does it make sense to have these 2 functions on different masters? If not, we may consider relying on the existing attribute (ipaconfigstring=caRenewalMaster).
Thanks for the design, Standa. One comment:
We already have `ipa-csreplica-manage set-renewal-master`. IMO configuring CRLs is in the same ball park, so why not make new subcommand(s), e.g.:
ipa-csreplica-manage [un]configure-crl-generation
If/when we support LDAP-based CRL configuration in Dogtag, we can enhance these subcommands to work with the new configuration system.
I do not have the whole history but I believe that a decision was made to move from ipa-csreplica-manage set-renewal-master to ipa config-mod --ca-renewal-master-server (see ticket https://pagure.io/freeipa/issue/5689), with the long term plan of completely deprecating ipa-(cs)replica-manage (https://www.freeipa.org/page/V4/Manage_replication_topology_4_4). If this plan is still valid, we should probably avoid making a new subcommand of ipa-csreplica-manage. This leaves us with either a new advise plugin or an extension of ipa config-mod.
Now concerning the new command, I'd rather have a single command that performs 1/ unconfigure CRL generation on current CRL generation master 2/ configure CRL generation on new master I think that having one subcommand for unconfigure + one subcommand for configure would create an unnecessary 2-step process with the risk of forgetting one of the steps. Moreover, if we want to enforce that only one master is configured as CRL renewal master, it is more user-friendly and less error-prone.
I would also like to see more details in the design, for instance how would the command react on failures (rollback or simply print error messages?), which checks will be performed etc...
Thanks, Flo
Regardless of where we put the behaviour, 100% agree with having a command to automate this for admins!
Cheers, Fraser _______________________________________________ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-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.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahost...
On Tue, Jun 05, 2018 at 09:51:08AM +0200, Florence Blanc-Renaud wrote:
On 06/01/2018 03:08 AM, Fraser Tweedale via FreeIPA-devel wrote:
On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
Looking forward to your comments, Stanislav Láznička
-- Standa Láznička A Red Hat person PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
# CRL master reassignment draft
## Rationale
Changing the CRL master of the FreeIPA system feels complex for the users and is thus rather error prone from the experience of the support engineers.
We should provide a more automatic way of handling this process.
## Design
While FreeIPA framework offers an API to define a server role, the framework itself counts with all the necessary information to be available in the backend database. Assigning an IPA server as a CRL master requires access to the filesystem [freeipa.org:Promote CA to Renewal and CRL Master]( https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) and therefore the framework should not be used, at least not until PKI allows us to change this configuration aspect of the system based on the values stored in the database. Instead, we will use the capabilities of the `ipa-advise` tool. Creating a separate Python script would also be an option but creating a script for every possible action in IPA seems like an unfortunate decision to make as it would only generate a bunch of binaries that would be hard getting rid of when a proper solution for that certain problem appears.
## Implementation A new `ipa-advise` plugin is created - `crl_master.py`. This plugin will provide the user with a script that will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master. The script will be based on the steps in the aforementioned HOWTO page.
## FEature management - CLI | Command | Arguments | | :---: | :---: | | ipa-advise | set-crl-master |
Hi Standa,
thanks for the design.
I was thinking as Rob and Fraser about storing the CRL generation master in LDAP, and came to the following question. Currently we always configure the CA renewal and CRL generation on the same host. Does it make sense to have these 2 functions on different masters? If not, we may consider relying on the existing attribute (ipaconfigstring=caRenewalMaster).
There is no technical reason these functions have to be the same server. There is usually no reason why they'd have to be separate servers, either. But they are separate and unrelated behaviours, so I'm wary of hanging CRL behaviour off the caRenewalMaster config.
Thanks for the design, Standa. One comment:
We already have `ipa-csreplica-manage set-renewal-master`. IMO configuring CRLs is in the same ball park, so why not make new subcommand(s), e.g.:
ipa-csreplica-manage [un]configure-crl-generation
If/when we support LDAP-based CRL configuration in Dogtag, we can enhance these subcommands to work with the new configuration system.
I do not have the whole history but I believe that a decision was made to move from ipa-csreplica-manage set-renewal-master to ipa config-mod --ca-renewal-master-server (see ticket https://pagure.io/freeipa/issue/5689), with the long term plan of completely deprecating ipa-(cs)replica-manage (https://www.freeipa.org/page/V4/Manage_replication_topology_4_4). If this plan is still valid, we should probably avoid making a new subcommand of ipa-csreplica-manage. This leaves us with either a new advise plugin or an extension of ipa config-mod.
Now concerning the new command, I'd rather have a single command that performs 1/ unconfigure CRL generation on current CRL generation master 2/ configure CRL generation on new master I think that having one subcommand for unconfigure + one subcommand for configure would create an unnecessary 2-step process with the risk of forgetting one of the steps. Moreover, if we want to enforce that only one master is configured as CRL renewal master, it is more user-friendly and less error-prone.
I would also like to see more details in the design, for instance how would the command react on failures (rollback or simply print error messages?), which checks will be performed etc...
Thanks, Flo
This hints at the long term "wishlist" item of an IPA configuration daemon that can observe changes in LDAP-based configuration and effect local configuration changes[1]. This is the ideal solution.
So whatever we do in the short term, be it enhancing ipa-csreplica-manage or whatever else, we should keep this long-term RFE in mind.
[1] https://pagure.io/freeipa/issue/5974
Thanks, Fraser
Regardless of where we put the behaviour, 100% agree with having a command to automate this for admins!
Cheers, Fraser _______________________________________________ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-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.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahost...
Thank you guys for your great comments, I was away for the past few days but you correctly understood all of the motivations of the design and shared them here. I'll add several comments throughout the mails here:
On 06/05/2018 11:02 AM, Fraser Tweedale wrote:
On Tue, Jun 05, 2018 at 09:51:08AM +0200, Florence Blanc-Renaud wrote:
On 06/01/2018 03:08 AM, Fraser Tweedale via FreeIPA-devel wrote:
On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
Looking forward to your comments, Stanislav Láznička
-- Standa Láznička A Red Hat person PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
# CRL master reassignment draft
## Rationale
Changing the CRL master of the FreeIPA system feels complex for the users and is thus rather error prone from the experience of the support engineers.
We should provide a more automatic way of handling this process.
## Design
While FreeIPA framework offers an API to define a server role, the framework itself counts with all the necessary information to be available in the backend database. Assigning an IPA server as a CRL master requires access to the filesystem [freeipa.org:Promote CA to Renewal and CRL Master]( https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) and therefore the framework should not be used, at least not until PKI allows us to change this configuration aspect of the system based on the values stored in the database. Instead, we will use the capabilities of the `ipa-advise` tool. Creating a separate Python script would also be an option but creating a script for every possible action in IPA seems like an unfortunate decision to make as it would only generate a bunch of binaries that would be hard getting rid of when a proper solution for that certain problem appears.
## Implementation A new `ipa-advise` plugin is created - `crl_master.py`. This plugin will provide the user with a script that will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master. The script will be based on the steps in the aforementioned HOWTO page.
## FEature management - CLI | Command | Arguments | | :---: | :---: | | ipa-advise | set-crl-master |
Hi Standa,
thanks for the design.
I was thinking as Rob and Fraser about storing the CRL generation master in LDAP, and came to the following question. Currently we always configure the CA renewal and CRL generation on the same host. Does it make sense to have these 2 functions on different masters? If not, we may consider relying on the existing attribute (ipaconfigstring=caRenewalMaster).
There is no technical reason these functions have to be the same server. There is usually no reason why they'd have to be separate servers, either. But they are separate and unrelated behaviours, so I'm wary of hanging CRL behaviour off the caRenewalMaster config.
I would really like to refrain from adding any CRL-master connected values/attributes to LDAP for now. While we're setting the CRL master along with the cert-renewal master, I believe that when the cert-renewal master is moved, we do not automatically move the CRL master functionality along with it. I would keep the behavior the same. This of course makes it a bit harder to discover what the current CRL master is (does Dogtag have an API on discovering that?) but it does not have a negative impact on the current user experience.
Thanks for the design, Standa. One comment:
We already have `ipa-csreplica-manage set-renewal-master`. IMO configuring CRLs is in the same ball park, so why not make new subcommand(s), e.g.:
ipa-csreplica-manage [un]configure-crl-generation
If/when we support LDAP-based CRL configuration in Dogtag, we can enhance these subcommands to work with the new configuration system.
I do not have the whole history but I believe that a decision was made to move from ipa-csreplica-manage set-renewal-master to ipa config-mod --ca-renewal-master-server (see ticket https://pagure.io/freeipa/issue/5689), with the long term plan of completely deprecating ipa-(cs)replica-manage (https://www.freeipa.org/page/V4/Manage_replication_topology_4_4). If this plan is still valid, we should probably avoid making a new subcommand of ipa-csreplica-manage. This leaves us with either a new advise plugin or an extension of ipa config-mod.
This was exactly my motivation not to go for ipa-csreplica-manage extensions, yes. I don't like the idea of using our framework (read `ipa config-mod`) to touch the filesystem and try to set it up somehow. It's supposed to work with the underlying database, not the master's file. That's why I am proposing an advise plugin instead.
Now concerning the new command, I'd rather have a single command that performs 1/ unconfigure CRL generation on current CRL generation master 2/ configure CRL generation on new master I think that having one subcommand for unconfigure + one subcommand for configure would create an unnecessary 2-step process with the risk of forgetting one of the steps. Moreover, if we want to enforce that only one master is configured as CRL renewal master, it is more user-friendly and less error-prone.
It should be definitely handled by just one step. It's described in the current design draft as such:
"""
...it will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master
"""
I would also like to see more details in the design, for instance how would the command react on failures (rollback or simply print error messages?), which checks will be performed etc...
Thanks, Flo
I thought such technical discussion could be held once the PR is created. Would that be acceptable or should I include speculations over the inputs and their error-handling to the design now?
This hints at the long term "wishlist" item of an IPA configuration daemon that can observe changes in LDAP-based configuration and effect local configuration changes[1]. This is the ideal solution.
So whatever we do in the short term, be it enhancing ipa-csreplica-manage or whatever else, we should keep this long-term RFE in mind.
[1] https://pagure.io/freeipa/issue/5974
Thanks, Fraser
Regardless of where we put the behaviour, 100% agree with having a command to automate this for admins!
Cheers, Fraser
On Wed, Jun 06, 2018 at 10:24:12AM +0200, Standa Laznicka wrote:
Thank you guys for your great comments, I was away for the past few days but you correctly understood all of the motivations of the design and shared them here. I'll add several comments throughout the mails here:
On 06/05/2018 11:02 AM, Fraser Tweedale wrote:
On Tue, Jun 05, 2018 at 09:51:08AM +0200, Florence Blanc-Renaud wrote:
On 06/01/2018 03:08 AM, Fraser Tweedale via FreeIPA-devel wrote:
On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
Looking forward to your comments, Stanislav Láznička
-- Standa Láznička A Red Hat person PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
# CRL master reassignment draft
## Rationale
Changing the CRL master of the FreeIPA system feels complex for the users and is thus rather error prone from the experience of the support engineers.
We should provide a more automatic way of handling this process.
## Design
While FreeIPA framework offers an API to define a server role, the framework itself counts with all the necessary information to be available in the backend database. Assigning an IPA server as a CRL master requires access to the filesystem [freeipa.org:Promote CA to Renewal and CRL Master]( https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) and therefore the framework should not be used, at least not until PKI allows us to change this configuration aspect of the system based on the values stored in the database. Instead, we will use the capabilities of the `ipa-advise` tool. Creating a separate Python script would also be an option but creating a script for every possible action in IPA seems like an unfortunate decision to make as it would only generate a bunch of binaries that would be hard getting rid of when a proper solution for that certain problem appears.
## Implementation A new `ipa-advise` plugin is created - `crl_master.py`. This plugin will provide the user with a script that will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master. The script will be based on the steps in the aforementioned HOWTO page.
## FEature management - CLI | Command | Arguments | | :---: | :---: | | ipa-advise | set-crl-master |
Hi Standa,
thanks for the design.
I was thinking as Rob and Fraser about storing the CRL generation master in LDAP, and came to the following question. Currently we always configure the CA renewal and CRL generation on the same host. Does it make sense to have these 2 functions on different masters? If not, we may consider relying on the existing attribute (ipaconfigstring=caRenewalMaster).
There is no technical reason these functions have to be the same server. There is usually no reason why they'd have to be separate servers, either. But they are separate and unrelated behaviours, so I'm wary of hanging CRL behaviour off the caRenewalMaster config.
I would really like to refrain from adding any CRL-master connected values/attributes to LDAP for now. While we're setting the CRL master along with the cert-renewal master, I believe that when the cert-renewal master is moved, we do not automatically move the CRL master functionality along with it. I would keep the behavior the same. This of course makes it a bit harder to discover what the current CRL master is (does Dogtag have an API on discovering that?) but it does not have a negative impact on the current user experience.
Dogtag does not have an API for that. You can look at CS.cfg to work out whether the server is configured to generate CRLs.
Based on the discussion, I'm fine with implementing this in ipa-advise.
Cheers, Fraser
Thanks for the design, Standa. One comment:
We already have `ipa-csreplica-manage set-renewal-master`. IMO configuring CRLs is in the same ball park, so why not make new subcommand(s), e.g.:
ipa-csreplica-manage [un]configure-crl-generation
If/when we support LDAP-based CRL configuration in Dogtag, we can enhance these subcommands to work with the new configuration system.
I do not have the whole history but I believe that a decision was made to move from ipa-csreplica-manage set-renewal-master to ipa config-mod --ca-renewal-master-server (see ticket https://pagure.io/freeipa/issue/5689), with the long term plan of completely deprecating ipa-(cs)replica-manage (https://www.freeipa.org/page/V4/Manage_replication_topology_4_4). If this plan is still valid, we should probably avoid making a new subcommand of ipa-csreplica-manage. This leaves us with either a new advise plugin or an extension of ipa config-mod.
This was exactly my motivation not to go for ipa-csreplica-manage extensions, yes. I don't like the idea of using our framework (read `ipa config-mod`) to touch the filesystem and try to set it up somehow. It's supposed to work with the underlying database, not the master's file. That's why I am proposing an advise plugin instead.
Now concerning the new command, I'd rather have a single command that performs 1/ unconfigure CRL generation on current CRL generation master 2/ configure CRL generation on new master I think that having one subcommand for unconfigure + one subcommand for configure would create an unnecessary 2-step process with the risk of forgetting one of the steps. Moreover, if we want to enforce that only one master is configured as CRL renewal master, it is more user-friendly and less error-prone.
It should be definitely handled by just one step. It's described in the current design draft as such:
"""
...it will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master
"""
I would also like to see more details in the design, for instance how would the command react on failures (rollback or simply print error messages?), which checks will be performed etc...
Thanks, Flo
I thought such technical discussion could be held once the PR is created. Would that be acceptable or should I include speculations over the inputs and their error-handling to the design now?
This hints at the long term "wishlist" item of an IPA configuration daemon that can observe changes in LDAP-based configuration and effect local configuration changes[1]. This is the ideal solution.
So whatever we do in the short term, be it enhancing ipa-csreplica-manage or whatever else, we should keep this long-term RFE in mind.
[1] https://pagure.io/freeipa/issue/5974
Thanks, Fraser
Regardless of where we put the behaviour, 100% agree with having a command to automate this for admins!
Cheers, Fraser
-- Standa Láznička A Red Hat person PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
On 06/06/2018 10:24 AM, Standa Laznicka via FreeIPA-devel wrote:
Thank you guys for your great comments, I was away for the past few days but you correctly understood all of the motivations of the design and shared them here. I'll add several comments throughout the mails here:
On 06/05/2018 11:02 AM, Fraser Tweedale wrote:
On Tue, Jun 05, 2018 at 09:51:08AM +0200, Florence Blanc-Renaud wrote:
On 06/01/2018 03:08 AM, Fraser Tweedale via FreeIPA-devel wrote:
On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
Looking forward to your comments, Stanislav Láznička
-- Standa Láznička A Red Hat person PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
# CRL master reassignment draft
## Rationale
Changing the CRL master of the FreeIPA system feels complex for the users and is thus rather error prone from the experience of the support engineers.
We should provide a more automatic way of handling this process.
## Design
While FreeIPA framework offers an API to define a server role, the framework itself counts with all the necessary information to be available in the backend database. Assigning an IPA server as a CRL master requires access to the filesystem [freeipa.org:Promote CA to Renewal and CRL Master]( https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) and therefore the framework should not be used, at least not until PKI allows us to change this configuration aspect of the system based on the values stored in the database. Instead, we will use the capabilities of the `ipa-advise` tool. Creating a separate Python script would also be an option but creating a script for every possible action in IPA seems like an unfortunate decision to make as it would only generate a bunch of binaries that would be hard getting rid of when a proper solution for that certain problem appears.
## Implementation A new `ipa-advise` plugin is created - `crl_master.py`. This plugin will provide the user with a script that will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master. The script will be based on the steps in the aforementioned HOWTO page.
## FEature management - CLI | Command | Arguments | | :---: | :---: | | ipa-advise | set-crl-master |
Hi Standa,
thanks for the design.
I was thinking as Rob and Fraser about storing the CRL generation master in LDAP, and came to the following question. Currently we always configure the CA renewal and CRL generation on the same host. Does it make sense to have these 2 functions on different masters? If not, we may consider relying on the existing attribute (ipaconfigstring=caRenewalMaster).
There is no technical reason these functions have to be the same server. There is usually no reason why they'd have to be separate servers, either. But they are separate and unrelated behaviours, so I'm wary of hanging CRL behaviour off the caRenewalMaster config.
I would really like to refrain from adding any CRL-master connected values/attributes to LDAP for now. While we're setting the CRL master along with the cert-renewal master, I believe that when the cert-renewal master is moved, we do not automatically move the CRL master functionality along with it. I would keep the behavior the same. This of course makes it a bit harder to discover what the current CRL master is (does Dogtag have an API on discovering that?) but it does not have a negative impact on the current user experience.
Ok for me, we can keep CRL generation and CA renewal as 2 distinct functionalities not necessarily co-located.
Thanks for the design, Standa. One comment:
We already have `ipa-csreplica-manage set-renewal-master`. IMO configuring CRLs is in the same ball park, so why not make new subcommand(s), e.g.:
ipa-csreplica-manage [un]configure-crl-generationIf/when we support LDAP-based CRL configuration in Dogtag, we can enhance these subcommands to work with the new configuration system.
I do not have the whole history but I believe that a decision was made to move from ipa-csreplica-manage set-renewal-master to ipa config-mod --ca-renewal-master-server (see ticket https://pagure.io/freeipa/issue/5689), with the long term plan of completely deprecating ipa-(cs)replica-manage (https://www.freeipa.org/page/V4/Manage_replication_topology_4_4). If this plan is still valid, we should probably avoid making a new subcommand of ipa-csreplica-manage. This leaves us with either a new advise plugin or an extension of ipa config-mod.
This was exactly my motivation not to go for ipa-csreplica-manage extensions, yes. I don't like the idea of using our framework (read `ipa config-mod`) to touch the filesystem and try to set it up somehow. It's supposed to work with the underlying database, not the master's file. That's why I am proposing an advise plugin instead.
Ok for me, too.
Now concerning the new command, I'd rather have a single command that performs 1/ unconfigure CRL generation on current CRL generation master 2/ configure CRL generation on new master I think that having one subcommand for unconfigure + one subcommand for configure would create an unnecessary 2-step process with the risk of forgetting one of the steps. Moreover, if we want to enforce that only one master is configured as CRL renewal master, it is more user-friendly and less error-prone.
It should be definitely handled by just one step. It's described in the current design draft as such:
"""
...it will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master
"""
Sure, your description was clear and I was mainly reacting to Fraser's proposal ipa-csreplica-manage [un]configure-crl-generation
I would also like to see more details in the design, for instance how would the command react on failures (rollback or simply print error messages?), which checks will be performed etc...
Thanks, Flo
I thought such technical discussion could be held once the PR is created. Would that be acceptable or should I include speculations over the inputs and their error-handling to the design now?
In general I agree that the PR is the right place to discuss specific details but I'm rather thinking of the overall behavior here. IMHO the most difficult part is often agreeing on the expectations and trying to foresee potential issues.
For instance ipa-advise will produce a script but what will be the script's arguments? Can the script be run by non-root? The script will perform local operations as well as remote operations, if one part succeeds but the other one fails will it rollback? For me it's easier to discuss these points as items in a design rather than code lines in a PR, but that's a personal preference. I completely understand if you prefer discussing in the PR.
Flo
This hints at the long term "wishlist" item of an IPA configuration daemon that can observe changes in LDAP-based configuration and effect local configuration changes[1]. This is the ideal solution.
So whatever we do in the short term, be it enhancing ipa-csreplica-manage or whatever else, we should keep this long-term RFE in mind.
[1] https://pagure.io/freeipa/issue/5974
Thanks, Fraser
Regardless of where we put the behaviour, 100% agree with having a command to automate this for admins!
Cheers, Fraser
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-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.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahost...
Flo, thank you for your invaluable comments.
I originally did not notice that there was a design draft page for this feature already. Since we all seem to be in agreement about the design I proposed, I updated the original page and the design can now be found at https://www.freeipa.org/page/V4/Promotion_to_CRL_generation_master
I expanded on the generated script requirements (some of them - I believe the most important - were already mentioned in the original design). Please check out the updated design page and see if it's now good enough to begin implementing the feature.
Many thanks, sl.
On 06/07/2018 09:33 AM, Florence Blanc-Renaud wrote:
On 06/06/2018 10:24 AM, Standa Laznicka via FreeIPA-devel wrote:
Thank you guys for your great comments, I was away for the past few days but you correctly understood all of the motivations of the design and shared them here. I'll add several comments throughout the mails here:
On 06/05/2018 11:02 AM, Fraser Tweedale wrote:
On Tue, Jun 05, 2018 at 09:51:08AM +0200, Florence Blanc-Renaud wrote:
On 06/01/2018 03:08 AM, Fraser Tweedale via FreeIPA-devel wrote:
On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via FreeIPA-devel wrote:
Hello people of the freeipa-devel channel,
Let me share a design that proposes a way of automating the way FreeIPA replicas would be promoted to become a CRL master. Since the configuration cannot be dynamically altered by modifying an entry in the LDAP database, the proposal is to create an ipa-advise extension that could handle this operation instead for now. Read all about it in the attachement.
Looking forward to your comments, Stanislav Láznička
-- Standa Láznička A Red Hat person PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
# CRL master reassignment draft
## Rationale
Changing the CRL master of the FreeIPA system feels complex for the users and is thus rather error prone from the experience of the support engineers.
We should provide a more automatic way of handling this process.
## Design
While FreeIPA framework offers an API to define a server role, the framework itself counts with all the necessary information to be available in the backend database. Assigning an IPA server as a CRL master requires access to the filesystem [freeipa.org:Promote CA to Renewal and CRL Master]( https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) and therefore the framework should not be used, at least not until PKI allows us to change this configuration aspect of the system based on the values stored in the database. Instead, we will use the capabilities of the `ipa-advise` tool. Creating a separate Python script would also be an option but creating a script for every possible action in IPA seems like an unfortunate decision to make as it would only generate a bunch of binaries that would be hard getting rid of when a proper solution for that certain problem appears.
## Implementation A new `ipa-advise` plugin is created - `crl_master.py`. This plugin will provide the user with a script that will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master. The script will be based on the steps in the aforementioned HOWTO page.
## FEature management - CLI | Command | Arguments | | :---: | :---: | | ipa-advise | set-crl-master |
Hi Standa,
thanks for the design.
I was thinking as Rob and Fraser about storing the CRL generation master in LDAP, and came to the following question. Currently we always configure the CA renewal and CRL generation on the same host. Does it make sense to have these 2 functions on different masters? If not, we may consider relying on the existing attribute (ipaconfigstring=caRenewalMaster).
There is no technical reason these functions have to be the same server. There is usually no reason why they'd have to be separate servers, either. But they are separate and unrelated behaviours, so I'm wary of hanging CRL behaviour off the caRenewalMaster config.
I would really like to refrain from adding any CRL-master connected values/attributes to LDAP for now. While we're setting the CRL master along with the cert-renewal master, I believe that when the cert-renewal master is moved, we do not automatically move the CRL master functionality along with it. I would keep the behavior the same. This of course makes it a bit harder to discover what the current CRL master is (does Dogtag have an API on discovering that?) but it does not have a negative impact on the current user experience.
Ok for me, we can keep CRL generation and CA renewal as 2 distinct functionalities not necessarily co-located.
Thanks for the design, Standa. One comment:
We already have `ipa-csreplica-manage set-renewal-master`. IMO configuring CRLs is in the same ball park, so why not make new subcommand(s), e.g.:
ipa-csreplica-manage [un]configure-crl-generation
If/when we support LDAP-based CRL configuration in Dogtag, we can enhance these subcommands to work with the new configuration system.
I do not have the whole history but I believe that a decision was made to move from ipa-csreplica-manage set-renewal-master to ipa config-mod --ca-renewal-master-server (see ticket https://pagure.io/freeipa/issue/5689), with the long term plan of completely deprecating ipa-(cs)replica-manage (https://www.freeipa.org/page/V4/Manage_replication_topology_4_4). If this plan is still valid, we should probably avoid making a new subcommand of ipa-csreplica-manage. This leaves us with either a new advise plugin or an extension of ipa config-mod.
This was exactly my motivation not to go for ipa-csreplica-manage extensions, yes. I don't like the idea of using our framework (read `ipa config-mod`) to touch the filesystem and try to set it up somehow. It's supposed to work with the underlying database, not the master's file. That's why I am proposing an advise plugin instead.
Ok for me, too.
Now concerning the new command, I'd rather have a single command that performs 1/ unconfigure CRL generation on current CRL generation master 2/ configure CRL generation on new master I think that having one subcommand for unconfigure + one subcommand for configure would create an unnecessary 2-step process with the risk of forgetting one of the steps. Moreover, if we want to enforce that only one master is configured as CRL renewal master, it is more user-friendly and less error-prone.
It should be definitely handled by just one step. It's described in the current design draft as such:
"""
...it will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master
"""
Sure, your description was clear and I was mainly reacting to Fraser's proposal ipa-csreplica-manage [un]configure-crl-generation
I would also like to see more details in the design, for instance how would the command react on failures (rollback or simply print error messages?), which checks will be performed etc...
Thanks, Flo
I thought such technical discussion could be held once the PR is created. Would that be acceptable or should I include speculations over the inputs and their error-handling to the design now?
In general I agree that the PR is the right place to discuss specific details but I'm rather thinking of the overall behavior here. IMHO the most difficult part is often agreeing on the expectations and trying to foresee potential issues.
For instance ipa-advise will produce a script but what will be the script's arguments? Can the script be run by non-root? The script will perform local operations as well as remote operations, if one part succeeds but the other one fails will it rollback? For me it's easier to discuss these points as items in a design rather than code lines in a PR, but that's a personal preference. I completely understand if you prefer discussing in the PR.
Flo
This hints at the long term "wishlist" item of an IPA configuration daemon that can observe changes in LDAP-based configuration and effect local configuration changes[1]. This is the ideal solution.
So whatever we do in the short term, be it enhancing ipa-csreplica-manage or whatever else, we should keep this long-term RFE in mind.
[1] https://pagure.io/freeipa/issue/5974
Thanks, Fraser
Regardless of where we put the behaviour, 100% agree with having a command to automate this for admins!
Cheers, Fraser
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-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.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahost...
On 06/08/2018 10:01 AM, Standa Laznicka via FreeIPA-devel wrote:
Flo, thank you for your invaluable comments.
I originally did not notice that there was a design draft page for this feature already. Since we all seem to be in agreement about the design I proposed, I updated the original page and the design can now be found at https://www.freeipa.org/page/V4/Promotion_to_CRL_generation_master
I expanded on the generated script requirements (some of them - I believe the most important - were already mentioned in the original design). Please check out the updated design page and see if it's now good enough to begin implementing the feature.
Hi Standa, thanks for the update, the design page contains exactly the information I was looking for. I just have a nitpick re. the combination of script name/argument that could be confusing.
If I read: # ipa-advise set-crl-master > set-crl-master.sh # ./set-crl-master.sh master1.example.com I would spontaneously assume that master1 is the target where I want to have CRL generation, not the old master. I agree that the script name is something set by the user but I guess in 99% of the cases he will do just like you did, ie reuse the same name as ipa-advise subcommand. Maybe we can use a subcommand like 'ipa-advise move-crl-master' to minimize the confusion. I am open to any suggestion (especially from native english speakers) as I am not convinced either by my proposal...
Flo
Many thanks, sl.
On 06/07/2018 09:33 AM, Florence Blanc-Renaud wrote:
On 06/06/2018 10:24 AM, Standa Laznicka via FreeIPA-devel wrote:
Thank you guys for your great comments, I was away for the past few days but you correctly understood all of the motivations of the design and shared them here. I'll add several comments throughout the mails here:
On 06/05/2018 11:02 AM, Fraser Tweedale wrote:
On Tue, Jun 05, 2018 at 09:51:08AM +0200, Florence Blanc-Renaud wrote:
On 06/01/2018 03:08 AM, Fraser Tweedale via FreeIPA-devel wrote:
On Thu, May 31, 2018 at 12:10:31PM +0200, Standa Laznicka via FreeIPA-devel wrote: > Hello people of the freeipa-devel channel, > > Let me share a design that proposes a way of automating the way > FreeIPA > replicas would be promoted to become a CRL master. Since the > configuration cannot be dynamically altered by modifying an entry > in the > LDAP database, the proposal is to create an ipa-advise extension > that > could handle this operation instead for now. Read all about it in > the > attachement. > > Looking forward to your comments, > Stanislav Láznička > > -- > Standa Láznička > A Red Hat person > PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3 > > # CRL master reassignment draft > > ## Rationale > > Changing the CRL master of the FreeIPA system feels complex for > the users > and is thus rather error prone from the experience of the support > engineers. > > We should provide a more automatic way of handling this process. > > ## Design > > While FreeIPA framework offers an API to define a server role, > the framework > itself counts with all the necessary information to be available > in the backend > database. Assigning an IPA server as a CRL master requires access > to the > filesystem [freeipa.org:Promote CA to Renewal and CRL Master]( > https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master) > and > therefore the framework should not be used, at least not until > PKI allows us to change this configuration aspect of the system > based on the > values stored in the database. Instead, we will use the > capabilities of the > `ipa-advise` tool. Creating a separate Python script would also > be an option > but creating a script for every possible action in IPA seems like an > unfortunate decision to make as it would only generate a bunch of > binaries > that would be hard getting rid of when a proper solution for that > certain > problem appears. > > ## Implementation > A new `ipa-advise` plugin is created - `crl_master.py`. This > plugin will > provide the user with a script that will simultaneously try to > change the > configuration files on the current CRL master making it a common > CRL clone > (should be done via ssh), and also edit the files on the current > system > so that it becomes the CRL master. The script will be based on the > steps in the aforementioned HOWTO page. > > ## FEature management - CLI > | Command | Arguments | > | :---: | :---: | > | ipa-advise | set-crl-master |
Hi Standa,
thanks for the design.
I was thinking as Rob and Fraser about storing the CRL generation master in LDAP, and came to the following question. Currently we always configure the CA renewal and CRL generation on the same host. Does it make sense to have these 2 functions on different masters? If not, we may consider relying on the existing attribute (ipaconfigstring=caRenewalMaster).
There is no technical reason these functions have to be the same server. There is usually no reason why they'd have to be separate servers, either. But they are separate and unrelated behaviours, so I'm wary of hanging CRL behaviour off the caRenewalMaster config.
I would really like to refrain from adding any CRL-master connected values/attributes to LDAP for now. While we're setting the CRL master along with the cert-renewal master, I believe that when the cert-renewal master is moved, we do not automatically move the CRL master functionality along with it. I would keep the behavior the same. This of course makes it a bit harder to discover what the current CRL master is (does Dogtag have an API on discovering that?) but it does not have a negative impact on the current user experience.
Ok for me, we can keep CRL generation and CA renewal as 2 distinct functionalities not necessarily co-located.
Thanks for the design, Standa. One comment:
We already have `ipa-csreplica-manage set-renewal-master`. IMO configuring CRLs is in the same ball park, so why not make new subcommand(s), e.g.:
ipa-csreplica-manage [un]configure-crl-generation
If/when we support LDAP-based CRL configuration in Dogtag, we can enhance these subcommands to work with the new configuration system.
I do not have the whole history but I believe that a decision was made to move from ipa-csreplica-manage set-renewal-master to ipa config-mod --ca-renewal-master-server (see ticket https://pagure.io/freeipa/issue/5689), with the long term plan of completely deprecating ipa-(cs)replica-manage (https://www.freeipa.org/page/V4/Manage_replication_topology_4_4). If this plan is still valid, we should probably avoid making a new subcommand of ipa-csreplica-manage. This leaves us with either a new advise plugin or an extension of ipa config-mod.
This was exactly my motivation not to go for ipa-csreplica-manage extensions, yes. I don't like the idea of using our framework (read `ipa config-mod`) to touch the filesystem and try to set it up somehow. It's supposed to work with the underlying database, not the master's file. That's why I am proposing an advise plugin instead.
Ok for me, too.
Now concerning the new command, I'd rather have a single command that performs 1/ unconfigure CRL generation on current CRL generation master 2/ configure CRL generation on new master I think that having one subcommand for unconfigure + one subcommand for configure would create an unnecessary 2-step process with the risk of forgetting one of the steps. Moreover, if we want to enforce that only one master is configured as CRL renewal master, it is more user-friendly and less error-prone.
It should be definitely handled by just one step. It's described in the current design draft as such:
"""
...it will simultaneously try to change the configuration files on the current CRL master making it a common CRL clone (should be done via ssh), and also edit the files on the current system so that it becomes the CRL master
"""
Sure, your description was clear and I was mainly reacting to Fraser's proposal ipa-csreplica-manage [un]configure-crl-generation
I would also like to see more details in the design, for instance how would the command react on failures (rollback or simply print error messages?), which checks will be performed etc...
Thanks, Flo
I thought such technical discussion could be held once the PR is created. Would that be acceptable or should I include speculations over the inputs and their error-handling to the design now?
In general I agree that the PR is the right place to discuss specific details but I'm rather thinking of the overall behavior here. IMHO the most difficult part is often agreeing on the expectations and trying to foresee potential issues.
For instance ipa-advise will produce a script but what will be the script's arguments? Can the script be run by non-root? The script will perform local operations as well as remote operations, if one part succeeds but the other one fails will it rollback? For me it's easier to discuss these points as items in a design rather than code lines in a PR, but that's a personal preference. I completely understand if you prefer discussing in the PR.
Flo
This hints at the long term "wishlist" item of an IPA configuration daemon that can observe changes in LDAP-based configuration and effect local configuration changes[1]. This is the ideal solution.
So whatever we do in the short term, be it enhancing ipa-csreplica-manage or whatever else, we should keep this long-term RFE in mind.
[1] https://pagure.io/freeipa/issue/5974
Thanks, Fraser
Regardless of where we put the behaviour, 100% agree with having a command to automate this for admins!
Cheers, Fraser
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-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.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahost...
FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-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.fedoraproject.org/archives/list/freeipa-devel@lists.fedorahost...
freeipa-devel@lists.fedorahosted.org
-
Florence Blanc-Renaud -
Fraser Tweedale -
Rob Crittenden -
Standa Laznicka