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]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+unsubscr...@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+unsubscr...@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 -- 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/20140310140449.GA9842%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/d/optout.
