[Puppet Users] Installing hiera-eyaml-gpg in Puppetserver

[Raphink]

Hello,


I'm trying to use hiera-eyaml-gpg with the puppetserver.

I've tried installing it with:

sudo -u puppet puppetserver gem install hiera-eyaml-gpg



where puppet is the user running the puppetserver.


However, it fails to compile the native gpgme gem:

Building native extensions.  This could take a while...
ERROR:  Error installing hiera-eyaml-gpg:
 ERROR: Failed to build gem native extension.


java -jar /usr/share/puppetserver/puppet-server-release.jar extconf.rb
Exception in thread "main" java.lang.IllegalStateException: Unable to find 
bootstrap.cfg file via --bootstrap-config command line argument, current 
working directory, or on classpath
 at puppetlabs.trapperkeeper.bootstrap$find_bootstrap_config.invoke(
bootstrap.clj:141)
 at puppetlabs.trapperkeeper.core$boot_with_cli_data.invoke(core.clj:113)
 at puppetlabs.trapperkeeper.core$run.invoke(core.clj:144)
 at puppetlabs.trapperkeeper.core$main.doInvoke(core.clj:159)
 at clojure.lang.RestFn.invoke(RestFn.java:408)
 at clojure.lang.Var.invoke(Var.java:415)
 at clojure.lang.AFn.applyToHelper(AFn.java:161)
 at clojure.lang.Var.applyTo(Var.java:532)
 at clojure.core$apply.invoke(core.clj:617)
 at puppetlabs.trapperkeeper.main$_main.doInvoke(main.clj:7)
 at clojure.lang.RestFn.applyTo(RestFn.java:137)
 at puppetlabs.trapperkeeper.main.main(Unknown Source)




Gem files will remain installed in /var/lib/puppet/jruby-gems/gems/gpgme-2.0
.8 for inspection.
Results logged to /var/lib/puppet/jruby-gems/gems/gpgme-2.0.8/ext/gpgme/
gem_make.out


Is there a way to install native gems inside the Puppetserver to use this 
functionality? What am I missing?


Cheers,

Raphaël

-- 
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/01d460a2-51e2-418c-9ad7-ef1bfb86a76e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Allowing duplicate namevars in custom types

[Raphink]

If more than one parameter make sense for a namevar, then you can use 
composite namevars, by using `isnamevar` for sevaral parameters and adding 
a `self.title_patterns` method to define how to parse the title and feed 
the namevar parameters.

See 
https://github.com/hercules-team/augeasproviders_postgresql/blob/master/lib/puppet/type/pg_hba.rb
 
for an example.




On Wednesday, February 11, 2015 at 6:09:32 PM UTC+1, jwil...@gmail.com 
wrote:
>
> Hi all!
>
> I'm working on a custom type that applies xpaths to files.  I expect the 
> interface to look something like:
>
> xpath { "some update":
>   xpath => "/some/xpath",
>   command => "replace",
>   value => "newvalue",
>   file => "/path/to/file.xml"
> }
>
> I'm having a little trouble picking the namevar.  It seems logical that 
> the xpath attribute should be the namevar, but I'm a little hung up on the 
> fact that it has to be unique among all xpath resources.  In theory, I 
> might want to apply the same xpath to many different files but with 
> different values.  I ran across a mention in the documentation that the 
> exec type allows duplicate namevars, but going through the implementation, 
> it isn't clear to me how that is done.  Is it just a matter of each exec 
> declaration having a unique title but the same command?
>
> Thanks for the help!
>

-- 
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/058c8dfd-515b-4251-9b4a-74c4880411cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Is there a better way to limit module actions based on facts?

[Joseph Karns]

Leam:

Can you reply with your code up too this point. Please include your heira 
file, so I can see the hash.

Thanks
Joey

