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 >>> >> -- Standa Láznička A Red Hat person PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3
signature.asc
Description: OpenPGP digital signature
_______________________________________________ FreeIPA-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/FZLVV2JWCXXRB2WH7WEZ6GAD2HKU6TML/
