Have to run puppet agent twice to install LDAP and ssh keys.

[Kenton Brede]

I've got a module that installs and configures LDAP for user authentication.  I've got another module that creates user directories and another that assigns ssh keys.

Using runstages I force the "ldap" module to run first and the "user" and "ssh_keys" modules to run last.

LDAP is installed but the exec that creates user directories and the ssh_authorized_key type fail since they can't see the LDAP users.

The reason being, I'm assuming, is because when the manifest is compiled, the LDAP users don't exist.  So ssh_authorized_key fails, even if the LDAP user information can be retrieved, by the time the ssh_keys module runs.

Is there any way around this?

If I run the puppet agent twice, all is well.  It would just be nice to do it in one run.

Thanks,

--

Kent

[Christopher Wood]

(inline)

On Fri, Mar 07, 2014 at 09:39:44AM -0600, Kenton Brede wrote:
> I've got a module that installs and configures LDAP for user
> authentication.� I've got another module that creates user directories and
> another that assigns ssh keys.
>
> Using runstages I force the "ldap" module to run first and the "user" and
> "ssh_keys" modules to run last.
> LDAP is installed but the exec that creates user directories and the
> ssh_authorized_key type fail since they can't see the LDAP users.
>
> The reason being, I'm assuming, is because when the manifest is compiled,
> the LDAP users don't exist.� So ssh_authorized_key fails, even if the LDAP
> user information can be retrieved, by the time the ssh_keys module runs.
>
> Is there any way around this?

Sounds like this somewhere top-scope:

Class['ldap'] -> User <| |>

So your ldap class would have to be successfully managed before puppet tries to manage any users.

http://docs.puppetlabs.com/puppet/latest/reference/lang_relationships.html
http://docs.puppetlabs.com/puppet/latest/reference/lang_collectors.html

> If I run the puppet agent twice, all is well.� It would just be nice to do
> it in one run.
> Thanks,
>
> --
> Kent
>

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [1]puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> [2]https://groups.google.com/d/msgid/puppet-users/CA%2BnSE38wWZn5vgv0bKC8kb5pjtdoQ8hHPK%2BWdajXGdssbOdHpA%40mail.gmail.com.
> For more options, visit [3]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:puppet-users...@googlegroups.com
> 2. https://groups.google.com/d/msgid/puppet-users/CA%2BnSE38wWZn5vgv0bKC8kb5pjtdoQ8hHPK%2BWdajXGdssbOdHpA%40mail.gmail.com?utm_medium=email&utm_source=footer
> 3. https://groups.google.com/d/optout

[jcbollinger]

On Friday, March 7, 2014 11:38:20 AM UTC-6, Christopher Wood wrote:

(inline)

On Fri, Mar 07, 2014 at 09:39:44AM -0600, Kenton Brede wrote:
>    I've got a module that installs and configures LDAP for user
>    authentication.� I've got another module that creates user directories and
>    another that assigns ssh keys.
>
>    Using runstages I force the "ldap" module to run first and the "user" and
>    "ssh_keys" modules to run last.
>    LDAP is installed but the exec that creates user directories and the
>    ssh_authorized_key type fail since they can't see the LDAP users.
>
>    The reason being, I'm assuming, is because when the manifest is compiled,
>    the LDAP users don't exist.� So ssh_authorized_key fails, even if the LDAP
>    user information can be retrieved, by the time the ssh_keys module runs.
>
>    Is there any way around this?

Sounds like this somewhere top-scope:

Class['ldap'] -> User <| |>

So your ldap class would have to be successfully managed before puppet tries to manage any users.

That's what the OP attempts to do via run stages.  Inasmuch as I don't care much for run stages, though, I do prefer the suggested chaining approach.  Nevertheless, if run stages didn't work then chaining probably won't solve the problem either.

I'm inclined to suspect a class containment failure; see http://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html for more information.  Upon further consideration, though, if it's a containment failure then chaining directly to a User<| |> collector might solve it after all.

John

[Christopher Wood]

Now there's a point. Back in the (2.6) day when I had puppet-managed resources in ldap users' home directories I didn't run into the above problem, but I had some require chaining going on.

There could still be other things going on, like nscd caching a previous files lookup or the ldap configuration in question returning intermittent false results (timeout, load balancer choke, incorrect search filter). If I had my hands on this system I might check with tcpdump whether there are any ldap searches performed while puppet is attempting to manage user-dependent resources, which would give further hints where the issue might lie.

> I'm inclined to suspect a class containment failure; see

> [1]http://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html

