Re: [Puppet Users] manage sudoers with augeas

[vincent]

How Can I detect why augeas doesn't treat them ?
How can I know if it is a lens failure ?
Does augeas have a debug mode ?



2011/8/25 Rob McBroom 

> On Aug 25, 2011, at 9:35 AM, Vincent wrote:
>
> > yes it was as root, why the ls /etc doesn't return the sudoers ?
>
> On Aug 25, 2011, at 9:23 AM, Rob McBroom wrote:
>
> > If a file hasn’t been properly parsed by Augeas, it simply won’t show up.
> This could mean that the file has a syntax error, the file doesn’t exist,
> you don’t have permission to read the file, or it could imply a failure in
> the lens itself.
>
>
> --
> Rob McBroom
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

RE: [Puppet Users] Re: Unexpected behavior using class inheritance and run stages

[Ricardo Bartolome Mendez]

Hello John,

Class rsyslog::stats does not override any definition already declared in
rsyslog, reason because I was not sure of doing a correct usage of class
inheritance. rsyslog was the simpler example, but I have a module was
suffering a serious problem of order (it's related to production code and
config retrieval, which is executed after all the related services are
ready). The tickets #6019 and #7533 are related with the issue I'm facing at
the moment, so I'll follow them up. It'll be potentially fixed/changed on
2.7.x branch, which I have planned to upgrade very soon. Thanks for pointing
me out in the correct direction.

Regards,

-Mensaje original-
De: puppet-users@googlegroups.com [mailto:puppet-users@googlegroups.com] En
nombre de jcbollinger
Enviado el: viernes, 26 de agosto de 2011 0:13
Para: Puppet Users
Asunto: [Puppet Users] Re: Unexpected behavior using class inheritance and
run stages



On Aug 25, 2:52 pm, Ricardo Bartolome Mendez 
wrote:
> Hello guys,
>
> I use stages for defining a kind of order about how the things are done in
> my automations. I’ve defined four different stages: boot, os, service and
> online. We also have Main stage. The issue I found today may be derived
> from
> a incorrect usage of class inheritance, or run stages. Let me show you an
> example:
>
> We use rsyslog for both systems logging and application logging. So,
> depending of the facilities and so on, we transport operating systems logs
> to a syslog receiver, or stats to a data analysis cluster. So, given that
> is
> the same piece of software I decided to create a module called “rsyslog”
> and
> inside init.pp describe all the necessary stuff for having the operating
> systems syslog configured, what is a must in any of my nodes. I also
> defined
> inside stats.pp a new class named “rsyslog::stats” that inherits rsyslog.


It's not clear that this is a good use case for class inheritance.
Does Class['rsyslog::stats'] override the properties of any resources
inherited from Class['rsyslog']?  From your description, it's not
obvious that it would need to do.  If indeed it doesn't, then you are
using inheritance where you should instead be aggregating (more on
that below).


> So, then, in my node class named “frontend” where I need both
> configurations
> I define the rsyslog class it in this way:
>
> include stages
>
> class { ‘rsyslog::stats’: stage => ‘os’ }
>
> But today I found (using debug option) that the things explicitly defined
> in
> “rsyslog::stats” are done in the stage “os”,  but the things defined in
> the
> class “rsyslog” are done in Main [1]. What I expect? I expect that given
> that “rsyslog::stats” was defined in the Stage “os”, the inherited one,
> too.


I would not have anticipated that result either, but in hindsight I
don't find it altogether surprising.  That doesn't mean you shouldn't
file a ticket about it, though.  Or it wouldn't, but it looks like
there are already at least three separate tickets describing this
issue (5349, 6019, 7533).

An important question arises at this point: is this something you
actually need to fix?  I mean, was anything actually breaking?  If
not, then you should consider just ignoring the issue.


> I’ve fixed this by defining the class in the node like:
>
> include stages
>
> class { ‘rsyslog’: stage => ‘os’ }
>
> class { ‘rsyslog::stats’: stage => ‘os’ }
>
> But this means repeating lines and it’s quite ugly.


I think that's your best alternative at the moment.  Also, although
the need to do that is a bit surprising, it makes a certain amount of
sense if you look at it from the right angle.  For one thing, it's
valid to do that in the first place.  For another, it is possible to
do that and specify different stages for base- and subclass.  For a
third, consider what would happen if you wanted to put two different
subclasses of the same class into different stages.

Moreover, if the stats collection is in addition to rsyslog reporting,
as opposed to being a modified form of the same, then I think the form
you found is what you should have been doing all along.  In that case,
the fact that stats collection relies on rsyslog is better modeled via
an ordinary relationship than via class inheritance.  That might even
allow you to make some of Class['rsyslog:stats'] implementation a
little cleaner, depending on what resource-level relationships you may
have declared.


> I don’t know if that’s
> the proper way of doing what I’m doing. I’m using class inheritance
> because
> there are servers that are running rsyslog for systems logs, but they don’t
> need the stats configuration (a database server, for example), so
> including
> just “rsyslog” class and defining its run stage should be enough.


I agree that it's good form for your Class['rsyslog'] to not contain
the stats stuff itself.  I'm still doubtful, however, that it's
appropriate to make Class['rsyslog::stats'] a subclass.  As a bonus,
if you make it a top-level class then maybe you won't 

[Puppet Users] Re: Secure Certification Authority Transfer

[It Dept]

On Aug 25, 5:37 pm, Nigel Kersten  wrote:
>
> I may be reading your request incorrectly, but it almost sounds like you
> don't really want to have the Puppet CA at all, and just want to generate
> certificates manually and distribute them yourself.
>
> Would launching all your masters with --no-ca help here?

We tried using our own existing CA infrastructure by using an
intermediate CA on our puppet master. During this test we were using --
no-ca. We manually generated certificates for the client and master,
but neither the master nor the client seemed to support using
intermediate CAs. The client simply failed to verify the certificate,
even when we tried putting the root CA and intermediate CA
certificates in the same file called ca.pem. This is unrelated to our
problem as it doesn't solve the security problem, but I just thought
I'd share our experience in this area.

With regard to our current issue: we don't mind the master acting as a
CA since we can manually generate certificates for the clients on the
master and transfer them to the clients ourselves. Our issue is with
the clients making unverifiable CA cert request. This cannot be solved
server side since even if the server refuses the clients requests for
the ca, there could still be a man-in-the-middle attack coupled with a
DNS poison which could lead to a third party CA being sent to the
client, compromising our security chain for the client.

