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
--
[email protected]
[email protected] -- 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
