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:

242

I wonder if it would be clearer to use variables instead of a raw list
in the return value for these handlers: (result, message) =
handler(...)
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
scripts...

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.

OK.



243

You are going to end up with a lot of acis with the same comment
value.
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.



247

We've been burned by hardcoded timeouts in the past. Should this be
configurable? This module doesn't currently do any logging but it
might
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
<http://www.redhat.com/archives/freeipa-devel/2014-April/msg00225.html>
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.



251

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
think
particularly an example for external certs and a description of what
you
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
execute
     self.validate_options()
   File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cacert_manage.py",




line 62, in validate_options
     super(CACertManage, self).validate_options(needs_root=True)
   File "/usr/lib/python2.7/site-packages/ipapython/admintool.py",
line
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
CA_WORKING:

ipaCert
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
<https://fedorahosted.org/389/ticket/47632>.


rob

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
example.

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!
3VCtgMvPVk
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.

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to