[Puppet Users] Re: Installation problem (PE 3.0.0 on RHEL 6.4 x64)
> > > Hello, I had the exact same issue. The problem was Postgres, its need to be able to resolve localhost. Added "127.0.0.1 localhost.localdomain localhost" to /etc/hosts - problem fixed. Once Puppet was installed, I removed the above entry - and pe-postgresql wouldn't start. Added localhost back in - and pe-postgresql starts... Cheers, Paul. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fde0dd83-9210-447d-ad11-45607111aa7a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] trouble sharing a file in a module
On Tue, Jan 7, 2014 at 5:00 PM, Tim Dunphy wrote:
> hey all,
>
>
> Having a little trouble sharing a file as part of a module I'm attempting to
> use.
>
> This is the error that I'm seeing:
>
> [root@beta:~] #puppet agent --test --server puppet.mydomain.com
> info: Caching catalog for beta.jokefire.com
> info: Applying configuration version '1389142209'
> err:
> /Stage[main]/Cassandra/File[/etc/alternatives/cassandrahome/conf/cassandra.yaml]:
> Could not evaluate: Could not retrieve information from environment
> production source(s)
> puppet:///modules/cassandra/etc/alternatives/cassandrahome/conf/cassandra.yaml
> at /etc/puppet/modules/cassandra/manifests/init.pp:12
> notice: Finished catalog run in 1.62 seconds
>
> Here is the class definition in the module I've created to share a cassandra
> configuration file and ensure that the service is running:
>
>
> [root@puppet:/etc/puppet] #cat modules/cassandra/manifests/init.pp
> class cassandra {
>service { cassandra:
> ensure => running,
> }
>
>
>file { "/etc/alternatives/cassandrahome/conf/cassandra.yaml":
> owner => "root",
> group => "root",
> mode => 0440,
> source =>
> "puppet:///modules/cassandra/etc/alternatives/cassandrahome/conf/cassandra.yaml",
> }
> }
>
>
> Here is the file I am trying to server on the puppet server:
>
> [root@puppet:/etc/puppet] #ls -l
> modules/cassandra/file/etc/alternatives/cassandrahome/conf/cassandra.yaml
> -r--r- 1 puppet puppet 30876 Jan 7 19:42
> modules/cassandra/file/etc/alternatives/cassandrahome/conf/cassandra.yaml
Hi Tim,
I think you want the directory 'file' to be named 'files', e.g.
`/etc/puppet/modules/cassandra/files`
>
> The file is physically there and the permissions and ownership seem right to
> me.
>
> Can anyone please help me with this error?
>
> Thanks
> Tim
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CAOZy0e%3DtKLkPu9EHaaEEF9NjSReqrgLVgoXpurEyFcq0tL6fig%40mail.gmail.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
Moses Mendoza
Puppet Labs
Join us at PuppetConf 2014, September 23-24 in San Francisco
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CA%2B421Wbc6XQusY-2QPO090x%3DNecjeK5KXA54sGTigBfhSWvYeA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] trouble sharing a file in a module
hey all,
Having a little trouble sharing a file as part of a module I'm attempting
to use.
This is the error that I'm seeing:
[root@beta:~] #puppet agent --test --server puppet.mydomain.com
info: Caching catalog for beta.jokefire.com
info: Applying configuration version '1389142209'
err:
/Stage[main]/Cassandra/File[/etc/alternatives/cassandrahome/conf/cassandra.yaml]:
Could not evaluate: Could not retrieve information from environment
production source(s)
puppet:///modules/cassandra/etc/alternatives/cassandrahome/conf/cassandra.yaml
at /etc/puppet/modules/cassandra/manifests/init.pp:12
notice: Finished catalog run in 1.62 seconds
Here is the class definition in the module I've created to share a
cassandra configuration file and ensure that the service is running:
[root@puppet:/etc/puppet] #cat modules/cassandra/manifests/init.pp
class cassandra {
service { cassandra:
ensure => running,
}
file { "/etc/alternatives/cassandrahome/conf/cassandra.yaml":
owner => "root",
group => "root",
mode => 0440,
source =>
"puppet:///modules/cassandra/etc/alternatives/cassandrahome/conf/cassandra.yaml",
}
}
Here is the file I am trying to server on the puppet server:
[root@puppet:/etc/puppet] #ls -l
modules/cassandra/file/etc/alternatives/cassandrahome/conf/cassandra.yaml
-r--r- 1 puppet puppet 30876 Jan 7 19:42
modules/cassandra/file/etc/alternatives/cassandrahome/conf/cassandra.yaml
The file is physically there and the permissions and ownership seem right
to me.
Can anyone please help me with this error?
Thanks
Tim
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAOZy0e%3DtKLkPu9EHaaEEF9NjSReqrgLVgoXpurEyFcq0tL6fig%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Upgrading from 2x to 3x while simultaneously learning Puppet
I'm new here, and to Puppet also. I've inherited some Puppet 2x code in an SVN repo at my work, and have the daunting task of sorting out whether we can/should use "what we have", or if we should upgrade/rewrite everything from scratch on Puppet 3x. Obviously there are pros and cons of each approach. We have to manage about 40 servers with the setup. *Are there any dead giveaways to tell what version of Puppet this code was written for?* In analyzing the puppet code that I have access to, it appears it was built for Puppet 2.6 or 2.7 but I can't tell for sure. (Of course code comments would be great if there were any.) Does it matter? *Anyone have any good puppet 2x to 3x upgrade guides/notes/links?* What would be killer is a complete list of changes and example code like if you did it this way in Puppet 2x then this is how you do that in Puppet 3x. Wishful thinking maybe. *Do any meta-data upgrade tools exist?* I have a lot of /extdata/ folders containing CSVs. I assume that this should be re-done with Heira for Puppet 3.4. I've read the Puppet 3x upgrade docs and lots of blog posts about upgrading puppet, but it doesn't mention much about upgrading your own Puppet code and data sources. *Should I start from scratch?* I see here that the puppet code I'm looking at was built by hand for SLES & Zypper with a custom RPM (I don't have access to) and we're using a different OS now. (CentOS mainly), so I'm not sure there's really any value to "what we have" beyond study as example code of how things used to be done. *How do I tell what files, services, packages are managed by Puppet?* I've found a few tools that scan puppet code to find resources (files) managed by puppet, but I'd also like to know which packages, services, users and ssh keys are managed by puppet. This is on a VM we have running Puppet 2.6. Suggestions here would be very helpful. Ref: http://somethingsinistral.net/blog/the-angry-guide-to-puppet-3/ http://www.olindata.com/blog/2013/12/case-upgrading-pre-puppet-3x-without-roles-and-profiles-rewriting-instead-refactoring -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0f54d1e4-6839-431b-9a8a-098dda7d3346%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] getting error on puppet plugin download
Hi, I am getting the following error when i execute "puppet plugin download" root@osbuild:/etc/puppet/manifests# puppet plugin download err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate: Error 403 on SERVER: Forbidden request: osbuild.iplabs.att.com(192.xxx.yyy.106) access to /file_metadata/plugins [search] at line 99 err: /File[/var/lib/puppet/lib]: Could not evaluate: Error 403 on SERVER: Forbidden request: osbuild.iplabs.att.com(192.xxx.yyy106) access to /file_metadata/plugins [find] at line 99 Could not retrieve file metadata for puppet://osbuild.iplabs.att.com/plugins: Error 403 on SERVER: Forbidden request: osbuild.iplabs.att.com(192.xxx.yyy.106) access to /file_metadata/plugins [find] at line 99 No plugins downloaded. How do i resolve this ? Thanks Bhavin -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5e778c4f-7df9-4dc0-93e0-3be2f3268070%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Announce: Puppet 2.7.25 is available
Released January 7, 2014. 2.7.25 is a bugfix release in the Puppet 2 series. Please note that this release is supported by the community; Puppet Labs is not responsible for maintaining the release. This release fixes: Andrew Parker (1): 233e80 (Maint) Add rake task for running specs on win Dominic Cleal (1): 3ea78c (PUP-1255) Fix assumed default file mode to 0644 Kylo Ginsberg (1): 4e10a0 (PUP-1255) Don't use POSIX defaults on Windows Sam Kottler (2): c2acac (PUP-1351) Load ext/packaging/packaging.rake instead of ext/packaging/tasks/** b1b29a Bump the version to 2.7.25 Puppet 2.7.25 Downloads -- Source: https://downloads.puppetlabs.com/puppet/puppet-2.7.25.tar.gz Available in native package format in the Puppet Labs yum and apt repositories: http://yum.puppetlabs.com and http://apt.puppetlabs.com Gems are available via rubygems at https://rubygems.org/downloads/puppet-2.7.25.gem or by using `gem install puppet` Please note that there are no longer DMG's or MSI's available for the 2.7 series. Users still on 2.7 using Puppet on OSX or Windows with the aforementioned native packaging formats should upgrade to the 3.x series as soon as possible. Please report feedback via the Puppet Labs tickets site, using an affected puppet version of 2.7.25: https://tickets.puppetlabs.com/browse/PUP -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAPO4y0RyiAVqWHhunFiz5hLPrrJYYjD2rT24POAGOAvsVzq%3Dyw%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] sudo class not found
>
> init.pp should be inside the manifests folder.
Yup! That did it. All set!
[root@puppet:~] #puppet agent --test
Info: Retrieving plugin
Info: Caching catalog for puppet.mydomain.com
Info: Applying configuration version '1389080461'
Notice: Finished catalog run in 0.42 seconds
Thanks for the clue-by-four! :)
Tim
On Tue, Jan 7, 2014 at 2:28 AM, Andrey Kozichev wrote:
> init.pp should be inside the manifests folder.
> On 7 Jan 2014 07:03, "Tim Dunphy" wrote:
>
>> Hey all,
>>
>> I'm attempting to follow along with the puppet pro book. And I'm trying
>> to create my first module without much success.
>>
>> This is the error that I'm getting when I do a puppet run:
>>
>> [root@puppet:/etc/puppet] #puppet agent --test
>> Info: Retrieving plugin
>> Error: Could not retrieve catalog from remote server: Error 400 on
>> SERVER: Could not find class sudo for puppet.jokefire.com on node
>> puppet.jokefire.com
>> Warning: Not using cache on failed catalog
>> Error: Could not retrieve catalog; skipping run
>>
>> This is where I'm setting my modules directory to be stored in the
>> puppet.conf file:
>>
>> ## Where puppet keeps it's modules
>> modulepath = $confdir/modules
>>
>> This is my modules dir
>>
>> root@puppet:/etc/puppet] #ls -ld /etc/puppet/modules
>> drwxr-xr-x 5 puppet puppet 4096 Jan 7 01:33 /etc/puppet/modules
>>
>>
>> And the contents thereof:
>>
>> [root@puppet:/etc/puppet] #ls -l /etc/puppet/modules
>> total 8
>> drwxr-xr-x 3 puppet puppet 4096 Jan 7 01:33 mysql
>> drwxr-xr-x 6 puppet puppet 4096 Jan 7 01:54 sudo
>>
>> Contents of sudo
>>
>> [root@puppet:/etc/puppet] #ls -l modules/sudo/
>> total 16
>> drwxr-xr-x 4 puppet puppet 4096 Jan 7 01:33 files
>> -rw-r--r-- 1 puppet puppet 399 Jan 7 01:54 init.pp
>> drwxr-xr-x 3 puppet puppet 4096 Jan 7 01:33 manifests
>> drwxr-xr-x 3 puppet puppet 4096 Jan 7 01:33 templates
>>
>> And this is what /etc/puppet/modules/sudo/init.pp looks like:
>>
>> [root@puppet:/etc/puppet] #cat modules/sudo/init.pp
>> class sudo {
>>package { sudo:
>> ensure => present,
>> }
>>
>> if $operatingsystem == "Ubuntu" {
>> package { "sudo-ldap":
>> ensure => present,
>> require => Package["sudo"],
>> }
>> }
>>
>>file { "/etc/sudoers":
>> owner => "root",
>> group => "root",
>> mode => 0440,
>> source => "puppet:///modules/sudo/etc/sudoers",
>> require => Package["sudo"],
>> }
>> }
>>
>>
>> I'm on puppet 3.4.1 and CentOS release 6.5
>>
>> Can anyone please help me out as to why my puppet server isn't finding
>> this module?
>>
>> Thanks
>> Tim
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to puppet-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/puppet-users/CAOZy0emU2Sx-MLxjn%3D_qRQyF4GURgUucKvzUrVi%3DCARs62hBtw%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/CACzr%3DFfKSBzMaeGPUaerNAM%3DuBTaL3y1eC%2B_DHnPT2HcPozp9Q%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CAOZy0entWymf%3DMG1MoLXm8pp1zpUxK_Cx2Udn3LcOGze6uLwtA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] PuppetDB 1.6.0-rc1 Now available
** Release Candidate ** PuppetDB 1.6.0-rc1 Prerelease: PuppetDB 1.6.0 is not yet released * RC1: January 7th, 2014. PuppetDB 1.6.0-rc1 Downloads Available in native package format in the pre-release repositories at: http://yum.puppetlabs.com and http://apt.puppetlabs.com For information on how to enable the Puppet Labs pre-release repos, see: http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#enabling-the-prerelease-repos Binary tarball: http://downloads.puppetlabs.com/puppetdb/ Source: http://github.com/puppetlabs/puppetdb Please report feedback via the Puppet Labs tickets site, using an affected PuppetDB version of 1.6.0-rc1: https://tickets.puppetlabs.com/browse/PDB Documentation: http://docs.puppetlabs.com/puppetdb/1.6 Puppet module: http://forge.puppetlabs.com/puppetlabs/puppetdb PuppetDB 1.6.0 Release Notes PuppetDB 1.6.0 is a performance and bugfix release. Things to take note of before upgrading: * There are a number of database migrations performed upon first startup. This will require extra free disk space on your PostgreSQL server while we rebuild some tables, so make sure you have enough free space _before_ you start the upgrade. Since a full table migration takes a copy of the old table, a good rule of thumb would be to check your current database usage (using du -sh on the database directory for example) and ensure you have as much free space on that partition. While all migrations are protected by an atomic database transaction, it never hurts to backup your database beforehand just in case. * Also due to the migrations that will take place, it might take several minutes (depending on the size of your database) before PuppetDB can respond to requests again. Give the migration ample time to complete and you should be fine. * Make sure all your PuppetDB instances are shutdown and only upgrade one at a time. * As usual, don’t forget to upgrade your puppetdb-terminus package also (on the host where your Puppet Master lives), and restart your master service. * This is primarily a performance release, so we’re interested in any feedback (good or bad) as to how helpful these changes have been especially around catalog hash-miss performance and general updates on the database. Most of the performance improvements are around facts and catalogs, so we don’t expect any improvements for report storage this time around. Notable improvements and fixes: * (PDB-81) Deprecate JDK6. It's been EOL for quite some time. * (#21083) Differential fact storage Previously when facts for a node were replaced, all previous facts for that node were deleted and all new facts were inserted. Now existing facts are updated, old facts (no longer present) are deleted and new facts are inserted. This results in much less I/O, both because we have to write much less data and also because we reduce churn in the database tables, allowing them to stay compact and fast. * (PDB-68) Differential edge storage Previously when a catalog wasn't detected as a duplicate, we'd have to reinsert all edges into the database using the new catalog's hash. This meant that even if 99% of the edges were the same, we'd still insert 100% of them anew and wait for our periodic GC to clean up the old rows. We now only modify the edges that have actually changed, and leave unchanged edges alone. This results in much less I/O as we touch substantially fewer rows. * (PDB-69) Differential resource storage Previously when a catalog wasn't detected as a duplicate, we'd have to reinsert all resource metadata into the catalog_resources table using the catalog's new hash. Even if only 1 resource changed out of a possible 1000, we'd still insert 1000 new rows. We now only modify resources that have actually changed. This results in much less I/O in the common case. * Streaming resource and fact queries. Previously, we'd load all rows from a resource or fact query into RAM, then do a bunch of sorting and aggregation to transform them into a format that clients expect. That has obvious problems involving RAM usage for large result sets. Furthermore, this does all the work for querying up-front...if a client disconnects, the query continues to tax the database until it completes. And lastly, we'd have to wait until all the query results have been paged into RAM before we could send anything to the client. New streaming support massively reduces RAM usage and time-to-first-result. Note that currently only resource and fact queries employ streaming, as they're the most frequently-used endpoints. * Improvements to our deduplication algorithm. We've improved our deduplication algorithms to better detect when we've already stored the necessary data. Early reports from the field has show users who previously had deduplication rates in the 0-10% range jumping up to the 60-70% range. This has a massi
Re: [Puppet Users] Augeus: Duplicate "sysctl" setting
On 1/6/14 9:28 AM, bruce bushby wrote:
> Hello
>
> I have a issue with duplicate Augeas settings and hoping to bounce the
> issue off the community for some ideas.
>
> I like to "pre-deploy" my servers regardless of what application they
> will run and I typically have them sitting in
> (/etc/puppet/manifest/classes/-linux-server) where they remain until
> they are moved into an "application class" which then adds
> additional modules
>
> My "base" setup does not allow ip_forwarding:
> [root@puppetdev-stc development]# grep net.ipv4.ip_forward
> defaults/manifests/config.pp
> sysctl { 'net.ipv4.ip_forward': value => '0', comment => 'this is a
> comment' }
> [root@puppetdev-stc development]#
>
> However, I have an application that does require ip_forwarding .and
> when I add the "application layer" I get a conflict:
>
> Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Duplicate declaration: Sysctl[net.ipv4.ip_forward] is already
> declared in file
> /etc/puppet/modules/development/defaults/manifests/config.pp:4; cannot
> redeclare at
> /etc/puppet/modules/development/wombat/manifests/config.pp:5 on node
> puppet-client..xxx.xx
>
>
> How can I force puppet to simply execute the sysctl settings in order (I
> use requires to control module order) ...meaning the last setting will
> become the valid setting?
>
>
> Thanks
> Bruce
Hi Bruce,
Recommend that you move the data from your current pattern of defaults
and application names into Hiera. You can then use your application name
as a hierarchy level in Hiera to supply different data based on the
application name.
Your method of getting into a pre-deploy state and then moving into a
deploy state is also potentially dangerous. If you manage any resources
in the pre-deploy state that are not in the deploy state, then you
cannot simply run Puppet with the deploy level code to reach the end
system state that you desire. Ideally you would classify the node and
get it into one state instead of your method of getting it into one
state and then into another through the use of different code paths and
data in Puppet.
BR,
-g
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/52CC58D9.6050507%40garretthoneycutt.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: mco package fail with puppet 3.4.0
https://tickets.puppetlabs.com/browse/MCO-144 It's fixed in package agent 4.2.1 (not yet pushed to yum repo, alas) Jeff On 01/07/2014 01:18 PM, Nikolay Georgieff wrote: Same issue here. [root@puppet ucla_gateway]# mco package puppet update -F foreman_env=testing -v Discovering hosts using the redisdiscovery method 58 / [ ==> ] 29 / 58 The package application failed to run, use -v for full error details: undefined class/module Puppet:: undefined class/module Puppet:: (ArgumentError) from /usr/libexec/mcollective/mcollective/security/psk.rb:27:in `load' < from /usr/libexec/mcollective/mcollective/security/psk.rb:27:in `decodemsg' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/message.rb:182:in `decode!' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:93:in `receive' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:152:in `req' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:151:in `loop' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:151:in `req' from /usr/lib/ruby/1.8/timeout.rb:67:in `timeout' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:148:in `req' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/rpc/client.rb:834:in `call_agent' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/rpc/client.rb:255:in `method_missing' from /usr/libexec/mcollective/mcollective/application/package.rb:63:in `send' from /usr/libexec/mcollective/mcollective/application/package.rb:63:in `main' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/application.rb:287:in `run' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/applications.rb:23:in `run' from /usr/bin/mco:20 [root@puppet ucla_gateway]# On Friday, December 27, 2013 7:03:06 AM UTC-8, Glenn Poston wrote: I can confirm this. Same issue here. On Thursday, December 26, 2013 1:54:33 PM UTC-5, Fabrice Bacchella wrote: When I upgrade a node with puppet 3.4.0, puppet-package is broken : ~$ mco package puppet status -I $(facter hostname) -v | [ > ] 0 / 1 The package application failed to run, use -v for full error details: undefined class/module Puppet:: undefined class/module Puppet:: (ArgumentError) from /usr/libexec/mcollective/mcollective/security/psk.rb:27:in `load' < from /usr/libexec/mcollective/mcollective/security/psk.rb:27:in `decodemsg' from /usr/lib/ruby/site_ruby/1.8/mcollective/message.rb:182:in `decode!' from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:93:in `receive' from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:152:in `req' from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:151:in `loop' from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:151:in `req' from /usr/lib/ruby/1.8/timeout.rb:67:in `timeout' from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:148:in `req' from /usr/lib/ruby/site_ruby/1.8/mcollective/rpc/client.rb:851:in `call_agent' from /usr/lib/ruby/site_ruby/1.8/mcollective/rpc/client.rb:244:in `method_missing' from /usr/libexec/mcollective/mcollective/application/package.rb:63:in `send' from /usr/libexec/mcollective/mcollective/application/package.rb:63:in `main' from /usr/lib/ruby/site_ruby/1.8/mcollective/application.rb:285:in `run' from /usr/lib/ruby/site_ruby/1.8/mcollective/applications.rb:23:in `run' from /usr/bin/mco:20 I'm running this on a up to date scientific linux 6.4 with up to date mcollective and puppet rpm directly from puppet labs : ~# rpm -qa | grep -e puppet -e mcollective mcollective-package-agent-4.2.0-1.noarch mcollective-package-client-4.2.0-1.noarch mcollective-2.2.4-1.el6.noarch puppet-3.4.0-1.el6.noarch puppetlabs-release-6-7.noarch mcollective-common-2.2.4-1.el6.noarch mcollective-client-2.2.4-1.el6.noarch mcollective-puppet-common-1.6.0-1.noarch mcollective-puppet-client-1.6.0-1.noarch mcollective-package-common-4.2.0-1.noarch -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9d4589aa-b7c5-47a4-b738-b38eb3e2a12d%40googlegroups.com. For more opt
Re: [Puppet Users] Hiera and puppet apply/puppet agent
---
:backends:
- yaml
- file
:hierarchy:
- defaults
- "%{clientcert}"
- "%{::domain}/%{::environment}/%{::osfamily}/%{::lsbdistcodename}"
- global
:yaml:
:datadir: /etc/puppet/data
On Tuesday, January 7, 2014 12:05:46 PM UTC-6, Andrew wrote:
>
>
> Content of the yaml file - any quotes there which might cause issues?
> Try puppet master compile for the node - is it failing as well?
>
>> What version of Puppet are you running?
>> *3.4.1 for both master and agent*
>> As what user is the master running? (Typically an unprivileged user
>> named 'puppet'.)
>> *The master is running as user puppet*
>> As what user are you running the agent in your tests?
>> *I am running the agent and the apply commands on the master as the root
>> user*
>> As what user are you running "puppet apply" in your tests?
>> *root*
>> What are the ownership and permissions of /etc/puppet/data/loc.example.
>> com/production/Debian/wheezy.yaml and all the directories in the path to
>> it? Do any of those have extended ACLs set on them?
>> *The permissions of the directory and the yaml file are root:root. No
>> ALC's. I chown-ed then to puppet:puppet with the same result.*
>> Are you running SELinux in enforcing mode? If so, then do you see
>> relevant AVC messages in the system log?
>> *This is a Debian Wheezy, so no selinux or apparmor on it.*
>>
>> The bellow works fine with this:
>
> $ puppet apply --debug --environment=production -e '$test =
> hiera('ssh_service_config') notify { $::test: }'
> Debug: hiera(): Hiera YAML backend starting
> Debug: hiera(): Looking up ssh_service_config in YAML backend
> Debug: hiera(): Looking for data source defaults
> Debug: hiera(): Looking for data source puppetmaster.iad3.example.com
> Debug: hiera(): Cannot find datafile
> /etc/puppet/data/puppetmaster.iad3.example.com.yaml, skipping
> Debug: hiera(): Looking for data source production/Debian/wheezy
> *Debug: hiera(): Found ssh_service_config in production/Debian/wheezy*
>
> but not with
>
> $ pupept agent -tv
> *Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find data item ssh_package_name in any Hiera data file
> and no default supplied at
> /srv/puppet/environments/production/modules/ssh/manifests/install.pp:2 on
> node puppetmaster.iad3.example.com *
>
> :hierarchy:
> - "%{::environment}/%{::osfamily}/%{::lsbdistcodename}" <--- This
> works with puppet apply, but not puppet agent -tv
>
> This is really strange, any help will be greatly appreciated. (Appending
> the domain fact produces the same result)
>
>> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users...@googlegroups.com .
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/2df4b281-7a41-4f16-a59f-34c574ae985f%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/279c0103-970d-468e-8f0a-6485a69f0c33%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hiera and puppet apply/puppet agent
I actually have both variables. On Tuesday, January 7, 2014 11:54:38 AM UTC-6, Jose Luis Ledesma wrote: > > Mmm the error is about ssh_package_name, but you have tried the puppet > apply with ssh_service_name. could be this the problem? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ccc3faa6-d401-47c4-9a77-a8e25009e2d0%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Hiera and puppet apply/puppet agent
Actually I figured it out. The problem was that if I want to use directory
the last element in the hierarchy must not be derived from a fact, so this
works:
:hierarchy:
-
"%{::domain}/%{::environment}/%{::osfamily}/%{::lsbdistcodename}/params"
/etc/puppet/data/loc.example.com/production/Debian/wheezy/params.yaml
where this does not (it works with puppet apply, but not with puppet agent):
:hierarchy:
- "%{::domain}/%{::environment}/%{::osfamily}/%{::lsbdistcodename}"
/etc/puppet/data/loc.example.com/production/Debian/wheezy.yaml
So not sure if this is by design or a bug, but I was not able to find this
in any of the documentation, so putting it here if someone else encounters
it.
On Monday, January 6, 2014 1:20:04 PM UTC-6, kai wrote:
>
> I have the following hiera.yaml file:
>
> ---
> :backends:
> - yaml
> - file
>
> :hierarchy:
> - defaults
> - "%{clientcert}"
> * - "%{::domain}/%{::environment}/%{::osfamily}/%{::lsbdistcodename}"*
> - global
>
> :yaml:
> :datadir: /etc/puppet/data
>
> and the following in /etc/puppet/data:
>
> *loc.example.com/production/Debian/wheezy.yaml
> *
>
> The domain fact returns loc.example.com, the osfamily fact returns Debian
> and the lsbdistcodename returns wheezy.
>
>
> When I run
>
> puppet apply --environment=production -e '$test =
> hiera('ssh_service_config') notify { $test: }'
>
> I get the ssh_service_config variable from the /etc/puppet/data/
> loc.example.com/production/Debian/wheezy.yaml file, which in my mind
> means that the correct file was chosen based on the 3 facts (environment.
> osfamily and lsbdistcodename), which is what I want.
>
> However if I run:
>
> $ puppet agent -tv --environment=production
> Info: Retrieving plugin
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Could not find data item ssh_package_name in any Hiera data file and no
> default supplied at
> /srv/puppet/environments/production/modules/ssh/manifests/install.pp:2 on
> node puppetmaster.iad3.example.com
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
> Or:
>
> $ hiera -d ssh_service_config environment=production osfamily=Debian
> lsbdistcodename=wheezy
> DEBUG: 2014-01-06 19:18:08 +: Hiera YAML backend starting
> DEBUG: 2014-01-06 19:18:08 +: Looking up ssh_service_config in YAML
> backend
> DEBUG: 2014-01-06 19:18:08 +: Looking for data source defaults
> DEBUG: 2014-01-06 19:18:08 +: Looking for data source global
> DEBUG: 2014-01-06 19:18:08 +: Hiera File backend starting
> DEBUG: 2014-01-06 19:18:08 +: Looking up ssh_service_config in File
> backend
> DEBUG: 2014-01-06 19:18:08 +: Hiera File_backend: looking for data
> source 'defaults'
> DEBUG: 2014-01-06 19:18:08 +: Cannot find datafile
> /var/lib/hiera/defaults.d, skipping
> DEBUG: 2014-01-06 19:18:08 +: Hiera File_backend: looking for data
> source 'global'
> DEBUG: 2014-01-06 19:18:08 +: Cannot find datafile
> /var/lib/hiera/global.d, skipping
> nil
>
> Any idea what is going on? I would like to have a simple hierarchy like
> the one in the hiera.yaml file, based on the three facts.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/9fcf5ea1-5328-4acc-9067-84fbed9982c3%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: mco package fail with puppet 3.4.0
Same issue here. [root@puppet ucla_gateway]# mco package puppet update -F foreman_env=testing -v Discovering hosts using the redisdiscovery method 58 / [ ==> ] 29 / 58 The package application failed to run, use -v for full error details: undefined class/module Puppet:: undefined class/module Puppet:: (ArgumentError) from /usr/libexec/mcollective/mcollective/security/psk.rb:27:in `load' < from /usr/libexec/mcollective/mcollective/security/psk.rb:27:in `decodemsg' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/message.rb:182:in `decode!' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:93:in `receive' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:152:in `req' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:151:in `loop' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:151:in `req' from /usr/lib/ruby/1.8/timeout.rb:67:in `timeout' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/client.rb:148:in `req' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/rpc/client.rb:834:in `call_agent' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/rpc/client.rb:255:in `method_missing' from /usr/libexec/mcollective/mcollective/application/package.rb:63:in `send' from /usr/libexec/mcollective/mcollective/application/package.rb:63:in `main' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/application.rb:287:in `run' from /usr/lib/ruby/gems/1.8/gems/stomp-1.2.2/lib/mcollective/applications.rb:23:in `run' from /usr/bin/mco:20 [root@puppet ucla_gateway]# On Friday, December 27, 2013 7:03:06 AM UTC-8, Glenn Poston wrote: > > I can confirm this. Same issue here. > > On Thursday, December 26, 2013 1:54:33 PM UTC-5, Fabrice Bacchella wrote: >> >> When I upgrade a node with puppet 3.4.0, puppet-package is broken : >> >> ~$ mco package puppet status -I $(facter hostname) -v >> >> | [ > ] 0 / >> 1 >> The package application failed to run, use -v for full error details: >> undefined class/module Puppet:: >> >> undefined class/module Puppet:: (ArgumentError) >> from /usr/libexec/mcollective/mcollective/security/psk.rb:27:in >> `load' < >> from /usr/libexec/mcollective/mcollective/security/psk.rb:27:in >> `decodemsg' >> from /usr/lib/ruby/site_ruby/1.8/mcollective/message.rb:182:in >> `decode!' >> from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:93:in >> `receive' >> from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:152:in >> `req' >> from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:151:in >> `loop' >> from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:151:in >> `req' >> from /usr/lib/ruby/1.8/timeout.rb:67:in `timeout' >> from /usr/lib/ruby/site_ruby/1.8/mcollective/client.rb:148:in >> `req' >> from /usr/lib/ruby/site_ruby/1.8/mcollective/rpc/client.rb:851:in >> `call_agent' >> from /usr/lib/ruby/site_ruby/1.8/mcollective/rpc/client.rb:244:in >> `method_missing' >> from >> /usr/libexec/mcollective/mcollective/application/package.rb:63:in `send' >> from >> /usr/libexec/mcollective/mcollective/application/package.rb:63:in `main' >> from >> /usr/lib/ruby/site_ruby/1.8/mcollective/application.rb:285:in `run' >> from >> /usr/lib/ruby/site_ruby/1.8/mcollective/applications.rb:23:in `run' >> from /usr/bin/mco:20 >> >> I'm running this on a up to date scientific linux 6.4 with up to date >> mcollective and puppet rpm directly from puppet labs : >> >> ~# rpm -qa | grep -e puppet -e mcollective >> mcollective-package-agent-4.2.0-1.noarch >> mcollective-package-client-4.2.0-1.noarch >> mcollective-2.2.4-1.el6.noarch >> puppet-3.4.0-1.el6.noarch >> puppetlabs-release-6-7.noarch >> mcollective-common-2.2.4-1.el6.noarch >> mcollective-client-2.2.4-1.el6.noarch >> mcollective-puppet-common-1.6.0-1.noarch >> mcollective-puppet-client-1.6.0-1.noarch >> mcollective-package-common-4.2.0-1.noarch >> > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9d4589aa-b7c5-47a4-b738-b38eb3e2a12d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hiera and puppet apply/puppet agent
Content of the yaml file - any quotes there which might cause issues?
Try puppet master compile for the node - is it failing as well?
> What version of Puppet are you running?
> *3.4.1 for both master and agent*
> As what user is the master running? (Typically an unprivileged user named
> 'puppet'.)
> *The master is running as user puppet*
> As what user are you running the agent in your tests?
> *I am running the agent and the apply commands on the master as the root
> user*
> As what user are you running "puppet apply" in your tests?
> *root*
> What are the ownership and permissions of /etc/puppet/data/loc.example.
> com/production/Debian/wheezy.yaml and all the directories in the path to
> it? Do any of those have extended ACLs set on them?
> *The permissions of the directory and the yaml file are root:root. No
> ALC's. I chown-ed then to puppet:puppet with the same result.*
> Are you running SELinux in enforcing mode? If so, then do you see
> relevant AVC messages in the system log?
> *This is a Debian Wheezy, so no selinux or apparmor on it.*
>
> The bellow works fine with this:
$ puppet apply --debug --environment=production -e '$test =
hiera('ssh_service_config') notify { $::test: }'
Debug: hiera(): Hiera YAML backend starting
Debug: hiera(): Looking up ssh_service_config in YAML backend
Debug: hiera(): Looking for data source defaults
Debug: hiera(): Looking for data source puppetmaster.iad3.example.com
Debug: hiera(): Cannot find datafile
/etc/puppet/data/puppetmaster.iad3.example.com.yaml, skipping
Debug: hiera(): Looking for data source production/Debian/wheezy
*Debug: hiera(): Found ssh_service_config in production/Debian/wheezy*
but not with
$ pupept agent -tv
*Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find data item ssh_package_name in any Hiera data file and no
default supplied at
/srv/puppet/environments/production/modules/ssh/manifests/install.pp:2 on
node puppetmaster.iad3.example.com *
:hierarchy:
- "%{::environment}/%{::osfamily}/%{::lsbdistcodename}" <--- This
works with puppet apply, but not puppet agent -tv
This is really strange, any help will be greatly appreciated. (Appending
the domain fact produces the same result)
> --
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2df4b281-7a41-4f16-a59f-34c574ae985f%40googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CACzr%3DFfVASm%3DOU7ep70th5Pqzrsht0VDo7M-yd7T60cBBrxkJA%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hiera and puppet apply/puppet agent
One more thing to mention is that if I change the hierarchy from being a
directory as mentioned above to just a file like so:
:hierarchy:
- "%{::environment}_%{::osfamily}_%{::lsbdistcodename}"
both puppet apply and puppet agent are able to find the variable.
However if I prepend the "domain" fact like this:
- "%{::domain}_%{::environment}_%{::osfamily}_%{::lsbdistcodename}"
even though it's just a single file again, puppet apply works, but puppet
agent -tv again is not able to find the variable.
This does not make any sense to me and I am starting to wonder if this is a
bug.
On Tuesday, January 7, 2014 11:39:14 AM UTC-6, kai wrote:
>
> What version of Puppet are you running?
>> *3.4.1 for both master and agent*
>> As what user is the master running? (Typically an unprivileged user
>> named 'puppet'.)
>> *The master is running as user puppet*
>> As what user are you running the agent in your tests?
>> *I am running the agent and the apply commands on the master as the root
>> user*
>> As what user are you running "puppet apply" in your tests?
>> *root*
>> What are the ownership and permissions of /etc/puppet/data/
>> loc.example.com/production/Debian/wheezy.yaml and all the directories in
>> the path to it? Do any of those have extended ACLs set on them?
>> *The permissions of the directory and the yaml file are root:root. No
>> ALC's. I chown-ed then to puppet:puppet with the same result.*
>> Are you running SELinux in enforcing mode? If so, then do you see
>> relevant AVC messages in the system log?
>> *This is a Debian Wheezy, so no selinux or apparmor on it.*
>>
>> The bellow works fine with this:
>
> $ puppet apply --debug --environment=production -e '$test =
> hiera('ssh_service_config') notify { $::test: }'
> Debug: hiera(): Hiera YAML backend starting
> Debug: hiera(): Looking up ssh_service_config in YAML backend
> Debug: hiera(): Looking for data source defaults
> Debug: hiera(): Looking for data source puppetmaster.iad3.example.com
> Debug: hiera(): Cannot find datafile
> /etc/puppet/data/puppetmaster.iad3.example.com.yaml, skipping
> Debug: hiera(): Looking for data source production/Debian/wheezy
> *Debug: hiera(): Found ssh_service_config in production/Debian/wheezy*
>
> but not with
>
> $ pupept agent -tv
> *Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find data item ssh_package_name in any Hiera data file
> and no default supplied at
> /srv/puppet/environments/production/modules/ssh/manifests/install.pp:2 on
> node puppetmaster.iad3.example.com *
>
> :hierarchy:
> - "%{::environment}/%{::osfamily}/%{::lsbdistcodename}" <--- This
> works with puppet apply, but not puppet agent -tv
>
> This is really strange, any help will be greatly appreciated. (Appending
> the domain fact produces the same result)
>
>>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5cf53edf-3d1a-49ea-8cd0-4f3392bfdb17%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppet Agent Callback
Thanks for the response. I shall look into the scheduler. - Ranga On Tuesday, January 7, 2014 6:44:14 AM UTC-8, jcbollinger wrote: > > > > On Monday, January 6, 2014 7:09:01 PM UTC-6, rsreen...@gopivotal.comwrote: >> >> Hi >> >> I am trying to wrap my head around how best to implement the following >> functionality: >> >>- Get information about puppet agent runs as soon as they complete >>- Some kind of a callback mechanism would be ideal >> >> > Calling back to whom? Seriously, I'm not just being picky. I know well > what a callback is in general, but I don't understand what you mean by that > in this context. That leaves me uncertain of the characteristics of your > ideal solution. > > > >> Could this be done by creating an "exported" resource? >> > > > No. Exported resources could conceivably be used to provide information > about catalog compilation, but they have no visibility into details or > completion status of agent runs. > > > >> Or could it be achieved using MCollective? >> > > > Only if you are using MCollective to perform agent runs (in non-daemon > mode) in the first place. If you are running the agent in daemon mode or > via an ordinary scheduler (e.g. cron) then how would MCollective have any > clue? > > > >> Any pointers around this is appreciated. >> >> > > Puppet's built-in reporting mechanism might serve your purpose, as > Aurélien suggested. Alternatively, if you run via a scheduler then you > could put a wrapper script around the agent invocation that sends whatever > information you like, by whatever means you like. > > > John > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c08af660-651f-4009-845c-9bcd093ebc77%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hiera and puppet apply/puppet agent
It is worth mentioning that if I replace this hierarchy:
- "%{::environment}/%{::osfamily}/%{::lsbdistcodename}"
which uses directories with just a single file like so:
- "%{::environment}_%{::osfamily}_%{::lsbdistcodename}"
both puppet apply and puppet agent are able to find the variable.
If I prefix the domain fact like so however:
- "%{::domain}_%{::environment}_%{::osfamily}_%{::lsbdistcodename}"
even though it's still just a single file like above, puppet apply works
but puppet agent -tv breaks again and facter domain returns fine.
I must be really doing something wrong here.
On Tuesday, January 7, 2014 11:39:14 AM UTC-6, kai wrote:
>
> What version of Puppet are you running?
>> *3.4.1 for both master and agent*
>> As what user is the master running? (Typically an unprivileged user
>> named 'puppet'.)
>> *The master is running as user puppet*
>> As what user are you running the agent in your tests?
>> *I am running the agent and the apply commands on the master as the root
>> user*
>> As what user are you running "puppet apply" in your tests?
>> *root*
>> What are the ownership and permissions of /etc/puppet/data/
>> loc.example.com/production/Debian/wheezy.yaml and all the directories in
>> the path to it? Do any of those have extended ACLs set on them?
>> *The permissions of the directory and the yaml file are root:root. No
>> ALC's. I chown-ed then to puppet:puppet with the same result.*
>> Are you running SELinux in enforcing mode? If so, then do you see
>> relevant AVC messages in the system log?
>> *This is a Debian Wheezy, so no selinux or apparmor on it.*
>>
>> The bellow works fine with this:
>
> $ puppet apply --debug --environment=production -e '$test =
> hiera('ssh_service_config') notify { $::test: }'
> Debug: hiera(): Hiera YAML backend starting
> Debug: hiera(): Looking up ssh_service_config in YAML backend
> Debug: hiera(): Looking for data source defaults
> Debug: hiera(): Looking for data source puppetmaster.iad3.example.com
> Debug: hiera(): Cannot find datafile
> /etc/puppet/data/puppetmaster.iad3.example.com.yaml, skipping
> Debug: hiera(): Looking for data source production/Debian/wheezy
> *Debug: hiera(): Found ssh_service_config in production/Debian/wheezy*
>
> but not with
>
> $ pupept agent -tv
> *Error: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find data item ssh_package_name in any Hiera data file
> and no default supplied at
> /srv/puppet/environments/production/modules/ssh/manifests/install.pp:2 on
> node puppetmaster.iad3.example.com *
>
> :hierarchy:
> - "%{::environment}/%{::osfamily}/%{::lsbdistcodename}" <--- This
> works with puppet apply, but not puppet agent -tv
>
> This is really strange, any help will be greatly appreciated. (Appending
> the domain fact produces the same result)
>
>>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/56ad0841-80ff-40a8-95b7-55951b6bc7ae%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hiera and puppet apply/puppet agent
Mmm the error is about ssh_package_name, but you have tried the puppet apply with ssh_service_name. could be this the problem? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c7ffbdaf-52ab-4ef3-b449-b108bcb900c1%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Puppet Agent Callback
Thanks Aurélien. Could you point me to some documentation around this? On Tuesday, January 7, 2014 2:10:35 AM UTC-8, Aurélien Degrémont wrote: > > Le 07/01/2014 02:09, rsreen...@gopivotal.com a écrit : > > Hi > > I am trying to wrap my head around how best to implement the following > functionality: > >- Get information about puppet agent runs as soon as they complete >- Some kind of a callback mechanism would be ideal > > Could this be done by creating an "exported" resource? Or could it be > achieved using MCollective? > Any pointers around this is appreciated. > > > You can try to use the "report" feature. > Puppet will sent a detailled report with a lot of information about what > it has done. > This could be sent in various ways depending on your tuning. You can > implement a callback thanks to this. > > > Aurélien > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3f628c06-a630-427d-9ad5-81447244960d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Alternating results with mount Puppet resource
Hi, I have a problem with a host which has a Puppet class applied to it. The host, a CentOS 6.4 machine, has been provisioned and is managed using Foreman, but I'm not sure this is related to the problem. The class includes a "mount" type resource which should mount a NFS share and add the related line in /etc/fstab. But the existing fstab file on that machine has an error: there is one custom line starting with a space (although I cannot find any official doc stating that this is actually forbidden), and this causes the manual application of the puppet class (puppet agent --test) to *always* fail with the message "Could not evaluate: Field 'device' is required". Up to here, this is ok. The failure is expected behaviour, if the leading space in fstab really is a syntax error. I've read elsewhere that this error does not come from puppet itself, but rather from the OS when puppet tries to "flush" the fstab file. The problem is with automated puppet runs every 30 minutes, as per default: 50% of the runs end with no errors in the report, even though the class is not correctly applied. One report shows the error, the next one does not, the next shows it again, then again not, and so on. This can be very misleading, as you could believe everything is ok by looking at the error-free logs. Any suggestions? Thanks. Marco -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3e7bd2fc-1122-42be-9d00-c91fbc309eea%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hiera and puppet apply/puppet agent
>
> What version of Puppet are you running?
> *3.4.1 for both master and agent*
> As what user is the master running? (Typically an unprivileged user named
> 'puppet'.)
> *The master is running as user puppet*
> As what user are you running the agent in your tests?
> *I am running the agent and the apply commands on the master as the root
> user*
> As what user are you running "puppet apply" in your tests?
> *root*
> What are the ownership and permissions of /etc/puppet/data/
> loc.example.com/production/Debian/wheezy.yaml and all the directories in
> the path to it? Do any of those have extended ACLs set on them?
> *The permissions of the directory and the yaml file are root:root. No
> ALC's. I chown-ed then to puppet:puppet with the same result.*
> Are you running SELinux in enforcing mode? If so, then do you see
> relevant AVC messages in the system log?
> *This is a Debian Wheezy, so no selinux or apparmor on it.*
>
> The bellow works fine with this:
$ puppet apply --debug --environment=production -e '$test =
hiera('ssh_service_config') notify { $::test: }'
Debug: hiera(): Hiera YAML backend starting
Debug: hiera(): Looking up ssh_service_config in YAML backend
Debug: hiera(): Looking for data source defaults
Debug: hiera(): Looking for data source puppetmaster.iad3.example.com
Debug: hiera(): Cannot find datafile
/etc/puppet/data/puppetmaster.iad3.example.com.yaml, skipping
Debug: hiera(): Looking for data source production/Debian/wheezy
*Debug: hiera(): Found ssh_service_config in production/Debian/wheezy*
but not with
$ pupept agent -tv
*Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find data item ssh_package_name in any Hiera data file and no
default supplied at
/srv/puppet/environments/production/modules/ssh/manifests/install.pp:2 on
node puppetmaster.iad3.example.com*
:hierarchy:
- "%{::environment}/%{::osfamily}/%{::lsbdistcodename}" <--- This
works with puppet apply, but not puppet agent -tv
This is really strange, any help will be greatly appreciated. (Appending
the domain fact produces the same result)
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/2df4b281-7a41-4f16-a59f-34c574ae985f%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Hiera and puppet apply/puppet agent
On Monday, January 6, 2014 4:42:54 PM UTC-6, kai wrote: > > Hm nothing in the logs. It's worth mentioning that I run this on the > puppet master. Here's the config in case I missed something there: > > What version of Puppet are you running? As what user is the master running? (Typically an unprivileged user named 'puppet'.) As what user are you running the agent in your tests? As what user are you running "puppet apply" in your tests? What are the ownership and permissions of /etc/puppet/data/loc.example.com/production/Debian/wheezy.yaml and all the directories in the path to it? Do any of those have extended ACLs set on them? Are you running SELinux in enforcing mode? If so, then do you see relevant AVC messages in the system log? John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/fbaba21c-c66e-437a-8334-6ba15d9f6f4c%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Puppet Agent Callback
On Monday, January 6, 2014 7:09:01 PM UTC-6, rsreen...@gopivotal.com wrote: > > Hi > > I am trying to wrap my head around how best to implement the following > functionality: > >- Get information about puppet agent runs as soon as they complete >- Some kind of a callback mechanism would be ideal > > Calling back to whom? Seriously, I'm not just being picky. I know well what a callback is in general, but I don't understand what you mean by that in this context. That leaves me uncertain of the characteristics of your ideal solution. > Could this be done by creating an "exported" resource? > No. Exported resources could conceivably be used to provide information about catalog compilation, but they have no visibility into details or completion status of agent runs. > Or could it be achieved using MCollective? > Only if you are using MCollective to perform agent runs (in non-daemon mode) in the first place. If you are running the agent in daemon mode or via an ordinary scheduler (e.g. cron) then how would MCollective have any clue? > Any pointers around this is appreciated. > > Puppet's built-in reporting mechanism might serve your purpose, as Aurélien suggested. Alternatively, if you run via a scheduler then you could put a wrapper script around the agent invocation that sends whatever information you like, by whatever means you like. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/bbb47db9-5a81-49df-96fb-17297c40753f%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: only subclasses can modify ?
On Tuesday, January 7, 2014 4:12:37 AM UTC-6, Klavs Klavsen wrote:
>
> I'm trying to modify certain users, created with by calling the define
> users::local.
>
> I tried to do it, by calling users::local::modify - but then puppet
> complains that only subclasses may modify.. :(
>
> What am I doing wrong here?
>
You are attempting to modify a declared resource. Although there are
sometimes valid reasons to do so, it is always at least a bit dodgy. I
certainly think it's questionable to establish a general-purpose mechanism
for such, as seems to be the intent here.
As far as the Puppet language goes, the resource override syntax you are
trying to use may only be used in a subclass of the class that originally
declared the target resource. The ability to perform such overrides is the
signature characteristic of Puppet subclasses, though it is rarely
highlighted any more. The concept there is that the subclass refines /
modulates the meaning of its parent class.
And no, defined types are not classes, and thus cannot be subclassed.
You would use that form of override more like so:
class myusers::alice {
users::local { 'alice':
uid => 501,
gid => 'users',
realname => 'Alice A. Anderson'
}
}
class myusers::admin_alice
inherits myusers::alice {
Users::Local['alice'] {
groups => [ 'admin' ]
}
}
Note, too, the conceptual distinction here: in the proposed override via a
defined type, the defined type is named as and serves as a *verb*("modify"),
whereas in the class-based example the classes represent
characteristics of the target node: that 'alice' is among the users, or
more specifically that 'alice' is an administrator.
With all that said, it *is* possible to override a resource declaration
made by an unrelated class via a resource collector. That it's possible
doesn't necessarily make it a good idea, but there are some valid
applications. In your specific case, the syntax would look like this:
User<| title == $title |> { groups => $groups }
Do not overuse.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/4aea1c89-de5f-4012-bf25-716124dbcdfe%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: The Future - ENCs vs Hiera?
- Original Message - > From: "Felix Frank" > To: puppet-users@googlegroups.com > Sent: Tuesday, January 7, 2014 11:08:38 AM > Subject: Re: [Puppet Users] Re: The Future - ENCs vs Hiera? > > This really speaks to me. > > I haven't dabbled in ENCs as of yet, but my natural response to the > question of hiera vs. ENC would be to use the right tool for the > respective job. If the added complexity of using both is acceptable, do > go ahead and use both. > > If I got my history correct, hiera was not intended to be an ENC > alternative or replacement. It did replace extlookup, which in turn was > kind of a crutch for people who didn't want to invest the effort of > creating a full fledged ENC. > > Personally, I agree with most commentors that hiera should not be a > reason to deprecate the ENC concept altogether. Hiera as you say replaced extlookup, primarily by making the backends pluggable and introducing the merging behaviours as a result of Puppet gaining more data types. Hiera is a tool that aims to be good at solving the common data modelling problem many of us have. Our machines and environments map well onto its hierarchical nature and so it gives us the ability put data in a way that maps well to the natural structure of compute environments. When Puppet 3 added the automatic class param lookup feature it make hiera a lot more powerful in concept and really brought the old ENC like hiera_include to full power so today, for most people, a hiera ENC works fine. Given a custom backend that talks to your DB that has a web frontend that administers the data in question you can get very close to what you can with an ENC in terms of friendly UI and such. Notice how I said it's aim is to solve data problems many of us have - not all. It's not intended to solve all data problems for all people. There will always be cases where your environment is too complex or just not hierarchical or whatever. These tend to be people with special needs who would generally not have a problem with doing their own development to solve a problem. So the ENC interface is valuable to this class of user, they have a powerful plugin method to do whatever they like without having to fit into what hiera prefers. Totally think there's a place for both types of people, if hiera saves 80% of us from writing their own ENC (deceptively complex process) then it's been a success, but it's aim is not to replace all ENCs > > Cheers, > Felix > > On 01/06/2014 10:09 AM, simon c wrote: > > For myself, I can see that Hiera is really the way to go, (with a good > > front end), however for where > > I am now on the puppet rollout, asking other admins to create even > > simple json/yaml files for > > each node would not get anywhere. > > > > So, I've got a very simple node terminus ENC script that parses flat > > text files to groups & > > "roles" and anything more complex goes either goes into hiera, or into a > > node specific > > manifest class file. > > > > I quite liked the puppet dashboard as an ENC, but there was no way to > > audit who > > changed what when, which would be unacceptable in our environment. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/52CBE036.8020203%40alumni.tu-berlin.de. > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1013087935.270.1389093861294.JavaMail.zimbra%40devco.net. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] only subclasses can modify ?
It seems defines can't inherit.. the docs are a bit vague, but they seem to indicate that only classes can inherit : http://docs.puppetlabs.com/puppet/2.7/reference/lang_classes.html#inheritance -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cc5c88a8-c437-4b85-a20b-a4b945457275%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: only subclasses can modify ?
but defines can't inherit it seems. The docs are a little vague, but they seem to indicate that only classes can inherit ( http://docs.puppetlabs.com/puppet/2.7/reference/lang_classes.html#inheritance ) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/50b8d6a0-f577-4843-a699-ba8dc83338d0%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Re: The Future - ENCs vs Hiera?
This really speaks to me. I haven't dabbled in ENCs as of yet, but my natural response to the question of hiera vs. ENC would be to use the right tool for the respective job. If the added complexity of using both is acceptable, do go ahead and use both. If I got my history correct, hiera was not intended to be an ENC alternative or replacement. It did replace extlookup, which in turn was kind of a crutch for people who didn't want to invest the effort of creating a full fledged ENC. Personally, I agree with most commentors that hiera should not be a reason to deprecate the ENC concept altogether. Cheers, Felix On 01/06/2014 10:09 AM, simon c wrote: > For myself, I can see that Hiera is really the way to go, (with a good > front end), however for where > I am now on the puppet rollout, asking other admins to create even > simple json/yaml files for > each node would not get anywhere. > > So, I've got a very simple node terminus ENC script that parses flat > text files to groups & > "roles" and anything more complex goes either goes into hiera, or into a > node specific > manifest class file. > > I quite liked the puppet dashboard as an ENC, but there was no way to > audit who > changed what when, which would be unacceptable in our environment. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/52CBE036.8020203%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] only subclasses can modify ?
You need to inherit users::local in users::modify
On 7 Jan 2014 10:12, "Klavs Klavsen" wrote:
> I'm trying to modify certain users, created with by calling the define
> users::local.
>
> I tried to do it, by calling users::local::modify - but then puppet
> complains that only subclasses may modify.. :(
>
> What am I doing wrong here?
>
> Code:
>
> define users::local
> ($uid,$gid,$realname,$groups=[],$pass='',$sshkey="",$shell="/bin/bash",$home="/home/$title")
> {
> user { $title:
> ensure => "present",
> uid => $uid,
> gid => $gid,
> groups => $groups,
> shell => $shell,
> home=> $home,
> comment => $realname,
> password => $pass ? {
> '' => undef,
> default => $pass
> },
> managehome => true,
> }
>
> if ( $sshkey != "" ) {
> ssh_authorized_key { $title:
> ensure => "present",
> type=> dsa,
> key => "$sshkey",
> user=> "$title",
> require => User["$title"],
> name=> "$title",
> }
> }
> }
>
> define users::local::modify
> ($uid='',$gid='',$realname='',$groups=[],$pass='',$sshkey="",$shell="/bin/bash",$home="/home/$title")
> {
> if ( ! empty($groups) ) {
> User[$title] { groups => $groups }
> }
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/77b419a4-e8da-42e8-921e-72156b1816ba%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CACzr%3DFdHA_avBvxioueMqbn5UzaxoEGCHVo%2BxmwCNqvu0BBrBw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] only subclasses can modify ?
I'm trying to modify certain users, created with by calling the define
users::local.
I tried to do it, by calling users::local::modify - but then puppet
complains that only subclasses may modify.. :(
What am I doing wrong here?
Code:
define users::local
($uid,$gid,$realname,$groups=[],$pass='',$sshkey="",$shell="/bin/bash",$home="/home/$title")
{
user { $title:
ensure => "present",
uid => $uid,
gid => $gid,
groups => $groups,
shell => $shell,
home=> $home,
comment => $realname,
password => $pass ? {
'' => undef,
default => $pass
},
managehome => true,
}
if ( $sshkey != "" ) {
ssh_authorized_key { $title:
ensure => "present",
type=> dsa,
key => "$sshkey",
user=> "$title",
require => User["$title"],
name=> "$title",
}
}
}
define users::local::modify
($uid='',$gid='',$realname='',$groups=[],$pass='',$sshkey="",$shell="/bin/bash",$home="/home/$title")
{
if ( ! empty($groups) ) {
User[$title] { groups => $groups }
}
}
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/77b419a4-e8da-42e8-921e-72156b1816ba%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Puppet Agent Callback
Le 07/01/2014 02:09, rsreeniva...@gopivotal.com a écrit : Hi I am trying to wrap my head around how best to implement the following functionality: * Get information about puppet agent runs as soon as they complete * Some kind of a callback mechanism would be ideal Could this be done by creating an "exported" resource? Or could it be achieved using MCollective? Any pointers around this is appreciated. You can try to use the "report" feature. Puppet will sent a detailled report with a lot of information about what it has done. This could be sent in various ways depending on your tuning. You can implement a callback thanks to this. Aurélien -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/52CBD29B.6080309%40cea.fr. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] dashed by dashboard
On Mon, Jan 6, 2014 at 8:51 PM, Stuart Cracraft wrote: > Okay, took care of that. Thanks. > > Now, when doing per page 170 in chapter 7 (chapter puppet consoles) in Pro > Puppet > by Krum et al, I have: > > ruby /usr/share/foreman-installer/generate_answers.rb > We changed the installation process as part of a pretty large overhaul in the Foreman installer that was released in 1.3. You can see the up-to-date installation guide here: http://theforeman.org/manuals/1.3/quickstart_guide.html > > but it does not have a file generate_answers.rb anywhere in the > /usr/share/foreman-installer tree. > > Has anyone else encountered the above? > > > On Monday, January 6, 2014 10:46:57 AM UTC-8, Jose Luis Ledesma wrote: > >> You hace to enable both epel and optional repositories. >> >> Regards, >> > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/d41f912e-2ed0-4efd-9354-a3f1d78c084c%40googlegroups.com > . > > For more options, visit https://groups.google.com/groups/opt_out. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAPO4y0SGQBMxdGe5YwPnSy2ePcnhnqNsZx%2BvJWg3AUzutFCX2g%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] Puppet require - failure handling
Thanks Jose! On Sunday, January 5, 2014 11:27:50 AM UTC-8, Jose Luis Ledesma wrote: > > Clases WordPress requiere both MySQL and apache, so no resource of > WordPress will be "executed" if any of them fails -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/302079be-3494-45ed-a56a-536154b0aca7%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
