named-pkcs11.service refuse to start

[Dan33l]

For testing purpose, i am trying to install FreeIPA using docker (docker-ce 5:19.03.5~3-0~ubuntu-bionic) on Ubuntu 18.04 host with CentOS 7 docker image 5e35e350aded.

Running the following command fail :

/usr/sbin/ipa-server-install --hostname=ipa1.example.lan --realm=EXAMPLE.LAN --domain=example.lan --admin-password='s^ecr@et.ea;R/O*=?j!.QsAu+$' --ds-password='s^ecr@et.ea;R/O*=?j!.QsAu+$' --setup-dns --auto-reverse --no-forwarders --ip-address 172.17.0.2 --idstart=10000 --unattended

The output of the command:

... 8x ....

 Configuring DNS (named)
   [1/12]: generating rndc key file
   [2/12]: adding DNS container
   [3/12]: setting up our zone
   [4/12]: setting up reverse zone
   [5/12]: setting up our own record
   [6/12]: setting up records for other masters
   [7/12]: adding NS record to the zones
   [8/12]: setting up kerberos principal
   [9/12]: setting up named.conf
   [10/12]: setting up server configuration
   [11/12]: configuring named to start on boot
   [12/12]: changing resolv.conf to point to ourselves
 Done configuring DNS (named).
 Restarting the web server to pick up resolv.conf changes
 Configuring DNS key synchronization service (ipa-dnskeysyncd)
   [1/7]: checking status
   [2/7]: setting up bind-dyndb-ldap working directory
   [3/7]: setting up kerberos principal
   [4/7]: setting up SoftHSM
   [5/7]: adding DNSSEC containers
   [6/7]: creating replica keys
   [7/7]: configuring ipa-dnskeysyncd to start on boot
 Done configuring DNS key synchronization service (ipa-dnskeysyncd).
 Restarting ipa-dnskeysyncd
 Restarting named
 ipaserver.install.bindinstance: ERROR    Named service failed to start (Command '/bin/systemctl restart named-pkcs11.service' returned non-zero exit status 1)
 named service failed to start

The log file /var/log/ipaserver-install.log contains:

2019-11-16T16:39:39Z DEBUG args=/bin/systemctl restart named-pkcs11.service
2019-11-16T16:41:10Z DEBUG Process finished, return code=1
2019-11-16T16:41:10Z DEBUG stdout=
2019-11-16T16:41:10Z DEBUG stderr=Job for named-pkcs11.service failed because a timeout was exceeded. See "systemctl status named-pkcs11.service" and "journalctl -xe" for details.

2019-11-16T16:41:10Z ERROR Named service failed to start (Command '/bin/systemctl restart named-pkcs11.service' returned non-zero exit status 1)

The systemd journal:

