Re: [Puppet Users] Why does my puppetmaster work happily with webrick but not passenger?
Hi, On 02/22/2014 08:17 PM, John Florian wrote: > > Any ideas what might be going on? not really, but seeing as you're running passenger, you should really consult your apache error logs, and any applicable puppet logs on the master side. More details will be appreciated. TIA, Felix -- 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/530B19E9.2050706%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hash iteration order in a template not consistent
On Friday, February 21, 2014 10:15:01 AM UTC-3, Andre Nathan wrote: > > On Thursday, February 20, 2014 12:06:15 PM UTC-3, jcbollinger wrote: >> >> File a ticket if you wish, but personally, I'm inclined to say that >> *any*reliance on iteration order of a hash is dodgy. If iteration order >> matters >> then you need to take proactive measures to ensure that you reliably get >> the (an) order that works for you. >> > > Well, it's not a case of order being important. I don't care about the > order, but it should always be the same. Otherwise, when you build a > configuration file from a template, that file gets changed every time > Puppet runs, because the directives are reordered. > I createt ticket PUP-1755 on the tracker. Cheers, Andre -- 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/21e0759a-811f-411b-91f5-aa5766bec9a2%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] notify on agent from puppet function
Hi all, could you advice any way to put a message in puppet agent output from puppet function on master. -- Best regards, Vasil Mikhalenya -- 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/CAPc4iSBhqFcajwj3-J9Xj9h2ibgGhTTo%3D5ZbsY-aYGbGq9jZAw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Arrays and case statements
On Friday, February 21, 2014 3:47:19 PM UTC-6, Kim Scarborough wrote:
>
> So I have a bunch of linux servers in different groups. Each server's
> group is defined as a custom fact. I want to set an array variable based on
> the server's group membership, so I have code like this:
>
> case $servergroup {
> MAMMAL: { $foo = ['horse', 'cow', 'dog'] }
> REPTILE: { $foo = ['gator', 'frog'] }
> BIRD:{ $foo = ['finch', 'chicken'] }
> }
>
> This works fine. The problem is that now I have a server that needs to be
> in two groups. I know I can convert a custom fact into an array like this:
>
> $slist = split($servergroup, ',')
>
> But I don't know how to have each value in the array be processed through
> the case statement. I tried this (using the future parser):
>
> each($slist) |$val| { case $val {
> MAMMAL: { $foo = ['horse', 'cow', 'dog'] }
> REPTILE: { $foo = ['gator', 'frog'] }
> BIRD:{ $foo = ['finch', 'chicken'] }
> }
> }
>
> But I just get an error.
>
> (There's another issue, which is that I'll want the $foo array to append
> to the previous value rather than overwrite, but I'll deal with that after
> getting over this hurdle).
>
> Is what I'm trying possible? Am I going about this totally the wrong way?
>
Your approach will not work. One of the core characteristics of Puppet
variables is that once assigned, their values never change.
I haven't played much with the future parser, but since you're looking that
direction, I think it can do the job for you. Start by replacing your
'case' statement with a hash declaration:
$group_attributes = {
'MAMMAL' => ['horse', 'cow', 'dog'],
'REPTILE' => ['gator', 'frog'],
'BIRD'=> ['finch', 'chicken']
}
The task you want to perform is essentially to transform / map server
groups to attibutes, so the future parser's map() function seems a good
candidate. The only extra trick is that you want to combine the results of
each mapping, but that should be straightforward if none of the elements
'horse', 'cow', etc. are themselves arrays IRL. Something along these
lines ought to do the job:
$foo = flatten(
split($servergroup, ',').map |$group_name| {
$group_attributes[$group_name]
}
)
Note in particular that there is only one assignment to variable $foo.
Note also that it will work equally well for servers belonging to one group
and those belonging to many.
If you are comfortable with using the future parser, then I think that's a
pretty good and effective application, much easier to apply to the merging
problem than hiera would be. There is still a role in this for hiera,
however: it would be better to store the $group_attributes data in an
external file, and getting the data from there into Puppet is Hiera's bread
& butter.
John
--
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/9d0ee56d-22f0-47f3-a08a-4745bc2a494e%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Using same script for multiple services fails
On Friday, February 21, 2014 12:05:46 PM UTC-6, Guy Knights wrote:
>
> I'd like to use the same init script (via upstart) for multiple service
> definitions, and I thought that if I gave them different titles but the
> same name paramter (eg. script name) it should allow that. However, I get a
> duplicated definition error.
>
> eg.
>
> * service { "gamedeploy-backend":*
> *name => 'gamedeploy',*
> *ensure => running,*
> *provider => upstart,*
> *start => "/sbin/initctl start gamedeploy
> GAME=${game_deploy['title']} COMPONENT=backend ENVIRONMENT=${::environment}
> DELAY=${game_deploy['delay']}",*
> *stop => '/sbin/initctl stop gamedeploy COMPONENT=backend',*
> *status => '/sbin/initctl status gamedeploy COMPONENT=backend',*
> *hasrestart => false,*
> *subscribe =>
> [File['gamedeploy_init_script'],File['gamedeploy_script']],*
> *require=> [File['/var/log/deploy'],Account['deployment']],*
> * }*
>
> * service { "gamedeploy-frontend":*
> *name => 'gamedeploy',*
> *ensure => running,*
> *provider => upstart,*
> *start => "/sbin/initctl start gamedeploy
> GAME=${game_deploy['title']} COMPONENT=frontend
> ENVIRONMENT=${::environment} DELAY=${game_deploy['delay']}",*
> *stop => '/sbin/initctl stop gamedeploy COMPONENT=frontend',*
> *status => '/sbin/initctl status gamedeploy COMPONENT=frontend',*
> *hasrestart => false,*
> *subscribe =>
> [File['gamedeploy_init_script'],File['gamedeploy_script']],*
> *require=> [File['/var/log/deploy'],Account['deployment']],*
> * }*
>
> Is there any way I can get this to work in Puppet, or will I have to
> create multiple copies of the same script with different filenames?
>
>
No two resources of the same type can have the same title or name. You
have a several options, among them:
1. Duplicate the initscript
2. Create symlink to the initscript to use as an alias
3. Create separate initscripts as wrappers for the one you are using
now; this could allow you to avoid passing a bunch of parameters to each
initscript action (they being handled instead by the wrappers), which would
have the side effects of making these services easier to manage manually
from the command line, and of not requiring you to express explicit start,
stop, and status commands in your manifest.
4. Just allow the services to have different names. Since you are
specifying explicit start, stop, and status commands and denying the
existence of a restart command, I don't think there's anything left that
Puppet would do with the resource name, other than emit it to the log.
Of those, I like (3) the best, followed by (4).
John
--
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/6ac2cfa5-2e9d-43bf-8fff-307d99bdc8f5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] How do you manage iptables packet length?
Taking this iptables rule as an example: iptables -A INPUT -p icmp -m length --length 3:65535 -j DROP If you manage that sort of thing using puppet, how do you do it? (The snazzy http://forge.puppetlabs.com/puppetlabs/firewall doesn't currently do packet length, as near as I can tell. It does everything else I currently want.) -- 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/20140224145759.GA6869%40iniquitous.heresiarch.ca. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Host is missing hostname and/or domain
On Friday, February 21, 2014 10:50:20 AM UTC-6, JonY wrote: > > I have 36 (seemingly) identical machines deployed from a single manifest. > Puppet does not do deployment, only post-deployment configuration. I raise that here because I think it likely that the problem likely boils down to a deployment issue. > For some reason I'm getting this error in my logs for a subset of them. > > /etc/hosts: > > 127.0.0.1 hostname hostname.fqdn localhost > > Maybe nowhere else. That hosts entry is bogus on at least two grounds: 1. You should not be pointing the host's primary name at a loopback address. If you list it in /etc/hosts at all, it should be pointed at the IP address assigned to the host's primary network interface. 2. The canonical name field of each entry (the second) should hold the fqdn. The unqualifed name, if listed, should be among the aliases (subsequent fields). Example: 192.168.0.42 host.mydomain.com host 127.0.0.1localhost.localdomain localhost Traditionally, the host's own name needed to be first in /etc/hosts, as that was how machines determined their own names. That might still be the case for some UNIX flavors, but I don't think it's common any longer. It doesn't work well for machines with dynamic IPs, so many systems use an alternative means to record a machine's hostname. On RedHat-family Linuxes, at least, that's the 'HOSTNAME' entry in file /etc/sysconfig/network. Machines that employ such a mechanism do not normally require a machine's own hostname to be listed in /etc/hosts at all. It may be illuminating to run the 'dnsdomainname' command on one of the affected machines. If it does not give the correct fully-qualified name for the machine, then the machine is configured wrongly. Such an error is an initial provisioning / deployment problem. You should assign the machine its name before first firing up the Puppet agent on it. John -- 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/cfeb2a0b-b041-414c-bf50-b537a2f9f7b1%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Getting rid of YAML?
On Friday, February 21, 2014 10:19:10 AM UTC-6, JonY wrote: > > > On Friday, February 21, 2014 8:10:23 AM UTC-8, jcbollinger wrote: >> >> >> >> On Thursday, February 20, 2014 4:41:33 PM UTC-6, JonY wrote: >>> >>> Looks like my server updated to 3.4.2. Since then I've started seeing >>> these occasional messages like: >>> >>> Feb 20 14:19:05 puppet-master[5626]: YAML in network requests is >>> deprecated and will be removed in a future version. See >>> http://links.puppetlabs.com/deprecate_yaml_on_network >>> Feb 20 14:19:05 puppet-master[5626]:(at >>> /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:304:in >>> `decode_params') >>> >>> Does this mean I'll be able to start using JSON or XML in my ENC >>> scripts? >>> >>> >> >> The master is complaining about YAML in the inbound request from an >> agent. You should stop seeing the message if you update the relevant >> agents to a sufficiently recent version. >> >> The message is not related to ENC output, but inasmuch as JSON is very >> nearly a subset of YAML, you should be able to have your ENC output JSON >> now, provided that you don't tickle one of the few inconsistencies. Not so >> much XML. >> >> >> John >> >> > > > All of my agents are running 3.4.0. (or so they are told to). Is there > some way to find out where this anomalous request is coming from? A $DEBUG > setting or equivalent? > If the name of the agent being serviced is not already logged in the context of the message (look a few lines before), then you can probably get it to be logged by enabling debug logging in the master (--debug command-line option). John -- 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/575138a0-44f0-4011-9e0f-fc3e0507ad12%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Getting rid of YAML?
On Monday, February 24, 2014 7:21:28 AM UTC-8, jcbollinger wrote: > > > > On Friday, February 21, 2014 10:19:10 AM UTC-6, JonY wrote: >> >> >> On Friday, February 21, 2014 8:10:23 AM UTC-8, jcbollinger wrote: >>> >>> >>> >>> On Thursday, February 20, 2014 4:41:33 PM UTC-6, JonY wrote: Looks like my server updated to 3.4.2. Since then I've started seeing these occasional messages like: Feb 20 14:19:05 puppet-master[5626]: YAML in network requests is deprecated and will be removed in a future version. See http://links.puppetlabs.com/deprecate_yaml_on_network Feb 20 14:19:05 puppet-master[5626]:(at /usr/lib/ruby/site_ruby/1.8/puppet/network/http/handler.rb:304:in `decode_params') Does this mean I'll be able to start using JSON or XML in my ENC scripts? >>> >>> The master is complaining about YAML in the inbound request from an >>> agent. You should stop seeing the message if you update the relevant >>> agents to a sufficiently recent version. >>> >>> The message is not related to ENC output, but inasmuch as JSON is very >>> nearly a subset of YAML, you should be able to have your ENC output JSON >>> now, provided that you don't tickle one of the few inconsistencies. Not so >>> much XML. >>> >>> >>> John >>> >>> >> >> >> All of my agents are running 3.4.0. (or so they are told to). Is there >> some way to find out where this anomalous request is coming from? A $DEBUG >> setting or equivalent? >> > > > If the name of the agent being serviced is not already logged in the > context of the message (look a few lines before), then you can probably get > it to be logged by enabling debug logging in the master (--debug > command-line option). > > > John > > Is this available via Passenger? IE a .conf setting? -- 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/48920fbc-4323-43a9-9211-6099cbec5ba4%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Module and class names confusion
On Friday, February 21, 2014 6:06:53 AM UTC-6, Anton Patiev wrote: > > Hello everyone! > > This may be a stupid question since i'm relatively new in Puppet, but I > haven't found an answer. > > I have external module, named, for example, 'ntp' and my own module > 'profile', which contains class with the same name. When i try to apply my > configuration, puppet says 'Could not find class profile::base::ntp'. What > am i doing wrong? > Puppet will report that error if it it does not initially have a definition of the named class, and it does not successfully autoload it. Your class and file names look right, but Puppet might nevertheless fail to autoload the class if access controls prevent it from reading the file, or perhaps if, having found the definition present and syntactically correct, nevertheless it fails for some reason to evaluate the class. Check the ownership and permissions (and spelling) of modules/profile/manifests/base/ntp.pp and its parent directory (directories further up the path matter, too, but it's already established that Puppet can access those). If all that seems right, then you could try commenting out everything in the body of class profile::base::ntp to see whether that makes the error go away, signaling some kind of problem with evaluating the class. John -- 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/535fe29c-cf6b-43dd-b109-95c771e03ed9%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: handy tip against unhelpful "Could not intern from pson" error
Thank you, this was a great help
On Wednesday, August 24, 2011 5:21:21 PM UTC+1, Luke Bigum wrote:
> Cheers, that'll teach me to cut and paste ;)
>
> The second example's resource name should be without quotes, so:
>
> $service_name = "httpd"
> service { $servicename: ensure => running }
> err: /Stage[main]/Puppet_dashboard::Service/Service[undef]/ensure:
> change from stopped to running failed: Could not start Service[undef]:
> Execution of '/sbin/service undef start' returned 1: at /etc/puppet/
> environments/testing/modules/httpd/manifests/service.pp:26
>
> On Aug 24, 5:12 pm, Henrik Lindberg
> wrote:
> > I can't see any difference between your two examples.
> > Typo?
> > - henrik
> > On 8/24/11 5:23 PM, Luke Bigum wrote:
> >
> >
> >
> >
> >
> >
> >
> > > Not sure if people are already aware of this, but it might save
> > > someone some time in the future. I've been tracking down the following
> > > error today, it's rather unhelpful in telling you where the problem is
> > > in your manifests:
> >
> > > # puppetd --test
> > > info: Retrieving plugin
> > > err: Could not retrieve catalog from remote server: Could not intern
> > > from pson: Could not convert from pson: Could not find relationship
> > > target "Service[]"
> >
> > > The problem is the parser using an empty string as a resource name
> > > which I arrived at by using a variable inside double quotes for a
> > > resource declaration. I did this for style (or have been until now) -
> > > I like to have user defined strings in quotes so it easily
> > > distinguishes between them and puppet keywords, plus for syntax
> > > highlighting, etc. Turns out this personal preference has shot me in
> > > the foot as the difference between the error messages for an empty
> > > string versus an undefined variable is rather big.
> >
> > > See this unhelpful message:
> >
> > > $service_name = "httpd"
> > > service { "$servicename": ensure => running }
> > > err: Could not retrieve catalog from remote server: Could not intern
> > > from pson: Could not convert from pson: Could not find relationship
> > > target "Service[]"
> >
> > > versus this:
> >
> > > $service_name = "httpd"
> > > service { "$servicename": ensure => running }
> > > err: /Stage[main]/Puppet_dashboard::Service/Service[undef]/ensure:
> > > change from stopped to running failed: Could not start Service[undef]:
> > > Execution of '/sbin/service undef start' returned 1: at /etc/puppet/
> > > environments/testing/modules/httpd/manifests/service.pp:26
--
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/4b9c3848-ea40-4709-aee2-73962edeb732%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hash iteration order in a template not consistent
On Friday, February 21, 2014 7:15:01 AM UTC-6, Andre Nathan wrote: > > On Thursday, February 20, 2014 12:06:15 PM UTC-3, jcbollinger wrote: >> >> File a ticket if you wish, but personally, I'm inclined to say that >> *any*reliance on iteration order of a hash is dodgy. If iteration order >> matters >> then you need to take proactive measures to ensure that you reliably get >> the (an) order that works for you. >> > > Well, it's not a case of order being important. I don't care about the > order, but it should always be the same. Otherwise, when you build a > configuration file from a template, that file gets changed every time > Puppet runs, because the directives are reordered. > > I understand that you had an unpleasant surprise here. I also understand the nature of the problem with respect to template implementation. I sympathize, but a change in undocumented behavior is not a bug. For correctness with respect to file changes, it was *always* necessary for your templates to ensure some specific iteration order, even though the particular one chosen doesn't matter to the file consumer. Who knows, though, PL might nevertheless accept your ticket and provide the feature you request. John -- 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/1df7abe3-f471-426f-a108-2034cb3fe0e1%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Host is missing hostname and/or domain
On Monday, February 24, 2014 7:17:28 AM UTC-8, jcbollinger wrote: > > > > On Friday, February 21, 2014 10:50:20 AM UTC-6, JonY wrote: >> >> I have 36 (seemingly) identical machines deployed from a single manifest. >> > > > Puppet does not do deployment, only post-deployment configuration. I > raise that here because I think it likely that the problem likely boils > down to a deployment issue. > > > >> For some reason I'm getting this error in my logs for a subset of them. >> >> /etc/hosts: >> >> 127.0.0.1 hostname hostname.fqdn localhost >> >> > > Maybe nowhere else. That hosts entry is bogus on at least two grounds: > >1. You should not be pointing the host's primary name at a loopback >address. If you list it in /etc/hosts at all, it should be pointed at the >IP address assigned to the host's primary network interface. >2. The canonical name field of each entry (the second) should hold the >fqdn. The unqualifed name, if listed, should be among the aliases >(subsequent fields). > > Example: > > 192.168.0.42 host.mydomain.com host > 127.0.0.1localhost.localdomain localhost > > Traditionally, the host's own name needed to be first in /etc/hosts, as > that was how machines determined their own names. That might still be the > case for some UNIX flavors, but I don't think it's common any longer. It > doesn't work well for machines with dynamic IPs, so many systems use an > alternative means to record a machine's hostname. On RedHat-family > Linuxes, at least, that's the 'HOSTNAME' entry in file > /etc/sysconfig/network. Machines that employ such a mechanism do not > normally require a machine's own hostname to be listed in /etc/hosts at all. > > It may be illuminating to run the 'dnsdomainname' command on one of the > affected machines. If it does not give the correct fully-qualified name > for the machine, then the machine is configured wrongly. Such an error is > an initial provisioning / deployment problem. You should assign the > machine its name before first firing up the Puppet agent on it. > > > John > > I think I found the problem. On the systems that have this error the /etc/resolv.conf file is missing the 'domain ' line. It's getting wiped out / replaced by DHCP at boot time. If I add the appropriate line back in the error goes away. I'll add a template file to puppet to maintain this add see what happens. -- 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/6bd9b67b-bb58-4eb3-9a7c-b9eb0267eed5%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Custom Facter Fact fails produces output second time around.
Hey Everyone, I am running puppet I'm having an issue when I run the puppet agent on my node, it errors out on loading this one customer fact. [root@munin-new puppet]# puppetd -t --noop info: Retrieving plugin info: Loading facts in gateway info: Loading facts in permgen_check info: Loading facts in ram info: Loading facts in mysql_version info: Loading facts in gateway info: Loading facts in permgen_check info: Loading facts in ram info: Loading facts in mysql_version mysql: unrecognized service mysql: unrecognized service mysql: unrecognized service info: Caching catalog for munin-new.pss.dev info: Applying configuration version '1393262564' notice: /Stage[main]/Munin-node/Exec[/usr/bin/munin-cron]/returns: is notrun, should be 0 (noop) notice: Finished catalog run in 6.83 seconds What's odd is that the mysql_version custom fact is called twice. MySQL is not installed on the box, hence the error. However I can't understand why it errors out the second time, but not the first. Any suggestions? This is occuring on a CentOS 5.4 box running Puppet 2.62. Thanks. -- 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/835b020a-2c27-437b-9484-b23c59aa4c36%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] How do I prevent logging of secure data?
By default puppet will report the changes to any files it updates. If the file includes any secure data like passwords or private encryption keys, that also shows up in the logs. Is there any way to block this level of logging for individual files? Disabling it for all files is also acceptable. -- 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/917812ed-e42e-4aec-b594-058155034bc3%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] How do I prevent logging of secure data?
On 24.02.2014 21:13, Larry Fast wrote: > By default puppet will report the changes to any files it updates. If > the file includes any secure data like passwords or private encryption > keys, that also shows up in the logs. Is there any way to block this > level of logging for individual files? Disabling it for all files is > also acceptable. You should be able to generally block it with the `show_diff` configuration option [1]. It can also be deactivated on a per-file basis [2] as long as you run a recent version of puppet (according to the original feature request [3] this has been added in puppet 3.2) [1] http://docs.puppetlabs.com/references/latest/configuration.html#showdiff [2] http://docs.puppetlabs.com/references/latest/type.html#file-attribute-show_diff [3] http://projects.puppetlabs.com/issues/16412 -Stefan -- 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/530BBCD2.6080504%40taunusstein.net. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Hit and miss application of puppet modules
Howdy folks, well after successfully rebuilding my hosed puppet environment
(puppet was removing /var/lib/yum and /var/lib/rpm), I finally have a sane
and mostly functioning puppet environment. However, I'm having a strange
issue with applying modules via roles. In some instances it works, and in
others it doesn't.
To begin with, I'm using the puppetlabs firewall module (
http://forge.puppetlabs.com/puppetlabs/firewall) to drive iptables on a
number of my servers. Right now it's only attempting to drive two of them:
A file server and the puppet master itself, and I'm doing this using a
roles module. However, it seems quite happy to apply the defined module to
the file server, but not to the puppetmaster. Config below:
## ../puppet/manifests/site.pp ##
node 'JUMPBOX' {
include role::fs_server
}
node 'PUPPETMASTER' {
include role::puppet_master
}
## ../puppet/modules/role/init.pp ##
class role {
include profile::base
}
class role::fs_server inherits role {
include profile::fs_server
}
class role::puppet_master inherits role {
include profile::puppet_master
}
## ../puppet/modules/profile/init.pp ##
class profile::base {
notify {"Applying profile::base":}
include ntp
include ssh_server
include my_fw
}
class profile::fs_server {
notify {"Applying profile::fs_server":}
include ssh_server::jump_box
}
class profile::puppet_master {
notify {"Applying profile::puppet_master":}
include puppet_master
}
As you can see it's a very very basic, skeletal config that is handling
role-based module application. In the case of the 'ssh_server::jump_box'
and 'puppet_master' modules, these are both firewall application rules:
## ../puppet/modules/ssh_server/manifests/init.pp ##
class ssh_server::jump_box {
# Firewall logic (allow forwarding)
firewall { '098 allow forwarding':
chain => 'FORWARD',
proto => 'tcp',
action => 'accept',
}
# Firewall logic (allow ssh from all)
firewall { '099 accept ssh from anywhere':
chain => 'INPUT',
state => ['NEW'],
dport => '22',
proto => 'tcp',
action => 'accept',
}
}
## ../puppet/modules/puppet_master/manifests/init.pp ##
class puppet_master {
# Firewall Logic: Allow TCP/8140
firewall { '200 allow puppetmaster port':
chain => 'INPUT',
state => ['NEW'],
dport => '8140',
proto => 'tcp',
source => '',
action => 'accept',
}
}
The JUMPBOX gets its 'ssh_server::jump_box' module just fine, but the
'puppet_master' module never gets applied to the PUPPETMASTER node. The
notify code in the 'profile' module is logging the "Applying
profile::fs_server" and "Applying profile::puppet_master" messages in both
cases, but for some reason is skipping the 'puppet_master' module.
If I perform a:
puppet apply -e "include puppet_master"
on the PUPPETMASTER node, it runs the module just fine and modifies the
firewall accordingly. Is there something completely simple that I'm just
missing above? I feel like I may just have a syntax error or something
wrong with the include that I'm completely ignoring :/
TIA,
C
--
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/CAFOrgqcS0SQncyuhF2YAkX3AbHZRfYmzYyNhX%3Dceq%3D22mYE_Kg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: Puppet client removing yum / rpm cache?
John, Just wanted to drop a quick note to say thanks for responding and for the great variety of ideas to try to troubleshoot. At the end of the day, the environment was so hosed that I eventually just rebuilt the puppetmaster from scratch with a setup script to ensure lack of errors in either sysconfig, puppet.conf, or any other location driving puppet. Worked nicely this time :) Cheers, C On Fri, Feb 21, 2014 at 8:00 AM, jcbollinger wrote: > > > On Thursday, February 20, 2014 5:03:53 PM UTC-6, Christopher Opena wrote: >> >> Howdy folks, >> >> I've got some weird behavior from one of my puppet clients (actually the >> client running on the puppet master), where running the agent somehow >> destroys either the yum cache or the rpm db. Directly after running the >> agent I get the following message from yum (without modifying yum.conf or >> any of the .repo files in /etc/yum.repos.d/): >> >> # yum list installed >> YumRepo Error: All mirror URLs are not using ftp, http[s] or file. >> Eg. $releasever is not a valid release or hasnt been released yet/ >> removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/$ >> releasever/base/mirrorlist.txt >> Error: Cannot find a valid baseurl for repo: base >> >> Prior to running the puppet agent, yum was working perfectly. I was able >> to fix the above problem by reinstalling the centos-release package, but >> even after doing so a 'yum list installed' and 'rpm -qa' listed the >> centos-release package as *the only package installed* (clearly others were >> installed but the db probably got corrupted). >> >> Restart the puppet agent, and the error with $releasever resumed, and >> centos-release was shown as not installed by both yum and rpm. >> >> Looking through the puppet agent log (/var/log/puppet/puppet.log), I only >> found this in the startup procedure: >> >> Thu Feb 20 14:26:50 -0800 2014 Puppet (notice): Caught TERM; calling stop >> Thu Feb 20 14:26:51 -0800 2014 Puppet (notice): Reopening log files >> Thu Feb 20 14:26:51 -0800 2014 Puppet (notice): Starting Puppet client >> version 3.4.2 >> Thu Feb 20 14:26:52 -0800 2014 /File[/var/lib/rpm]/ensure (notice): >> removed >> Thu Feb 20 14:26:52 -0800 2014 /File[/var/lib/yum]/ensure (notice): >> removed >> Thu Feb 20 14:26:55 -0800 2014 Puppet (err): Could not prefetch package >> provider 'yum': Execution of '/usr/bin/python /usr/lib/ruby/site_ruby/1.8/ >> puppet/provider/package/yumhelper.py' returned 1: Loaded plugins: >> fastestmirror >> >> So it looks like directly after the client starts, it removes(?) >> /var/lib/rpm and /var/lib/yum and then yum stops working again (with the >> same $releasever) error. >> > > > Wow. > > > >> The odd thing is that we have several other nodes that are having the >> exact same modules applied and experiencing zero issues, so something odd >> is going on with this particular node (which is also the master). >> >> Anyone experience anything like this or have any ideas what could be >> causing the puppet runs to basically destroy the yumdb? >> >> > > I have never heard of such behavior. > > The problem likely is not directly related to your manifests, because it > looks like the agent is removing the rpm and yum databases before it starts > applying the catalog. I would start by looking for differences between the > puppet configuration files (puppet.conf) on the master and on a node that > does not experience the problem. Focus on differences in the [main] and > [agent] sections, if there are any. > > It is also possible that your Puppet installation is corrupted or > compromised, though the likelihood of the latter seems remote. It is > unfortunate that destruction of /var/lib/rpm will make those alternatives > harder to evaluate. > > > John > > -- > 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/ab0f3c82-cacb-458d-a76b-33943495b85a%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/CAFOrgqcQvNBFfSyyg%3DAkR0AVwVKMA_4xb%3D3qacdwHS7mGim8tA%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hit and miss application of puppet modules
On 2/24/2014 4:47 PM, Christopher Opena wrote:
class profile::puppet_master {
notify {"Applying profile::puppet_master":}
include puppet_master
}
Because you're within class profile::puppet_master Puppet assume you
mean the local puppet_master class instead of the top scope
puppet_master. In order to force top scope you need include ::puppet_master
I find myself defaulting to include ::module_name when using
role/profile as a safety precaution.
Ramin
--
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/530BF14E.7090001%40badapple.net.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hit and miss application of puppet modules
Ah, thanks Ramin K - I knew it would be something fairly simple yet
completely unknown to me. Learn something new every day. I think I'll
pick up the same default habit, seems the safe thing to do indeed.
On Mon, Feb 24, 2014 at 5:26 PM, Ramin K wrote:
> On 2/24/2014 4:47 PM, Christopher Opena wrote:
>
> class profile::puppet_master {
>> notify {"Applying profile::puppet_master":}
>> include puppet_master
>> }
>>
>
> Because you're within class profile::puppet_master Puppet assume you mean
> the local puppet_master class instead of the top scope puppet_master. In
> order to force top scope you need include ::puppet_master
>
> I find myself defaulting to include ::module_name when using role/profile
> as a safety precaution.
>
> Ramin
>
> --
> 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/530BF14E.7090001%40badapple.net.
> 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/CAFOrgqf2nKY7%3DyHe7wDpNVCfp-HWP%3DpiHVN%2Btn1G4qY%3D9wJYUA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
