[Freeipa-users] ipa-client-install via Kickstart in RHEL7

Discussion:

Baird, Josh

2014-08-20 15:18:16 UTC

Hi,

We are attempting to run ipa-client-install in the %post section of a Kickstart in order to join the host to an IPA domain (3.3/RHEL7 IdM). We are using something like:

/usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U --no-ssh --no-sshd --no-ntp --domain=realm.com

The machine does indeed join the domain correctly, but the certmonger request fails. Looking at the logs, we can see this:

2014-08-19T15:02:45Z DEBUG Starting external process
2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service
2014-08-19T15:02:45Z DEBUG Process finished, return code=0
2014-08-19T15:02:45Z DEBUG stdout=
2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request.

The error is occurring because the certmonger service fails to start. This is because systemd is not able to manipulate services in a chrooted environment (ala the anaconda installation environment). Prior to systemd, this would work fine as services could start normally via init in a chroot/%post.

Additionally, we see the error:

Unable to find 'admin' user with 'getent passwd ***@domain.com'

Again, this is because systemd is unable to start sssd in the chrooted installation environment. I'm wondering if anyone else has experienced these issues with systemd unable to start these required services during installation and what you did to work around them. One option would be to move the ipa-client-install out of Kickstart and have Puppet join the host to the domain post-installation (after firstboot), but this isn't really ideal.

Any advice or suggestions would be appreciated.

Thanks,

Josh

Rich Megginson

2014-08-20 15:24:52 UTC

Permalink

Post by Baird, Josh
Hi,
/usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U --no-ssh --no-sshd --no-ntp --domain=realm.com
2014-08-19T15:02:45Z DEBUG Starting external process
2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service
2014-08-19T15:02:45Z DEBUG Process finished, return code=0
2014-08-19T15:02:45Z DEBUG stdout=
2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request.
The error is occurring because the certmonger service fails to start. This is because systemd is not able to manipulate services in a chrooted environment (ala the anaconda installation environment). Prior to systemd, this would work fine as services could start normally via init in a chroot/%post.
Again, this is because systemd is unable to start sssd in the chrooted installation environment. I'm wondering if anyone else has experienced these issues with systemd unable to start these required services during installation and what you did to work around them. One option would be to move the ipa-client-install out of Kickstart and have Puppet join the host to the domain post-installation (after firstboot), but this isn't really ideal.
Any advice or suggestions would be appreciated.

Create a file that is run at boot, presumably after networking and
certmonger are started.

Post by Baird, Josh
Thanks,
Josh

Martin Kosek

2014-08-21 11:55:34 UTC

Permalink

Post by Baird, Josh
Hi,
We are attempting to run ipa-client-install in the %post section of a
Kickstart in order to join the host to an IPA domain (3.3/RHEL7 IdM). We are
/usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U
--no-ssh --no-sshd --no-ntp --domain=realm.com
The machine does indeed join the domain correctly, but the certmonger request
2014-08-19T15:02:45Z DEBUG Starting external process
2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service
2014-08-19T15:02:45Z DEBUG Process finished, return code=0
2014-08-19T15:02:45Z DEBUG stdout=
2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request.
The error is occurring because the certmonger service fails to start. This
is because systemd is not able to manipulate services in a chrooted
environment (ala the anaconda installation environment). Prior to systemd,
this would work fine as services could start normally via init in a
chroot/%post.
Again, this is because systemd is unable to start sssd in the chrooted
installation environment. I'm wondering if anyone else has experienced these
issues with systemd unable to start these required services during
installation and what you did to work around them. One option would be to
move the ipa-client-install out of Kickstart and have Puppet join the host to
the domain post-installation (after firstboot), but this isn't really ideal.
Any advice or suggestions would be appreciated.

Create a file that is run at boot, presumably after networking and certmonger
are started.

What I saw as the common approach in OpenStack or other projects are scripts
and configurations for Cloud-init [1].

Are there people using it for this purpose or are there other (better) approaches?

[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/End_User_Guide/user-data.html

Martin

Rich Megginson

2014-08-21 13:30:29 UTC

Permalink

Post by Martin Kosek

Create a file that is run at boot, presumably after networking and certmonger
are started.

What I saw as the common approach in OpenStack or other projects are scripts
and configurations for Cloud-init [1].
Are there people using it for this purpose or are there other (better) approaches?

Yes, you can do ipa-server-install/ipa-client-install from a cloud-init
user-data runcmd script. However, there are selinux issues - some of
the transitions from the cloud-init contexts are not handled correctly.
What you can do is to first run with selinux in Permissive mode,
audit2allow -M cloudinit < /var/log/audit/audit.log , then in subsequent
runs do semodule -i cloudinit.pp with selinux Enforcing.

However, cloud-init and kickstart do not mix afaik.

Post by Martin Kosek
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/4/html/End_User_Guide/user-data.html
Martin