Hi! On my servers, i''m using pam-ldap and cie. All the configuration of the system is done by puppet. After to the system installation, when i run puppet, in a first time, puppet sets up the ldap configuration and after, the services installation and configuration. While setting up of one of these services, puppet doesn''t find a user which is provided by LDAP. When i launch again puppet, the user is found. I think that puppet stores in it''s cache the list of the users of the system, but when ldap is up, puppet doesn''t reload it''s cache to find new users. It''s there a way to do this ? Thank you for your support -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/L2o0C_vGeJwJ. 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 Sunday, July 15, 2012 4:01:13 PM UTC-5, Thomas Bétrancourt wrote:> > Hi! > > On my servers, i''m using pam-ldap and cie. > > All the configuration of the system is done by puppet. > > After to the system installation, when i run puppet, in a first time, > puppet sets up the ldap configuration and after, the services installation > and configuration. > > While setting up of one of these services, puppet doesn''t find a user > which is provided by LDAP. When i launch again puppet, the user is found. >When you say "puppet doesn''t find", do you mean that in the context of a User resource, or do you simply mean that the user is not visible on the system?> > I think that puppet stores in it''s cache the list of the users of the > system, but when ldap is up, puppet doesn''t reload it''s cache to find new > users. >If you mean that the *system* doesn''t see your LDAP user then that''s not inherently a Puppet problem. It could be a problem with a caching service provided by the system, such as nscd. Alternatively, it may be that resources are not being applied in the order you expect. Unless you declare ordering relationships between resources, you cannot predict the relative order in which they will be applied. The log will show the order in which resources are actually applied. On the other hand, if you mean that Puppet itself doesn''t recognize a User resource present in LDAP then you have probably analyzed the situation correctly. It is a common pattern for the "providers" of Puppet resource types to pre-load all existing instances of the resource type they manage. I have not checked, but it would expect the User providers to be among those.> > It''s there a way to do this ? >Maybe. If your problem is of the first type, then defining appropriate relationships among your resources will probably take care of it pretty easily. If your problem is of the second type, then you may be able to resolve it by setting up relationships that cause LDAP to be set up before *any* User resource is synced. For example, if you have a class "ldap::config" that ensures the system is correctly configured for LDAP access, then you could make this this declaration be parsed after all User resources have been declared: Class[''ldap::config''] -> User<| |> Do note that that particular declaration will, I think, also realize all virtual User resources, so it''s probably more useful for testing than for production. On the other hand, if you are hoping for Puppet to use the "ldap" User provider to manage an LDAP user, then you may be out of luck. Puppet determines very early which providers are applicable to the target node, based mostly on node facts and available system binaries. It is a well-known Puppet limitation that you cannot use a provider in the same Puppet run that installs its dependencies. If you want Puppet to be able to use the "ldap" User provider on its first run, then you need to ensure at least that the client software is installed during the initial provisioning. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/pWdvzP5kXW4J. 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 Mon, Jul 16, 2012 at 7:53 AM, jcbollinger <John.Bollinger@stjude.org> wrote:> > > On Sunday, July 15, 2012 4:01:13 PM UTC-5, Thomas Bétrancourt wrote: >> >> Hi! >> >> On my servers, i''m using pam-ldap and cie. >> >> All the configuration of the system is done by puppet. >> >> After to the system installation, when i run puppet, in a first time, >> puppet sets up the ldap configuration and after, the services installation >> and configuration. >> >> While setting up of one of these services, puppet doesn''t find a user >> which is provided by LDAP. When i launch again puppet, the user is found. > > > When you say "puppet doesn''t find", do you mean that in the context of a > User resource, or do you simply mean that the user is not visible on the > system? > >> >> >> I think that puppet stores in it''s cache the list of the users of the >> system, but when ldap is up, puppet doesn''t reload it''s cache to find new >> users. > > > If you mean that the system doesn''t see your LDAP user then that''s not > inherently a Puppet problem. It could be a problem with a caching service > provided by the system, such as nscd. Alternatively, it may be that > resources are not being applied in the order you expect. Unless you declare > ordering relationships between resources, you cannot predict the relative > order in which they will be applied. The log will show the order in which > resources are actually applied. > > On the other hand, if you mean that Puppet itself doesn''t recognize a User > resource present in LDAP then you have probably analyzed the situation > correctly. It is a common pattern for the "providers" of Puppet resource > types to pre-load all existing instances of the resource type they manage. > I have not checked, but it would expect the User providers to be among > those. > >> >> >> It''s there a way to do this ? > > > Maybe. If your problem is of the first type, then defining appropriate > relationships among your resources will probably take care of it pretty > easily. > > If your problem is of the second type, then you may be able to resolve it by > setting up relationships that cause LDAP to be set up before any User > resource is synced. For example, if you have a class "ldap::config" that > ensures the system is correctly configured for LDAP access, then you could > make this this declaration be parsed after all User resources have been > declared: > > Class[''ldap::config''] -> User<| |> > > Do note that that particular declaration will, I think, also realize all > virtual User resources, so it''s probably more useful for testing than for > production. > > On the other hand, if you are hoping for Puppet to use the "ldap" User > provider to manage an LDAP user, then you may be out of luck. Puppet > determines very early which providers are applicable to the target node, > based mostly on node facts and available system binaries. It is a > well-known Puppet limitation that you cannot use a provider in the same > Puppet run that installs its dependencies. If you want Puppet to be able to > use the "ldap" User provider on its first run, then you need to ensure at > least that the client software is installed during the initial provisioning.This last issue is something that should have been fixed in 2.7.8. In the past providers had to be modified as optional_command, but this is no longer necessary. Resource order still matters, but we are able to install mysql and manage mysql database using a type and provider in the same run as an example. For more details, see: http://projects.puppetlabs.com/issues/6907. Thanks, Nan -- 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.
This is likely a factor of how unix works rather than puppet. When puppet starts up, it reads nsswitch.conf. If you modify nsswitch.conf during the puppet run, it will not see the changes until after the process has restarted and sees the new nsswitch.conf file. I have gotten around this by putting the LDAP config in a stage prior to main and restarting puppet within that stage, so that puppet restarts itself before processing the main stage. It''s a bit clunky and painful to manage the dependancy trees, but it works. On Jul 15, 2012, at 2:01 PM, Thomas Bétrancourt wrote:> On my servers, i''m using pam-ldap and cie. > > All the configuration of the system is done by puppet. > > After to the system installation, when i run puppet, in a first time, puppet sets up the ldap configuration and after, the services installation and configuration. > > While setting up of one of these services, puppet doesn''t find a user which is provided by LDAP. When i launch again puppet, the user is found. > > I think that puppet stores in it''s cache the list of the users of the system, but when ldap is up, puppet doesn''t reload it''s cache to find new users. > > It''s there a way to do this ? > > Thank you for your support > > -- > You received this message because you are subscribed to the Google Groups "Puppet Users" group. > To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/L2o0C_vGeJwJ. > 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.-- Jo Rhett Net Consonance : net philanthropy to improve open source and internet projects. -- 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.
Reasonably Related Threads
- centos 6.2 - puppet 2.7.13 - SSL_connect returned=1 errno=0 state=SSLv3 read server session ticket A: tlsv1 alert protocol version
- User's and managing expired passwords
- Solaris 10 Client "Default Provider for User" Woes Again
- Terminology merging
- Trouble installing packages with Puppet on Arch Linux