Master-less : What do I lose?

1183 views
Skip to first unread message

jblaine

unread,
Feb 7, 2011, 12:59:01 PM2/7/11
to puppet...@googlegroups.com
I've not found an explanation of what is lost by using Puppet without a puppetmaster.

Does anyone have a link to something like that, or is anyone willing to expound on the topic?

Felix Frank

unread,
Feb 9, 2011, 2:28:49 AM2/9/11
to puppet...@googlegroups.com

To throw a few buzzwords:
- access control
- stored configs
- modules (?)

I haven't tried extlookup, but there may be issues with that as well.

Some of these can be (more or less) easily circumvented (ACL,
extlookup), but the others may be outright impossible to. There's surely
more I'm not thinking of.

Cheers,
Felix

Kelly Collier

unread,
Feb 9, 2011, 2:46:03 AM2/9/11
to puppet...@googlegroups.com

Puppet is about centralizing administration. If you have dozens/hundreds
of client nodes to administer, then you clearly gain by being able to
make changes in one central location (the puppetmaster) without having
to bother with pushing those changes to all your client nodes yourself.

You could devise a mechanism to push/pull your repository to your
various machines automatically, but then you'd be re-inventing the
wheel, not to mention missing out on the functionality that Felix Frank
listed.

I you have even a modest number of nodes (e.g., ten) to administer,
you're probably complicating things unnecessarily by forgoing a
puppetmaster.


Kelly

> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

Jordan Sissel

unread,
Feb 9, 2011, 4:15:56 AM2/9/11
to puppet...@googlegroups.com
On Mon, Feb 7, 2011 at 9:59 AM, jblaine <cjbl...@gmail.com> wrote:
I've not found an explanation of what is lost by using Puppet without a puppetmaster.

Does anyone have a link to something like that, or is anyone willing to expound on the topic?

I presented a few weeks ago about how I use puppet, and that included masterless. 

Searchable slides on one page here:

I include caveats and other stuff to consider for masterless.

All told, while I love masterless, I don't recommend it for the average case. Do you have a reason or requirement that makes you want to use masterless?

-Jordan

prayther

unread,
Feb 9, 2011, 6:07:16 AM2/9/11
to Puppet Users


On Feb 9, 4:15 am, Jordan Sissel <j...@semicomplete.com> wrote:
> On Mon, Feb 7, 2011 at 9:59 AM, jblaine <cjbla...@gmail.com> wrote:
> > I've not found an explanation of what is lost by using Puppet without a
> > puppetmaster.
>
> > Does anyone have a link to something like that, or is anyone willing to
> > expound on the topic?
>
> I presented a few weeks ago about how I use puppet, and that included
> masterless.
>
> Searchable slides on one page here:http://semicomplete.com/presentations/puppet-at-loggly/puppet-at-logg...
>
> I include caveats and other stuff to consider for masterless.
>
> All told, while I love masterless, I don't recommend it for the average
> case. Do you have a reason or requirement that makes you want to use
> masterless?
>
> -Jordan
>
>
>
>
>
>
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Users" group.
> > To post to this group, send email to puppet...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > puppet-users...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/puppet-users?hl=en.

I am specifically trying to eliminate the need for puppet master for 2
reasons (i am just scratching the surface on what puppet can do and
how it works. nooby). 1 simplicity to others to use an open systems
management process that has red hat satellite server at the center
(all i want them to NEED to understand is satellite and channels) of
it and 2 so i can use the satellite's disconnected feature to be able
to deliver a complete solution to disconnected networks.

i am packaging puppet content in an RPM's and delivering it that way.
i also believe i have it figured out how to deliver content for
security, application and host in separate RPM's

so i too have been looking for a concise, this is what you loose and a
brief description of what that means in a "mature" enterprise
installation.

I am currently having a healthy debate with 2 folks that are fresh out
of puppet training (jealous) and really want to present good info on
exactly what you gain (simplicity?, no extra infrastructure? with
puppet being integrated with satellite this may be a null point?) and
what you loose.

Regards,

Aaron

Romain Pelisse

unread,
Feb 9, 2011, 6:12:32 AM2/9/11
to puppet...@googlegroups.com
Having your puppetmaster configuration in a git repository and simply ask the puppet (crontab) to periodically fetches configuration changes and run it could also be an approach to a masterless deployment but keeping a centralized configuration... 