On Wednesday, February 11, 2015 at 4:49:38 PM UTC-5, leam hall wrote:
>
> On Wed, Feb 11, 2015 at 4:18 PM, Joseph Karns  > wrote: 
> > Hello Leam: 
> > 
> > I think your looking for something like this: 
> > 
> > - 
> > 
> > define sysusers::setup( 
> > $hash 
> > ) { 
> > 
> > 
> > case $::osfamily { 
> > 'redhat': { 
> > $user_home = '/home' 
> > } 
> > 'solaris': { 
> > $user_home = '/export/home' 
> > } 
> > 'default': { 
> > $user_home = '/home' 
> > } 
> > } 
> > 
> > if(!defined(User[$name])) { 
> > user { $name : 
> > home => "${user_home}/$hash[$name]['name'], 
> >   ensure=> $hash[$name]['ensure'], 
> >   comment=> $hash[$name]['comment'], 
> >   expiry=> $hash[$name]['expiry'], 
> >   gid=> $hash[$name]['gid'], 
> > } 
> >   } 
> > } 
> > 
> > --- 
> > 
> > Let me know 
> > 
> > Thanks 
> > Joey 
> > 
>
> Fortunately I'm doing this on one box. It put the entire user hash 
> into each line in /etc/passwd.  Still cleaning up.  :) 
>
> Leam 
>
> -- 
> Mind on a Mission 
>

-- 
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/c897fedb-29dc-4ab0-9545-981d6dbe6dde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Installing hiera-eyaml-gpg in Puppetserver

[Raphink]

https://github.com/puppetlabs/puppet-server/blob/master/documentation/gems.markdown#gems-with-native-c-extensions
 
apparently answers my question, so I'm looking to port hiera-eyaml-gpg to a 
pure ruby module now.

On Thursday, February 12, 2015 at 12:17:41 PM UTC+1, Raphink wrote:
>
> Hello,
>
>
> I'm trying to use hiera-eyaml-gpg with the puppetserver.
>
> I've tried installing it with:
>
> sudo -u puppet puppetserver gem install hiera-eyaml-gpg
>
>
>
> where puppet is the user running the puppetserver.
>
>
> However, it fails to compile the native gpgme gem:
>
> Building native extensions.  This could take a while...
> ERROR:  Error installing hiera-eyaml-gpg:
>  ERROR: Failed to build gem native extension.
>
>
> java -jar /usr/share/puppetserver/puppet-server-release.jar extconf.rb
> Exception in thread "main" java.lang.IllegalStateException: Unable to 
> find bootstrap.cfg file via --bootstrap-config command line argument, 
> current working directory, or on classpath
>  at puppetlabs.trapperkeeper.bootstrap$find_bootstrap_config.invoke(
> bootstrap.clj:141)
>  at puppetlabs.trapperkeeper.core$boot_with_cli_data.invoke(core.clj:113)
>  at puppetlabs.trapperkeeper.core$run.invoke(core.clj:144)
>  at puppetlabs.trapperkeeper.core$main.doInvoke(core.clj:159)
>  at clojure.lang.RestFn.invoke(RestFn.java:408)
>  at clojure.lang.Var.invoke(Var.java:415)
>  at clojure.lang.AFn.applyToHelper(AFn.java:161)
>  at clojure.lang.Var.applyTo(Var.java:532)
>  at clojure.core$apply.invoke(core.clj:617)
>  at puppetlabs.trapperkeeper.main$_main.doInvoke(main.clj:7)
>  at clojure.lang.RestFn.applyTo(RestFn.java:137)
>  at puppetlabs.trapperkeeper.main.main(Unknown Source)
>
>
>
>
> Gem files will remain installed in /var/lib/puppet/jruby-gems/gems/gpgme-
> 2.0.8 for inspection.
> Results logged to /var/lib/puppet/jruby-gems/gems/gpgme-2.0.8/ext/gpgme/
> gem_make.out
>
>
> Is there a way to install native gems inside the Puppetserver to use this 
> functionality? What am I missing?
>
>
> Cheers,
>
> Raphaël
>
>

-- 
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/1f463563-1a20-4c69-8ab3-77b64df0f88b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: facter error esolved to an invalid value

[jcbollinger]

