On Wednesday, September 3, 2014 4:10:11 PM UTC-5, Tamás PAPP wrote: > > > On 09/03/2014 08:20 PM, jcbollinger wrote: > > > > There are several viable solutions. I would favor putting your users and > groups under management, and keeping (user, group) relationships in your > external data. Then you could choose the correct group for any given user > by, say, looking up the username in a hash. Strictly speaking, it is not > mandatory in that case to put the users and groups under management, but > doing so makes sense if you are relying on anything about them, including > their existence. You then don't need to worry about how users and groups > initially *are*, which is comparatively hard to know, but rather on how > they *will be*, which would be easy to know. > > > There are system and ldap users as well, I cannot manage all of them by > puppet. > The users, their database is already there so I need to adapt the rest of > the system. > > If you need to discover user -> group mappings for a small number of users whom the node you can identify in advance of catalog compilation, then you can write a custom fact by which to communicate that information to the master. That does not seem to be your situation, however.
Where the agent needs to perform an evaluation such as you describe during catalog application, the canonical approach is to write a custom type and provider. Since that's non-trivial, I think it's fairly common to use an Exec instead. All resource properties recorded in the catalog are constants; you cannot embed a command as if catalogs were scripts. 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/364edbeb-89d9-4a80-8fbf-e6556eeaeccd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