Are am I missing "some active" thing (puppetrun for instance) that can do a puppetmaster ?..
--
Romain PELISSE,
"The trouble with having an open mind, of course, is that people will insist on coming along and trying to put things in it" -- Terry Pratchett
http://belaran.eu/wordpress/belaran

Nan Liu

unread,
Feb 9, 2011, 11:19:01 AM2/9/11
to puppet...@googlegroups.com
On Wed, Feb 9, 2011 at 3:07 AM, prayther <pray...@gmail.com> wrote:
>
> I am specifically trying to eliminate the need for puppet master for 2
> reasons (i am just scratching the surface on what puppet can do and
> how it works.  nooby).  1 simplicity to others to use an open systems
> management process that has red hat satellite server at the center
> (all i want them to NEED to understand is satellite and  channels) of
> it and 2 so i can use the satellite's disconnected feature to be able
> to deliver a complete solution to disconnected networks.
>
> i am packaging puppet content in an RPM's and delivering it that way.
> i also believe i have it figured out how to deliver content for
> security, application and host in separate RPM's
>
> so i too have been looking for a concise, this is what you loose and a
> brief description of what that means in a "mature" enterprise
> installation.

There's quite a bit of functionality in Puppet Master so this is not a
comprehensive list. Puppet Master provides a centralized location for:
managing manifests, modules, and environments
syncing custom facts and types/providers
reports
puppet:/// file service
certificates
filebucket backup
collecting facts from clients (future inventory service)

You can achieve some these functionality without a puppet master, but
you would still have the same hurdles for disconnected networks.
Jordan's slides list several differences so I won't reiterate them
here.

Another key difference is the agent only receives a catalog in
master/agent mode. In masterless mode you must provide the puppet
manifest/templates to each client system. The catalog is system
specific and does not contain any configuration information about
other systems, the manifests and templates would have all the
configuration data for all systems.

It would be non trivial to keep the configuration data isolated in
masterless mode if you have a desire to segment and isolate
configuration data by system, or even system roles (i.e. my website
database system should not contain puppet manifest with my financial
database password).

The rest of the features are mainly trade off between a central
service vs. distributed service, and the ability to isolate access
(i.e. if you use an ENC, puppet master is the only system that needs
access to the LDAP/CMDB/database, if you implement something similar
in a masterless environment, every agent needs an account and access
to that central source of information).

Thanks,

Nan

Ryan Dooley

unread,
Feb 9, 2011, 1:19:46 PM2/9/11
to puppet...@googlegroups.com
Okay... that's very cool (and thanks for the github example repo for nodeless puppet!).  This plus the 'scaling puppet with git' [0] concepts I'll use here at Lookout, Inc.  

Cheers,
Ryan

ro001

unread,
Feb 9, 2011, 9:02:27 AM2/9/11
to Puppet Users
emmm everything?!

is the master-client relationship not the whole point of puppet? the
master stores the scripts and the client obtains the instructions in
the scripts from the master. If you have no master, where do you get
your instructions?

Kevin Beckford

unread,
Feb 9, 2011, 3:32:07 PM2/9/11
to puppet...@googlegroups.com
I think it depends on the use case.  I much prefer the git method.  I'm trying to do it the classic way this week, but there is a lot of decisions to deploy an efficient puppetmaster which add complexity and unwanted software to some setups.  

Git does ssh.
Git is far faster.

Finally, the source of changes, really is my puppet repo. 

I'm quite curious about this issue also.

Kevin Beckford

unread,
Feb 9, 2011, 3:42:10 PM2/9/11
to puppet...@googlegroups.com

It would be non trivial to keep the configuration data isolated in
masterless mode if you have a desire to segment and isolate
configuration data by system, or even system roles (i.e. my website
database system should not contain puppet manifest with my financial
database password).


I really am trying to understand here.  To me this is the thing I love about git/merc... wait, I dont love mercurial.  The thing I love about DVCS is that this seems a perfect problem domain for it.  You would be the master, store the total repo on your laptop and push the branches needed, where they need to go.  I suppose that the logic would be in several systems instead of one, but git does distributed versioning better, surely?  Please advise. 

DaveQB

unread,
Feb 9, 2011, 8:22:02 PM2/9/11
to Puppet Users
We have moved to a masterless puppet install after running a server/
client method for over a year (maybe two). We have about 500 machines
but started having trouble with alot less (~100)
The puppet master would consume 8 GB and then crash due to running out
of RAM. The puppet server was too unstable. We went through the
upgrade process for several versions, each time hoping the memory
leaks would be solved. But they were not.
One thing we have is mulitple NFS mounts common to all machines. So
moving to serverless was quite painless and has so far been a HUGE
improvement.