journalctl -u named-pkcs11.service
-- Logs begin at Sat 2019-11-16 16:28:05 UTC, end at Sat 2019-11-16 17:01:01 UTC. --
Nov 16 16:39:39 ipa1.example.lan systemd[1]: Starting Berkeley Internet Name Domain (DNS) with native PKCS#11...
Nov 16 16:39:40 ipa1.example.lan bash[6279]: zone localhost.localdomain/IN: loaded serial 0
Nov 16 16:39:40 ipa1.example.lan bash[6279]: zone localhost/IN: loaded serial 0
Nov 16 16:39:40 ipa1.example.lan bash[6279]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
Nov 16 16:39:40 ipa1.example.lan bash[6279]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Nov 16 16:39:40 ipa1.example.lan bash[6279]: zone 0.in-addr.arpa/IN: loaded serial 0
Nov 16 16:39:40 ipa1.example.lan systemd[1]: New main PID 6282 does not belong to service, and PID file is not owned by root. Refusing.
Nov 16 16:39:40 ipa1.example.lan systemd[1]: New main PID 6282 does not belong to service, and PID file is not owned by root. Refusing.
Nov 16 16:41:10 ipa1.example.lan systemd[1]: named-pkcs11.service start operation timed out. Terminating.
Nov 16 16:41:10 ipa1.example.lan systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.
Nov 16 16:41:10 ipa1.example.lan systemd[1]: Unit named-pkcs11.service entered failed state.
Nov 16 16:41:10 ipa1.example.lan systemd[1]: named-pkcs11.service failed.
Nov 16 16:43:29 ipa1.example.lan systemd[1]: Starting Berkeley Internet Name Domain (DNS) with native PKCS#11...
Nov 16 16:43:29 ipa1.example.lan bash[6449]: zone localhost.localdomain/IN: loaded serial 0
Nov 16 16:43:29 ipa1.example.lan bash[6449]: zone localhost/IN: loaded serial 0
Nov 16 16:43:29 ipa1.example.lan bash[6449]: zone 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN: loaded serial 0
Nov 16 16:43:29 ipa1.example.lan bash[6449]: zone 1.0.0.127.in-addr.arpa/IN: loaded serial 0
Nov 16 16:43:29 ipa1.example.lan bash[6449]: zone 0.in-addr.arpa/IN: loaded serial 0
Nov 16 16:43:29 ipa1.example.lan systemd[1]: New main PID 6452 does not belong to service, and PID file is not owned by root. Refusing.
Nov 16 16:43:29 ipa1.example.lan systemd[1]: New main PID 6452 does not belong to service, and PID file is not owned by root. Refusing.
Nov 16 16:44:59 ipa1.example.lan systemd[1]: named-pkcs11.service start operation timed out. Terminating.
Nov 16 16:44:59 ipa1.example.lan systemd[1]: Failed to start Berkeley Internet Name Domain (DNS) with native PKCS#11.
Nov 16 16:44:59 ipa1.example.lan systemd[1]: Unit named-pkcs11.service entered failed state.
Nov 16 16:44:59 ipa1.example.lan systemd[1]: named-pkcs11.service failed.

FreeIPA version:

ipa --version
VERSION: 4.6.5, API_VERSION: 2.231

SELinux:

SELinux status:                 disabled

[adelton]

Running the following command fail :

/usr/sbin/ipa-server-install --hostname=ipa1.example.lan ...

What was the docker run command and how did not run that /usr/sbin/ipa-server-install in the container? Via docker exec?

[Dan33l]

This is via Puppet during acceptance test The Puppet code tested is here : https://gitlab.adullact.net/adullact/puppet-freeipa/blob/master/manifests/install/server/master.pp#L12

Beaker is used for provisioning : https://github.com/puppetlabs/beaker-docker/blob/master/lib/beaker/hypervisor/docker.rb

Edit:: the current acceptance tests are using VMs. But i would like to switch to Docker because containers are less resource consuming

[adelton]

What set of docker commands does it all translate to?

[Dan33l]

The generated Dockerfile is :

FROM centos:7
ENV container docker
RUN yum clean all
RUN yum install -y sudo openssh-server openssh-clients curl ntpdate
RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
RUN mkdir -p /var/run/sshd
RUN echo root:#{root_password} | chpasswd
RUN sed -ri 's/^#?PermitRootLogin .*/PermitRootLogin yes/' /etc/ssh/sshd_config
RUN sed -ri 's/^#?PasswordAuthentication .*/PasswordAuthentication yes/' /etc/ssh/sshd_config
RUN sed -ri 's/^#?UseDNS .*/UseDNS no/' /etc/ssh/sshd_config
RUN cp /bin/true /sbin/agetty
RUN yum install -y crontabs initscripts iproute openssl sysvinit-tools tar wget which ss
EXPOSE 22
CMD ["/sbin/init"]

[adelton]

That Dockerfile does not seem to have anything about FreeIPA server in it ... so I'm not sure how it's relevant.

Or do you say that you run container from this container and then in it you install freeipa-server-dns manually via yum and then run /usr/sbin/ipa-server-install? In that case you might want to compare it to the Dockerfile.centos-7 in this repository so see how the setup provided here differs.