On Aug 25, 7:22 pm, Nan Liu  wrote:
>
> To clarify, puppet will verify the agent and master certificates
> against the CA cert. So I think your focus is on the CA cert. If you
> distribute the CA as part of the puppet install, it should resolve
> this issue. Make the CA file immutable as Mark has suggested. If you
> want to take it one step further, maybe a feature request so puppet
> agent doesn't request the CA, maybe something like an option
> :disable_cacert_download.

You exactly right in terms of what we want to achieve. We want to
distribute both the CA and client certificates/keys manually as part
of the install process. We just want to disable the clients'
capability to ever make requests when they cannot verify the identity
of the server. I know that the client will not make these requests
when the certificates are put in place manually, but mistakes can
happen and it would be very difficult to identify where they had. It
does seem to be a matter for a feature request, but I would like to go
further and have the option to disable ALL unverifiable requests on
the client.

> In order to verify the CA cert up some chain, it only make sense if
> it's not self signed (and I don't believe puppet cert will generate
> anything other than a self signed CA), so we need to know what to
> verify it against. Are you planning to have a third party like
> Verisign/Thawte sign the CA cert?
>
As I mentioned above we did try to have the puppet CA signed by our
own in house root CA, but we could not get puppet to accept a full
chain (unless there is a way to specify more than one ca.pem file?).
As it stands we are just using the standard puppet-generated CA
structure and want a way to stop clients downloading the ca from the
server when they cannot verify the identity of the server.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] issues with a custom fact, runs fine manually, not via the puppet service...

[Matthew Nicholson]

I think i'm missing something small...

So, I've got a couple custom facts, this is the one I'm dealing with now:

if Facter.value("compute_node") == "true"
Facter.add("lsf_queues") do
setcode do
hostname = Facter.value("hostname")
queues =
Facter::Util::Resolution.exec('/lsf/7.0/linux2.6-glibc2.3-x86_64/bin/bqueues
-m ' + hostname + ' -w | grep -v QUEUE | grep -v \^priority | cut -d " " -f
1')
lsf_queues=Array.new
queues.each do |line|
lsf_queues.push(line)
end
lsf_queues=lsf_queues.join(",")
lsf_queues
end
end
end

Basically, checked another custom fact to see if we're working on a compute
node (true/false), and if so, tried to findout what queues target this node.
 I can run puppet agent -t , and see it load the fact, run it, and it
returns a good value and everything to out foreman instance. All is happy.

But, once i made this live, everything that has got it has failed to send a
report, BUT, if i logon a node and run puppet, all is well. So there is some
difference between me running puppet as root with this fact in place, and it
running out of the service. Now, I 'd normally su/sudo -u to the puppet
user, but its not a shell user, so I can't execute this as the puppet
user...

Any ideas on why this isn't working and/or how to run this in the same way
the service runs to I can see whats going wrong when invoked that way?


-- 
Matthew Nicholson

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] aptitude provider ignores some bad package names

[Andreas Kuntzagk]

Hi,

for some (mistyped?) bad package names the aptitude provider does not fail.
Example manifest:

Package {
provider => 'aptitude',
ensure   => 'latest',
}

package {"qt4":
  ensure => latest,
}

# puppet agent --test
...
notice: /Stage[main]//Package[qt4]/ensure: ensure changed 'purged' to 'latest'
...

# aptitude install qt4
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Couldn't find package "qt4", and more than 40
packages contain "qt4" in their name.
Couldn't find package "qt4", and more than 40
packages contain "qt4" in their name.
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 11 not upgraded.
Need to get 0B of archives. After unpacking 0B will be used.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done

If I use "foobar" as package name it complains about non-existing package.

regards, Andreas

--
Andreas Kuntzagk
SystemAdministrator
MDC Berlin / BIMSB
Tel.: +49 30 9406 2997

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Exec resource not being applied properly

[Frederiko Costa]

Hi folks,

I have the following resource on my test environ:

exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
/etc/selinux/config":
path => [ '/usr/bin', '/bin' ],
onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
2>/dev/null",
logoutput => true,
}

Whenever I run:
puppet agent  --no-daemonize --test --environment development

I get the following:
debug: Exec[/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
/etc/selinux/config](provider=posix): Executing check '/bin/grep
'^SELINUX=enforcing' /etc/sysconfig/selinux
2>/dev/null'
debug: Executing '/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
2>/dev/null'


If I run these commands individually, it works fine. When I run through
puppet, it fails to get the file changes. Does anyone know why? Could it be
because of the --test switch, although it does not execute in --noop mode?

I appreciate any help

thanks,
-fred

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Exec resource not being applied properly

[Aaron Grewell]

I think you may have a typo in your resource:
/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'

should have '-e' after '-i' I believe.

On Fri, Aug 26, 2011 at 8:03 AM, Frederiko Costa wrote:

> Hi folks,
>
> I have the following resource on my test environ:
>
> exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
> /etc/selinux/config":
> path => [ '/usr/bin', '/bin' ],
> onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
> 2>/dev/null",
> logoutput => true,
> }
>
> Whenever I run:
> puppet agent  --no-daemonize --test --environment development
>
> I get the following:
> debug: Exec[/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
> /etc/selinux/config](provider=posix): Executing check '/bin/grep
> '^SELINUX=enforcing' /etc/sysconfig/selinux
> 2>/dev/null'
> debug: Executing '/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
> 2>/dev/null'
>
>
> If I run these commands individually, it works fine. When I run through
> puppet, it fails to get the file changes. Does anyone know why? Could it be
> because of the --test switch, although it does not execute in --noop mode?
>
> I appreciate any help
>
> thanks,
> -fred
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Exec resource not being applied properly

[Frank Sweetser]

On 08/26/2011 11:03 AM, Frederiko Costa wrote:
> Hi folks,
> 
> I have the following resource on my test environ:
> 
> exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' 
> /etc/selinux/config":
> path => [ '/usr/bin', '/bin' ],
> onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux 
> 2>/dev/null",
> logoutput => true,
> }

As an alternative to the exec method, you might want to look into using the
augeas type instead.  It's capable of reading /etc/sysconfig/selinux and
managing the entries within it.

-- 
Frank Sweetser fs at wpi.edu|  For every problem, there is a solution that
Manager of Network Operations   |  is simple, elegant, and wrong.
Worcester Polytechnic Institute |   - HL Mencken

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] manage sudoers with augeas

[Aaron Grewell]

My 2c: I avoid the augeas provider whenever possible.  I've got it in one
manifest, but it's a pain to troubleshoot.  I would either assemble the file
from fragments using the concat module or drop prebuilt fragments in
/etc/sudoers.d/.  You may have to create the directory, but recent sudoers
releases support this and it's easy to work with.  You just have to be
careful to chmod the files 440.

