I hit the exact same issue, thanks for confirming this. Basically one run (other than cert request run) in kickstart is not possible for puppet to completely configure a node in LDAP environment.
On 3/10/11, Daniel Pittman <dan...@puppetlabs.com> wrote: > Actually, it is worse than that: it is "libc, as used by Ruby, as used > by Puppet"; we are several layers abstracted from the NSS data source, > and if that doesn't dynamically update we are totally stuck. Which I > understand to be the root cause here. > > Regards, > Daniel > > On Tue, Mar 8, 2011 at 12:48, Disconnect <dc.disconn...@gmail.com> wrote: >> If you are changing how the system sees users (eg before the run, 'id >> user' >> would fail) then the "some provider" is puppet. >> >> The workaround is to do two runs - a bootstrap base environment that sets >> up >> ldap, then a second run that uses those users. >> >> On Thu, Feb 17, 2011 at 6:50 AM, Felix Frank >> <felix.fr...@alumni.tu-berlin.de> wrote: >>> >>> On 02/15/2011 11:49 PM, Jay N. wrote: >>> > Hi Puppet Users, >>> > >>> > In my configuration, I modify in the "pre" stage the ldap.conf file >>> > which is originally generic and useless. >>> > >>> > Then, in the main stage, I try to modify the ownership of files with >>> > ldap users and groups and I have an error "Cannot find user/group". >>> > >>> > I have done several tests : >>> > - just after the modification of the ldap.conf, I added an exec >>> > object : 'id any_ldap_user' and it worked but there were always the >>> > error when modifying the ownership of files >>> > - when I do a second puppet pass just after the first without any >>> > modification, it works and the modifications are applied >>> > >>> > It's like the modification of the ldap.conf wasn't taken into account. >>> > >>> > Any clue? >>> >>> Hi, >>> >>> apparently some provider reads your LDAP DB upon initialization, and >>> cannot catch on to your changes mid-run. >>> >>> Is there a fact that changes when LDAP was configured (during your first >>> run)? If so, you could ignore all the dependent resources if LDAP isn't >>> ready prior to your run (puppet reads facts at startup, too). >>> A custom fact will work for this as well. >>> >>> HTH, >>> Felix >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Users" group. >>> To post to this group, send email to puppet-users@googlegroups.com. >>> To unsubscribe from this group, send email to >>> puppet-users+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/puppet-users?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-users@googlegroups.com. >> To unsubscribe from this group, send email to >> puppet-users+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > > > -- > ⎋ Puppet Labs Developer – http://puppetlabs.com > ✉ Daniel Pittman <dan...@puppetlabs.com> > ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 > ♲ Made with 100 percent post-consumer electrons > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
