Re: [Puppet Users] Couldn't worked reports in last foreman snapshot's (09.28.10)

[Ohad Levy]

Hi,

This was fixed at http://theforeman.org/issues/394.

Ohad

On Wed, Sep 29, 2010 at 2:40 PM, koliama  wrote:

> Hello all,
> I upgrade my foreman from last snapshot's in testing env. When I click
> on "Reports" or "host name" url I see error message in foreman
> error_log:
>
> => Booting WEBrick
> => Rails 2.3.5 application starting on http://0.0.0.0:3000
> => Call with -d to detach
> => Ctrl-C to shutdown server
> [2010-09-29 16:35:46] INFO  WEBrick 1.3.1
> [2010-09-29 16:35:46] INFO  ruby 1.8.7 (2009-06-08) [i386-linux]
> [2010-09-29 16:35:46] INFO  WEBrick::HTTPServer#start: pid=13573
> port=3000
>
>
> Processing HostsController#index (for 172.30.64.135 at 2010-09-29
> 16:35:49) [GET]
>  Parameters: {"action"=>"index", "controller"=>"hosts"}
> Rendering template within layouts/standard
> Rendering hosts/index
> Completed in 233ms (View: 101, DB: 11) | 200 OK [http://srv2-puppet/]
>
>
> Processing HostsController#show (for 172.30.64.135 at 2010-09-29
> 16:35:51) [GET]
>  Parameters: {"action"=>"show", "id"=>"srv-redhat.net.billing.ru",
> "controller"=>"hosts"}
>
> NoMethodError (undefined method `round_with_precision' for 0:Fixnum):
>  app/models/report.rb:68:in `config_retrieval'
>  app/models/host.rb:394:in `graph'
>  app/models/host.rb:393:in `graph'
>  app/controllers/hosts_controller.rb:28:in `show'
>  app/controllers/hosts_controller.rb:22:in `show'
>  /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
>  /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
>  /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
>  /usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
>  /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
>  /usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
>  /usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
>  /usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
>  /usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
>  /usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
>
> Rendering /var/rails/foreman/public/500.html (500 Internal Server
> Error)
>
>
> Processing ReportsController#index (for 172.30.64.135 at 2010-09-29
> 16:36:15) [GET]
>  Parameters: {"action"=>"index", "controller"=>"reports"}
> Rendering template within layouts/standard
> Rendering reports/index
>
> ActionView::TemplateError (undefined method `round_with_precision' for
> 0:Fixnum) on line #27 of app/views/reports/_list.html.erb:
> 24:   <%= h report.failed %>
> 25:   <%= h report.failed_restarts %>
> 26:   <%= h report.skipped %>
> 27:   <%= h report.config_retrieval %>
> 28:   <%= h report.runtime %>
> 29:   
> 30: <%= link_to "Details", report %>
>
>app/models/report.rb:68:in `config_retrieval'
>app/views/reports/_list.html.erb:27
>app/views/reports/_list.html.erb:16:in `each'
>app/views/reports/_list.html.erb:16
>app/views/reports/index.html.erb:3
>/usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service'
>/usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run'
>/usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread'
>/usr/lib/ruby/1.8/webrick/server.rb:162:in `start'
>/usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread'
>/usr/lib/ruby/1.8/webrick/server.rb:95:in `start'
>/usr/lib/ruby/1.8/webrick/server.rb:92:in `each'
>/usr/lib/ruby/1.8/webrick/server.rb:92:in `start'
>/usr/lib/ruby/1.8/webrick/server.rb:23:in `start'
>/usr/lib/ruby/1.8/webrick/server.rb:82:in `start'
>
> Rendering /var/rails/foreman/public/500.html (500 Internal Server
> Error)
>
> What's wrong?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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: getting empty files from fileserver

[Naresh V.]

Hi,

I gave this another attempt recently with 2.6.2rc1, nginx, and thin
via config.ru. (not nginx + mongrels like earlier)
Now I know a little more about the problem than I did a month ago:

I use a lot of variables such as $project in my file path array I set
for the source parameter for file type resources:

>     source => [
>                "puppet:///imapproxy/$project/imapproxy.conf.$hostname",

And in my site manifest, I tend to have

class foo {
 $project = "blah"
 include imapproxy
}

node bar {
 include foo
}

I get the correct file served when I use the stock WEBrick/
puppetmasterd and I don't get the correct file served with nginx+thin
+config.ru unless I do:

node bar {
  $project = "blah"
  include imapproxy
}

FWIW, my server-side logs don't show me the $project part in the GETs
at all - the $hostname (and other facts are) is shown.

[2010-10-06 00:04:35] bar - - [06/Oct/2010:00:04:35 CDT] "GET /
production/file_metadata/users//sudoers.xen-3 HTTP/1.1" 404 48
[2010-10-06 00:04:35] bar - - [06/Oct/2010:00:04:35 CDT] "GET /
production/file_metadata/users//sudoers- HTTP/1.1" 404 43
[2010-10-06 00:04:35] bar - - [06/Oct/2010:00:04:35 CDT] "GET /
production/file_metadata/users//sudoers HTTP/1.1" 200 336

There should've been a "GET /production/file_metadata/users/blah/
sudoers.xen-3" etc.)


Thank you,
Naresh.

On Aug 25, 6:23 pm, "Naresh V."  wrote:
> Hi,
>
> My setup:
>
> gems:
> rack (1.0.1)
> rails (2.3.4)
> rake (0.8.7)
> activerecord (2.3.8, 2.3.4)
> activeresource (2.3.8, 2.3.4)
> activesupport (2.3.8, 2.3.4)
> mongrel (1.1.5)
>
> RPMs:
> puppet-server-2.6.0-0.7.el5 (tmz's)
>
> I patched the files installed via the RPM to test out nginx+mongrel as
> follows (taken fromhttp://projects.puppetlabs.com/issues/4319):
>
> http://pastie.org/1114966
>
> The problem I'm facing is:
> My modules have 'source' like:
>
>     source => [
>                "puppet:///imapproxy/$project/imapproxy.conf.
> $hostname",
>                "puppet:///imapproxy/$project/imapproxy.conf-$class",
>                "puppet:///imapproxy/imapproxy.conf.$hostname",
>                "puppet:///imapproxy/imapproxy.conf",
>                ],
>
> in my files directory, I have:
>
> /projectA/imapproxy.conf-webmail
> /projectA/imapproxy.conf
>
> In my site manifest, I have a few webmail servers which have $class =
> 'webmail' in them and a few which don't have any $class set to
> something else. Before I migrated to the nginx+mongrel setup (and
> after I reverted back from it), for the nodes that have a $class !=
> 'webmail', the default imapproxy.conf was being served, but now, I'm
> served an emtpy file instead.
>
> The hosts with $class = 'webmail' face no such problem - they receive
> the file they were supposed to receive.
>
> ($project is set to 'projectA' for all nodes in the manifest.)
>
> Is anybody else able to replicate this?
>
> -Naresh.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Puppetd attempting to install packages that aren't required

[Jeff McCune]

On Tue, Oct 5, 2010 at 12:16 AM, ncantor  wrote:
> However, by default, the package isn't called by anything.

There's also a subtle shift in thinking that may help you work with
puppet.  In the puppet language, resources are "declared" rather than
"called"  It's a bit strange because many resources actually look like
function calls, especially when you start defining your own resources,
but they really do not behave much like functions, procedures or
methods in other languages.

If you shift your thinking to "I am declaring the configuration of
this package resource" rather than "I am calling this package
resource" the language might make more sense.  In puppet, the idea is
not to write procedures and actions but rather to declare the desired
state.  In most cases declaring the desired state is enough for puppet
to "figure out" the actions to carry out to get the system into that
state.

This is why puppet was able to, and did, take action on your systems
without you actually telling it to install the package.  Instead, you
told it you wanted the package installed.  See the subtle difference?

Hope this helps,
-- 
Jeff McCune
http://www.puppetlabs.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-us...@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] Puppetd attempting to install packages that aren't required

[Jeff McCune]

On Tue, Oct 5, 2010 at 12:16 AM, ncantor  wrote:
> For some reason, puppet is attempting to install ruby-enterprise on
> all my puppet clients.

You told puppet to do so.  =)  I don't mean to be a jerk, but this
really is the simple answer.

> The only reason I can find for this behaviour
> is that I've defined a package to install ruby-enterprise. However, by
> default, the package isn't called by anything.

Unless you put the declaration inside of a defined resource type, or a
class, then it will be included in the configuration catalog of all
nodes.  In this case, the package has been declared at top scope.

> In order to get the package to only install on the systems that I
> wanted to have it, I had to move it from a general package definition
> to be inside a class. Is this normal behaviour?

Yep, a class is a collection and intended to bundle together a set of
resources into something you can easily add or remove from nodes.
This is generally called node classification as in "I've classified
this node as a web server." or "This node is classified as a
ruby-enterprise node."

Nodes may have many classes.

Hope this helps,
-- 
Jeff McCune
http://www.puppetlabs.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-us...@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] How do you ensure safety from errors/bugs in large deployments?

[Jeff McCune]

On Tue, Oct 5, 2010 at 6:05 PM, Mohamed Lrhazi  wrote:
> Hello all,
>
> This is not a puppet proper issue of course.. but I was wondering if
> any of you could share some thoughts...
>
> When you deploy a system like Puppet at a large park of systems, you
> instantly increase the efficacy of mistakes and bugs in destroying the
> environment

With great power comes great responsibility.

> How do you deal with that? I would be interested in any experience or
> input, especially puppet proper best practices...

In addition to the other responses (testing, some more testing, and a
well defined release process) I also recommend a "Big red stop button"
of sorts.  Few sites seem to employ this, but the ones who have have
reported it to be incredibly useful when necessary and enjoy a little
more peace of mind.

The big red stop button can take many forms.  I personally use a
wrapper script to launch puppet agent runs from cron, so the stop
button in my case  could be a simple curl command before running
puppet agent and the agent proceeds if and only if the curl command
does not get a valid 200 response from the HTTP request.

This allow you to quickly touch a file somewhere and know it will halt
all puppet agents on all of your nodes.

-- 
Jeff McCune
http://www.puppetlabs.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-us...@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] How do you ensure safety from errors/bugs in large deployments?

[Nigel Kersten]

On Tue, Oct 5, 2010 at 6:05 PM, Mohamed Lrhazi  wrote:
> Hello all,
>
> This is not a puppet proper issue of course.. but I was wondering if
> any of you could share some thoughts...
>
> When you deploy a system like Puppet at a large park of systems, you
> instantly increase the efficacy of mistakes and bugs in destroying the
> environment
> How do you deal with that? I would be interested in any experience or
> input, especially puppet proper best practices...


Lots of precommit hooks to catch the obvious human errors
Easy to use testing environment so you can test your changes quickly.
Strict release process. We follow unstable -> testing -> stable like Debian.

You absolutely need to sort your release process out.



>
> BTW, does puppet have any means to say something like "don't ever do
> anything that takes more than 5 minutes? or that involves more than
> 1000 files/inodes?
>
> Thanks a lot.
> Mohamed.
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>



-- 
nigel

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] How do you ensure safety from errors/bugs in large deployments?

[Patrick]

On Oct 5, 2010, at 6:05 PM, Mohamed Lrhazi wrote:

> Hello all,
> 
> This is not a puppet proper issue of course.. but I was wondering if
> any of you could share some thoughts...
> 
> When you deploy a system like Puppet at a large park of systems, you
> instantly increase the efficacy of mistakes and bugs in destroying the
> environment
> How do you deal with that? I would be interested in any experience or
> input, especially puppet proper best practices...

The answer is simple, although simple is not the same as quick or easy.  You 
can avoid most problems like that by having different environments and testing 
your changes in a development environment on a representative sample of you 
machines you are managing.


-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] How do you ensure safety from errors/bugs in large deployments?

[Mohamed Lrhazi]

Hello all,

This is not a puppet proper issue of course.. but I was wondering if
any of you could share some thoughts...

When you deploy a system like Puppet at a large park of systems, you
instantly increase the efficacy of mistakes and bugs in destroying the
environment
How do you deal with that? I would be interested in any experience or
input, especially puppet proper best practices...

BTW, does puppet have any means to say something like "don't ever do
anything that takes more than 5 minutes? or that involves more than
1000 files/inodes?

Thanks a lot.
Mohamed.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Can a hacker take over by impersonating puppetmaster?

[Patrick]

On Oct 5, 2010, at 5:55 PM, Mohamed Lrhazi wrote:

> On Mon, Oct 4, 2010 at 7:17 PM, Nan Liu  wrote:
>> Correction. The puppet agent fetches the CA cert and it verifies the
>> puppet master cert is signed by the CA cert. If not, the agent will
>> not communicate with puppet master due to a cert mismatch.
> 
> Thanks a lot Nan. I think I have just one more clarification to ask...
> Where does the client fetch the CA cert from and how often?
> 
> I guess I'll feel all safe if the fetching happens during the initial
> setup phase of a new client, and it keeps it locally from that point
> on.

I believe the client will not actually save the ca's certificate until the 
client has a signed cert.  After that point it keeps the cert.  The distro I 
use keeps it in /var/lib/puppet/ssl/ca.pem.  You can always just put that cert 
into what ever process you use to install puppet in the first place if you're 
worried. 

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Can a hacker take over by impersonating puppetmaster?

[Mohamed Lrhazi]

On Mon, Oct 4, 2010 at 7:17 PM, Nan Liu  wrote:
> Correction. The puppet agent fetches the CA cert and it verifies the
> puppet master cert is signed by the CA cert. If not, the agent will
> not communicate with puppet master due to a cert mismatch.

Thanks a lot Nan. I think I have just one more clarification to ask...
Where does the client fetch the CA cert from and how often?

I guess I'll feel all safe if the fetching happens during the initial
setup phase of a new client, and it keeps it locally from that point
on.

Thanks,
Mohamed.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Help Puppet get better. Take an 8-minute survey.

[Hal Newton]

It case you missed the other messages on this topic, you can help
Puppet improve by taking an 8-minute survey. The survey is open
through October 15.. http://bit.ly/ayJ0hN

Your perspective is an important part of this process. Thanks for
participating.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] puppetd memory consumption

[Patrick]

This is huge.  Are you serving a lot of big files or templates?

On Oct 5, 2010, at 4:01 AM, Angelos Oikonomopoulos wrote:

> Hello all,
> 
> I'm playing with a new puppet setup (2.6.1 on debian stable with ruby 1.8) 
> and I've run into a problem with puppetd consuming ridiculous amounts of 
> memory.
> 
> My setup isn't that complex (apache2 configuration and a few other 
> packages/services), but puppetd will force the machine into swapping. It 
> seems to be CPU bound; if I run strace -e '!rt_sigprocmask' on it, I can see 
> that the only system calls it makes are brk() calls. The system ends up 
> swapping heavily and of course puppetd never makes progress. (On this VM with 
> 512MB of RAM, puppetd ends up w/ an RSS that oscillates around 450MB, while 
> having 596MB mapped).
> 
> It seems like there's a superlinear algorithm or some infinite loop that's 
> triggered by my configuration. FWIW, the catalog for this client is 3145 
> lines long and the server compiles it in 0.21 seconds.
> 
> Now, this client was able to run the catalog just fine a few days ago, so I'm 
> going to concentrate on my last set of changes, but I'm reporting this here 
> as this seems like an obvious bug to me. Perhaps others have run into it 
> before?
> 
> Also, is there some mechanism to monitor what puppetd is doing that will 
> provide me with more information than --debug?
> 
> Thanks,
> Aggelos
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@googlegroups.com.
To unsubscribe from this group, send email to 
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en.

[Puppet Users] Puppet Server

[Christian Bryant]

I'm going to be starting a project in a month or so for a Puppet
Server using SUSE Studio to generate the ISO and VM I'll be using for
testing.  I'm curious to get feedback from folks that have already
built Puppet servers.  I don't have any specific questions yet,
naturally, but I would like to know how it's working for you.  Also,
per every server, how nodes on average is everyone managing?

Cheers,

Christian Bryant
http://en.opensuse.org/User:christian_bryant

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Puppetd attempting to install packages that aren't required

[Bruce Richardson]

On Tue, Oct 05, 2010 at 12:16:28AM -0700, ncantor wrote:
> In order to get the package to only install on the systems that I
> wanted to have it, I had to move it from a general package definition
> to be inside a class. Is this normal behaviour?

Yes.  If you do want packages to be visible at the top level, to
absolutely everything, but only installed when you want them, then you
should make them virtual resources and then realize them where you need
them.

What is your motive for defining packages at the top level?  As with
most resources, it's usually better to define them within the
classes/modules which need them and just include the class.  This allows
you to concentrate on high level function (e.g. "This node should get
its user and group data from an ldap server at $uri") in your main
config and keep the low level details ("On Debian, the nss_ldap config
file is '/etc/libnss-ldap.conf'") hidden within the module.

-- 
Bruce

I object to intellect without discipline.  I object to power without
constructive purpose. -- Spock

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] questions about certs on 2.6.1

[Arnau Bria]

On Sun, 03 Oct 2010 11:54:45 +0200
Brice Figureau wrote:

[...]

> > But when I run an "old" client, which already have ca from prod
> > server (which is the same a test one), it runs with no problem:
> 
> This is normal too. The client knows the CA, it can validate the new
> master server certificate. The reverse is also true, the server can
> validate the client cert because it was signed by the same CA
> certificate (and it is not in the CRL).
Ok, it's not in CRL. miss that.
 
[...]
thanks for the rest of explanation.

> > 2.-) If I revoke (clean) a cert of a client, the cert is revoke but
> > client is able to run against server:
> > 
> > Server:
> > 
> > #  puppetca --list  --all
> > + test.pic.es (BB:1A:38:12:F8:83:EF:C6:D6:93:C2:1E:EB:FD:E2:89)
> > + client.pic.es (87:08:04:8F:9B:CE:17:F6:1A:56:15:90:15:72:92:09)
> > 
> > #  puppetca --clean client.pic.es
> > notice: Revoked certificate with serial 2008
> > notice: Removing file Puppet::SSL::Certificate client.pic.es at
> > '/var/lib/puppet/ssl/ca/signed/client.pic.es.pem' notice: Removing
> > file Puppet::SSL::Certificate client.pic.es at
> > '/var/lib/puppet/ssl/certs/client.pic.es.pem'
> > 
> > client:
> > #  puppetd --server ser01-test.pic.es --test
> > info: Caching catalog for client.pic.es
> > info: Applying configuration version '1285678851'
> > notice: Finished catalog run in 0.01 seconds
> > 
> > 
> > Is it a desired behaviour? if yes, how may I revoke certs so clients
> > can't connect to master again?
> 
> It shouldn't. Check your nginx/apache configuration, it should have
> the necessary statements to check the crl.
> For instance on my nginx master:
> ssl_crl /var/lib/puppet/ssl/ca/ca_crl.pem;
> 
> You also need a nginx version that supports the CRL (ie >= 0.7.64)

Will do,

thanks for your reply,

Arnau

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Facter ignores interfaces with non eth names

[Christopher Johnston]

I got this working by modifying the regex which seems to be explicit for a
specific output, but in reality it could be simpler - unless I am missing
something.  This change works for me now and I tested various interface
names (eth0, eth0.100, bond0, eth, WAN, LAN).  Thoughts?

$ git diff ip.rb
diff --git a/lib/facter/util/ip.rb b/lib/facter/util/ip.rb
index 366303c..32d943e 100644
--- a/lib/facter/util/ip.rb
+++ b/lib/facter/util/ip.rb
@@ -56,7 +56,7 @@ module Facter::Util::IP
 # at the end of interfaces.  So, we have to trim those trailing
 # characters.  I tried making the regex better but supporting all
 # platforms with a single regex is probably a bit too much.
-output.scan(/^[-\w]+[.:]?\d+[.:]?\d*[.:]?\w*/).collect { |i|
i.sub(/:$/, '') }.uniq
+output.scan(/^[-\w]\S*/).collect { |i| i.sub(//, '') }.uniq
 end

 def self.get_all_interface_output


On Tue, Oct 5, 2010 at 9:37 AM, Christopher Johnston wrote:

> Yes, but by X you mean they are represented with a digit?  I have systems
> that do not have interfaces represented with the name and then a digit (WAN,
> LAN, BACKUP, etc).  The regex looks to not pick those interfaces up.
>
>
> On Tue, Oct 5, 2010 at 9:31 AM, Joe McDonagh 
> wrote:
>
>> On 10/04/2010 05:35 PM, Christopher Johnston wrote:
>>
>>> Does facter support NICs that are not named ethX? I happen to use custom
>>> names on my systems.  Just a quick look at the code I don't see why it
>>> wouldn't but the behavior I am seeing is very different. --
>>>
>>> You received this message because you are subscribed to the Google Groups
>>> "Puppet Users" group.
>>> To post to this group, send email to puppet-us...@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.
>>>
>> On OpenBSD NIC devices are named based on the driver they use, and in some
>> cases the meta-type of the NIC (trunkX, carpX). Those all show up in facter
>> on those machines.
>>
>> --
>> Joe McDonagh
>> AIM: YoosingYoonickz
>> IRC: joe-mac on freenode
>> "When the going gets weird, the weird turn pro."
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-us...@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-us...@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] puppetd memory consumption

[Trevor Vaughan]

You might want to try running the client with --evaltrace for
additional information.

Trevor

On 10/5/10, Angelos Oikonomopoulos
 wrote:
> Hello all,
>
> I'm playing with a new puppet setup (2.6.1 on debian stable with ruby
> 1.8) and I've run into a problem with puppetd consuming ridiculous
> amounts of memory.
>
> My setup isn't that complex (apache2 configuration and a few other
> packages/services), but puppetd will force the machine into swapping. It
> seems to be CPU bound; if I run strace -e '!rt_sigprocmask' on it, I can
> see that the only system calls it makes are brk() calls. The system ends
> up swapping heavily and of course puppetd never makes progress. (On this
> VM with 512MB of RAM, puppetd ends up w/ an RSS that oscillates around
> 450MB, while having 596MB mapped).
>
> It seems like there's a superlinear algorithm or some infinite loop
> that's triggered by my configuration. FWIW, the catalog for this client
> is 3145 lines long and the server compiles it in 0.21 seconds.
>
> Now, this client was able to run the catalog just fine a few days ago,
> so I'm going to concentrate on my last set of changes, but I'm reporting
> this here as this seems like an obvious bug to me. Perhaps others have
> run into it before?
>
> Also, is there some mechanism to monitor what puppetd is doing that will
> provide me with more information than --debug?
>
> Thanks,
> Aggelos
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>
>


-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Our new survey

[Luke Kanies]

Hi All,

You've probably all received our new survey.  We're hoping you'll
spend a few minutes helping us understand how you use Puppet and what
we (both the Puppet developers and Puppet Labs) can do to make your
experience better.

One of the things that the survey mentions is a commercial edition of
Puppet - I've mentioned this before, and it's basically a packaged,
supported distribution of Puppet, associated tools, and all of its
dependencies needed for a fully scalable installation.  I've mentioned
this before, and the goal is to provide a higher level of support for
those who want help with the full stack rather than just Puppet and
for those who want less frequent and more consistent release cycles.

We are still figuring this product out, and your filling out the
survey will really help us understand what, if anything, you would
like to see from us here.

Thanks,
Luke

-- 
http://puppetlabs.com/ | +1-615-594-8199 | @puppetmasterd

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Override puppet environment at the command line

[Tony G.]

Kenneth,

On Tue, Oct 5, 2010 at 8:20 AM, Kenneth Holter wrote:

> Hi all.
>
>
> My puppet client has "environment = envA" defined in
> /etc/puppet/puppet.conf, but I'd like to override this manuall at the
> command line: "puppetd --server puppet.master.com --environment=envB".
> This doens't seem to work, so it always run code from envA. Is there a way
> to override the environment variable like this?
>
> It should work with --environment=envB..

Which version are you running?  Could you share the puppet.conf in your
master to see how you set the environments?

Once I had this issue and the settings were ok until I realized that in the
client there were two conf files in /etc/puppet those were puppet.conf and
puppetd.conf the latter was used in older versions of puppet.
http://groups.google.com/group/puppet-users/browse_thread/thread/95cf5a8552ba086a/8ca3447f3d35f128?lnk=gst&q=tonysk8#8ca3447f3d35f128

>
> Best regards,
> Kenneth Holter
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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.
>



-- 
Tony
http://blog.tonyskapunk.net

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: StoreConfigs not supported without ActiveRecord 2.1 or higher, but 3.0.0 is installed.

[James Turnbull]

bwood wrote:

Thanks for the reply. I'll try the RC.  Should it work with the 0.25
releases?



Puppet masters should always be the more recent release - so a 2.6.2 
master will support 0.25.x clients.


Regards

James Turnbull

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] puppetd memory consumption

[Angelos Oikonomopoulos]

Hello all,

I'm playing with a new puppet setup (2.6.1 on debian stable with ruby 
1.8) and I've run into a problem with puppetd consuming ridiculous 
amounts of memory.


My setup isn't that complex (apache2 configuration and a few other 
packages/services), but puppetd will force the machine into swapping. It 
seems to be CPU bound; if I run strace -e '!rt_sigprocmask' on it, I can 
see that the only system calls it makes are brk() calls. The system ends 
up swapping heavily and of course puppetd never makes progress. (On this 
VM with 512MB of RAM, puppetd ends up w/ an RSS that oscillates around 
450MB, while having 596MB mapped).


It seems like there's a superlinear algorithm or some infinite loop 
that's triggered by my configuration. FWIW, the catalog for this client 
is 3145 lines long and the server compiles it in 0.21 seconds.


Now, this client was able to run the catalog just fine a few days ago, 
so I'm going to concentrate on my last set of changes, but I'm reporting 
this here as this seems like an obvious bug to me. Perhaps others have 
run into it before?


Also, is there some mechanism to monitor what puppetd is doing that will 
provide me with more information than --debug?


Thanks,
Aggelos

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

[Puppet Users] puppet push mode

[James Louis]

Hello All,

I am trying to put puppet into push mode only. The instructions I've seen
have said to put listen=true in puppet.conf but that doesn't seem to have
stopped the pull every 30 minutes. What else needs to be set?

Thanks,

Jim

-- 
“Twenty years from now you will be more disappointed by the things that you
didn’t do than by the ones you did do. So throw off the bowlines. Sail away
from the safe harbor. Catch the trade winds in your sails. Explore. Dream.
Discover.”
– Mark Twain

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: StoreConfigs not supported without ActiveRecord 2.1 or higher, but 3.0.0 is installed.

[bwood]

Thanks for the reply. I'll try the RC.  Should it work with the 0.25
releases?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Facter ignores interfaces with non eth names

[Christopher Johnston]

Yes, but by X you mean they are represented with a digit?  I have systems
that do not have interfaces represented with the name and then a digit (WAN,
LAN, BACKUP, etc).  The regex looks to not pick those interfaces up.

On Tue, Oct 5, 2010 at 9:31 AM, Joe McDonagh wrote:

> On 10/04/2010 05:35 PM, Christopher Johnston wrote:
>
>> Does facter support NICs that are not named ethX? I happen to use custom
>> names on my systems.  Just a quick look at the code I don't see why it
>> wouldn't but the behavior I am seeing is very different. --
>>
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-us...@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.
>>
> On OpenBSD NIC devices are named based on the driver they use, and in some
> cases the meta-type of the NIC (trunkX, carpX). Those all show up in facter
> on those machines.
>
> --
> Joe McDonagh
> AIM: YoosingYoonickz
> IRC: joe-mac on freenode
> "When the going gets weird, the weird turn pro."
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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: Question regarding the SERVICE type

[D.N. van der Meijden]

*ahem* ...found it

PATH settings:
export PATH="${PATH:+$PATH:}/usr/sbin:/sbin"

works... (with /usr/sbin/zabbix_agentd)
Can't seem to get it working with /etc/zabbix/sbin/zabbix_agentd
though??



On 5 okt, 14:53, "D.N. van der Meijden" 
wrote:
> I hope I'm not spamming this group, but just trying to share
> everything :-)
>
> I tried using a new puppet client (v2.6.1), but same results:
> ...
> debug: Loaded state in 0.00 seconds
> info: Applying configuration version '1286282327'
> debug: Service[JADDA](provider=debian): Executing '/etc/init.d/
> zabbix_agent status'
> debug: Service[JADDA](provider=debian): Executing '/etc/init.d/
> zabbix_agent start'
> err: /Stage[main]//Service[JADDA]/ensure: change from stopped to
> running failed: Could not start Service[JADDA]: Execution of '/etc/
> init.d/zabbix_agent start' returned 1:  at /tmp/jadda.pp:6
> debug: Finishing transaction 70131490329360
> debug: Storing state
> debug: Stored state in 0.01 seconds
>
> Also tried the zabbix manifest file (http://projects.puppetlabs.com/
> projects/1/wiki/Zabbix_Agent_Patterns), but this one fails as well
>
> this is getting ridiculous, as all other daemons work perfectly...
>
> On 5 okt, 13:22, "D.N. van der Meijden" 
> wrote:
>
>
>
> > By the way I tried the 'puppet' command to get some more info:
>
> > client:/tmp# puppet -d -v jadda
> > debug: file /sbin/chkconfig does not exist
> > debug: file /usr/sbin/svcadm does not exist
> > debug: file /sbin/rc-update does not exist
> > debug: Creating default schedules
> > debug: Service[zabbix_agent](provider=debian): Executing '/etc/init.d/
> > zabbix_agent status'
> > debug: Puppet::Type::Service::ProviderDebian: Executing '/usr/sbin/
> > update-rc.d -n -f zabbix_agent remove'
> > debug: //Service[zabbix_agent]: Changing ensure
> > debug: //Service[zabbix_agent]: 1 change(s)
> > debug: Service[zabbix_agent](provider=debian): Executing '/etc/init.d/
> > zabbix_agent start'
> > err: //Service[zabbix_agent]/ensure: change from stopped to running
> > failed: Could not start Service[zabbix_agent]: Execution of '/etc/
> > init.d/zabbix_agent start' returned 1:  at /tmp/jadda.pp:6
> > debug: Finishing transaction 7018954900 with 1 changes
>
> > client:/tmp# cat jadda.pp
> >    service { "zabbix_agent":
> >       name      => "zabbix_agent",
> >       enable    => true,
> >       ensure    => running,
> >       hasstatus => true,
> >    }
>
> > On 5 okt, 13:11, "D.N. van der Meijden" 
> > wrote:
>
> > > Thanks for the extra info Nan.
> > > I've changed the init script to support the status option, but to no
> > > avail...
>
> > > +  . /lib/lsb/init-functions
> > > +
> > > +  status)
> > > +     status_of_proc -p $PID && exit 0 || exit $?
> > > +     ;;
>
> > > after this the status option works, but puppet still cannot start the
> > > daemon...
> > > as a workaround I can reboot the client (since the daemon does start
> > > after a reboot because of the rc2.d symlink created by the mantifest
> > > file), but this is not really an option...
>
> > > The only thing I can think of right now is that the zabbix_agent
> > > daemon needs to run as userzabbix, and puppet can't get it to run
> > > that way (I know really far fetched, but I'm getting out of options
> > > here..)
>
> > > On 30 sep, 18:26, Nan Liu  wrote:
>
> > > > On Thu, Sep 30, 2010 at 8:46 AM, D.N. van der Meijden
>
> > > >  wrote:
> > > > > Here's the init script:
>
> > > > > (by the way, I changed the service to rsyslog [in thezabbixmanifest
> > > > > file] and this works like a charm. So the service action works in
> > > > > puppet...)
>
> > > > > #! /bin/sh
> > > > > PATH=/bin:/usr/bin:/sbin:/usr/sbin:/etc/zabbix:/etc/zabbix/bin:/etc/
> > > > >zabbix/sbin
> > > > > DAEMON=/etc/zabbix/sbin/zabbix_agentd
> > > > > NAME=zabbix_agentd
> > > > > DESC="Zabbixagent"
> > > > > PID=/var/tmp/$NAME.pid
>
> > > > > test -f $DAEMON || exit 0
> > > > > set -e
> > > > > case "$1" in
> > > > >  start)
> > > > >        echo "Starting $DESC: $NAME"
> > > > >        start-stop-daemon --oknodo --start --pidfile $PID \
> > > > >                --exec $DAEMON
> > > > >        ;;
> > > > >  stop)
> > > > >        echo "Stopping $DESC: $NAME"
> > > > >        start-stop-daemon --oknodo --stop  --pidfile $PID \
> > > > >                --exec $DAEMON
> > > > >        ;;
> > > > >  restart|force-reload)
> > > > >        $0 stop
> > > > >        $0 start
> > > > >        ;;
> > > > >  *)
> > > > >        N=/etc/init.d/$NAME
> > > > >        echo "Usage: $N {start|stop|restart|force-reload}" >&2
> > > > >        exit 1
> > > > >        ;;
> > > > > esac
> > > > > exit 0
>
> > > > The script does not provide status, so when hasstatus is set to true,
> > > > puppet is querying service state via an invalid command:
> > > > /etc/init.d/zabbixstatus
>
> > > > This will always fail, which makes puppet think the service is always 
> > > > stopped.
>
> > > > I would look at:http://www.nowvox.com/contrib/zabbix/zabbix_agentd
>
> > > > Thank

Re: [Puppet Users] Facter ignores interfaces with non eth names

[Joe McDonagh]

On 10/04/2010 05:35 PM, Christopher Johnston wrote:
Does facter support NICs that are not named ethX? I happen to use 
custom names on my systems.  Just a quick look at the code I don't see 
why it wouldn't but the behavior I am seeing is very different. --
You received this message because you are subscribed to the Google 
Groups "Puppet Users" group.

To post to this group, send email to puppet-us...@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.
On OpenBSD NIC devices are named based on the driver they use, and in 
some cases the meta-type of the NIC (trunkX, carpX). Those all show up 
in facter on those machines.


--
Joe McDonagh
AIM: YoosingYoonickz
IRC: joe-mac on freenode
"When the going gets weird, the weird turn pro."

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] Override puppet environment at the command line

[Kenneth Holter]

Hi all.


My puppet client has "environment = envA" defined in
/etc/puppet/puppet.conf, but I'd like to override this manuall at the
command line: "puppetd --server puppet.master.com --environment=envB". This
doens't seem to work, so it always run code from envA. Is there a way to
override the environment variable like this?


Best regards,
Kenneth Holter

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: Question regarding the SERVICE type

[D.N. van der Meijden]

I hope I'm not spamming this group, but just trying to share
everything :-)

I tried using a new puppet client (v2.6.1), but same results:
...
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1286282327'
debug: Service[JADDA](provider=debian): Executing '/etc/init.d/
zabbix_agent status'
debug: Service[JADDA](provider=debian): Executing '/etc/init.d/
zabbix_agent start'
err: /Stage[main]//Service[JADDA]/ensure: change from stopped to
running failed: Could not start Service[JADDA]: Execution of '/etc/
init.d/zabbix_agent start' returned 1:  at /tmp/jadda.pp:6
debug: Finishing transaction 70131490329360
debug: Storing state
debug: Stored state in 0.01 seconds


Also tried the zabbix manifest file (http://projects.puppetlabs.com/
projects/1/wiki/Zabbix_Agent_Patterns), but this one fails as well

this is getting ridiculous, as all other daemons work perfectly...


On 5 okt, 13:22, "D.N. van der Meijden" 
wrote:
> By the way I tried the 'puppet' command to get some more info:
>
> client:/tmp# puppet -d -v jadda
> debug: file /sbin/chkconfig does not exist
> debug: file /usr/sbin/svcadm does not exist
> debug: file /sbin/rc-update does not exist
> debug: Creating default schedules
> debug: Service[zabbix_agent](provider=debian): Executing '/etc/init.d/
> zabbix_agent status'
> debug: Puppet::Type::Service::ProviderDebian: Executing '/usr/sbin/
> update-rc.d -n -f zabbix_agent remove'
> debug: //Service[zabbix_agent]: Changing ensure
> debug: //Service[zabbix_agent]: 1 change(s)
> debug: Service[zabbix_agent](provider=debian): Executing '/etc/init.d/
> zabbix_agent start'
> err: //Service[zabbix_agent]/ensure: change from stopped to running
> failed: Could not start Service[zabbix_agent]: Execution of '/etc/
> init.d/zabbix_agent start' returned 1:  at /tmp/jadda.pp:6
> debug: Finishing transaction 7018954900 with 1 changes
>
> client:/tmp# cat jadda.pp
>    service { "zabbix_agent":
>       name      => "zabbix_agent",
>       enable    => true,
>       ensure    => running,
>       hasstatus => true,
>    }
>
> On 5 okt, 13:11, "D.N. van der Meijden" 
> wrote:
>
>
>
> > Thanks for the extra info Nan.
> > I've changed the init script to support the status option, but to no
> > avail...
>
> > +  . /lib/lsb/init-functions
> > +
> > +  status)
> > +     status_of_proc -p $PID && exit 0 || exit $?
> > +     ;;
>
> > after this the status option works, but puppet still cannot start the
> > daemon...
> > as a workaround I can reboot the client (since the daemon does start
> > after a reboot because of the rc2.d symlink created by the mantifest
> > file), but this is not really an option...
>
> > The only thing I can think of right now is that the zabbix_agent
> > daemon needs to run as userzabbix, and puppet can't get it to run
> > that way (I know really far fetched, but I'm getting out of options
> > here..)
>
> > On 30 sep, 18:26, Nan Liu  wrote:
>
> > > On Thu, Sep 30, 2010 at 8:46 AM, D.N. van der Meijden
>
> > >  wrote:
> > > > Here's the init script:
>
> > > > (by the way, I changed the service to rsyslog [in thezabbixmanifest
> > > > file] and this works like a charm. So the service action works in
> > > > puppet...)
>
> > > > #! /bin/sh
> > > > PATH=/bin:/usr/bin:/sbin:/usr/sbin:/etc/zabbix:/etc/zabbix/bin:/etc/
> > > >zabbix/sbin
> > > > DAEMON=/etc/zabbix/sbin/zabbix_agentd
> > > > NAME=zabbix_agentd
> > > > DESC="Zabbixagent"
> > > > PID=/var/tmp/$NAME.pid
>
> > > > test -f $DAEMON || exit 0
> > > > set -e
> > > > case "$1" in
> > > >  start)
> > > >        echo "Starting $DESC: $NAME"
> > > >        start-stop-daemon --oknodo --start --pidfile $PID \
> > > >                --exec $DAEMON
> > > >        ;;
> > > >  stop)
> > > >        echo "Stopping $DESC: $NAME"
> > > >        start-stop-daemon --oknodo --stop  --pidfile $PID \
> > > >                --exec $DAEMON
> > > >        ;;
> > > >  restart|force-reload)
> > > >        $0 stop
> > > >        $0 start
> > > >        ;;
> > > >  *)
> > > >        N=/etc/init.d/$NAME
> > > >        echo "Usage: $N {start|stop|restart|force-reload}" >&2
> > > >        exit 1
> > > >        ;;
> > > > esac
> > > > exit 0
>
> > > The script does not provide status, so when hasstatus is set to true,
> > > puppet is querying service state via an invalid command:
> > > /etc/init.d/zabbixstatus
>
> > > This will always fail, which makes puppet think the service is always 
> > > stopped.
>
> > > I would look at:http://www.nowvox.com/contrib/zabbix/zabbix_agentd
>
> > > Thanks,
>
> > > Nan- Tekst uit oorspronkelijk bericht niet weergeven -
>
> > > - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit oorspronkelijk 
> > > bericht niet weergeven -
>
> > - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit oorspronkelijk 
> > bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email

[Puppet Users] Re: Question regarding the SERVICE type

[D.N. van der Meijden]

By the way I tried the 'puppet' command to get some more info:

client:/tmp# puppet -d -v jadda
debug: file /sbin/chkconfig does not exist
debug: file /usr/sbin/svcadm does not exist
debug: file /sbin/rc-update does not exist
debug: Creating default schedules
debug: Service[zabbix_agent](provider=debian): Executing '/etc/init.d/
zabbix_agent status'
debug: Puppet::Type::Service::ProviderDebian: Executing '/usr/sbin/
update-rc.d -n -f zabbix_agent remove'
debug: //Service[zabbix_agent]: Changing ensure
debug: //Service[zabbix_agent]: 1 change(s)
debug: Service[zabbix_agent](provider=debian): Executing '/etc/init.d/
zabbix_agent start'
err: //Service[zabbix_agent]/ensure: change from stopped to running
failed: Could not start Service[zabbix_agent]: Execution of '/etc/
init.d/zabbix_agent start' returned 1:  at /tmp/jadda.pp:6
debug: Finishing transaction 7018954900 with 1 changes

client:/tmp# cat jadda.pp
   service { "zabbix_agent":
  name  => "zabbix_agent",
  enable=> true,
  ensure=> running,
  hasstatus => true,
   }


On 5 okt, 13:11, "D.N. van der Meijden" 
wrote:
> Thanks for the extra info Nan.
> I've changed the init script to support the status option, but to no
> avail...
>
> +  . /lib/lsb/init-functions
> +
> +  status)
> +     status_of_proc -p $PID && exit 0 || exit $?
> +     ;;
>
> after this the status option works, but puppet still cannot start the
> daemon...
> as a workaround I can reboot the client (since the daemon does start
> after a reboot because of the rc2.d symlink created by the mantifest
> file), but this is not really an option...
>
> The only thing I can think of right now is that the zabbix_agent
> daemon needs to run as userzabbix, and puppet can't get it to run
> that way (I know really far fetched, but I'm getting out of options
> here..)
>
> On 30 sep, 18:26, Nan Liu  wrote:
>
>
>
> > On Thu, Sep 30, 2010 at 8:46 AM, D.N. van der Meijden
>
> >  wrote:
> > > Here's the init script:
>
> > > (by the way, I changed the service to rsyslog [in thezabbixmanifest
> > > file] and this works like a charm. So the service action works in
> > > puppet...)
>
> > > #! /bin/sh
> > > PATH=/bin:/usr/bin:/sbin:/usr/sbin:/etc/zabbix:/etc/zabbix/bin:/etc/
> > >zabbix/sbin
> > > DAEMON=/etc/zabbix/sbin/zabbix_agentd
> > > NAME=zabbix_agentd
> > > DESC="Zabbixagent"
> > > PID=/var/tmp/$NAME.pid
>
> > > test -f $DAEMON || exit 0
> > > set -e
> > > case "$1" in
> > >  start)
> > >        echo "Starting $DESC: $NAME"
> > >        start-stop-daemon --oknodo --start --pidfile $PID \
> > >                --exec $DAEMON
> > >        ;;
> > >  stop)
> > >        echo "Stopping $DESC: $NAME"
> > >        start-stop-daemon --oknodo --stop  --pidfile $PID \
> > >                --exec $DAEMON
> > >        ;;
> > >  restart|force-reload)
> > >        $0 stop
> > >        $0 start
> > >        ;;
> > >  *)
> > >        N=/etc/init.d/$NAME
> > >        echo "Usage: $N {start|stop|restart|force-reload}" >&2
> > >        exit 1
> > >        ;;
> > > esac
> > > exit 0
>
> > The script does not provide status, so when hasstatus is set to true,
> > puppet is querying service state via an invalid command:
> > /etc/init.d/zabbixstatus
>
> > This will always fail, which makes puppet think the service is always 
> > stopped.
>
> > I would look at:http://www.nowvox.com/contrib/zabbix/zabbix_agentd
>
> > Thanks,
>
> > Nan- Tekst uit oorspronkelijk bericht niet weergeven -
>
> > - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit oorspronkelijk 
> > bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: Augeas type to edit/append to /etc/pam.d/sshd

[luke.bigum]

Tim,

Thanks a lot, I never would have thought of trying to cludge Augeas
like that. Your specific insert line didn't work for my environment,
what did work was a slight variation:

"ins 100 after *[last()]"

I'll still try chase up the Augeas people to see if there is a more
elegant solution, but for now that works great and should translate to
all all Augeas lenses that present nodes as array indexes.

Thanks,

-Luke

On Oct 5, 11:43 am, Tim Sharpe  wrote:
> Hi Luke,
>
> I do something similar for a different module, give the following a try:
>
> augeas { "mod_mkhomedir_for_pam_sshd":
>     context => "/files/etc/pam.d/sshd",
>     changes => ["ins 100 before *",
>                     "set 100/type session",
>                     "set 100/control required",
>                     "set 100/module pam_mkhomedir.so",
>                     "set 100/argument umask=0022"],
>     onlyif => "match
> *[type='session'][module='pam_mkhomedir.so'][argument='umask=0022']
> size == 0"
>
> }
>
> Cheers,
> Tim
>
> On 5 October 2010 03:00, luke.bigum  wrote:
>
> > Hi all,
>
> > I'm trying to do something that should be pretty simple but can't
> > figure it out.
>
> > I want to append a line to /etc/pam.d/sshd if a line with a certain
> > module doesn't exist.
>
> > What I would like to work is this:
>
> >  augeas { sshd_pam_mkhomedir:
> >    context => "/files/etc/pam.d/sshd",
> >    changes => [
> >      "set *[module = 'pam_mkhomedir.so']/type session",
> >      "set *[module = 'pam_mkhomedir.so']/control required",
> >      "set *[module = 'pam_mkhomedir.so']/module pam_mkhomedir.so",
> >      "set *[module = 'pam_mkhomedir.so']/argument[1] umask=0022",
> >    ],
> > }
>
> > That "*[module = foo]" fails to match and create a new line, even in
> > augtool. This doesn't work either:
>
> > augtool> set /files/etc/pam.d/sshd/*[last()+1]/type session
> > Failed
>
> > Nor can I get an insert to work, as to do that I'd need to know the
> > number of entries that already exist in the file in order to create
> > the next one.
>
> > If no one's already got a solution to this I'll have to ask on augeas-
> > devel.
>
> > Thanks,
>
> > -Luke
>
> > --
> > You received this message because you are subscribed to the Google Groups 
> > "Puppet Users" group.
> > To post to this group, send email to puppet-us...@googlegroups.com.
> > To unsubscribe from this group, send email to 
> > puppet-users+unsubscr...@googlegroups.com.
> > For more options, visit this group 
> > athttp://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-us...@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: Question regarding the SERVICE type

[D.N. van der Meijden]

Thanks for the extra info Nan.
I've changed the init script to support the status option, but to no
avail...

+  . /lib/lsb/init-functions
+
+  status)
+ status_of_proc -p $PID && exit 0 || exit $?
+ ;;

after this the status option works, but puppet still cannot start the
daemon...
as a workaround I can reboot the client (since the daemon does start
after a reboot because of the rc2.d symlink created by the mantifest
file), but this is not really an option...

The only thing I can think of right now is that the zabbix_agent
daemon needs to run as user zabbix, and puppet can't get it to run
that way (I know really far fetched, but I'm getting out of options
here..)


On 30 sep, 18:26, Nan Liu  wrote:
> On Thu, Sep 30, 2010 at 8:46 AM, D.N. van der Meijden
>
>
>
>
>
>  wrote:
> > Here's the init script:
>
> > (by the way, I changed the service to rsyslog [in thezabbixmanifest
> > file] and this works like a charm. So the service action works in
> > puppet...)
>
> > #! /bin/sh
> > PATH=/bin:/usr/bin:/sbin:/usr/sbin:/etc/zabbix:/etc/zabbix/bin:/etc/
> >zabbix/sbin
> > DAEMON=/etc/zabbix/sbin/zabbix_agentd
> > NAME=zabbix_agentd
> > DESC="Zabbixagent"
> > PID=/var/tmp/$NAME.pid
>
> > test -f $DAEMON || exit 0
> > set -e
> > case "$1" in
> >  start)
> >        echo "Starting $DESC: $NAME"
> >        start-stop-daemon --oknodo --start --pidfile $PID \
> >                --exec $DAEMON
> >        ;;
> >  stop)
> >        echo "Stopping $DESC: $NAME"
> >        start-stop-daemon --oknodo --stop  --pidfile $PID \
> >                --exec $DAEMON
> >        ;;
> >  restart|force-reload)
> >        $0 stop
> >        $0 start
> >        ;;
> >  *)
> >        N=/etc/init.d/$NAME
> >        echo "Usage: $N {start|stop|restart|force-reload}" >&2
> >        exit 1
> >        ;;
> > esac
> > exit 0
>
> The script does not provide status, so when hasstatus is set to true,
> puppet is querying service state via an invalid command:
> /etc/init.d/zabbixstatus
>
> This will always fail, which makes puppet think the service is always stopped.
>
> I would look at:http://www.nowvox.com/contrib/zabbix/zabbix_agentd
>
> Thanks,
>
> Nan- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] obtaining stdout information from client configuration executions

[Ohad Levy]

On Tue, Oct 5, 2010 at 12:23 PM, Tim Lank  wrote:

> Thanks Daniel.  I appreciate your commentary.
>
> The main difference it would appear from this and tagmail is that
> tagmail constantly sends numerous emails.  This script is run
> on-demand or out of cron and harvests the stdout of all the last run
> reports into one summary email/report.  One email when you want it and
> how you want it vs. hundreds or thousands every hour.  I agree, this
> would be way too much noise and why I didn't like the idea of tagmail.
>  I only want a summary once in a while, not a constant flow of them.
>
>
just my two cents - this is why Foreman daily (or what ever interval) emails
exists - they provide a summary of all puppet activities (with links to see
more of course).

another benefit is to see which hosts are not reporting...

Ohad

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

[Puppet Users] Puppet truth, nil and templates

[Bruce Richardson]

Does Puppet have any genuine concept of truth and nil that survives the
interface with Ruby?  has_variable? only returns false if a variable has
never been assigned a value at all in the enclosing scope; there is no
way to assign undef to a regular variable (as opposed to a resource
parameter) within a scope and so make it undefined for the template.

It would be a very useful thing to be able to do; makes for much cleaner
code.  Have I missed something?

-- 
Bruce

I object to intellect without discipline.  I object to power without
constructive purpose. -- Spock

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Augeas type to edit/append to /etc/pam.d/sshd

[Tim Sharpe]

Hi Luke,

I do something similar for a different module, give the following a try:

augeas { "mod_mkhomedir_for_pam_sshd":
context => "/files/etc/pam.d/sshd",
changes => ["ins 100 before *",
"set 100/type session",
"set 100/control required",
"set 100/module pam_mkhomedir.so",
"set 100/argument umask=0022"],
onlyif => "match
*[type='session'][module='pam_mkhomedir.so'][argument='umask=0022']
size == 0"
}

Cheers,
Tim

On 5 October 2010 03:00, luke.bigum  wrote:
> Hi all,
>
> I'm trying to do something that should be pretty simple but can't
> figure it out.
>
> I want to append a line to /etc/pam.d/sshd if a line with a certain
> module doesn't exist.
>
> What I would like to work is this:
>
>  augeas { sshd_pam_mkhomedir:
>    context => "/files/etc/pam.d/sshd",
>    changes => [
>      "set *[module = 'pam_mkhomedir.so']/type session",
>      "set *[module = 'pam_mkhomedir.so']/control required",
>      "set *[module = 'pam_mkhomedir.so']/module pam_mkhomedir.so",
>      "set *[module = 'pam_mkhomedir.so']/argument[1] umask=0022",
>    ],
> }
>
> That "*[module = foo]" fails to match and create a new line, even in
> augtool. This doesn't work either:
>
> augtool> set /files/etc/pam.d/sshd/*[last()+1]/type session
> Failed
>
> Nor can I get an insert to work, as to do that I'd need to know the
> number of entries that already exist in the file in order to create
> the next one.
>
> If no one's already got a solution to this I'll have to ask on augeas-
> devel.
>
> Thanks,
>
> -Luke
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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: Augeas type to edit/append to /etc/pam.d/sshd

[luke.bigum]

Hi Rob,

Thanks for the suggestion but it seems to make no difference. Even
that set command in augtool doesn't work, you get a very helpful
"failed" message and no recorded error I can find. I hoped someone had
come across this before and had an Augeas solution (would be so easy
to use an exec type to do it). I'll try ask the Augeas community and
come back with what they say.

On Oct 4, 7:31 pm, Rob McBroom  wrote:
> On Oct 4, 2010, at 12:00 PM, luke.bigum wrote:
>
> >    changes => [
> >      "set *[module = 'pam_mkhomedir.so']/type session",
> >      "set *[module = 'pam_mkhomedir.so']/control required",
> >      "set *[module = 'pam_mkhomedir.so']/module pam_mkhomedir.so",
> >      "set *[module = 'pam_mkhomedir.so']/argument[1] umask=0022",
> >    ],
>
> Have you tried re-arranging these so the value for module is the first one 
> set? I think you have to do it that way so the other three 'set' statements 
> can find the path.
>
> --
> 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-us...@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] obtaining stdout information from client configuration executions

[Tim Lank]

Thanks Daniel.  I appreciate your commentary.

The main difference it would appear from this and tagmail is that
tagmail constantly sends numerous emails.  This script is run
on-demand or out of cron and harvests the stdout of all the last run
reports into one summary email/report.  One email when you want it and
how you want it vs. hundreds or thousands every hour.  I agree, this
would be way too much noise and why I didn't like the idea of tagmail.
 I only want a summary once in a while, not a constant flow of them.


On Mon, Oct 4, 2010 at 9:32 PM, Daniel Pittman  wrote:
> Tim Lank  writes:
>
>> I've developed a simple mini-script system that can be setup on a
>> puppetmaster to send the stdout of the last reports for each client to a set
>> of email addresses.  I find it convenient to get these results in my inbox
>> so that I can view them at a glance, review at leisure, forward on, cut &
>> paste elsewhere, etc...
>
> Isn't this what the tagmail system does?
>
> http://docs.puppetlabs.com/references/stable/report.html
>
>> recommendations, suggestions, comments welcome.
>
> The main comment is a general sysadmin one: make sure you only generate noise
> when something goes wrong, not when it goes right.  Otherwise puppet will
> rapidly overwhelm you with reports and you will never notice the problems. :)
>
> Regards,
>        Daniel
> --
> ✣ Daniel Pittman            ✉ dan...@rimspace.net            ☎ +61 401 155 707
>               ♽ made with 100 percent post-consumer electrons
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] Puppetd attempting to install packages that aren't required

[Peter Meier]

For some reason, puppet is attempting to install ruby-enterprise on
all my puppet clients. The only reason I can find for this behaviour
is that I've defined a package to install ruby-enterprise. However, by
default, the package isn't called by anything.
In order to get the package to only install on the systems that I
wanted to have it, I had to move it from a general package definition
to be inside a class. Is this normal behaviour?


Yes.

I would recommend you to have a look at modules and how you can  
organize your manifests with classes and modules to group code  
together and include it to the appropriate nodes.


~pete

--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To post to this group, send email to puppet-us...@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] Puppetd attempting to install packages that aren't required

[ncantor]

For some reason, puppet is attempting to install ruby-enterprise on
all my puppet clients. The only reason I can find for this behaviour
is that I've defined a package to install ruby-enterprise. However, by
default, the package isn't called by anything.
In order to get the package to only install on the systems that I
wanted to have it, I had to move it from a general package definition
to be inside a class. Is this normal behaviour?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.