Moving existing unmanaged system under Puppet has it's own set of issues, but what Ohad said is going to work. Let Puppet manage Puppet, the version and puppet.conf.
Why do you want to use an Initialize tag? Wouldn't you at least want to know if not have Puppet fix it if the state anything you mention was changed? (Yum repo/libshadow) On Mon, Feb 2, 2009 at 8:44 AM, Dan Bode <bod...@gmail.com> wrote: > Most of the machines that we are working with are already installed, so we > cant rely on preconfig. > > I am just proposing the wrapper script to control which order config tasks > execute in. Using tags to create PRECONFIG calls > seems like an appealing solution to get around the need to constantly > declare dependencies everywhere in puppet. > > Are you using puppetmaster to manage the upgrades for puppetd? I am not a > ruby expert, but I assumed that this will not work reliably. > Can you 100% reliably load scripts in ruby, then remove those scripts while > they are loaded? > > It seems safer (although more of a pain to maintain) to let another script > manage upgrade for puppetd. > > > > On Mon, Feb 2, 2009 at 3:37 PM, Ohad Levy <ohadl...@gmail.com> wrote: > >> Dan, >> >> it is much easier to manage puppet with a simple puppet class. >> >> what I do, is to include a class which configures puppet it self. >> in that class (which is also applied to the puppetmaster) you can define >> everything you want (from config files to puppet version etc). >> >> the only problem you need to solve is the how to get a basic working >> config file before the first puppet run... which could easily be done using >> a kickstart/jumpstart whatever script when you install the machine (or if >> you want, you can rebuild the puppet package). >> >> Dont forget the puppetmaster, it should also run puppetd....... >> >> Cheers, >> Ohad >> >> >> >> >> On Mon, Feb 2, 2009 at 8:12 PM, Dan Bode <bod...@gmail.com> wrote: >> >>> Hi, >>> >>> I am putting together a solution to allow puppet to manage its agents >>> >>> The following things need to be managed: >>> 1. Ensure that the puppet agent version is the same as the server version >>> (and that we upgrade if there is a version mismatch) >>> 2. Ensure that all facts are imported (easy enough with --factsync, need >>> to read more about plugins) >>> 3. Ensure that we can distribute the puppet.conf files so that we can >>> control reporting (and other things later) >>> >>> Is there a known solution for this? I can't find any documents. >>> >>> I am leaning towards a solution that relies on a wrapper script for >>> puppetd and tagging. >>> >>> 1. Puppetd executable is replaced with a script: >>> *call to puppetmasterd with tag VERSION, this will just print out the >>> version (is there a better way to do this?) >>> *have the script check the version and determine if the agent needs to be >>> upgraded, if so the script upgrades the agent with yum >>> **this assumes that yum is working because the puppet agent should always >>> be the correct version the first time that it runs, so yum will be set. >>> *perform puppetd run using tag INITIALIZE (sets up yum repos, peroforms >>> other pre-run dependencies, like ruby-shadow) >>> *make the main puppet run >>> >>> Just wondering what other solutions have been devised, and thinking there >>> must be a better way than what I am about to implement. >>> >>> thanks as always, >>> >>> Dan Bode >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