[Dan33l]

After the container is launched via this Dockerfile generated by Beaker, a helper provided by Beaker install a puppet binary. And then, Beaker apply this puppet code in the container: https://gitlab.adullact.net/adullact/puppet-freeipa/blob/master/spec/acceptance/01_freeipa_spec.rb#L10

And this /usr/sbin/ipa-server-install command , embedded in the Puppet code, is executed: https://gitlab.adullact.net/adullact/puppet-freeipa/blob/master/manifests/install/server/master.pp#L13

And it is this /usr/sbin/ipa-server-install command that fail.

[adelton]

Since the container image is not the one from this repository, I suggest bringing this issue to https://gitlab.adullact.net/adullact/puppet-freeipa. The puppet-freeipa developers will have much better idea than people using this repo what they do and don't do in that container, and will be able to reproduce and debug the issue in detail.

[Dan33l]

Humm i am maintainer of puppet-freeipa module.

I created an issue here, as suggested in IRC channel #freeipa, to get some help to understand why the named process refuse to start in our Docker environment.

Probably a requirement is not present, but i was not able to find which one.

Edit : On a true VM, all works as expected.

[adelton]

On Fedora 31 host with moby-engine-18.09.8-2.ce.git0dd43dd.fc31.x86_64, when I run

host# docker run --name=ipa -h ipa1.example.lan --tmpfs /run -v /sys/fs/cgroup:/sys/fs/cgroup:ro --rm -ti registry.centos.org/centos:7 /usr/sbin/init

and then in another terminal

host# docker exec -ti ipa bash
[root@ipa1 /]# yum install -y ipa-server-dns
[...]
[root@ipa1 /]# ipa-server-install --realm=EXAMPLE.LAN --domain=example.lan --admin-password='s^ecr@et.ea;R/O*=?j!.QsAu+$' --ds-password='s^ecr@et.ea;R/O*=?j!.QsAu+$' --setup-dns --auto-reverse --no-forwarders --idstart=10000 --unattended

in passes up to

  [6/7]: creating replica keys
  [7/7]: configuring ipa-dnskeysyncd to start on boot
Done configuring DNS key synchronization service (ipa-dnskeysyncd).
Restarting ipa-dnskeysyncd
Restarting named
Updating DNS system records
Configuring client side components
Using existing certificate '/etc/ipa/ca.crt'.
Client hostname: ipa1.example.lan
Realm: EXAMPLE.LAN
DNS Domain: example.lan
IPA Server: ipa1.example.lan
BaseDN: dc=example,dc=lan

Skipping synchronizing time with NTP server.
New SSSD config will be created
Configured sudoers in /etc/nsswitch.conf
Configured /etc/sssd/sssd.conf
trying https://ipa1.example.lan/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://ipa1.example.lan/ipa/json'
trying https://ipa1.example.lan/ipa/session/json
[try 1]: Forwarding 'ping' to json server 'https://ipa1.example.lan/ipa/session/json'
[try 1]: Forwarding 'ca_is_enabled' to json server 'https://ipa1.example.lan/ipa/session/json'
Systemwide CA database updated.
SSSD enabled
Configured /etc/openldap/ldap.conf
/etc/ssh/ssh_config not found, skipping configuration
/etc/ssh/sshd_config not found, skipping configuration
Configuring example.lan as NIS domain.
Command '/bin/systemctl restart rhel-domainname.service' returned non-zero exit status 1
The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information

I'd recommend starting your investigation with that, with as little things and as little options as possible.

[And202403]

Are there any news about solving this problem ?

[adelton]

It seemed that the OP was in 2019 using some setup from some other git repository but he did not show the exact docker run that he's using. So there really isn't a "this problem" to solve, at least not one related to this repository.

If you are hitting a specific problem while using this specific repo or images built from it, please open a new issue describing your specific situation.