On Fri, Aug 26, 2011 at 1:15 AM, vincent  wrote:

> How Can I detect why augeas doesn't treat them ?
> How can I know if it is a lens failure ?
> Does augeas have a debug mode ?
>
>
>
>
> 2011/8/25 Rob McBroom 
>
>> On Aug 25, 2011, at 9:35 AM, Vincent wrote:
>>
>> > yes it was as root, why the ls /etc doesn't return the sudoers ?
>>
>> On Aug 25, 2011, at 9:23 AM, Rob McBroom wrote:
>>
>> > If a file hasn’t been properly parsed by Augeas, it simply won’t show
>> up. This could mean that the file has a syntax error, the file doesn’t
>> exist, you don’t have permission to read the file, or it could imply a
>> failure in the lens itself.
>>
>>
>> --
>> Rob McBroom
>> 
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Exec resource not being applied properly

[Aaron Grewell]

Or just push a new file, that's what we do.

On Fri, Aug 26, 2011 at 8:16 AM, Frank Sweetser  wrote:

> On 08/26/2011 11:03 AM, Frederiko Costa wrote:
> > Hi folks,
> >
> > I have the following resource on my test environ:
> >
> > exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
> /etc/selinux/config":
> > path => [ '/usr/bin', '/bin' ],
> > onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
> 2>/dev/null",
> > logoutput => true,
> > }
>
> As an alternative to the exec method, you might want to look into using the
> augeas type instead.  It's capable of reading /etc/sysconfig/selinux and
> managing the entries within it.
>
> --
> Frank Sweetser fs at wpi.edu|  For every problem, there is a solution
> that
> Manager of Network Operations   |  is simple, elegant, and wrong.
> Worcester Polytechnic Institute |   - HL Mencken
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Exec resource not being applied properly

[Frederiko Costa]

Hi folks,

Thanks for the quick help

Aaron - the -i does an in place modification. If I run on the command-line,
works fine. If I don't use -i, I would have to use some sort of redirection
and replace the original file. I will try placing -e as well for testing
sake
"-i[SUFFIX], --in-place[=SUFFIX]
  edit files in place (makes backup if extension supplied)"

Frank - I will read about the augeas type. As a newbie in Puppet, it was
unknown to me.

Thanks,
-fred




On Fri, Aug 26, 2011 at 8:16 AM, Frank Sweetser  wrote:

> On 08/26/2011 11:03 AM, Frederiko Costa wrote:
> > Hi folks,
> >
> > I have the following resource on my test environ:
> >
> > exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
> /etc/selinux/config":
> > path => [ '/usr/bin', '/bin' ],
> > onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
> 2>/dev/null",
> > logoutput => true,
> > }
>
> As an alternative to the exec method, you might want to look into using the
> augeas type instead.  It's capable of reading /etc/sysconfig/selinux and
> managing the entries within it.
>
> --
> Frank Sweetser fs at wpi.edu|  For every problem, there is a solution
> that
> Manager of Network Operations   |  is simple, elegant, and wrong.
> Worcester Polytechnic Institute |   - HL Mencken
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Exec resource not being applied properly

[Aaron Grewell]

I'm clear on what -i does, but I thought -e was also required.  I'm not a
sed expert, but last time I left out -e things went rather badly.

On Fri, Aug 26, 2011 at 8:25 AM, Frederiko Costa wrote:

> Hi folks,
>
> Thanks for the quick help
>
> Aaron - the -i does an in place modification. If I run on the command-line,
> works fine. If I don't use -i, I would have to use some sort of redirection
> and replace the original file. I will try placing -e as well for testing
> sake
> "-i[SUFFIX], --in-place[=SUFFIX]
>   edit files in place (makes backup if extension supplied)"
>
> Frank - I will read about the augeas type. As a newbie in Puppet, it was
> unknown to me.
>
> Thanks,
> -fred
>
>
>
>
> On Fri, Aug 26, 2011 at 8:16 AM, Frank Sweetser  wrote:
>
>> On 08/26/2011 11:03 AM, Frederiko Costa wrote:
>> > Hi folks,
>> >
>> > I have the following resource on my test environ:
>> >
>> > exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
>> /etc/selinux/config":
>> > path => [ '/usr/bin', '/bin' ],
>> > onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
>> 2>/dev/null",
>> > logoutput => true,
>> > }
>>
>> As an alternative to the exec method, you might want to look into using
>> the
>> augeas type instead.  It's capable of reading /etc/sysconfig/selinux and
>> managing the entries within it.
>>
>> --
>> Frank Sweetser fs at wpi.edu|  For every problem, there is a solution
>> that
>> Manager of Network Operations   |  is simple, elegant, and wrong.
>> Worcester Polytechnic Institute |   - HL Mencken
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Exec resource not being applied properly

[Frederiko Costa]

I will give a try and get back to you soon. You may be correct.

-fred




On Fri, Aug 26, 2011 at 8:30 AM, Aaron Grewell wrote:

> I'm clear on what -i does, but I thought -e was also required.  I'm not a
> sed expert, but last time I left out -e things went rather badly.
>
> On Fri, Aug 26, 2011 at 8:25 AM, Frederiko Costa wrote:
>
>> Hi folks,
>>
>> Thanks for the quick help
>>
>> Aaron - the -i does an in place modification. If I run on the
>> command-line, works fine. If I don't use -i, I would have to use some sort
>> of redirection and replace the original file. I will try placing -e as well
>> for testing sake
>> "-i[SUFFIX], --in-place[=SUFFIX]
>>   edit files in place (makes backup if extension supplied)"
>>
>> Frank - I will read about the augeas type. As a newbie in Puppet, it was
>> unknown to me.
>>
>> Thanks,
>> -fred
>>
>>
>>
>>
>> On Fri, Aug 26, 2011 at 8:16 AM, Frank Sweetser  wrote:
>>
>>> On 08/26/2011 11:03 AM, Frederiko Costa wrote:
>>> > Hi folks,
>>> >
>>> > I have the following resource on my test environ:
>>> >
>>> > exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
>>> /etc/selinux/config":
>>> > path => [ '/usr/bin', '/bin' ],
>>> > onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
>>> 2>/dev/null",
>>> > logoutput => true,
>>> > }
>>>
>>> As an alternative to the exec method, you might want to look into using
>>> the
>>> augeas type instead.  It's capable of reading /etc/sysconfig/selinux and
>>> managing the entries within it.
>>>
>>> --
>>> Frank Sweetser fs at wpi.edu|  For every problem, there is a
>>> solution that
>>> Manager of Network Operations   |  is simple, elegant, and wrong.
>>> Worcester Polytechnic Institute |   - HL Mencken
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Puppet Users" group.
>>> To post to this group, send email to puppet-users@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> puppet-users+unsubscr...@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/puppet-users?hl=en.
>>>
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

