Hello, I''m scratching my head as to the best way to plug in a script to do some client configuration. The script is about 40 lines long (full of basic instructions to fiddle with VCS in fact). Lots of execs would seems cumbersome. My thoughts are to simply install this to the client (via the fileserver) and exec out to it. Does this seem sensible? And if so, be aware of things like this for the Best Practice document. Furthermore, should we be looking to a way of pulling over whole directories to streamline this further? Thoughts? Derek ------------------------------------------------------------------------ For important statutory and regulatory disclosures and more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ------------------------------------------------------------------------
On 11 June , 2007, at 05:09, <Derek.Whayman@barclayscapital.com> <Derek.Whayman@barclayscapital.com> wrote:> Hello, > > I'm scratching my head as to the best way to plug in a script to do > some > client configuration. The script is about 40 lines long (full of > basic > instructions to fiddle with VCS in fact). > > Lots of execs would seems cumbersome. My thoughts are to simply > install > this to the client (via the fileserver) and exec out to it. > > Does this seem sensible? And if so, be aware of things like this for > the Best Practice document.How sensible it seems, in my mind, depends on what this script is doing… If it is a script that is run once at OS-install time, perhaps it would be better to include that as part of the machine customization process and include the script in your kickstart/jumpstart/kickstand configuration. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jun 11, 2007, at 4:09 AM, <Derek.Whayman@barclayscapital.com> wrote:> Hello, > > I''m scratching my head as to the best way to plug in a script to do > some > client configuration. The script is about 40 lines long (full of > basic > instructions to fiddle with VCS in fact). > > Lots of execs would seems cumbersome. My thoughts are to simply > install > this to the client (via the fileserver) and exec out to it. > > Does this seem sensible? And if so, be aware of things like this for > the Best Practice document.That''s what I would recommend, as long as you''ve got some way to know whether the script has already run, so it only runs when necessary.> Furthermore, should we be looking to a way of pulling over whole > directories to streamline this further?I know that''s what I always did when I managed larger networks -- I maintained a "scripts" directory that I always pulled down to all of my hosts (or that I NFS mounted on them). -- I''m worried about Bart. Today, he''s sucking people''s blood, tommorrow he might be smoking. -Marge Simpson --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
>> How sensible it seems, in my mind, depends on what this script isdoing... The script is setting up a bunch of basic VCS services & monitors, things which are a bit much to expect Puppet to have types for. This particular one only needs running once, but who''s to say we won''t have things which need doing reguarly. It''s not too big a deal to make your maintenance scripts idempotent.>> If it is a script that is run once at OS-install time, perhaps itwould be better to include that as part of the>> machine customization process and include the script in yourkickstart/jumpstart/kickstand configuration. We currently have large, tangled and unmanageable postinstall scripts. The idea is to replace them with an absolutely minimal install (a few packages and Puppet). Then, Puppet would control the machine install and customisation process and also revert any files that have been tampered with subsequently. I expect the 80/20 rule to apply in terms of what can be done with the built in types. This case covers the things you don''t necessarily get out of the box. I think it''s unrealistic to have your config management tool cover these more edge cases, but having things broken down and structured by it as external modules helps immeasurably with the spaghetti. Derek ------------------------------------------------------------------------ For important statutory and regulatory disclosures and more information about Barclays Capital, please visit our web site at http://www.barcap.com. Internet communications are not secure and therefore the Barclays Group does not accept legal responsibility for the contents of this message. Although the Barclays Group operates anti-virus programmes, it does not accept responsibility for any damage whatsoever that is caused by viruses being passed. Any views or opinions presented are solely those of the author and do not necessarily represent those of the Barclays Group. Replies to this email may be monitored by the Barclays Group for operational or business reasons. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ------------------------------------------------------------------------
On Jun 11, 2007, at 11:14 AM, <Derek.Whayman@barclayscapital.com> <Derek.Whayman@barclayscapital.com> wrote:> > The script is setting up a bunch of basic VCS services & monitors, > things which are a bit much to expect Puppet to have types for.Ah. That might make more sense to model as types, even just using definitions.> This particular one only needs running once, but who''s to say we won''t > have things which need doing reguarly. It''s not too big a deal to > make > your maintenance scripts idempotent.True, but if you''re going to go to that effort, it probably makes sense to go all the way to using defined types, which are easy to make idempotent and keep all of your configuration data in your Puppet configuration, rather than being stored in these scripts.> We currently have large, tangled and unmanageable postinstall scripts. > The idea is to replace them with an absolutely minimal install (a few > packages and Puppet). Then, Puppet would control the machine install > and customisation process and also revert any files that have been > tampered with subsequently. I expect the 80/20 rule to apply in terms > of what can be done with the built in types. This case covers the > things you don''t necessarily get out of the box.That''s definitely reasonable.> I think it''s unrealistic to have your config management tool cover > these > more edge cases, but having things broken down and structured by it as > external modules helps immeasurably with the spaghetti.I would go one further and say that even if you''re using external modules, modeling them like any other resource -- when possible -- makes things even cleaner. -- You can''t have everything. Where would you put it? -- Stephen Wright --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com