Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've recently got my puppetmaster and client up and running and have had the client correctly signed, then requested and applied simple changes, all good.

I have a growing number of machines (>100). They are not consistently named (historical reasons). They fall into a handful of categories (think of it like: dataserver_type1, dataserver_type2, webserver_type1, webserver_type2....). New instances of these types of machines are added weekly.

I don't understand (yet) or cannot see how I can declare a "generic" node of (say) "dataserver_type1" that contains whatever modules it needs, and set something in the client puppet.conf that says "I am a dataserver_type1" without using the hostname/FQDN

If I set the node name in the catalog as (say) "my-data-server-type1" - the certified hostname - it picks it up and works. I know you can use patterns for hostnames but as I said, my server names are not consistent, and I can't change them.

This seems disingenuous to have to edit a file and manually add a node for each server, when they continue to grow.


Digging deeper, it seems roles may be what I want. But there still seems to be an element whereby the master has contain a list of roles that a specific named server should do. Perhaps what I am asking is, how can a client say "I want to be this role", without the server having to be updated?

share|improve this question
You could possibly extend facter to read some local file or something and then create global variables. – Zoredache Oct 30 '12 at 16:43
@Zoredache - thanks, I had stumbled upon something else alluding to this a little earlier, I will post the links if it works out. You are right though, custom facts appear to be the way to go. – Aitch Oct 30 '12 at 22:03

Nodes are always centrally defined, either in your manifests or an external node classifier (or both).

I guess you could put together an ENC that allows clients to specify their role.. but why are you wanting to touch each computer to configure it locally?

Sounds like you might just need some better organization to your node manifests. Maybe some node inheritance for your system "roles" to reduce duplication every time you make a new node, as well as some good regex node names that cover sets of system names (as in, you might not be able to cover every webserver_type2 with one regex, but put one in place that covers the naming convention you're using for new nodes).

share|improve this answer
we are retro fitting puppet to our machines hence we will need to touch all machines anyway, install the puppet client package and modify the /etc/puppet/puppet.conf I guess I was wondering whether there was a setting I could put in there that would specify the roles at the client side. – Aitch Oct 30 '12 at 15:32
@Aitch Not in the client-server model, there is not. A local puppet apply on the server, with all the module definitions on the server (you'll need to have them copied or synced there somehow), will let the local system determine what it gets for that run, but that won't change anything about how the master classifies it. – Shane Madden Oct 30 '12 at 15:56
up vote 0 down vote accepted

Coming back with a solution and for future googlers. Thanks to others for the input.

There was a discussion here that led to a set of files hinting at a solution.

However my limited experience suggests this was a little out of date in terms of file locations. On the client, you need a file like so:

root@vbox1-test:/etc/puppet# cat custom_facts.yml 
servertype: webserver-type1

On the server (puppetmaster) if you follow the files in the second link provided then the .rb works fine, but the location is wrong (I'm using v3.x). Try moving it to:

ubuntu@puppetmaster:/etc/puppet/modules/custom/lib/facter$ ls custom_facts.rb

Within any one of your module .pp files etc, simply add something like

notify { "My servertype is: ${servertype}" : }

Again the second link alludes to the fact you can do a "case" statement of sorts to then pick and choose which modules/manifests are used. So i can apply a base set of rules to most machines, then some custom ones for certain types, without touching the server manifests.

The effect you get on the client is something like this:

root@vbox1-test:/etc/puppet# puppet agent --test
Info: Retrieving plugin
/File[/var/lib/puppet/lib/facter]/ensure: created
/File[/var/lib/puppet/lib/facter/custom_facts.rb]/ensure: defined content as '{md5}xxxxxxxxxxxxxxxxxxxxxxx'
Info: Loading facts in /var/lib/puppet/lib/facter/custom_facts.rb
Info: Caching catalog for vbox1-test
Info: Applying configuration version '1351762428'
My servertype is: webserver-type1
/Stage[main]//Node[default]/Notify[My servertype is: webserver-type1]/message: defined 'message' as 'My servertype is: webserver-type1'
Finished catalog run in 0.05 seconds

I'm pretty optimistic this give me what I want and I can keep the manifests free of server names, which are legacy and growing continually.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.