jblaine

unread,
Feb 14, 2011, 3:54:40 PM2/14/11
to puppet...@googlegroups.com
Wow, I'm glad this generated some discussion.  I had almost given up on my post/thread.

Thanks for the replies, everyone.

Jordan, for context, we've been using Cfengine 2.x for 12 years now on ~180 boxes (nowadays) which I was wholly responsible for and continue to be (for lame reasons I won't get into) the person who administers/drives it.  We hook a cfengine run into the end of our network installs (kickstart and Jumpstart) which does its thing, where one of those things is to add our cfengine_run wrapper script to root's crontab (nightly at 3AM + random(100secs)).  We're a "thinktanky" place, not a public-facing web product company.  SW and HW devs, researchers doing NLP stuff, etc.  For more context, I'm extremely averse to shoddy-seeming architectures or software, especially for something as important as configuration management.  To that topic, I had some choice words toward my screen when I came to understand the bogusness that is WEBrick+Rubythreads, and that most do the Mongrel/proxy or Passenger dance.  I'm not going to do that.  It's BS to me, and I'm sure there plenty of people here who will take issue with that.  I'm actually pretty amazed at Puppet's adoption in agent+master form.

So I'm either going masterless Puppet + git repo or something else entirely (Cfengine 3), and I'm just trying to gain a clear picture of the masterless list of cons.  Going from Cfengine 2 to Cfengine 3 is almost as much effort as learning Puppet, so I figured I'd poke around with Puppet.

I've read the Loggly slide deck, but don't quite know enough about Puppet terms yet to extract real meaning from most of the masterless info slides.

Right now, thanks to our existing cfengine 2 setup, I've built and pushed Cfengine 3, Facter 1.5.8, Puppet 2.4.6, Ruby 1.8.7 + rubyssl, and the ruby-shadow module to all of our boxes' local disk.  For Solaris 10, I tweaked ruby-shadow (patch submitted and accepted) and also include the Cfengine 3 dependencies not commonly found: PCRE and Oracle Berkeley DB.

I'm not sure how relevant this is to the topic, but I'll mention it as well in case.  There are two goals to this next-gen CM plan.  The first is to serve our managed machine needs in way that is saner than a gigantic Cfengine 2 config file.  The second is to provide a way for other ad-hoc UNIX/Linux boxes in the organization to benefit from using our tool tree + manifests/configs.  There's no reason for Jim Smith to need to hand-configure the 12 things on his Ubuntu 10.x box to make it worthwhile on the corp. network... etc.  This second goal is largely marketing for our group's capabilities and worth.

At any rate, I think the only thing for me to do is retreat into masterless-Puppet-test-rollout-land until I understand clearly what the limitations (mentioned in the thread here) mean to our goals.

jblaine

unread,
Feb 14, 2011, 3:58:04 PM2/14/11
to puppet...@googlegroups.com
On Wednesday, February 9, 2011 8:22:02 PM UTC-5, DaveQB wrote:
One thing we have is mulitple NFS mounts common to all machines. So
moving to serverless was quite painless and has so far been a HUGE
improvement.

This is what I was planning to do as well (once I understand the other masterless losses more).

Thanks

jblaine

unread,
Feb 14, 2011, 4:06:23 PM2/14/11
to puppet...@googlegroups.com
On Wednesday, February 9, 2011 3:32:07 PM UTC-5, Kevin Beckford wrote:
I think it depends on the use case.  I much prefer the git method.  I'm trying to do it the classic way this week, but there is a lot of decisions to deploy an efficient puppetmaster which add complexity and unwanted software to some setups.  

That's exactly what prompted me to start this thread.  I refuse to go down that road.

Nigel Kersten

unread,
Feb 14, 2011, 4:13:08 PM2/14/11
to puppet...@googlegroups.com
On Wed, Feb 9, 2011 at 8:19 AM, Nan Liu <n...@puppetlabs.com> wrote:

> Another key difference is the agent only receives a catalog in
> master/agent mode. In masterless mode you must provide the puppet
> manifest/templates to each client system. The catalog is system
> specific and does not contain any configuration information about
> other systems, the manifests and templates would have all the
> configuration data for all systems.
>
> It would be non trivial to keep the configuration data isolated in
> masterless mode if you have a desire to segment and isolate
> configuration data by system, or even system roles (i.e. my website
> database system should not contain puppet manifest with my financial
> database password).

