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 -- [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/VXMKDFOIPTVD6K364DCHSVQTMYQGNNWU/
_______________________________________________
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/OYC635U7QKJSPMYSXNGJV65S7V77NGR5/
