[Puppet Users] Different paths based on environment
Hi All,
In our environment, we have production and DR puppet clients that live on
different networks. Currently, we do things like "include s_service::prod"
or "include s_service::dr", etc. Both of these subclasses would inherit from
s_service where common things lie.
I am re-doing the Puppet config and trying to come up with a better way of
solving the multiple environment problem. Sometimes files need to be sourced
that depend on their environment. Currently we do "source =>
puppet:///${env}/file", which isn't very nice.
I have created 2 new facter variables that identify whether the host is prod
or DR (based on the network they sit on), whereas before we would set the
zone statically in nodes.pp.
How do you guys solve the multiple environment problem? Is it best to use
templates and have if statements in them?
Thanks in advance.
Gonzalo
--
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] Issues switching over to using environments
Somewhat related to this, is there a way for Puppet to source files in this
manner:
First: /etc/puppet/modules//$environment/
Default: /etc/puppet/modules//
Just to avoid having the same directory structure under
/etc/puppet/$environment/ as Deven has done.
Best regards,
Gonzalo
On Wed, Oct 12, 2011 at 8:26 AM, Deven Phillips wrote:
> Jacob,
>
>That was the problem!! Thanks so much for the help. And Aaron and
> everyone else as well. Much appreciated!!
>
> Deven
>
> On Tue, Oct 11, 2011 at 3:56 PM, Deven Phillips
> wrote:
> > Trying that out now.. I will respond back in a bit with results.
> >
> > Thanks!!!
> >
> > Deven
> >
> > On Tue, Oct 11, 2011 at 3:42 PM, Jacob Helwig
> wrote:
> >> The layout should look something more like this:
> >>
> /etc/puppet/prod/modules/$module_name/files/generic_node/etc/ssh/sshd_config
> >>
> >> With the source lines looking like:
> >> puppet://lou1/modules/$module_name/generic_node/etc/ssh/sshd_config
> >>
> >>
> >> If you wanted 'generic_node' to be the name of the module, then you'd
> >> have the layout as
> >>
> >> /etc/puppet/prod/modules/generic_node/files/etc/ssh/sshd_config
> >>
> >> and the source line as
> >>
> >> puppet://lou1/modules/generic_node/etc/ssh/sshd_config
> >>
> >> --
> >> Jacob Helwig
> >>
> >> On Tue, 11 Oct 2011 15:26:16 -0400, Deven Phillips wrote:
> >>> Date: Tue, 11 Oct 2011 15:26:16 -0400
> >>> From: Deven Phillips
> >>> To: puppet-users@googlegroups.com
> >>> Subject: Re: [Puppet Users] Issues switching over to using environments
> >>> Message-ID: <
> cajw+4nd2kwpgc5-mre1k23of_ym9equbaa+09xmukzkou-o...@mail.gmail.com>
> >>>
> >>> The manifest which calls this looks like:
> >>>
> >>> file {"/etc/ssh/sshd_config":
> >>> owner => "root",
> >>> group => "root",
> >>> mode=> "0644",
> >>> ensure => "present",
> >>> source =>
> >>> "puppet://lou1/modules/files/generic_node/etc/ssh/sshd_config",
> >>> require => Package['openssh'],
> >>> notify => Service['ssh'],
> >>> }
> >>>
> >>> And the current error on the agent node shows:
> >>>
> >>> err: /Stage[main]/Secureshell/File[/etc/ssh/sshd_config]: Could not
> >>> evaluate: Could not retrieve information from environment production
> >>> source(s) puppet://lou1/modules/files/generic_node/etc/ssh/sshd_config
> >>> at /etc/puppet/prod/manifests/classes/ssh.pp:55
> >>>
> >>>
> >>> TIA,
> >>>
> >>> Deven
> >>>
> >>> On Tue, Oct 11, 2011 at 3:23 PM, Deven Phillips
> >>> wrote:
> >>> > Nope, that didn't seem to help the way I tried it... So, here's my
> layout:
> >>> >
> >>> > /etc/puppet/
> >>> > prod/
> >>> > modules/
> >>> > files/
> >>> > generic_node/
> >>> > etc/
> >>> >
> ssh/
> >>> >
> >>> > sshd_config
> >>> >
> >>> > From a machine which is using "production" as it's environment, and
> >>> > production points to "prod/modules" for it's modules; I still get
> >>> > errors trying to get the sshd_config file.
> >>> >
> >>> > TIA!!
> >>> >
> >>> > Deven
> >>> >
> >>
> >
>
> --
> 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.
>
>
--
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] Issues switching over to using environments
Thanks Dan. I thought Puppet may have a way to automagically search for a
file based on environment first (e.g. modules/nfs/$environment/foo), then a
default as specified by source (e.g. modules/nfs/foo). I can see how what
you pasted helps, but it could become tedious having to specify the search
path in various places.
On Wed, Oct 12, 2011 at 12:14 PM, Dan White wrote:
> http://docs.puppetlabs.com/references/stable/type.html#file
>
> under "source"
>
> If you specify multiple file sources for a file, then the first source that
> exists will be used. This allows you to specify what amount to search paths
> for files:
>
> file { "/path/to/my/file":
> source => [
> "/modules/nfs/files/file.$host",
> "/modules/nfs/files/file.$operatingsystem",
> "/modules/nfs/files/file"
> ]
> }
>
> This will use the first found file as the source.
>
> On Oct 11, 2011, at 5:43 PM, Gonzalo Servat wrote:
>
> Somewhat related to this, is there a way for Puppet to source files in this
> manner:
>
> First: /etc/puppet/modules//$environment/
> Default: /etc/puppet/modules//
>
> Just to avoid having the same directory structure under
> /etc/puppet/$environment/ as Deven has done.
>
> Best regards,
> Gonzalo
>
> On Wed, Oct 12, 2011 at 8:26 AM, Deven Phillips
> wrote:
>
>> Jacob,
>>
>>That was the problem!! Thanks so much for the help. And Aaron and
>> everyone else as well. Much appreciated!!
>>
>> Deven
>>
>> On Tue, Oct 11, 2011 at 3:56 PM, Deven Phillips
>> wrote:
>> > Trying that out now.. I will respond back in a bit with results.
>> >
>> > Thanks!!!
>> >
>> > Deven
>> >
>> > On Tue, Oct 11, 2011 at 3:42 PM, Jacob Helwig
>> wrote:
>> >> The layout should look something more like this:
>> >>
>> /etc/puppet/prod/modules/$module_name/files/generic_node/etc/ssh/sshd_config
>> >>
>> >> With the source lines looking like:
>> >> puppet://lou1/modules/$module_name/generic_node/etc/ssh/sshd_config
>> >>
>> >>
>> >> If you wanted 'generic_node' to be the name of the module, then you'd
>> >> have the layout as
>> >>
>> >> /etc/puppet/prod/modules/generic_node/files/etc/ssh/sshd_config
>> >>
>> >> and the source line as
>> >>
>> >> puppet://lou1/modules/generic_node/etc/ssh/sshd_config
>> >>
>> >> --
>> >> Jacob Helwig
>> >>
>> >> On Tue, 11 Oct 2011 15:26:16 -0400, Deven Phillips wrote:
>> >>> Date: Tue, 11 Oct 2011 15:26:16 -0400
>> >>> From: Deven Phillips
>> >>> To: puppet-users@googlegroups.com
>> >>> Subject: Re: [Puppet Users] Issues switching over to using
>> environments
>> >>> Message-ID: <
>> cajw+4nd2kwpgc5-mre1k23of_ym9equbaa+09xmukzkou-o...@mail.gmail.com>
>> >>>
>> >>> The manifest which calls this looks like:
>> >>>
>> >>> file {"/etc/ssh/sshd_config":
>> >>> owner => "root",
>> >>> group => "root",
>> >>> mode=> "0644",
>> >>> ensure => "present",
>> >>> source =>
>> >>> "puppet://lou1/modules/files/generic_node/etc/ssh/sshd_config",
>> >>> require => Package['openssh'],
>> >>> notify => Service['ssh'],
>> >>> }
>> >>>
>> >>> And the current error on the agent node shows:
>> >>>
>> >>> err: /Stage[main]/Secureshell/File[/etc/ssh/sshd_config]: Could not
>> >>> evaluate: Could not retrieve information from environment production
>> >>> source(s) puppet://lou1/modules/files/generic_node/etc/ssh/sshd_config
>> >>> at /etc/puppet/prod/manifests/classes/ssh.pp:55
>> >>>
>> >>>
>> >>> TIA,
>> >>>
>> >>> Deven
>> >>>
>> >>> On Tue, Oct 11, 2011 at 3:23 PM, Deven Phillips
>> >>> wrote:
>> >>> > Nope, that didn't seem to help the way I tried it... So, here's my
>> layout:
>> >>> >
>> >>> > /etc/puppet/
>> >>> >
Re: [Puppet Users] Different paths based on environment
On Wed, Oct 12, 2011 at 7:02 PM, Daniel Maher wrote:
> On 10/11/2011 11:14 PM, Gonzalo Servat wrote:
>
> I am re-doing the Puppet config and trying to come up with a better way
>> of solving the multiple environment problem. Sometimes files need to be
>> sourced that depend on their environment. Currently we do "source =>
>> puppet:///${env}/file", which isn't very nice.
>>
>
> Just out of curiousity, what is it that you don't like about your current
> solution ?
>
Mainly the fact that it won't fallback to a default if it can't find
${env}/file. I just learnt yesterday that you can specify multiple sources
and Puppet will simply pick the first one found, so that's good news.
- Gonzalo
--
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] Different paths based on environment
On Thu, Oct 13, 2011 at 2:25 AM, Nigel Kersten wrote: > > Are you saying you're sourcing files from outside the current environment > for the client? > > if you put your files into modules that differ per environment, then > something like: > > puppet:///modules/mymodule/myfile > > will resolve to $modulepath/mymodule/files/myfile separately for each > environment automatically. > Ah, so then I would need to specify a different modulepath per environment, right? - Gonzalo -- 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] LSB facts
Hi All, In the example42 modules, I noticed the following is done: # Calculate OS version (without using lsb facts) $ossplit=split($operatingsystemrelease, '[.]') $osver=$ossplit[0] I've been using $lsbmajdistrelease in all my configs. Is there any particular reason why I might want to use the above instead? (apart from the dependency on redhat-lsb, which is always installed) Regards, Gonzalo -- 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] if not contains in template
I'm not a Ruby expert, but shouldn't it be
<% if scope.lookupvar("::fqdn") !~ /string/ %>
?
- Gonzalo
On Thu, Nov 10, 2011 at 9:35 AM, Denmat wrote:
> Hi,
>
> that would be '!=' and not '!=~' wouldn't it?
>
> Den
>
> On 10/11/2011, at 9:02, "david.gar...@gmail.com"
> wrote:
>
> I can't seem to find the erb logic for this?
>
> This works:
> <% if scope.lookupvar("::product_info") =~ /string/ %>
> hostgroups sting ; hostgroups.cfg
> <% end %>
>
> While this doesn't:
> <% if scope.lookupvar("::fqdn") !=~ /string/ %>
> define service{
> use remote-service ; Name of service
> template to use
> host_name <%= scope.lookupvar('::fqdn') %>
> service_description NRPE CHECK SERVICE
> check_command check_nrpe!check_service
> }
> <% end %>
>
>
> David Garvey
>
> --
> 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.
>
> --
> 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.
>
--
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] Adding a parameter to a custom Puppet type/provider
Hi All, I've downloaded a Puppet module and I'm trying to add a parameter to it by editing lib/puppet/type/.rb. I simply added: newproperty(:pcfree) do desc "My description here" end In the corresponding file in lib/puppet/provider, I do something with :pcfree. Whenever I call the resource from Puppet with my new parameter, it keeps saying "Invalid parameter pcfree". Do I have to define the new parameter in any other file? Thanks in advance. - Gonzalo -- 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: Adding a parameter to a custom Puppet type/provider
... and I just found this ( http://docs.puppetlabs.com/guides/troubleshooting.html): err: Could not retrieve catalog: Invalid parameter ‘foo’ for type ‘bar’ When you are developing new custom types, you should restart both the puppetmasterd and the puppetd before running the configuration using the new custom type. The pluginsync feature will then synchronise the files and the new code will be loaded when both daemons are restarted. Restarted puppetmaster and it's now OK. Caused me many hours of grief!! - Gonzalo On Tue, Nov 15, 2011 at 4:48 PM, Gonzalo Servat wrote: > Hi All, > > I've downloaded a Puppet module and I'm trying to add a parameter to it by > editing lib/puppet/type/.rb. I simply added: > > newproperty(:pcfree) do > desc "My description here" > end > > In the corresponding file in lib/puppet/provider, I do something with > :pcfree. > > Whenever I call the resource from Puppet with my new parameter, it keeps > saying "Invalid parameter pcfree". > > Do I have to define the new parameter in any other file? > > Thanks in advance. > > - Gonzalo > -- 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] Variables inside node definition
Hi All,
How would I go about achieving the following?
node basenode {
include motd
}
node www inherits basenode {
$purpose = "web server"
}
In the "motd" module, I have a template that formats a standard /etc/motd
file and I want to make use of the $purpose variable. When I access
scope.lookupvar('::purpose'), I get undefined.
Thanks,
Gonzalo
--
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: Variables inside node definition
On Sat, Nov 19, 2011 at 12:58 AM, jcbollinger wrote: > [..snip..] > > You have a great use case here for external data: instead of using a > node variable to communicate the machine's purpose, you could instead > have class motd look it up via extlookup() or hiera. > Thanks for replying John. I hadn't looked into extlookup() until you mentioned this. It's just what I need! I also have a custom facter variable that defines which data centre the server is in, which fits in nicely with extlookup() to look into a dc-specific CSV file. I'm not using ENC as I do call a few defines from node definitions, and I don't think there is a way of calling defines from a YAML node definition? Thanks again for the pointer! - Gonzalo -- 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: Is it possible to get a list of all nodes in your manifests and all classes assigned to those nodes programatically in Ruby?
I rely on Puppet dashboard to tell me which nodes haven't checked in for a while... :) - Gonzalo On Tue, Nov 22, 2011 at 11:43 AM, Trevor Vaughan wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Thanks for the suggestions guys but I'm giving this one up as too annoying > to bother. > > The issue was to detect the nodes that hadn't checked in but were defined > in the manifest. > > Getting the information out of the YAML is pretty easy, yes. > > Thanks! > > Trevor > > On 11/21/2011 12:10 PM, Brian Gallew wrote: > > This is (almost) trivial. > > First, create a fact that turns /var/lib/puppet/state/classes.txt into > an array. Then extract that fact from the storedconfigs DB > programmatically. Admittedly, this won't get all defined nodes, as that is > somewhat meaningless since nodes can be "default" or regular exceptions. > Instead, this gets all nodes that have run Puppet at least once. > > > > On Nov 20, 2011, at 6:04 PM, James Turnbull wrote: > > > >> Trevor Vaughan wrote: > >>> Sorry but...bump? > >>> > >>> On 11/18/2011 02:20 PM, Trevor Vaughan wrote: > Sorry if this is a double post, my e-mail glitched on me. > >>> > Anyway, I'm trying to write a Ruby script that can get all defined > nodes and all classes assigned to those nodes. I would prefer to not > have to compile a catalog for each node. > >>> > I tried looking through the puppet/util/rdoc material but it really > didn't handle the node entries as far as I could tell and also didn't > seem to have a way to get the info without printing it all out. > >>> > >> > >> Sorry missed this one - I do something vaguely similar for the Puppet > >> Rundeck integration - have a look at the code at: > >> > >> https://github.com/jamtur01/puppet-rundeck > >> > >> Others may be able to chime in with better ideas. > >> > >> James > >> > >> -- > >> James Turnbull > >> Puppet Labs > >> 1-503-734-8571 > >> To schedule a meeting with me: http://tungle.me/jamtur01 > >> > >> -- > >> 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. > >> > > > > - -- > Trevor Vaughan > Vice President, Onyx Point, Inc. > email: tvaug...@onyxpoint.com > phone: 410-541-ONYX (6699) > pgp: 0x6C701E94 > > - -- This account not approved for unencrypted sensitive information -- > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > > iQEcBAEBAgAGBQJOyvARAAoJECNCGV1OLcypxvYH/03J2v+V+ReyewLkA5wynTq+ > J9NbiXjwqKK7RZOlB+LFrIbR8/OBP46zRLSI0iujfwua3vwQromA9wga59e9XvuL > vFsKiKmwxArzcrafuTNnIk47jyV6vvYvxq7roIqcU0kQIj9rECEJSkktNI/gy8PK > DMiIMqNSz6jGw+ZUAhWJMQtvzLZ73BiFl61WKFH0NEAM1uBIidp4hfPQ9Bn2OVPJ > TLfGlN2/nuFVUFU6SgDICFsaXKuM6Cc4CnUH1o+UJH6SKXXZBtnuXZDncmwsA4ez > BG+fP3rfS4q3EzZYrl05zFh4frsLyo5PQDYKTZyALPDY9QmZvkHQ62IloFLYcdY= > =8sEZ > -END PGP SIGNATURE- > > -- > 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. > > -- 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] Dynamic configuration file
Hi All,
We use a package called "Torque Scheduler" which is based on a
configuration file that defines nodes, the queues they handle, how many
slots, etc. The config file format is similar to:
unlimited ...
node: : ...
node: : ...
...
node: : ...
(a node may or may not be listed as "unlimited")
We would normally store this file as-is in Puppet and push it out using
file {}, but I'd like to "Puppetize" it. Ideally, I'd like to be able to do
the following:
node { "node1":
unlimited => true,
load => XX,
slots => XX,
queues => {
"queue1" => 80,
"queue2" => 20,
"queueN" => XX
}
}
So basically to build the config file, I'd have to process all the nodes
and where unlimited is true, add to the "unlimited" line.
I know what I want the config file to look like, but I'm not sure how to
achieve this in Puppet. Does this sound like a job for a custom Puppet
provider? I can't figure out how I would build the "unlimited" line over
time.
Can anyone suggest a module that does something similar to this so I can
get some ideas flowing?
Thanks in advance.
Gonzalo
--
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] Puppet for Oracle Enterprise Linux
Try the EPEL repo -- http://fedoraproject.org/wiki/EPEL. - Gonzalo On Fri, Dec 2, 2011 at 11:07 AM, Douglas Garstang wrote: > On Thu, Dec 1, 2011 at 4:03 PM, Michael Stahnke > wrote: > > Puppet works fine on OEL. You can add yum.puppetlabs.com as a repo > > and use the el based stuff. > > > > rpm -Uvh > http://yum.puppetlabs.com/el/5/products/i386/puppetlabs-release-5-1.noarch.rpm > > > > That should get you going. > > > > > > Mike > > Mike, > > Almost see below. As I said, there are NO other repo's installed. > I guess puppet doesn't provide ruby-augeas... > > > $ yum install puppet > Loaded plugins: security > Setting up Install Process > Resolving Dependencies > --> Running transaction check > ---> Package puppet.i386 0:2.7.1-1 set to be updated > --> Processing Dependency: facter >= 1.5 for package: puppet > --> Processing Dependency: ruby-augeas for package: puppet > ---> Package puppet.x86_64 0:2.7.1-1 set to be updated > --> Processing Dependency: ruby-augeas for package: puppet > --> Running transaction check > ---> Package facter.i386 0:1.6.0-1 set to be updated > ---> Package puppet.i386 0:2.7.1-1 set to be updated > --> Processing Dependency: ruby-augeas for package: puppet > ---> Package puppet.x86_64 0:2.7.1-1 set to be updated > --> Processing Dependency: ruby-augeas for package: puppet > --> Finished Dependency Resolution > puppet-2.7.1-1.i386 from puppetlabs-products has depsolving problems > --> Missing Dependency: ruby-augeas is needed by package > puppet-2.7.1-1.i386 (puppetlabs-products) > > Doug. > > -- > 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. > > -- 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] Class name clashes
Hi All, I have a module called "openvpn" which lives in /etc/puppet/modules/openvpn/. It just sets up generic OpenVPN stuff. I then set-up another class called s_jumpbox::openvpn, which lives in /etc/puppet/services/s_jumpbox/manifests/openvpn.pp. Inside this latter class, I did an "include openvpn" and for several resources, I set it to: require => Class["openvpn"] This confused Puppet, as it created a dependency on itself thinking I was referring to s_jumpbox::openvpn, which is not the case. Is this how it's supposed to work? Regards Gonzalo -- 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] Class name clashes
On Fri, Dec 9, 2011 at 6:50 AM, Adam Gibbins wrote: > On 7 December 2011 23:09, Gonzalo Servat wrote: >> >> Is this how it's supposed to work? >> >> Pretty sure I've done this before and haven't had it do that. > Could you try specifying the namespace? e.g. ::openvpn > As in Class["::openvpn"] ? Tried this but Puppet didn't like it. Everything started working as soon as I renamed the second OpenVPN class to s_jumpbox::ovpn, but I don't understand why they clash! > What puppet version are you running? > 2.7.6 - Gonzalo -- 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] Making a system user member of a Puppet managed group
Hi All, I have a particular requirement where a Puppet managed group needs to have several members that are either local and not managed by Puppet (e.g. mysql) or they reside in LDAP. Apart from running an exec call to "groupmems", is there another way to achieve this? Thanks in advance. Gonzalo -- 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: Making a system user member of a Puppet managed group
On Thu, Jan 5, 2012 at 1:00 AM, jcbollinger wrote: > > It depends on the Group provider, which usually depends on operating > system. If you are using the default Group provider for AIX, OS X, or > Windows, then group membership is managed as an attribute of the group > instead of the user. In those cases you can manage the group in > question and use its 'members' property to achieve your end. > My group provider is "groupadd" I believe (default for most platforms), as they are all RHEL boxes. > Otherwise, group membership is managed as a property of Users, ergo > you cannot manage it (directly) if you do not manage the users in > question. Your only options in that case are an Exec or a custom > Group provider. > Ah, ok. That confirms it then. I managed to create a define to do what I want and it seems to work. Happy to share it if anyone is interested in it. Thanks for your reply! - Gonzalo -- 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: Making a system user member of a Puppet managed group
On Thu, Jan 5, 2012 at 10:50 AM, Andreas N wrote:
> On Wednesday, January 4, 2012 3:06:27 PM UTC+1, Gonzalo wrote:
>>
>>
>> Otherwise, group membership is managed as a property of Users, ergo
>>> you cannot manage it (directly) if you do not manage the users in
>>> question. Your only options in that case are an Exec or a custom
>>> Group provider.
>>>
>>
>> Ah, ok. That confirms it then. I managed to create a define to do what I
>> want and it seems to work. Happy to share it if anyone is interested in it.
>>
>
> I'd be very interested in your solution, as I am in a similar situation.
>
Sure. Just a quick disclaimer, there may be better ways of doing this!! But
it works for me:
define groups::addlocalmembers (
$group,
$ensure='present'
) {
case $ensure {
'present': {
exec { "add_${name}_to_${group}":
command => "groupmems -g $group -a $name",
onlyif => [ "id $name" ],
unless => [ "groups $name | grep ' $group\\( \\|\$\\)'" ],
require => Group["$group"],
}
}
'absent': {
exec { "remove_${name}_to_${group}":
command => "groupmems -g $group -d $name",
onlyif => [ "groups $name | grep ' $group\\( \\|\$\\)'" ],
require => Group["$group"],
}
}
default: {
fail("Unknown ensure value: $ensure")
}
}
}
... so essentially I would call it like so:
groups::addlocalmembers { ["mysql", "user1", "user2"]: group =>
"local_group_here" }
Hope this helps.
- Gonzalo
--
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] puppet cert list --all shows revoked certificates even though they're not?
Hi All, As per the subject, "puppet cert list --all" is showing a heap of revoked certificates, even though they're not actually revoked. I can go on any of the revoked clients' host and trigger a Puppet run, and it'll work fine. The only reason why they appear revoked is because the systems were re-installed, so I've issued a puppetca --clean and signed the new certificate, and it immediately appears as revoked (even though it's not). Any ideas? Thanks Gonzalo -- 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] puppet cert list --all shows revoked certificates even though they're not?
Thanks for your reply. I was expecting to see something like: + host(good fingerprint here) - host(revoked fingerprint here) (certificate revoked) ... but instead I just see the second line. I guess I just find it a bit confusing. - Gonzalo On Tue, Jan 10, 2012 at 12:18 PM, Jo Rhett wrote: > The previous certificate was revoked, and the new one was signed. So what > you are seeing is true… > > On Jan 9, 2012, at 5:11 PM, Gonzalo Servat wrote: > > As per the subject, "puppet cert list --all" is showing a heap of revoked > certificates, even though they're not actually revoked. I can go on any of > the revoked clients' host and trigger a Puppet run, and it'll work fine. > > The only reason why they appear revoked is because the systems were > re-installed, so I've issued a puppetca --clean and signed the new > certificate, and it immediately appears as revoked (even though it's not). > > Any ideas? > > Thanks > Gonzalo > > -- > 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. > > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > -- > 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. > -- 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] puppet cert list --all shows revoked certificates even though they're not?
Done :) https://projects.puppetlabs.com/issues/11854 On Tue, Jan 10, 2012 at 1:14 PM, Jo Rhett wrote: > I agree. I would open a bug report :) > > On Jan 9, 2012, at 5:26 PM, Gonzalo Servat wrote: > > Thanks for your reply. > > I was expecting to see something like: > > + host(good fingerprint here) > - host(revoked fingerprint here) (certificate revoked) > > ... but instead I just see the second line. I guess I just find it a bit > confusing. > > - Gonzalo > > On Tue, Jan 10, 2012 at 12:18 PM, Jo Rhett wrote: > >> The previous certificate was revoked, and the new one was signed. So >> what you are seeing is true… >> >> On Jan 9, 2012, at 5:11 PM, Gonzalo Servat wrote: >> >> As per the subject, "puppet cert list --all" is showing a heap of revoked >> certificates, even though they're not actually revoked. I can go on any of >> the revoked clients' host and trigger a Puppet run, and it'll work fine. >> >> The only reason why they appear revoked is because the systems were >> re-installed, so I've issued a puppetca --clean and signed the new >> certificate, and it immediately appears as revoked (even though it's not). >> >> Any ideas? >> >> Thanks >> Gonzalo >> >> -- >> 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. >> >> >> -- >> Jo Rhett >> Net Consonance : consonant endings by net philanthropy, open source and >> other randomness >> >> >> -- >> 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. >> > > > -- > 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. > > > -- > Jo Rhett > Net Consonance : consonant endings by net philanthropy, open source and > other randomness > > -- > 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. > -- 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] puppet cert list --all shows revoked certificates even though they're not?
Thanks for your reply, Nan. I had a look at the ca_crl.pem and the "puppet cert -p " output, and the serial number for the host is not listed in the revoked certificates list in ca_crl.pem, yet puppet cert -la shows the certificate as revoked for the host? - Gonzalo On Tue, Jan 10, 2012 at 3:17 PM, Nan Liu wrote: > I couldn't really reproduce it. I would check your CRL revocation and > match it with your certificate serial number in puppet cert -p > . > > openssl crl -in /etc/puppetlabs/puppet/ssl/ca/ca_crl.pem -noout -text > Certificate Revocation List (CRL): > ... > Revoked Certificates: >Serial Number: 0A > ... >Serial Number: 0C > ... > > puppet cert -p demo.puppetlabs.lan > ... >Serial Number: 13 (0xd) > > If these number match, it's revoked. And if your puppet master is > still accepting agents with revoked certs, it might be a CRL > misconfiguration. It's easy to tell if you resigned a cert by looking > at inventory.txt (because the same CN will show up twice): > > cat /etc/puppetlabs/puppet/ssl/ca/inventory.txt > ... > 0x000c 2011-12-13T21:58:43GMT 2016-12-12T21:58:43GMT > /CN=demo.puppetlabs.lan > 0x000d 2011-12-13T21:58:55GMT 2016-12-12T21:58:55GMT > /CN=demo.puppetlabs.lan > > With all the info above, you should be able to tell 0xc is revoked, > the server currently have 0xd which is still valid and puppet cert -la > should show + demo.puppetlabs.lan. > > Thanks, > > Nan > > On Mon, Jan 9, 2012 at 6:54 PM, Gonzalo Servat wrote: > > Done :) > > > >https://projects.puppetlabs.com/issues/11854 > > > > > > On Tue, Jan 10, 2012 at 1:14 PM, Jo Rhett > wrote: > >> > >> I agree. I would open a bug report :) > >> > >> On Jan 9, 2012, at 5:26 PM, Gonzalo Servat wrote: > >> > >> Thanks for your reply. > >> > >> I was expecting to see something like: > >> > >> + host(good fingerprint here) > >> - host(revoked fingerprint here) (certificate revoked) > >> > >> ... but instead I just see the second line. I guess I just find it a bit > >> confusing. > >> > >> - Gonzalo > >> > >> On Tue, Jan 10, 2012 at 12:18 PM, Jo Rhett > >> wrote: > >>> > >>> The previous certificate was revoked, and the new one was signed. So > >>> what you are seeing is true… > >>> > >>> On Jan 9, 2012, at 5:11 PM, Gonzalo Servat wrote: > >>> > >>> As per the subject, "puppet cert list --all" is showing a heap of > revoked > >>> certificates, even though they're not actually revoked. I can go on > any of > >>> the revoked clients' host and trigger a Puppet run, and it'll work > fine. > >>> > >>> The only reason why they appear revoked is because the systems were > >>> re-installed, so I've issued a puppetca --clean and signed the > new > >>> certificate, and it immediately appears as revoked (even though it's > not). > >>> > >>> Any ideas? > >>> > >>> Thanks > >>> Gonzalo > >>> > >>> -- > >>> 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. > >>> > >>> > >>> -- > >>> Jo Rhett > >>> Net Consonance : consonant endings by net philanthropy, open source and > >>> other randomness > >>> > >>> > >>> -- > >>> 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. > >> > >> > >> > >> -- > >> 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. >
[Puppet Users] puppetd hanging on some nodes
Hi All, In my set-up, I've got a cron job that triggers a Puppet run every 20 minutes. I've found that on approximately 13 nodes (out of 166), puppetd just hangs. I have to go in, kill the process, remove /var/lib/puppet/state/puppetdlock, and run puppet again and then it's fine. After a while, it just hangs again so I have to go in, kill the process, etc. Any ideas? Thanks! Gonzalo -- 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] puppetd hanging on some nodes
On Wed, Feb 8, 2012 at 3:25 PM, Brian Gallew wrote: > If you are like me, the problem is that the ruby for your platform sucks. > The webstack ruby 1.8.7 for Solaris 10 has a nasty tendency to hang (for > the daemons) and core dump for individual runs. Individual runs out of a > crontab are the most reliable way I've found to make it all work. This is ruby-1.8.7.299-7.el6_1.1 and I am running Puppet out of crontab, but it's still frequently hanging. Right about now it has hanged again on several nodes. Any ideas? - Gonzalo -- 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] puppetd hanging on some nodes
On Thu, Feb 9, 2012 at 5:44 AM, Daniel Pittman
wrote:
> RedHat released some update kernels that reintroduced a bug from the
> 2.6.13 Linux kernel. You can run any of the code in this gist to
> check if your kernel suffers that: https://gist.github.com/441278
>
> The C code is obviously a pretty good choice, as it excludes Ruby
> entirely from the problem space, and will confirm if that is your root
> cause.
>
> (The bug is that select on a file in /proc hangs for a long time,
> possibly forever, and Ruby will use select on a file if there are
> enough handles open. This happens in some daemon configurations.)
Hi Daniel,
I tried the C code (with vda, instead of sda, as this is a VM using virtio)
and the result matched the "good" section of that url you pasted.
On stracing a hung puppetd run, I see infinite number of these:
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
gettimeofday({1328740663, 962461}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
The process looks like this:
/usr/bin/ruby /usr/sbin/puppetd --pluginsync --ignorecache
--no-usecacheonfailure --onetime --no-daemonize --logdest syslog
--environment=production --server=puppet-server --report
Any other ideas?
- Gonzalo
--
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] puppetd hanging on some nodes
>
> Damn. Well, at least we eliminated one possible cause. Is there any
> chance you can run with `--debug` enabled on one of the failed
> machines, and see if that points to the right place? Otherwise we
> have to start to get into some fairly heavy ways to figure out what is
> going on.
>
OK I'm now running it with --debug into separate log files, to compare a
working and non-working runs. Unfortunately the hung Puppet doesn't seem to
reveal anything interesting in the logs. A working puppet run looks like
this:
[..stuff..]
debug: Finishing transaction 70131030874760
debug: Loaded state in 0.01 seconds
info: Retrieving plugin
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml;
using pson
debug: Using cached certificate for ca
debug: Using cached certificate for mtsldrp118.sirca.org.au
debug: Using cached certificate_revocation_list for ca
debug: Finishing transaction 70131030519320
info: Loading facts in /var/lib/puppet/lib/facter/server_class.rb
[...more custom facts loading...]
debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw yaml;
using pson
debug: Puppet::Type::Package::ProviderRpm: Executing '/bin/rpm --version'
debug: Puppet::Type::Package::ProviderAptrpm: Executing '/bin/rpm -ql rpm'
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm --version'
[..etc..]
A broken Puppet run shows:
[..stuff..]
debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/clientbucket]: Autorequiring
File[/var/lib/puppet]
debug: /File[/var/lib/puppet/client_data]: Autorequiring
File[/var/lib/puppet]
debug: Finishing transaction 69910666048880
debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/private]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring
File[/var/lib/puppet/ssl]
debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring
File[/var/lib/puppet/ssl/certs]
debug: Finishing transaction 69910666553940
debug: Using cached certificate for ca
debug: Using cached certificate for puppetclient.mydomain
debug: Finishing transaction 69910665891720
debug: Loaded state in 0.01 seconds
info: Retrieving plugin
debug: file_metadata supports formats: b64_zlib_yaml marshal pson raw yaml;
using pson
debug: Using cached certificate for ca
debug: Using cached certificate for puppetclient.mydomain
debug: Using cached certificate_revocation_list for ca
debug: Finishing transaction 69910665535980
That's it. Nothing else in the output. Strace on the puppetd process shows
repetitions of what I pasted in an earlier email:
select(0, NULL, NULL, NULL, {1, 0}) = 0 (Timeout)
gettimeofday({1328767567, 900875}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
gettimeofday({1328767567, 901663}, NULL) = 0
Would appreciate any suggestions you have on this.
Regards
Gonzalo
--
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] puppetd hanging on some nodes
On Thu, Feb 9, 2012 at 5:08 PM, Gonzalo Servat wrote: > Damn. Well, at least we eliminated one possible cause. Is there any >> chance you can run with `--debug` enabled on one of the failed >> machines, and see if that points to the right place? Otherwise we >> have to start to get into some fairly heavy ways to figure out what is >> going on. >> > > OK I'm now running it with --debug into separate log files, to compare a > working and non-working runs. Unfortunately the hung Puppet doesn't seem to > reveal anything interesting in the logs. A working puppet run looks like > this: > [..snip..] Hi Daniel, I'm having an increasing number of nodes now with puppet hangs. I now have 26 nodes where puppetd just hangs. Any ideas on what I can try? I've tried removing any Puppet configuration for the hanging nodes, but it doesn't help so it looks like a client side problem and not the catalog that gets applied to them. Kernel on hanging nodes: 2.6.32-131.17.1.el6.x86_64. It would be nice if all the nodes running the above kernel had this problem, but unfortunately there are other nodes using the above kernel that are not hanging. Thanks in advance. Gonzalo -- 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 displaying multiple IP addresses?
On Mon, Feb 13, 2012 at 2:01 PM, Will S. G. wrote:
>
> Is there a way to display eth{0-5} as well?
>
You could do a for loop from 0 to N (5?) and check if the variable exists (if
has_variable?("ipaddress_eth" + index)) then print it. I'm sure there's
probably a nicer way of doing this in Ruby :)
- Gonzalo
--
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] puppetd hanging on some nodes
On Wed, Feb 15, 2012 at 11:02 AM, Daniel Pittman wrote: > Sorry for not getting back to this sooner. If you are running 2.7.10, > can you try removing the file > `puppet/util/instrumentation/listeners/process_name.rb` and see if > that fixes the problem? > No worries Daniel. Yes. It did fix the problem and I did actually raise a bug on this (to avoid doubling up work): http://projects.puppetlabs.com/issues/12588 - Gonzalo -- 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] Managing /etc/yum.conf
Hi,
It's easy enough to modify, say, the "exclude" variable in /etc/yum.conf
with something like:
augeas { yum_exclude_kernel:
context => '/files/etc/yum.conf/main',
changes => 'set exclude kernel*'
}
However, I'd like a more flexible system where I can "build" the list of
excludes from various classes. Has anyone come up with a good solution to
this type of problem?
Thanks in advance.
Gonzalo
--
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] Managing /etc/yum.conf
On Fri, Feb 17, 2012 at 5:26 PM, Gary Larizza wrote:
> Hey Gonzalo,
>
> Have you tried Hiera at all? (http://github.com/puppetlabs/hiera and
> http://github.com/puppetlabs/hiera-puppet ) With Hiera (and,
> specifically the hiera_array() function), you can scour through a hierarchy
> to populate a variable inside your Puppet manifest. If you had a variable
> to set excludes in many levels of your hierarchy, then
> hiera_array('yum_excludes') would search every level of the hierarchy
> (pertinent to your node according to its Facter facts) for a variable
> called 'yum_excludes', and return an array with all values that it finds.
> You could then utilize a template to populate the "exclude=" line in
> yum.conf.
>
Ah, yes. I've heard of Hiera but didn't really have a use case for it. I'll
definitely check it out.
Thanks Gary!
- Gonzalo
--
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] Managing /etc/yum.conf
On Fri, Feb 17, 2012 at 5:26 PM, Gary Larizza wrote:
> Hey Gonzalo,
>
> Have you tried Hiera at all? (http://github.com/puppetlabs/hiera and
> http://github.com/puppetlabs/hiera-puppet ) With Hiera (and,
> specifically the hiera_array() function), you can scour through a hierarchy
> to populate a variable inside your Puppet manifest. If you had a variable
> to set excludes in many levels of your hierarchy, then
> hiera_array('yum_excludes') would search every level of the hierarchy
> (pertinent to your node according to its Facter facts) for a variable
> called 'yum_excludes', and return an array with all values that it finds.
> You could then utilize a template to populate the "exclude=" line in
> yum.conf.
>
Hiera looks good, however in my case where I may want to build an array of
yum_excludes from various classes, I'm not sure it suits this problem case.
I can see Hiera being useful in cases where you might have different
distributions, networks, etc. but building up an array from any number of
classes, how would it work? Were you thinking that I could add the class
name to the hiera hierarchy and set yum_excludes in there?
- Gonzalo
--
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] Best way to test changes?
On Thu, Feb 23, 2012 at 11:09 PM, jimbob palmer wrote: > I'm worried about making bad changes to a module which will impact > lots of hosts. > > How can I avoid this? > > Ideally I'd like every node to run in noop, and then to approve the > changes if they look right. > Hi Jim, We're not currently using this method, but we're planning on using a second Puppet server which will have a copy of the Puppet tree with whatever major changes have been made in development. We run Puppet from cron so every host would continue to point at the master server, but we would connect to specific hosts and try noop against the second Puppet server. I'd like to hear how other people manage this sort of thing. - Gonzalo -- 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] Mounts occasionally not applied on first run
Hi All, Strange problem specifically to do with mounts. When I run Puppet for the first time on a server, occasionally everything will get applied except for mounts, and other times mounts are applied as part of the first run. No errors in /var/log/messages unfortunately. Has anyone else experienced this? Version 2.7.9. Regards Gonzalo -- 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: Mounts occasionally not applied on first run
On Sat, Feb 25, 2012 at 2:06 AM, jcbollinger wrote: > > I have not noticed this behavior, but you're a little vague. Yes, I guess I wasn't sure what I could provide in terms of detail so your questions help! When you say that the Mount resources are not applied, what exactly does > that > mean? Is /etc/fstab not modified? Is fstab modified but the filesystem is > not mounted? /etc/fstab is not modified at all. I rebooted the server and made it rebuild again and this time Puppet ran fine and all the mounts were applied correctly. > Either way, does the mount point exist (and is it a directory) before the > Mount is applied? What shows up in > the client log? Can you provide a simple manifest that exhibits the > behavior you describe (even if only intermitently)? > I have a define that creates the directory and then mounts it. Nothing in the client log indicating an error with the mounts. Unfortunately I don't have a simple manifest that shows this behaviour. I was hoping someone would say "oh yeah, seen that happen" based on my description, as it's not something I can easily show in a manifest. It happens occasionally too making the troubleshooting effort even harder. If I run Puppet again right after the first run, it gets all the mounts done correctly. Most of the time the first run is enough to get the entire catalog applied including mounts. - Gonzalo -- 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] Puppet staging server
Hi All, I tried to implement a second Puppet server as a "staging" server with the idea of being able to run puppet in dry run mode against this staging server. I ran into some SSL trouble. When I point at the staging server, I get various SSL related errors and I assume it's because the ca cert is different. I can get around it by clearing /var/lib/puppet/ssl and regenerating/signing the certificate, but I have to do the same thing when I go back to the production server which is not what I was hoping for. Has anyone done this sort of thing? How'd you get around the SSL issues? I could use the same CA cert on both Puppet servers but I assume that won't work as the hostnames are different? Thanks in advance Gonzalo -- 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 job listings?
On Thu, May 31, 2012 at 7:13 AM, R.I.Pienaar wrote: > > job postings from community members looking for themselves/their employers > with clear direct to employer contact information +1 > > job postings from recruiters -1 > +1 to what R.I.P just said :-) The problem with the weekly digest email is that if it goes out on, say, Monday and someone posts an ad on Tuesday, it'll be almost a week until it goes out to the list, which depending on urgency to fill the role, may not be ideal (for both; the candidate and the company). - Gonzalo -- 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] Dynamic yum.conf 'exclude' line
Hi All,
I have finally switched to using hiera (worthy goal!) and I am looking for
a flexible way to manage the 'exclude' line in /etc/yum.conf.
I want to be able to specify from different classes RPMs to be excluded in
/etc/yum.conf, then build the exclude line from all those classes that set
an exclude.
In my hiera hierarchy, I use %{calling_module}, but I actually modify the
yum.conf exclude line from a "yum" module so of course setting yum_excludes
in various classes and calling hiera_array('yum_excludes') is not going to
work as the %{calling_module} will be "yum".
Any ideas?
Thanks!
Gonzalo
--
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: Dynamic yum.conf 'exclude' line
On Sat, Jan 26, 2013 at 1:38 AM, jcbollinger wrote: > > Puppet's architecture does not lend itself to constructing values > iteratively, and what Hiera brings to the table in that area does not apply > to the scenario you describe. There are a couple of ways you might be able > to work around Puppet's constraints there, but before you go that way I > would suggest that you consider alternative strategies. > > Let's start with why you want to add package exclusions to yum.conf via > multiple modules. I have some ideas of why you might be trying to > implement such a design, but I'd prefer to avoid guessing. > Hi John, Thanks for your reply. To be honest, I think in this particular case it's more about trying to work out how to solve this type of problem, perhaps not necessarily useful with this exclude line issue. One hypothetical example might be constructing a "users=" line for some config file and I want to set users from various modules to construct the line. For this exclude line question, I have a class that many nodes "include" and they all need to exclude one particular RPM to ensure a "yum update" never upgrades it. These same servers "include" another class, which also have a package to be excluded. Do you have any ideas on how to solve this type of problem? - Gonzalo -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Hiera question -- accessing a hash from an erb template
Hi All,
Simple question (hopefully). Say I have this:
common.yaml:
foo:
bar: 10GB
... and in the manifest:
$config = hiera('foo')
file { '/etc/foo.conf':
content => template('module/foo.erb')
}
... and in foo.erb:
file_size: <%= @config['bar'] %>
For some reason, the output in /etc/foo.conf will be '10GB' on its own
line, instead of 'file_size: 10GB'. Almost as if there is a funny character
in there?
Any ideas?
Thanks.
Gonzalo
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Hiera question -- accessing a hash from an erb template
On Wed, Feb 13, 2013 at 1:41 AM, jcbollinger wrote: > > For some reason, the output in /etc/foo.conf will be '10GB' on its own >> line, instead of 'file_size: 10GB'. Almost as if there is a funny character >> in there? >> >> Any ideas? >> > > > Maybe there's a funny character in there. Seriously. > > Especially if you have a mixture of Windows and Unix, you might > accidentally end up with carriage return characters (ASCII 0x0D) in some of > your text files on the Unix side. Different Unix editors, viewers, and > utilities may handle that situation differently. > > Examine both your template and your data file for unexpected characters. > Many Unix text editors have modes in which they will display such > characters to you (and thus allow you to edit them out). To just see > whether there are any, you could try listing the files via 'cat > --show-nonprinting' > Thanks John for replying. Odd stuff but just before this line, I had another <%= ... %> block and replacing %> with -%> on the previous block seems to have done the trick. - Gonzalo -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Augeas lens dependency on valid config file parsing
Hi All, I just ran into a frustrating Augeas problem, which I thought I'd share with you all. We run a cron every morning to fetch the latest RPMs (for the packages we're interested in) from various places such as rpmforge, EPEL, etc. This morning I tried to build a VM and it failed. What happened was that last night, a new version of nagios-nrpe was downloaded so the VM that was built had this latest version. The RPM includes nrpe.cfg which had a new option added to it: allow_bash_command_substitution=0 In the manifest, I have an augeas block to modify the allowed_hosts line in the nrpe.cfg file. Puppet was failing giving a "Save failed" error message, so I went in via augtool to see what's going on. I noticed that it could not parse nrpe.cfg (i.e. ls /files/etc/nagios returned nothing). I had the previous config file saved for NRPE somewhere, so I diff'ed them and noticed the only new option is the option I mentioned above. After removing this new option, augtool could parse the file again and Puppet was happy. After having a quick read of the nrpe.lns file inside augeas-libs, I noticed it actually lists each of the options that it will recognise from the config file, and evidently fails if it finds new options that it doesn't recognise. Anyway, it hit me that there is quite a big dependency between config files and augeas lenses. A change in one config file can affect Augeas which affects Puppet runs. Or is this just a poorly written lens? - Gonzalo -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Augeas lens dependency on valid config file parsing
On Fri, Mar 22, 2013 at 9:11 PM, Dominic Cleal wrote: > Perhaps ideally, lenses could be bundled with the software responsible > for the config file formats themselves so they're more easily kept in > sync. There are a small number of projects that do this (libvirt, > libguestfs, corosync), but it needs a supportive upstream. > Hi Dominic, Thanks for replying. I haven't got my head around the lens syntax just yet but I will have a go at it and see if I can submit a patch. I think your last paragraph is spot on -- the lenses should be bundled with the software responsible for the config file formats. Perhaps augeas should look in /etc/augeas.d/ or something for the lenses and packages can include a lens file that goes in that directory. It makes sense, as a change in a config file has to include a review of the lens before releasing a new package. - Gonzalo -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Augeas lens dependency on valid config file parsing
On Sat, Mar 23, 2013 at 9:47 AM, Gonzalo Servat wrote: > On Fri, Mar 22, 2013 at 9:11 PM, Dominic Cleal wrote: > >> Perhaps ideally, lenses could be bundled with the software responsible >> for the config file formats themselves so they're more easily kept in >> sync. There are a small number of projects that do this (libvirt, >> libguestfs, corosync), but it needs a supportive upstream. >> > > Hi Dominic, > > Thanks for replying. I haven't got my head around the lens syntax just yet > but I will have a go at it and see if I can submit a patch. > > I think your last paragraph is spot on -- the lenses should be bundled > with the software responsible for the config file formats. Perhaps augeas > should look in /etc/augeas.d/ or something for the lenses and packages can > include a lens file that goes in that directory. It makes sense, as a > change in a config file has to include a review of the lens before > releasing a new package. > I had a go at modifying the lens and got it working to accept any option. For anyone that runs into the same problem, I've opened a ticket and submitted a patch: https://fedorahosted.org/augeas/ticket/334 - Gonzalo -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] erb syntaxes
On Mon, Sep 3, 2012 at 1:31 PM, Choon Ming Goh wrote:
> Hi guys,
>
> I'm trying to do the following in my template:
>
> location <%= location %> {
> proxy_pass <%= proxy %>;
> <% if scope.lookupvar('nginx::resource::location::proxy_header') then
> scope.lookupvar('nginx::resource::location::proxy_header').each do
> |header| %>
> proxy_set_header <%= header %>
> <% end %>
>
Not sure if this is it, but try adding another <% end %> as you have an
"if" statement and a "do" block to close.
- Gonzalo
--
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] Staging environment
Hi All, In our environment, we use the $::environment variable extensively to determine if the host should have one set of mounts (e.g. production) or a different set of mounts (e.g. qa). This is just one example, but there are many others where the $::environment variable comes into play. The problem is that I have a number of puppet changes that I want to test before merging into the production tree, so I've created a staging environment however, given the importance of the $::environment variable throughout the manifests, this won't work well. Any suggestions? I'd like to point a number of production nodes at a secondary puppet server using --noop to see what would change, but then I run into SSL issues. Would be great if I could use puppet over cleartext http for this test, but I'm not sure if that's possible. Thanks in advance for any feedback. Gonzalo -- 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] Staging environment
Hi All, Thanks for your feedback. While writing the original email, the subject sounded familiar and that's because I had written about it in the past: https://groups.google.com/d/topic/puppet-users/twLhIwsCRu4/discussion Apologies to those involved in the other thread for not replying, but thank you for your feedback. I ended up doing what Pablo F suggested, which is to run a puppetmasterd instance as a user, that way I use a copy of the /var/lib/puppet directory and the certificates work fine. Glenn, I like the hiera idea (currently I'm using extlookup) but I think I would run into the same problem. In some of my erb templates, settings are set depending on the environment. For example, in my.cnf (for MySQL), we set the innodb buffer pool size to different sizes depending on the environment. How would I set specific settings depending on the environment here? Cheers Gonzalo On Thu, Sep 20, 2012 at 8:04 AM, Glenn Poston wrote: > Use heira. Heira can load a config file based on the environment. > Setting this up is as simple as creating a hiera definition such as... > > (environment).yaml > > ... And then creating the following files: production.yaml and > staging.yaml that contain your environment specific configs. > > Install the puppet-hiera gem, then you can lookup the appropriate command > inside puppet using heira_lookup(param_name). > > For an example, checkout the vagrant-hiera project on github. If your > unfamiliar with vagrant, you'll need to install that to run the example. > It's a great tool for doing local puppet testing. Even if you don't want > to install vagrant, looking at the source of that project will show you a > quick example of how to use hiera. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/YlJx3dHegBsJ. > 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. > > -- 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] Staging environment
On Thu, Sep 20, 2012 at 3:37 PM, Garrett Honeycutt
wrote:
> No need at all to use a different puppet master, you could just use
> environments[1]. When you want to test a system again a different
> environment, staging in this example, you can run `puppet agent -t
> --environment=staging`.
>
Yep, I need to move towards this. I guess this means I need to go through
all my templates and put hiera variables for everything.
> Hiera[2] is meant to solve this. You might have staging.yaml and
> production.yaml that specify values for mysql_innodb_buffer_pool_size.
>
> In your code you could have
>
> $innodb_buffer_pool_size = hiera('mysql_innodb_buffer_pool_size')
>
> and then use <%= innodb_buffer_pool_size %> in a template for your my.cnf.
>
Can one call hiera() from within the ERB templates?
- Gonzalo
--
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] Staging environment
On Thu, Sep 20, 2012 at 3:37 PM, Garrett Honeycutt wrote: > Hiera[2] is meant to solve this. You might have staging.yaml and > production.yaml that specify values for mysql_innodb_buffer_pool_size. > Another scenario I've found is that we also add certain users if $::environment is production, and a different set of users if it's qa, etc. How would you work with that using hiera? One idea that comes to mind is that within hiera I set a special environment variable called $::env or something, which is what I would evaluate instead of $::environment, that way I can have any puppet environment setting $::env to whatever I want. - Gonzalo -- 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] Answer a question after a command has been run in a init.pp in a module.
On Wed, Oct 10, 2012 at 5:26 AM, JGonza1 wrote: > I have the command below in a init.pp file that I run to startup splunk > for the first time but it outputs the license agreement which requires to > input a y or n. Is there a way to input a y after the lincese agreement? > According to http://docs.splunk.com/Documentation/Splunk/latest/Installation/Startsplunkforthefirsttime : To accept the license automatically when you start Splunk for the first time, add the accept-license option to the start command: $SPLUNK_HOME/bin/splunk start --accept-license - Gonzalo -- 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: Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Sun, Oct 14, 2012 at 11:27 AM, Jakov Sosic wrote: > On 10/08/2012 09:21 PM, Jeff McCune wrote: > > I hope this helps and thank you again for reporting this issue, >> > > I think the easiest way of handling this issue is to have different > repositories for different versions of puppet. > I would certainly +1 this method! I was bitten by the puppet 3.x packages for 2 reasons. The first one is that in my kickstart configs, I have "puppet" specified as a package which gets installed during installation and performs some trickery to run Puppet for the first time on the client, and get the certificate signed. As Puppet 3.x was now being installed by yum, it broke our installations. My workaround was to set "puppet-2.7" in the kickstart file, but far from ideal :( I was then bitten by Puppet doing what it's supposed to do :) As I had ensure => latest for the Puppet client, it went around and upgraded a lot of my clients to 3.x, which broke things. I guess I never expected such incompatible packages to be made available in the puppetlabs yum repo, but there's always a first :) It looks like Puppetlabs are well aware of this issue, so I look forward to the resolution. Personally, I think packages should be grouped in a logical manner, so that any package in the group will not (or should not) break functionality if upgraded. - Gonzalo -- 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] Ways to set a global variable
Hi All,
In hiera, I have something like:
interfaces:
nic1:
10G: true
ip: x.x.x.x
netmask: x.x.x.x
nic2:
ip: x.x.x.x
netmask: x.x.x.x
This hiera config is used to build the interface configuration files. Now,
if a server has at least ONE NIC with 10G == true, I want to make a few
more changes to that machine. It can happen from various manifests so
preferably I'd like a global boolean or some way to say "if $10G { ... }".
I could have a root setting called "10G: true" and I can just do:
if hiera('10G', false) {
// do stuff
}
... but I'd like to avoid having to duplicate the 10G setting in the hiera
file.
The logic I had in mind was to go through hiera('interfaces') and, if any
NIC has 10G == true, then set a global "boolean" that I can reference from
any manifest.
I thought I could write a custom fact of some sort that calls hiera(), but
since the fact gets generated on the client and hiera is on the server...
Any ideas?
Thanks in advance.
Gonzalo
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Ways to set a global variable
For anyone interested in how I got around this, I ended up creating a
custom function and placed it inside
modules//lib/puppet/parser/functions. The function essentially uses
hiera to lookup my 'interfaces' key in the YAML and loops through it to
find if 10G has been set for any interfaces. Similar to:
module Puppet::Parser::Functions
newfunction(:is_10G, :type => :rvalue) do |arg|
result = false
Puppet::Parser::Functions.autoloader.loadall
function_hiera(['interfaces']).each { |key, value|
if $value['10G']
result = true
break
end
end
result
end
end
With the above function, I can call is_10G() from anywhere to find out if
any interface is 10G capable. Next step is probably to create facts based
on ethtool to tell me if an interface is 10G capable, as opposed to setting
it statically in hiera.
- Gonzalo
On Fri, Oct 11, 2013 at 9:53 AM, Gonzalo Servat wrote:
> Hi All,
>
> In hiera, I have something like:
>
> interfaces:
> nic1:
> 10G: true
> ip: x.x.x.x
> netmask: x.x.x.x
> nic2:
> ip: x.x.x.x
> netmask: x.x.x.x
>
> This hiera config is used to build the interface configuration files. Now,
> if a server has at least ONE NIC with 10G == true, I want to make a few
> more changes to that machine. It can happen from various manifests so
> preferably I'd like a global boolean or some way to say "if $10G { ... }".
>
> I could have a root setting called "10G: true" and I can just do:
>
> if hiera('10G', false) {
>// do stuff
> }
>
> ... but I'd like to avoid having to duplicate the 10G setting in the hiera
> file.
>
> The logic I had in mind was to go through hiera('interfaces') and, if any
> NIC has 10G == true, then set a global "boolean" that I can reference from
> any manifest.
>
> I thought I could write a custom fact of some sort that calls hiera(), but
> since the fact gets generated on the client and hiera is on the server...
>
> Any ideas?
>
> Thanks in advance.
> Gonzalo
>
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Managing /etc/hosts without using exported resources
Hi All,
I am using Puppet 3.2.4 and I'd like Puppet to manage /etc/hosts for me and
add "neighbouring hosts" only to /etc/hosts. These hosts are determined to
be neighbours based on where they are (city/country).
For example ($::city and $::country are custom facts):
@@host { $::fqdn:
ip => $::ipaddress,
host_aliases => [ $::hostname ],
tag => [ $::city, $::country ],
}
Host <<| tag == $::city and tag == $::country |>>
As I have never used exported resources before, I gave this a try and
realised there is more to them than the above config. It looks like I need
to install PuppetDB to make it work, which looks challenging given that the
puppet master is on SLES 11.
Apart from using exported resources, does anyone have any ideas on how to
achieve this?
One nasty way of doing it was to create a Puppet function that looks at
/var/lib/puppet/yaml/node/*.yaml and matches filenames based on a regex
passed in as an argument, then parses each yaml file and returns
'ipaddress', 'fqdn' and 'hostname' from them to update /etc/hosts, but it's
way too hacky for my liking.
- Gonzalo
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Managing /etc/hosts without using exported resources
Hi Juan,
Thanks for your reply. I was going to look into using stored configs with
MySQL as per your suggestion, until I saw R.I.Pienaar's email :(
Yes, I would certainly use DNS if I could, but unfortunately DNS is not an
option in this setup.
I think I will have to either parse files (eek) or maybe look into that ENC
suggestion.
- Gonzalo
On Mon, Oct 14, 2013 at 10:45 PM, JuanBrein wrote:
> Hi Gonzalo,
>
> First of all you don't need puppetdb to use exported resources. A simple
> mysql database will do it, even sqlite works, not recommended though.
> Specifically what you need is "stored configs" configured in your puppet
> master. The problem with exported resources is that sometimes they can be
> slow... depends obviously on the amount of nodes, resources, etc.
>
> Regarding your question if it can be done in a different way... I would
> definitely use DNS if possible... if not exported resources if very easy to
> implement. The function idea I don't think is "that" bad... I would prefer
> to query a database rather than parsing files.
>
> Another way I can think about is to use a custom ENC to export those
> parameter. The ENC would take the information from some type of database
> that you have to update as well. That would be definitely faster and a more
> elegant solution
>
> Depending on the size of your infrastructure and performance I would go
> for exported resources and if that is too slow I would consider some of the
> other options
>
> Cheers
>
> Juan
>
>
> On Monday, October 14, 2013 7:19:56 AM UTC+1, Gonzalo wrote:
>>
>> Hi All,
>>
>> I am using Puppet 3.2.4 and I'd like Puppet to manage /etc/hosts for me
>> and add "neighbouring hosts" only to /etc/hosts. These hosts are determined
>> to be neighbours based on where they are (city/country).
>>
>> For example ($::city and $::country are custom facts):
>>
>> @@host { $::fqdn:
>>ip => $::ipaddress,
>>host_aliases => [ $::hostname ],
>>tag => [ $::city, $::country ],
>> }
>>
>> Host <<| tag == $::city and tag == $::country |>>
>>
>> As I have never used exported resources before, I gave this a try and
>> realised there is more to them than the above config. It looks like I need
>> to install PuppetDB to make it work, which looks challenging given that the
>> puppet master is on SLES 11.
>>
>> Apart from using exported resources, does anyone have any ideas on how to
>> achieve this?
>>
>> One nasty way of doing it was to create a Puppet function that looks at
>> /var/lib/puppet/yaml/node/*.**yaml and matches filenames based on a
>> regex passed in as an argument, then parses each yaml file and returns
>> 'ipaddress', 'fqdn' and 'hostname' from them to update /etc/hosts, but it's
>> way too hacky for my liking.
>>
>> - Gonzalo
>>
> --
> 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 post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Dashboard running in masterless puppet
Hi All, I'm running Puppet in masterless mode and trying to make Puppet dashboard play nice with it in this non-standard setup. I'd love to hear how other people are doing this. The process I have in mind is: 1) Run "puppet apply" from cron on each node 2) Rsync (using --remove-sent-files) the reports from each node's /var/lib/puppet/reports dir back to the puppet dashboard server 3) Run rake:import The issue I'm having is that rake:import will create a new failed task for every report that already exists in the database. It does skip them, but I don't want to be notified it's a failed task when it skips them. I was thinking of deleting old reports, but given that they get imported by the delayed task workers, it is hard to know which reports have been processed to avoid deleting a report that hasn't been imported yet. If I can find a way to stop it reporting skipped reports as failed tasks, then I should be OK. Any ideas? Anyone else running Puppet dashboard with masterless Puppet? - GS -- 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/CAHpidMBFwOuqiLNNbE_yjSzZeiqYxKH_Xt4UKjkpwh9fM3J4Ow%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] exec only if condition is true
Add "refreshonly => true" to the exec definition.
GS
On 17/01/2014 6:17 pm, "kaustubh chaudhari" wrote:
> Hi All,
>
> I am not a programer or from the same background, trying to explore!
> Please excuse if you find this question silly.
>
> I was to exec a .bat file of if there are any changes to the files. Eg: i
> am trying to activate windows with the valid keys, however this action is
> required only once.
> My current code will execute it with every puppet run. How can i configure
> it to run it only when there are any changes to .bat file, say i wish to
> change the key.
>
>
> ==
> file {'C:/Windows/puppetwinactivaion.bat':
> ensure => 'file',
> source =>
> 'puppet:///modules/win642k8hardning/puppetwinactivaion.bat',
> mode => '0755',
> notify => Exec['puppetwinactivaion.bat'],
> }
> exec {'puppetwinactivaion.bat':
> require => File['C:/Windows/puppetwinactivaion.bat'],
> command => 'C:/Windows/puppetwinactivaion.bat',
> }
> ==
>
> -Kaustubh
>
> --
> 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/6695d390-ff19-4ba3-8016-75f428e51661%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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/CAHpidMBytDPm%2BpbMtBo2xtd9SGuHOwPQPTZcfUHBx653TwVH%3DQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
