Re: [Puppet Users] Trying to get a basic connection going between master and agent
Is your Puppet client's hostname puppet-slave?
On Sep 24, 2011 10:16 AM, mlove mikelove...@gmail.com wrote:
Hi all,
I am trying to get a simple example going with one master and one
puppet. I am on Debian and used apt-get install puppetmaster for the
master and apt-get install puppet for the puppet. I was able to get
the cert signed and imported to the master from the puppet. Now I am
just trying to get a basic example like putting a fil in the /tmp
directory on the puppet. I put the following in nodes.pp in /etc/
puppet/manifests/
node basenode {
}
node 'puppet-slave' inherits basenode {
file {'testfile':
path = '/tmp/testfile',
ensure = present,
mode = 0640,
content = I'm a test file.,
}
}
I run puppet agent --onetime on the puppet but when I check /tmp the
file testfile is not there. Any suggestions?
--
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: Official puppetlabs position on cron vs puppet as a service?
On Sep 24, 9:42 pm, Aaron Grewell aaron.grew...@gmail.com wrote: We had frequent inexplicable daemon crashes on Solaris, but not on RHEL5 (at least not yet) . Given known issues with memory leakage in older Ruby releases Cron seemed more likely to be reliable. We stuck a random wait in the Cron job to spread load on the master and so far it works well. On Sep 24, 2011 7:22 AM, treydock treyd...@gmail.com wrote: On Sep 23, 5:42 pm, Brian Gupta brian.gu...@brandorr.com wrote: Over the years many shops have come to start running puppet via cron to address memory leaks in earlier versions of Ruby, but the official position was that puppet was meant to be run as a continually running service. I am wondering if the official position has changed. On one hand many if not all of the early Ruby issues have been fixed, on the other, the addition of mcollective into the mix as a lightweight agent for triggering adhoc puppet runs, and other tasks somewhat lowers the requirements for puppet to be run as a service. (Or out of cron for that matter). I understand that in cases where old Ruby versions are for whatever reason mandated the answer may be different. Thanks, Brian -- http://aws.amazon.com/solutions/solution-providers/brandorr/ Could those memory leak problems cause the Puppet daemon to crash with no logs indicating why? I have about 20 systems all running CentOS 5 and 6, with Puppet 2.6.9, and I now have to have Zabbix run a /etc/ init.d/puppet start everytime the daemon crashes which is almost on a daily basis for every client. Would be interested to know of a known fix or if the only fix is the workaround of using Cron. Thanks - Trey -- 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. Could you share how you did the random wait? I may have to switch to a cron job with how often my daemons are crashing and having to be restarted by Zabbix. Thanks - Trey -- 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: Official puppetlabs position on cron vs puppet as a service?
On Sun, Sep 25, 2011 at 10:33 PM, treydock treyd...@gmail.com wrote: On Sep 24, 9:42 pm, Aaron Grewell aaron.grew...@gmail.com wrote: We had frequent inexplicable daemon crashes on Solaris, but not on RHEL5 (at least not yet) . Given known issues with memory leakage in older Ruby releases Cron seemed more likely to be reliable. We stuck a random wait in the Cron job to spread load on the master and so far it works well. On Sep 24, 2011 7:22 AM, treydock treyd...@gmail.com wrote: On Sep 23, 5:42 pm, Brian Gupta brian.gu...@brandorr.com wrote: Over the years many shops have come to start running puppet via cron to address memory leaks in earlier versions of Ruby, but the official position was that puppet was meant to be run as a continually running service. I am wondering if the official position has changed. On one hand many if not all of the early Ruby issues have been fixed, on the other, the addition of mcollective into the mix as a lightweight agent for triggering adhoc puppet runs, and other tasks somewhat lowers the requirements for puppet to be run as a service. (Or out of cron for that matter). I understand that in cases where old Ruby versions are for whatever reason mandated the answer may be different. Thanks, Brian -- http://aws.amazon.com/solutions/solution-providers/brandorr/ Could those memory leak problems cause the Puppet daemon to crash with no logs indicating why? I have about 20 systems all running CentOS 5 and 6, with Puppet 2.6.9, and I now have to have Zabbix run a /etc/ init.d/puppet start everytime the daemon crashes which is almost on a daily basis for every client. Would be interested to know of a known fix or if the only fix is the workaround of using Cron. Thanks - Trey -- 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. Could you share how you did the random wait? I may have to switch to a cron job with how often my daemons are crashing and having to be restarted by Zabbix. I used the ip_to_cron function from http://projects.puppetlabs.com/projects/1/wiki/Cron_Patterns afterwards, I just do a sleep random 59, so its also random within the minute. Ohad Thanks - Trey -- 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] Could not render to pson: you must specify title patterns
On Sat, Sep 24, 2011 at 01:43:05AM +0200, Steve Traylen wrote:
Hi,
I'm trying to add my first custom type to puppet largely copying
examples whilst working with puppet-2.6.6.
My error:
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not render to pson: you must specify title patterns when
there are two or more key attributes
What is a title pattern?
My extremely trivial files:
The type metric
http://pastebin.com/9F7sVYjp
The provider lemon.
http://pastebin.com/eJEvsV6v
Puppet 2.6 has basic support for types with composite namevars. That
means that not only one parameter identifies a resource but the
combination of parameters. One example is a port in /etc/services. What
really identifies an entry in /etc/services is not only the port's name
it is the name AND the protocol.
But when you write your manifest and describe a resource it is common
to not set any namevar explicitly but implicitly via the title. Example:
file { '/tmp/foo':
ensure = file,
}
The namevar of the fileresource is called `path` and because I haven't
specified the path parameter explicitly it is implicitly set to /tmp/foo (the
resource's title). If we have more then one namevar (I prefer the term
keyattribute by the way) the type developer has to specify a title pattern.
The title pattern is basically as special array that determines how to
convert the title of a resource into values for the different key attributes.
So to pick up the previous example of a port entry in /etc/services a resource
title could look like this:
inet_port { 'telnet/tcp':
ensure = present
number = '22',
}
With the correct title pattern puppet can now set the name parameter to
'telnet' and the protocol parameter to 'tcp'.
Long story short:
You see this message because your type does not implement the title
pattern method but you have a type with more than one keyattribute:
1. »id« which you explicitly marked with the isnamevar method
2. »name« which is implicitly always treated as a keyattribute
If the second one is not what you want you have to rename your
parameter.
-Stefan
pgpfo1fqXIvj3.pgp
Description: PGP signature
Re: [Puppet Users] Re: Official puppetlabs position on cron vs puppet as a service?
Ohad, was rand_fqdn not sufficient for you? On Sep 25, 2011 1:03 PM, Ohad Levy ohadl...@gmail.com wrote: On Sun, Sep 25, 2011 at 10:33 PM, treydock treyd...@gmail.com wrote: On Sep 24, 9:42 pm, Aaron Grewell aaron.grew...@gmail.com wrote: We had frequent inexplicable daemon crashes on Solaris, but not on RHEL5 (at least not yet) . Given known issues with memory leakage in older Ruby releases Cron seemed more likely to be reliable. We stuck a random wait in the Cron job to spread load on the master and so far it works well. On Sep 24, 2011 7:22 AM, treydock treyd...@gmail.com wrote: On Sep 23, 5:42 pm, Brian Gupta brian.gu...@brandorr.com wrote: Over the years many shops have come to start running puppet via cron to address memory leaks in earlier versions of Ruby, but the official position was that puppet was meant to be run as a continually running service. I am wondering if the official position has changed. On one hand many if not all of the early Ruby issues have been fixed, on the other, the addition of mcollective into the mix as a lightweight agent for triggering adhoc puppet runs, and other tasks somewhat lowers the requirements for puppet to be run as a service. (Or out of cron for that matter). I understand that in cases where old Ruby versions are for whatever reason mandated the answer may be different. Thanks, Brian -- http://aws.amazon.com/solutions/solution-providers/brandorr/ Could those memory leak problems cause the Puppet daemon to crash with no logs indicating why? I have about 20 systems all running CentOS 5 and 6, with Puppet 2.6.9, and I now have to have Zabbix run a /etc/ init.d/puppet start everytime the daemon crashes which is almost on a daily basis for every client. Would be interested to know of a known fix or if the only fix is the workaround of using Cron. Thanks - Trey -- 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. Could you share how you did the random wait? I may have to switch to a cron job with how often my daemons are crashing and having to be restarted by Zabbix. I used the ip_to_cron function from http://projects.puppetlabs.com/projects/1/wiki/Cron_Patterns afterwards, I just do a sleep random 59, so its also random within the minute. Ohad Thanks - Trey -- 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] Re: Using puppet to install debian packages from backports
Thank to both of you for your help, I'll try to setup apt-pinning. Cheers -- S Barthélémy -- 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] Gotchas around upgrading from an old version (0.25.4) to a newer version.
If you follow the mailing list it seems that there were a larger number of deliberate syntax changes from the move from 2.6 to 2.7 than there were from 0.25 to 2.6. IE: Syntax that changes behavior, not just breaks. The rule of thumb has always been to support one major version backwards, so a 2.7 server should in theory support 2.6 clients, and 0.25 clients less so. YMMV, as there really isn't a strict guarantee of backwards compatibility in any case. Check out: http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notesand you'll see the 2.7 release had a lot more changes than the 2.6 branch. You are likely to have fewer issues migrating from 0.25 to 2.6 vs 2.7. Two things to consider when you are making this migration. 1) 2.6.9 is a more stable code base. (Stable meaning mature and vetted). 1) 2.7.4 is a more featureful, faster-moving code base. (Faster moving because it's the active branch and is newer). We are just now feeling that it is ready for new deployments, so if the features are compelling, maybe the risk and pain of a two major version upgrade might be worth it. I still think skipping major puppet versions when upgrading is somewhat risky, and I would probably move my environment to 2.6.9 and then plan on a later move to 2.7. I guess for me the deciding factors would be, a) how large is my code base (the smaller it is, the easier it will be to debug any issues that come up), and b) what is my pain tolerance if there are incompatibilities that come up. -Brian On Fri, Sep 23, 2011 at 6:06 PM, brokenpipe yvo.vando...@gmail.com wrote: I've been tasked at my workplace to upgrade our puppet installation to a more modern version. Currently all the environments run a RubyGem version of puppet 0.25.4 on mostly RHEL/Centos 5.3 - 5.5 (there are, like most environments, a few laggards running RHEL4 or new machines running CentOS 6). The plan is to upgrade these to the most stable version of Puppet, which at the time of writing is 2.7.3. I plan on building RPMs on RHEL5.3 for Puppet 2.7.3 against the Ruby version that RHEL5 shipped with which is 1.8.5 I believe. Are there are any significant gotaches. My plan was to upgrade the server first and then do a few roll outs to some QA machines and see how it goes. However there is some concern in the group that 0.25.4 agents are unable to talk to a 2.7.3 server. Are these unfounded or true? -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-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. -- http://aws.amazon.com/solutions/solution-providers/brandorr/ -- 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] Lost sunglasses at PuppetConf
Hi folks, sorry about this unusual email but I wasn't sure where else to send this. I just attended PuppetConf 2011 in Portland. On the last day near the end of the conference, I found a pair of sunglasses in the main auditorium. I stowed them in my backpack intending to find out if there was a lost and found, but I confess that I completely forgot about them until I found them after getting home. I looked them up online and found that they are relatively expensive sunglasses. If you are the owner and can identify the type of sunglasses that you lost, shoot me an email and I'll see about getting them shipped back to you. -Steve -- 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.
