#5803 Add utility to promote CA replica to CRL master
Closed: fixed by fcami. Opened by tscherf.

Currently it's a manual process to promote a replica to CRL master and it's error-prone. Ideally we add a new utility to ease this process:

master# ipa-crl-manage disable master.example.test

newmaster# ipa-crl-manage enable

newmaster# ipa-crl-manage status


Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1326425

Should this be instead accomplished by the Roles? I.e. http://www.redhat.com/archives/freeipa-devel/2016-April/msg00011.html, so that users can change the setting from UI without logging to the actual machine? It could help in container use case for example.

Doing it from roles(i.e. LDAP) would be great. But it would need PKI support for it.

+1 to the idea of Roles. Is there a design proposal summarised based on the discussion on the list?

If done using roles then it would be:

ipa config-mod --ca-crl-master ipasrv2.example.com

Replying to [comment:5 pvoborni]:

If done using roles then it would be:
{{{
ipa config-mod --ca-crl-master ipasrv2.example.com
}}}

Yes but I was asking about a bigger picture:

 ipa config-mod --ca-crl-master ipasrv2.example.com
 ipa config-mod --dns-server ipasrv2.example.com
 ipa config-mod --dnssec-master ipasrv2.example.com
 ipa config-mod --ca-server ipasrv2.example.com
 ipa config-mod --cert-renew-master-server ipasrv2.example.com
 ipa config-mod --secrets-server ipasrv2.example.com
 ipa config-mod --signing-server ipasrv2.example.com
 ipa config-mod --ocsp-server ipasrv2.example.com
 ipa config-mod --trust-agent ipasrv2.example.com
 ipa config-mod --trust-server ipasrv2.example.com
 ipa config-mod --kdc-proxy-server ipasrv2.example.com

I suspect that some of these "roles" can be assumed by a single server in realm but others can be assigned to more than one or all servers.
Also some roles might automatically imply other roles. This all needs to be captures somewhere and spelled out so this is what I was asking about.

This is probably not the right ticket to have a conversation. I suggest we for a ticket and move the conversation there if we do not have one already.

It's being designed at http://www.freeipa.org/page/V4/Server_Roles

Replying to [comment:7 pvoborni]:

It's being designed at http://www.freeipa.org/page/V4/Server_Roles

+1

    the procedure  is documented. It would help admins. But I'm afraid that there is no time in 4.4 therefore 4.5 backlog
    [DP] IMO a part of "server roles" idea. I suggest we group the related tickets and create a proposal that covers all of them, but that can be done as a thesis
    pv: server roles has two parts - reading and setting. Setting of almost everything requires to run and installer or config utility and therefore cannot be done now via a API command. Reading can be implemented easily. 4.4 discussions are about reading the stuff. This ticket is setting.
    kaleem: ok
    4.5 backlog for now (see if Dogtag can be changed to support the change better)

Metadata Update from @tscherf:
- Issue assigned to someone
- Issue set to the milestone: FreeIPA 4.5 backlog

Design page: https://www.freeipa.org/page/V4/Promotion_to_CRL_generation_master

Metadata Update from @rcritten:
- Issue close_status updated to: None
- Issue priority set to: important (was: low)
- Issue set to the milestone: FreeIPA 4.6.5 (was: FreeIPA 4.5 backlog)

Metadata Update from @rcritten:
- Issue assigned to rcritten (was: someone)

Some comments reg the proposed design:

Having two different processes and tools to change CA renewal and CRL master role is a bit unfortunate. I would rather prefer to also use a server role for this as described above: This would be a consistent approach and doesn't require admins to remember different tools when moving those roles. Usually you want to move both roles at the same time, so it should be an easy process.

But I understand this is currently not possible because of https://pagure.io/dogtagpki/issue/1262. Once this ticket has been resolved, using 'ipa config-mod' to define CA renewal and CRL master roles should be the preferred solution. But when we implement the design as proposed in https://www.freeipa.org/page/V4/Promotion_to_CRL_generation_master we would need to change the process. Do we want this?

Metadata Update from @frenaud:
- Custom field on_review adjusted to https://github.com/freeipa/freeipa/pull/2859 (was: 0)
- Issue assigned to frenaud (was: rcritten)

