Hi Puppet Users, Hi Luke,
Happy to find myself here. I am an old ISConf user -- Luke might
remember my random questions back in the infrastructures / isconf list
-- and have been developing the School Server ("XS") for OLPC for a
while (and lately doing a dozen more things at OLPC which has shrunk
my XS time).
Writing here because my original intention with the XS was to dust-off
some ISConf concepts and have a minimalistic modern implementation of
something isconf-ish that should integrate well with package mgmt
tools (dpkg/apt, rpm/yum). By the time I managed to look at the
situation, I was very happy to find Luke had done something similar
(but much better than I''d be able to) -- Puppet!
[ Did I say THANKS!? Should say it lots, and often. ]
So I''ve just been working with a deployment team in the field, and
working through the Puppet docs, defined an initial configuration
strategy, and rolled out the puppet client to the initial 10 XSs (soon
to be joined by approx 800 more).
I have a series of questions, coming from an old hand in terms of
config mgmt, but absolutely new to Puppet. Happy to RTFM, or to code
what''s missing; pointers welcome. In many cases I might be missing the
right terminology for things in puppet-land.
Your help is appreciated. Just in the deployment above, the "userbase"
for this infra is 50 000 children with XOs. Demanding userbase, let me
tell you... but they sure know how to say thanks, and how to get a lot
from what we put into it :-)
First, I''ll confess to some oddities in our usage:
- All our nodes are identical (for the purposes of Puppet anyway --
differences are handled by code installed on the node).
- Currently our nodes run Fedora 9, with an old (0.24.x I think)
Puppet. And update is in the works, but bear in mind for my questions
later...
- Some of our nodes are behind NAT... multiple layers of it sometimes.
- Some of our nodes have no WAN/Internet -- questions to follow on this. -
=Questions
1 - With a high number of identical nodes, we are very precious about
deploying the exact same sw package (rpm in this case) to all nodes.
Can I declare an exact rpm version/revision in a packages[] section?
Can I later update it with a later version and will it know to upgrade
via yum?
2 - Can I say "install this shellscript and run it once"? How?
2a - Is there an ISConf-like facility that says "run it until it
succeeds once"? [ Happy to use Makefiles, but if there''s a
Puppet-supported elegant way of doing it... ]
3 - Can I hook up a trigger so when a new conffile for a service is
installed the service is restarted? IE: I provide a new
/etc/named.conf, I want to add a trigger that says that everytime it
changes, "services named restart" should be invoked...
4 - Can the clients send a "deployed configuration successfully" msg
to the server, so we keep a tally of
- clients seen recently
- success vs failure in deployment of latest config
- what clients are failing or behind in their sync
5 - Is there any "server status" monitoring tool that
integrates/piggybacks with Puppet? Our NAT''ted clients make most
monitoring tools a pain...
6 - For disconnected configuration clients -- is there a way to tell
the puppet client: the puppet config of the server is available to you
on file:///media/usb/puppetconfig ? The XS already has a mechanism
that can guarantee the integrity of files coming from the sysadmin
team (so only "signed" files are accepted over usb).
That''s all -- Thanks in advance for your help.
Are these very odd questions?
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don''t get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
--
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.
> 2 - Can I say "install this shellscript and run it once"? How? > > 2a - Is there an ISConf-like facility that says "run it until it > succeeds once"? [ Happy to use Makefiles, but if there''s a > Puppet-supported elegant way of doing it... ]If the code of the shell script can be minimized to use as much as of Puppet''s existing resources, that would be a good way to go about things. Of course, you can execute the shell scripts, and define the conditions that you mentioned. Have a look at the exec resource type in puppet for such things.> 3 - Can I hook up a trigger so when a new conffile for a service is > installed the service is restarted? IE: I provide a new > /etc/named.conf, I want to add a trigger that says that everytime it > changes, "services named restart" should be invoked...Yes, you can have the service "subscribe" to the configuration file: service{"named": . . . subscribe=>File["/etc/named.conf"] . . . } Or alternatively, a notify statement in the file resource type.> 4 - Can the clients send a "deployed configuration successfully" msg > to the server, so we keep a tally of > > - clients seen recently > - success vs failure in deployment of latest config > - what clients are failing or behind in their syncAt the most basic level, you can do this by simply enabling report true in clients'' configuration and at the server reports = log. This will log the required information in the puppet master''s logs. There are many more options for reporting, along with various tools (web interfaces) like Dashboard & Foreman. -- 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.
On Wed, Sep 8, 2010 at 11:45 AM, alcy <mohit.chawla.binary@gmail.com> wrote:>> 2a - Is there an ISConf-like facility that says "run it until it >> succeeds once"? [ Happy to use Makefiles, but if there''s a >> Puppet-supported elegant way of doing it... ] > > If the code of the shell script can be minimized to use as much as of > Puppet''s existing resources, that would be a good way to go about > things. Of course, you can execute the shell scripts, and define the > conditions that you mentioned. Have a look at the exec resource type > in puppet for such things.Thanks! Will look at exec. I think I''ll make a /var/lib/mypuppetstate directory and touch files in there on successful completion of scripts.>> 3 - Can I hook up a trigger so when a new conffile for a service is >> installed the service is restarted? IE: I provide a new >> /etc/named.conf, I want to add a trigger that says that everytime it >> changes, "services named restart" should be invoked... > > Yes, you can have the service "subscribe" to the configuration file: > > service{"named":And I assume that it knows that on Fedora the magic incantation is service <servicename> restart... That''ll only work if the file is updated by Puppet, correct? Or is there an inotify side to Puppet that I didn''t know before...? If the service is sub''d to several files, and all are updated "in one go" from Puppet, will there be one service restart, or one per file?>> 4 - Can the clients send a "deployed configuration successfully" msg >> to the server, so we keep a tally of >> >> - clients seen recently >> - success vs failure in deployment of latest config >> - what clients are failing or behind in their sync > > At the most basic level, you can do this by simply enabling report > true in clients'' configuration and at the server reports = log. ThisHmmm... from what I''ve seen, that gets me when the puppet client _requested_ stuff, but not a "puppet client deployed successfully". Am I missing something?> like Dashboard & Foreman.Will investigate ;-) m -- martin.langhoff@gmail.com martin@laptop.org -- School Server Architect - ask interesting questions - don''t get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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.
On Sep 8, 2010, at 7:20 AM, Martin Langhoff wrote:> Hi Puppet Users, Hi Luke, > > Happy to find myself here. I am an old ISConf user -- Luke might > remember my random questions back in the infrastructures / isconf list > -- and have been developing the School Server ("XS") for OLPC for a > while (and lately doing a dozen more things at OLPC which has shrunk > my XS time). > > Writing here because my original intention with the XS was to dust-off > some ISConf concepts and have a minimalistic modern implementation of > something isconf-ish that should integrate well with package mgmt > tools (dpkg/apt, rpm/yum). By the time I managed to look at the > situation, I was very happy to find Luke had done something similar > (but much better than I''d be able to) -- Puppet! > > [ Did I say THANKS!? Should say it lots, and often. ] > > So I''ve just been working with a deployment team in the field, and > working through the Puppet docs, defined an initial configuration > strategy, and rolled out the puppet client to the initial 10 XSs (soon > to be joined by approx 800 more). > > I have a series of questions, coming from an old hand in terms of > config mgmt, but absolutely new to Puppet. Happy to RTFM, or to code > what''s missing; pointers welcome. In many cases I might be missing the > right terminology for things in puppet-land. > > Your help is appreciated. Just in the deployment above, the "userbase" > for this infra is 50 000 children with XOs. Demanding userbase, let me > tell you... but they sure know how to say thanks, and how to get a lot > from what we put into it :-) > > First, I''ll confess to some oddities in our usage: > > - All our nodes are identical (for the purposes of Puppet anyway -- > differences are handled by code installed on the node). > > - Currently our nodes run Fedora 9, with an old (0.24.x I think) > Puppet. And update is in the works, but bear in mind for my questions > later... > > - Some of our nodes are behind NAT... multiple layers of it sometimes. > > - Some of our nodes have no WAN/Internet -- questions to follow on this. - > > =Questions> > 1 - With a high number of identical nodes, we are very precious about > deploying the exact same sw package (rpm in this case) to all nodes. > Can I declare an exact rpm version/revision in a packages[] section? > Can I later update it with a later version and will it know to upgrade > via yum?You can, but this is usually a way to cause yourself a lot of pain. Creating a custom repository mirror and doing stuff with that is probably simpler.> 2 - Can I say "install this shellscript and run it once"? How?How bad is running it a second time? Does it just take a long time or destroy the system if run a second time?> 2a - Is there an ISConf-like facility that says "run it until it > succeeds once"? [ Happy to use Makefiles, but if there''s a > Puppet-supported elegant way of doing it... ]Sometimes you can check to see if it succeeded by using the exec parameters "creates" or "unless". Is there a simple command you can run later to see if it worked, or a file you can check for the existence of? If that fails, you "/var/lib/mypuppetstate" idea sounds good, but again, at east consider what happens if you lose power in the middle of a command.> 4 - Can the clients send a "deployed configuration successfully" msg > to the server, so we keep a tally of > > - clients seen recently > - success vs failure in deployment of latest config > - what clients are failing or behind in their sync> 6 - For disconnected configuration clients -- is there a way to tell > the puppet client: the puppet config of the server is available to you > on file:///media/usb/puppetconfig ? The XS already has a mechanism > that can guarantee the integrity of files coming from the sysadmin > team (so only "signed" files are accepted over usb).Puppet is made to be able to apply a config in a local directory. Take a look at the "puppet" command. Hooking that into cron should be pretty trivial.> That''s all -- Thanks in advance for your help. > > Are these very odd questions?I thought the USB one was strange.> cheers,-- 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.
On Sep 8, 2010, at 11:00 AM, Martin Langhoff wrote:>>> 3 - Can I hook up a trigger so when a new conffile for a service is >>> installed the service is restarted? IE: I provide a new >>> /etc/named.conf, I want to add a trigger that says that everytime it >>> changes, "services named restart" should be invoked... >> >> Yes, you can have the service "subscribe" to the configuration file: >> >> service{"named": > > And I assume that it knows that on Fedora the magic incantation is > service <servicename> restart...That doesn''t matter because puppet know how to do it.> That''ll only work if the file is updated by Puppet, correct? Or is > there an inotify side to Puppet that I didn''t know before...?That will only work if the file is updated by puppet.> If the service is sub''d to several files, and all are updated "in one > go" from Puppet, will there be one service restart, or one per file?Once per run.>>> 4 - Can the clients send a "deployed configuration successfully" msg >>> to the server, so we keep a tally of >>> >>> - clients seen recently >>> - success vs failure in deployment of latest config >>> - what clients are failing or behind in their sync >> >> At the most basic level, you can do this by simply enabling report >> true in clients'' configuration and at the server reports = log. This > > Hmmm... from what I''ve seen, that gets me when the puppet client > _requested_ stuff, but not a "puppet client deployed successfully". > > Am I missing something?This sends a report from the client to the server at the end of a run telling the server what itthe client did including any errors applying a manifest.>> like Dashboard & Foreman. > > Will investigate ;-)-- 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.
On Wed, 08 Sep 2010, Martin Langhoff wrote:> 1 - With a high number of identical nodes, we are very precious about > deploying the exact same sw package (rpm in this case) to all nodes. > Can I declare an exact rpm version/revision in a packages[] section? > Can I later update it with a later version and will it know to upgrade > VIA YUM?Yes, you can put a version number in the "require" parameter of a package resource. As somebody else said, it would be a good idea to maintain your own package repository.> 2 - Can I say "install this shellscript and run it once"? How?There''s no easy way to do exactly that, but you can easily achieve much the same result if the script has a way of testing whether its work needs to be done: $script = "/some/dir/filename" file { $script: ensure => file, owner => ..., group => ..., mode => ..., source => "puppet:///wherever", } exec { "run the script if necessary": command => "$script --really-do-it", onlyif => "$script --check-whether-it-needs-to-be-done", require => File[$script], }> 2a - Is there an ISConf-like facility that says "run it until it > succeeds once"? [ Happy to use Makefiles, but if there''s a > Puppet-supported elegant way of doing it... ]Again, no, but there are several alternatives. To run the command several times per puppet run, you can put a while loop in the "command" parameter of a puppet exec resource, or write a wrapper script that loops. To run a command once per puppet run as long as it keeps failing, but stop after it has been successful once, can use the exec/onlyif technique. I don''t want to add anything to the answers others have given to the remaining questions. --apb (Alan Barrett) -- 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.
On Sep 8, 2010, at 7:20 AM, Martin Langhoff wrote:> > [...] > [ Did I say THANKS!? Should say it lots, and often. ]Hi Martin, It looks like the list has you pretty well handled, so mostly I''m writing back to say I''m glad to see ISconf users still around, and very glad to see it looks like Puppet will work for you. That being said, I''ll throw my responses in here, too, since I''ve got more of the ISconf context.> 1 - With a high number of identical nodes, we are very precious about > deploying the exact same sw package (rpm in this case) to all nodes. > Can I declare an exact rpm version/revision in a packages[] section? > Can I later update it with a later version and will it know to upgrade > via yum?ensure => ''1.0'' or whatever works fine.> 2 - Can I say "install this shellscript and run it once"? How?Not in so many words, but as Patrick said, use the ''creates'' argument to provide idempotency and you''ll actually be happier.> 2a - Is there an ISConf-like facility that says "run it until it > succeeds once"? [ Happy to use Makefiles, but if there''s a > Puppet-supported elegant way of doing it... ]Execs run every time by default, so this is essentially on. You need some additional check (onlyif/unless/creates) to make them idempotent. [...]> 5 - Is there any "server status" monitoring tool that > integrates/piggybacks with Puppet? Our NAT''ted clients make most > monitoring tools a pain...Our own Dashboard, along with Foreman and a few others.> 6 - For disconnected configuration clients -- is there a way to tell > the puppet client: the puppet config of the server is available to you > on file:///media/usb/puppetconfig ? The XS already has a mechanism > that can guarantee the integrity of files coming from the sysadmin > team (so only "signed" files are accepted over usb).Yes, use stand-alone ''puppet'' rather than a client/server. You can still report back in this mode, although that probably won''t help you much if you''re disconnected. -- The surest sign that intelligent life exists elsewhere in the universe is that it has never tried to contact us. --Calvin and Hobbes (Bill Watterson) --------------------------------------------------------------------- Luke Kanies | http://puppetlabs.com | http://madstop.com -- 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.
On Fri, Sep 10, 2010 at 9:56 AM, Luke Kanies <luke@madstop.com> wrote:> It looks like the list has you pretty well handled, so mostly I''m writing back to say I''m glad to see ISconf users still around, and very glad to see it looks like Puppet will work for you.Indeed, very well treated. Even my oddest questions are being answered! Thanks!> That being said, I''ll throw my responses in here, too, since I''ve got more of the ISconf context. > >> 1 - With a high number of identical nodes, we are very precious about >> deploying the exact same sw package (rpm in this case) to all nodes. >> Can I declare an exact rpm version/revision in a packages[] section? >> Can I later update it with a later version and will it know to upgrade >> via yum? > > ensure => ''1.0'' or whatever works fine.Excellent - thanks! I was going to write full package+version/revision names instead (which wouldn''t have worked properly).>> 2 - Can I say "install this shellscript and run it once"? How? > > Not in so many words, but as Patrick said, use the ''creates'' argument to provide idempotency and you''ll actually be happier.Cool! I do write my scripts to be (internally) idempotent, but I hate to see them re-run everytime (as time goes by, the number grows...) so touching a file and using the ''creates'' arg will DTRT.>> 5 - Is there any "server status" monitoring tool that >> integrates/piggybacks with Puppet? Our NAT''ted clients make most >> monitoring tools a pain... > > Our own Dashboard, along with Foreman and a few others.Will look at Dashboard more in depth - thanks!>> 6 - For disconnected configuration clients -- is there a way to tell >> the puppet client: the puppet config of the server is available to you >> on file:///media/usb/puppetconfig ? The XS already has a mechanism >> that can guarantee the integrity of files coming from the sysadmin >> team (so only "signed" files are accepted over usb). > > Yes, use stand-alone ''puppet'' rather than a client/server. You can still report back in this mode, although that probably won''t help you much if you''re disconnected.Overall, I have to say puppet is treating me a bit too well. Thanks!!! cheers, m -- martin.langhoff@gmail.com martin@laptop.org -- School Server Architect - ask interesting questions - don''t get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- 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.