> for more information.  Upon further consideration, though, if it's a
> containment failure then chaining directly to a User<| |> collector might
> solve it after all.
>
> John
>

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [2]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [3]https://groups.google.com/d/msgid/puppet-users/f8225371-7b34-492a-bab8-8395caaaecdf%40googlegroups.com.
> For more options, visit [4]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. http://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html
> 2. mailto:puppet-users...@googlegroups.com
> 3. https://groups.google.com/d/msgid/puppet-users/f8225371-7b34-492a-bab8-8395caaaecdf%40googlegroups.com?utm_medium=email&utm_source=footer
> 4. https://groups.google.com/d/optout

[Kenton Brede]

OK, stages and chaining doesn't seem to work.  I'm running Puppet 3.4.3. 

The following is executing in order but I still get fails on Users::Admin_homedir_define and Ssh_authorized_key.

Class [ 'ldap_auth' ] -> Exec <| title == 'disable_selinux' |> -> Users::Admin_homedir_define <||> -> Ssh_authorized_key <||>

Ldap_auth installs needed ldap packages, runs authconfig and takes care of some config file changes.  LDAP auth should be configured and working just after SELinux is disabled.  Users::Admin_homedir_define consists of a file type and just creates home directories, /home/$name.

If I do a "puppet agent -t --tags "ldap_auth,files"" LDAP auth is configured and works fine.

I did a tcpdump and discovered that there is no attempt to communicate with the LDAP server during the run of "puppet agent -t."  I'm not sure why.

I put a 60 second sleep between disable_selinux and Users::Admin_homedir.  I backgrounded "puppet agent -t" and verified LDAP auth was working.  Once I fg the process, the file type fails, not able to find the user.

Info: /Stage[main]/Ldap_auth/Exec[added_lines_nslcd]: Scheduling refresh of Service[nslcd]
Notice: /Stage[main]/Ldap_auth/Service[nslcd]: Triggered 'refresh' from 1 events
Notice: /Stage[main]/Files::Common/Exec[disable_selinux]/returns: executed successfully
Error: Could not set 'directory' on ensure: Could not find user user1 at 9:/etc/puppet/modules/users/manifests/admin_homedir_define.pp
Error: Could not set 'directory' on ensure: Could not find user user1 at 9:/etc/puppet/modules/users/manifests/admin_homedir_define.pp
Wrapped exception:
Could not find user user1
Error: /Stage[main]/Users::Ldap/Users::Admin_homedir_define[user1]/File[/home/user1]/ensure: change from absent to directory failed: Could not set 'directory' on ensure: Could not find user user1 at 9:/etc/puppet/modules/
users/manifests/admin_homedir_define.pp

Anyway.  I think I'm going to give up on this and just do a "puppet agent -t --tags ldap_auth && puppet agent -t" for the first run on new boxes.  That works every time. :)

Thanks for looking into this.
Kent

To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140310140449.GA9842%40iniquitous.heresiarch.ca.

For more options, visit https://groups.google.com/d/optout.

--

Kent Brede

[Christopher Wood]

(inline)

On Mon, Mar 10, 2014 at 04:29:30PM -0500, Kenton Brede wrote:
> OK, stages and chaining doesn't seem to work.  I'm running Puppet 3.4.3. 
>
> The following is executing in order but I still get fails on
> Users::Admin_homedir_define and Ssh_authorized_key.
>
> Class [ 'ldap_auth' ] -> Exec <| title == 'disable_selinux' |> ->
> Users::Admin_homedir_define <||> -> Ssh_authorized_key <||>
>
> Ldap_auth installs needed ldap packages, runs authconfig and takes care of
> some config file changes.  LDAP auth should be configured and working just
> after SELinux is disabled.  Users::Admin_homedir_define consists of a file
> type and just creates home directories, /home/$name.
>
> If I do a "puppet agent -t --tags "ldap_auth,files"" LDAP auth is
> configured and works fine.
>
> I did a tcpdump and discovered that there is no attempt to communicate
> with the LDAP server during the run of "puppet agent -t."  I'm not sure
> why.
>
> I put a 60 second sleep between disable_selinux and Users::Admin_homedir. 
> I backgrounded "puppet agent -t" and verified LDAP auth was working.  Once
> I fg the process, the file type fails, not able to find the user.

I think you've found something interesting, namely that puppet/ruby itself appears to be not using your new ldap configuration inside of a single agent run process. It does work to break out ldap configuration and everything else into two agent runs. This implies that something about name lookups is being read when puppet starts, and then sticks around until the end of the child process. (I could just be rhubarbing on.)

If you recreationally wanted to see what gives and maybe file a bug report, you could compare two sets of puppet/nslcd strace/ltrace:

a) agent run in the original form, ldap+users in the same run
b) agent run in the second form as below

