Sounds like a job better suited for ENC/inventory. IMO. On Wed, Aug 10, 2011 at 2:13 PM, Craig White <craig.wh...@ttiltd.com> wrote:
> > On Aug 10, 2011, at 11:50 AM, Daniel Pittman wrote: > > > On Wed, Aug 10, 2011 at 18:31, Craig White <craig.wh...@ttiltd.com> > wrote: > >> > >> what I am trying to do is execute a shell script on the puppetmaster... > essentially add 'host' attribute to specific ldap users. That's why the > command has parameters... > >> > >> shellscript HOSTNAME GROUP > > > > OK. > > > >> the script is more than capable of getting the users from GROUP, adding > host attribute HOSTNAME to each of the users but it must run on the > puppetmaster, not on puppet clients which is why I am using the generate > function. So in answer to your question, my ldap-add-host.sh script is > actually creating things. > >> > >> yes, it is idempotent - I can run it and run it and it will always do > the same thing but and if uid=craig already has 'host' ubuntu.ttinet, it > will simply move on if I try to add it again. I could almost live with that > except that if I manually remove 'host' ubuntu.ttinet from uid=craig, the > next pass it will add it again so I need some method of tracking it so > therefore I was trying to use 'unless' which is only available in an exec > resource, not a file resource. I suppose if I had no alternative, I could > maintain a list on the puppetmaster of which hosts have already been added > to which groups and abort if it has already been done. > > > > OK. So, yeah. `generate` doesn't do what you want: functions don't > > take parameters of any sort, let alone resource level metaparameters. > > > > You will need to implement all your logic in the script you invoke > > from generate, so that it will avoid doing things twice when called > > with the same arguments. > > > > > > ...and if you are wondering why this seems so hard? This really isn't > > something that Puppet is designed to support. Generally, modifying > > external data sources from Puppet like you are trying to do isn't > > really the way we approach things. Better, we feel, to modify the > > external data source and then draw read-only from that into the > > manifest. > > > > So, rather than calling generate to modify LDAP, instead modify LDAP > > and have code in your manifest to do whatever stuff when the LDAP > > changes have been applied. > > > > You can do it the way you are trying, more or less, but you really > > don't get much help from the tool.s > ---- > I modified my shell script to keep track of what has already been added to > LDAP and return a constant result if already added. It's really neat how > standard output from the generate command ends up as the content of a 'file' > on the client but yes, the 'generate' command will run each time the puppet > client runs because the only way it can decide what the content actually is > going to be is by running again and comparing with the file that is (or > isn't) on the client already. In my methodology, I already had a directory > /etc/puppet/deployment_files for keeping track of things so it was a simple > task to have file resources for things that really aren't a file on a normal > server but triggers for actions (or inaction) by puppet. > > I never really wondered why or even thought it was hard to accomplish this > because I definitely understand that processing is really targeted at the > client level. > > But I am sure you understand the desire to integrate more than just the > clients - in this case, we are dealing with a large set of knowns... > - the new host/node > - ldap configuration from the first puppet run that implements host based > access control > - the members of specific groups > - the distribution of sudoers 'include' files for these groups > > and thus the only missing link was the ability to actually be able to log > into these hosts was for admins to have the host attributes set for the new > hosts. This was separately scripted and I just needed the missing link and > that was provided to me by generate... not perfect, not exactly how I would > have wanted it but definitely workable. > > Thanks for the help - it was invaluable and made this a relatively simple > task > > Craig > > -- > 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.
