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][email protected]. > 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:[email protected] > 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 [email protected]. 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.
