(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. > 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 > > On Mon, Mar 10, 2014 at 9:04 AM, Christopher Wood > <[1]christopher_w...@pobox.com> wrote: > > On Mon, Mar 10, 2014 at 06:35:12AM -0700, jcbollinger wrote: > > 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. > > 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][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+unsubscr...@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+unsubscr...@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+unsubscr...@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+unsubscr...@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:christopher_w...@pobox.com > 2. http://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html > 3. mailto:puppet-users%2bunsubscr...@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%2bunsubscr...@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%2bunsubscr...@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+unsubscr...@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 -- 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/20140310215938.GA12122%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
