On Mon, Jul 16, 2012 at 7:53 AM, jcbollinger <john.bollin...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
