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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 <bodepd@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 <ohadlevy@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 <bodepd@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 <bodepd@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 <ohadlevy@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 <bodepd@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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
1.
I will have a look at having puppet manage version. It just seems strange to
write a program that says
"while I am running, remove all of the script files that were interpreted
and replace them with other ones." (yum upgrade)
I need to do some reading on ruby to understand what is happening with the
actual script files when ruby is interpreting them.
I wanted to introduce code so that a different set of instructions other
than puppetd would manage the upgrade.
2.
As for yum, I can manage its dependencies more cleanly with puppet by doing
the following:
I can set a global requirement for a package that it depends on the yum
class. (ie)
Package{requires => Class["yum"]} (so that no packages every try to
install
before yum does)
4.
Shadow was not a valid use case, b/c I didn''t see that it was set up as
an
rpm dependency.
5.***
The --tags INIT is just something that I am considering to manage
dependencies. Puppet doesnt seem to have a good way to say
"apply this resource before any others are applied", and I surely dont
want
to set a dependency between a resource and EVERY other resource.
It would be great if there was something like
resource{"x":
before => "*"
}
and it seems like
puppetd --server X --tags PRE-RUN
puppetd --server X --tags RUN
puppetd --server X --tags POST-RUN
is an elegent alternative to setting massive numbers of dependencies in the
code to express the same thing.
(I wish that I had access to IRC from work:)
thanks,
Dan
--~--~---------~--~----~------------~-------~--~----~
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---