Re: [Puppet Users] is there a way to make the puppetlabs/firewall module implement the iptables -P flag?
On 15 March 2012 22:39, Chris O'Donnell wrote: > With our current iptables rules, we implement the following in a script: > > iptables -P INPUT DROP > iptables -P FORWARD DROP > iptables -P OUTPUT ACCEPT > > Then the script continues on and does the rest of the rules. some custom > policies, etc.Now we're moving to Puppet and trying to replace all of our > scripts. From what I can tell, the puppetlabs/firewall module doesn't allow > a way to set the default policy for a default chain. By default, the > puppetlabs/firewall module sets it as: > > INPUT ACCEPT > FORWARD ACCEPT > OUTPUT ACCEPT > > I've tried going through the module to implement this, but my Ruby skills > aren't there yet. As this would be the default in all of our rules, I don't > need a full implementation (i.e. able to set this from a pp file), I just > need to be able to set it as the default for all iptables settings. Anyone > have a hack (ugly or not) to implement this? I'm looking at other firewall > modules, but this one is pretty slick, and would like to use this one > (albeit with this modification) if possible. > You can achieve the same effect with a default DROP/DENY rule at the end of your chain. I have some fondness for this approach, being one of the many hapless sysadmins that has once locked themselves out of a machine by running "iptables -F" without paying attention to the policy defaults. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Using fact to determine node environment
On 2 May 2012 12:19, R.I.Pienaar wrote: > > your only option at present is to write out puppet.conf using a template > with your fact We use this approach. The very first run gets called with "--environment foo" and it sticks. "--environment" can then be called again if it needs to move to another environment/branch. "puppet.conf" simply contains: # Make environment "sticky" with each run. # Populated by `environment` variable from Facter. environment = <%= @environment %> -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Check if class has been included?
On 3 May 2012 23:32, jcbollinger wrote:
>
> Hmm. I guess I misunderstood your objective. It is still true that
> 'defined' is not a good approach, however, and also that
> os::motd::register is a bit rude to not take care of declaring its
> dependencies itself.
>
> It might work to declare all your os::motd::register instances
> virtually, right where they now are, and then collect them at the end
> of each node definition. I suspect, though, that you would end up
> with the same problem you already have.
>
> Generally, I recommend replacing "is foo defined?" conditions with "is
> foo *supposed to be* defined?". The latter can be evaluated based on
> global or class variables, or (better) external data.
It's a fine use case for virtual resources. Each class would declare the
virtual:
class pulp {
@os::motd::register { $name: }
...
}
Then os::motd would, when included in the catalog, collect/realize
everything available:
class os::motd {
Os::Motd::Register <| |>
...
}
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Thoughts on preseed vs config files?
On 2 May 2012 19:42, Brian Gupta wrote: > So having an internal debate on whether to use puppet managed debian > preseed files to configure packages prior to installation or > installing with no-config and using puppet to manage the config files > after the fact. > > The end of the discussion is that ideally one would use both, but if > one had to chose just one, it would be puppet managing the configs, > with the exception of certain packages that gain more benefit than > average by being configured through debconf. e.g. - Setting root mysql > password, so that debian maint. cron jobs can run without issue. > > Thoughts? If you had to choose one then I would shoot for the latter. Consider that you want to maintain the state of the machine, not just it's initial installation. If one of those configs changes, because you need to roll out a new MySQL setting or someone gets naughty with vi(1), then you'll want to enforce that without going through the package installation again. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Can you check a setting set in puppet.conf from within a module
On 25 April 2012 08:30, Peter wrote: > Hi Gary, > > Thank you very much! I thought it may have been a scoping issue! > > Peter. > > On Apr 25, 8:56 am, Gary Larizza wrote: > > Hey Peter, > > > > You should be able to do $settings::storeconfigs to get that value. > Speaking of scope, you probably want to use $::settings::storeconfigs -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Installing Jenkins with Puppet fails to import GPG key
On 27 April 2012 06:15, denmat wrote: > > Normally what happens is that if it is 'assumed yes', yum will > automatically accept the public key via the url - I don't know why > Jenkins is different - but it appears to install a new repo file and > try to import the pubkey again on install - maybe this confuses yum? > Just speculating - not going to investigate further :) > The problem stems from Yum on EL5 not being able to parse user attributes within key. It can be worked around a bit more cleanly by removing the attribute from the public key. I've written a blog post with more details: http://dan.carley.co/blog/2012/05/22/yum-gpg-keys-for-jenkins/ -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] rspec spec_helper
On Jun 4, 2012 5:07 PM, "Jeff McCune" puppetlabs.com > wrote: > I'll leave the description to Branan but please be aware that we're > actively and currently working to centralize all of this into a single > repository named puppetlabs_spec_helper. The goal of this repository > is to provide a single place that abstracts away the details of > initializing Puppet for spec testing. This includes initializing > Puppet for use with modules being spec tested. And, by the looks of it, will depend on rspec-puppet for core functionality. Which is great news. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Using with EC2 (and auto-scaling)
On 21 July 2011 16:41, John Fieber wrote: > I use instance userdata to configure puppet (via ubuntu cloudinit) and set > an explicit certname, in the form: > > -- > > The server uses a a node classifier that fabricates the node spec from > that. > Similarly I've used a port of cloud-init baked into a minimal CentOS AMI. Vanity hostname (under our own zone), location of the Puppet master, environment and some misc stuff are defined as YAML in the instance's user-data. The stock cloud-init modules set the machine's hostname and populate "puppet.conf" from user-data on boot, amongst other things. A custom route53 module registers a CNAME for the instance's vanity hostname, pointing to Amazon's split horizon record. If the instance reboots then it updates DNS with it's new dynamic address. Those vanity hostnames then serve as static records which can be used for Puppet certs and nodes in manifests. Not ideal, but seems to work pretty well. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Managing sudo via puppet using #includedir
On 3 August 2011 07:07, Iain Sutton wrote: > To add a newline, put the closing double quote on a new line. > > content => "zabbix ALL=NOPASSWD: /var/lib/zabbix/bin/start_puppet", > > becomes > > content => "zabbix ALL=NOPASSWD: /var/lib/zabbix/bin/start_puppet > ", > Or, cleaner IMHO: content => "zabbix ALL=NOPASSWD: /var/lib/zabbix/bin/start_puppet\n", -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: setting the hostname automatically of EC2 puppet clients
On 3 August 2011 03:14, edovale wrote: > If you are on ubuntu the I understand that you could set the hostname > using cloud-init like explained here: > https://help.ubuntu.com/community/CloudInit It's also possible to use cloud-init on EL based distros, as seen in the Amazon Linux AMI. I have patches for vanilla cloud-init on CentOS/RHEL that I might tidy up and release if there's interest. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] pluginsync before catalogue?
On 3 August 2011 04:38, josbal wrote: > Hi All, > > I have an issue with puppet where we are getting errors on some of our > new built servers where the catalogue is trying to render before > distributing custom facts that are required to render the catalogue > correctly. > > We are running puppet 2.6.6 server and client. > > Error: > err: Could not retrieve catalog from remote server: Error 400 on > SERVER: Failed to parse template sudo/sudoers: Could not find value > for 'customfact1' at /etc/puppet/default/modules/sudo/manifests/ > init.pp:11 on node host.example.com > > Its my understanding the 'customfact1' fact is meant to be transferred > to the host as part of the pluginsync process before the catalogue is > rendered, but this doesn't seem to be happening on our new builds from > the above error. > > Does anyone have any insight into the pluginsync/catalogue process and > how this is fixable? > The "pluginsync" config var defaults to false. I believe there's a ticket to default it to true in the future. But until that happens you have a few options: 1. Populate "pluginsync = true" in "puppet.conf" before the first run. 2. Use the "--pluginsync" argument on the first run 3. Possibly use stages to send out the correct "puppet.conf" before any modules use variables that are populated by custom facts. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] facter-1.6.0 incorrectly identifies hardware node as virtual
On 17 August 2011 22:44, Jake wrote:
> I've installed facter-1.6.0 and puppet-2.7.3 on a number of SLES 10
> hardware nodes (HP DL580) running the Virtuozzo hosting software.
>
> Well, facter correctly identifies such a machine as a hardware node
> ("virtual => openvzhn") but somehow concludes that the hardware node
> is in fact virtual. ("is_virtual => true")
>
> This breaks some rather important logic. If anyone knows of a patch
> floating around out there for 1.6.0 I'd be obliged. Even better would
> be to get this officially fixed for facter-1.6.1.
>
You can try this: https://gist.github.com/1153679
To get it fixed in the next release you'll need to file an issue over at:
http://projects.puppetlabs.com/projects/facter
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: facter-1.6.0 incorrectly identifies hardware node as virtual
On 18 August 2011 18:38, Jake wrote: > Excellent, thanks - patch applied here with good results. > > It appears the issue is already known as of facter-1.5.9: > http://projects.puppetlabs.com/issues/7957 > > So, the ball should already be rolling on this one - right? > I missed that in my brief search. I've commented with said patch and unit tests. Should be fixed upstream in the future. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] help with the firewall puppet forge module
On 25 October 2011 22:49, David Alden wrote: > I got: > > err: Could not autoload firewall: no such file to load -- > puppet/util/firewall at /etc/puppet/modules/snmp/manifests/config.pp:9 > on node ns2.math.osu.edu > > I tried "puppet describe firewall" and got: > > Could not run: Could not autoload > /etc/puppet/modules/firewall/lib/puppet/type/firewall.rb: no such file > to load -- puppet/util/firewall > For the benefit of the archives, you'll also see the same error if used in master-less setup with "puppet apply". It's related to this bug: https://projects.puppetlabs.com/issues/4248 A hacky workaround is to make all the requires relative to __FILE__ like this: https://gist.github.com/1315760 -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Rounding in variable expressions
On 15 November 2011 16:57, Jacob Helwig wrote:
> On 2011-11-15 07:24 , Tom Hall wrote:
> > Hi,
> >
> > Can you round in variable assignment expressions?
> >
> > I would like to be able to set
> >
> > $my_var = floor(::processorcount * 0.8)
> >
> > Cheers,
> > Tom
> >
>
> That should work just fine as long as you define an rvalue function
> called 'floor'. There should be a bunch of good examples of how to do
> this in the stdlib[0] repo in lib/puppet/parser/functions.
>
> [0] https://github.com/puppetlabs/puppetlabs-stdlib/
I suspect it won't be a trivial or generic function. Puppet won't be able
to do the initial arithmetic within the braces because $::processorcount is
a string. So you might end up with something like
"multiply_floor($::processorcount, 0.8)" or
"floor(str2int($::processorcount) * 0.8)".
Alternatively the cheap and hacky approach:
$foo = inline_template("<%= (processorcount.to_i * 0.8).floor -%>")
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] [foreman-users] dropping support for ruby 1.85?
On 17 Nov 2011 22:42, "Michael Stahnke" wrote: > A while back you could just take the srpms from Fedora's 1.8.7 and > they would build pretty easily on EL5. I haven't tried that for a > while, but you can at least get the RPMs from a known source that way. SRPMs from EL6 (which has Ruby 1.8.7) are a much safer bet now. Which is what Karanbir's aforementioned repo is. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: [Puppet-dev] Puppet IRC logs
On 22 November 2011 06:36, James Turnbull wrote: > Hi all > > I finally got around to fixing the IRC logs up a little and adding them > to their own site: > > http://www.puppetlogs.com/ > > The site contains search-able IRC logs for #puppet and #puppet-dev going > back to late 2007 or so. > > It's maintained by me (not Puppet Labs) so best to contact me for issues > rather than bother anyone else. > Nice work. Always a great resource for finding information about obscure error strings. Small request: could you setup a ServerAlias for "puppetlogs.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-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Evaluate the value of a variable's value
On 18 April 2010 04:24, Andrew Heagle wrote:
> Hi,
>
> Is it possible for puppet to do the equivalent to this in bash:
> and...@comet:~$ a=1
> and...@comet:~$ x="a"
> and...@comet:~$ eval echo \$$x
> 1
>
> Or this perl:
> #!/usr/bin/perl
> $a=1;
> $x="a";
> print $$x;
> (Output would be 1)
>
> Or would I need to write a function to do this?
>
It's possible with inline_template():
dan.car...@jim ~ $ puppet
$a = 1
$x = "a"
notice("Bad:", inline_template("<%= x %>"))
notice("Good:", inline_template("<%= $x %>"))
^D
notice: Scope(Class[main]): Bad: a
notice: Scope(Class[main]): Good: 1
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Setting Variable in Class or Node and Using in Included Module
On 27 April 2010 08:52, Peter Meier wrote: > The best practice is to either go with an external node tool for > complexe node definitions or at least not to use any includes in > super-nodes which behavior you want to tweak with variables in > sub-nodes, as inheritance in nodes don't work the way most people expect > it. > Or similarly move the configuration data out of your manifests using RIP's extlookup[0]. I use the precedence to set NTP servers on a default, per-domain or per-host (less common) basis. [0] http://code.google.com/p/extlookup/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] puppet for switches
On 5 May 2010 16:54, Gary Law wrote: > > Before reinventing the wheel in terms of grabbing and storing > switch/router/firewall configs, take a look at this: > > http://www.shrubbery.net/rancid/ And http://trac.nocproject.org/trac/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] custom facts run three times?
On 6 May 2010 17:05, Joe McDonagh wrote: > > I have this similar issue- I notice the "loading facts in " message > twice when running puppet. Likewise - printed twice. It's been low on my priority list because it doesn't seem to have any negative effect, but since you mention it. Facter 1.5.2 Puppet 0.25.4 Excerpt from puppet.conf: vardir = /var/lib/puppet factpath = $vardir/lib/facter pluginsync = true -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] custom facts run three times?
On 6 May 2010 18:46, Michael DeHaan wrote: > Yeah, that's not so efficient. > > Please file a bug on this one! Duly filed. http://projects.puppetlabs.com/issues/3741 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Provisioning VM in Xen via Puppet - Howto??
On 12 May 2010 16:13, Thomas Bellman wrote:
> [..]
> I don't create the logical volumes automatically, nor do I
> partition or create filesystems on them automatically, to lessen
> the risk of destroying important data.
Good info. I do much the same - logical vols are managed by hand first.
Then initial booting of the domU is handled automatically with notify's to
some exec{}'s so I don't have to log back in. Like:
exec { "xm_create_${domu_name}":
command => "/usr/sbin/xm create /etc/xen/auto/${domu_name}",
unless => "/usr/sbin/xm list ${domu_name} > /dev/null",
refreshonly => true,
}
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Using a set of recipes to build stuff from source...
On 19 May 2010 21:17, Peter Berghold wrote:
> I thought that as well, but didn't really want to just yet.
>
> If I go that route I guess it will mean I'll have to get around to doing
> something I've been putting off.. I've been planning to build a custom yum
> repository but that was not going to happen right way.
I suspect you'll find that the initial install is quite easy. It's the
subsequent upgrades that will be a tangled mess of exec{}, require and
onlyif.
Seriously, roll your own packages and use the package{} type now. You'll
thank yourself later.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Nginx/Mongrel Could not retrieve catalog from remote server: Error 403 on SERVER
On 8 June 2010 10:06, Jomo wrote: > It works well when I use webrick. The config of nginx is from puppet > wiki, some logs is below, what's wrong? > I suspect that it relates to the use of HTTP headers and Puppet not knowing who the client is from it's certificate. The wiki documentation assumes that you're launching puppetmasterd with the argument `--ssl_client_header=HTTP_X_SSL_SUBJECT`. It does so in order to maintain configuration compatibility with Pound. But personally, I don't use Pound and prefer to keep Puppet as vanilla as possible. The following (exclusive) `proxy_set_header` directives work fine under for me: proxy_set_headerHost$host; proxy_set_headerX-Real-IP $remote_addr; proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_headerX-Client_DN $ssl_client_s_dn; proxy_set_headerX-Client-Verify $ssl_client_verify; You don't mention what version of Nginx you're using. They'll need adjusting suitably for <0.8.x -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Storeconfigs connection pool problem
On 9 June 2010 06:09, Jason Koppe wrote: > On Fri, Feb 12, 2010 at 12:28 AM, Joe McDonagh < > joseph.e.mcdon...@gmail.com> wrote: >> >> Daniel Kerwin wrote: >> > Hi list, >> > >> > i just enabled storeconfigs and cannot use puppetrun on more than 5 >> > hosts. When i try 6+ i get the error message: >> > >> > puppetmasterd[16209]: could not obtain a database connection within 5 >> > seconds. The max pool size is currently 5; consider increasing it. >> > >> > My Mysql setup allows a lot more connections (500). Any suggestions? >> >> Do you have the proper rubygem for mysql installed? I think on >> deb/ubuntu it's something like libmysql-ruby1.8. > > > I'm having the same problem with the mysql gem installed and the gem > appears to be in-use > The gem version is a bit of a red herring, so long are using the gem and not Ruby's own connector. As the warning suggests, ActiveRecord's pool option simply needs raising if it's to be put under any strain at all. There is a bug/feature ticket as #2568 [0] which exposes this option to Puppet's configuration. But it's not due to be delivered until 2.6/rowlf. I've been slipstreaming the patch into 0.25 myself because storeconfigs grinds to a halt without it in my environment. Given the simplicity of the diff and that it seems to be affecting a number of people I think it probably warrants being brought forward to 0.25. [0] http://projects.puppetlabs.com/issues/2568 -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] nginx + passenger + puppetmaster
On 28 June 2010 23:03, Dan Urist wrote: > Has anyone gotten puppetmaster running under nginx with passenger? I've > tried various permutations of setting headers in the nginx config file, > but am still getting "Forbidden request" errors from the client. > Sounds like this.. http://groups.google.com/group/puppet-users/msg/cae809c17a9acd8a -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] ERB / Tagging...
On 30 June 2010 18:40, CraftyTech wrote:
> Hello All,
>
> Can someone point me in the right direction here. I'm trying to
> create an erb template for my /etc/hosts file, so that when executed,
> it populates the /etc/hosts file only with entries that are tag
> relevant. For instance, if a server is tagged apache, only the apache
> tagged entries would be populated into the /etc/hosts file. Thanks in
> advance for you help.
This is possible with `if all_tags.include?("")`.
But, and a big but, it is highly dependent on the order which your modules
are compiled[0]. It will prove unreliable if your Apache module happens to
be `included` after the module which is creating the templated hosts file.
For this reason it will introduce extra use complexity into your modules and
most people will probably recommend that you use facts instead.
It happens to be a bit of a bug bear of mine because it is otherwise quite a
useful feature that precludes the mess of populating additional facts. The
conundrum is similar to a recent thread[1] entitled "do X if package Y is
installed".
[0] That is "compiled" by the puppetmaster. Not "executed" by the puppet
client.
[1]
http://groups.google.com/group/puppet-users/browse_thread/thread/b037fa88eb09b8ae
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: ERB / Tagging...
On 1 July 2010 18:17, jb wrote: > This also vexes me, I also would love to use 'all_tags', but it's not > consistent. The issues is best described in the following bug, I > believe: > > http://projects.puppetlabs.com/issues/3049 Good call. I wasn't aware there was an existing ticket for it. For what it's worth, I have conceded to using all_tags in some cases, by writing and documenting the execution order into my manifests. I've had a number of instances whereby I want module X to behave differently if module Y is present, without having to put additional cross-dependencies into module Y. It's not something that I'm thrilled about though because the principle of least surprise is out the window if you pick up a module and use it in a slightly different way. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Package requires....
On 1 July 2010 00:32, Douglas Garstang wrote:
> If I have a package { "foo": ensure => installed; require => something
> } in a module, AND I also have a Package { require =>
> Class['yum::client']} in site.pp, what happens in the module? Does the
> package in the module require both 'something' and the yum::client
> class, or does the fact I specified a package{} with a require in the
> module mean that only the yum::client class is required?
>
The latter will happen. The default will be replaced by the explicit
statement in package{"foo"}. You might want to look into plusignment (+>) to
do this, but there are some caveats to it's usage. Such as feature #2825.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Splitting classes into separate files
On 5 July 2010 15:11, Thomas Bellman wrote:
> On 2010-07-03, Jeff McCune wrote:
>
> > In this module, if you use the following orginization puppet will
> > autoload everything:
> >
> > manifests/init.pp contains class apache { }
> > manifests/disable.pp contains class apache::disable inherits apache {}
> > manifests/virtualhost.pp contains define apache::virtualhost(){}
>
> Yuck! Forcing each class or define into its own file sucks royally.
> No sane person wants their code organized like that.
Really? I find it a much more manageable way to work, rather than wading
through lines of `init.pp` to find the relevant class or maintaining lists
of slightly artificially named `import` statements. It also provides some
more reliable behaviour with regards to caching of compilation failures.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Splitting classes into separate files
On 5 July 2010 16:27, Patrick Mohr wrote:
> I usually put some of the really small classes in init.pp. For instance,
> do you put your packages classes in their own file?
>
> class apache::package {
> package { apache2: ensure => present }
> }
>
> Would you put this in it's own file?
>
Yeah. I uniformly split all classes and definitions into their own files,
big or small.
I wouldn't typically put that snippet into it's own class - but that's
probably another 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-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Recipes release management : separate test and prod
On 5 July 2010 11:01, Jean-Baptiste Barth wrote: > For the moment we only have 1 puppetmaster here. I noticed that if I have a > syntax error in one of my included .pp, then puppet runs fail on all nodes > (even if they do not use this recipe), which is not acceptable. More > generally, working directly on production recipes seems too riskee, since > people who will manage those recipes are not devs but sysadmins, which means > poor development skills (and no versionning for the moment). > > I found the documentation about puppet "environments" ( > http://docs.puppetlabs.com/guides/environment.html ) : does anybody use it > here ? I also read some of you have 2 puppetmasters running on different > ports, for test and prod : how do you do that (init scripts available > somewhere? different conf/manifests directories? sync between test and > prod?). Do you have a pool of client machines dedicated to your tests ? Do > you handle this kind of problems directly with your version control system > (post hooks?), or maybe at an other level in your external node provider ? > Mostly echoing Daniel Pittman's comments.. - We use environments a lot. The default production environment is for, well, production. All other environments are for development use. Each has their own SVN branch and Puppet `manifest`/`modulepath`/extlookup directives. - In addition to custom types, providers and facts, flapping back and forth between environments. It's also not possible to have separate fileservers for additional paths between environments. But it's probably not something that will affect you at this stage. - We have virtualised dev/staging machines which reflect the roles of our production machines, only on a slightly smaller scale. Any changes get pushed here and monitored first. We also have some shell scripts which are a shorthand for `--test --noop` to quickly review what is going to happen for a given machine. When we're happy with the results then the changes get merged to production. - Syntax errors are caught by a pre-commit hook. It won't guard against stupid yet syntactically correct code. But it does vastly reduce the time spent dealing with simple humanoid typos. - Be sure to version control your manifests from day one. Without doing so, you'll have no way of knowing who changed what and when. Nor the ability to roll back to a point in history. It will also provide you with an easy mechanism to peer review any code that you're not confident with, as Daniel notes. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Recipes release management : separate test and prod
On 6 July 2010 21:21, James Turnbull wrote: > Just so people know this is fixed in 2.6 and when we're finished > hammering the alpha into a beta - we'd love you guys to test this. > Sure, I'll try and put some time aside for testing. It sounds like 2.6 should resolve a few of the bugbears I've accumulated over time. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] conditional execution of package
On 9 July 2010 08:18, Patrick Mohr wrote: > It's probably better to make a package instead. +1, roll a package. Your life will be easier. The sun will shine. Birds will serenade you. Beer will flow from fountains. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Deploying Splunk using Puppet
On 13 July 2010 11:23, Matthew Macdonald-Wallace wrote: > We're looking at deploying Splunk using puppet - can anyone give any > guidance on the best way to do this? > > We need to setup light-forwarders and an indexing service via puppet > manifests however it looks like we're going to have to maintain a > custom yum repo - how do other people do it? > I opted for syslog-ng TCP/SSL forwards, instead of Splunk's own light forwarders, because I wasn't keen on adding the additional proprietary dependency on each frontend node. Each node configures itself to send the relevant logs back to a central host and Splunk indexes from a pattern of directories therein. I also wrapped the web service up with Nginx for some additional security. You can find my modules here: http://github.com/dcarley/puppet/tree/master/modules/service_splunk/ http://github.com/dcarley/puppet/tree/master/modules/service_syslog/ I suspect that you will almost certainly need to roll your own package if you want to play with the latest and greatest Splunk 4.1. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Classes in templates
On 23 November 2010 19:27, Dan Bode wrote: > > This is unfortunately true. It's possible that this may work in a future > version. > It's described by this ticket: http://projects.puppetlabs.com/issues/3049 Which you might want to add yourself as a watcher to, Alaric. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Namespacing, includes and module lookup. Bug?
On 24 December 2010 11:11, Daniel Piddock wrote:
> Hey all,
>
> I'm not sure if I've made a fundamental misunderstanding of Puppet
> namespacing and include resolution or whether there's a bug.
>
> Background:
> I have a modules, called kerberos, that configures a client for working
> on my kerberos domain. I then have a module called ssh that sets up a
> basic sshd. I wanted to create a ssh::kerberos class in the ssh module
> that extends my ssh setup with kerberos support. I wanted to put a
> dependency on the kerberos module. However things fell apart and there
> was lots of hair tearing thinking I'd done something stupid (e.g. a
> typo.) I now believe it's not that simple...
>
> ..
>
> Is this by design? If so, how do I specify module, not subclass, in the
> include/require?
> Is there a bug?
>
It's a bug, IMO. One which seems to be cropping up more frequently.
I think it's quite a common use case to have sub-classes of the same name as
top-level classes. For instance, I have a number of classes like
'php::mysql', 'python::mysql' and 'exim::mysql' which all 'include mysql' in
order to pull in common MySQL client functionality.
The trouble is that the resolution of a class name always begins relative to
the current class. If it's able to satisfy the include from within the
current class namespace, including the current class itself, then it won't
check the top-level. It can be demonstrated with a simplified example:
"""
d...@dan-macpro:~$ puppet apply
class bar {
notify { "bar": }
}
class foo::bar {
include bar
notify { "foo": }
}
include foo::bar
^D
notice: foo
notice: /Stage[main]/Foo::Bar/Notify[foo]/message: defined 'message' as
'foo'
"""
You can see that Class["bar"] and Notify["bar"] have both been ignored. I
suspect that in a lot of cases this behaviour will go unnoticed by people.
It's not until you add a require to the resource that the loop is then
exposed with a failure:
"""
d...@dan-macpro:~$ puppet apply
class bar {
notify { "bar": }
}
class foo::bar {
include bar
notify { "foo":
require => Class["bar"],
}
}
include foo::bar
^D
err: Could not apply complete catalog: Found dependency cycles in the
following relationships: Notify[foo] => Notify[foo]
"""
There are some hack-ish ways to work around it. You can specify that all of
your includes come from the top scope by prefixing them with ::, such as
'include ::mysql'. But this makes for some pretty long winded manifest
writing if you want to be sure 100% of the time. There isn't
an equivalent syntax for require meta-parameters. You can achieve
something vaguely similar with 'require ::mysql' which will create
dependencies from all resources in the current class. It's certainly not the
same effect though.
I spoke to James Turnbull and some others on IRC about this a couple of
weeks ago. I believe he was going to see whether it fitted in with an
existing ticket. If there isn't one, then something new needs to be
raised. What I'd really like to see is that all class naming becomes
absolute. That would leave much less scope for this kind of confusion and
erratic behaviour.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Concat Module posted to Onyx Point Github.
On 12 June 2011 20:21, Markus Falb wrote:
> I also tried with 0.25.5 and noticed that your module does not work.
> All autorequire stuff does not work. It seems like things like
>
> if catalog.resources.find_all { ... }.empty?
>
> is always true. I have no clue why.
It's because "catalog.resources()" only returns an array of strings on
0.25.x
There might be another way to construct the autorequires. Not sure though.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