This is a very important point that I'd like to reiterate.

In some environments it's simply unacceptable to expose all password
hashes for all services to all machines.

You can work around this in masterless mode with appropriate ACLs and
some custom function work, but you're going to be doing work that a
master does for you.

For certain patterns of usage, a masterless setup may be the way to
go. It's certainly a simpler model for scaling, but you'll probably
want to at least submit reports to a central location.

tom

unread,
Feb 14, 2011, 4:33:11 PM2/14/11
to puppet...@googlegroups.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...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I use Puppet in a standalone mode.
I created a templating system using Perl and TemplateToolkit to create (simple) puppet manifests and configuration files I wish to manage. These are stored in a Git repo that allows me to easily see when changes are made to a servers' configuration before pushing. Rollbacks are possible too in this scenario.
Clients pull via rsync - there is definitely scope for a more robust TLS transport here.
The big plus side here is that I am holding every servers' set of files in a DVCS (as well as my colleagues) so we are less dependant on backups as everyone in the team will hold a fairly recent copy of the entire server farm.
Tied in mainly to CentOS, I can Kickstart a server and let it pull it's own configuration and apply it in mere minutes if I was to loose a server.

As I say, manifests are fairly simple, but enough to manage files, services and other custom executables.

This was inspired by some work a guy did at Oxford University. It seems to scal very well as I am managing 180+ servers this way.

Tom














Geoff

unread,
Feb 15, 2011, 5:31:50 AM2/15/11
to Puppet Users
I'm an advocate of both camps.
I use puppet in standalone mode when I'm demonstrating puppet to a new
client.
It's lightweight, I can use NFS or a CM repository to provide the
recipes to a server and run it standalone post kickstart. It's the
perfect mode for small scale repeatable system builds. Quite often my
clients want a definable set to work. A kickstart template with a CM
controlled puppet recipe works a treat.

But, when the number of systems grows to a certain size, you do not
want the recipes available on each host.
For the reasons Nigel cited, it isn't good security practice to
provide knowledge of all the servers on your estate to each server. It
would be difficult to compartmentalize your recipes via your CM
repository / fileshare to minimise the scope.
The puppetmaster ensures only the server specific catalog is provided.
That's the big win.

Cosimo Streppone

unread,
Feb 21, 2011, 1:20:19 AM2/21/11
to puppet...@googlegroups.com
On Wed, 09 Feb 2011 18:28:49 +1100, Felix Frank
<felix...@alumni.tu-berlin.de> wrote:

> On 02/07/2011 06:59 PM, jblaine wrote:
>> I've not found an explanation of what is lost by using Puppet without a
>> puppetmaster.
>>
>> Does anyone have a link to something like that, or is anyone willing to
>> expound on the topic?
>
> To throw a few buzzwords:
> - access control
> - stored configs
> - modules (?)

Modules apparently worked just fine for me locally without a puppetmaster.

--
Cosimo

James Turnbull

unread,
Feb 21, 2011, 2:09:04 AM2/21/11
to puppet...@googlegroups.com
Cosimo Streppone wrote:
>> - modules (?)
>
> Modules apparently worked just fine for me locally without a puppetmaster.
>

Modules work fine with stand-alone Puppet by specifying a --modulepath.

Regards

James

--
James Turnbull
Puppet Labs
1-503-734-8571

Felix Frank

unread,
Feb 21, 2011, 8:45:02 AM2/21/11
to puppet...@googlegroups.com
On 02/21/2011 07:20 AM, Cosimo Streppone wrote:
> On Wed, 09 Feb 2011 18:28:49 +1100, Felix Frank
> <felix...@alumni.tu-berlin.de> wrote:
>
>> On 02/07/2011 06:59 PM, jblaine wrote:
>>> I've not found an explanation of what is lost by using Puppet without a
>>> puppetmaster.
>>>
>>> Does anyone have a link to something like that, or is anyone willing to
>>> expound on the topic?
>>
>> To throw a few buzzwords:
>> - access control
>> - stored configs
>> - modules (?)

In IRC, RI Pienaar noted that, in fact, *all* of the above work in
masterless operation (even though you have to rely on access control
mechanisms other than those found in puppet).

Cheers,
Felix

Reply all
Reply to author
Forward
0 new messages