[CentOS-devel] help with the IPA tests

[Nico Kadel-Garcia]

On Sat, Jun 13, 2015 at 3:38 AM, Karanbir Singh <kbsingh at 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-64/5/console
>
>
> 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.