RE: [Puppet Users] Exec resource not being applied properly

[Kinzel, David]

> Hi folks,
>
> I have the following resource on my test environ:
>
> exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
/etc/selinux/config":
> path => [ '/usr/bin', '/bin' ],
> onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
2>/dev/null",
> logoutput => true,
> }


/bin/egrep: Regular /bin/grep will not do your start (^) matching as you
want.   




This email communication and any files transmitted with it may contain
confidential and or proprietary information and is provided for the use of the
intended recipient only. Any review, retransmission or dissemination of this
information by anyone other than the intended recipient is prohibited. If you
receive this email in error, please contact the sender and delete this
communication and any copies immediately. Thank you.

http://www.encana.com

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Announce Only List

[Christopher Webber]

Is there an announce only list for Puppet at this point?

-- cwebber

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Exec resource not being applied properly

[Frederiko Costa]

I tried both suggestions: egrep and adding the -e switch on sed, but none
worked. I'm going to try augeas ...

-fred




On Fri, Aug 26, 2011 at 8:31 AM, Kinzel, David wrote:

> > Hi folks,
> >
> > I have the following resource on my test environ:
> >
> > exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
> /etc/selinux/config":
> > path => [ '/usr/bin', '/bin' ],
> > onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
> 2>/dev/null",
> > logoutput => true,
> > }
>
>
> /bin/egrep: Regular /bin/grep will not do your start (^) matching as you
> want.
>
>
>
>
> This email communication and any files transmitted with it may contain
> confidential and or proprietary information and is provided for the use of
> the
> intended recipient only. Any review, retransmission or dissemination of
> this
> information by anyone other than the intended recipient is prohibited. If
> you
> receive this email in error, please contact the sender and delete this
> communication and any copies immediately. Thank you.
>
> http://www.encana.com
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Service resource does not seem to be disabling service on reboots

[Frederiko Costa]

Hi folks,

The question I have is regarding to Service resource on Red Hat systems. I
have the following:

service { [ "anacron", "atd" ]:
   ensure => stopped,
enable => false,
hasrestart => true,
hasstatus => true,
  }

It runs fine, disabling the service while the system is up. Debugging it, I
noticed that it run the following:
debug: Service[atd](provider=redhat): Executing '/sbin/service atd status'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
atd'

The idea is to disable it completely, so it does not come back in the next
reboot. By running '/sbin/chkconfig atd', that does not happen. So, the
correct command, I think, would be '/sbin/chkconfig atd off'.

Is there any way to accomplish this?

thanks,
-fred

-fred

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Forcing package resources to fail to install in Solaris sparse root zones when install path is inherited from global zone

[Matt]

Hello,

I've have a bunch of Solaris sparse root zones. The share /opt/csw
with the global zone. Because of this, attempts to install a package
that roots in that directory will fail. How do I get puppet to notify
and fail if the package is missing, rather than attempt to install, in
such a zone? facter reports virtual => zone and I thought maybe it's
something to do with adding something to Package {}  so all package
resources inherit, but that's about as far as my (currently only a few
days old) knowledge of Puppet takes me.

Thanks,
Matt

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Custom provider works only immediately after sync

[Adrian Casajús]

Hi all,

 I've got a custom type with a single custom provider. I've got
enabled pluginsync in both client and server. When I run the puppet
agent in the client it syncs the type and the provider and properly
executes them. But if I execute the agent again it will tell me

err: Could not run Puppet configuration client: Could not find a
default provider for passwduser

If I go to the server and modify a single line just to trigger the
sync and execute the agent again, it properly syncs the modification
and runs properly the provider. Then if I run again it goes back to no
default provider.

Any hints? tips? I've looked at the docs and the mailing list and
haven't found anything similar.

Thanks for any hint.

Cheers,
 Adri

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Announce Only List

[Nigel Kersten]

On Fri, Aug 26, 2011 at 8:35 AM, Christopher Webber wrote:

> Is there an announce only list for Puppet at this point?
>
>
http://groups.google.com/group/puppet-announce

Only final releases, you won't see the RC churn here.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Exec resource not being applied properly

[Frederiko Costa]

Hi folks,

for the next user looking for help ... augeas did the trick

augeas { "selinux":
context => "/files/etc/sysconfig/selinux/",
changes => [ "set SELINUX disabled" ],
}

debug: Augeas[selinux](provider=augeas): Augeas version 0.8.1 is installed
debug: Augeas[selinux](provider=augeas): Will attempt to save and only run
if files
changed

debug: Augeas[selinux](provider=augeas): sending command 'set' with params
["/files/etc/sysconfig/selinux/SELINUX",
"disabled"]
debug: Augeas[selinux](provider=augeas): Executing 'diff -u
/etc/sysconfig/selinux
/etc/sysconfig/selinux.augnew'

wrong number of arguments (2 for 1)
debug: Augeas[selinux](provider=augeas): Files changed, should execute
debug: Augeas[selinux](provider=augeas): /etc/sysconfig/selinux.augnew moved
to
/etc/sysconfig/selinux

debug: Augeas[selinux](provider=augeas): Closed the augeas connection

thanks for the help!
-fred




On Fri, Aug 26, 2011 at 8:42 AM, Frederiko Costa wrote:

> I tried both suggestions: egrep and adding the -e switch on sed, but none
> worked. I'm going to try augeas ...
>
> -fred
>
>
>
>
>
> On Fri, Aug 26, 2011 at 8:31 AM, Kinzel, David wrote:
>
>> > Hi folks,
>> >
>> > I have the following resource on my test environ:
>> >
>> > exec { "/bin/sed -i 's/^SELINUX=enforcing/SELINUX=disabled/'
>> /etc/selinux/config":
>> > path => [ '/usr/bin', '/bin' ],
>> > onlyif => "/bin/grep '^SELINUX=enforcing' /etc/sysconfig/selinux
>> 2>/dev/null",
>> > logoutput => true,
>> > }
>>
>>
>> /bin/egrep: Regular /bin/grep will not do your start (^) matching as you
>> want.
>>
>>
>>
>>
>> This email communication and any files transmitted with it may contain
>> confidential and or proprietary information and is provided for the use of
>> the
>> intended recipient only. Any review, retransmission or dissemination of
>> this
>> information by anyone other than the intended recipient is prohibited. If
>> you
>> receive this email in error, please contact the sender and delete this
>> communication and any copies immediately. Thank you.
>>
>> http://www.encana.com
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Complex YAML Data in External Nodes

