[Puppet Users] puppet 2.6.5-rc1 Parameter type failed: type is read-only
Hello All Well, I quickly packaged up puppet-2.6.5-rc1 and dropped it on my test VM (Solaris 10 U9) against my 2.6.4 server, and immediately started getting the same error message, but on different manifests, or the same manifests but different line numbers. These manifests were written in 0.25.5 days and successfully made the transition to 2.6.4 running on a couple of hundred servers John root@warbjohn# /opt/local/sbin/run-puppet.sh --color true + /opt/local/sbin/puppetd --server puppet-lab.bfm.com --verbose --onetime --no-daemonize --ignorecache --no-usecacheonfailure --config /var/puppet/etc/puppetd.conf --environment Lwarbjoh --logdest /var/log/puppet_client/puppet_client.log --color true err: Could not run Puppet configuration client: Parameter type failed: type is read-only at /u1/warbjoh/svn-workspace/puppet/trunk/modules/base/manifests/openssh.pp:44 root@warbjohn# /opt/local/sbin/run-puppet.sh --color true + /opt/local/sbin/puppetd --server puppet-lab.bfm.com --verbose --onetime --no-daemonize --ignorecache --no-usecacheonfailure --config /var/puppet/etc/puppetd.conf --environment Lwarbjoh --logdest /var/log/puppet_client/puppet_client.log --color true err: Could not run Puppet configuration client: Parameter type failed: type is read-only at /u1/warbjoh/svn-workspace/puppet/trunk/modules/base/manifests/openssh.pp:54 root@warbjohn# /opt/local/sbin/run-puppet.sh --color true + /opt/local/sbin/puppetd --server puppet-lab.bfm.com --verbose --onetime --no-daemonize --ignorecache --no-usecacheonfailure --config /var/puppet/etc/puppetd.conf --environment Lwarbjoh --logdest /var/log/puppet_client/puppet_client.log --color true err: Could not run Puppet configuration client: Parameter type failed: type is read-only at /u1/warbjoh/svn-workspace/puppet/trunk/modules/base/manifests/init.pp:111 root@warbjohn# /opt/local/sbin/run-puppet.sh --color true --trace + /opt/local/sbin/puppetd --server puppet-lab.bfm.com --verbose --onetime --no-daemonize --ignorecache --no-usecacheonfailure --config /var/puppet/etc/puppetd.conf --environment Lwarbjoh --logdest /var/log/puppet_client/puppet_client.log --color true --trace info: Retrieving plugin info: Loading facts in cyberark_init info: Loading facts in pkgs_facts info: Loading facts in svcs_facts info: Loading facts in serialnumber info: Loading facts in solaris_memory info: Loading facts in cyberark_init info: Loading facts in pkgs_facts info: Loading facts in svcs_facts info: Loading facts in serialnumber info: Loading facts in solaris_memory info: Caching catalog for warbjohn.insidelive.net /opt/local/lib/puppet/parameter.rb:171:in `fail' /opt/local/lib/puppet/type/file/type.rb:15:in `unsafe_validate' /opt/local/lib/puppet/parameter.rb:255:in `validate' /opt/local/lib/puppet/property.rb:300:in `should=' /opt/local/lib/puppet/property.rb:300:in `each' /opt/local/lib/puppet/property.rb:300:in `should=' /opt/local/lib/puppet/property.rb:337:in `value=' /opt/local/lib/puppet/type.rb:416:in `[]=' /opt/local/lib/puppet/type.rb:1773:in `set_parameters' /opt/local/lib/puppet/type.rb:1767:in `each' /opt/local/lib/puppet/type.rb:1767:in `set_parameters' /opt/local/lib/puppet/type.rb:1749:in `initialize' /opt/local/lib/puppet/type/file.rb:387:in `initialize' /opt/local/lib/puppet/resource.rb:277:in `new' /opt/local/lib/puppet/resource.rb:277:in `to_ral' /opt/local/lib/puppet/resource/catalog.rb:553:in `send' /opt/local/lib/puppet/resource/catalog.rb:553:in `to_catalog' /opt/local/lib/puppet/resource/catalog.rb:531:in `each' /opt/local/lib/puppet/resource/catalog.rb:531:in `to_catalog' /opt/local/lib/puppet/resource/catalog.rb:468:in `to_ral' /opt/local/lib/puppet/configurer.rb:113:in `convert_catalog' /opt/local/lib/puppet/configurer.rb:108:in `retrieve_catalog' /opt/local/lib/puppet/configurer.rb:139:in `run' /opt/local/lib/puppet/agent.rb:39 /opt/local/lib/puppet/agent/locker.rb:21:in `lock' /opt/local/lib/puppet/agent.rb:39 /opt/local/pkgs/ruby-1.8.7-p249/lib/ruby/1.8/sync.rb:230:in `synchronize' /opt/local/lib/puppet/agent.rb:39 /opt/local/lib/puppet/agent.rb:103:in `with_client' /opt/local/lib/puppet/agent.rb:37 /opt/local/lib/puppet/application.rb:171:in `call' /opt/local/lib/puppet/application.rb:171:in `controlled_run' /opt/local/lib/puppet/agent.rb:35:in `run' /opt/local/lib/puppet/application/agent.rb:114:in `onetime' /opt/local/lib/puppet/application/agent.rb:88:in `run_command' /opt/local/lib/puppet/application.rb:304:in `run' /opt/local/lib/puppet/application.rb:410:in `exit_on_fail' /opt/local/lib/puppet/application.rb:304:in `run' /opt/local/sbin/puppetd:4 err: Could not run Puppet configuration client: Parameter type failed: type is read-only at /u1/warbjoh/svn-workspace/puppet/trunk/modules/base/manifests/openssh.pp:44 -- 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] Re: Fwd: [Puppet-dev] ANNOUNCE: Puppet 2.6.5 - Release Candidate 1 available!
On Feb 4, 12:00 am, Jacob Helwig ja...@puppetlabs.com wrote: - Forwarded message from Nick Lewis n...@puppetlabs.com - essage-ID: aanlktikjfwz98p_ncxf54zhbu2mjf15xdrlg2cmp2...@mail.gmail.com We're back with a maintenance release: 2.6.5. This release addresses a number of bugs in the 2.6.x branch. 2.6.5 is a maintenance release in the 2.6.x branch and it contains only bug fixes, documentation updates and a small handful of features. [...] License is now GPLv2 Previous versions of Puppet were licensed as GPL version 2 or greater; the license is now specified as GPL version 2. The license change is not a serious problem for me, but I'm curious: what is the reason for this change? Does PuppetLabs see a problem with GPLv3? 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.
[Puppet Users] Puppet CA Inventory and Serial # file... unique format?
I'm working on a system for auto-resigning certificates for our clients and Iv'e basically got it working .. but I notice that Puppet uses an inventory file and a serial # file that seem to be differently formatted than the openssl toolkit uses? The serial number file that puppet generates has a 4 digit number starting with ... but openssl tracks its serial numbers in a hex format (0C, for example). The inventory files are also not compatible I found. Can anyone explain why this is? It makes it harder to use these two different tools with the same serial, inventory and CA files... —Matt (example inventory files below) puppet: 0x0007 2011-02-06T14:17:23GMT 2011-02-08T14:17:23GMT /CN=master102.dc1.xxx.com 0x0008 2011-02-06T14:17:28GMT 2011-02-08T14:17:28GMT /CN=master103.dc1.xxx.com openssl: V 110209142816Z 09 unknown /CN=master101.dc1.xxx.com V 110209150001Z 0A unknown /CN=master102.dc1.xxx.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] Re: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
Because I like to live dangerously I upgraded to 2.6.5 and it seems like this has resolved the CPU problem completely for me. On Tue, Feb 1, 2011 at 3:17 PM, Udo Waechter udo.waech...@uni-osnabrueck.de wrote: On 01.02.2011, at 18:14, Brice Figureau wrote: On Tue, 2011-02-01 at 10:30 -0500, Ashley Penney wrote: This is the crux of the situation for me too - Puppetlabs blame it on a Ruby bug that hasn't been resolved with RHEL6 (in my situation) but this wasn't an issue until .3 for me too. I feel that fact that many of us have this problem since upgrading means it can be fixed within Puppet, rather than Ruby, because it was fine before. Do you mean puppet 2.6.2 wasn't exhibiting this problem? Yes for me. --udo. -- :: udo waechter - r...@zoide.net :: N 52º16'30.5 E 8º3'10.1 :: genuine input for your ears: http://auriculabovinari.de :: your eyes: http://ezag.zoide.net :: your brain: http://zoide.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. -- 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] Specifying owners/groups in puppet.conf
Hi,
this puppet.conf (excerpted):
[main]
logdir=/var/log/puppet { owner = ffrank, mode = 755 }
is supposed to change the owner of the logdir but won't:
# puppet master --no-daemonize --color false --masterport 8145
--pidfile=/var/run/puppet/master.debug.pid
/usr/lib/ruby/1.8/puppet/util/settings/file_setting.rb:33:in `owner=':
Internal error: The :owner setting for The Puppet log directory.:
logdir: $vardir/log must be either 'root' or 'service', not 'ffrank'
(Puppet::Util::Settings::FileSetting::SettingError)
Quoting my user name leads to a parse error.
The proposed service setting will do me no good - I'd like to specify
a distinct user (or rather, a group, but that's apparently the same
scenario) owning the logdir, not the puppet user. (Same goes for reportdir.)
Is this possible at all?
Thanks in advance,
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.
[Puppet Users] freebsd rc.conf type - looking for beta testers
While working on a bunch of freebsd servers, one feature that I found lacking was the ability to nicely modify rc.conf variables (eg: item_flags=--something) for installed ports/applications and have a service do dependency checking so it restarts if it changes. So a wrote a new puppet type (rcconf) to specifically handle this. It's got a single provider at the moment, which uses the sysrc script (available at http://druidbsd.sourceforge.net/) to do key/value modifications. BTW: it's a nice script I'd recommend freebsd admins get anyways. I've placed the code for the new type at: https://github.com/westr/westr-puppet-extras/tree/master/freebsd/rcconf If anyone wants to download and test, that would be appreciated. Please note this is definitely what I'd call beta software that's only been tested with Puppet v2.6.x Simple documentation is in the README file in the directory. R. -- 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: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
On 07/02/11 17:23, Ashley Penney wrote: Because I like to live dangerously I upgraded to 2.6.5 and it seems like this has resolved the CPU problem completely for me. Did you upgrade the master or the master and all the nodes? I had a discussion about this issue with Nigel during the week-end, and he said something really interesting I didn't thought about: it might be possible that the reports generated by 2.6.3 were larger than what they were in previous versions. It is then possible that the CPU time taken to unserialize and process those larger reports is the root cause of the high CPU usage. That'd be great if one of the people having the problem could disable reports to see if that's the culprit. And if this is the case, we should at least log how long it takes to process a report on the master. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- 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] Two file mode bugs in puppet 0.25?
Did you ever files these bugs in the tracker?
On Feb 1, 2011, at 7:35 PM, Barry Jaspan wrote:
I'm using puppet 0.25.5 and just discovered two file resource bugs. I suspect
the bugs did not exist in 0.24 because the code were using that triggers them
has been the same for a long time and while it is possible we did not notice
the problem earlier, it seems unlikely as it has been triggering failures in
our automated system tests since around the time we upgraded.
Anyway, here's the bug. In our site.pp, we have
File {
mode = 400,
}
These two resources
file { /mnt/www:
ensure = directory,
mode = 755,
}
file { /var/www:
require = File[/mnt/www],
ensure = /mnt/www,
}
result in /mnt/www being created as mode 400. My guess is that /mnt/www is
being created with mode 755 as requested, then /var/www is being created as a
symlink to /mnt/www and then (because 400 is the default mode for all file
resources) it is being chmod'ed to mode 400, which chmod's the referenced
directory. Since the file resource is creating a symlink the correct behavior
would be to call lchmod()... except Linux has no lchmod(), all symlinks in
Linux are effectively mode 777. So puppet should in fact not call chmod() on
symlinks at all on Linux. Two other things I've observed:
* Putting mode = 755 into the second file resource fixes the problem; this
must make puppet call chmod(755) on the symlink, which changes the
directory to its current value.
* /mnt/www's mode is fixed on the second puppet run; the File[/mnt/www]
notices the mode is wrong and fixes it, and I guess the File[/var/www]
symlink resource does not try to change the mode on symlinks.
In a somewhat related issue, we also have this code:
file { /usr/src/php:
ensure = directory,
}
This results in /usr/src/php being created as mode 400. One could argue this
is not a bug since 400 is the default mode. However on its second run puppet
changes the mode on this dir to 500. So either the initial mode or the later
change is clearly a bug. :-)
I haven't tried to track down these behaviors in puppet's source and do not
know if they are fixed in 0.26.
Thanks,
Barry
--
Barry Jaspan
Senior Architect | Acquia
barry.jas...@acquia.com | (c) 617.905.2208 | (w) 978.296.5231
Get a free, hosted Drupal 7 site: http://www.drupalgardens.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.
--
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: puppetmaster 100%cpu usage on 2.6 (not on 0.24)
I just upgraded the master, I was too lazy to do the nodes yet. On Mon, Feb 7, 2011 at 1:56 PM, Brice Figureau brice-pup...@daysofwonder.com wrote: On 07/02/11 17:23, Ashley Penney wrote: Because I like to live dangerously I upgraded to 2.6.5 and it seems like this has resolved the CPU problem completely for me. Did you upgrade the master or the master and all the nodes? I had a discussion about this issue with Nigel during the week-end, and he said something really interesting I didn't thought about: it might be possible that the reports generated by 2.6.3 were larger than what they were in previous versions. It is then possible that the CPU time taken to unserialize and process those larger reports is the root cause of the high CPU usage. That'd be great if one of the people having the problem could disable reports to see if that's the culprit. And if this is the case, we should at least log how long it takes to process a report on the master. -- Brice Figureau My Blog: http://www.masterzen.fr/ -- 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] How should I use puppetdoc?
I'm having a bit of trouble figuring out the best way to do my puppetdoc stuff. I hope to have actual tutorial introductory chapter type documentation as well as individual module documentation, but it seems like all the examples I can find merely re-state the parameters that puppetdoc already noted. I'm trying to find a good whole-tree example for this, and all the examples I've been shown tend to be either a single .pp file and its output (oh boy! One .pp file can become a hideous tangled mess of frames and three-lines-of-text-per-page HTML!) or a vague hand-wave toward rdoc and instructions to go read the sourceforge (wow are they still around?) pages on rdoc. I saw someone say that it was good at finding README files, but: puppetdoc --all --mode rdoc --modulepath ./modules/ --manifestdir ./manifests/ ...was unable to find ./manifests/README or ./manifests/README.rdoc or any other common combination. I tried using the :include: directive at this point, but it didn't seem to have the effect I expected. I'm a little confused by http://projects.puppetlabs.com/projects/1/wiki/Puppet_Manifest_Documentation which seems to suggest that my puppetdoc comments need to immediately precede a class. Is that a hard and fast rule? Can I not puppetdoc a node or an individual resource? Can I not create structure in addition to that provided by the manifests themselves? Is this simply the wrong tool for my needs? I was hoping for something a bit more useful than just generate reams of API printouts for the mandatory documentation binder software, but I'm getting worried that that's exactly what this is. I want to build tutorial documentation as well as reference, but there appears to be a very heavy reference bias in the output I'm seeing. I'd greatly appreciate any pointers to example manifest trees that make effective use of puppetdoc! -- If you carefully examine the intercal package (which was not available for a month despite emails about it being a 404), you will discover that . is in ESR's PATH. -- Joey Hess -- 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] How should I use puppetdoc?
Hi,
First, I'm sorry to hear you have any issues with puppetdoc (and before
you ask yourself why I started like this, I wrote the tool :).
On 07/02/11 20:19, Nick Moffitt wrote:
I'm having a bit of trouble figuring out the best way to do my puppetdoc
stuff. I hope to have actual tutorial introductory chapter type
documentation as well as individual module documentation, but it seems
like all the examples I can find merely re-state the parameters that
puppetdoc already noted.
I'm trying to find a good whole-tree example for this, and all the
examples I've been shown tend to be either a single .pp file and its
output (oh boy! One .pp file can become a hideous tangled mess of
frames and three-lines-of-text-per-page HTML!) or a vague hand-wave
toward rdoc and instructions to go read the sourceforge (wow are they
still around?) pages on rdoc.
I would recommend having a look to Lab42 modules on Puppet Forge (or
github). Alessandro did an amazing job at commenting properly his
modules to work with puppetdoc.
I saw someone say that it was good at finding README files, but:
puppetdoc --all --mode rdoc --modulepath ./modules/ --manifestdir
./manifests/
Assuming you have modules in ./modules/ and manifests in ./manifests/,
then puppetdoc will generate an html tree in ./doc containing all your
nodes, classes and modules (and in your case resources).
...was unable to find ./manifests/README or ./manifests/README.rdoc or
any other common combination. I tried using the :include: directive at
this point, but it didn't seem to have the effect I expected.
Puppetdoc doesn't support a global manifests/README file.
It is only able to extract documentations from your comments embedded in
your actual manifests.
It is able, though, to use modules/mymodule/README as the cover for your
modules.
In any case adding --debug to your command line will show you what
puppetdoc parsed and understood.
Note that running with --all as you were doing, means that puppetdoc
will reference every found resources.
I'm a little confused by
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Manifest_Documentation
which seems to suggest that my puppetdoc comments need to immediately
precede a class. Is that a hard and fast rule?
This is a hard rule in the sense that there shouldn't be a single blank
line between the comment and the puppet entity (be it a class, node,
resource...).
Ex:
# My super definition
# Use like this:
# my_super_definition { test: }
#
define my_super_definition() {
...
}
will work, but if you add a blank line between the comment and the
define keyword, puppetdoc will lose the comment.
Can I not puppetdoc a
node or an individual resource? Can I not create structure in addition
to that provided by the manifests themselves?
Puppetdoc generates the structure for you by understanding how your
classes fit, how your modules are layed out and used.
Is this simply the wrong tool for my needs? I was hoping for something
a bit more useful than just generate reams of API printouts for the
mandatory documentation binder software, but I'm getting worried that
that's exactly what this is. I want to build tutorial documentation as
well as reference, but there appears to be a very heavy reference bias
in the output I'm seeing.
Yes, this is a tool to produce the reference manual for your modules.
I don't think any automatic tool can produce the kind of documentation
you're trying to achieve, but if you can prove me wrong (especially in
the form of a patch or good suggestions that would be awesome).
If you follow the best practice to encapsulate your puppet code in
classes and modules, then I think puppetdoc can be a really good tool
(and you don't need the --all parameter in this case).
In any case, what is produced is a bunch of html files, which means you
can do whatever post-processing you want to them. If you just need to
include some static html files on top of this, then nothing prevents you
to do so :)
I'd greatly appreciate any pointers to example manifest trees that make
effective use of puppetdoc!
Hope that helped,
--
Brice Figureau
My Blog: http://www.masterzen.fr/
--
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] define yum baseurl
hello puppet list!
I am having some difficulty setting the correct baseurl setting for a
yum repo I am attempting to include in my puppet config.
Here is the error I am getting when I run puppetd --test
[root@VIRTCENT02:/etc/yum.repos.d] #puppetd --test
info: Caching catalog for virtcent02.summitnjhome.com
info: Applying configuration version '1297108455'
err: //baseapps/Package[koan]/ensure: change from absent to present
failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install koan' returned
1: Error: Cannot retrieve repository metadata (repomd.xml) for
repository: epel-repo. Please verify its path and try again
notice: //centos/Yumrepo[epel-repo]/baseurl: baseurl changed
'http://mirrors.fedoraproject.org/5.5' to
'http://download.fedoraproject.org/pub/epel/5/'
notice: Finished catalog run in 1.52 seconds
And this is how I have the yumrepo defined:
class centos {
yumrepo { epel-repo:
baseurl = http://download.fedoraproject.org/pub/epel/5/$basearch;,
descr = Epel Repo,
enabled = 1,
gpgcheck = 0,
}
}
any advice I could get on how to correctly format this url would be
greatly appreciated!
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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] define yum baseurl
Did you escape the $basearch with a back-slash in your manifest?
baseurl = http://download.fedoraproject.org/pub/epel/5/\$basearch;,
-Mark
On Feb 7, 2011, at 2:57 PM, Tim Dunphy wrote:
hello puppet list!
I am having some difficulty setting the correct baseurl setting for a
yum repo I am attempting to include in my puppet config.
Here is the error I am getting when I run puppetd --test
[root@VIRTCENT02:/etc/yum.repos.d] #puppetd --test
info: Caching catalog for virtcent02.summitnjhome.com
info: Applying configuration version '1297108455'
err: //baseapps/Package[koan]/ensure: change from absent to present
failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install koan' returned
1: Error: Cannot retrieve repository metadata (repomd.xml) for
repository: epel-repo. Please verify its path and try again
notice: //centos/Yumrepo[epel-repo]/baseurl: baseurl changed
'http://mirrors.fedoraproject.org/5.5' to
'http://download.fedoraproject.org/pub/epel/5/'
notice: Finished catalog run in 1.52 seconds
And this is how I have the yumrepo defined:
class centos {
yumrepo { epel-repo:
baseurl = http://download.fedoraproject.org/pub/epel/5/$basearch;,
descr = Epel Repo,
enabled = 1,
gpgcheck = 0,
}
}
any advice I could get on how to correctly format this url would be
greatly appreciated!
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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] using facts_terminus breaks puppet 2.6.5rc1
I've got a 4-server puppetmaster farm setup.. one server (master100) is the ca master, all the others are just compile-time hosts. I was experimenting with the facts_terminus = rest options and the inventory service, and found that as soon as I turned on facts_terminus = rest on say master101, then master102 could not retrieve its config from master101. Only from master 100. This is the error I received: debug: catalog supports formats: b64_zlib_yaml dot marshal pson raw yaml; using pson err: Could not retrieve catalog from remote server: Error 400 on SERVER: certificate verify failed warning: Not using cache on failed catalog As soon as I got rid of the facts_terminus line, all of the masters could talk to eachother just fine. Bug? Feature? —Matt -- 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] returning a hash (json object) from custom function?
We have a command line utility that queries a database to get certain
facts about our hosts -- I wanted to write a custom function to obtain
all of those facts at once. The tool outputs JSON and I wanted to
take that output and return a hash back into puppet where I could
access the facts like...
$a = host_info()
if $a['in_maintenance'] == 'yes' {
} ...
etc, etc.
Right now I'm getting:
can't convert Array into String at ... Which I assume means that
puppet is expecting a string back from the custom function.
Maybe I just need to make a fact out of these instead and prefix them
with foo_in_maintenance, etc., etc., etc., but I'd really rather use
structured data.
--
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: returning a hash (json object) from custom function?
Ok, I was mistaken. Returning a hash works. It would be helpful if
the ruby exceptions bubbled up to puppet reported the correct line
number from the ruby source -- if that is possible.
Rich
On Mon, Feb 7, 2011 at 4:18 PM, Rich Rauenzahn rraue...@gmail.com wrote:
We have a command line utility that queries a database to get certain
facts about our hosts -- I wanted to write a custom function to obtain
all of those facts at once. The tool outputs JSON and I wanted to
take that output and return a hash back into puppet where I could
access the facts like...
$a = host_info()
if $a['in_maintenance'] == 'yes' {
} ...
--
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] can we choose which inteface defines the $ipaddress fact?
Hi, I've run into some bug today with nagios checks that are exported in a client's puppet setup. The problem is that some host definitions are exported with an internal address (10.x or 192.168.x) even though the servers do have an external IP on another interface. One of those uses a tap inteface to bridge traffic, and another has a virtual interface that is used for a vlan. In all cases, the interface with an internal IP comes up higher in the output of ifconfig, and this makes the fact ipaddress take it as its value. Is there a way to force facter to chose a specific interface for the ipaddress value? -- 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.
[Puppet Users] multiple yum repos in manifest
hello puppet!!
I am attempting to install multiple yum repos in one of my manifests,
but am expressing this incorrectly (and hopefully only slightly)...
how may I express this idea appropriately in puppet?
class centos {
yumrepo { epel-repo:
baseurl = http://download.fedoraproject.org/pub/epel/5/\$basearch;,
descr = Epel Repo,
enabled = 1,
gpgcheck = 0,
}
yumrepo { remi-repo:
baseurl = http://rpms.famillecollet.com/enterprise/5/remi/\$basearch/;,
descr = Les RPM de remi pour Enterprise Linux 5,
enabled = 1,
gpgcheck = 0,
}
}
thanks and best!!!
--
GPG me!!
gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
--
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] can we choose which inteface defines the $ipaddress fact?
On Feb 7, 2011, at 6:14 PM, Gabriel Filion wrote: Hi, I've run into some bug today with nagios checks that are exported in a client's puppet setup. The problem is that some host definitions are exported with an internal address (10.x or 192.168.x) even though the servers do have an external IP on another interface. One of those uses a tap inteface to bridge traffic, and another has a virtual interface that is used for a vlan. In all cases, the interface with an internal IP comes up higher in the output of ifconfig, and this makes the fact ipaddress take it as its value. Is there a way to force facter to chose a specific interface for the ipaddress value? Yes and no. Try running facter | grep ipaddress on the client. This will give you the names of variables you should be using instead that are listed by interface. -- 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] freebsd rc.conf type - looking for beta testers
On Mon, Feb 07, 2011 at 12:30:29PM -0500, Ross W wrote: While working on a bunch of freebsd servers, one feature that I found lacking was the ability to nicely modify rc.conf variables (eg: item_flags=--something) for installed ports/applications and have a service do dependency checking so it restarts if it changes. So a wrote a new puppet type (rcconf) to specifically handle this. It's got a single provider at the moment, which uses the sysrc script (available at http://druidbsd.sourceforge.net/) to do key/value modifications. BTW: it's a nice script I'd recommend freebsd admins get anyways. I've placed the code for the new type at: https://github.com/westr/westr-puppet-extras/tree/master/freebsd/rcconf If anyone wants to download and test, that would be appreciated. Please note this is definitely what I'd call beta software that's only been tested with Puppet v2.6.x Simple documentation is in the README file in the directory. R. Hi Ross, I had a short look at you code and I dont know if this is intentional but I think you dont use instances in the way it was meant to be. It shouldn't return an array of hashes but an array of providers. So instead of keysall keyin.dup you'll do instances new(keyin) If you call providerclass.new(a_hash) all items in a_hash will be put in the property_hash of the provider instance. Prefetch will become def self.prefetch(userkeys) instances.each do |provider| if matchresource = userkeys[provider.name] # resource object to be configured. matchresource.provider = provider end # if end # eachloop end This way, purging your resource with the resource type should work and I guess even »puppet resource rcconf« should work. If you think you can trust your prefetched values during a puppetrun (e.g. no installed package will change the prefetched value) you can even reduce a few methods. def exists? get(:ensure) != :absent end def value get(:value) end get will return the value in the property_hash. If it is not stored in the property_hash it will return :absent. -Stefan pgpVsS5DmIAOl.pgp Description: PGP signature
