[Puppet Users] Re: puppet certificate generate fails for mcollective client
I had this issue as well. To get around it you can pass an extra option:
--certname
This way it won't try to use your current host's FQDN as the certname
(which will fail if it's already registered with the CA)
So, e.g.
puppet certificate generate treydock --certname treydock
On Tuesday, March 25, 2014 at 6:58:46 PM UTC-4, treydock wrote:
>
> Following the mcollective documentation [1] for adding clients to execute
> mco commands when using SSL I am getting an error executing the 'puppet
> certificate generate' command as my user account. I feel like I'm missing
> something very obvious here.
>
> $ puppet certificate generate treydock --ssldir
> ~/.mcollective.d/credentials --ca-location remote --ca_server
> puppet.
> Error: The certificate retrieved from the master does not match the
> agent's private key.
> Certificate fingerprint:
> E3:EA:FA:AD:68:53:D8:AF:DB:63:C9:2A:89:CC:68:AA:4F:B2:35:F6:9F:8C:E0:3C:3F:56:D5:1F:41:45:0D:53
> To fix this, remove the certificate from both the master and the agent and
> then start a puppet run, which will automatically regenerate a certficate.
> On the master:
> puppet cert clean login3.
> On the agent:
> rm -f /home/treydock/.mcollective.d/credentials/certs/login3..pem
> puppet agent -t
>
> Error: Try 'puppet help certificate generate' for usage
>
> This happens from all my systems.
>
> The host 'login3' puppet.conf (comments removed):
>
> $ cat /etc/puppet/puppet.conf
> [main]
> logdir = /var/log/puppet
> rundir = /var/run/puppet
> ssldir = $vardir/ssl
> privatekeydir = $ssldir/private_keys { group = service }
> hostprivkey = $privatekeydir/$certname.pem { mode = 640 }
> autosign = $confdir/autosign.conf { mode = 664 }
>
> [agent]
> classfile = $vardir/classes.txt
> localconfig = $vardir/localconfig
> default_schedules = false
>
> report= true
> pluginsync= true
> masterport= 8140
> environment = production
> certname = login3.brazos.tamu.edu
> server= puppet.brazos.tamu.edu
> listen= false
> splay = false
> runinterval = 3600
> noop = true
> show_diff = true
> configtimeout = 120
>
> Thanks
> - Trey
>
> [1] -
> http://docs.puppetlabs.com/mcollective/deploy/standard.html#managing-client-credentials
>
--
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/682a6987-c601-41b8-85f0-68847d4c0e64%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Sending facts out-of-band natively
For anyone that's interested, here's what I ended up doing: I created a new Puppet face called 'maintenance' with an 'enter' and 'exit' action. When you 'enter' maintenance mode, it runs the 'config' face to set 'noop' to 'true' (by default in the agent section, but you can specify). This way, all of the standard agent processing logic runs (reports, etc.), except the host won't apply any config changes. Operationally, our team is just going to deprecate usage of 'puppet agent --disable' and instead use this custom command for maintenance/troubleshooting activities. On Thursday, September 11, 2014 10:11:10 AM UTC-4, Jon McKenzie wrote: > > Hi all, > > We're thinking about implementing the "puppet facts upload" pattern to > send facts up to the Puppetmaster (and into Foreman) out-of-band. > Basically, we need a way to distinguish hosts which are alive, but just > have their agent disabled (e.g. for troubleshooting), and hosts which are > just not communicating with the Puppet infrastructure. We'd also like to > keep up-to-date inventory information (we have a few dozen custom facts > which we need to report on) despite the status (enabled/disabled) of the > puppet agent. > > It's surprising that this functionality isn't just accomplished > automatically. But now, since Puppet 4 is deprecating the inventory > service, the above solution will likely need to change. But the suggestion > in the deprecation documentation that users simply write a script to parse > the facts into the PuppetDB wire format and send them along seems like a > pretty big step backwards from a usability point of view. It seems a little > crazy that an end user has to deal with something so low-level to > accomplish something that the Puppet agent can (and does) already do. The > interface goes from 1 touchpoint (the 'puppet facts' command) to about four > (get the current facts, format the facts into PuppetDB wire, retrieve the > puppetdb server hostname from .. who knows where, configuration?, make the > request to the PuppetDB API). > > Is there room in this equation for a different agent run mode, one where > the Puppet modules don't get applied, but the rest of the workflow (facts, > etc.) still executes? Is there a better way of accomplishing this? > > Thoughts? > > Thanks > -- 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/fd3fd128-c998-47f9-bf13-2c7e7826943f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Sending facts out-of-band natively
Hi all, We're thinking about implementing the "puppet facts upload" pattern to send facts up to the Puppetmaster (and into Foreman) out-of-band. Basically, we need a way to distinguish hosts which are alive, but just have their agent disabled (e.g. for troubleshooting), and hosts which are just not communicating with the Puppet infrastructure. We'd also like to keep up-to-date inventory information (we have a few dozen custom facts which we need to report on) despite the status (enabled/disabled) of the puppet agent. It's surprising that this functionality isn't just accomplished automatically. But now, since Puppet 4 is deprecating the inventory service, the above solution will likely need to change. But the suggestion in the deprecation documentation that users simply write a script to parse the facts into the PuppetDB wire format and send them along seems like a pretty big step backwards from a usability point of view. It seems a little crazy that an end user has to deal with something so low-level to accomplish something that the Puppet agent can (and does) already do. The interface goes from 1 touchpoint (the 'puppet facts' command) to about four (get the current facts, format the facts into PuppetDB wire, retrieve the puppetdb server hostname from .. who knows where, configuration?, make the request to the PuppetDB API). Is there room in this equation for a different agent run mode, one where the Puppet modules don't get applied, but the rest of the workflow (facts, etc.) still executes? Is there a better way of accomplishing this? Thoughts? Thanks -- 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/574e25ff-e2be-4328-94d1-2dc7ab25285b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: puppet node find doesn't return classes and scope vars ?
https://tickets.puppetlabs.com/browse/PUP-1185 On Thursday, December 19, 2013 7:49:08 AM UTC-5, Felix.Frank wrote: > > Is there an issue for this in Jira? If not, it would be much appreciated > for either of you to create one. > > Thanks, > Felix > > On 12/13/2013 11:08 PM, Paul Archer wrote: > > I see that puppet 3.3.2 has the problem as well. Worse, the > > documentation for 'puppet node' doesn't match the actual command. > > > > > > On Friday, December 13, 2013 11:13:26 AM UTC-6, Jon McKenzie wrote: > > > > Re-upping this topic rather than creating a new one. > > > > I'm using Puppet 3.3.1 and am still having this 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/d8ab6651-45c5-45ea-846b-c1e2d874885d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: puppet node find doesn't return classes and scope vars ?
Re-upping this topic rather than creating a new one. I'm using Puppet 3.3.1 and am still having this problem. For example, if I run: puppet node find $(puppet config print certname) --render-as yaml The resulting YAML is missing ENC-set parameters (among other things). On the other hand, if I call the Puppet server's REST API (e.g. a GET to https://puppet:8140/production/node/), I *do* get the ENC-set parameters. I'd like to use the provided command-line tool to do this, but it doesn't seem to be working correctly. Am I missing something? Thanks! On Friday, April 5, 2013 4:14:36 AM UTC-4, Mohit Chawla wrote: > > Hi, > > I am trying to use the node subcommand like so: > > puppet node find --terminus rest --render-as yaml --mode master foo.com > > This only shows facts, name, environment, expiration and time but not the > classes or node level variables. > > Puppet version is 2.7.20. Any suggestions ? > -- 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/8441d5dd-8207-4f3a-9fce-6f8ab872b199%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Class declaration ordering causes duplicate resource error
Thanks for the replies and being patient with me!
Maybe I'm thinking about this incorrectly, but it seems to me that
announcing a dependency ("I need x defined somewhere in order to work
properly") shouldn't require a class to declare the dependency as well. It
seems to me that the dependent class should not have to know anything about
how a particular dependency is defined, just that it is defined.
As an analogy to RPM package dependencies, if I have a package called
Django that requires a package which provides the "python" capability, the
Django package shouldn't need to include it's own version of Python. It
should be able to re-use any package which has the capability.
What does one have to do with the other?
>
You were suggesting using auto-lookups via Hiera to populate class
parameters, but we're using Foreman to populate those parameters. AFAIK,
there's no interoperability between Foreman's ENC and Hiera (without
writing my own).
Jon
--
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/e76b49ff-70f0-4b18-8b41-ecf853acef65%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Re: Class declaration ordering causes duplicate resource error
Thanks John,
Unfortunately, we're using Foreman in our shop for the ENC, so using Hiera
is currently not possible (AFAIK)
For some reason, I thought the "require" statement was analogous to the
"require" metaparameter. But looking at the documentation, clearly that's
not the case. Still, this seems like a bug to me. If this is a duplicate
declaration, shouldn't it error regardless of the ordering within the
manifest?
Anyways, would writing something like this work?
class { "foo::bar":
Class["foo:baz"] -> Class["foo::bar"]
}
On Friday, November 15, 2013 5:27:11 PM UTC-5, jcbollinger wrote:
>
>
>
> On Friday, November 15, 2013 10:08:54 AM UTC-6, Jon McKenzie wrote:
>>
>> Has anyone run into this issue before?
>> http://projects.puppetlabs.com/issues/5046#note-17
>>
>> Is there something obvious that I'm missing?
>>
>
>
> Yes. The 'require' function is a form of class declaration, functionally
> equivalent to 'include' + an automatic relationship. You therefore do have
> multiple declarations of class foo::baz: one in foo::bar and one in
> foo::bam. As long as the parameterized-style declaration is evaluated
> first, all is well, but otherwise you will get a duplicate declaration
> error.
>
> This general problem is one of my principal reasons for advising folks to
> not use parameterized-style class declarations, as I have done since
> parameterized classes were introduced. In Puppet 3 you can usefully create
> and use parameterized classes without using parameterized-style
> declarations by relying on automatic parameter binding through Hiera.
>
>
> 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/813a4c7c-f7b8-4d9a-9620-430a8c2f307d%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Class declaration ordering causes duplicate resource error
Has anyone run into this issue before? http://projects.puppetlabs.com/issues/5046#note-17 Is there something obvious that I'm missing? -- 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/400dd448-7a55-48b3-a1ca-1cf49cfddb2e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[Puppet Users] Node collecting its own exported resource
I'm writing a module in which nodes export a concat::fragment, collect all
other nodes' analogous resource, and populate a config file (in this case,
the krb5.conf for MIT Kerberos).
It seems that nodes are not able to collect their own resource, but they
can collect every other resource, with a given tag. I've validated that all
of the appropriate resources exist
in the storeconfigs database.
I've been doing some searching, and have read some things that suggest
there might be a regression in this area, but I haven't found anything
definitive.
I know the documentation states that nodes can in fact collect their own
exported resources, but I haven't been able to get this working.
I've also tried it with just a plain "file" resource (rather than a
concat::fragment), e.g. inside a given class:
@@file { "/tmp/export-${::fqdn}":
tag => "testexport",
}
File <<| tag == "testexport" |>>
This also produces the same behavior.
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/-/huzwZYKfZs4J.
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] Question: Custom puppet type for semanage, converting inputs to flags?
Hi Dan, Thanks for the input. If I were to implement this in the provider, what would be the proper way to do that? Is there a validation/conversion hook I can override? On Sunday, September 9, 2012 1:55:17 PM UTC-4, Dan Bode wrote: > > > > On Sun, Sep 9, 2012 at 10:46 AM, Jon McKenzie > > wrote: > >> Hi, >> >> I'm just trying to get an idea about the best way to implement this: >> >> I want a type that uses the 'semanage' binary to manage targeted policy >> (in this case for files). >> >> So for example to create a targeted policy, I might do something like: >> >> semanage fcontext -a -f -d -t some_domain_t "/path/to/files(/.*)?" >> >> ... which would add a target policy that sets 'some_domain_t' on all >> directories in "/path/to/files/" >> >> The question I have is about the "-d", which is a parameter to "-f", that >> directs policy to only cover directories (e.g. "-d" is for directories, >> "--" is for regular files, "-s" is for sockets, etc. -- see the help for >> semanage for the rest). >> >> I want a property called :filetype that can have a value of :file, >> :directory, :all, :socket, :character, :block, etc. Once I get valid input, >> I want to convert the value to the appropriate flag for the command. What's >> the best way to do this? >> >> My current idea is to accept any input, and then have a case switch >> inside of a munge block, e.g.: >> >> munge do |value| >> case value >> when "file" >> value = "--" >> when "directory" >> value = "-d" >> ... etc.. >> end >> end >> >> Is this the "correct" way to implement this? > > > The syntax here looks correct. You may also want to use newvalues to > restrict the values that are allowed. > > >> Should this even be in the type definition (since these are details of >> the provider)? >> > > That is a really good point. It would be more consistent with the model if > this munging was done in the provider. Of coarse in only really 'matters' > if you think the type will have multiple providers. > > >> >> Thanks for your help, >> Jon >> >> -- >> 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/-/1PVDZB_Cw2QJ. >> 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/-/5nVGbDoO7bAJ. 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: Could not render to pson: undefined method 'merge' for []:Array
I restarted my puppetmaster and this seemed to resolve the issue. Very
strange message, though. I suppose if I've defined a new type, but haven't
restarted puppetmaster it throws a message like this? I will need to test
that though
On Sunday, September 9, 2012 4:16:53 PM UTC-4, Jon McKenzie wrote:
>
> I'm having this issue as well, with a nearly identical stack trace (I'm
> running on RHEL, however).
>
> Anyone have any ideas?
>
> I stuck some debugs inside my provider methods, but they don't ever seem
> to get executed.
>
> On Wednesday, July 11, 2012 4:08:42 PM UTC-4, Micah Martin wrote:
>>
>> This ones got me absolutely scratching my head. I'm trying to created a
>> custom type for managing couchbase. It may not be the right approach but
>> I'm a total noob and I'm trying to figure this thing out. Here's what I
>> have:
>>
>> */Puppet/manifests/site.pp*
>>
>> node 'qamachine' {
>>
>> include webserver
>>
>> }
>>
>>
>>
>> */Puppet/modules/webserver/init.pp*
>>
>> class webserver {
>>
>> couchbase { 'test': }
>>
>> }
>>
>>
>> */Puppet/modules/couchbase/lib/puppet/type/couchbase.rb*
>>
>> Puppet::Type.newtype(:couchbase) do
>>
>> newparam(:name) do
>>
>> isnamevar
>>
>> end
>>
>> end
>>
>>
>> */Puppet/modules/couchbase/lib/puppet/provider/couchbase/couchbase.rb*
>>
>> Puppet::Type.type(:couchbase).provide(:couchbase) do
>>
>>
>>
>> end
>>
>>
>>
>> When I try to update the machine this is what I get:
>>
>> info: Loading downloaded plugin
>> C:/ProgramData/PuppetLabs/puppet/var/lib/puppet/type/couchbase.rb
>> info: Loading downloaded plugin
>> C:/ProgramData/PuppetLabs/puppet/var/lib/puppet/provider/couchbase/couchbase.rb
>> debug: Reloading couchbase couchbase provider
>> debug: catalog supports formats: b64_zlib_yaml dot pson raw yaml; using
>> pson
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:56:in `deserialize'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:120:in `find'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/indirector/indirection.rb:196:in `find'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/configurer.rb:240:in `retrieve_new_catalog'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/util.rb:490:in `thinmark'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/sys/ruby/lib/ruby/1.8/benchmark.rb:308:in `realtime'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/util.rb:489:in `thinmark'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/configurer.rb:239:in `retrieve_new_catalog'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/configurer.rb:86:in `retrieve_catalog'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/configurer.rb:112:in
>> `retrieve_and_apply_catalog'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/configurer.rb:152:in `run'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/agent.rb:43:in `run'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/agent/locker.rb:21:in `lock'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/agent.rb:43:in `run'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/sys/ruby/lib/ruby/1.8/sync.rb:230:in `synchronize'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/agent.rb:43:in `run'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/agent.rb:95:in `with_client'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/agent.rb:41:in `run'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/application.rb:172:in `call'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/application.rb:172:in `controlled_run'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/agent.rb:39:in `run'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/application/agent.rb:337:in `onetime'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/puppet/application/agent.rb:311:in `run_command'
>> C:/Program Files (x86)/Puppet
>> Labs/Puppet/puppet/lib/p
[Puppet Users] Re: Could not render to pson: undefined method 'merge' for []:Array
I'm having this issue as well, with a nearly identical stack trace (I'm
running on RHEL, however).
Anyone have any ideas?
I stuck some debugs inside my provider methods, but they don't ever seem to
get executed.
On Wednesday, July 11, 2012 4:08:42 PM UTC-4, Micah Martin wrote:
>
> This ones got me absolutely scratching my head. I'm trying to created a
> custom type for managing couchbase. It may not be the right approach but
> I'm a total noob and I'm trying to figure this thing out. Here's what I
> have:
>
> */Puppet/manifests/site.pp*
>
> node 'qamachine' {
>
> include webserver
>
> }
>
>
>
> */Puppet/modules/webserver/init.pp*
>
> class webserver {
>
> couchbase { 'test': }
>
> }
>
>
> */Puppet/modules/couchbase/lib/puppet/type/couchbase.rb*
>
> Puppet::Type.newtype(:couchbase) do
>
> newparam(:name) do
>
> isnamevar
>
> end
>
> end
>
>
> */Puppet/modules/couchbase/lib/puppet/provider/couchbase/couchbase.rb*
>
> Puppet::Type.type(:couchbase).provide(:couchbase) do
>
>
>
> end
>
>
>
> When I try to update the machine this is what I get:
>
> info: Loading downloaded plugin
> C:/ProgramData/PuppetLabs/puppet/var/lib/puppet/type/couchbase.rb
> info: Loading downloaded plugin
> C:/ProgramData/PuppetLabs/puppet/var/lib/puppet/provider/couchbase/couchbase.rb
> debug: Reloading couchbase couchbase provider
> debug: catalog supports formats: b64_zlib_yaml dot pson raw yaml; using
> pson
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:56:in `deserialize'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/indirector/rest.rb:120:in `find'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/indirector/indirection.rb:196:in `find'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/configurer.rb:240:in `retrieve_new_catalog'
> C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:490:in
> `thinmark'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/sys/ruby/lib/ruby/1.8/benchmark.rb:308:in `realtime'
> C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/util.rb:489:in
> `thinmark'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/configurer.rb:239:in `retrieve_new_catalog'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/configurer.rb:86:in `retrieve_catalog'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/configurer.rb:112:in
> `retrieve_and_apply_catalog'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/configurer.rb:152:in `run'
> C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:43:in
> `run'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/agent/locker.rb:21:in `lock'
> C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:43:in
> `run'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/sys/ruby/lib/ruby/1.8/sync.rb:230:in `synchronize'
> C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:43:in
> `run'
> C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:95:in
> `with_client'
> C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:41:in
> `run'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/application.rb:172:in `call'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/application.rb:172:in `controlled_run'
> C:/Program Files (x86)/Puppet Labs/Puppet/puppet/lib/puppet/agent.rb:39:in
> `run'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/application/agent.rb:337:in `onetime'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/application/agent.rb:311:in `run_command'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/application.rb:309:in `run'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/application.rb:416:in `hook'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/application.rb:309:in `run'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/application.rb:407:in `exit_on_fail'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/application.rb:309:in `run'
> C:/Program Files (x86)/Puppet
> Labs/Puppet/puppet/lib/puppet/util/command_line.rb:69:in `execute'
> C:/Program Files (x86)/Puppet Labs/Puppet/puppet/bin/puppet:4
> err: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Could not render to pson: undefined method `mer
> ge' for []:Array
>
> when I remove the call to couchbase in the init.pp file it works fine.
>
--
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/-/5nFH3c0T45oJ.
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] Question: Custom puppet type for semanage, converting inputs to flags?
Hi, I'm just trying to get an idea about the best way to implement this: I want a type that uses the 'semanage' binary to manage targeted policy (in this case for files). So for example to create a targeted policy, I might do something like: semanage fcontext -a -f -d -t some_domain_t "/path/to/files(/.*)?" ... which would add a target policy that sets 'some_domain_t' on all directories in "/path/to/files/" The question I have is about the "-d", which is a parameter to "-f", that directs policy to only cover directories (e.g. "-d" is for directories, "--" is for regular files, "-s" is for sockets, etc. -- see the help for semanage for the rest). I want a property called :filetype that can have a value of :file, :directory, :all, :socket, :character, :block, etc. Once I get valid input, I want to convert the value to the appropriate flag for the command. What's the best way to do this? My current idea is to accept any input, and then have a case switch inside of a munge block, e.g.: munge do |value| case value when "file" value = "--" when "directory" value = "-d" ... etc.. end end Is this the "correct" way to implement this? Should this even be in the type definition (since these are details of the provider)? Thanks for your help, Jon -- 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/-/1PVDZB_Cw2QJ. 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: Manually creating class resource in site.pp works, calling same class from ENC silently fails
Hi,
I found what my issue was. I knew it would likely be something silly (it
almost always is.. ).
Basically my ENC reads out of a set of YAML files to determine a node's
configuration. The particular class wasn't working because its YAML config
was 0640 and not 0644. My ENC script will silently skip the YAML config if
it isn't readable (will now remedy that..).
Thanks for your help
-Jon
On Friday, August 24, 2012 9:11:57 AM UTC-4, Jon McKenzie wrote:
>
> I altered my ENC script to get rid of the {} on empty params, and instead
> follow what's prescribed in the documentation. Still no good.
>
> Also, if I run the puppet node command you gave me on the master, the
> classes appear correct. When I run 'puppet --test --noop' on the client,
> though, it still is only getting a subset of the defined ENC classes.
>
> I've tried stopping and restarting the web server as well, which doesn't
> appear to have any effect.
>
> I'm not sure what's going on
>
> On Thursday, August 23, 2012 8:37:24 PM UTC-4, Jon McKenzie wrote:
>>
>>
>>> It should be:
>>>
>>> ---
>>> classes:
>>> foobar:
>>>
>>>
>>>
>> I thought the {} might be the issue too, however that* is* valid YAML
>> (my ENC is a ruby script that just calls .to_yaml on a constructed hash).
>> If that's indeed the issue, I think
>> that should probably be considered a bug. I think whatever's taking the
>> output of the ENC should not get confused between a nil and an empty hash
>> (what happened to duck typing? :-))
>>
>> I will try it tomorrow. However if I remember correctly (I was bogged
>> down with other things yesterday as well), I did try passing dummy
>> parameters too, e.g.
>>
>> ---
>> classes:
>> foobar:
>> foo: bar
>>
>> ... and this also did not work.
>>
>> And thanks for the puppet node command! I did not know about that. I'll
>> give that a go as well
>>
>> On Thursday, August 23, 2012 7:40:46 PM UTC-4, Nick Fagerlund wrote:
>>>
>>> Oh wait, also!
>>>
>>> On Thursday, August 23, 2012 1:12:03 PM UTC-7, Jon McKenzie wrote:
>>>>
>>>>
>>>> Is there a way on the server side to validate the ENC -> class
>>>> transformation for clients? I can see in the logs when the ENC script gets
>>>> run, but there's not much other detail
>>>>
>>>>
>>>>
>>> Yeah, get the node object at the command line on your puppet master.
>>>
>>> $ sudo puppet node find screech.magpie.lan --mode master --render-as yaml
>>>
>>> ...where screech.magpie.lan is the node name. It'll have a 'classes'
>>> key which will be either an array or a hash depending on how your ENC was
>>> rigged.
>>>
>>
--
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/-/Y2v6Z1IcebgJ.
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: Manually creating class resource in site.pp works, calling same class from ENC silently fails
I altered my ENC script to get rid of the {} on empty params, and instead
follow what's prescribed in the documentation. Still no good.
Also, if I run the puppet node command you gave me on the master, the
classes appear correct. When I run 'puppet --test --noop' on the client,
though, it still is only getting a subset of the defined ENC classes.
I've tried stopping and restarting the web server as well, which doesn't
appear to have any effect.
I'm not sure what's going on
On Thursday, August 23, 2012 8:37:24 PM UTC-4, Jon McKenzie wrote:
>
>
>> It should be:
>>
>> ---
>> classes:
>> foobar:
>>
>>
>>
> I thought the {} might be the issue too, however that* is* valid YAML (my
> ENC is a ruby script that just calls .to_yaml on a constructed hash). If
> that's indeed the issue, I think
> that should probably be considered a bug. I think whatever's taking the
> output of the ENC should not get confused between a nil and an empty hash
> (what happened to duck typing? :-))
>
> I will try it tomorrow. However if I remember correctly (I was bogged down
> with other things yesterday as well), I did try passing dummy parameters
> too, e.g.
>
> ---
> classes:
> foobar:
> foo: bar
>
> ... and this also did not work.
>
> And thanks for the puppet node command! I did not know about that. I'll
> give that a go as well
>
> On Thursday, August 23, 2012 7:40:46 PM UTC-4, Nick Fagerlund wrote:
>>
>> Oh wait, also!
>>
>> On Thursday, August 23, 2012 1:12:03 PM UTC-7, Jon McKenzie wrote:
>>>
>>>
>>> Is there a way on the server side to validate the ENC -> class
>>> transformation for clients? I can see in the logs when the ENC script gets
>>> run, but there's not much other detail
>>>
>>>
>>>
>> Yeah, get the node object at the command line on your puppet master.
>>
>> $ sudo puppet node find screech.magpie.lan --mode master --render-as yaml
>>
>> ...where screech.magpie.lan is the node name. It'll have a 'classes' key
>> which will be either an array or a hash depending on how your ENC was
>> rigged.
>>
>
--
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/-/OUlNoARM7DsJ.
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: Manually creating class resource in site.pp works, calling same class from ENC silently fails
>
>
> It should be:
>
> ---
> classes:
> foobar:
>
>
>
I thought the {} might be the issue too, however that* is* valid YAML (my
ENC is a ruby script that just calls .to_yaml on a constructed hash). If
that's indeed the issue, I think
that should probably be considered a bug. I think whatever's taking the
output of the ENC should not get confused between a nil and an empty hash
(what happened to duck typing? :-))
I will try it tomorrow. However if I remember correctly (I was bogged down
with other things yesterday as well), I did try passing dummy parameters
too, e.g.
---
classes:
foobar:
foo: bar
... and this also did not work.
And thanks for the puppet node command! I did not know about that. I'll
give that a go as well
On Thursday, August 23, 2012 7:40:46 PM UTC-4, Nick Fagerlund wrote:
>
> Oh wait, also!
>
> On Thursday, August 23, 2012 1:12:03 PM UTC-7, Jon McKenzie wrote:
>>
>>
>> Is there a way on the server side to validate the ENC -> class
>> transformation for clients? I can see in the logs when the ENC script gets
>> run, but there's not much other detail
>>
>>
>>
> Yeah, get the node object at the command line on your puppet master.
>
> $ sudo puppet node find screech.magpie.lan --mode master --render-as yaml
>
> ...where screech.magpie.lan is the node name. It'll have a 'classes' key
> which will be either an array or a hash depending on how your ENC was
> rigged.
>
--
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/-/vy0CAL46eE8J.
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] Manually creating class resource in site.pp works, calling same class from ENC silently fails
I have a simple class, call it "foobar". It has two simple resources, a
file and an augeas call to edit sysctl.conf.
When I run my ENC script against a node, the class appears in the resulting
YAML, e.g.
---
classes:
foobar: {}
However, when I call 'puppetd --test' on the client side, this class is not
included in the catalog. If I cat classes.txt, it's also not listed. There
are no error messages.
I've enabled trace logging for my puppetmaster, and I also do not see
anything erroneous.
I should note that I have other classes hooked up through my ENC for the
exact same node, and they are working fine.
Now, if I manually create this class as a resource, e.g. "class { "foobar":
}" in my site.pp, the class gets compiled and runs just fine.
I'm running puppet 2.7.18-1 from the puppetlabs-provided RPMs.
Is there a way on the server side to validate the ENC -> class
transformation for clients? I can see in the logs when the ENC script gets
run, but there's not much other detail
Thanks!
Jon
--
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/-/vkeKbjdht24J.
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.
