Thanks Doug and Rich. Yes, I guess I am using the default webrick server. I just enabled the puppet-master service in init.d and assumed that was enough. We already have an Apache instance and I will look into passenger. Based on what I see on the Passenger page, this alone could be the cause of all my network issues.
I *do* know all about organizing puppet manifests into modules. I didn't really want to get into this but, here you go. The idea behind currently having just one site.pp file and that's it is that we're evaluating puppet and don't have many rules. It is just not a good use of anybody's time to have 12 rules split up into 6 modules with 18 (24?) different files when you could do it all in one file. As our puppet rules grow (along with our puppet experience) we will refactor. Good to know that Puppet Dashboard is on the outs and puppetdb+puppetboard is the way to go. Should we need such functionality in the future, I'll (IDE? Vim and emacs do my syntax highlighting just fine thank you. ;-) The last three comments could be summarized by our philosophy here at work that we're lean and mean and we'd never install a "framework" when a few lines of bash or perl code would do the trick just as well. Yes, we do use custom facts to define a server's geographical location (e.g. important for our NTP and SNMP config) and its internal purpose. Doug hints at using some kind of dynamically generated fact to get a different manifest from the master (e.g. daily vs. weekly manifest); I will investigate that. Puppet being useful for deploying servers. Absolutely, that's a great point. Thing is, we already have a fully functional kickstart + post-install bash script process to do just that already. We *may* replace this with puppet, if we decide we love puppet and can't live without it. But for now, if it ain't broke don't spend weeks coding and debugging up a replacement for it that's no better. Thanks again, Steve On Tuesday, 17 June 2014 01:23:22 UTC-4, Doug_F wrote: > > Steve, > > I think you said you put all your configuration in a single site.pp. This > is often bad form and limits the flexibility of your deployment. Something > we do is layout modules. > > The common pattern is: > /etc/puppet/environments/production > -> Manifests/site.pp > -> Hieradata/*.yaml > -> Modules/foo > > This keeps everything in the production environment. All of your clients > will do this normally. One of the beauties of doing this is you may want to > do a cron job weekly that runs with a different environment like "weekly". > To take advantage of the flexibility you may want to group servers into > buckets by sticking custom facts and including modules based off them. > > As for the Network issues. I think you may be running your puppetmaster > with the built in webbrick server. In my experience this offers a single > threaded approach to the puppetmaster with it failing if more than one > client connects at a time. Setup apache and run Passenger to allow for > multiple threads. > > Info on Environments: > > http://docs.puppetlabs.com/puppet/latest/reference/environments.html#enabling-directory-environments > > (note this was introduced in 3.5 so you may want to checkout the legacy way > to achieve the same thing. ) > Passenger with Apache: > http://docs.puppetlabs.com/guides/passenger.html > > Finally to get visiblity into the network I would strongly suggest setting > up PuppetDB with Puppetboard as puppet Dashboard is effectivly dead. > > Info on PuppetDB > http://docs.puppetlabs.com/puppetdb/2.0/install_from_packages.html > PuppetBoard module on the forge. > https://forge.puppetlabs.com/nibalizer/puppetboard > > Last tip I would give to someone new is use an IDE that helps you code. > Puppetlabs maintains Geppetto for this purpose. > http://docs.puppetlabs.com/geppetto/4.0/ > > On Mon, Jun 16, 2014 at 1:33 PM, Stephen Morton <stephen....@gmail.com > <javascript:>> wrote: > >> I've got some newbie puppet questions. >> My team has a tremendous amount of linux/computer knowledge, but we're >> new to Puppet. >> We recently started using puppet to manage some 100 servers. Their >> configs are all pretty similar with some small changes. >> >> ---- >> History >> >> Prior to Puppet, we already had a management system that involved having >> config files under revision control and the config file repo checked out on >> every server and the repo config files symlinked into the appropriate place >> in the filesystem. Updating the repo would update these files.This was >> mostly just great, with the following limitations: >> >> >> - If the symlink got broken, it didn't work. >> - Some files require very specific ownership, or were required not to >> be symlinks (e.g. /etc/sudoers. /etc/vsftpd/ files I think) >> - Updating a daemon's config file does not mean that the daemon is >> restarted. e.g. updating /etc/httpd/conf/httpd.conf does not do a >> "service >> httpd reload" >> - You can't add a new symlink. >> - All files must be in revision control to link to. Some >> security-sensitive files we want to only be available to some servers and >> something like puppet that can send files over the network is a good >> solution to this. >> >> ---- >> >> Puppet to the rescue? >> >> So we've tried a very conservative Puppet implementation. We've left our >> existing infrastructure and we just add new rules in Puppet. So far, we >> have a single site.pp file and only a dozen or so rules. But already we're >> seeing problems. >> >> 1. Puppet is good for configuring dynamic stuff that changes. But it >> seems silly to have rules for stuff that will be configured just one time >> and then will not change. If we set up some files, we don't expect them >> to >> disappear. In fact if they do disappear we might not want them silently >> fixed up we probably want to know what's going on. Doing everything in >> puppet results in ever-growing manifests. I don't know of a way to >> specify >> different manifests, e.g. every 30 minutes I want Puppet to run and >> request >> the lean and mean regular manifest and then once a week I want it to run >> the "make sure everything is in the right place" manifest. >> 2. Puppet seems very sensitive to network glitches. We run puppet >> from a cron job and errors were so frequent that we just started sending >> all output to /dev/null. >> 3. Endless certificate issues. It's crazy. So sometimes hosts would >> get "dropped"... for unknown reasons their certificates were no longer >> accepted. Because we'd already stopped output (see previous bullet point) >> we would not know this and the server would be quietly not updated. And >> when you get a certificate problem, often simply deleting the cert on the >> agent and master won't fix it. Sometimes a restart of the master service >> (or more?) is required. >> - The solution to this to me is not "you should run puppet dashboard, >> then you'd know". This shouldn't be failing in the first place. If >> something is that flaky, I don't want to run it. >> >> (We're running version 3.4.2 on CentOS 6.5, 64-bit.) >> >> --- >> >> Questions. >> >> So my questions for the above three issue are I guess as follows >> >> 1. Is there a common Puppet pattern to address this? Or am I thinking >> about things all wrong. >> 2. Is there a way to get puppet to be more fault-tolerant, or at >> least complain less? >> 3. Are endless certificate woes the norm? Once an agent has >> successfully got its certificates working with the server, is it a known >> issue that it should sometimes start to subsequently fail? >> >> >> Thanks, >> >> >> Steve >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to puppet-users...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/08b72832-d18a-4397-9587-a769f0ee2d6e%40googlegroups.com >> >> <https://groups.google.com/d/msgid/puppet-users/08b72832-d18a-4397-9587-a769f0ee2d6e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/405a02b2-6b71-446b-9be1-ec979bc4c781%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
