On Sat, Jun 13, 2015 at 3:38 AM, Karanbir Singh kbsingh@centos.org wrote:

hi,

Can someone help debug why the ipa tests are failing when run inside a VM ? ref: https://ci.centos.org/view/AtomicApp/job/vagrant-libvirt-base/27/console

I've bumped machine resources to multiple cores and 4G of ram, but afaict, its not failing due to running out of resources here.

seems to work fine when run in the same infra, but on the bare metal machine. Which makes me think it might be network related ? this is the same test running on the bare metal: https://ci.centos.org/view/CentOS-Core-QA/job/CentOS-Core-QA-t_functional-c7...

regards

Do the "bare metal" and the VM environment have the same OS image? I doubt it, especially with the error:

Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds

[1/27]: creating certificate server user [2/27]: configuring certificate server instance [3/27]: stopping certificate server instance to update CS.cfg [4/27]: backing up CS.cfg [5/27]: disabling nonces [6/27]: set up CRL publishing [7/27]: enable PKIX certificate path discovery and validation [8/27]: starting certificate server instance [9/27]: creating RA agent certificate database [10/27]: importing CA chain to RA certificate database [error] RuntimeError: Unable to retrieve CA chain: [Errno 111] Connection refused Unable to retrieve CA chain: [Errno 111] Connection refused [+] Fri 12 Jun 17:42:54 EDT 2015 -> FAIL + exit 1

That's hinting to me that it's failing to verify the CA chain, and *that* may be is sensitive to current members of the existing SSL setups for the build user. It may also be sensitive in this build environment to the locally configured FQDN, which does not normally match the system hostname of the build server. I've not taken apart the IPA particular packages, so can't offer much more help than that.

I personally admit that I haven't found any use for IPA. Kerberos authentication, yes, but with only a few local users on most systems requiring account management, I've really seen no use for it. Frankly, in large environments, I find it much easier to use Kerberos for authentication, and a locked down central NIS server for account management. It's much lighter weight, it's much easier to slave, and it's much easier to keep the NIS accounts segregated from local system accounts on the NIS server itself by using alternative passwd and group files. It's *much* lighter weight, and closer to the models used by MIT when they published Kerberos.