I''ve spent the last week or two poring over the documentation and
setting up my first puppet environment, and while I''ve figured out
how to do most of what I want to do with it, I have some questions
that I haven''t been able to find answers for...
* Can I match parts of a facter fact? In particular I have hostnames
that include the environment as part of the name (dev-app-01, test-
app-01, stage-app-01, prod-app-01, etc), and there are some settings
where I''d like to be able to do something like this:
case $hostname {
"dev-*": { $gateway = ''192.168.1.1'' }
"test-*": { $gateway = ''192.168.2.1'' }
"stage-*": { $gateway = ''192.168.3.1'' }
}
I''ll probably end up writing a facter module to create facts out of
this information, but for now I''ve kind of kludged it by adding this
to /etc/profile.d/puppet.sh (I''m running Fedora) so it ends up in the
environment where facter can see it:
TMP=`hostname -s`
export FACTER_NETLOC=${TMP/-*}
TMP=${TMP/$FACTER_NETLOC-}
export FACTER_SERVTYPE=${TMP/-*}
TMP=${TMP/$FACTER_SERVTYPE-}
export FACTER_SERVID=$TMP
Ultimately though, I feel like it would be easier if it was possible
to use wildcard matches for the case statement, then I could also do
things like "dev-build-*" when I need to...
* Is it possible to extend built-in types? I''d like to add ssh keys
to the user type, and have them added to the users .ssh/authorized
keys file on the hosts where that user has access.
* Is there any way to remove or report any entries that are not part
of the puppet manifest? Specifically I''d like the manifest to
specify all the users that should be in the password file and all the
RPMs that should be installed, and have puppet remove (or at least
report) any users or RPMs on the system that shouldn''t be there. Or
at least is there a way to get a list of what users/rpms the manifest
is managing so that I can whip together a little script to check for
the extras?
--
Jason Kohles
email@jasonkohles.com
http://www.jasonkohles.com/
"A witty saying proves nothing." -- Voltaire
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 27 June 2007, Jason Kohles wrote:> I''ve spent the last week or two poring over the documentation and > setting up my first puppet environment, and while I''ve figured out > how to do most of what I want to do with it, I have some questions > that I haven''t been able to find answers for... > > > * Can I match parts of a facter fact? In particular I have hostnames > that include the environment as part of the name (dev-app-01, test- > app-01, stage-app-01, prod-app-01, etc), and there are some settings > where I''d like to be able to do something like this: > > case $hostname { > "dev-*": { $gateway = ''192.168.1.1'' } > "test-*": { $gateway = ''192.168.2.1'' } > "stage-*": { $gateway = ''192.168.3.1'' } > } > > I''ll probably end up writing a facter module to create facts out of > this information, but for now I''ve kind of kludged it by adding this > to /etc/profile.d/puppet.sh (I''m running Fedora) so it ends up in the > environment where facter can see it: > > TMP=`hostname -s` > export FACTER_NETLOC=${TMP/-*} > TMP=${TMP/$FACTER_NETLOC-} > export FACTER_SERVTYPE=${TMP/-*} > TMP=${TMP/$FACTER_SERVTYPE-} > export FACTER_SERVID=$TMP > > Ultimately though, I feel like it would be easier if it was possible > to use wildcard matches for the case statement, then I could also do > things like "dev-build-*" when I need to...Usually this is solved the other way round: node dev { $gateway = "....1" include dev_classes } node dev-app-01, dev-app-02, ... inherits dev { }> * Is it possible to extend built-in types? I''d like to add ssh keys > to the user type, and have them added to the users .ssh/authorized > keys file on the hosts where that user has access.There is a recipe on the wiki for that: https://reductivelabs.com/trac/puppet/wiki/Authorized_keysRecipe> * Is there any way to remove or report any entries that are not part > of the puppet manifest? Specifically I''d like the manifest to > specify all the users that should be in the password file and all the > RPMs that should be installed, and have puppet remove (or at least > report) any users or RPMs on the system that shouldn''t be there. Or > at least is there a way to get a list of what users/rpms the manifest > is managing so that I can whip together a little script to check for > the extras?Look for the purge parameter in the type reference: https://reductivelabs.com/trac/puppet/wiki/TypeReference Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGgqbJ/Pp1N6Uzh0URAhykAJwJi9tcFW4WHdwJM86snan4agr6+gCgjNxs swvp5vxfnCR0enaG5+6x9WA=QOPY -----END PGP SIGNATURE-----
On Jun 27, 2007, at 2:04 PM, David Schmitt wrote:>> * Can I match parts of a facter fact? In particular I have hostnames >> that include the environment as part of the name (dev-app-01, test- >> app-01, stage-app-01, prod-app-01, etc), and there are some settings >> where I''d like to be able to do something like this: >> >> case $hostname { >> "dev-*": { $gateway = ''192.168.1.1'' } >> "test-*": { $gateway = ''192.168.2.1'' } >> "stage-*": { $gateway = ''192.168.3.1'' } >> } >> > > Usually this is solved the other way round: > > node dev { > $gateway = "....1" > include dev_classes > } > > node dev-app-01, dev-app-02, ... inherits dev { } >This would work if I could do multiple inheritance, but puppet doesn''t seem to like multiple inheritance. The big problem I have is that I have a lot of settings that are based on the environment (primarily because in addition to the test/staging/production environments, I have multiple dev environments, which are differentiated because of the network they are located on, so dev1-* are all in one location, and dev2-* are all in another location. On top of that, I have a lot of settings that differ based on the server type, so to use inheritance, I''d need something more like: node dev1-app-01 inherits dev1_network,app_server {} What I''ll probably end up doing is writing a script to generate my node definitions, so I can just include the settings/classes I need in the node...>> * Is it possible to extend built-in types? I''d like to add ssh keys >> to the user type, and have them added to the users .ssh/authorized >> keys file on the hosts where that user has access. > > There is a recipe on the wiki for that: > > https://reductivelabs.com/trac/puppet/wiki/Authorized_keysRecipe >I''ve looked at that, but it''s way more complex than I need, as I really don''t want to be generating keys for users. What I really wanted was just the ability to do: user { "jason": uid => 500, gid => 500, sshkey => "ssh-dss AAAA.........== jason@localhost'' } After digging through it, I''ve found a way to accomplish my goal, rather than trying to extend ''user'', I''m adapting the ''define account'' that is found in there.>> * Is there any way to remove or report any entries that are not part >> of the puppet manifest? Specifically I''d like the manifest to >> specify all the users that should be in the password file and all the >> RPMs that should be installed, and have puppet remove (or at least >> report) any users or RPMs on the system that shouldn''t be there. Or >> at least is there a way to get a list of what users/rpms the manifest >> is managing so that I can whip together a little script to check for >> the extras? > > Look for the purge parameter in the type reference: > > https://reductivelabs.com/trac/puppet/wiki/TypeReference >Hmm, somehow I managed to miss that, several times it seems, while reading that page... -- Jason Kohles email@jasonkohles.com http://www.jasonkohles.com/ "A witty saying proves nothing." -- Voltaire
On Jun 27, 2007, at 1:04 PM, David Schmitt wrote:>> * Is there any way to remove or report any entries that are not part >> of the puppet manifest? Specifically I''d like the manifest to >> specify all the users that should be in the password file and all the >> RPMs that should be installed, and have puppet remove (or at least >> report) any users or RPMs on the system that shouldn''t be there. Or >> at least is there a way to get a list of what users/rpms the manifest >> is managing so that I can whip together a little script to check for >> the extras? > > Look for the purge parameter in the type reference: > > https://reductivelabs.com/trac/puppet/wiki/TypeReferenceAnd especially look at the ''resources'' type, which can be used to remove unmanaged resources. Set noop => true to just log what would be removed. -- Should I say "I believe in physics", or "I know that physics is true"? -- Ludwig Wittgenstein, On Certainty, 602. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jun 27, 2007, at 2:51 PM, Jason Kohles wrote:> What I''ll probably end up doing is writing a script to generate my > node definitions, so I can just include the settings/classes I need > in the node...You should look at the external node support: http://reductivelabs.com/trac/puppet/wiki/ ConfigurationReference#external-nodes That''s a *much* better solution than generating your node definitions, and is a good stop-gap until we solve this problem permanently.> After digging through it, I''ve found a way to accomplish my goal, > rather than trying to extend ''user'', I''m adapting the ''define > account'' that is found in there.That''s the approach I would recommend. -- Those who speak most of progress measure it by quantity and not by quality. --George Santayana --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jun 27, 2007, at 5:09 PM, Luke Kanies wrote:> On Jun 27, 2007, at 2:51 PM, Jason Kohles wrote: >> What I''ll probably end up doing is writing a script to generate my >> node definitions, so I can just include the settings/classes I need >> in the node... > > You should look at the external node support: > > http://reductivelabs.com/trac/puppet/wiki/ > ConfigurationReference#external-nodes > > That''s a *much* better solution than generating your node > definitions, and is a good stop-gap until we solve this problem > permanently. >This is definitely a much better approach, although I''m having a bit of trouble with it (maybe after struggling with this for a while I''ll finally learn enough Ruby to figure it out from the code...) I started out confused because I was running 0.22.4, and the URL has documenation for 0.23, which has a very different format. So I looked through the code and came up with this very simple test script for the external_nodes setting: #!/bin/sh echo "" echo "common puppet dns" This seemed to work great until I tried to add network_dev classes that set variables that needed to be used elsewhere, and the scoping rules got me. Since the 0.23 version seemed to have already dealt with that, I built RPMs for 0.23 and upgraded my test machines, then I converted the simple test script to produce YAML. It seems to work, but I can''t figure out what format the ''parameters'' section is supposed to have... If I run the script from the command line, I get this output: [root@dev1-mgmt-01 puppet]# ./node_classifier dev1-mgmt-01 --- parameters: puppet_server: dev1-puppet file_server: puppet://dev1-puppet/files classes: - mgmt_server - cron - dns - puppet - ssh - admin_users - user_root - virt_all_users From looking at the code, I thought this was going to get turned into the equivalent of: node dev1-mgmt-01 { $puppet_server = ''dev1-puppet'' $file_server = ''puppet://dev1-puppet/files'' include mgmt_server include cron include dns include puppet include ssh include admin_users include user_root include virt_all_users } But that doesn''t seem to be the case, when it gets parsed I end up with this error: [root@dev1-mgmt-01 puppet]# puppetd --test --server dev1-puppet notice: Ignoring cache err: Could not retrieve configuration: Could not evaluate classes for dev1-mgmt-01: Could not find class puppet_server in namespaces mgmt_server at /etc/puppet/manifests/site.pp:14 warning: Not using cache on failed configuration So it seems like I got the ''classes'' part right, but can someone tell me what I''m doing wrong with the ''parameters'' part? -- Jason Kohles email@jasonkohles.com http://www.jasonkohles.com/ "A witty saying proves nothing." -- Voltaire
On Jun 28, 2007, at 9:32 AM, Jason Kohles wrote:> This is definitely a much better approach, although I''m having a bit > of trouble with it (maybe after struggling with this for a while I''ll > finally learn enough Ruby to figure it out from the code...)One hopes that wouldn''t be necessary...> [...] > If I run the script from the command line, I get this output: > > [root@dev1-mgmt-01 puppet]# ./node_classifier dev1-mgmt-01 > --- > parameters: > puppet_server: dev1-puppet > file_server: puppet://dev1-puppet/files > classes: > - mgmt_server > - cron > - dns > - puppet > - ssh > - admin_users > - user_root > - virt_all_usersLooks good.> From looking at the code, I thought this was going to get turned > into the equivalent of: > > node dev1-mgmt-01 { > $puppet_server = ''dev1-puppet'' > $file_server = ''puppet://dev1-puppet/files'' > include mgmt_server > include cron > include dns > include puppet > include ssh > include admin_users > include user_root > include virt_all_users > } > > But that doesn''t seem to be the case, when it gets parsed I end up > with this error: > > [root@dev1-mgmt-01 puppet]# puppetd --test --server dev1-puppet > notice: Ignoring cache > err: Could not retrieve configuration: Could not evaluate classes for > dev1-mgmt-01: Could not find class puppet_server in namespaces > mgmt_server at /etc/puppet/manifests/site.pp:14 > warning: Not using cache on failed configuration > > > So it seems like I got the ''classes'' part right, but can someone tell > me what I''m doing wrong with the ''parameters'' part?You''re sure your server is running the new code? I just tested it with this Ruby script to generate the yaml: host = ARGV.shift.sub(/\..+$/,'''') hash = { "classes" => %w{one}.collect { |name| name + host }, "parameters" => {"a" => host, "c" => host} } require ''yaml'' puts YAML.dump(hash) And this Puppet script to use it: class onephage { notify { "got one: $a $c": } } On my host (named phage), I get this result: notice: got one: phage phage -- What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against? --Larry Wall in <1992Aug26.184221.29627@netlabs.com> --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Jun 28, 2007, at 11:51 AM, Luke Kanies wrote:> On Jun 28, 2007, at 9:32 AM, Jason Kohles wrote: >> This is definitely a much better approach, although I''m having a bit >> of trouble with it (maybe after struggling with this for a while I''ll >> finally learn enough Ruby to figure it out from the code...) > > One hopes that wouldn''t be necessary...Well, the documentation for this particular feature is, to put it nicely, terse. :) I added a page to the wiki (ExternalNodes) that explains what I''ve found out about the feature so far, although mt implementation isn''t actually working yet, so it may need correction...>> [...] >> If I run the script from the command line, I get this output: >> >> [root@dev1-mgmt-01 puppet]# ./node_classifier dev1-mgmt-01 >> --- >> parameters: >> puppet_server: dev1-puppet >> file_server: puppet://dev1-puppet/files >> classes: >> - mgmt_server >> - cron >> - dns >> - puppet >> - ssh >> - admin_users >> - user_root >> - virt_all_users > > Looks good. > >> From looking at the code, I thought this was going to get turned >> into the equivalent of: >> >> node dev1-mgmt-01 { >> $puppet_server = ''dev1-puppet'' >> $file_server = ''puppet://dev1-puppet/files'' >> include mgmt_server >> include cron >> include dns >> include puppet >> include ssh >> include admin_users >> include user_root >> include virt_all_users >> } >> >> But that doesn''t seem to be the case, when it gets parsed I end up >> with this error: >> >> [root@dev1-mgmt-01 puppet]# puppetd --test --server dev1-puppet >> notice: Ignoring cache >> err: Could not retrieve configuration: Could not evaluate classes for >> dev1-mgmt-01: Could not find class puppet_server in namespaces >> mgmt_server at /etc/puppet/manifests/site.pp:14 >> warning: Not using cache on failed configuration >> >> >> So it seems like I got the ''classes'' part right, but can someone tell >> me what I''m doing wrong with the ''parameters'' part? > > You''re sure your server is running the new code? >I''m certain, I''ve been restarting puppetmaster every time I make changes, and I even rewrote the script in perl instead of bash planning to have it get information from an existing database, and I still get the same error... line 14 of my site.pp is ''import "definitions/*"'', and none of the files in definitions refers to $puppet_server. however, I did find some more information about what is going on, if the script produces this: --- classes: - common - mgmt_server parameters: puppet_server: dev1-puppet then I get that error, which mentions mgmt_server, if I remove mgmt_server from the classes list, then I don''t get that error and everything else seems to work fine. The mgmt_server class looks like this: class mgmt_server { include puppet_server } Could I be having a conflict caused by having a class and a variable with the same name? I hadn''t realized until I started digging into it that I had done that, is it something I should avoid, or is the language supposed to be able to handle it? -- Jason Kohles email@jasonkohles.com http://www.jasonkohles.com/ "A witty saying proves nothing." -- Voltaire
On Jun 28, 2007, at 2:29 PM, Jason Kohles wrote:> > however, I did find some more information about what is going on, if > the script produces this: > > --- > classes: > - common > - mgmt_server > parameters: > puppet_server: dev1-puppet > > then I get that error, which mentions mgmt_server, if I remove > mgmt_server from the classes list, then I don''t get that error and > everything else seems to work fine. The mgmt_server class looks like > this: > > class mgmt_server { > include puppet_server > } > > Could I be having a conflict caused by having a class and a variable > with the same name? I hadn''t realized until I started digging into > it that I had done that, is it something I should avoid, or is the > language supposed to be able to handle it? >So it turns out my problem was even stupider than that, I didn''t have a variable and a class with the same name, I only had a variable with that name, and ''include puppet_server'' should have been ''include puppetmaster'', once I fixed it to refer to the class that actually exists then it worked fine... -- Jason Kohles email@jasonkohles.com http://www.jasonkohles.com/ "A witty saying proves nothing." -- Voltaire
On Jun 28, 2007, at 1:38 PM, Jason Kohles wrote:> So it turns out my problem was even stupider than that, I didn''t have > a variable and a class with the same name, I only had a variable with > that name, and ''include puppet_server'' should have been ''include > puppetmaster'', once I fixed it to refer to the class that actually > exists then it worked fine...Yeah, once I saw that class of yours, I figured that was the problem. Glad to hear you got it all working, and thanks for making that page. -- I used to get high on life but lately I''ve built up a resistance. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com