On Wednesday, February 11, 2015 at 7:04:18 AM UTC-6, Robert Reilly wrote:
>
> All, I am getting the following problem with facter on 5 of my nodes,
> Fact resolution fact='enviro', resolution='' resolved to an 
> invalid value: Expected (?-mix:xxx(vs|sv).{2,7}\d{1,2}) to be one of 
> [Integer, Float, TrueClass, FalseClass, NilClass, String, Array, Hash], but 
> was Regexp, this seems to only happen to one application running on rhel 
> 5.8 puppet agent 3.5.1 facter 2.0.1
>
>

Do you have other machines running RHEL 5?  Is it possible that Facter on 
this machine is running under the distribution's Ruby (which is version 
1.8.5, no longer supported by Puppet)?

 

> here is my fact
>
> Facter.add(:enviro) do
> setcode do
>   hostname = Facter.value('hostname')
> if ( hostname =~  /^.{5}d{1}/i )
>enviro="dev"
>enviro
> elsif (hostname =~  /^.{5}q{1}/i )
>   enviro="qa"
>   enviro
> elsif (hostname =~  /^.{4,5}u{1}/i )
>   enviro="uat"
>   enviro
> elsif (hostname =~  /^.{5}p{1}/i )
>   enviro="prod"
>   enviro
> elsif (hostname =~  /^.{5}xxx/i )
>   enviro="prod"
>   enviro
> else
>   enviro="unclassified"
>   enviro
> end
> end
> end
> ~   
>


That's a slightly odd way to write it, but it looks like it should work.  
Note that it is pointless for your blocks to end with "enviro" as a 
standalone statement when the statement immediately preceding is an 
assignment to that variable.  The combination has exactly the same 
semantics as the assignment alone. Also, it is always pointless to use a 
'{1}' quantifier in a regex, as it has the same effect as no quantifier at 
all.

Though I don't see a reason why your fact code should fail, I would 
probably use much simpler code for the job, myself.  Perhaps something like 
this:

Facter.add(:enviro) do
setcode do
   case Facter.value('hostname')
   when /^.{5}d/i
  'dev'
   when /^.{5}q/i
  'qa'
   when /^.{4,5}u/i
  'uat'
   when /^.{5}p/i
  'prod'
   when /^.{5}xxx/i
  'prod'
   else
  'unclassified'
   end
   end
end

Not only is it easier to read, there is much less room for any question 
about its semantics.  There is exactly one (compound) statement at the top 
level of the setcode block, so its value determines the fact value.  There 
are no variable assignments, so it is clear that no value can be carried 
forward from an earlier part of the code to a later part.  Even someone 
with little Ruby experience would have a good chance of understanding what 
it's doing if told that the setcode block produces a value.


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/d3da2294-2cba-4265-819e-ab73b5ad2123%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Allowing duplicate namevars in custom types

[jwilkicki]

I did try to do that for another type I wrote and it was a mess.  I ended 
up having a single namevar that required a particular format that my type 
then processed to get the parameters I needed.  I'll take a look at your 
example; I'm sure I'll learn something from it.  Maybe it's worth another 
stab.

In the meantime, I based my new type on the regular augeas type and the 
exec type and will see if I hit a problem with duplicate namevars.

On Thursday, February 12, 2015 at 8:15:56 AM UTC-5, Raphink wrote:
>
> If more than one parameter make sense for a namevar, then you can use 
> composite namevars, by using `isnamevar` for sevaral parameters and adding 
> a `self.title_patterns` method to define how to parse the title and feed 
> the namevar parameters.
>
> See 
> https://github.com/hercules-team/augeasproviders_postgresql/blob/master/lib/puppet/type/pg_hba.rb
>  
> for an example.
>
>
>
>
> On Wednesday, February 11, 2015 at 6:09:32 PM UTC+1, jwil...@gmail.com 
> wrote:
>>
>> Hi all!
>>
>> I'm working on a custom type that applies xpaths to files.  I expect the 
>> interface to look something like:
>>
>> xpath { "some update":
>>   xpath => "/some/xpath",
>>   command => "replace",
>>   value => "newvalue",
>>   file => "/path/to/file.xml"
>> }
>>
>> I'm having a little trouble picking the namevar.  It seems logical that 
>> the xpath attribute should be the namevar, but I'm a little hung up on the 
>> fact that it has to be unique among all xpath resources.  In theory, I 
>> might want to apply the same xpath to many different files but with 
>> different values.  I ran across a mention in the documentation that the 
>> exec type allows duplicate namevars, but going through the implementation, 
>> it isn't clear to me how that is done.  Is it just a matter of each exec 
>> declaration having a unique title but the same command?
>>
>> Thanks for the help!
>>
>

