Jan Cholasta wrote:
On 10.4.2014 22:06, Rob Crittenden wrote:
Some in-line, a whole ton of data appended to end.

Jan Cholasta wrote:
On 7.4.2014 20:09, Rob Crittenden wrote:
Rob Crittenden wrote:


I wonder if it would be clearer to use variables instead of a raw list
in the return value for these handlers: (result, message) =
rather than examining result[0], etc. That may be beyond the scope of
this patch though.

Yes. It would be nice if certmonger included a Python module for helper

Yes, but what I mean is the internal handling returns tuples of data
with unique variable names, then plucks them out positionally.

len(result) depends on result[0], so you can't do "result, message =
handler(...)", because it would blow up when len(result) != 2.



You are going to end up with a lot of acis with the same comment
Perhaps add the host in there as well.

These are not removed when a master is deleted.

I merely did the same thing as the "Add CA Certificates for renewals"
and "Modify CA Certificates for renewals" ACIs.

I agree it's suboptimal, but IMO it should be fixed in the scope of
<https://fedorahosted.org/freeipa/ticket/3416> (the "ipa masters
hostgroup" part).

There is a replica_cleanup() method in replication.py. I don't know why
this couldn't be added there.

OK, added, see patch 263. But we should do the hostgroup thing anyway,
this solution sucks.

I completely agree.


We've been burned by hardcoded timeouts in the past. Should this be
configurable? This module doesn't currently do any logging but it
be worth spitting out a "waiting" message, at least for debugging.

Added a timeout argument.

Did you forget to send this one, I didn't see an update to 247.

Are you sure you have 247.1 (now 247.2)?

I can see at
that I have sent the correct version of the patches.

The call has a timeout, the callers don't use it. I guess it'll do for now, but these almost always come back to bite us.


The tool should provide some feedback while it's running. For the
impatient (me) it takes a really long time and it's hard to know
what is
going on, something in between nothing and full debug output.

Added some messages about what's going on.

I dpn't see an update to 251 either.

Please make sure you have 251.1 (now 251.2).

There is a little bit more output but there are still very long periods of waiting between any visual activity, particularly when doing it on an IPA self-signed CA.

The man page needs some more work too. I think some more
explanation is
needed and an example would probably be really helpful as well. I
particularly an example for external certs and a description of what
mean by Self-signed CA (I assume you mean IPA-provided). I don't think
it really matters how many steps there are unless you are going to
provide progress output.

Reworded the man page a little bit.

Got a backtrace when running as non-root:

$ ipa-cacert-manage -v renew
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG:   File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line
168, in

line 62, in validate_options
     super(CACertManage, self).validate_options(needs_root=True)
   File "/usr/lib/python2.7/site-packages/ipapython/admintool.py",
189, in validate_options
     raise ScriptError('Must be root to run %s' %
self.command_name, 1)

ipa.ipaserver.install.ipa_cacert_manage.CACertManage: DEBUG: The
ipa-cacert-manage command failed, exception: ScriptError: Must be root
to run ipa-cacert-manage
ipa.ipaserver.install.ipa_cacert_manage.CACertManage: ERROR: Must be
root to run ipa-cacert-manage

That's correct, you can run it only as root, because you can't resubmit
certmonger requests as a regular user.

Yes but one shouldn't get a traceback!

You get the traceback only in verbose mode. I did not invent this, it's
how ipapython.admintool does things.

Ok, I'll blame Petr.

After moving time forward on the replica these certificates are in

auditSigningCert cert-pki-ca
ocspSigningCert cert-pki-ca
subsystemCert cert-pki-ca

cn=ca_renewal is completely empty on the replica. On the master it only
has the subsystemCert. I'm guessing this is at least partly due to my
switching time one system at a time rather than (somewhat)
simultaneously, but it still would have blown up with 3 missing certs.

Can you post the related log messages from /var/log/messages from the
master somewhere?

