Keytab join runs on every Puppet refresh

[Socob]

The two Execs run_kinit_with_keytab and realm_join_with_keytab have an unless clause specifying that they should only run if the command kinit -k host/$(hostname -f) does not run successfully. However, this test doesn’t work on our setup (Ubuntu 17.04 machine in an Active Directory domain):

$ kinit -k host/$(hostname -f)
kinit: Keytab contains no suitable keys for host/test.example.com@EXAMPLE.COM while getting initial credentials

Consequently, the keytab join to the domain is executed every time Puppet runs, which is not desirable.

This test was added in fd73597. Before, the unless clause was unless => "klist -k /etc/krb5.keytab | grep -i '${::hostname[0,15]}@${_domain}'", which worked for us (see the output of klist -k /etc/krb5.keytab below). Unfortunately, I don’t know enough about Kerberos to understand why this change was made or what the pros and cons of each version are, but the way it is right now isn’t working for us.

This is the output of klist -k /etc/krb5.keytab, in case it helps:

# klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 TEST$@EXAMPLE.COM
   3 TEST$@EXAMPLE.COM
   3 TEST$@EXAMPLE.COM
   3 TEST$@EXAMPLE.COM
   3 TEST$@EXAMPLE.COM
   3 TEST$@EXAMPLE.COM
   3 host/TEST@EXAMPLE.COM
   3 host/TEST@EXAMPLE.COM
   3 host/TEST@EXAMPLE.COM
   3 host/TEST@EXAMPLE.COM
   3 host/TEST@EXAMPLE.COM
   3 host/TEST@EXAMPLE.COM
   3 host/test@EXAMPLE.COM
   3 host/test@EXAMPLE.COM
   3 host/test@EXAMPLE.COM
   3 host/test@EXAMPLE.COM
   3 host/test@EXAMPLE.COM
   3 host/test@EXAMPLE.COM
   3 RestrictedKrbHost/TEST@EXAMPLE.COM
   3 RestrictedKrbHost/TEST@EXAMPLE.COM
   3 RestrictedKrbHost/TEST@EXAMPLE.COM
   3 RestrictedKrbHost/TEST@EXAMPLE.COM
   3 RestrictedKrbHost/TEST@EXAMPLE.COM
   3 RestrictedKrbHost/TEST@EXAMPLE.COM
   3 RestrictedKrbHost/test@EXAMPLE.COM
   3 RestrictedKrbHost/test@EXAMPLE.COM
   3 RestrictedKrbHost/test@EXAMPLE.COM
   3 RestrictedKrbHost/test@EXAMPLE.COM
   3 RestrictedKrbHost/test@EXAMPLE.COM
   3 RestrictedKrbHost/test@EXAMPLE.COM
   4 TEST$@EXAMPLE.COM
   4 TEST$@EXAMPLE.COM
   4 TEST$@EXAMPLE.COM
   4 TEST$@EXAMPLE.COM
   4 TEST$@EXAMPLE.COM
   4 host/TEST@EXAMPLE.COM
   4 host/TEST@EXAMPLE.COM
   4 host/TEST@EXAMPLE.COM
   4 host/TEST@EXAMPLE.COM
   4 host/TEST@EXAMPLE.COM
   4 host/test@EXAMPLE.COM
   4 host/test@EXAMPLE.COM
   4 host/test@EXAMPLE.COM
   4 host/test@EXAMPLE.COM
   4 host/test@EXAMPLE.COM
   4 RestrictedKrbHost/TEST@EXAMPLE.COM
   4 RestrictedKrbHost/TEST@EXAMPLE.COM
   4 RestrictedKrbHost/TEST@EXAMPLE.COM
   4 RestrictedKrbHost/TEST@EXAMPLE.COM
   4 RestrictedKrbHost/TEST@EXAMPLE.COM
   4 RestrictedKrbHost/test@EXAMPLE.COM
   4 RestrictedKrbHost/test@EXAMPLE.COM
   4 RestrictedKrbHost/test@EXAMPLE.COM
   4 RestrictedKrbHost/test@EXAMPLE.COM
   4 RestrictedKrbHost/test@EXAMPLE.COM

[carceneaux]

Bump - Is this just semantics? Most modules I've seen simply apply and then are good unless they have to fix something. This module applies and refreshes this on every Puppet run. If this is acceptable behavior, please let me know but it seems to me like @Socob pointed out, a necessary check in place could forego this repetitive action.

[walkamongus]

@carceneaux @Socob I think you are both correct and will revert this check to the previous version.

[walkamongus]

fix pushed up

[walkamongus]

2.2.0 pushed to forge

[carceneaux]

Awesome! Thanks!