[Douglas Garstang]

Can I do this in an external node?

parameters:
  foo:
- { id: 0, Name: Doug }

And access it with:

notice ("DATA=$foo[0]['Name']")

?

Doug

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Forcing package resources to fail to install in Solaris sparse root zones when install path is inherited from global zone

[Nan Liu]

On Fri, Aug 26, 2011 at 8:30 AM, Matt  wrote:
> I've have a bunch of Solaris sparse root zones. The share /opt/csw
> with the global zone. Because of this, attempts to install a package
> that roots in that directory will fail. How do I get puppet to notify
> and fail if the package is missing, rather than attempt to install, in
> such a zone? facter reports virtual => zone and I thought maybe it's
> something to do with adding something to Package {}  so all package
> resources inherit, but that's about as far as my (currently only a few
> days old) knowledge of Puppet takes me.

Add the attribute noop => true for the package to skip the
installation and just notify. You can make this a variable dependent
on whether the system is solaris and virtual.

Thanks,

Nan

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Service resource does disable services on reboots

[Frederiko Costa]

Hi folks,

The question I have is regarding to Service resource on Red Hat systems. I
have the following example:

service { [ "anacron", "atd" ]:
   ensure => stopped,
enable => false,
hasrestart => true,
hasstatus => true,
  }

It runs fine, disabling the service while the system is up. Debugging it, I
noticed that it run the following:
debug: Service[atd](provider=redhat): Executing '/sbin/service atd status'
debug: Puppet::Type::Service::
ProviderRedhat: Executing '/sbin/chkconfig atd'

The idea is to disable it completely, so it does not come back in the next
reboot. By running '/sbin/chkconfig atd', that does not happen. So, the
correct command, I think, would be '/sbin/chkconfig atd off'.

Is there any way to accomplish this?

thanks,
-fred

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Certificate Verify Failed

[PuppetNewbie]

I could use some help.  I am a newbie with puppet, and am trying to
learn it and use it here at the office.  I have created 2 CentOS 5.5
machines ( puppet.1on1.com - puppetmaster and puppetclient.1on1.com -
which will be the client that I control.)  When I attempt to connect
my client to the master, I get the following output:

# puppet agent --server=puppet.1on1.com --no-daemonize --verbose --
debug --trace
debug: Failed to load library 'selinux' for feature 'selinux'
debug: Failed to load library 'shadow' for feature 'libshadow'
debug: Failed to load library 'ldap' for feature 'ldap'
debug: Puppet::Type::User::ProviderLdap: feature ldap is missing
debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/
dscl does not exist
debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does
not exist
debug: Puppet::Type::User::ProviderPw: file pw does not exist
debug: Puppet::Type::File::ProviderMicrosoft_windows: feature
microsoft_windows is missing
debug: /File[/var/lib/puppet/log]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/run]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/
ssl]
debug: /File[/etc/puppet/ssl]: Autorequiring File[/etc/puppet]
debug: /File[/etc/puppet/ssl/public_keys]: Autorequiring File[/etc/
puppet/ssl]
debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring
File[/etc/puppet/ssl]
debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring File[/etc/
puppet/ssl]
debug: /File[/etc/puppet/ssl/private]: Autorequiring File[/etc/puppet/
ssl]
debug: /File[/etc/puppet/ssl/private_keys/puppetclient.1on1.com.pem]:
Autorequiring File[/etc/puppet/ssl/private_keys]
debug: /File[/etc/puppet/ssl/public_keys/puppetclient.1on1.com.pem]:
Autorequiring File[/etc/puppet/ssl/public_keys]
debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet]
debug: /File[/var/lib/puppet/run/agent.pid]: Autorequiring File[/var/
lib/puppet/run]
debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/
lib/puppet]
debug: /File[/var/lib/puppet/state/graphs]: Autorequiring File[/var/
lib/puppet/state]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
puppet]
debug: Finishing transaction 167894360
debug: /File[/var/lib/puppet/log]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/
puppet]
debug: /File[/var/lib/puppet/run]: Autorequiring File[/var/lib/puppet]
debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/
ssl]
debug: /File[/etc/puppet/ssl]: Autorequiring File[/etc/puppet]
debug: /File[/etc/puppet/ssl/public_keys]: Autorequiring File[/etc/
puppet/ssl]
debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring
File[/etc/puppet/ssl]
debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring File[/etc/
puppet/ssl]
debug: /File[/etc/puppet/ssl/private]: Autorequiring File[/etc/puppet/
ssl]
debug: /File[/etc/puppet/ssl/private_keys/puppetclient.1on1.com.pem]:
Autorequiring File[/etc/puppet/ssl/private_keys]
debug: /File[/etc/puppet/ssl/public_keys/puppetclient.1on1.com.pem]:
Autorequiring File[/etc/puppet/ssl/public_keys]
debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
puppet]
debug: Finishing transaction 174279260
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
indirector/rest.rb:97:in `rescue in http_request'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
indirector/rest.rb:81:in `http_request'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
indirector/rest.rb:76:in `block (2 levels) in '
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
indirector/rest.rb:118:in `find'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
indirector/certificate/rest.rb:11:in `find'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
indirector/indirection.rb:188:in `find'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/ssl/
host.rb:180:in `certificate'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/ssl/
host.rb:263:in `wait_for_cert'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
application/agent.rb:416:in `setup_host'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
application/agent.rb:480:in `setup'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
application.rb:305:in `block (2 levels) in run'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
application.rb:411:in `hook'
/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
applic

[Puppet Users] Re: issues with a custom fact, runs fine manually, not via the puppet service...

[Matthew Nicholson]

Following up on my own question, I'm closer but not there:

The fact no longer breaks a puppet run.

On a node, facter -p shows my fact. It is not, however, in the report sent
to my master, nor in the yaml file for the host.
However, if i run puppet manually (puppet agent -t), once it finishes, it is
ONLY then in the report/yaml.

Why would this happen?

Matt

On Fri, Aug 26, 2011 at 10:12 AM, Matthew Nicholson <
matthew.a.nichol...@gmail.com> wrote:

>
> I think i'm missing something small...
>
> So, I've got a couple custom facts, this is the one I'm dealing with now:
>
> if Facter.value("compute_node") == "true"
> Facter.add("lsf_queues") do
> setcode do
> hostname = Facter.value("hostname")
> queues =
> Facter::Util::Resolution.exec('/lsf/7.0/linux2.6-glibc2.3-x86_64/bin/bqueues
> -m ' + hostname + ' -w | grep -v QUEUE | grep -v \^priority | cut -d " " -f
> 1')
> lsf_queues=Array.new
> queues.each do |line|
> lsf_queues.push(line)
> end
> lsf_queues=lsf_queues.join(",")
> lsf_queues
> end
> end
> end
>
> Basically, checked another custom fact to see if we're working on a compute
> node (true/false), and if so, tried to findout what queues target this node.
>  I can run puppet agent -t , and see it load the fact, run it, and it
> returns a good value and everything to out foreman instance. All is happy.
>
> But, once i made this live, everything that has got it has failed to send a
> report, BUT, if i logon a node and run puppet, all is well. So there is some
> difference between me running puppet as root with this fact in place, and it
> running out of the service. Now, I 'd normally su/sudo -u to the puppet
> user, but its not a shell user, so I can't execute this as the puppet
> user...
>
> Any ideas on why this isn't working and/or how to run this in the same way
> the service runs to I can see whats going wrong when invoked that way?
>
>
> --
> Matthew Nicholson
>



-- 
Matthew Nicholson

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Re: Complex YAML Data in External Nodes

[Douglas Garstang]

I must be asking hard questions.

On Fri, Aug 26, 2011 at 10:04 AM, Douglas Garstang
wrote:

> Can I do this in an external node?
>
> parameters:
>   foo:
> - { id: 0, Name: Doug }
>
> And access it with:
>
> notice ("DATA=$foo[0]['Name']")
>
> ?
>
> Doug
>



-- 
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.garst...@gmail.com
Cell: +1-805-340-5627

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Certificate Verify Failed

[Ben House]

PuppetNewbie  wrote:

>I could use some help.  I am a newbie with puppet, and am trying to
>learn it and use it here at the office.  I have created 2 CentOS 5.5
>machines ( puppet.1on1.com - puppetmaster and puppetclient.1on1.com -
>which will be the client that I control.)  When I attempt to connect
>my client to the master, I get the following output:
>
># puppet agent --server=puppet.1on1.com --no-daemonize --verbose --
>debug --trace
>debug: Failed to load library 'selinux' for feature 'selinux'
>debug: Failed to load library 'shadow' for feature 'libshadow'
>debug: Failed to load library 'ldap' for feature 'ldap'
>debug: Puppet::Type::User::ProviderLdap: feature ldap is missing
>debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/
>dscl does not exist
>debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does
>not exist
>debug: Puppet::Type::User::ProviderPw: file pw does not exist
>debug: Puppet::Type::File::ProviderMicrosoft_windows: feature
>microsoft_windows is missing
>debug: /File[/var/lib/puppet/log]: Autorequiring File[/var/lib/puppet]
>debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/
>puppet]
>debug: /File[/var/lib/puppet/run]: Autorequiring File[/var/lib/puppet]
>debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
>debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/
>ssl]
>debug: /File[/etc/puppet/ssl]: Autorequiring File[/etc/puppet]
>debug: /File[/etc/puppet/ssl/public_keys]: Autorequiring File[/etc/
>puppet/ssl]
>debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring
>File[/etc/puppet/ssl]
>debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring File[/etc/
>puppet/ssl]
>debug: /File[/etc/puppet/ssl/private]: Autorequiring File[/etc/puppet/
>ssl]
>debug: /File[/etc/puppet/ssl/private_keys/puppetclient.1on1.com.pem]:
>Autorequiring File[/etc/puppet/ssl/private_keys]
>debug: /File[/etc/puppet/ssl/public_keys/puppetclient.1on1.com.pem]:
>Autorequiring File[/etc/puppet/ssl/public_keys]
>debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet]
>debug: /File[/var/lib/puppet/run/agent.pid]: Autorequiring File[/var/
>lib/puppet/run]
>debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/
>puppet]
>debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/
>puppet]
>debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/
>lib/puppet]
>debug: /File[/var/lib/puppet/state/graphs]: Autorequiring File[/var/
>lib/puppet/state]
>debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
>puppet]
>debug: Finishing transaction 167894360
>debug: /File[/var/lib/puppet/log]: Autorequiring File[/var/lib/puppet]
>debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/
>puppet]
>debug: /File[/var/lib/puppet/run]: Autorequiring File[/var/lib/puppet]
>debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
>debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/
>ssl]
>debug: /File[/etc/puppet/ssl]: Autorequiring File[/etc/puppet]
>debug: /File[/etc/puppet/ssl/public_keys]: Autorequiring File[/etc/
>puppet/ssl]
>debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring
>File[/etc/puppet/ssl]
>debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring File[/etc/
>puppet/ssl]
>debug: /File[/etc/puppet/ssl/private]: Autorequiring File[/etc/puppet/
>ssl]
>debug: /File[/etc/puppet/ssl/private_keys/puppetclient.1on1.com.pem]:
>Autorequiring File[/etc/puppet/ssl/private_keys]
>debug: /File[/etc/puppet/ssl/public_keys/puppetclient.1on1.com.pem]:
>Autorequiring File[/etc/puppet/ssl/public_keys]
>debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
>puppet]
>debug: Finishing transaction 174279260
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/rest.rb:97:in `rescue in http_request'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/rest.rb:81:in `http_request'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/rest.rb:76:in `block (2 levels) in '
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/rest.rb:118:in `find'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/certificate/rest.rb:11:in `find'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/indirection.rb:188:in `find'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/ssl/
>host.rb:180:in `certificate'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/ssl/
>host.rb:263:in `wait_for_cert'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>application/agent.rb:416:in `setup_host'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>application/agent.rb:480:in `setup'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>application.rb:305:in `block (2 levels) in run'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/pup

Re: [Puppet Users] Certificate Verify Failed

[Ben House]

PuppetNewbie  wrote:

>I could use some help.  I am a newbie with puppet, and am trying to
>learn it and use it here at the office.  I have created 2 CentOS 5.5
>machines ( puppet.1on1.com - puppetmaster and puppetclient.1on1.com -
>which will be the client that I control.)  When I attempt to connect
>my client to the master, I get the following output:
>
># puppet agent --server=puppet.1on1.com --no-daemonize --verbose --
>debug --trace
>debug: Failed to load library 'selinux' for feature 'selinux'
>debug: Failed to load library 'shadow' for feature 'libshadow'
>debug: Failed to load library 'ldap' for feature 'ldap'
>debug: Puppet::Type::User::ProviderLdap: feature ldap is missing
>debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/
>dscl does not exist
>debug: Puppet::Type::User::ProviderUser_role_add: file roleadd does
>not exist
>debug: Puppet::Type::User::ProviderPw: file pw does not exist
>debug: Puppet::Type::File::ProviderMicrosoft_windows: feature
>microsoft_windows is missing
>debug: /File[/var/lib/puppet/log]: Autorequiring File[/var/lib/puppet]
>debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/
>puppet]
>debug: /File[/var/lib/puppet/run]: Autorequiring File[/var/lib/puppet]
>debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
>debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/
>ssl]
>debug: /File[/etc/puppet/ssl]: Autorequiring File[/etc/puppet]
>debug: /File[/etc/puppet/ssl/public_keys]: Autorequiring File[/etc/
>puppet/ssl]
>debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring
>File[/etc/puppet/ssl]
>debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring File[/etc/
>puppet/ssl]
>debug: /File[/etc/puppet/ssl/private]: Autorequiring File[/etc/puppet/
>ssl]
>debug: /File[/etc/puppet/ssl/private_keys/puppetclient.1on1.com.pem]:
>Autorequiring File[/etc/puppet/ssl/private_keys]
>debug: /File[/etc/puppet/ssl/public_keys/puppetclient.1on1.com.pem]:
>Autorequiring File[/etc/puppet/ssl/public_keys]
>debug: /File[/etc/puppet/puppet.conf]: Autorequiring File[/etc/puppet]
>debug: /File[/var/lib/puppet/run/agent.pid]: Autorequiring File[/var/
>lib/puppet/run]
>debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/
>puppet]
>debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/
>puppet]
>debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/
>lib/puppet]
>debug: /File[/var/lib/puppet/state/graphs]: Autorequiring File[/var/
>lib/puppet/state]
>debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
>puppet]
>debug: Finishing transaction 167894360
>debug: /File[/var/lib/puppet/log]: Autorequiring File[/var/lib/puppet]
>debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/
>puppet]
>debug: /File[/var/lib/puppet/run]: Autorequiring File[/var/lib/puppet]
>debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
>debug: /File[/etc/puppet/ssl/certs]: Autorequiring File[/etc/puppet/
>ssl]
>debug: /File[/etc/puppet/ssl]: Autorequiring File[/etc/puppet]
>debug: /File[/etc/puppet/ssl/public_keys]: Autorequiring File[/etc/
>puppet/ssl]
>debug: /File[/etc/puppet/ssl/certificate_requests]: Autorequiring
>File[/etc/puppet/ssl]
>debug: /File[/etc/puppet/ssl/private_keys]: Autorequiring File[/etc/
>puppet/ssl]
>debug: /File[/etc/puppet/ssl/private]: Autorequiring File[/etc/puppet/
>ssl]
>debug: /File[/etc/puppet/ssl/private_keys/puppetclient.1on1.com.pem]:
>Autorequiring File[/etc/puppet/ssl/private_keys]
>debug: /File[/etc/puppet/ssl/public_keys/puppetclient.1on1.com.pem]:
>Autorequiring File[/etc/puppet/ssl/public_keys]
>debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
>puppet]
>debug: Finishing transaction 174279260
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/rest.rb:97:in `rescue in http_request'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/rest.rb:81:in `http_request'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/rest.rb:76:in `block (2 levels) in '
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/rest.rb:118:in `find'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/certificate/rest.rb:11:in `find'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>indirector/indirection.rb:188:in `find'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/ssl/
>host.rb:180:in `certificate'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/ssl/
>host.rb:263:in `wait_for_cert'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>application/agent.rb:416:in `setup_host'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>application/agent.rb:480:in `setup'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/puppet-2.7.3/lib/puppet/
>application.rb:305:in `block (2 levels) in run'
>/usr/local/rvm/gems/ruby-1.9.2-p290/gems/pup

[Puppet Users] Open Source Team iteration & planning summary 2011-08-26

[Jacob Helwig]