There's not much I can do about broken replication. I think you hit


Thanks for the review.

Updated and rebased patches attached.

Patch 262 has lots of lint errors because you're adding arguments to
functions that don't currently define one, is_renewal_master() for

They are defined in patch 246.1 (now 246.2).

I think the ipa-cacert-manage man page is missing one really important
piece: why would you ever need to run this? And when?

Added a paragraph about this.

It's better, couple of comments:

Add "the" in between renew and CA in "used to manually renew CA certificate of" and "When IPA CA...". I haven't had any luck renewing the CA certificate yet. I see that it is tracked now. I started moving the system clock forward in order to get to renewal and about the 3rd iteration the requests started failing with an XML error. Did you see this?

[Thu Apr 21 11:08:49.929486 2016] [:error] [pid 11692] Traceback (most recent call last): [Thu Apr 21 11:08:49.929489 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 344, in wsgi_execute [Thu Apr 21 11:08:49.929493 2016] [:error] [pid 11692] result = self.Command[name](*args, **options) [Thu Apr 21 11:08:49.929496 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ [Thu Apr 21 11:08:49.929499 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.929503 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run [Thu Apr 21 11:08:49.929506 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.929509 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 382, in execute [Thu Apr 21 11:08:49.929512 2016] [:error] [pid 11692] result = api.Command['cert_show'](unicode(serial))['result'] [Thu Apr 21 11:08:49.929516 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 436, in __call__ [Thu Apr 21 11:08:49.929519 2016] [:error] [pid 11692] ret = self.run(*args, **options) [Thu Apr 21 11:08:49.930559 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 752, in run [Thu Apr 21 11:08:49.930567 2016] [:error] [pid 11692] result = self.execute(*args, **options) [Thu Apr 21 11:08:49.930570 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py", line 514, in execute [Thu Apr 21 11:08:49.930573 2016] [:error] [pid 11692] result=self.Backend.ra.get_certificate(serial_number) [Thu Apr 21 11:08:49.930577 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1502, in get_certificate [Thu Apr 21 11:08:49.930580 2016] [:error] [pid 11692] parse_result = self.get_parse_result_xml(http_body, parse_display_cert_xml) [Thu Apr 21 11:08:49.930591 2016] [:error] [pid 11692] File "/usr/lib/python2.7/site-packages/ipaserver/plugins/dogtag.py", line 1363, in get_parse_result_xml [Thu Apr 21 11:08:49.930594 2016] [:error] [pid 11692] doc = etree.fromstring(xml_text, parser) [Thu Apr 21 11:08:49.930598 2016] [:error] [pid 11692] File "lxml.etree.pyx", line 3032, in lxml.etree.fromstring (src/lxml/lxml.etree.c:68129) [Thu Apr 21 11:08:49.930601 2016] [:error] [pid 11692] File "parser.pxi", line 1785, in lxml.etree._parseMemoryDocument (src/lxml/lxml.etree.c:102493) [Thu Apr 21 11:08:49.930604 2016] [:error] [pid 11692] File "parser.pxi", line 1673, in lxml.etree._parseDoc (src/lxml/lxml.etree.c:101322) [Thu Apr 21 11:08:49.930607 2016] [:error] [pid 11692] File "parser.pxi", line 1074, in lxml.etree._BaseParser._parseDoc (src/lxml/lxml.etree.c:96504) [Thu Apr 21 11:08:49.930611 2016] [:error] [pid 11692] File "parser.pxi", line 582, in lxml.etree._ParserContext._handleParseResultDoc (src/lxml/lxml.etree.c:91308) [Thu Apr 21 11:08:49.930614 2016] [:error] [pid 11692] File "parser.pxi", line 683, in lxml.etree._handleParseResult (src/lxml/lxml.etree.c:92494) [Thu Apr 21 11:08:49.930617 2016] [:error] [pid 11692] File "parser.pxi", line 633, in lxml.etree._raiseParseError (src/lxml/lxml.etree.c:91957)
[Thu Apr 21 11:08:49.930621 2016] [:error] [pid 11692] XMLSyntaxError: None
[Thu Apr 21 11:08:49.930829 2016] [:error] [pid 11692] ipa: INFO: [xmlserver] host/lyra.greyoak....@greyoak.com: cert_request(u'MIIDmTCCAoECAQAwMTEUMBIGA1UECgwLR1JFWU9BSy5DT00xGTAXBgNVBAMMEGx5cmEuZ3JleW9hay5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVw34/WP/pKg+kxmM7aDcjYsEFA9By4SyV1n4FeeDpr2gBulyjKNGTaxuoEssqYy33qVU7vxQ8WS9LtYt1eyAZrKLCVso1njtMZZ2mpymltRgRT+QFzMjwrcoqqGM9XWjVAMur/FJggVPxcpNXy2EUAiVcMEO4zCgxjkWjaXSs5jigvFO5wzolnQRYPECPhYuYwKpVRPwCsqpeiymfpiVuHt+oTHA9lNIGRWWxA+72NLFhrLBKaVaFDl4NCT6jJ71xZDXLQWQw1kAWvYKV22jCfDS/Yxdtyt3O0kUs8dHYClTgW4QN3bBQsgUaspHuWGdF6rwqmIihPUjq07fB6r8jAgMBAAGgggEhMCUGCSqGSIb3DQEJFDEYHhYAUwBlAHIAdgBlAHIALQBDAGUAcgB0MIH3BgkqhkiG9w0BCQ4xgekwgeYwDgYDVR0PAQEABAQDAgTwMIGBBgNVHREBAQAEdzB1oDEGCisGAQQBgjcUAgOgIwwhSFRUUC9seXJhLmdyZXlvYWsuY29tQEdSRVlPQUsuQ09NoEAGBisGAQUCAqA2MDSgDRsLR1JFWU9BSy5DT02hIzAhoAMCAQGhGjAYGwRIVFRQGxBseXJhLmdyZXlvYWsuY29tMCAGA1UdJQEBAAQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjAMBgNVHRMBAf8EAjAAMCAGA1UdDgEBAAQWBBQ2k1wey/NlwORBA7I+O26IX0WyGTANBgkqhkiG9w0BAQsFAAOCAQEABUStRJyl5DBTpEOdKOXCnhSdRuElwv64XLIX47B1DVsiI9tL806nsLH16XSFIZqo1HWXxDU90/Wm8VPZgm!
3k4qYBz6/2B8PEeQY2/W5CULkfjqJhDxr0qodiYAc8GOyHMDpymfC3+QUIXkmoy94USRS2x8CMvzq8h1tpBPcXAei6waohTJtO33o79iVNbeLIif3RD22dghPx3JvEB4FXWQv6IylXGyJb6NRRneI4R8Ko0xCA9xiyPegfDgiQEUUSCtJ/Qr9/OpytFgrpJHSTd8n9DzLbRO5FQW4yS45A8xp5WkJCU5IslIon6luf9v5eNCVsIp7EPgaQ==', principal=u'HTTP/lyra.greyoak....@greyoak.com', add=True, version=u'2.51'): XMLSyntaxError

I noticed that in the external CA case we still have certmonger tracking the CA. What will it do at expiration?

I updated selinux-policy but I'm not seeing the certs added consistently
to ca_renewal so there is nothing to do, so it sits in CA_WORKING. I
verified it isn't a replication issue, the replication is working fine,
the certs just weren't pushed.

Fixed renewal scripts not to use ldapi, see patch 264.

Renewal in the self-signed case is working a lot smoother now.

Also fixed certificate retrieval from LDAP to check if the certificate
was actually renewed, see patch 265.

/etc/ipa/ca.crt isn't being updated on renewal.


Freeipa-devel mailing list

Reply via email to