-- 
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/5742b030-9988-4985-b8be-a65b370e2f46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] use of CNAMES and Puppet/Foreman

[Peter Berghold]

Hi folks,

When I put my Foreman/Puppet architecture into production the requirement I
am working against is to allow the use of "service names" instead of the
fqdn of the host to access Puppet and Foreman.

In my testing in my lab I have generated a cert against (I'm sanitizing
here) the service name pocpuppet.{fqdn} which went well.  I put in the
dns_alternate_names in puppet.conf (where's the right place for that?
main?).

Everything seems to be going smoothly with puppet itself but for whatever
reason the foreman-proxy is looking for the cert with the original fqdn of
the host itself.

I went into every foreman YAML file out there and put the service name in
place of the hostname and it still is looking for the original server.

Anybody else run into this?  Any thoughts.

-- 

Peter L. Berghold   salty.cowd...@gmail.com

h ttp://science-fiction.berghold.net

-- 
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/CAArvnv2k6OzGT%2Bp5N4d%2BDue7Uor5vEfjh0YEGfrsvAu5trjxRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Virtual Resource Visibility

[Peter Berghold]

On Tue, Feb 10, 2015 at 9:21 AM, jcbollinger 
wrote:

> so I have to think that you have some wrong expectation about the effect.
>
>
Based on some reading I did yesterday I must confess that may be true. My
thinking was using that type of declaration made the fact the file was
installed "visible" to other resources.

One of the concerns I have (and not in this particular case) if I were to
declare something like

class apache {
   @package { apache3: ensure => latest}
}

and then in another module

include apache
class somevhost {
   realize Package[apache3]
  blah..blah...blan

and then another module tried to do the same thing what would happen?
Eventually there are going to be other developers working on Puppet modules
in my current environment and I am wondering how to avoid collisions...



-- 

Peter L. Berghold   salty.cowd...@gmail.com

h ttp://science-fiction.berghold.net

-- 
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/CAArvnv3DH9J%3D0JX4ThdFf908LigQM92%3DYf3%3D2nmxjnoEtG6xBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Allowing duplicate namevars in custom types

[jcbollinger]

On Wednesday, February 11, 2015 at 11:09:32 AM UTC-6, jwil...@gmail.com 
wrote:
>
> Hi all!
>
> I'm working on a custom type that applies xpaths to files.  I expect the 
> interface to look something like:
>
> xpath { "some update":
>   xpath => "/some/xpath",
>   command => "replace",
>   value => "newvalue",
>   file => "/path/to/file.xml"
> }
>
> I'm having a little trouble picking the namevar.  It seems logical that 
> the xpath attribute should be the namevar, but I'm a little hung up on the 
> fact that it has to be unique among all xpath resources.  In theory, I 
> might want to apply the same xpath to many different files but with 
> different values.  I ran across a mention in the documentation that the 
> exec type allows duplicate namevars, but going through the implementation, 
> it isn't clear to me how that is done.  Is it just a matter of each exec 
> declaration having a unique title but the same command?
>
>

Multiple Exec resources may have the same command and/or title.  This is a 
hard-coded special case, and other types cannot emulate it.

No physical resource can be identified by an XPath expression alone.  Only 
in the context of an XML file does an XPath expression represent anything 
concrete, and the natural identifier of that thing (or things) is the 
combination of file and XPath expression.  Your type absolutely *begs* for 
a compound namevar.

With that said, I can't say I care for the rest of what I see about your 
type.  In particular, the presence of a 'command' attribute suggests that 
you are trying to model an action on some resource, instead of modeling the 
resource itself.  You probably can make that work, but it runs against 
Puppet's design and mode of operation, which may end up presenting 
practical problems.


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/727e781b-c151-4208-8ba3-d9c9c5cf7efa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Allowing duplicate namevars in custom types

[jwilkicki]

Well, I was thinking of doing a type similar to what xmlstarlet does, 
including being able to add and remove nodes.  I don't really need the 
added behavior of adding and removing nodes from the file right now, so I 
left command as a future expansion parameter, but it basically only accepts 
'replace' and is set to default to that. 