On master server:
[root@f29-idm0 ~]# ipa-crlgen-manage status
CRL generation: enabled
Unable to find last CRL
The ipa-crlgen-manage command was successful
[root@f29-idm0 ~]# ipa-crlgen-manage disable
Stopping pki-tomcatd
Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
Starting pki-tomcatd
Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
Restarting httpd
CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable
The ipa-crlgen-manage command was successful

On replica:
[root@f29-idm1 ~]# ipa-crlgen-manage status

CRL generation: disabled
The ipa-crlgen-manage command was successful
[root@f29-idm1 ~]#
[root@f29-idm1 ~]# ipa-crlgen-manage disable
Nothing to do, CRL generation already disabled
CRL generation disabled on the local host. Please make sure to configure CRL generation on another master with ipa-crlgen-manage enable
The ipa-crlgen-manage command was successful
[root@f29-idm1 ~]# ipa-crlgen-manage enable
Stopping pki-tomcatd
Editing /var/lib/pki/pki-tomcat/conf/ca/CS.cfg
Starting pki-tomcatd
Editing /etc/httpd/conf.d/ipa-pki-proxy.conf
Restarting httpd
Forcing CRL update
CRL generation enabled on the local host. Please make sure to have only a single CRL generation master.
The ipa-crlgen-manage command was successful

Difference in config files seem sane:

--- disabled/CS.cfg 2019-03-12 16:37:23.128831778 +0100
+++ enabled/CS.cfg 2019-03-12 16:37:56.767714341 +0100
@@ -433,2 +433,2 @@
-ca.crl.MasterCRL.enableCRLCache=false
-ca.crl.MasterCRL.enableCRLUpdates=false
+ca.crl.MasterCRL.enableCRLCache=true
+ca.crl.MasterCRL.enableCRLUpdates=true

--- disabled/ipa-pki-proxy.conf 2019-03-12 16:37:23.128831778 +0100
+++ enabled/ipa-pki-proxy.conf 2019-03-12 16:37:56.767714341 +0100
@@ -46,3 +46 @@
-
-
-RewriteRule ^/ipa/crl/MasterCRL.bin http://f29-idm0.laptop.example.org/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
\ No newline at end of file
+#RewriteRule ^/ipa/crl/MasterCRL.bin http://f29-idm0.laptop.example.org/ca/ee/ca/getCRL?op=getCRL&crlIssuingPoint=MasterCRL [L,R=301,NC]
\ No newline at end of file

When a server is CRL generation master uninstall is prohibited:
[root@f29-idm1 ~]# ipa-crlgen-manage status
CRL generation: enabled
Last CRL update: 2019-03-12 15:44:07
Last CRL Number: 4
The ipa-crlgen-manage command was successful
[root@f29-idm1 ~]# ipa-server-install --uninstall -U
Deleting this server will leave your installation without a CRL generation master.

Aborting uninstall operation.
The ipa-server-install command failed. See /var/log/ipaserver-uninstall.log for more information
[root@f29-idm1 ~]# ipa-crlgen-manage status
CRL generation: enabled
Last CRL update: 2019-03-12 15:44:07
Last CRL Number: 4
The ipa-crlgen-manage command was successful

master:

  • 0d23fa92788b1258005e46920505d9b768d30799 CRL generation master: new utility to enable|disable
  • 4e3a64f70316c98a18e403486f6f8afcec5e24e4 Test: add new tests for ipa-crlgen-manage
  • 2e73c964e5896eb18006e1ae8b70f2faef484ab3 ipa server: prevent uninstallation if the server is CRL master

ipa-4-7:

  • 52770aa5f9223eb26f42b301e54b228708ba83cc CRL generation master: new utility to enable|disable
  • 67533b3a1d037f314ad013572e0892ec85ffc288 Test: add new tests for ipa-crlgen-manage
  • e654a1b9189e38aafa5faa72cb9587262e13cec2 ipa server: prevent uninstallation if the server is CRL master

ipa-4-6:

  • af5abe0d743155953aa91c8e49f9d0199e5fe78a CRL generation master: new utility to enable|disable
  • 8fa3e9bf55062bbb6bcf255cc2a0142946adf5c2 Test: add new tests for ipa-crlgen-manage
  • 52e259b3fe9b6b07cafb7e1b2eea5d7e201a2878 ipa server: prevent uninstallation if the server is CRL master

Metadata Update from @fcami:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

Metadata