Anyone, How can I guarantee that all components of the LDAP client module get installed before ANY components of any other module? The need for this is driven from the fact that various packages will often install a local user. In order to make sure that that id''s of any of these local users do not clash with id''s from LDAP users, the ldap client configuration needs to be fully deployed first. When the RPM adds the user as part of it''s pre/post install script, and useradd calls getpwent, since ldap is already up, the same user id will not get re-used. This is another one of those situations where the ability to have modules fully installed in order they are listed would be hugely beneficial. Doug. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hey Douglas Douglas Garstang wrote:> How can I guarantee that all components of the LDAP client module get > installed before ANY components of any other module?Take a look at the new Run Stages[1] functionality in Puppet 2.6. Run stages would allow you to specify that the LDAP class has to run first before any other module is actioned. cYa, Avi [1] http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#Run+Stages -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jul 21, 2010, at 4:29 PM, Douglas Garstang wrote:> Anyone, > > How can I guarantee that all components of the LDAP client module get > installed before ANY components of any other module?Use 2.6.x and use run stages. -OR- Use 0.25.x and make all User and Package resources depend on that class.> This is another one of those situations where the ability to have > modules fully installed in order they are listed would be hugely > beneficial.Making everything install in the order it''s listed means you can''t explicitly specify dependencies. Explicit dependencies are one of the reasons I really like using puppet over shell scripts. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Jul 21, 2010 at 4:32 PM, Avi Miller <avi.miller@gmail.com> wrote:> Hey Douglas > > Douglas Garstang wrote: >> >> How can I guarantee that all components of the LDAP client module get >> installed before ANY components of any other module? > > Take a look at the new Run Stages[1] functionality in Puppet 2.6. Run stages > would allow you to specify that the LDAP class has to run first before any > other module is actioned.So... the release notes have an example: class yum { ... } class redhat { ... class { yum: stage => pre } } followed by the statement: "Note that we’re using the new parameterized classes here – this is necessary because of the class-level limitations of Run Stages. These limitations are present because of the complication of trying to untangle resource dependencies across stage boundaries if we allowed arbitrary resources to specify stages." Any idea what that means? Doug. " -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Jul 21, 2010 at 4:47 PM, Douglas Garstang> "Note that we’re using the new parameterized classes here – this is > necessary because of the class-level limitations of Run Stages. These > limitations are present because of the complication of trying to > untangle resource dependencies across stage boundaries if we allowed > arbitrary resources to specify stages." > > Any idea what that means?It means the design is to specify the run stage at class "level", not resource "level". -- Jeff McCune http://www.puppetlabs.com/ -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I spent a few minutes playing with stages as well and they seem like a great solution to certain problems. Will there be more documentation made available about how to use stages after final release? All I''m familiar with is what''s in the changelog. --Ryan ----- Original Message -----> From: "Douglas Garstang" <doug.garstang@gmail.com> > To: puppet-users@googlegroups.com > Sent: Wednesday, July 21, 2010 7:47:46 PM > Subject: Re: [Puppet Users] Installing a module FIRST > On Wed, Jul 21, 2010 at 4:32 PM, Avi Miller <avi.miller@gmail.com> > wrote: > > Hey Douglas > > > > Douglas Garstang wrote: > >> > >> How can I guarantee that all components of the LDAP client module > >> get > >> installed before ANY components of any other module? > > > > Take a look at the new Run Stages[1] functionality in Puppet 2.6. > > Run stages > > would allow you to specify that the LDAP class has to run first > > before any > > other module is actioned. > > So... the release notes have an example: > > class yum { ... } > class redhat { > ... > class { yum: stage => pre } > } > > followed by the statement: > "Note that we’re using the new parameterized classes here – this is > necessary because of the class-level limitations of Run Stages. These > limitations are present because of the complication of trying to > untangle resource dependencies across stage boundaries if we allowed > arbitrary resources to specify stages." > > Any idea what that means? > > Doug. > > > " > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Jul 21, 2010 at 4:55 PM, Jeff McCune <jeff@puppetlabs.com> wrote:> On Wed, Jul 21, 2010 at 4:47 PM, Douglas Garstang >> "Note that we’re using the new parameterized classes here – this is >> necessary because of the class-level limitations of Run Stages. These >> limitations are present because of the complication of trying to >> untangle resource dependencies across stage boundaries if we allowed >> arbitrary resources to specify stages." >> >> Any idea what that means? > > It means the design is to specify the run stage at class "level", not > resource "level".I was kinda wondering why it was a requirement to use parameterized classes. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Wed, Jul 21, 2010 at 4:44 PM, Patrick Mohr <kc7zzv@gmail.com> wrote:> > On Jul 21, 2010, at 4:29 PM, Douglas Garstang wrote: > >> Anyone, >> >> How can I guarantee that all components of the LDAP client module get >> installed before ANY components of any other module? > > Use 2.6.x and use run stages. > > -OR- > > Use 0.25.x and make all User and Package resources depend on that class.Doing that is a sure fire path to cyclic dependency hell. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Ryan Y. Coleman wrote:> I spent a few minutes playing with stages as well and they seem like > a great solution to certain problems. Will there be more > documentation made available about how to use stages after final > release? All I''m familiar with is what''s in the changelog. >We''ve had final release. :) We don''t currently have any additional documentation but I''ll have a chat with Jeff, Dan et al about some additional notes. Regards James Turnbull -- Puppet Labs - http://www.puppetlabs.com C: 503-734-8571 -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jul 21, 2010, at 5:16 PM, Douglas Garstang wrote:> On Wed, Jul 21, 2010 at 4:44 PM, Patrick Mohr <kc7zzv@gmail.com> wrote: >> >> On Jul 21, 2010, at 4:29 PM, Douglas Garstang wrote: >> >>> Anyone, >>> >>> How can I guarantee that all components of the LDAP client module get >>> installed before ANY components of any other module? >> >> Use 2.6.x and use run stages. >> >> -OR- >> >> Use 0.25.x and make all User and Package resources depend on that class. > > Doing that is a sure fire path to cyclic dependency hell. >I''ll grant you that. I did it for that package setup, but it was very annoying. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Jul 21, 2010, at 7:29 PM, Douglas Garstang wrote:> The need for this is driven from the fact that various packages will > often install a local user. In order to make sure that that id''s of > any of these local users do not clash with id''s from LDAP users, the > ldap client configuration needs to be fully deployed first. When the > RPM adds the user as part of it''s pre/post install script, and useradd > calls getpwent, since ldap is already up, the same user id will not > get re-used.Slightly OT, but is that any better? Say the last user in LDAP has a UID of 2000. A package creates a new local user and picks 2001 for the UID. Sometime later, you create a new user in LDAP. Since it isn’t aware of any local accounts, it also gets a UID of 2001 and now you have a conflict anyway. And besides, don’t most of the RPMs create the accounts they need with a specific, low numbered UID, rather than just picking the next available? FWIW, We started numbering our LDAP users at 1100 to avoid such conflicts. -- Rob McBroom <http://www.skurfer.com/> -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.