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]:
+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:
ipa-4-7:
ipa-4-6:
Metadata Update from @fcami: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.