[Pike] kerberos configuration lacks default_realm

[Cédric Jeanneret deactivated]

Openstack release: Pike

Dear tripleO maintainers,

In order to get the openstack -> freeipa link working, I've installed the brand new (and not yet released) pike version.
The link is working as expected, and nodes are created in freeipa, and removed when we drop them.

Still, there's a small issue with the kerberos configuration: apparently, there's nothing managing its configuration file, located in /etc/krb5.conf.

This leads to an issue, at least for the setup we have in here:
- CloudDomain is set to cloud.example.com
- FreeIPA realm is idm.example.com

This creates a small complication, especially when we want to enable the full TLS stack, making certmonger requests certificates for the services (mysql, api and so on).
When certmonger is called, it fails with this error:

*Configuration file does not specify default realm.*

After poking around and making some other test, it appears we can add a configuration un the krb5.conf file:
default_realm = IDM.EXAMPLE.COM

And all seems to work properly.

In order to workaround that issue, we've modified the vendor cloud-init script in order to run a sed command on that file - the goal is to get that configuration as soon as possible, before certmonger is called.

A better way to do that would be to include a puppet module for kerberos, like that one:
https://forge.puppet.com/Aethylred/kerberos (apparently a good one, seeing downloads and grades).
It can then be configured properly using hiera.

Care to tackle that issue before the release day? That would be just wonderful :).

Thank you!

Cheers,

C.

[Cédric Jeanneret deactivated (cjeanneret-c2c-deactivated)]

Hello,

After some more tests and debunking, I think there's a better way in the end: the krb5.conf is generated by ipa-client-install command - that means a simple modification to the cloud-init vendor2 snippet might as well be sufficient, without the need of a new puppet module.

Indeed, allowing the installer to add the following options to the ipa-client-install command should provide the necessary information in the krb5.conf file:
--realm
--server (multiple time allowed)
--domain (not mandatory I think, but...)

Hence, a better templating for that script when we install the undercloud can do the trick in a better way.

Cheers,

C.

[Juan Antonio Osorio Robles (juan-osorio-robles)]

I think we could fix this in novajoin. re-triaging.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/501112
Committed: https://git.openstack.org/cgit/openstack/novajoin/commit/?id=61346df6c8e9fd11576e6086064819e6b0ab7cb4
Submitter: Jenkins
Branch: master

commit 61346df6c8e9fd11576e6086064819e6b0ab7cb4
Author: Juan Antonio Osorio Robles <email address hidden>
Date: Wed Sep 6 08:59:45 2017 +0300

    Use novajoin's kerberos realm for instances

    This is useful in cases where the kerberos realm isn't the same as
    the domain. It gets the kerberos realm that novajoin is using, and gets
    the instance to register using that.

    Closes-Bug: #1711312
    Change-Id: Ic8a32a0ace69b32e1bb66145ac460175c4508a17