Also, if nscd is running, uninstalling it will provide more clarity in troubleshooting.

>  [1][2]http://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html

> >    for more information.  Upon further consideration, though, if it's
> a
> >    containment failure then chaining directly to a User<| |> collector
> might
> >    solve it after all.
> >
> >    John
> >
> >    --
> >    You received this message because you are subscribed to the Google
> Groups
> >    "Puppet Users" group.
> >    To unsubscribe from this group and stop receiving emails from it,
> send an

> >    email to [2][3]puppet-users...@googlegroups.com.

> >    To view this discussion on the web visit
> >  

>  [3][4]https://groups.google.com/d/msgid/puppet-users/f8225371-7b34-492a-bab8-8395caaaecdf%40googlegroups.com.
> >    For more options, visit [4][5]https://groups.google.com/d/optout.
> >
> > References
> >
> >    Visible links
> >    1.
> [6]http://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html
> >    2. mailto:[7]puppet-users...@googlegroups.com
> >    3.
> [8]https://groups.google.com/d/msgid/puppet-users/f8225371-7b34-492a-bab8-8395caaaecdf%40googlegroups.com?utm_medium=email&utm_source=footer
> >    4. [9]https://groups.google.com/d/optout

> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to [10]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [11]https://groups.google.com/d/msgid/puppet-users/20140310140449.GA9842%40iniquitous.heresiarch.ca.
> For more options, visit [12]https://groups.google.com/d/optout.
>
> --
> Kent Brede
>

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to [13]puppet-users...@googlegroups.com.

> To view this discussion on the web visit

> [14]https://groups.google.com/d/msgid/puppet-users/CA%2BnSE38JBDemrKrbvM9k2%3DottMW1zGVyWD3s3m1rF38WiTdW4w%40mail.gmail.com.
> For more options, visit [15]https://groups.google.com/d/optout.
>
> References
>
> Visible links
> 1. mailto:christop...@pobox.com
> 2. http://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html
> 3. mailto:puppet-users%2Bunsu...@googlegroups.com
> 4. https://groups.google.com/d/msgid/puppet-users/f8225371-7b34-492a-bab8-8395caaaecdf%40googlegroups.com
> 5. https://groups.google.com/d/optout
> 6. http://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html
> 7. mailto:puppet-users%2Bunsu...@googlegroups.com
> 8. https://groups.google.com/d/msgid/puppet-users/f8225371-7b34-492a-bab8-8395caaaecdf%40googlegroups.com?utm_medium=email&utm_source=footer
> 9. https://groups.google.com/d/optout
> 10. mailto:puppet-users%2Bunsu...@googlegroups.com
> 11. https://groups.google.com/d/msgid/puppet-users/20140310140449.GA9842%40iniquitous.heresiarch.ca
> 12. https://groups.google.com/d/optout
> 13. mailto:puppet-users...@googlegroups.com
> 14. https://groups.google.com/d/msgid/puppet-users/CA%2BnSE38JBDemrKrbvM9k2%3DottMW1zGVyWD3s3m1rF38WiTdW4w%40mail.gmail.com?utm_medium=email&utm_source=footer
> 15. https://groups.google.com/d/optout

[jcbollinger]

On Monday, March 10, 2014 4:59:38 PM UTC-5, Christopher Wood wrote:

[...]

I think you've found something interesting, namely that puppet/ruby itself appears to be not using your new ldap configuration inside of a single agent run process. It does work to break out ldap configuration and everything else into two agent runs. This implies that something about name lookups is being read when puppet starts, and then sticks around until the end of the child process. (I could just be rhubarbing on.)

Indeed, this feels like a libc issue.  I would have no problem whatsoever believing that the name service switch configuration is read just once, when the program loads, that modules not then available are not used, and that changes to the config made after program startup are not seen by that instance of the program.  In fact, although I can't find docs at the moment, my comments are partially informed by a vague (possibly erroneous) recollection that NSS works exactly that way.

That might produce particularly confusing results with Puppet, because Puppet performs such a mix of forking external programs for some tasks and using in-process Ruby for other tasks -- the former type of tasks would likely see the NSS changes, but the latter wouldn't.

 

If you recreationally wanted to see what gives and maybe file a bug report, you could compare two sets of puppet/nslcd strace/ltrace:

a) agent run in the original form, ldap+users in the same run
b) agent run in the second form as below

Also, if nscd is running, uninstalling it will provide more clarity in troubleshooting.

Yes, nscd can muddle the waters, but you should be able to get away with just turning it off.  It's especially pesky, though, so whether you turn it off or remove it altogether you may need to reboot to completely clear it out.

John