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
> 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
>>> 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
>>> 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
>>> database. Assigning an IPA server as a CRL master requires access to the
>>> filesystem [freeipa.org:Promote CA to Renewal and CRL Master](
>>> 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
> 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
), with the long term plan of
> completely deprecating ipa-(cs)replica-manage
> 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
> 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
daemon that can observe changes in LDAP-based configuration and
effect local configuration changes. 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.
>> Regardless of where we put the behaviour, 100% agree with having a
>> command to automate this for admins!
A Red Hat person
PGP: 8B00 620A 713B 714E B4CB 4767 C98C 4149 36B1 A7F3