Re: [Puppet Users] failing with fail() without failing everything
On Thu, Feb 3, 2011 at 7:02 PM, Rich Rauenzahn wrote:
> We would like to have a default node applied to systems, but also
> trigger a failure so that we notice the system in puppet-dashboard.
>
> At the moment we're doing...
>
> node default {
> include system_defaults
> fail("$hostname doesn't have a node to apply to it")
> }
>
> Unfortunately this seems to fail before the system_defaults class can
> be applied to the node (which we want applied every time). And err()
> doesn't propagate up to the dashboard.
Fail function fails the catalog, and without a catalog the client does
not have anything to apply. This is intended as a big red stop button.
You can use bad exec to generate a message and still provide the
resources in system_defaults class which flags this in dashboard (but
I thought this gets applied to ENC nodes anyhow).
exec { "/bin/echo 'not defined'; exit 1": }
This feels like a kludge, and perhaps the following process is better.
Write a function on the puppetmaster that appends a file on the master
about undefined nodes.
Create a notify resource that's tagged=alertme, and use tagmail
function to email an alert as necessary.
Not sure if anyone else have a more elegant solution.
Thanks,
Nan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] failing with fail() without failing everything
We would like to have a default node applied to systems, but also
trigger a failure so that we notice the system in puppet-dashboard.
At the moment we're doing...
node default {
include system_defaults
fail("$hostname doesn't have a node to apply to it")
}
Unfortunately this seems to fail before the system_defaults class can
be applied to the node (which we want applied every time). And err()
doesn't propagate up to the dashboard.
Is there any way to accomplish what I want?
Rich
--
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] Starting Tomcat Through Service Resource
On Wed, Feb 2, 2011 at 11:12 AM, robertbogdon wrote:
>
> I'm running into a bizarre issue. What it boils down to is that when
> I start tomcat through puppetd, certain UTF-8 settings do not appear
> to take effect and the end result is garbage characters on a web
> page. However, when we run puppetd with --no-daemonize --debug --
> trace --one-time, everything works fine. Tomcat also starts
> appropriately when started on boot, or manually with the service start
> command. Our initial thought was that potentially there was a
> difference in the environment variables being passed to tomcat
> depending on how it was started, but we've examined the environments
> and altered the start command puppet is using to ensure that they are
> identical. I've included our service entry below, any help would be
> appreicated.
>
> service { tomcat6:
> enable => false,
> #hasrestart => true,
> start => '/bin/bash -c "unset LANGUAGE; unset LC_ALL; unset
> LC_MESSAGES; /usr/sbin/service tomcat6 start"',
> require => [ Package[tomcat6] ],
> subscribe => [ File["/etc/tomcat6/tomcat-users.xml"], File["/etc/
> tomcat6/server.xml"], File["/etc/tomcat6/config.properties"], File["/
> etc/tomcat6/context.xml"] ],
> ensure => running,
> }
There's some subtle difference in environment variable between running
puppet agent as a daemon and onetime under the root user. Is your
script by any chance affected by environment variables? If so add an
exec that dumps this info to a file or check /proc/{proc_id}/environ.
Thanks,
Nan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] reusing variables "best practices"
Hi All, I'm in the process of creating Puppet modules for my load balanced environment. I have multiple Apache nodes behind a load balancer and each Apache virtual host has its own internal IP. I've created an Apache module that does this by creating an Apache vhost template and define my own variables that are substituted by variables I've defined in my nodes configuration. E.g. apache1 node.pp: $ip_www = 10.0.0.1 $ip_www2 10.0.0.1 apache2 node.pp: $ip_www = 10.0.0.1 $ip_www2 10.0.0.1 apache vhost template: :80> The next step is to configure Piranha using Puppet. The module creates a template using the IP's defined in my node configuration. In order to use the IP's I've defined in the nodes config file for the piranha configuration I'd need to rename the variables to something like: $apache1_ip_www = 10.0.0.2 $apache1_ip_www2 10.0.0.2 As you can see if change the variable names to reflect the node name then the Apache vhost template will not be generated correctly. My question is what is the "best practise" when doing something like this? I was thinking of creating a new file for each apache node and write an "if" statement to include the appropriate file. Another option would be to put a case statement in the Apache module that if, for example, the nodes name is apache2 then set $ip_www as $apache1_ip_www. The part that I'm "concerned about" is how to redefine variables to make them compatible with both modules and perhaps future modules. I hope this all makes sense. Thanks, Gareth -- 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] user authorized_keys with wrong perms
Hi,
I sometimes get a strange problem with some user's authorized_keys file.
The file should belong to user:users_group but puppet sets it as
root:root:
i.e:
err: /Stage[os]/Computing_ssh/Ssh_authorized_key[neuro...@si.pic.es]:
Could not evaluate: Permission denied - /home/neuroadm/.ssh/authorized_keys
# ls -lsa /home/neuroadm/.ssh/
total 12
4 drwx-- 2 neuroadm neuro 4096 Feb 3 21:02 .
4 drwx-- 3 neuroadm neuro 4096 Feb 3 21:02 ..
4 -rw--- 1 root root 578 Feb 3 21:02 authorized_keys
My code looks like:
file{
'ssh_neuroadm' :
name=> '/home/neuroadm/.ssh',
owner => 'neuroadm',
group => 'neuro',
mode=> 700,
ensure => directory,
require => File['home_neuroadm'];
'home_neuroadm' :
name=> '/home/neuroadm/',
owner => 'neuroadm',
group => 'neuro',
mode=> 700,
ensure => directory;
'neuro...@si.pic.es' :
user=> 'neuroadm',
key => 'Key';
The most strange thing is that it works sometimes and sometimes not...
The problem is solved if I remove .ssh dir and rerun puppet.
Anyone could help to find a reasonable explanation for this behaviour?
TIA,
Arnau
--
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] 2.6.2 excluding an exported resource
I have the class below to export host entries.
However I wish to override the entry for my host to 127.0.0.1
So for all of the hosts other than foo.bar.com I would like them to
have the real IP address but for foo.bar.com I would like to just have
the loopback host entry. 2.6.2 doesn't allow multiple tags and if I
put in another entry for localhost there is a collision.
Is there any way to accomplish this in 2.6.2?
=
class stagehosts {
if $MY_CUSTOM_FACT =~ /BLAH-BLAH/ {
@@host { $fqdn:
target => '/etc/hosts',
ip => $ipaddress,
host_aliases => [$hostname],
tag => stagehosts,
}
Host <<|tag == 'stagehosts'|>>
}
}
--
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: Exported resources and the tag function
The other alternative is to call the tag function in a node but it seems the tag is not inherited so rather than defining the tag in the default node, I'd have to do so in every node. The lack of inheritance seems to be by design so I'm fine using a define if I can get it to work. > > I am led to believe by http://projects.puppetlabs.com/issues/5239 that using > a tag is the accepted workaround to not being able to collect by environment > directly. The tag function works in the global scope and it appears to not cause problems when clients with a different environment contact the same master. That's my solution unless someone advises against it. -- 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: Ordering
On Feb 3, 2011, at 10:22 AM, Adam Gibbins wrote: > On 3 February 2011 18:14, Brian Gallew wrote: > Add a fact that's derived from parsing /var/lib/puppet/state/classes.txt. It > will be exactly one run behind, but it will have the complete list of classes > as of the previous run and it's reliable. > > I considered this, though as you say the run is going to be delayed which is > a little annoying as our puppet runs are only once every half hour. So I'd > have to wait an hour for graphing, also seems not as clean as it should be. Welcome to my life. I'm building Nagios and ssh configs off of class data, and both suffer from this issue. If it helps, it's only annoying when you think about it. 8-/ -- 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: Ordering
On 3 February 2011 17:58, Richard Crowley wrote: > On Thursday, February 3, 2011 at 9:53 AM, Adam Gibbins wrote: > > Hi All, > I'm trying to implement a template (for my collectd config) that gives > different results depending on the other modules included on that machine. > I tried to do this by checking for the class tags but it turns out that due > to bug #3049 this is a huge pain and 90% of the time the tags aren't > registered by the time the template is parsed so I don't get my expected > result. > > Use multiple collectd configuration files if you possibly can. Then each > class can manage its own little corner of collectd. Putting > > Include "/etc/collectd.d/*.conf" > > in your main /etc/collectd.conf should make this possible if it isn't by > default. > > Rich > This could work, although I'd have to modify all my modules that require graphing to call collectd which would be somewhat annoying and would stop the module being so standalone (e.g. we couldn't change monitoring systems so easy). On 3 February 2011 18:14, Brian Gallew wrote: > Add a fact that's derived from parsing /var/lib/puppet/state/classes.txt. > It will be exactly one run behind, but it will have the complete list of > classes as of the previous run and it's reliable. > I considered this, though as you say the run is going to be delayed which is a little annoying as our puppet runs are only once every half hour. So I'd have to wait an hour for graphing, also seems not as clean as it should be. -- 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: Ordering
Add a fact that's derived from parsing /var/lib/puppet/state/classes.txt. It will be exactly one run behind, but it will have the complete list of classes as of the previous run and it's reliable. On Feb 3, 2011, at 9:58 AM, Richard Crowley wrote: > On Thursday, February 3, 2011 at 9:53 AM, Adam Gibbins wrote: > >> Hi All, >> I'm trying to implement a template (for my collectd config) that gives >> different results depending on the other modules included on that machine. >> I tried to do this by checking for the class tags but it turns out that due >> to bug #3049 this is a huge pain and 90% of the time the tags aren't >> registered by the time the template is parsed so I don't get my expected >> result. > Use multiple collectd configuration files if you possibly can. Then each > class can manage its own little corner of collectd. Putting > > Include "/etc/collectd.d/*.conf" > > in your main /etc/collectd.conf should make this possible if it isn't by > default. > > Rich > > -- > 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] Re: Ordering
On Thursday, February 3, 2011 at 9:53 AM, Adam Gibbins wrote: Hi All, > I'm trying to implement a template (for my collectd config) that gives > different results depending on the other modules included on that machine. > I tried to do this by checking for the class tags but it turns out that due > to bug #3049 this is a huge pain and 90% of the time the tags aren't > registered by the time the template is parsed so I don't get my expected > result. > Use multiple collectd configuration files if you possibly can. Then each class can manage its own little corner of collectd. Putting Include "/etc/collectd.d/*.conf" in your main /etc/collectd.conf should make this possible if it isn't by default. Rich -- 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] Ordering
Hi All, I'm trying to implement a template (for my collectd config) that gives different results depending on the other modules included on that machine. I tried to do this by checking for the class tags but it turns out that due to bug #3049 this is a huge pain and 90% of the time the tags aren't registered by the time the template is parsed so I don't get my expected result. I'm running Puppet 2.6.2 and MCollective 1.0 (a workaround using mcollective would be perfectly viable for me). Does anyone have any suggestions to workarounds for this? I can think of a possible few, none of which are particularly clean though and I don't wish to reinvent the wheel if someone already has a nice fix. Thanks -- 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: Starting Tomcat Through Service Resource
The only substantial differences in execution environment between
those two should be that the daemon is running in a distinct session
from your shell, has a CWD of '/', and has std{in,out,err} open to
/dev/null.
The rest of the code is identical; it might be interesting to find out
if the '--debug' or '--trace' flags are what makes the difference, by
dropping them from the command-line while retaining '--no-daemonize'
and see if that works or fails?
Regards,
Daniel
On Thu, Feb 3, 2011 at 08:14, Robert Bogdon wrote:
> We're looking at /proc//environ to see the environment of the
> tomcat process. We're not using SELinux, and in this case everything
> is being run by root, though tomcat does switch over to a tomcat user
> at some point during it's startup. What really confuses me is why it
> works in with all of the debug flags, but not when run normally as a
> daemon.
>
> On Thu, Feb 3, 2011 at 6:26 AM, jcbollinger wrote:
>>
>>
>> On Feb 2, 1:12 pm, robertbogdon wrote:
>>> I'm running into a bizarre issue. What it boils down to is that when
>>> I start tomcat through puppetd, certain UTF-8 settings do not appear
>>> to take effect and the end result is garbage characters on a web
>>> page. However, when we run puppetd with --no-daemonize --debug --
>>> trace --one-time, everything works fine. Tomcat also starts
>>> appropriately when started on boot, or manually with the service start
>>> command. Our initial thought was that potentially there was a
>>> difference in the environment variables being passed to tomcat
>>> depending on how it was started, but we've examined the environments
>>> and altered the start command puppet is using to ensure that they are
>>> identical. I've included our service entry below, any help would be
>>> appreicated.
>>>
>>> service { tomcat6:
>>> enable => false,
>>> #hasrestart => true,
>>> start => '/bin/bash -c "unset LANGUAGE; unset LC_ALL; unset
>>> LC_MESSAGES; /usr/sbin/service tomcat6 start"',
>>> require => [ Package[tomcat6] ],
>>> subscribe => [ File["/etc/tomcat6/tomcat-users.xml"], File["/etc/
>>> tomcat6/server.xml"], File["/etc/tomcat6/config.properties"], File["/
>>> etc/tomcat6/context.xml"] ],
>>> ensure => running,
>>> }
>>>
>>> enable is set to false in this entry to ensure that the correct
>>> configuration is in place before the service is started and picked up
>>> by the load balancer.
>>
>> I concur that the difference is probably related to the environment.
>> How are you testing / verifying that the environments are identical?
>> For instance, have you inserted code in the init script to dump the
>> environment to a file at runtime?
>>
>> Other than environment *variables*, the most suspect environmental
>> influence is the user identity (effective *and* real) on whose behalf
>> the service is started. Do you perchance have SELinux running in
>> enforcing mode? In that case, you need to expand the notion of
>> "identity" to security context. These considerations could affect
>> whether Tomcat is able to read various configuration files, especially
>> any that have been locally modified.
>>
>>
>> John
>>
>> --
>> 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.
>>
>>
>
>
>
> --
> ---
> Robert Bogdon
> Sr. Systems Engineer, DivX
> http://www.blah.net
>
> --
> 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 Labs Developer – http://puppetlabs.com
✉ Daniel Pittman
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons
--
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] Multiple external commands with puppet
On Thu, Feb 3, 2011 at 08:23, linuxbsdfreak wrote:
> I want to execute multiple sed commands using the exec commands within
> puppet. I can only setup one command parameter. For now i have to give
> a long list of commands separated with ";" in order to use the single
> command parameter. I know there are other efficient ways to solve this
> problem. But my requirement is such i need to execute multiple
> commands using the exec tool within puppet. Any one have who can give
> me a hint how this problem could be solved.
>
> NOTE: I need only the command parameter of exec. I dont need the other
> parameters
So, uh, your constraints are kind of strange, and suggest to me that
there is something else you are not telling us about what you are
trying to do that we should probably know. It would be a big help if
you could post the manifest that is causing trouble somewhere.
Anyhow, you can do this a bunch of ways; can you just pass your
multiple operations to the single sed instance? That should behave
the same way as multiple sed instances, in pretty much every case I
can imagine.
If that isn't possible for some reason, you can always fall back to
invoking the shell:
exec { "example":
command => "/bin/sh -c 'sed -e s@very@strange@ | sed -e s@choice@here@'"
}
Finally, as already noted, installing the script as an extra file
would be a really good way to make this easier to manage in future and
all.
Regards,
Daniel
PS: If you are trying to do multiple, independent things in the one
command, please don't. Running multiple exec operations to mutate the
file, and making sure they are all equipped with an appropriate
'unless' or 'onlyif' is much better in the long term.
--
⎋ Puppet Labs Developer – http://puppetlabs.com
✉ Daniel Pittman
✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775
♲ Made with 100 percent post-consumer electrons
--
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: Puppetrun problem
Just FYI...looks like it was an ordering problem in auth.conf. I did not know that this file was ordered. Entries in this file have to be *before* path / auth any On Feb 2, 4:27 pm, rjl wrote: > One more piece of infolisten = true in my puppet.conf file on the > clients. > > On Feb 2, 3:19 pm, rjl wrote: > > > Hi, > > I am running puppet-2.6.4-0.7.el5 and puppetmaster-2.6.4-0.7.el5 on > > CentOS 5.4 and cannot get puppetrun to work. > > > Files on my clients are as follows: > > /etc/puppet/auth.conf contains: > > path /run > > method save > > allow * > > > /etc/puppet/namespaceauth.conf contains: > > [fileserver] > > allow * > > [puppetmaster] > > allow * > > [puppetrunner] > > allow * > > [puppetbucket] > > allow * > > [puppetreports] > > allow * > > [resource] > > allow * > > > Here is the output from running puppetrun from my puppetmaster: > > > [root@stsdev-pri puppet]# puppetrun --debug -- > > host=devadm0108.cdntools.nsatc.net > > Triggering devadm0108.cdntools.nsatc.net > > Host devadm0108.cdntools.nsatc.net failed: Error 403 on SERVER: > > Forbidden request: stsdev-pri(10.248.58.43) access to /run/ > > devadm0108.cdntools.nsatc.net [save] authenticated at line 101 > > devadm0108.cdntools.nsatc.net finished with exit code 2 > > Failed: devadm0108.cdntools.nsatc.net > > > Thanks in advance for any assistance. -- 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] Multiple external commands with puppet
While it's perfectly appropriate to have multiple exec{} or a single exec{}
with a multi-line command in your puppet manifest, once you reach a certain
level of complexity you almost invariably want to switch to a
file{"/usr/local/scripts": ...} exec{"/usr/local/scripts/doit": ...} model.
The script can be trivially customized for the local system by puppet giving
you great flexibility, while allowing more complex code paths or alternate
languages to be easily used.
On Feb 3, 2011, at 8:29 AM, Mark Stanislav wrote:
> Are you able to group these sed statements into a script and pass arguments
> to the script to do whatever set of executions are needed for that specific
> dataset?
>
> I may not understand your 'need' exactly, either. Can you explain more of
> what you are trying to accomplish and less about what you've chosen to
> accomplish it with. May help stir-up better answers.
>
> -Mark
>
> On Feb 3, 2011, at 11:23 AM, linuxbsdfreak wrote:
>
>> Hi,
>>
>> I want to execute multiple sed commands using the exec commands within
>> puppet. I can only setup one command parameter. For now i have to give
>> a long list of commands separated with ";" in order to use the single
>> command parameter. I know there are other efficient ways to solve this
>> problem. But my requirement is such i need to execute multiple
>> commands using the exec tool within puppet. Any one have who can give
>> me a hint how this problem could be solved.
>>
>> NOTE: I need only the command parameter of exec. I dont need the other
>> parameters
>>
>> Regards,
>> Kevin
>>
>> --
>> 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.
Re: [Puppet Users] Multiple external commands with puppet
Are you able to group these sed statements into a script and pass arguments to the script to do whatever set of executions are needed for that specific dataset? I may not understand your 'need' exactly, either. Can you explain more of what you are trying to accomplish and less about what you've chosen to accomplish it with. May help stir-up better answers. -Mark On Feb 3, 2011, at 11:23 AM, linuxbsdfreak wrote: > Hi, > > I want to execute multiple sed commands using the exec commands within > puppet. I can only setup one command parameter. For now i have to give > a long list of commands separated with ";" in order to use the single > command parameter. I know there are other efficient ways to solve this > problem. But my requirement is such i need to execute multiple > commands using the exec tool within puppet. Any one have who can give > me a hint how this problem could be solved. > > NOTE: I need only the command parameter of exec. I dont need the other > parameters > > Regards, > Kevin > > -- > 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] Multiple external commands with puppet
Hi, I want to execute multiple sed commands using the exec commands within puppet. I can only setup one command parameter. For now i have to give a long list of commands separated with ";" in order to use the single command parameter. I know there are other efficient ways to solve this problem. But my requirement is such i need to execute multiple commands using the exec tool within puppet. Any one have who can give me a hint how this problem could be solved. NOTE: I need only the command parameter of exec. I dont need the other parameters Regards, Kevin -- 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] Exported resources and the tag function
Should I be able to use the built-in tag function...
define nagios::host($hostgroups) {
tag "environment:$environment"
nagios_host { "$name":
address => "$ipaddress_eth0",
contact_groups => "ops",
hostgroups => $hostgroups,
notify => Service["nagios"],
require => File["/etc/nagios/hosts"],
target => "/etc/nagios/hosts/$name.cfg",
use => "generic-host",
}
}
...with the goal of exporting @@nagios::host resources and collecting them by
tag?
node default {}
node a inherits default {
@@nagios::host { "$hostname": hostgroups => ["admin"] }
}
node b inherits default {
Nagios::Host<<| tag == "environment:$environment" |>>
}
This example code does not work unless I add a tag parameter to the
@@nagios::host resource in node a.
The other alternative is to call the tag function in a node but it seems the
tag is not inherited so rather than defining the tag in the default node, I'd
have to do so in every node. The lack of inheritance seems to be by design so
I'm fine using a define if I can get it to work.
I am led to believe by http://projects.puppetlabs.com/issues/5239 that using a
tag is the accepted workaround to not being able to collect by environment
directly.
Thanks,
Richard
--
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: Starting Tomcat Through Service Resource
We're looking at /proc//environ to see the environment of the
tomcat process. We're not using SELinux, and in this case everything
is being run by root, though tomcat does switch over to a tomcat user
at some point during it's startup. What really confuses me is why it
works in with all of the debug flags, but not when run normally as a
daemon.
On Thu, Feb 3, 2011 at 6:26 AM, jcbollinger wrote:
>
>
> On Feb 2, 1:12 pm, robertbogdon wrote:
>> I'm running into a bizarre issue. What it boils down to is that when
>> I start tomcat through puppetd, certain UTF-8 settings do not appear
>> to take effect and the end result is garbage characters on a web
>> page. However, when we run puppetd with --no-daemonize --debug --
>> trace --one-time, everything works fine. Tomcat also starts
>> appropriately when started on boot, or manually with the service start
>> command. Our initial thought was that potentially there was a
>> difference in the environment variables being passed to tomcat
>> depending on how it was started, but we've examined the environments
>> and altered the start command puppet is using to ensure that they are
>> identical. I've included our service entry below, any help would be
>> appreicated.
>>
>> service { tomcat6:
>> enable => false,
>> #hasrestart => true,
>> start => '/bin/bash -c "unset LANGUAGE; unset LC_ALL; unset
>> LC_MESSAGES; /usr/sbin/service tomcat6 start"',
>> require => [ Package[tomcat6] ],
>> subscribe => [ File["/etc/tomcat6/tomcat-users.xml"], File["/etc/
>> tomcat6/server.xml"], File["/etc/tomcat6/config.properties"], File["/
>> etc/tomcat6/context.xml"] ],
>> ensure => running,
>> }
>>
>> enable is set to false in this entry to ensure that the correct
>> configuration is in place before the service is started and picked up
>> by the load balancer.
>
> I concur that the difference is probably related to the environment.
> How are you testing / verifying that the environments are identical?
> For instance, have you inserted code in the init script to dump the
> environment to a file at runtime?
>
> Other than environment *variables*, the most suspect environmental
> influence is the user identity (effective *and* real) on whose behalf
> the service is started. Do you perchance have SELinux running in
> enforcing mode? In that case, you need to expand the notion of
> "identity" to security context. These considerations could affect
> whether Tomcat is able to read various configuration files, especially
> any that have been locally modified.
>
>
> John
>
> --
> 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.
>
>
--
---
Robert Bogdon
Sr. Systems Engineer, DivX
http://www.blah.net
--
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] Migrating from 0.25.4 to 2.6
On 02/03/2011 04:46 PM, Matthew Macdonald-Wallace wrote: > OK, thanks, that answers the question about whether we can go > backwards (we can't, we're using Regexes and a few other things!) > > Anyone know if a Puppet 2.6.2 client can talk to a 0.25.4 puppet master? Newer masters will entertain older clients. Do *not* use 0.24.x under any circumstances. Rolling 0.25.4 (or, while you're at it, 0.25.5) packages for debian is rather straight-forward. If you can spare a couple hours, you may find this to be the least painful road. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Migrating from 0.25.4 to 2.6
OK, thanks, that answers the question about whether we can go backwards (we can't, we're using Regexes and a few other things!) Anyone know if a Puppet 2.6.2 client can talk to a 0.25.4 puppet master? M. On 3 February 2011 15:18, Adam Heinz wrote: > On Thu, Feb 3, 2011 at 2:39 AM, Matthew Macdonald-Wallace > wrote: >> I'm also wondering what impact the move would have on our puppet >> manifests. Are there any "gotcha's" that I need to be aware of that >> could prevent my current manifests working under 2.6.2 or 0.24.5? > > I personally have been bitten running 0.24.x when the mysql module I > included used regexes (introduced in 0.25.x). > > http://docs.puppetlabs.com/guides/language_tutorial.html > > The "Language Feature by Release" should give you a good idea of other > things missing in 0.24.x that your 0.25.x manifests need. I haven't > used 2.6, so I can't speak to any forward migration issues. > > -- > 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] Migrating from 0.25.4 to 2.6
On Thu, Feb 3, 2011 at 2:39 AM, Matthew Macdonald-Wallace wrote: > I'm also wondering what impact the move would have on our puppet > manifests. Are there any "gotcha's" that I need to be aware of that > could prevent my current manifests working under 2.6.2 or 0.24.5? I personally have been bitten running 0.24.x when the mysql module I included used regexes (introduced in 0.25.x). http://docs.puppetlabs.com/guides/language_tutorial.html The "Language Feature by Release" should give you a good idea of other things missing in 0.24.x that your 0.25.x manifests need. I haven't used 2.6, so I can't speak to any forward migration issues. -- 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: Starting Tomcat Through Service Resource
On Feb 2, 1:12 pm, robertbogdon wrote:
> I'm running into a bizarre issue. What it boils down to is that when
> I start tomcat through puppetd, certain UTF-8 settings do not appear
> to take effect and the end result is garbage characters on a web
> page. However, when we run puppetd with --no-daemonize --debug --
> trace --one-time, everything works fine. Tomcat also starts
> appropriately when started on boot, or manually with the service start
> command. Our initial thought was that potentially there was a
> difference in the environment variables being passed to tomcat
> depending on how it was started, but we've examined the environments
> and altered the start command puppet is using to ensure that they are
> identical. I've included our service entry below, any help would be
> appreicated.
>
> service { tomcat6:
> enable => false,
> #hasrestart => true,
> start => '/bin/bash -c "unset LANGUAGE; unset LC_ALL; unset
> LC_MESSAGES; /usr/sbin/service tomcat6 start"',
> require => [ Package[tomcat6] ],
> subscribe => [ File["/etc/tomcat6/tomcat-users.xml"], File["/etc/
> tomcat6/server.xml"], File["/etc/tomcat6/config.properties"], File["/
> etc/tomcat6/context.xml"] ],
> ensure => running,
> }
>
> enable is set to false in this entry to ensure that the correct
> configuration is in place before the service is started and picked up
> by the load balancer.
I concur that the difference is probably related to the environment.
How are you testing / verifying that the environments are identical?
For instance, have you inserted code in the init script to dump the
environment to a file at runtime?
Other than environment *variables*, the most suspect environmental
influence is the user identity (effective *and* real) on whose behalf
the service is started. Do you perchance have SELinux running in
enforcing mode? In that case, you need to expand the notion of
"identity" to security context. These considerations could affect
whether Tomcat is able to read various configuration files, especially
any that have been locally modified.
John
--
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: using return value of a shell command as a puppet conditional
On Wed, Feb 2, 2011 at 1:52 PM, Ashley Gould wrote: > On Mon, Jan 31, 2011 at 06:27:20PM -0800, Daniel Pittman wrote: >> In the longer term I would hope to have that information pushed out >> from the puppet system, so that if a node *should* be joined with >> centrifyDC puppet will make it so, but until then what you have is >> great. > > I have considered that option, but I'll need to learn to walk first. > What makes it difficult for puppet to manage this task is that the > centrifyDC tools require authorization as AD admin user to join a > node to AD. This can be scripted, but I don't want to hardcode AD > admin passwords into puppet manifests. Again, suggestions are very > welcome. In my previous life, we created a special account in AD with only the permission to create a computer account in the directory. The special account didn't have login rights or anything. It should be well documented in your centrifyDC tools how to create such a limited account. Once you have this account in place, you can lock it. You can then unlock the account when you need to build a machine and have it automatically lock again after 15 minutes or so, if you want. Hope this helps, -- Jeff McCune http://www.puppetlabs.com/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] CIDR-matching in puppet manifests?
Martijn Grendelman: > Would you be so kind to post the solution you cho(o)se in the end? I > am interested in this too.. Thank you! I'm afraid I chose a rather less glamorous solution to a very specific problem. It suddenly occurred to me that for the majority of my needs would be served by matching on facts like network_eth0 and netmask_eth0. I can reason about the ranges involved by matching on these, and do my own CIDR logic in-manifest for a lot of it. It's not as powerful as the ruby IP address operations, but it gives me the functionality I need in a way that a newcomer to the system need only scowl over it for a short time. -- "There should be a homonym exam before people are issued keyboards." -- George Moffitt -- 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: using return value of a shell command as a puppet conditional
Nigel Kersten: > On Wed, Feb 2, 2011 at 5:10 PM, Daniel Pittman wrote: > > (Also, I went looking and found zero attempts to solve this in a > > reusable, FOSS way, let alone working solutions.) > > Yep. I've been dreaming of a Puppet-integrated Password Safe for a while :) Alas! I'm currently enjoying a powerful need for such a thing. My one need is that someone who compromises a puppet client host shouldn't have access to the safe except in specific circumstances specified by external conditions. I'd also like a pony. Have it on my desk by Monday. -- "N'aimez pas votre voiture? Alor, l'heure est arrive pour la brulé!" -- Mark Jaroski -- 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] end of file reached
On 02/01/2011 04:01 PM, walexey wrote: > hello everybody! > > server: > [awasilyev@puppet ~]$ rpm -q puppet-server > puppet-server-2.6.4-0.7.el5 > > client: > [root@opensource ~]# rpm -q puppet > puppet-2.6.4-0.7.el5 > > [root@opensource ~]# puppetd -t > info: Creating a new SSL key for opensource.vm.griddynamics.net > warning: peer certificate won't be verified in this SSL session > info: Caching certificate for ca > warning: peer certificate won't be verified in this SSL session > err: Could not request certificate: end of file reached > Exiting; failed to retrieve certificate and waitforcert is disabled > > How can i fix it? Try puppetd -t --waitforcert=60 HTH, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: accessing puppet config variables inside a manifest
On 11-02-01 04:16 AM, R.I.Pienaar wrote: > Since 2.6.0 you can just do notice($settings::vardir) oh .. I've just tried it out and it works. hurray for 2.6, then! :) and, I'll also keep Nan Liu's suggestion in mind for 0.25.x Thanks to everyone for the feedback! -- Gabriel Filion -- 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] accessing puppet config variables inside a manifest
On 11-01-31 01:09 PM, Nan Liu wrote:
>> I've done a quick test to print (notify{}) the value of $vardir and it's
>> > empty. Do you guys know of a way I could access this value within the
>> > module's manifests?
> Yeah, that would make manifests a lot more flexible. Here's a function
> that should work for this purpose and potentially other puppet
> configuration variables as well:
>
> # puppet_vardir.rb
> module Puppet::Parser::Functions
> newfunction(:puppet_vardir, :type => :rvalue) do
> Puppet[:vardir]
> end
> end
hmm, that's interestingly very simple. I would personally use a fact
instead of a function, but now that I know the ruby part to fetch the
config value, writing a fact shouldn't be too difficult.
thanks,
--
Gabriel Filion
--
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.