Puppet.features.root? will now correctly report whether Puppet is
running with elevated administrative privileges on Windows, instead of
always returning true (#8662).  Management of permissions and
ownership of Puppet's internal files was also disabled as part of this
change until the general problem of managing file ownership, and
permissions has been addressed.  This has been merged into the 2.7.x
branch, and should be available in the next 2.7.x release after 2.7.3.

The exec type now works on Windows (#8410).  This also includes some
refactoring around how Puppet determines whether a path is absolute or
not, which is a step towards a larger refactor in this area.  This has
been merged into the 2.7.x branch, and should be available in the next
2.7.x release after 2.7.3.

Jeff Blane provided a fix for a debug message (01df2375), which has
been merged into the master branch, and will be available in Telly.

Completed items:

 * #8662 - Puppet.features.root? always returns true on Windows

 * #8410 - Exec provider for Windows

 * Remove spurious "exec" from a debug string

Current backlog:

 * #8439 - Basic facter on Windows

 * #8414 - Task scheduler type/provider for Windows

 * #8411 - File type working on Windows

 * #9186 - Windows file security support

 * #9189 - File provider on Windows

 * #8412 - MSI package provider for Windows

 * #8413 - Ability to run Puppet as an agent on Windows

 * #7316 - puppet applications delivered via pluginsync don't work.

 * #5517 - Overriding parameters on included & inherited classes

 * #3741 - Custom facts loaded multiple times

 * #4916 - Plugins should not be able to override core functionality.

-- 
Jacob Helwig
,
| Join us for PuppetConf, September 22nd and 23rd in Portland, OR
| http://bit.ly/puppetconfsig
`


signature.asc
Description: Digital signature

[Puppet Users] Announce: Dashboard 1.2.0 is available now

[Michael Stahnke]

It's here.  Puppet Labs Announces Puppet Dashboard version 1.2.0.

This is a significant upgrade over the 1.1.x series, with new
features, prettier views and some all-in-all awesomeness.   Thanks to
those who filed bugs, submitted patches and helped with the RC
process.


Major Highlights:
--
*  Dashboard now processes workloads asynchronously with a delayed_job
worker.  The worker is controlled either through Rake in the RAILSROOT
or through init scripts (puppet-dashboard-workers) on rpm and deb
based systems.
* License change to Apache Software License version 2.0
* Upgraded version of Rails stack components
* Export most views to CSV
* Dashboard now requires Ruby 1.8.7 to operate
* Puppet agents should be at 2.6.4 or higher


This release is available for download at:
http://downloads.puppetlabs.com/dashboard/

We have included Debian and RPM packages as well as a tarball.

See the Verifying Puppet Download section at:
http://projects.puppetlabs.com/projects/puppet/wiki/Downloading_Puppet

Please report feedback via the Puppet Labs Redmine site, using an
affected version of 1.2.0
http://projects.puppetlabs.com/projects/dashboard

Documentation is available at:
http://docs.puppetlabs.com/dashboard/index.html


CHANGELOG since 1.1.1

v1.2.0
===
9c32431 (#8228) Reports fail to upload with spool directory
0bfa755 (#9101) Dashboard workers should not be enabled by default
3abc596 (#9103) Remove invalid files from git repo
f52b0ee (#9182) Fix ability to add classes and groups on creation
e924586 (#9195) Use a shorter date format for the report status graph
2e85b8d Apply security patch for XSS Vulnerability in the escaping
function in Ruby on Rails
d3bfcf5 Apply security patch for XSS Vulnerability in strip_tags helper
107f101 Apply security patch for SQL Injection Vulnerability in quote_table_name
0a73593 (#7934) Improve wording to filebucket error
fa8d27c (#7934) Give a better error message when filebucket contents don't exist
7b742e9 (#7934) Don't link md5s for new content
735925f (#9032) Update Debian package to ensure VERSION is packaged
620de4e (#8251 and #8042) Don't use our own logger
a2a97ab (#8796) Re-write misleading 500 error message
6b525b1 (#5845) Changed host to node in UI.
90f5ce0 (#8488) Move tfoot before tbody in reports table
ee1f182 (#8488) Make columns consistent between report views
e54ecb8 (#8790) Fix reports page column display and alignment
947dcee (#8748) Put sensible umask on pids and logs that delayed_job creates
4ef96b6 (#8785) Close a directory that we open
0bfbbf6 (#8785) - Revert "(#8748) Upgrade vendored daemons gem to fix
umask on pids"
3f88c7f (#8748) Fix my forgetting to add a vendored gem
2f636a9 Allow setting of RUBY for the workers on redhat systems
651511c (#8748) Upgrade vendored daemons gem to fix umask on pids
3a65fd0 (#8694) Add backtrace info to DelayedJobFailure
bf22939 Add document outlining preferred contribution methods
49cca0b Add document outlining preferred contribution methods
803be4f (#8745) Update gitignore to not exlucde tmp during tarball creation
e45338a (#8691) Fix the order of changed and unchanged resources on
the report summary
7653800 Provide clearer error message when report host, kind and time
are not unique
e86526f (#8686) Handle concurrent DelayedJob workers importing for same node
88771ec (#8589) Report events are now ordered by name.
8bd0ffb (#8544) Make empty inspected resources "red".
d036276 (#8505) Update the default date stringification.
bb99ed9 Properly Quote RAILS_ROOT in get_app_version method
08717e1 (#8508) Add delayed job worker script for debian/ubuntu package
2eef4f4 (#8529) Remove unneeded a print statement from sass.rb
af8b6e9 (#8500) Replace README with a smaller one
dff2256 (#8499) Update the usage of mktemp in Rakefile to work on mac
3f0afca (#8484) "Nodes for this group" heading now appears correctly
d389d8b (#7568) Relicense to Apache-2.0 License
82eeea7 (#7567) Refactor dashboard packaging to allow for nightly builds
a58f3e0 (#6840) Remove need for VERSION file in puppet-dashboard
d9a384f (#8316) Ruby sorting for ResourceEvents.
57d0122 (#8276) Remove MaRuKu dependency
a44d9ff (#8262) Show node groups even when node classification is disabled
3996b29 (#8262) Create callbacks for each section of node_classification partial
8f7da94 Remove unused node_groups/_node_groups partial
5dac13a (#8199) Move 'failed' resources to the top when viewing report events
2a3a73c (#7967) Improved user-facing design for delayed job warnings
c78b85a (#8266) Back-end logic for splitting read and unread DJ failures.
15bba31 (#8121) Properly generate CSS from SASS in production.
68c0236 Maint: Added $RAILSROOT/spool directory
365a432 Maint: Removing reference to CentOS 5.5.
518bbca Maint: Added rake task to generate srpm
223822e Maint: Updated rpm spec file.
a9abf41 (#8101) Updated to new version of Tipsy plugin
9cb5e55 (Maint) More generalized tabbed interface
07ae6f7 Updating to rename pupet-dashboard-workers
491cf33 Updating spec.
a428d15 

[Puppet Users] Re: facter identifies Oracle Linux 6.1 as 'RedHat'

[Avi Miller]

Hi Nan,

On Aug 25, 2:20 am, Nan Liu  wrote:
> Should we still use OEL? If we change the the value to OracleLinux,
> besides manifests changes, we also need to update types and provider
> that are currently configured to :confine(OEL).

I would prefer to change it to OracleLinux as it is no longer referred
to as OEL. I did change the other location in Facter that OEL is
referenced as well. The problem is that OEL is marked by the existence
of /etc/enterprise-release, while OracleLinux, i.e. from 5 Update 6
and higher, is identified by the existence of /etc/oracle-release.

That would also give users a way to differentiate between the older
releases and the newer ones. But, it's your call. I just submitted the
patch. :) You guys get to decide what to do with it.

Cheers,
Avi

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

Re: [Puppet Users] Custom provider works only immediately after sync

[Stefan Schulte]

On Fri, Aug 26, 2011 at 08:13:03AM -0700, Adrian Casajús wrote:
> Hi all,
> 
>  I've got a custom type with a single custom provider. I've got
> enabled pluginsync in both client and server. When I run the puppet
> agent in the client it syncs the type and the provider and properly
> executes them. But if I execute the agent again it will tell me
> 
> err: Could not run Puppet configuration client: Could not find a
> default provider for passwduser
> 
> If I go to the server and modify a single line just to trigger the
> sync and execute the agent again, it properly syncs the modification
> and runs properly the provider. Then if I run again it goes back to no
> default provider.
> 
> Any hints? tips? I've looked at the docs and the mailing list and
> haven't found anything similar.
> 
> Thanks for any hint.
> 
> Cheers,
>  Adri

Both files are .rb Files? I just know that when puppet syncs plugins, it
will load them no matter what they are (READMEs, helper scripts that are
not written in ruby, etc) while on a normal puppetrun puppet will just
load the ruby code.

-Stefan


pgpaDxdaj7cHs.pgp
Description: PGP signature