RE: [Puppet Users] puppet client could not request certificate: Error 500 on SERVER
Have you confirmed that puppet master is running as user = puppet? On the master check: puppet --genconfig|grep user Mark From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On Behalf Of Jo Rhett Sent: Monday, August 20, 2012 1:03 PM To: puppet-users@googlegroups.com Subject: Re: [Puppet Users] puppet client could not request certificate: Error 500 on SERVER You should spend some time and determine how and why that is happening. I can assure you that it's not normal, so this is something specific to some custom code on your site. On Aug 19, 2012, at 10:56 AM, Stuart Cracraft wrote: I am seriously thinking of putting those recursive chown's in root crontab on puppet masters and puppet agents for /etc/puppet* and /var/lib/puppet* I shouldn't have to do this but have seen cases of ownership reversion. --Stuart Via Apple iPhone 4S on the AT&T Wireless Network On Aug 13, 2012, at 3:04 AM, Frederik Vos wrote: For the people still looking for an answer: chown -R puppet:puppet /var/lib/puppet/reports Op woensdag 30 maart 2011 21:02:43 UTC+2 schreef hyzhang het volgende: Thank. I am pasting the entire message here: Mar 30 14:01:04 puppetclient1 puppet-agent[28571]: Could not request certificate: Error 500 on SERVER: http://www.w3.org/TR/html4/strict.dtd";> Ruby (Rack) application could not be started
RE: [Puppet Users] newish puppet on RHEL4 and/or SLES9?
I'm not running newish puppet on rhel/cent 4, but the 0.25.6 EPEL packages seem to work well enough with my puppet master that runs 2.7.18. -Original Message- From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] On Behalf Of Jason Antman Sent: Wednesday, August 15, 2012 7:42 AM To: puppet-users@googlegroups.com Subject: [Puppet Users] newish puppet on RHEL4 and/or SLES9? I'm in the process of building out a new puppet master and pulling our existing/legacy infrastructure into Puppet control for the basic system-level stuff (mail, syslog, sudo, ssh, etc.). Unfortunately, the directive from on high is that all of our hosts need to be managed by the same system. That list is about 95% RHEL/Cent 5 or 6, but there's a few RHEL4 and SLES9 machines on the "must have" list. As upgrades are very unlikely, I'd like to be on the newest version possible - ideally, 2.7.12+ on the master so I can leverage puppetDB. Is anyone out there running new-ish puppet (2.7, or else 2.6) on such ancient beasts? If so, can anyone point me at sources for the packages, and dependencies? Or perhaps have spec files to share? I'd like to say I can spend the time to build and test puppet and all the dependencies, but alas, that is very far from the case. Thanks for any assistance, Jason PS - If you happen to be a competent generalist Linux admin in the Boston, MA or Atlanta, GA area, feel free pass along your resume... -- 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. Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. -- 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] Concat module
Can't speak to concat, but you might consider using augeas for managing
/etc/sysctl.conf. There is an excellent example of this at:
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Augeas , see "Working
Examples"
> -Original Message-
> From: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com]
> On Behalf Of Douglas Garstang
> Sent: Thursday, November 03, 2011 11:59 AM
> To: Puppet Users
> Subject: [Puppet Users] Concat module
>
> All,
>
> Trying to use the concat module with:
>
>
> class sysctl::common {
>
> include concat::setup
>
> concat {
> '/etc/sysctl.conf':
> owner => 'root',
> group => 'root',
> mode => '0644';
> }
>
> concat::fragment {
> '/etc/sysctl.conf':
> target => '/etc/sysctl.conf',
> content => 'kernel.sem=250 32000 32 2048',
> order => '99';
>}
>
> }
>
> Getting this error:
> Nov 3 14:54:04 dev-c3-app-90 puppet-agent[8143]: Failed to apply
> catalog: Parameter path failed: File paths must be fully qualified,
> not 'undef' at /etc/puppet/devmp/modules/concat/manifests/setup.pp:37
>
> What am I doing wrong?
>
> Doug.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to puppet-
> users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
Confidentiality Notice.
This message may contain information that is confidential or otherwise
protected from disclosure. If you are not the intended recipient, you are
hereby notified that any use, disclosure, dissemination, distribution, or
copying of this message, or any attachments, is strictly prohibited. If you
have received this message in error, please advise the sender by reply e-mail,
and delete the message and any attachments. Thank you.
--
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: I managed to break my Cent5 mongrel puppetmaster after upgrading from EPEL .25.5 to 2.6.6
I removed the rubygem-mongrel rpm and reinstalled it. That appears to have fixed my issue. On Oct 13, 6:22 pm, Mark Christian wrote: > CentOS release 5.7 (Final) > puppet-server-2.6.6-1.el5.noarch > ruby-1.8.5-19.el5_6.1.x86_64 > rake, version 0.9.2 > > The upgrade from 25.5 to 2.6.6 had been working fine. > > Not sure if this is relevant: I then attempted to get puppet-dashboard > working using this > guide:http://docs.puppetlabs.com/guides/installing_dashboard.html > I managed to upgrade rake, but never got this to work: rake > RAILS_ENV=production db:migrate , I then decided to restart the > puppetmaster and now I get this message: > > Starting puppetmaster: > Port: 18140/usr/lib/ruby/site_ruby/1.8/puppet/network/http.rb:8:in > `server_class_by_type': Mongrel is not installed on this platform > (ArgumentError) > from /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:157:in > `http_server_class_by_type' > from /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:137:in > `http_server_class' > from /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:58:in > `initialize' > from /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:104:in > `new' > from /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:104:in > `main' > from /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:46:in > `run_command' > from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' > from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:410:in > `exit_on_fail' > from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' > from /usr/sbin/puppetmasterd:4 > [FAILED] > > Any help would be most appreciated. Thanks in advance. > > $ cat /etc/puppet/puppet.conf > [main] > # Where Puppet stores dynamic and growing data. > # The default value is '/var/puppet'. > vardir = /var/lib/puppet > > # The Puppet log directory. > # The default value is '$vardir/log'. > logdir = /var/log/puppet > > # Where Puppet PID files are kept. > # The default value is '$vardir/run'. > rundir = /var/run/puppet > > # Where SSL certificates are kept. > # The default value is '$confdir/ssl'. > ssldir = $vardir/ssl > > [production] > modulepath=/etc/puppet/modules > manifest=/etc/puppet/manifests/site.pp > > [development] > modulepath=/etc/puppet/environments/development/modules > manifest=/etc/puppet/environments/development/manifests/site.pp > trace=true > report=false > > [agent] > # The file in which puppetd stores a list of the classes > # associated with the retrieved configuratiion. Can be loaded in > # the separate ``puppet`` executable using the ``--loadclasses`` > # option. > # The default value is '$confdir/classes.txt'. > classfile = $vardir/classes.txt > > # Where puppetd caches the local configuration. An > # extension indicating the cache format is added automatically. > # The default value is '$confdir/localconfig'. > localconfig = $vardir/localconfig > > [master] > user = root > storeconfigs = false > dbadapter = mysql > dbuser = puppet > dbpassword = > dbserver = localhost > dbsocket = /var/lib/mysql/mysql.sock > > modulepath = $confdir/modules > > factsync = true > factpath = $vardir/facts > > environments=production,development > > # The list of reports to generate. All reports are looked for > # in puppet/reports/.rb, and multiple report names should be > # comma-separated (whitespace is okay). > # The default value is 'store'. > reports = store, rrdgraph, tagmail > tagmap = /etc/puppet/tagmail.conf > > # Whether RRD information should be graphed. > rrdgraph = true > > # How often RRD should expect data. > # This should match how often the hosts report back to the server. > # The default value is '$runinterval'. > rrdinterval = $runinterval > > # The directory where RRD database files are stored. > # Directories for each reporting host will be created under > # this directory. > # The default value is '$vardir/rrd'. > rrddir = $vardir/rrd > > $ cat /etc/sysconfig/puppetmaster > # Location of the main manifest > #PUPPETMASTER_MANIFEST=/etc/puppet/manifests/site.pp > > # Where to log general messages to. > # Specify syslog to send log messages to the system log. > #P
[Puppet Users] I managed to break my Cent5 mongrel puppetmaster after upgrading from EPEL .25.5 to 2.6.6
CentOS release 5.7 (Final) puppet-server-2.6.6-1.el5.noarch ruby-1.8.5-19.el5_6.1.x86_64 rake, version 0.9.2 The upgrade from 25.5 to 2.6.6 had been working fine. Not sure if this is relevant: I then attempted to get puppet-dashboard working using this guide: http://docs.puppetlabs.com/guides/installing_dashboard.html I managed to upgrade rake, but never got this to work: rake RAILS_ENV=production db:migrate , I then decided to restart the puppetmaster and now I get this message: Starting puppetmaster: Port: 18140/usr/lib/ruby/site_ruby/1.8/puppet/network/http.rb:8:in `server_class_by_type': Mongrel is not installed on this platform (ArgumentError) from /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:157:in `http_server_class_by_type' from /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:137:in `http_server_class' from /usr/lib/ruby/site_ruby/1.8/puppet/network/server.rb:58:in `initialize' from /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:104:in `new' from /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:104:in `main' from /usr/lib/ruby/site_ruby/1.8/puppet/application/master.rb:46:in `run_command' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:410:in `exit_on_fail' from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:304:in `run' from /usr/sbin/puppetmasterd:4 [FAILED] Any help would be most appreciated. Thanks in advance. $ cat /etc/puppet/puppet.conf [main] # Where Puppet stores dynamic and growing data. # The default value is '/var/puppet'. vardir = /var/lib/puppet # The Puppet log directory. # The default value is '$vardir/log'. logdir = /var/log/puppet # Where Puppet PID files are kept. # The default value is '$vardir/run'. rundir = /var/run/puppet # Where SSL certificates are kept. # The default value is '$confdir/ssl'. ssldir = $vardir/ssl [production] modulepath=/etc/puppet/modules manifest=/etc/puppet/manifests/site.pp [development] modulepath=/etc/puppet/environments/development/modules manifest=/etc/puppet/environments/development/manifests/site.pp trace=true report=false [agent] # The file in which puppetd stores a list of the classes # associated with the retrieved configuratiion. Can be loaded in # the separate ``puppet`` executable using the ``--loadclasses`` # option. # The default value is '$confdir/classes.txt'. classfile = $vardir/classes.txt # Where puppetd caches the local configuration. An # extension indicating the cache format is added automatically. # The default value is '$confdir/localconfig'. localconfig = $vardir/localconfig [master] user = root storeconfigs = false dbadapter = mysql dbuser = puppet dbpassword = dbserver = localhost dbsocket = /var/lib/mysql/mysql.sock modulepath = $confdir/modules factsync = true factpath = $vardir/facts environments=production,development # The list of reports to generate. All reports are looked for # in puppet/reports/.rb, and multiple report names should be # comma-separated (whitespace is okay). # The default value is 'store'. reports = store, rrdgraph, tagmail tagmap = /etc/puppet/tagmail.conf # Whether RRD information should be graphed. rrdgraph = true # How often RRD should expect data. # This should match how often the hosts report back to the server. # The default value is '$runinterval'. rrdinterval = $runinterval # The directory where RRD database files are stored. # Directories for each reporting host will be created under # this directory. # The default value is '$vardir/rrd'. rrddir = $vardir/rrd $ cat /etc/sysconfig/puppetmaster # Location of the main manifest #PUPPETMASTER_MANIFEST=/etc/puppet/manifests/site.pp # Where to log general messages to. # Specify syslog to send log messages to the system log. #PUPPETMASTER_LOG=syslog # You may specify an alternate port or an array of ports on which # puppetmaster should listen. Default is: 8140 # If you specify more than one port, the puppetmaster ist automatically # started with the servertype set to mongrel. This might be interesting # if you'd like to run your puppetmaster in a loadbalanced cluster. # Please note: this won't setup nor start any loadbalancer. # If you'd like to run puppetmaster with mongrel as servertype but only # on one (specified) port, you have to add --servertype=mongrel to # PUPPETMASTER_EXTRA_OPTS. # Default: Empty (Puppetmaster isn't started with mongrel, nor on a # specific port) # # Please note: Due to reduced options in the rc-functions lib in RHEL/ Centos # versions prior to 5, this feature won't work. Fedora versions >= 8 are # known to work. #PUPPETMASTER_PORTS="" # Puppetmaster on a di
[Puppet Users] Re: Upgraded puppet-server from EPEL 24.8 to 25.1 - now seeing "puppetmasterd[xxxx]: Too many connections"
As far as disabling modules is concerned. The way I've organized my
manifests allows me to quickly comment out the various "include
someclass" entries per system role or hostgroup. The following works
for my environment and is not necessarily considered best practice.
For example, I might have a "generic role" that has numerous "include
someclass" entries like so:
node generic {
include autofs
include puppet
include crontab
include ntp
...
}
a typical node might look like:
node 'typical-node' inherits generic {
}
The above configuration allows me to quickly comment out modules for
my nodes.
Mark
On Mar 8, 1:55 am, Matt wrote:
> Out of interest Mark, how did you go about disabling all modules bar puppet?
>
> Matt
>
> On 8 March 2010 02:07, Mark Christian wrote:
>
> > Thanks for the suggestion. I've set storeconfigs = false, it's been a
> > couple hours and I've yet to see any "too many connections" errors.
>
> > On Mar 7, 5:47 pm, Ohad Levy wrote:
> > > Hi Mark,
>
> > > Are you using storeconfigs? I've seen the too many connections error in
> > > relationship to activerecord versions (and the lack of mysql gem
> > existence).
>
> > > In general, I would expect the load on your mongrels to be lower than
> > > 0.24.x
> > > cheers,
> > > Ohad
>
> > > On Mon, Mar 8, 2010 at 3:46 AM, Mark Christian
> > wrote:
> > > > I have updated the 1100 clients that prior to the update used to
> > > > connect to the master just fine. Now after about 30 minutes of
> > > > running, puppetmasterd starts to complain "puppetmasterd[6875]: Too
> > > > many connections", and from that point forward will stop compiling
> > > > catalogs. Puppetmaster is configured using the Mongrel Apache
> > > > configuration as described here:
> > > >http://reductivelabs.com/trac/puppet/wiki/UsingMongrel
>
> > > > In addition I've disabled all modules except for the "puppet" module
> > > > which helped push the client upgrade as well as configure the
> > > > "runinterval" from the pre-upgrade 1 hour run to a 4 hour run
> > > > interval. At this point there might be a couple dozen 24.8 clients
> > > > still attempting to connect.
>
> > > > I guess I'm wondering if I need to scrap the Mongrel config with 5
> > > > "Mongrel instances" that used to handle 1100+ clients all which had
> > > > significant configurations, or if someone has an idea outside of
> > > > implementing more puppetmasters.
>
> > > > Thank you for any insight.
>
> > > > Mark
>
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "Puppet Users" group.
> > > > To post to this group, send email to puppet-us...@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > puppet-users+unsubscr...@googlegroups.com
> >
>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/puppet-users?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Users" group.
> > To post to this group, send email to puppet-us...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > puppet-users+unsubscr...@googlegroups.com
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/puppet-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Upgraded puppet-server from EPEL 24.8 to 25.1 - now seeing "puppetmasterd[xxxx]: Too many connections"
Thanks for the suggestion. I've set storeconfigs = false, it's been a couple hours and I've yet to see any "too many connections" errors. On Mar 7, 5:47 pm, Ohad Levy wrote: > Hi Mark, > > Are you using storeconfigs? I've seen the too many connections error in > relationship to activerecord versions (and the lack of mysql gem existence). > > In general, I would expect the load on your mongrels to be lower than > 0.24.x > cheers, > Ohad > > On Mon, Mar 8, 2010 at 3:46 AM, Mark Christian wrote: > > I have updated the 1100 clients that prior to the update used to > > connect to the master just fine. Now after about 30 minutes of > > running, puppetmasterd starts to complain "puppetmasterd[6875]: Too > > many connections", and from that point forward will stop compiling > > catalogs. Puppetmaster is configured using the Mongrel Apache > > configuration as described here: > >http://reductivelabs.com/trac/puppet/wiki/UsingMongrel > > > In addition I've disabled all modules except for the "puppet" module > > which helped push the client upgrade as well as configure the > > "runinterval" from the pre-upgrade 1 hour run to a 4 hour run > > interval. At this point there might be a couple dozen 24.8 clients > > still attempting to connect. > > > I guess I'm wondering if I need to scrap the Mongrel config with 5 > > "Mongrel instances" that used to handle 1100+ clients all which had > > significant configurations, or if someone has an idea outside of > > implementing more puppetmasters. > > > Thank you for any insight. > > > Mark > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com > > . > > For more options, visit this group at > >http://groups.google.com/group/puppet-users?hl=en. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Upgraded puppet-server from EPEL 24.8 to 25.1 - now seeing "puppetmasterd[xxxx]: Too many connections"
I have updated the 1100 clients that prior to the update used to connect to the master just fine. Now after about 30 minutes of running, puppetmasterd starts to complain "puppetmasterd[6875]: Too many connections", and from that point forward will stop compiling catalogs. Puppetmaster is configured using the Mongrel Apache configuration as described here: http://reductivelabs.com/trac/puppet/wiki/UsingMongrel In addition I've disabled all modules except for the "puppet" module which helped push the client upgrade as well as configure the "runinterval" from the pre-upgrade 1 hour run to a 4 hour run interval. At this point there might be a couple dozen 24.8 clients still attempting to connect. I guess I'm wondering if I need to scrap the Mongrel config with 5 "Mongrel instances" that used to handle 1100+ clients all which had significant configurations, or if someone has an idea outside of implementing more puppetmasters. Thank you for any insight. Mark -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: SSL Makes My Brain Bleed
I am keen to get this to work, but can't seem to. Will this work with Mongrel and Apache as described at http://reductivelabs.com/trac/puppet/wiki/UsingMongrel ? Im using the EPEL puppet package versions 24.8-4 and simply can't get the client to retrieve the catalog from the "Development" server. Could not retrieve catalog: Certificates were not trusted: tlsv1 alert unknown ca The clients have all been signed by the "Production" server, I've put ca_server = myProduction.Server.com in the client's puppet.conf. Is there any more detail to add to step 5. below? Thank you. On Nov 6, 9:38 pm, Dan Bode wrote: > Hi Paul,, > > I just want to share how I have done this before. > > 1. Production server is the only certificate authority. > 2. Development server sets ca_server = false > 3. Development server calls puppetd --server production.server > 4. Development server now gets a copy of the production servers certificate > (ca.pem) > 5. Other machines must get signed by the prod server before they can call > the dev server (there is a ca_server command line argument) > > the puppet dev server ensures that any calling machines have been signed by > the production server (its ca). > > Can you try this setup and see if it resolves your issue? > > There is another thread of people discussing passenger issues. I will go > ahead and stage the passenger config with 25.1 this weekend. I will make a > post outlining my findings. > > hope this helps, > > Dan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=.
[Puppet Users] Re: is it possible to pass a node variable to file source in a class?
Thank you for taking the time to demonstrate how to implement a
template. This is exactly what I needed.
On Sep 15, 3:28 pm, Eric Heydrick wrote:
> That should work. However, a more puppetish way of doing it is using a
> template to generate ntp.conf. I'm guessing the only difference between
> your ntp.conf's is the server setting. Here's how you could do it with a
> template:
>
> in site.pp specify ntp servers for each site, e.g.:
>
> case $site {
> sj: {
> $ntpServerList = [ 'ntp1.sj', 'ntp2.sj' ]
> }
> to: {
> $ntpServerList = [ 'ntp1.to', 'ntp2.to' ]
> }
>
> }
>
> then make an ntp.conf.erb in the templates directory that contains this:
>
> <% ntpServerList.each do |ntpServer| -%>
> server <%= ntpServer %>
> <% end -%>
>
> then in your manifest:
>
> file { "/etc/ntp.conf":
> content => template("ntp/ntp.conf.erb"),
>
> }
>
> This way you have only one file to edit to change site-specific setings.
>
> In our environment we have a function in site.pp that determines $site
> based on fqdn.
>
> -Eric
>
> On Tue, 15 Sep 2009, Mark Christian wrote:
>
> > Following the example in the CommonMisconceptions I've done away with
> > the inherits "base_node" and have instead included the class base_node
> > and can now successfully pass my $site variable. However I can't seem
> > to include the variable in the "source" parameter for "file" type.
>
> > For now I'm using this:
>
> > file { "/etc/ntp.conf":
> > owner => root,
> > group => root,
> > mode => 0644,
> > source => $site ? {
> > "sj" => "puppet:///ntp/SJ/ntp.conf",
> > "to" => "puppet:///ntp/TO/ntp.conf",
> > "uk" => "puppet:///ntp/UK/ntp.conf",
> > "pg" => "puppet:///ntp/PG/ntp.conf",
> > default => "puppet:///ntp/ntp.conf",
> > },
> > notify => Service[ntpd],
> > require => Package["ntp"],
> > }
>
> > I was just hoping I could use this instead:
>
> > source => "puppet:///ntp/$site/ntp.conf"
>
> > On Sep 15, 12:45 pm, Silviu Paragina wrote:
> > > I thinks you are in the case explained
> > > herehttp://reductivelabs.com/trac/puppet/wiki/CommonMisconceptions
>
> > > Silviu
>
> > > Mark Christian wrote:
> > > > say I have a couple nodes:
>
> > > > node 'uk-host' inherits basenode {
> > > > $site = "UK"
> > > > }
> > > > node 'ap-host' inherits basenode {
> > > > $site = "AP"
> > > > }
>
> > > > Is it possible to pass the $site variable to the file resource source
> > > > parameter?:
>
> > > > class ntp {
>
> > > > package { ntp: ensure => installed }
>
> > > > file { "/etc/ntp.conf":
> > > > owner => root,
> > > > group => root,
> > > > mode => 0644,
> > > > source => "puppet:///ntp/$site/ntp.conf", # $modulepath/ntp/
> > > > files/{AP,UK}/ntp.conf
> > > > source => "puppet:///ntp/ntp.conf",
> > > > notify => Service[ntpd],
> > > > require => Package["ntp"],
> > > > }
>
> > > > service { ntpd:
> > > > name => "ntpd",
> > > > enable => true,
> > > > hasstatus => true,
> > > > hasrestart => true,
> > > > ensure => running,
> > > > require => Package["ntp"],
> > > > }
> > > > }
>
> > > > The above does not appear to work. Am I simply misguided and should I
> > > > be trying something else? Thank you.
>
> > > > Mark
--~--~-~--~~~---~--~~
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: is it possible to pass a node variable to file source in a class?
Following the example in the CommonMisconceptions I've done away with
the inherits "base_node" and have instead included the class base_node
and can now successfully pass my $site variable. However I can't seem
to include the variable in the "source" parameter for "file" type.
For now I'm using this:
file { "/etc/ntp.conf":
owner => root,
group => root,
mode=> 0644,
source => $site ? {
"sj"=> "puppet:///ntp/SJ/ntp.conf",
"to"=> "puppet:///ntp/TO/ntp.conf",
"uk"=> "puppet:///ntp/UK/ntp.conf",
"pg"=> "puppet:///ntp/PG/ntp.conf",
default => "puppet:///ntp/ntp.conf",
},
notify => Service[ntpd],
require => Package["ntp"],
}
I was just hoping I could use this instead:
source => "puppet:///ntp/$site/ntp.conf"
On Sep 15, 12:45 pm, Silviu Paragina wrote:
> I thinks you are in the case explained
> herehttp://reductivelabs.com/trac/puppet/wiki/CommonMisconceptions
>
> Silviu
>
> Mark Christian wrote:
> > say I have a couple nodes:
>
> > node 'uk-host' inherits basenode {
> > $site = "UK"
> > }
> > node 'ap-host' inherits basenode {
> > $site = "AP"
> > }
>
> > Is it possible to pass the $site variable to the file resource source
> > parameter?:
>
> > class ntp {
>
> > package { ntp: ensure => installed }
>
> > file { "/etc/ntp.conf":
> > owner => root,
> > group => root,
> > mode => 0644,
> > source => "puppet:///ntp/$site/ntp.conf", # $modulepath/ntp/
> > files/{AP,UK}/ntp.conf
> > source => "puppet:///ntp/ntp.conf",
> > notify => Service[ntpd],
> > require => Package["ntp"],
> > }
>
> > service { ntpd:
> > name => "ntpd",
> > enable => true,
> > hasstatus => true,
> > hasrestart => true,
> > ensure => running,
> > require => Package["ntp"],
> > }
> > }
>
> > The above does not appear to work. Am I simply misguided and should I
> > be trying something else? Thank you.
>
> > Mark
--~--~-~--~~~---~--~~
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] is it possible to pass a node variable to file source in a class?
say I have a couple nodes:
node 'uk-host' inherits basenode {
$site = "UK"
}
node 'ap-host' inherits basenode {
$site = "AP"
}
Is it possible to pass the $site variable to the file resource source
parameter?:
class ntp {
package { ntp: ensure => installed }
file { "/etc/ntp.conf":
owner => root,
group => root,
mode=> 0644,
source => "puppet:///ntp/$site/ntp.conf", # $modulepath/ntp/
files/{AP,UK}/ntp.conf
source => "puppet:///ntp/ntp.conf",
notify => Service[ntpd],
require => Package["ntp"],
}
service { ntpd:
name=> "ntpd",
enable => true,
hasstatus => true,
hasrestart => true,
ensure => running,
require => Package["ntp"],
}
}
The above does not appear to work. Am I simply misguided and should I
be trying something else? Thank you.
Mark
--~--~-~--~~~---~--~~
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] snmpd v3 class help - need to stop service before copying file and then restart
The problem I have is that I need to ensure that snmpd is stopped
before attempting to copy /var/net-snmp/snmpd.conf (snmpd credentials
file that gets corrupted if copied while snmpd is running). Any
suggestions on how best to proceed?
# what I have so far.
class snmpd {
package { net-snmp: ensure => installed }
file { "/etc/snmp/snmpd.conf":
owner => root,
group => root,
mode=> 0644,
source => "puppet:///snmpd/snmp.conf",
require => Package[net-snmp],
notify => Service[snmpd],
}
file { "/var/net-snmp/snmpd.conf":
owner => root,
group => root,
mode=> 0600,
source => "puppet:///snmpd/net-snmpd.conf",
require => Package[net-snmp],
notify => Service[snmpd],
}
service { snmpd:
enable => true,
hasrestart => true,
ensure => running,
require => Package[$autofs_packages],
}
Thank you.
Mark
--~--~-~--~~~---~--~~
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] need assistance with autofs5 reload across rhel5/rhel4 hosts
I’m trying to manage autofs5 on RHEL4 and RHEL5 hosts and would like
to reload /etc/auto.master rather than restart.
The following class errors out with “Could not retrieve catalog:
Syntax error at '.'; expected '}' at /etc/puppet/modules/autofs/
manifests/init.pp:4 on node somenode” when I attempt to process it.
class autofs {
case $kernelversion {
2.6.9: { $autofs_packages = ["autofs", "autofs5"] }
default: { $autofs_packages = ["autofs"] }
}
exec { "reload":
command => $kernelversion ? {
2.6.9 => "/etc/init.d/autofs5 reload",
default => "/etc/init.d/autofs reload",
},
refreshonly => true,
require => Package[$autofs_packages],
}
package { $autofs_packages: ensure => installed }
file { "/etc/auto.master":
owner => root,
group => root,
mode=> 0644,
source => "puppet:///autofs/auto.master",
require => Package[$autofs_packages],
notify => Exec[$reload]
}
}
Mark
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
