Re: [Puppet Users] in-module data with hiera
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/30/2012 05:01 PM, Ashley Penney wrote: > This is -exactly- what I've wanted in my modules since I heard of > Hiera and I am strongly supporting this proposal. I'll be > experimenting with your gem. I can't give this enough support as > this is what I wanted since Hiera began. It'll make supporting > multiple distros/operating systems much easier for modules on the > forge. +1. Nice idea! ~pete -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBqkw0ACgkQbwltcAfKi398AACbBbGxDdWcpHBySXCSUY++yydb D4cAn318SEhFYPqjyKymaH45vKYUzxvi =3lWJ -END PGP SIGNATURE- -- 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] sharing a storeconfigs db between masters (across versions)
On 2012-10-02 02:46, David Schmitt wrote: > On 01.10.2012 23:11, Gabriel Filion wrote: >> On 2012-09-29 16:42, Gabriel Filion wrote: >>> From what I understand of storeconfigs, it is possible to plug both >>> puppetmasters on the same MySQL db. Are there any possibilities of >>> issues with having two puppetmasters with *different versions* hit on >>> the same db ? >> >> FYI I ran a test run and got my answer. It is *not* a good idea :P >> >> the 2.6 client run on the 2.6 master got the following error: >> >> err: Could not run Puppet configuration client: Parameter require >> failed: No title provided and "#" is not a >> valid resource reference >> >> and after that, the storeconfigs DB was screwed up on the 0.25.4 master. >> clients kept getting the following error: >> >> err: Could not retrieve catalog from remote server: Error 400 on SERVER: >> Could not render to pson: undefined method `title' for nil:NilClass >> >> dropped the db and restored the dump I had made before the test and >> client runs started working again against the 0.25.4 master. >> > > You should be able to run 0.25 clients against a 2.6 master. I tried the other way around :) actually the case was a bit more perverted. it was a 2.6 client against a 2.6 master, but I had configured the 2.6 master to poke around the same MySQL database than the 0.25 master uses for the storeconfigs. It proved out to mess up the database and prevent client runs :\ -- 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] Custom ruby gem continuously updates
Considering the source you have seems to have a version in it already
have you tried it without the version number in the name?
as in
package { "sapnwrfc":
ensure => 'installed',
provider => 'gem',
source => "/export/admin_scripts/sapnwrfc-0.24",
}
On 2 October 2012 06:51, jmadtech wrote:
> The gem is there and installed. I didn't install it by hand, so it did get
> installed by puppet at some point. I'm assuming it's because the gem source
> file is local so it has no way to verify the file version versus the
> installed version.
>
>
> On Monday, October 1, 2012 4:42:46 PM UTC-4, Pete wrote:
>>
>> Does it actually install?
>> I find if package resources try to install on each run it means they
>> don't get installed correctly.
>>
>> On 28 September 2012 13:22, jmadtech wrote:
>> > Hey all,
>> >
>> > I'm not sure if there's a real issue or if I'm doing something
>> > incorrectly.
>> >
>> > I have a custom compiled gem that I'm installing via:
>> >
>> > package { "sapnwrfc-0.24":
>> > ensure => 'installed',
>> > provider => 'gem',
>> > source => "/export/admin_scripts/sapnwrfc-0.24",
>> > }
>> >
>> > On first run, it installs correctly. A 'gem list' shows it as:
>> >
>> > sapnwrfc (0.24 x86_64-linux)
>> >
>> > However, every subsequent checkin with the master results in:
>> >
>> > Thu Sep 27 20:07:34 -0700 2012 Puppet (notice): Starting Puppet client
>> > version 2.7.19
>> > Thu Sep 27 20:07:49 -0700 2012
>> > /Stage[main]/my_app/Package[sapnwrfc-0.24]/ensure (notice): created
>> > Thu Sep 27 20:07:53 -0700 2012 Puppet (notice): Finished catalog run in
>> > 12.90 seconds
>> >
>> > I've tried changing the ensure from 'installed' to '0.24', '0.24
>> > x86_64-linux', etc. to no avail... it keeps registering a change.
>> >
>> > what am I doing wrong?
>> >
>> > Thanks in advance!
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "Puppet Users" group.
>> > To view this discussion on the web visit
>> > https://groups.google.com/d/msg/puppet-users/-/I_o9G1NySfUJ.
>> > To post to this group, send email to puppet...@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > puppet-users...@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 view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/2-aZE0n23ewJ.
>
> 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: how to stop puppet from checking a service
On Mon, Oct 1, 2012 at 6:03 PM, jcbollinger wrote: > > > On Monday, October 1, 2012 3:56:42 PM UTC-5, Darin Perusich wrote: >> >> Is there an way for puppet to not check whether a service is running >> or not? I'm basically looking for the equivalent of enable => manual >> for Linux systems, I think. This would be useful when the service >> itself is under the control of a CRM like Pacemaker or I want to give >> control of the service to an end user, say both tomcat and glassfish >> are on the same box and they want to run one instead of the other. > > > > I suspect it's not possible to prevent Puppet from checking whether a > managed service is running, but it may be possible to prevent it from > managing whether the service is running. Try omitting the 'ensure' > parameter altogether. You are correct...by omitting the "ensure" the service is no longer checked to if it's running or not. Thanks! > Note that if you're not managing whether the service is running, then the > only other thing about it you can be managing is whether it starts at boot > (via the 'enable' parameter). If you don't want to manage that either, then > just don't declare a Service resource in the first place. > > >> >> Supposedly the Example42 modules support this by disableboot=>true, >> but that doesn't appear to do anything other than set "enable => >> false" for the service and I don't see how that stops Puppet from >> checking whether the service is up or down. >> > > It doesn't, but what's the harm in just checking? > > I haven't looked at the modules you're talking about, but perhaps they do as > I suggested? It would be fairly easy to overlook complete omission of a > parameter -- much more so than to overlook a special parameter value. > > > John > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/GdMKCawsHsoJ. > 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] Puppet 3.0.0 and Augeas on Ubuntu Lucid 10.04
Hi, My manifests used to work with 2.7.19 but after upgrading to 3.0.0 I keep getting: Error: /Stage[main]/.../Augeas[...]: Could not evaluate: uninitialized constant Augeas::NO_LOAD Anyone else had and solved this problem? On precise I just get: Warning: Augeas[...](provider=augeas): Loading failed for one or more files, see debug for /augeas//error output Cheers, Paul -- 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 3.0 with passenger
Hi everyone,
I am trying to setup puppet 3.0 with passenger since this morning, it is a
really painful for me.
I am using the directive:
SSLOptions +StdEnvVars +ExportCertData
No problem, but when putting '+ExportCertData', I am unable to autosign or
revoke remotely any certificate I have the following error:
info: Creating a new SSL key for linux-install.fqdn
err: Could not request certificate: Error 400 on SERVER: header too long
Exiting; failed to retrieve certificate and waitforcert is disabled
When using only:
SSLOptions +StdEnvVars
Everything works perfectly.
So here is the apache configuration file:
--
# you probably want to tune these settings
PassengerMaxPoolSize 12
PassengerPoolIdleTime 1500
# PassengerMaxRequests 1000
PassengerStatThrottleRate 120
RackAutoDetect Off
RailsAutoDetect Off
PassengerHighPerformance on
Listen 8140
ServerName puppetmaster.fqdn
ServerAlias puppetmaster
ErrorLog /var/log/apache2/puppetmaster_error.log
LogLevel warn
SetEnvIf Remote_Addr "::1" dontlog
CustomLog /var/log/apache2/puppetmaster_access.log combined
env=!dontlog
SSLEngine on
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
SSLCertificateFile
/data/local/puppet/ssl/certs/puppetmaster.fqdn.pem
SSLCertificateKeyFile
/data/local/puppet/ssl/private_keys/puppetmaster.fqdn.pem
SSLCertificateChainFile /data/local/puppet/ssl/ca/ca_crt.pem
SSLCACertificateFile/data/local/puppet/ssl/ca/ca_crt.pem
# If Apache complains about invalid signatures on the CRL, you can
try disabling
# CRL checking by commenting the next line, but this is not
recommended.
SSLCARevocationFile /data/local/puppet/ssl/ca/ca_crl.pem
SSLVerifyClient optional
SSLVerifyDepth 1
# The `ExportCertData` option is needed for agent certificate
expiration warnings
SSLOptions +StdEnvVars +ExportCertData
# This header needs to be set if using a loadbalancer or proxy
# RequestHeader unset X-Forwarded-For
RequestHeader set X-SSL-Subject %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-DN %{SSL_CLIENT_S_DN}e
RequestHeader set X-Client-Verify %{SSL_CLIENT_VERIFY}e
RackAutoDetect On
DocumentRoot /var/www/puppetmaster/public/
RackBaseURI /
Options None
AllowOverride None
Order allow,deny
allow from all
--
So any clue?
Regards,
JM
--
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] Fileserver error with Puppet 3.0
Hi,
I am evaluating Puppet 3.0 on my test puppetmaster. I have what looks
like a regression from Puppet 2.7.19:
Info: Retrieving plugin
Info: Loading facts in /var/lib/puppet/lib/facter/ircamnetwork.rb
Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
Info: Loading facts in /var/lib/puppet/lib/facter/passenger_root.rb
Info: Loading facts in /var/lib/puppet/lib/facter/raid_md.rb
Info: Loading facts in /var/lib/puppet/lib/facter/mysql.rb
Info: Loading facts in /var/lib/puppet/lib/facter/ircamserver.rb
Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
Info: Caching catalog for cobbler-staging.ircam.fr
Info: Applying configuration version '1349189813'
Error:
/Stage[main]/Collectd::Node/Collectd::Collectd_service[network]/File[/etc/collectd.d/network.conf]:
Could not evaluate: Error 400 on SERVER: Not authorized to call find on
/file_metadata/private/modules/collectd/network.conf Could not retrieve file
metadata for puppet:///private/modules/collectd/network.conf: Error 400 on
SERVER: Not authorized to call find on
/file_metadata/private/modules/collectd/network.conf
/Stage[main]/Collectd/Service[collectd]: Dependency
File[/etc/collectd.d/network.conf] has failures: true
Warning: /Stage[main]/Collectd/Service[collectd]: Skipping because of failed
dependencies
Finished catalog run in 5.41 seconds
I am aware of bug #16667 but I fail to see if it is relevant; I never
saw the deprecation notice when running Puppet 2.7.
To give a little more detail, here is the definition of
collectd_service:
define collectd_service () {
file { "/etc/collectd.d/${name}.conf":
source => [
"puppet:///private/modules/collectd/${name}.conf",
"puppet:///modules/collectd/services/${name}.conf",
],
owner => 'root',
group => 'root',
mode => '0444',
require => Package['collectd'],
notify => Service['collectd'],
}
}
So IIUC, the client should first try the private mount on the
fileserver, and fall back to the module in case of failure, right? And
here is the contents of fileserver.conf, which defines the private
mount:
[files]
path /etc/puppet/files
allow 129.102.0.0/16
allow 2001:660:3004::/49
[private]
path /etc/puppet/files-private/%H
allow 129.102.0.0/16
allow 2001:660:3004::/49
Here are the debug logs on both sides if needed:
http://files.glou.org/puppet/puppetmaster-fileserver-failure.log
http://files.glou.org/puppet/puppet-agent-fileserver-failure.log
--
A
--
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] Removing intermediate variables in calculation
I'm in no way a puppet guru but rewritting it didnt work? from a logic
point of view this should work:
class
$baseurl,
$webapp_context_path = ''
) {
if ($webapp_context_path == '') {
# Try to get value from baseurl
$webapp_context_path = regsubst($baseurl, '^https?://[^/]+(/.*)', '\1')
if ($webapp_context_path == '') {
#Set default
$webapp_context_path = '/'
}
}
notify{"rewritted webapp_context_path='${webapp_context_path}' from
url='${baseurl}'": }
}
But as I said I'm fairly new with puppet, did not tried above code.
On Mon, Oct 1, 2012 at 10:28 PM, Amos Shapira wrote:
> Hello,
>
> I have a small Puppet 2.7 module to configure Sonatype Nexus Professional.
> The module takes, among other things, a baseurl in the form of "
> http://example.com/path"; and I'd like it to extract the "/path" from that
> variable into a separate variable IF an optional "path" variable haven't
> been supplied.
>
> Here is an extract:
> class nexus::config(
> ...
> $baseurl,
> $webapp_context_path = ''
> ) {
> if ($webapp_context_path == '')
> {
> $webapp_context_path = regsubst($baseurl, '^https?://[^/]+(/.*)', '\1')
>
$webapp_context_path = regsubst($baseurl, '^https?://[^/]+(/.*)', '\1')
if ($extracted_url_path)
> {
> $int_webapp_context_path = $extracted_url_path
> }
> else
> {
> # in case we were given a $baseurl without the tailing "/"
> $int_webapp_context_path = '/'
> }
> notify{"extracted int_webapp_context_path
> \"${int_webapp_context_path}\" from url \"${baseurl}\"": }
> }
>
> # use $int_webapp_context_path in the .erb template file
>
> My question - this use of $int_webapp_context_path and $extracted_url_path
> looks a bit shabby. But I didn't find a way to use conditional assignments
> to remove these intermediate variables and either:
> 1. Assign the value I want to $webapp_context_path if it's not set yet.
> 2. Or at least get rid of the $extracted_url_path
>
> Is there a nicer way to achieve the above?
>
> Thanks.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/rNRGRX2LrzkJ.
> 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.
>
--
GuruHub - Guzmán Brasó
http://www.guruhub.com.uy - +59898674020
Rivera 3565 - CP11400 - Montevideo, Uruguay
--
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] Operating system conflict?
Hi,
I've have some problems with my puppet configuration, I'm managing several
Ubuntu and OpenBSD hosts.
I sometimes get on OpenBSD hosts (5.0 is OpenBSD release):
info: Retrieving plugin
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find template 'ubuntu-common/5.0/etc-openntpd-ntpd.conf.erb' at
/usr/share/puppet/modules/ubuntu-common/manifests/base.pp:7 on node xxx
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
But this is in an Ubuntu template file, OpenBSD should never include this
file, according to the case $operatingsystem in site.pp.
I tracked the exact scenario which make it fail:
1. Restart puppet master - run agent only with OpenBSD hosts - it never
fails, everything works as expected
2. Restart puppet master - run agent only with Ubuntu hosts - it never
fails, everything works as expected
3. Restart puppet master - run agent with Ubuntu and OpenBSD hosts - Ubuntu
works as expected, OpenBSD fails with the above error message (after the
first Ubuntu agent was connected)
4. after scenario 3. on puppet config file changes, OpenBSD works again
until an Ubuntu agent connects to the master
Do you have an idea of what could be wrong, or an known issue of puppet?
Could it be a puppet version issue, the master and Ubuntu hosts are using
2.7.19, OpenBSD hosts are using 2.7.1? (I haven't tried to downgrade ubuntu
or upgrade OpenBSD's version, newer OpenBSD 5.1 comes with puppet 2.7.5)
According to scenario 4. could it be a caching issue on the master?
I tried some puppet.conf options:
ignorecache=true
usecacheonfailure=false
but it didn't change anything.
The master and ubuntu hosts are running on Ubuntu 12.04
# puppet --version
2.7.19
# ruby --version
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]
The OpenBSD hosts are OpenBSD 5.0
# puppet --version
2.7.1
# ruby18 --version
ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-openbsd]
Here is my very simplified version of puppet files, I didn't try exactly
this subset of configuration, I will try to narrow down the problem to the
simplest configuration.
manifests/site.pp:
node basenode {
case $operatingsystem {
"Ubuntu" : { include "ubuntu-common::base" }
"OpenBSD" : { include "openbsd-common::base" }
default : {}
}
}
modules/ubuntu-common/manifests/base.pp:
class ubuntu-common::base {
file { "/etc/openntpd/ntpd.conf":
ensure => file,
owner => root,
group => root,
mode => 644,
content =>
template("ubuntu-common/$operatingsystemrelease/etc-openntpd-ntpd.conf.erb"),
}
}
modules/openbsd-common/manifests/base.pp:
class openbsd-common::base {
...
}
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/pLm1_gzZ9LsJ.
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] service question
Hi,
I have a service /etc/init.d/a that spawns multiple daemons b and c.
This manifest does not make much sense to me but… any tip?
service { 'a':
ensure => running,
pattern => ["/usr/local/bin/b", "/usr/local/bin/c"],
}
or should I test them individually?
service { 'a':
ensure => running,
pattern => "/usr/local/bin/b",
}
service { 'a':
ensure => running,
pattern => "/usr/local/bin/c",
}
or even other way around :)
thanks in advance
--
Frank
--
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] Fileserver error with Puppet 3.0
In Puppet 3.x, allow directives are limited to hostnames, if you wish
to allow an ip address, the allow_ip directive should be used. This
was in response to CVE-2012-3408
(http://puppetlabs.com/security/cve/cve-2012-3408/).
On Tue, Oct 2, 2012 at 8:10 AM, Arnaud Gomes-do-Vale
wrote:
> Hi,
>
> I am evaluating Puppet 3.0 on my test puppetmaster. I have what looks
> like a regression from Puppet 2.7.19:
>
> Info: Retrieving plugin
> Info: Loading facts in /var/lib/puppet/lib/facter/ircamnetwork.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/root_home.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/passenger_root.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/raid_md.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/mysql.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/ircamserver.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/facter_dot_d.rb
> Info: Loading facts in /var/lib/puppet/lib/facter/puppet_vardir.rb
> Info: Caching catalog for cobbler-staging.ircam.fr
> Info: Applying configuration version '1349189813'
> Error:
> /Stage[main]/Collectd::Node/Collectd::Collectd_service[network]/File[/etc/collectd.d/network.conf]:
> Could not evaluate: Error 400 on SERVER: Not authorized to call find on
> /file_metadata/private/modules/collectd/network.conf Could not retrieve file
> metadata for puppet:///private/modules/collectd/network.conf: Error 400 on
> SERVER: Not authorized to call find on
> /file_metadata/private/modules/collectd/network.conf
> /Stage[main]/Collectd/Service[collectd]: Dependency
> File[/etc/collectd.d/network.conf] has failures: true
> Warning: /Stage[main]/Collectd/Service[collectd]: Skipping because of failed
> dependencies
> Finished catalog run in 5.41 seconds
>
> I am aware of bug #16667 but I fail to see if it is relevant; I never
> saw the deprecation notice when running Puppet 2.7.
>
> To give a little more detail, here is the definition of
> collectd_service:
>
> define collectd_service () {
> file { "/etc/collectd.d/${name}.conf":
> source => [
> "puppet:///private/modules/collectd/${name}.conf",
> "puppet:///modules/collectd/services/${name}.conf",
> ],
> owner => 'root',
> group => 'root',
> mode => '0444',
> require => Package['collectd'],
> notify => Service['collectd'],
> }
> }
>
> So IIUC, the client should first try the private mount on the
> fileserver, and fall back to the module in case of failure, right? And
> here is the contents of fileserver.conf, which defines the private
> mount:
>
> [files]
> path /etc/puppet/files
> allow 129.102.0.0/16
> allow 2001:660:3004::/49
>
> [private]
> path /etc/puppet/files-private/%H
> allow 129.102.0.0/16
> allow 2001:660:3004::/49
>
> Here are the debug logs on both sides if needed:
>
> http://files.glou.org/puppet/puppetmaster-fileserver-failure.log
> http://files.glou.org/puppet/puppet-agent-fileserver-failure.log
>
> --
> A
>
> --
> 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.
>
--
Matthaus Owens
Release Manager, Puppet Labs
--
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] Deploy nagios client on windows
On Mon, Oct 1, 2012 at 10:39 AM, Josh Cooper wrote:
> Hi Thomas,
>
> On Thu, Sep 27, 2012 at 12:59 PM, Thomas Bendler
> wrote:
>> Hi @all,
>>
>> does anyone manage the NSClient++ deployment with puppet? I have the strange
>> behavior that I can distribute the installation package to the target server
>> and install the package with the MSI provider. The relevant code is here:
>>
>> if $windows {
>> file {
>> "c:/local/source":
>> ensure => directory, mode => 0770,
>> owner => "Administrators", group => "Administrators";
>>
>> "c:/local/source/NSClient++-0.3.9-x64.msi":
>> ensure => present, mode => 0660,
>> owner => "Administrators", group => "Administrators",
>> require => File["c:/local/source"],
>> path => $::operatingsystem ? { default =>
>> "c:/local/source/NSClient++-0.3.9-x64.msi" },
>> source => "puppet:///modules/monitor/nagios/NSClient++-0.3.9-x64.msi";
>
> This require shouldn't be necessary as the file will autorequire its
> ancestor directories.
>
>>
>> "c:/local/nsclient/boot.ini":
>> ensure => present, mode => 0664,
>> owner => "Administrators", group => "SYSTEM",
>> require => Package["NSClientpp"],
>> notify => Service["NSClientpp"],
>> path => $::operatingsystem ? { default => "c:/local/nsclient/boot.ini"
>> },
>> content => template("monitor/nagios/client/boot.ini.erb");
>>
>> "c:/local/nsclient/nsc.ini":
>> ensure => present, mode => 0664,
>> owner => "Administrators", group => "SYSTEM",
>> require => Package["NSClientpp"],
>> notify => Service["NSClientpp"],
>> path => $::operatingsystem ? { default => "c:/local/nsclient/nsc.ini"
>> },
>> content => template("monitor/nagios/client/nsc.ini.erb");
>> }
>>
>> package {
>> "NSClientpp":
>> ensure => installed,
>> provider => "msi",
>> source => 'c:\local\source\NSClient++-0.3.9-x64.msi',
>> install_options => {
>> 'INSTALLLOCATION' => 'c:\local\nsclient',
>> 'ADDLOCAL' => 'ALL',
>> 'START_SERVICE_ON_EXIT' => '1'
>> };
>> }
>>
>> service {
>> "NSClientpp":
>> name => $::operatingsystem ? { default => "NSClientpp" },
>> ensure => "running", enable => true,
>> require => Package["NSClientpp"];
>> }
>> }
>>
>> Now to the strange thing, when the package is installed with the MSI
>> provider, the service entry from the NSClient++ disapear. When I manually
>> execute the installation package with option repair, it apears again ...
>> until the next puppet run where it disapear again. So calling the service
>> resource fail because of the missing service entry. The OS is a 2003SP2 x64,
>> the puppet client has the version 2.7.19. Any ideas?
>
> The name of the package needs to match the "DisplayName" as specified
> in the registry (and Add/Remove Programs). This used to be in the
> puppet wiki page, but I don't see it in the new documentation. I'll
> file a doc bug about this.
I submitted a pull request https://github.com/puppetlabs/puppet-docs/pull/107
> For this package, it should be "NSClient++ (x64)", both in the package
> resource and the service resource that requires it.
>
> It appears what is occurring is that the second time puppet runs, it
> thinks the package is not installed, so it installs it again (really a
> repair). For some reason, the NSClient MSI gets confused and
> uninstalls the service during the repair.
>
> In any case, the second time you run puppet (with --debug), you should
> see something like:
>
> Debug: /Stage[main]//File[c:/local/nagios/NSClient++-0.3.9-x64.msi]/require:
> requires File[c:/local/nagios]
> Debug: /Stage[main]//Service[NSClientpp]/require: requires
> Package[NSClient++ (x64)]
> ...
> Debug: Prefetching msi resources for package
> Debug: Service[NSClientpp](provider=windows): Service NSClientpp is running
> Debug: Service[NSClientpp](provider=windows): Service NSClientpp start
> type is auto start
>
> But you should not see:
>
> Debug: Executing 'msiexec.exe /qn /norestart /i
> c:\local\nagios\NSClient++-0.3.9-x64.msi ADDLOCAL=ALL
> INSTALLLOCATION=c:\local\nsclient START_SERVICE_ON_EXIT=1'
>
> Josh
>
> --
> Josh Cooper
> Developer, Puppet Labs
Josh
--
Josh Cooper
Developer, Puppet Labs
--
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] Set variable value
Hi, Is it possible to set the value of a variable from the content of a text file? Regards. -- 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 3.0 deprecates the kick command
I use the command "puppet kick" to do remote triggers of a 60 node cluster. In the new release (3.0) it deprecated the command and the command fails with: Error: Host lcms-dn1.aws.tie.noklab.net failed: Error 400 on SERVER: Could not find indirection 'run' (I use Passenger on Apache) The web page it gives for reference: http://links.puppetlabs.com/puppet-kick-deprecation is a dummy to the deprecation bug. What are we supposed to use to remote trigger puppet reloads? -C -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/3YFhyVycpyYJ. 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] Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
The ChangeLog and the PR are not clear about this. In fact, the
documentation is vague and doesn't really mention allow_ip at all. This
should be updated and made more clear?
I will give this a try later on, on a test system, and see if that solves
the problem.
Thanks.
On Tuesday, October 2, 2012 1:30:34 AM UTC-4, Matthaus Litteken wrote:
>
> Oh, sorry, you mention that you already found that changelog entry. I
> misread that part.
>
> On Mon, Oct 1, 2012 at 10:27 PM, Matthaus Owens
> >
> wrote:
> > In Puppet 3.x, allow directives are limited to hostnames, if you wish
> > to allow an ip address, the allow_ip directive should be used. This
> > was in response to CVE-2012-3408
> > (http://puppetlabs.com/security/cve/cve-2012-3408/).
> >
> > On Mon, Oct 1, 2012 at 5:48 PM, Forrie >
> wrote:
> >> I've seen mention of this error in several places, with different
> causes.
> >> So before I posted here, I attempted to resolve this on my own.
> >>
> >> I corrected the change from puppet:///files to puppet:/// in my
> manifests
> >> *.pp files.
> >>
> >> No changes were made to the auth.conf file, and I did note in the
> ChangeLog
> >> that:
> >>
> >>> Auth.conf differentiates between names and IPs – There’s a new
> allow_ip
> >>> keyword in auth.conf if you want to permit IP addresses. (PR991)
> >>
> >>
> >> But I see no mention of that on the docs page at
> >> http://docs.puppetlabs.com/guides/rest_auth_conf.html.
> >>
> >> Our auth.conf is simple, and basically has either "allow $1" or "allow
> *"
> >> both which appear to still be valid in 3.0.
> >>
> >> Here's an example, a simple example, an ntp.conf file:
> >>
> >> class ntp-client {
> >> file { "/etc/ntp.conf":
> >> owner => root,
> >> group => root,
> >> mode=> 644,
> >> source => "puppet:///etc/ntp.conf",
> >> require => [ Package["ntp"] ],
> >> notify => Service["ntpd"],
> >> }
> >> package { "ntp":
> >> ensure => latest,
> >> }
> >> service { "ntpd":
> >> ensure => running,
> >> hasrestart => true,
> >> subscribe => File["/etc/ntp.conf"],
> >> }
> >> } # ntp-client
> >>
> >>
> >> The error I'm seeing in the puppet.log, on the client system:
> >>
> >>
> >>> Oct 1 20:02:28 test-fms puppet-agent[11062]: Starting Puppet client
> >>> version 2.7.17
> >>> Oct 1 20:02:31 test-fms puppet-agent[11062]:
> >>> (/Stage[main]/Ntp-client/File[/etc/ntp.conf]) Could not evaluate:
> Error 400
> >>> on SERVER: Not authorized to call find on /file_metadata/etc/ntp.conf
> Could
> >>> not retrieve file metadata for puppet:///etc/ntp.conf: Error 400 on
> SERVER:
> >>> Not authorized to call find on /file_metadata/etc/ntp.conf at
> >>> /etc/puppet/manifests/classes/ntp-client.pp:10
> >>
> >>
> >>
> >> The permissions from /etc/puppet/files are correct:
> >>
> >>> -rw-r--r--. 1 puppet puppet 446 Mar 31 2011 etc/ntp.conf
> >>
> >>
> >> The client puppet.conf file doesn't have any custom references other
> than
> >> the basics.
> >>
> >>> [main]
> >>> server = ourpuppet.server.com
> >>> vardir = /var/lib/puppet
> >>> logdir = /var/log/puppet
> >>> rundir = /var/run/puppet
> >>> ssldir = $vardir/ssl
> >>> [agent]
> >>> classfile = $vardir/classes.txt
> >>> localconfig = $vardir/localconfig
> >>> syslogfacility = local4
> >>> report = true
> >>> listen = true
> >>
> >>
> >> I ran puppet master in verbose mode and got these diagnostics:
> >>
> >> Starting Puppet master version 3.0.0
> >> Info: access[^/catalog/([^/]+)$]: allowing 'method' find
> >> Info: access[^/catalog/([^/]+)$]: allowing $1 access
> >> Info: access[/certificate_revocation_list/ca]: allowing 'method' find
> >> Info: access[/certificate_revocation_list/ca]: allowing * access
> >> Info: access[/report]: allowing 'method' save
> >> Info: access[/report]: allowing * access
> >> Info: access[/file]: allowing * access
> >> Info: access[/certificate/ca]: adding authentication no
> >> Info: access[/certificate/ca]: allowing 'method' find
> >> Info: access[/certificate/ca]: allowing * access
> >> Info: access[/certificate/]: adding authentication no
> >> Info: access[/certificate/]: allowing 'method' find
> >> Info: access[/certificate/]: allowing * access
> >> Info: access[/certificate_request]: adding authentication no
> >> Info: access[/certificate_request]: allowing 'method' find
> >> Info: access[/certificate_request]: allowing 'method' save
> >> Info: access[/certificate_request]: allowing * access
> >> Info: access[/]: adding authentication any
> >> Info: Inserting default '~ ^/node/([^/]+)$' (auth true) ACL
> >> Info: Inserting default '/status' (auth true) ACL
> >> Warning: Host is missing hostname and/or domain: one-host.ourdomain.com
> >> Compiled catalog for one-host.ourdomain.com in environment production
> in
> >> 1.16 secon
[Puppet Users] Re: Puppet 3.0 deprecates the kick command
They recommend installing MCollective, which I've not tackled yet -- but it seems like overkill for basic needs that were met by simple "puppet kick". There are other options out there like Func, et al. -- 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] Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
Check out the example auth.conf that comes with the distribution, it's
heavily commented and should point the way:
https://github.com/puppetlabs/puppet/blob/master/conf/auth.conf
On Tuesday, October 2, 2012 11:09:08 AM UTC-7, Forrie wrote:
>
> The ChangeLog and the PR are not clear about this. In fact, the
> documentation is vague and doesn't really mention allow_ip at all. This
> should be updated and made more clear?
>
> I will give this a try later on, on a test system, and see if that solves
> the problem.
>
> Thanks.
>
>
>
> On Tuesday, October 2, 2012 1:30:34 AM UTC-4, Matthaus Litteken wrote:
>>
>> Oh, sorry, you mention that you already found that changelog entry. I
>> misread that part.
>>
>> On Mon, Oct 1, 2012 at 10:27 PM, Matthaus Owens
>> wrote:
>> > In Puppet 3.x, allow directives are limited to hostnames, if you wish
>> > to allow an ip address, the allow_ip directive should be used. This
>> > was in response to CVE-2012-3408
>> > (http://puppetlabs.com/security/cve/cve-2012-3408/).
>> >
>> > On Mon, Oct 1, 2012 at 5:48 PM, Forrie wrote:
>> >> I've seen mention of this error in several places, with different
>> causes.
>> >> So before I posted here, I attempted to resolve this on my own.
>> >>
>> >> I corrected the change from puppet:///files to puppet:/// in my
>> manifests
>> >> *.pp files.
>> >>
>> >> No changes were made to the auth.conf file, and I did note in the
>> ChangeLog
>> >> that:
>> >>
>> >>> Auth.conf differentiates between names and IPs – There’s a new
>> allow_ip
>> >>> keyword in auth.conf if you want to permit IP addresses. (PR991)
>> >>
>> >>
>> >> But I see no mention of that on the docs page at
>> >> http://docs.puppetlabs.com/guides/rest_auth_conf.html.
>> >>
>> >> Our auth.conf is simple, and basically has either "allow $1" or "allow
>> *"
>> >> both which appear to still be valid in 3.0.
>> >>
>> >> Here's an example, a simple example, an ntp.conf file:
>> >>
>> >> class ntp-client {
>> >> file { "/etc/ntp.conf":
>> >> owner => root,
>> >> group => root,
>> >> mode=> 644,
>> >> source => "puppet:///etc/ntp.conf",
>> >> require => [ Package["ntp"] ],
>> >> notify => Service["ntpd"],
>> >> }
>> >> package { "ntp":
>> >> ensure => latest,
>> >> }
>> >> service { "ntpd":
>> >> ensure => running,
>> >> hasrestart => true,
>> >> subscribe => File["/etc/ntp.conf"],
>> >> }
>> >> } # ntp-client
>> >>
>> >>
>> >> The error I'm seeing in the puppet.log, on the client system:
>> >>
>> >>
>> >>> Oct 1 20:02:28 test-fms puppet-agent[11062]: Starting Puppet client
>> >>> version 2.7.17
>> >>> Oct 1 20:02:31 test-fms puppet-agent[11062]:
>> >>> (/Stage[main]/Ntp-client/File[/etc/ntp.conf]) Could not evaluate:
>> Error 400
>> >>> on SERVER: Not authorized to call find on /file_metadata/etc/ntp.conf
>> Could
>> >>> not retrieve file metadata for puppet:///etc/ntp.conf: Error 400 on
>> SERVER:
>> >>> Not authorized to call find on /file_metadata/etc/ntp.conf at
>> >>> /etc/puppet/manifests/classes/ntp-client.pp:10
>> >>
>> >>
>> >>
>> >> The permissions from /etc/puppet/files are correct:
>> >>
>> >>> -rw-r--r--. 1 puppet puppet 446 Mar 31 2011 etc/ntp.conf
>> >>
>> >>
>> >> The client puppet.conf file doesn't have any custom references other
>> than
>> >> the basics.
>> >>
>> >>> [main]
>> >>> server = ourpuppet.server.com
>> >>> vardir = /var/lib/puppet
>> >>> logdir = /var/log/puppet
>> >>> rundir = /var/run/puppet
>> >>> ssldir = $vardir/ssl
>> >>> [agent]
>> >>> classfile = $vardir/classes.txt
>> >>> localconfig = $vardir/localconfig
>> >>> syslogfacility = local4
>> >>> report = true
>> >>> listen = true
>> >>
>> >>
>> >> I ran puppet master in verbose mode and got these diagnostics:
>> >>
>> >> Starting Puppet master version 3.0.0
>> >> Info: access[^/catalog/([^/]+)$]: allowing 'method' find
>> >> Info: access[^/catalog/([^/]+)$]: allowing $1 access
>> >> Info: access[/certificate_revocation_list/ca]: allowing 'method' find
>> >> Info: access[/certificate_revocation_list/ca]: allowing * access
>> >> Info: access[/report]: allowing 'method' save
>> >> Info: access[/report]: allowing * access
>> >> Info: access[/file]: allowing * access
>> >> Info: access[/certificate/ca]: adding authentication no
>> >> Info: access[/certificate/ca]: allowing 'method' find
>> >> Info: access[/certificate/ca]: allowing * access
>> >> Info: access[/certificate/]: adding authentication no
>> >> Info: access[/certificate/]: allowing 'method' find
>> >> Info: access[/certificate/]: allowing * access
>> >> Info: access[/certificate_request]: adding authentication no
>> >> Info: access[/certificate_request]: allowing 'method' find
>> >> Info: access[/certificate_request]: allowing 'method' save
>> >> Info: access[/certificate_r
[Puppet Users] Re: Puppet 3.0 fails install on Solaris 10 w/ ruby 1.8.7
I solved the ruby18_dev dependency. However, when I go to compile, I
get this error:
# gem install puppet
Building native extensions. This could take a while...
ERROR: Error installing puppet:
ERROR: Failed to build gem native extension.
/opt/csw/bin/ruby18 extconf.rb
creating Makefile
make
/opt/SUNWspro/bin/cc -I. -I/opt/csw/lib/ruby/1.8/i386-solaris2.9 -I/
opt/csw/lib/ruby/1.8/i386-solaris2.9 -I. -DJSON_GENERATOR -I/opt/csw/
include -D_FILE_OFFSET_BITS=64 -KPIC -xO3 -m32 -xarch=386 -KPIC -
O3 -c generator.c
make: /opt/SUNWspro/bin/cc: Command not found
make: *** [generator.o] Error 127
Gem files will remain installed in /opt/csw/lib/ruby/gems/1.8/gems/
json-1.7.5 for inspection.
Results logged to /opt/csw/lib/ruby/gems/1.8/gems/json-1.7.5/ext/json/
ext/generator/gem_make.out
Interesting as I haven't used that in a long time and it's not
installed here. This variable is not set anywhere in the environment
that I can tell. Equally, when I manually set CC=/opt/csw/bin/gcc
(and export it) the build does not honor that.
Interestingly, when I do a "find" I can see this mentioned in the /opt/
csw/lib/ruby structure:
# find . -type f -exec grep SUNWspro {} \;
CONFIG["configure_args"] = " '--prefix=/opt/csw' '--exec_prefix=/opt/
csw' '--bindir=/opt/csw/bin' '--sbindir=/opt/csw/sbin' '--libexecdir=/
opt/csw/libexec' '--datadir=/opt/csw/share' '--sysconfdir=/opt/csw/
etc' '--sharedstatedir=/opt/csw/share' '--localstatedir=/opt/csw/var'
'--libdir=/opt/csw/lib' '--infodir=/opt/csw/share/info' '--includedir=/
opt/csw/include' '--mandir=/opt/csw/share/man' '--enable-pthread' '--
enable-shared' '--with-tcl-dir=/opt/csw' '--with-tk-dir=/opt/csw' '--
with-dbm-dir=/opt/csw/bdb48' '--with-gdbm-dir=/opt/csw' '--with-iconv-
dir=/opt/csw' '--with-openssl-dir=/opt/csw' '--with-readline-dir=/opt/
csw' '--with-zlib-dir=/opt/csw' '--program-suffix=18' 'CC=/opt/
SUNWspro/bin/cc' 'CFLAGS=-xO3 -m32 -xarch=386' 'LDFLAGS=-L/opt/csw/
lib' 'CPPFLAGS=-I/opt/csw/include'"
CONFIG["CPP"] = "/opt/SUNWspro/bin/cc -E"
CONFIG["CC"] = "/opt/SUNWspro/bin/cc"
/opt/SUNWspro/bin/cc -I. -I/opt/csw/lib/ruby/1.8/i386-solaris2.9 -I/
opt/csw/lib/ruby/1.8/i386-solaris2.9 -I. -DJSON_GENERATOR -I/opt/csw/
include -D_FILE_OFFSET_BITS=64 -KPIC -xO3 -m32 -xarch=386 -KPIC -
O3 -c generator.c
make: /opt/SUNWspro/bin/cc: Command not found
CC = /opt/SUNWspro/bin/cc
We have solstudio2.2 installed -- so I put a symlink in /opt pointing
SUNWspro -> solstudio2.2 and it seems happy.
I'm just putting this out here in case someone else gets bitten by
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.
[Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available. Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7). I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/o33U4atSmJwJ. 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] Puppet 3.0.0 and Augeas on Ubuntu Lucid 10.04
On Tue, Oct 2, 2012 at 6:49 AM, Paul Tötterman wrote: > Hi, > > My manifests used to work with 2.7.19 but after upgrading to 3.0.0 I > keep getting: Did you upgrade only the agent, or the master to 3.0.0 before upgrading any agents? > Error: /Stage[main]/.../Augeas[...]: Could not evaluate: uninitialized > constant Augeas::NO_LOAD Could you please run the master and the agent with --trace and paste in the strack trace? > Anyone else had and solved this problem? On precise I just get: > > Warning: Augeas[...](provider=augeas): Loading failed for one or more > files, see debug for /augeas//error output Could you provide a snippet of Puppet manifest code that reproduces the issue? This information will help us quickly identify, record, and (hopefully) fix, the issue. -Jeff -- 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] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg wrote: > I am using CentOS 6 with the PuppetLabs yum repo from > http://yum.puppetlabs.com > > I noticed that today version 3 is available on the repo, so of course, an > upgrade to Puppet is available. Yes, this major version update went live on Monday. There are a number of breaking-changes between 2.7 and 3.0 which are described at: http://links.puppetlabs.com/telly_breaking_changes > Ideally, it would have been better if v3 had a different distribution name, > so that systems with v2.7.x are not upgraded (especially if there will be > future releases if v2.7). Could you please file an issue (with impact data) about the distribution name issue. I believe we considered doing what you describe, but decided against it. I don't know the reasons off the top of my head though, an issue will give us a clear place to track the request, the impact it has on you and your organization, and the decision we come to (or have already come to). > I am concerned about things breaking. So is there a document detailing > incompatibilities? Will there be future 2.7 releases? There will be future releases of 2.7. We will continue to fix bugs in the 2.7 series, but we are intending to avoid adding any new features or make any large changes to the behavior of Puppet 2.7. Hope this helps, -Jeff -- 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] PROBLEM : Cannot require an Exec
hello:
i currently am using Puppet to run some commands in a sequence. there are
two sequences of exec resources. we found that we cannot use require =>
Exec and it does not work at all as expected. here is some sample code.
exec { "exec-AAA":
command => "/bin/true",
returns => 0,
notify => Exec["exec-BBB"],
}
exec { "exec-BBB":
refreshonly => true,
command => "/bin/false",
returns => 0,
notify => Exec["exec-CCC"],
}
exec { "exec-CCC":
refreshonly => true,
command => "/bin/touch /tmp/CCC",
returns => 0,
}
exec { "exec-DDD":
require => Exec["exec-CCC"],
command => "/bin/true",
returns => 0,
notify => Exec["exec-EEE"],
}
exec { "exec-EEE":
refreshonly => true,
command => "/bin/false",
notify => Exec["exec-FFF"],
}
exec { "exec-FFF":
refreshonly => true,
command => "/bin/touch /tmp/FFF",
returns => 0,
}
*ms1:/root/aaron> puppet apply t1.pp*
notice: /Stage[main]//Exec[exec-AAA]/returns: executed successfully
err: /Stage[main]//Exec[exec-BBB]: Failed to call refresh: /bin/false
returned 1 instead of one of [0] at /root/aaron/t1.pp:11
notice: /Stage[main]//Exec[exec-DDD]/returns: executed successfully
err: /Stage[main]//Exec[exec-EEE]: Failed to call refresh: /bin/false
returned 1 instead of one of [0] at /root/aaron/t1.pp:28
notice: Finished catalog run in 0.36 seconds
in the example above, how did Exec["exec-DDD"] run when Exec["exec-CCC"]
did not run and Exec["exec-DDD"] require Exec["exec-CCC"]?
*ms1:/root/aaron> puppet apply --debug t1.pp*
info: Applying configuration version '1349209769'
debug: /Stage[main]//Exec[exec-DDD]/require: requires Exec[exec-CCC]
debug: /Stage[main]//Exec[exec-DDD]/notify: subscribes to Exec[exec-EEE]
debug: /Stage[main]//Exec[exec-BBB]/notify: subscribes to Exec[exec-CCC]
debug: /Stage[main]//Exec[exec-AAA]/notify: subscribes to Exec[exec-BBB]
debug: /Stage[main]//Exec[exec-EEE]/notify: subscribes to Exec[exec-FFF]
debug: /Schedule[never]: Skipping device resources because running on a host
debug: /Schedule[daily]: Skipping device resources because running on a host
debug: /Schedule[monthly]: Skipping device resources because running on a
host
debug: /Schedule[puppet]: Skipping device resources because running on a
host
debug: /Schedule[hourly]: Skipping device resources because running on a
host
debug: /Schedule[weekly]: Skipping device resources because running on a
host
debug: Exec[exec-AAA](provider=posix): Executing '/bin/true'
debug: Executing '/bin/true'
notice: /Stage[main]//Exec[exec-AAA]/returns: executed successfully
debug: /Stage[main]//Exec[exec-AAA]: The container Class[Main] will
propagate my refresh event
info: /Stage[main]//Exec[exec-AAA]: Scheduling refresh of Exec[exec-BBB]
debug: Exec[exec-BBB](provider=posix): Executing '/bin/false'
debug: Executing '/bin/false'
err: /Stage[main]//Exec[exec-BBB]: Failed to call refresh: /bin/false
returned 1 instead of one of [0] at /root/aaron/t1.pp:11
debug: Exec[exec-DDD](provider=posix): Executing '/bin/true'
debug: Executing '/bin/true'
notice: /Stage[main]//Exec[exec-DDD]/returns: executed successfully
debug: /Stage[main]//Exec[exec-DDD]: The container Class[Main] will
propagate my refresh event
info: /Stage[main]//Exec[exec-DDD]: Scheduling refresh of Exec[exec-EEE]
debug: Exec[exec-EEE](provider=posix): Executing '/bin/false'
debug: Executing '/bin/false'
err: /Stage[main]//Exec[exec-EEE]: Failed to call refresh: /bin/false
returned 1 instead of one of [0] at /root/aaron/t1.pp:28
debug: Class[Main]: The container Stage[main] will propagate my refresh
event
debug: Finishing transaction 70054935787440
debug: Storing state
debug: Stored state in 0.06 seconds
notice: Finished catalog run in 0.37 seconds
debug: /File[/var/lib/puppet/rrd]/seluser: Found seluser default 'system_u'
for /var/lib/puppet/rrd
debug: /File[/var/lib/puppet/rrd]/selrole: Found selrole default 'object_r'
for /var/lib/puppet/rrd
debug: /File[/var/lib/puppet/rrd]/seltype: Found seltype default
'puppet_var_lib_t' for /var/lib/puppet/rrd
debug: /File[/var/lib/puppet/rrd]/selrange: Found selrange default 's0' for
/var/lib/puppet/rrd
debug: Finishing transaction 70054934905120
debug: Recieved report to process from ms1
debug: Processing report from ms1 with processor Puppet::Reports::Store
as you can see in the debug run, even though Exec["exec-DDD"] require
Exec["exec-CCC"], and the latter does not run, the former runs. what is
going on here?
thank you for your time.
have a nice day,
Aaron
--
{<-encapsulation->}
--
This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail.
--
You receive
Re: [Puppet Users] Puppet 3.0: Not authorized to call find on /file_metadata, more issues?
On Tue, Oct 2, 2012 at 11:09 AM, Forrie wrote: > The ChangeLog and the PR are not clear about this. In fact, the > documentation is vague and doesn't really mention allow_ip at all. This > should be updated and made more clear? Forrie, I agree this wasn't very clear. I too had a hard time finding the information until Matthaus pointed me in the right direction. We're currently working on updating the documentation at docs.puppetlabs.com to be much more clear about the breaking changes in Telly that we're aware of and we intend. I think this information is important because it can be hard to tell the difference between a breaking change we intended to be a breaking change and a breaking change in behavior that is actually a bug. The current list of change for the 3.0.0 release will always be available at the following URL: http://links.puppetlabs.com/telly_breaking_changes If you're still having trouble figuring out if a change in behavior is intentional or is a bug, and the information at the above URL isn't helpful, then please don't hesitate to ping me on IRC. I'll be hanging out in #puppet-dev all week and my #1 priority this week is working with the community on 3.0.0 related issues. My handle is jmccune. I hope this helps, -Jeff -- 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] Puppet 3.0 deprecates the kick command
On Tue, Oct 2, 2012 at 11:06 AM, Corby Wilson wrote: > I use the command "puppet kick" to do remote triggers of a 60 node cluster. > In the new release (3.0) it deprecated the command and the command fails > with: > Error: Host lcms-dn1.aws.tie.noklab.net failed: Error 400 on SERVER: Could > not find indirection 'run' As Forrie points out, we've deprecated kick in favor of mcollective, or you can log into the box and run the agent directly. That it isn't working is a bug. You can see a list of upgrade issues that we are tracking at http://projects.puppetlabs.com/projects/puppet/wiki/Telly_Upgrade_Issues and the issue with puppet kick being broken is specifically at http://projects.puppetlabs.com/issues/15717 > > (I use Passenger on Apache) > > The web page it gives for reference: > http://links.puppetlabs.com/puppet-kick-deprecation > is a dummy to the deprecation bug. > > What are we supposed to use to remote trigger puppet reloads? > > -C > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/puppet-users/-/3YFhyVycpyYJ. > 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] Introducing our new Community Manager - Dawn Foster
Hi all I am thrilled to announce our new Community Manager: Dawn Foster. Dawn joins us from Intel where she managed several open source communities (I'm going to let her introduce herself in more detail in a later email). Dawn will initially be lurking and getting to know you all. She's going to have a focus on helping us communicate better, making the relationship between the community and Puppet Labs work better, extending our developer community, helping getting traction on tickets and features the community wants, sharing lots of cool metrics and generally working to make Puppet and the community more awesome. Please make Dawn welcome! Regards James -- James Turnbull Puppet Labs 1-503-734-8571 To schedule a meeting with me: http://tungle.me/jamtur01 -- 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] Introducing our new Community Manager - Dawn Foster
On Tue, Oct 2, 2012 at 5:35 PM, James Turnbull wrote: > Hi all > > I am thrilled to announce our new Community Manager: Dawn Foster. Dawn > joins us from Intel where she managed several open source communities > (I'm going to let her introduce herself in more detail in a later email). > > Dawn will initially be lurking and getting to know you all. She's going > to have a focus on helping us communicate better, making the > relationship between the community and Puppet Labs work better, > extending our developer community, helping getting traction on tickets > and features the community wants, sharing lots of cool metrics and > generally working to make Puppet and the community more awesome. > > Please make Dawn welcome! > > Regards > > James > > -- > James Turnbull > Puppet Labs > 1-503-734-8571 > To schedule a meeting with me: http://tungle.me/jamtur01 > > -- > 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. > > Welcome to Puppet Labs Dawn! -- Kelsey Hightower Operations Manager Puppet Labs (678) 4719501 -- 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: Introducing our new Community Manager - Dawn Foster
Welcome, Dawn :) Jos -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/5rkoHCdvUYYJ. 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: Puppet 3.0 deprecates the kick command
On Tue, Oct 2, 2012 at 3:13 PM, Forrie wrote: > They recommend installing MCollective, which I've not tackled yet -- > but it seems like overkill for basic needs that were met by simple > "puppet kick". There are other options out there like Func, et al. > I have raised this same point a few weeks ago at puppet-dev mailing list [1], when I saw the committed change. `puppet kick` is very handy and I think that deprecating it is kinda of an imposition made by PuppetLabs' developers in favor of MCollective. [1] https://groups.google.com/d/topic/puppet-dev/P987lwK4AI0/discussion -- 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] PROBLEM : Cannot require an Exec
On Tue, Oct 2, 2012 at 5:36 PM, am-aaron wrote:
>
> exec { "exec-AAA":
> command => "/bin/true",
> returns => 0,
> notify => Exec["exec-BBB"],
> }
> exec { "exec-BBB":
> refreshonly => true,
> command => "/bin/false",
> returns => 0,
> notify => Exec["exec-CCC"],
> }
> exec { "exec-CCC":
> refreshonly => true,
> command => "/bin/touch /tmp/CCC",
> returns => 0,
> }
>
> exec { "exec-DDD":
> require => Exec["exec-CCC"],
> command => "/bin/true",
> returns => 0,
> notify => Exec["exec-EEE"],
> }
I tested your code and indeed, it is a strange behavior.
I guess the root cause of the problem is the `refreshonly => true` of exec-CCC.
My reading of the situation:
- exec-BBB runs and fails, sending nothing to exec-CCC.
- exec-CCC has `refreshonly => true`, since exec-BBB has failed, it
does nothing.
- exec-DDD runs, even having `require => Exec['exec-CCC']` which has
not received a notify because exec-BBB failed.
I did a test using the chaining syntax and the behavior is the same:
Exec['exec-AAA'] ~> Exec['exec-BBB'] ~> Exec['exec-CCC'] -> Exec['exec-DDD']
# puppet apply test.pp
/Stage[main]//Exec[exec-AAA]/returns: executed successfully
Error: /Stage[main]//Exec[exec-BBB]: Failed to call refresh:
/bin/false returned 1 instead of one of [0]
Error: /Stage[main]//Exec[exec-BBB]: /bin/false returned 1 instead of one of [0]
/Stage[main]//Exec[exec-DDD]/returns: executed successfully
Exec['exec-CCC'] does not receive a notification and does not run
because exec-BBB failed. Although, it fulfills the `require`
relationship with Exec['exec-DDD'], which runs.
Note: changing the relationship of Exec['exec-CCC'] and
Exec['exec-DDD'] from `require` para `notify` does not solve the
problem, the behavior is the same.
Very odd. The documentation about `exec` does not say anything about
this behavior of `refreshonly` [1].
[1] http://docs.puppetlabs.com/references/stable/type.html#exec
--
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] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune wrote: > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg wrote: >> I am using CentOS 6 with the PuppetLabs yum repo from >> http://yum.puppetlabs.com >> >> I noticed that today version 3 is available on the repo, so of course, an >> upgrade to Puppet is available. > > Yes, this major version update went live on Monday. There are a > number of breaking-changes between 2.7 and 3.0 which are described at: > http://links.puppetlabs.com/telly_breaking_changes > >> Ideally, it would have been better if v3 had a different distribution name, >> so that systems with v2.7.x are not upgraded (especially if there will be >> future releases if v2.7). We sent out several notices about this prior to doing it. The Puppet Labs repositories are designed to be the place you get the latest software from Puppet Labs. This was a conscious choice. > > Could you please file an issue (with impact data) about the > distribution name issue. I believe we considered doing what you > describe, but decided against it. I don't know the reasons off the > top of my head though, an issue will give us a clear place to track > the request, the impact it has on you and your organization, and the > decision we come to (or have already come to). > >> I am concerned about things breaking. So is there a document detailing >> incompatibilities? Will there be future 2.7 releases? There will be. I'd imagine you'll see activity slow on it though. > > There will be future releases of 2.7. We will continue to fix bugs in > the 2.7 series, but we are intending to avoid adding any new features > or make any large changes to the behavior of Puppet 2.7. > > Hope this helps, > -Jeff > > -- > 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] is_virtual selector
I too have been pushed into Puppet 3.0. Clients and PuppetMaster are now
at 3.0.0. Not sure if this is a version change or syntax error that I am
experiencing. We'll use 'ntp' as the example and the "build" host is a VM.
The old way:
class baseline::ntpd {
package { "ntp":
ensure => $virtual ? {
physical => present,
vmware => purged,
default => present
}
}
On the client, it always says that it is created, even though it's not
present:
[root@build ~]# puppet agent -tv
Info: Retrieving plugin
Info: Caching catalog for build
Info: Applying configuration version '1349227476'
/Stage[main]/Baseline::Ntpd/Package[ntp]/ensure: created
Finished catalog run in 1.46 seconds
[root@build ~]#
[root@build ~]# rpm -q ntp
package ntp is not installed
[root@build ~]#
When trying the $is_virtual facter..
class baseline-testing::ntpd {
package { "ntp":
ensure => $is_virtual ? {
false => present,
true => purged
}
}
}
On client:
[root@build ~]# puppet agent -tv
Info: Retrieving plugin
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: No matching value for selector param 'true' at
/etc/puppet/manifests/classes/baseline_linux-testing.pp:35 on node build
[root@build ~]#
[root@build ~]# facter | grep virtual
is_virtual => true
virtual => vmware
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/j-ojRf6R83AJ.
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] PROBLEM : Cannot require an Exec
I think it's the expected behavior...
My reading is that if you want Exec["exec-DDD"] being run only when
Exec["exec-CCC"] have run, and at the same time, Exec["exec-CCC"] has
refreshonly attribute, then it's not require the way, it's set it to
refreshonly and tell Exec["exec-CCC"] to notify Exec["exec-"].
When you require exec-CCC from exec-DDD, puppet will make sure of place
exec-CCC before exec-DDD, but if exec-CCC does not run, be it for a ifonly
non true, be it for been a refreshonly type without notice, it will
continue anyway.
Metaparameters page (
http://docs.puppetlabs.com/references/stable/metaparameter.html) says:
>
> This is used purely for guaranteeing that changes to required objects
happen before the dependent object"
>
The word "happen" here is tricky, I would say then than happen means "are
parsed and run if needed".
Or... I'm more lost than I thought with puppet and my english still sucks :)
Cheers
Guzman
On Tue, Oct 2, 2012 at 9:32 PM, Miguel Di Ciurcio Filho <
miguel.fi...@gmail.com> wrote:
> On Tue, Oct 2, 2012 at 5:36 PM, am-aaron wrote:
> >
> > exec { "exec-AAA":
> > command => "/bin/true",
> > returns => 0,
> > notify => Exec["exec-BBB"],
> > }
> > exec { "exec-BBB":
> > refreshonly => true,
> > command => "/bin/false",
> > returns => 0,
> > notify => Exec["exec-CCC"],
> > }
> > exec { "exec-CCC":
> > refreshonly => true,
> > command => "/bin/touch /tmp/CCC",
> > returns => 0,
> > }
> >
> > exec { "exec-DDD":
> > require => Exec["exec-CCC"],
> > command => "/bin/true",
> > returns => 0,
> > notify => Exec["exec-EEE"],
> > }
>
> I tested your code and indeed, it is a strange behavior.
>
> I guess the root cause of the problem is the `refreshonly => true` of
> exec-CCC.
>
> My reading of the situation:
> - exec-BBB runs and fails, sending nothing to exec-CCC.
> - exec-CCC has `refreshonly => true`, since exec-BBB has failed, it
> does nothing.
> - exec-DDD runs, even having `require => Exec['exec-CCC']` which has
> not received a notify because exec-BBB failed.
>
> I did a test using the chaining syntax and the behavior is the same:
>
> Exec['exec-AAA'] ~> Exec['exec-BBB'] ~> Exec['exec-CCC'] ->
> Exec['exec-DDD']
>
> # puppet apply test.pp
> /Stage[main]//Exec[exec-AAA]/returns: executed successfully
> Error: /Stage[main]//Exec[exec-BBB]: Failed to call refresh:
> /bin/false returned 1 instead of one of [0]
> Error: /Stage[main]//Exec[exec-BBB]: /bin/false returned 1 instead of one
> of [0]
> /Stage[main]//Exec[exec-DDD]/returns: executed successfully
>
> Exec['exec-CCC'] does not receive a notification and does not run
> because exec-BBB failed. Although, it fulfills the `require`
> relationship with Exec['exec-DDD'], which runs.
>
> Note: changing the relationship of Exec['exec-CCC'] and
> Exec['exec-DDD'] from `require` para `notify` does not solve the
> problem, the behavior is the same.
>
> Very odd. The documentation about `exec` does not say anything about
> this behavior of `refreshonly` [1].
>
> [1] http://docs.puppetlabs.com/references/stable/type.html#exec
>
> --
> 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.
>
>
--
GuruHub - Guzmán Brasó
http://www.guruhub.com.uy - +59898674020
Rivera 3565 - CP11400 - Montevideo, Uruguay
--
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 Forge Happenings
Hello, If you weren't at PuppetConf or didn't catch my talk, here's a quick recap. I'm product owner for the Puppet Forge team which formed in July with 2 awesome engineers and an equally awesome designer. We're a team dedicated to the Forge and while ramping up, we've shipped three small improvements to the Forge that we hope you enjoy. * Two lists were added to the homepage, highlighting recently active modules and contributors * An authors Gravatar is now displayed on each module page. * Today, the Forge will now retrieve information about GitHub issues and pull requests for a module for display on a module page. This has been automatically enabled for any module that lists GitHub as its 'Project Issue Tracker URL'. The team is just getting started. In the mean-time, we've been making improvements to our back-end services, user-testing new feature ideas and getting ready for the next wave of functionality. Our next features will focus on these two areas. A) Making it easy for you to contribute your module & B) Improve the information you have to make a decision about which module to use. As we develop and test ideas to address these goals, we want your feedback! Feel free to file bugs, features --anything really-- to our Redmine project: https://projects.puppetlabs.com/projects/module-site/issues Aside from that and this user list, you may always email me directly -- r...@puppetlabs.com -- or find me on #puppet as ryancoleman. I'm always connected via ZNC so if you don't get an immediate response in IRC, know that I'll see your message and reply if I can. Finally, if you haven't tried out the Forge in a while, please give it another go. http://forge.puppetlabs.com -- Each day new content is added or updated and there's some truly awesome stuff amongst the 500+ Forge modules. There's also a blog-post series showcasing a new one each week. links.puppetlabs.com/motw Thanks for your time and for being an awesome community! --Ryan -- 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: Passing http_proxy_host option
hmm I get the concept of the wrapper script, though I'm not too sure how/where to implement within Vagrant. I haven't had much luck on the Vagrant forums, so instead I've decided to simply run a Vagrant reload after it fails the first time (that gives puppet the chance to update bashrc with the proxy, subsequent runs work just fine as you'd expect. I believe puppet not honouring the http_proxy_host option it has is the real issue, though with this workaround in place, I can live with it. On Tuesday, October 2, 2012 12:59:56 AM UTC+10, jcbollinger wrote: > > > > On Sunday, September 30, 2012 11:40:42 PM UTC-5, drew khoury wrote: >> >> May have spoken too soon. >> >> If I set the env variable, and I'm manually logged, then I run puppet all >> is good. >> >> I'm still not clear on how I set the env variable when puppet is invoked >> from Vagrant (this might end up being a question for Vagrant not puppet?). >> > > > Yes, that would be a Vagrant question. You could, however, have Vagrant > invoke a wrapper script that sets the desired variable instead of invoking > "puppet apply" directly. I'm not sure how that differs from what you tried > but it should work. Something like this: > > #!/bin/bash > export http_proxy=my.proxy > puppet apply "$@" > > > >> >> Setting the env variable in a bash script invoked via the puppet manifest >> proved to be useless, as it doesn't have any scope OUTSIDE the bash script. >> > > > Indeed not. That's why you need to put the Puppet invocation inside the > script. > > > >> >> I've tried a combination of setting the variable in /home/vagrant/.bashrc >> AND keeping the env via env_keep in sudoers but I'm not sure I'm >> understanding how Vagrant is invoking Puppet. >> > > > Command runners typically are very careful and selective about the > environment they provide to commands they run. Puppet is a good example, > and likely Vagrant is, too. Such programs normally have a way to configure > the environment for each command along with the command itself, and they > usually provide little or nothing else in those environments. In > particular, they normally do not pass on their own environment to commands. > > > John > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/9JTtpL-CwUIJ. 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] Puppet 3.0 deprecates the kick command
On Tue, Oct 2, 2012 at 9:06 PM, Corby Wilson wrote: > I use the command "puppet kick" to do remote triggers of a 60 node cluster. > In the new release (3.0) it deprecated the command and the command fails > with: > Error: Host lcms-dn1.aws.tie.noklab.net failed: Error 400 on SERVER: Could > not find indirection 'run' > > (I use Passenger on Apache) > > The web page it gives for reference: > http://links.puppetlabs.com/puppet-kick-deprecation > is a dummy to the deprecation bug. > > What are we supposed to use to remote trigger puppet reloads? > I've dropped puppet kick (and even the agents) in favor of using pssh. If you use something like pssh -h clientlist -o out -e err "puppet agent --test" you can more easily browse the results afterwards. You can even set the parallelism, so you don't choke the master or the network. -- 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] Set variable value
On 02.10.2012 20:02, Darvin Denmian wrote: Hi, Is it possible to set the value of a variable from the content of a text file? Regards. See the file() function. D. -- 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.
