On Fri, 25 Sep 2015, Jan Pazdziora wrote:
On Fri, Sep 25, 2015 at 10:09:55AM +0300, Alexander Bokovoy wrote:
>Well, we have separate daemon listening on the
>/var/run/krb5kdc/DEFAULT.socket in the container which should start
>the ipa-otpd@.service when there's a connection made to it. But
>somehow it does not seem to be happening even if I fix the parsing of
>/etc/ipa/default.conf that ipa-otpd@.service is doing.
As I wrote earlier, ipa-otpd relies on socket activation feature of
systemd -- systemd opens this socket and listens for incoming
connections. Any incoming connection causes to start ipa-otpd daemon and
connects its stdin/stdout to the socket's client.

And in the container there is no systemd so I emulate it there by just
running a separate daemon listening on that socket which will fork
that ipa-otpd daemon.
You did write another daemon? socat is enough.

>What is the simplest way to trigger the connection to
>/var/run/krb5kdc/DEFAULT.socket, for debugging purposes?
Use socat. Something like
socat UNIX-LISTEN:/var/run/krb5kdc/DEFAULT.socket,unlink-early,fork 

I meant, how do I cause the IPA stack (KDC?) to make the connection
and communication with the ipa-otpd daemon?
Enable OTP tokens globally or for specific user in web UI, restart KDC.

Create OTP token for a user and try to login via SSSD.

Also, does the Sync OTP Token operation invoke the ipa-otpd daemon
path (so if Duncan managed to sync the token, it worked for him at
least once) in any way or does it bypass it?
No. It uses LDAP extended operation.

/ Alexander Bokovoy

Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to