 I'm only doing this type because Augeas doesn't like the particular XML 
file that has the value I need to change, but REXML parses it just fine.  I 
really just want to do what Augeas can do to files, just using XPaths 
instead.  I understand your point about the Puppet way of doing things.  
This type should really be saying "this XML document should have a path 
with this value" and, as my example is written, it looks more imperative 
than that.  In practice, I think will basically be declarative since the 
only operation the type can do is retrieving an existing XPath, comparing 
it to the desired value, and then setting it if it doesn't match.

I haven't had a lot of success getting compound namevars to work.  I've 
added title_patterns to a different custom type before and done all of the 
basically undocumented steps for making it happen and hit a snag in the 
Puppet support code that meant my provider didn't get the values.  I have 
this type doing the XPath operations properly now, so I'll try to go back 
and tweak it according to the postgres example that Raphink linked and see 
if I can get compound namevars to work.  Hopefully you or the group will be 
able to get me on the right path if I can't get them working. :-)

On Thursday, February 12, 2015 at 12:57:18 PM UTC-5, jcbollinger wrote:
>
>
>
> On Wednesday, February 11, 2015 at 11:09:32 AM UTC-6, jwil...@gmail.com 
> wrote:
>>
>> Hi all!
>>
>> I'm working on a custom type that applies xpaths to files.  I expect the 
>> interface to look something like:
>>
>> xpath { "some update":
>>   xpath => "/some/xpath",
>>   command => "replace",
>>   value => "newvalue",
>>   file => "/path/to/file.xml"
>> }
>>
>> I'm having a little trouble picking the namevar.  It seems logical that 
>> the xpath attribute should be the namevar, but I'm a little hung up on the 
>> fact that it has to be unique among all xpath resources.  In theory, I 
>> might want to apply the same xpath to many different files but with 
>> different values.  I ran across a mention in the documentation that the 
>> exec type allows duplicate namevars, but going through the implementation, 
>> it isn't clear to me how that is done.  Is it just a matter of each exec 
>> declaration having a unique title but the same command?
>>
>>
>
> Multiple Exec resources may have the same command and/or title.  This is a 
> hard-coded special case, and other types cannot emulate it.
>
> No physical resource can be identified by an XPath expression alone.  Only 
> in the context of an XML file does an XPath expression represent anything 
> concrete, and the natural identifier of that thing (or things) is the 
> combination of file and XPath expression.  Your type absolutely *begs* 
> for a compound namevar.
>
> With that said, I can't say I care for the rest of what I see about your 
> type.  In particular, the presence of a 'command' attribute suggests that 
> you are trying to model an action on some resource, instead of modeling the 
> resource itself.  You probably can make that work, but it runs against 
> Puppet's design and mode of operation, which may end up presenting 
> practical problems.
>
>
> 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/fbafd64c-4339-4924-899e-519beb53a2cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: representing undef in hiera?

[ess]

On Monday, February 9, 2015 at 11:37:39 AM UTC-5, Christopher Wood wrote:
>
> How would I represent an undef in hiera such that a class parameter will 
> be populated as undef?


John's doing a better job than I would of talking about the overall theory, 
but we ran into something similar and I found this bug / feature that you 
might find interesting if you haven't already seen it:

https://projects.puppetlabs.com/issues/20923

We are using the puppetlabs-lvm module and needed to set the size value to 
be undef / use extents for a specific filesystem.  Since it didn't seem 
possible to do that with Hiera, we moved that functionality back into code.

>
>

-- 
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/a4c38428-6027-498f-905b-edb807c1e134%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Is trusting the agents a bad thing?

[UK_beginner]

I'm new to puppet and have been exploring different ways of configuring 
manifests, ranging from huge single manifests, through per-node and am 
currently looking at the role/profile patterns.

One thing I've been looking at is using a mix of puppet and hiera to set up 
a hierarchy based around server roles (i.e. web. database, logging etc.) 
using the environment and a custom fact set on the agents using 
/etc/facter/facts.d. For me this seems an efficient way to describe a 
configuration since it can avoid a lot of duplication.

However, some of the team I'm working with have concerns around the fact 
that we're letting the agents dictate what manifests get passed to them 
since they define the role & environment facts. I've been told that if 
someone found a 'root-level' exploit they could change the facts to 
retrieve whatever manifest they want - my response is if we get to that 
stage, all bets are off since they can just stop puppet, download rpm's etc.

However I wanted to gauge the feeling of the experts - is this a risky 
solution, or do others feel that as we implement other security factors 
(firewalls, correct file permissions, certificates) that this is an 
acceptable route to investigate?

Thanks in advance for you thoughts.

-- 
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/b24c11a0-1e0a-459f-9873-de80fccd41a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Is trusting the agents a bad thing?

[Alex Elman]

I don't think you should limit your agent's ability to dictate what
resources should be configured and served. The Puppet client-server trust
model is fairly flat and this provides a decent trade-off between
flexibility and security. If your agent is owned, then as you mention, you
have bigger concerns.

You do have some decently granular control over which agents get access to
which resources by using auth.conf. See
https://docs.puppetlabs.com/guides/rest_auth_conf.html. Configuring
auth.conf on the master side, you can lock down certain resources using
allow/deny directives or ACLs for things other than facter facts like
hostnames and ip addresses. I would make sure you lock things down against
unauthenticated agents at the very least. Also be judicious about how you
design your auto-signing configuration if you're worried about rouge
agents. See
https://docs.puppetlabs.com/puppet/3.7/reference/ssl_autosign.html.

-Alex

On Thu, Feb 12, 2015 at 4:10 PM, UK_beginner  wrote:

> I'm new to puppet and have been exploring different ways of configuring
> manifests, ranging from huge single manifests, through per-node and am
> currently looking at the role/profile patterns.
>
> One thing I've been looking at is using a mix of puppet and hiera to set
> up a hierarchy based around server roles (i.e. web. database, logging etc.)
> using the environment and a custom fact set on the agents using
> /etc/facter/facts.d. For me this seems an efficient way to describe a
> configuration since it can avoid a lot of duplication.
>
> However, some of the team I'm working with have concerns around the fact
> that we're letting the agents dictate what manifests get passed to them
> since they define the role & environment facts. I've been told that if
> someone found a 'root-level' exploit they could change the facts to
> retrieve whatever manifest they want - my response is if we get to that
> stage, all bets are off since they can just stop puppet, download rpm's etc.
>
> However I wanted to gauge the feeling of the experts - is this a risky
> solution, or do others feel that as we implement other security factors
> (firewalls, correct file permissions, certificates) that this is an
> acceptable route to investigate?
>
> Thanks in advance for you thoughts.
>
> --
> 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/b24c11a0-1e0a-459f-9873-de80fccd41a9%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Alex Elman

-- 
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/CAD-8G_pnMVcpK76OaKWVNcw6PM%3Dsv8enSDX_SHxxXyhUXg1fCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Is trusting the agents a bad thing?

[Denmat]

One thing to consider is using hiera e-yaml gpg based on certnames. You can put 
secrets (db passwords etc) here and they are matched to the SSL certname. In 
this configuration an attacker can change their role/profile but still cant 
access secrets for a particular node that doesn't match its certname.

That is not the only way but a fairly reasonable compromise.

Den



> On 13 Feb 2015, at 09:43, Alex Elman  wrote:
> 
> I don't think you should limit your agent's ability to dictate what resources 
> should be configured and served. The Puppet client-server trust model is 
> fairly flat and this provides a decent trade-off between flexibility and 
> security. If your agent is owned, then as you mention, you have bigger 
> concerns.
> 
> You do have some decently granular control over which agents get access to 
> which resources by using auth.conf. See 
> https://docs.puppetlabs.com/guides/rest_auth_conf.html. Configuring auth.conf 
> on the master side, you can lock down certain resources using allow/deny 
> directives or ACLs for things other than facter facts like hostnames and ip 
> addresses. I would make sure you lock things down against unauthenticated 
> agents at the very least. Also be judicious about how you design your 
> auto-signing configuration if you're worried about rouge agents. See 
> https://docs.puppetlabs.com/puppet/3.7/reference/ssl_autosign.html.
> 
> -Alex
> 
>> On Thu, Feb 12, 2015 at 4:10 PM, UK_beginner  wrote:
>> I'm new to puppet and have been exploring different ways of configuring 
>> manifests, ranging from huge single manifests, through per-node and am 
>> currently looking at the role/profile patterns.
>> 
>> One thing I've been looking at is using a mix of puppet and hiera to set up 
>> a hierarchy based around server roles (i.e. web. database, logging etc.) 
>> using the environment and a custom fact set on the agents using 
>> /etc/facter/facts.d. For me this seems an efficient way to describe a 
>> configuration since it can avoid a lot of duplication.
>> 
>> However, some of the team I'm working with have concerns around the fact 
>> that we're letting the agents dictate what manifests get passed to them 
>> since they define the role & environment facts. I've been told that if 
>> someone found a 'root-level' exploit they could change the facts to retrieve 
>> whatever manifest they want - my response is if we get to that stage, all 
>> bets are off since they can just stop puppet, download rpm's etc.
>> 
>> However I wanted to gauge the feeling of the experts - is this a risky 
>> solution, or do others feel that as we implement other security factors 
>> (firewalls, correct file permissions, certificates) that this is an 
>> acceptable route to investigate?
>> 
>> Thanks in advance for you thoughts.
>> -- 
>> 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/b24c11a0-1e0a-459f-9873-de80fccd41a9%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> Alex Elman
> -- 
> 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/CAD-8G_pnMVcpK76OaKWVNcw6PM%3Dsv8enSDX_SHxxXyhUXg1fCg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/57237023-2022-40F7-B508-56FD3830EB08%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Nodes remain in unresponsive state

[abhi]

Hello,

I have a couple of nodes that always remain in unresponsive state in PE 
console. When I run the agent manually, it runs without issues. I can see 
that the agent runs in the bg. i.e the pe-puppet service is running. 
/opt/puppet/bin/ruby 
/opt/puppet/bin/puppet agent agent is listed in ps aux

When I restarted the service, this is what it reported in the syslog:

Feb 13 07:26:58 qumu-prd-sigd-aws-euwe1a-001 puppet-agent[1802]: message 
repeated 3325 times: [ Did not receive certificate]
Feb 13 07:27:05 qumu-prd-sigd-aws-euwe1a-001 puppet-agent[1802]: Could not 
run: SIGTERM
Feb 13 07:27:07 qumu-prd-sigd-aws-euwe1a-001 puppet-agent[30258]: Reopening 
log files
Feb 13 07:27:07 qumu-prd-sigd-aws-euwe1a-001 puppet-agent[30258]: Starting 
Puppet client version 3.6.2 (Puppet Enterprise 3.3.0)


It however, proceeds to run and apply any updates. However, I had another 
machine with the same name which I had removed from puppet by doing a cert 
clean followed by a node deactivate.

Is there someway I can make puppet forget the older certs so it does not 
fail to start.

--
Abhi

-- 
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/ed8b60a0-c821-4670-abd0-8133d7d9c590%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.