At PyCon Australia on the weekend I was reminded of PEP-484 type
hinting** and the Mypy type checker for Python.
With focus of FreeIPA project shifting more towards stability,
quality and maintainability, and with Python 3 porting work nearly
wrapped up, now is the time to think about how we can get more
confidence in our code not just from tests, but from the code
itself. Static checking of annotated types can help us there, and
Mypy can let us begin to do this when writing new code or
refactoring old code. Furthermore there is a benefit for IDE-users
where plugins can use type annotations to provide better completion
suggestions, etc. For an overview of Mypy please see the PyCon AU
talk or the docs.
So, what's the plan? Alongside my other tasks, I'm going to start
looking at how we could use Mypy in FreeIPA CI, and see what it is
like using types in some of the areas I'm familiar with e.g.
ipalib.x509. Based on my findings I'll update the team on the wins
and challenges and we can decide how to proceed from there.
Title: #955: host_port_open: revert to old behavior where one iface is sufficient
Changed behavior of host_port_open to require all discovered interfaces to
listed on the port.
But usage of host_port_open function in wait_for_open_ports function which is
indirectly used from service.start might be still ok with only one interface.
Requiring all interfaces might then cause issue(waiting till timeout) in IPA upgrader in specific DNS
or network setups.
To pull the PR as Git branch:
git remote add ghfreeipa https://github.com/freeipa/freeipa
git fetch ghfreeipa pull/955/head:pr955
git checkout pr955
This is at least the second time recently that people needing to
renew service certificates used ``ipa-cacert-manage renew`` (the
wrong command) and either didn't solve the problem or got into a
Clearly we have a usability problem here.
The ipa-cacert-manage(1) man page is clear, but perhaps could use a
prominent statement that it doesn't renew service certs and if
that's all the user needs to do, to use `getcert resubmit` instead.
But I think better would be to enhance `ipa-cacert-manage renew` to
inspect the current CA certificate and if it has, say, more than 75%
of its validity period still to go, to PROMPT the user to confirm
that renewing the *CA* certificate is really what they wanted to do.
What do others think of this idea?
On Tue, Aug 01, 2017 at 05:22:53PM +0200, Florence Blanc-Renaud via FreeIPA-users wrote:
> On 08/01/2017 03:50 PM, Jason B. Nance via FreeIPA-users wrote:
> > Hello everyone,
> > I'm running FreeIPA 4.4 (as shipped with current CentOS 7). I had a series of unfortunate events which resulted in the entire cluster being offline for a matter of a couple weeks during which the certificate in /etc/httpd/alias expired. I rolled back the clocks on all of the servers in the cluster and started them successfully, however, the certificates in /etc/httpd/alias did not get renewed. Is there a process that automatically handles this or was I supposed to be maintaining that?
> > Additionally, based on:
> > https://www.freeipa.org/page/Howto/CA_Certificate_Renewal
> > ...I ran "ipa-cacert-manage renew" on my CA in a hope that that would trigger renewals across the boards, but now it appears that only the CA was updated as none of the server certificates were re-issued and are now all untrusted (I can't do "kinit admin" any longer as my realm is now down). Is there any chance of rolling that back or issuing new certs to get things going again?
> ipa-cacert-manage will only renew IPA CA certificate, not the LDAP or HTTP
> server certificates.
> When IPA is using an embedded CA, the LDAP and HTTP server certificates
> should be automatically renewed thanks to certmonger. If the automatic
> renewal did not happen, you can check:
> - if the certificates are indeed tracked by certmonger
> sudo getcert list -n Server-Cert
> The tool should output one cert for HTTP (in /etc/httpd/alias) and one for
> LDAP (in /etc/dirsrv/slapd-DOM...). If the certs are not tracked, you need
> to use getcert start-tracking to track them.
> - if they are tracked but not renewed, check the journal for certmonger
> messages. Certmonger should log a message when a certificate is nearing its
> expiration, and another message when the renewal succeeded.
> When the certificates are expired, the method is to stop ntpd, go back in
> time to a date where the certs were still valid, then manually trigger the
> renewal using getcert resubmit -i <ID>. In case of errors, examine the
> journal logs and try to fix the issue, then relaunch getcert resubmit. Once
> the renewal succeeds, getcert list shows the cert status as MONITORING and
> you can restart ntpd.
> This blog  provides a few examples of issues and their resolution
>  https://floblanc.wordpress.com/2016/12/19/troubleshooting-certmonger-issu...
> > If I have to start over, that is certainly an option. I'm just trying to get a better understanding of what I should have been doing to avoid this situation in the first place.
> > Thanks,
> > j
> > _______________________________________________
> > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
We'd like to announce our pull-request CI infrastructure is live.
Similarly to Travis CI, it picks up pull request and runs some tests on
the code. You can see the result directly in the pull-request.
If the test run fails, you can click 'Details' and check the logs. You
can inspect the runner.log which has all the high-level information. For
pytest, there's also report.html. Other relevant logs are also collected
during builds and test runs.
*Important changes for contributors*
- If you're fixing a bug for an older release which requires a fix in
multiple branches, make a separate pull-request for each branch.
- Please re-base your current pull-request to trigger the PR CI.
- If you're not on the white-list , a reviewer will have to trigger
the test run manually with the 're-run' label.
*Notice for people with commit rights*
- Please make sure PR CI jobs were executed before giving the 'ack' label.
- Do not push a single pull-request into multiple branches.
As of now, please consider the PR CI a tech preview. If a test run
fails, especially during the provisioning phase, issue a re-run. If it
fails consistently and you don't think the issue is on your side, please
report it to github issues .
We're currently working on resolving some pressing issues. Once the most
urgent ones are addressed and the system is more stable and usable, you
can expect a demo for contributors, describing the work-flow, logs etc.
 - https://github.com/freeipa/freeipa-pr-ci/blob/master/whitelist.yml
 - https://github.com/freeipa/freeipa-pr-ci/issues
PGP: 4A8B A48C 2AED 933B D495 C509 A1FB A5F7 EF8C 4869