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 On Mon, Mar 10, 2014 at 9:04 AM, Christopher Wood < [email protected]> 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] > 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. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2BnSE38JBDemrKrbvM9k2%3DottMW1zGVyWD3s3m1rF38WiTdW4w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
