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? -- 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 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 (?) 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 -- 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.
jblaine wrote on 02/07/2011 06:59 PM:> 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?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-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.-- 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 Mon, Feb 7, 2011 at 9:59 AM, jblaine <cjblaine@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-loggly.pdf.html 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-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. >-- 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 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-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.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 -- 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.
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 ?.. On 9 February 2011 12:07, prayther <prayther@gmail.com> wrote:> > > 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-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. > > 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 > > -- > 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. > >-- 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 -- 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.
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? On Feb 7, 10:59 pm, 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?-- 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, Feb 9, 2011 at 3:07 AM, prayther <prayther@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 -- 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.
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 [0] - http://bitfieldconsulting.com/scaling-puppet-with-distributed-version-control On Feb 9, 2011, at 1:15 AM, Jordan Sissel wrote:> > > On Mon, Feb 7, 2011 at 9:59 AM, jblaine <cjblaine@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-loggly.pdf.html > > 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-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. > > > -- > 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.-- 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.
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. -- 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.
> 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 loveabout 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. -- 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.
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. On Feb 8, 4: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?-- 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.
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. -- 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 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> On Feb 8, 4: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?-- 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 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. -- 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, Feb 9, 2011 at 8:19 AM, Nan Liu <nan@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. -- 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 09/02/11 20:42, Kevin Beckford wrote:> > 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. > -- > 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.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 -- 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.
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. On Feb 14, 9:33 pm, tom <tom.ash...@gmail.com> wrote:> On 09/02/11 20:42, Kevin Beckford wrote: > > > > > 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. > > -- > > 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. > > 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-- 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, 09 Feb 2011 18:28:49 +1100, Felix Frank <felix.frank@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 -- 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.
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 -- 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 02/21/2011 07:20 AM, Cosimo Streppone wrote:> On Wed, 09 Feb 2011 18:28:49 +1100, Felix Frank > <felix.frank@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 -- 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.