Petr Viktorin wrote:
On 10/19/2012 05:42 PM, Rob Crittenden wrote:
Petr Viktorin wrote:
See ticket & commit message.

Please tell me of a better way to extend the Services.

What's interesting is that usually the CA is "running" right after the
ports are opened, but if not, it takes *exactly* one minute between the
ports being open and the time I stop getting 503 "Service Temporarily
Unavailable" from ca/admin/ca/getStatus. Is there a sleep somewhere in
pki? or httpd? or IPΑ?

No sleep that I know of, and I'm not seeing that behavior. In my testing
I got 503 exactly once. Most of the time once the port(s) were open and
the request went through the status was that dogtag was up and ready.

Just a few minor requests.

Can you add a block comment to ca_status? I think particularly
explaining why port 443 and not a CA port directly (I assume so we test
the proxy).


I'm a little confused by the wait variable. It is a boolean in some
cases and a string in others (no-proxy)? Why not just pass in False?

Since the proxy is installed after the CA, we can't check the proxy in
CA installation's restart step, but we do want to wait for the ports to
I agree the 'no-proxy' was a bad solution. The included patch just skips
the check if the httpd service is not configured yet.

I found out that knownservices.httpd.is_installed() returns True even
after an IPA server is uninstalled. I'm not sure if that's expected,
I've sent a separate mail asking for clarification.
As a workaround I check for the /etc/httpd/conf.d/ipa.conf file, which
we remove on uninstall.

Juggling the proxy configuration, httpd restart, and CA restart/wait to
happen in the right order in all cases is not trivial (especially with
the long testing times). If you can think of an exotic scenario, please
test it.

The patch itself looks good. I'm having a replica install problem which
I'm guessing is unrelated.

The configure proxy step is failing to restart httpd. It is failing
because the default mod_nss port is 8443 which is also being used by
dogtag, so httpd fails to restart and the installation blows up.

Thanks for catching this. It was happening with --setup-ca. Fixed.

I think that ipa-replica-install --setup-ca should be changed to behave
exactly like ipa-replica-install followed by ipa-ca-install. Same for
the DNS installation. If there are no objections I'll include this in my
installer framework effort (#2652).

I think you may be right about the ordering, it may be better to do it last.

I'm not super happy with the fix for determining if we are configured yet but I can't find a better way so it'll work for the time being.

pushed to master and ipa-3-0


Freeipa-devel mailing list

Reply via email to