[Puppet Users] Re: ANNOUNCE: Puppet 2.6.2 - Release Candidate 1 available!

[James Turnbull]

James Turnbull wrote:
> * User type now manages password age
> 
> We’ve add a new feature to user providers manages_password_age, along
> with the new properties password_min_age and password_max_age to the
> user type. These represent password minimum and maximum age in days.
> The useradd and user_role_add providers now support these new properties.
> 
> * User type now manages user expiry
> 
> We’ve add a new feature to user providers, manages_expiry along with a
> new property, expiry. The expiry property is specified in the form of
> -MM-DD and sets an expiration date for an account
> 

Sorry - I probably should have provided examples of all these new
properties:

user { "james":
  password_min_age => '10',
  password_max_age => '30',
  expiry => '2010-09-30',
  ...
  ensure => present,
}

Regards

James Turnbull

-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571

-- 
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] ANNOUNCE: Puppet 2.6.2 - Release Candidate 1 available!

[James Turnbull]

And we're back with another exiting release in the 2.6.x branch - 2.6.2.

The first release candidate is now available.

2.6.2 is a maintenance release in the 2.6.x branch and it contains bug
fixes, maintenance and a small number of features (see Release Notes below).

We've include release notes below that you can also see at:

http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes

The release candidate is available for download at:

http://puppetlabs.com/downloads/puppet/puppet-2.6.2rc1.tar.gz

Please note that all final releases of Puppet are signed with the
Puppet Labs key.

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

Please test this release candidate and report feedback via the
Puppet Labs Redmine site:

http://projects.puppetlabs.com

Please select an affected version of 2.6.2rc1.

RELEASE NOTES

* User type now manages password age

We’ve add a new feature to user providers manages_password_age, along
with the new properties password_min_age and password_max_age to the
user type. These represent password minimum a nd maximum age in days.
The useradd and user_role_add providers now support these new properties.

* User type now manages user expiry

We’ve add a new feature to user providers, manages_expiry along with a
new property, expiry. The expiry property is specified in the form of
-MM-DD and sets an expiration date for an account

CHANGELOG since 2.6.1

1b6094d  Fixed documentation typo
bdf12fe  Fix for #4896 -- stray newline left over from removed diagnostic
e7424c6  (#4772) Update SuSE .spec file
0aaa742  Fixes #4792 (Duplicate definition since 2.6.1 upgrade)
ea49d13  Improvement to #4025: made spec tests work on all platforms
0b4ce08  Adds #3046 - support for password min/max age
e9f9d26  [#4783] (#4783) Fix RRDGraph report generation
34f87cf  Add user account expiry to the useradd type and provider
a7fb9b1  Fixed #4025 (failure in launchd if certain plists are binary).
2573872  Fix for #4649 -- avoid unsupported features on non-posix systems
eb9279c  Fix for 4273 -- revert b7e2580ab49ecdb67fc9b522829c005fc3750fbe
53a2bea  Fix for #4804 -- escaped backslashes in interpolated strings
d12e477  Fixes #4863 (Missing "require 'webrick'" causes
nondeterministic spec failures)
574812e  (#4860) Add regression tests that would have caught bad params
method
68947e7  (#4860) Fix wrong method name.. params seems to be renamed to
parameters
021359b  Fix for #4644: install.rb works properly on Windows
d057b90  Fix #4726 Update puppet rrdtool metric code to support modern
rrd ruby bindings
66cf3a9  Fix #4226 - Prepend 'Puppet CA: ' to fqdn for default root ca_name
d54352a  Port Puppet::SSLCertificates::CA test to rspec
effc6b8  Fixes #4852 - error messages involving Whits now mention
Classes instead
3f99bd7  Fix #4267 - Create a backup before dropping permissions
6468f4e  (#4763) Don't call a method that was removed in Rails 3
activerecord
79d5fde  Fixed #4763 - Hardcoded ActiveRecord version
4798df3  Fixes #4822 -- Puppet doc -o option broken
99c1019  [#4798] Puppet doc manifests documentation mode broken
8cd1540  [#4692] undefined variables cause :undef to be passed to functions
06bf566  [#4787] Missing require causing failure
bba04e0  Fix for #4746 -- Newline goes at the _end_ of the line
9e17c25  Fix #4743: Allow the audit meta-parameter to accept both 'all',
and :all
f950061  [#4716] ResourceTypeAPI exposes implementation details that are
likely to change
8ff4b9a  Fixed #4819 - corrected cron documentation
2b50f30  [#4771] Import of manifests with the same name only happens once
7b8cb74  Fix for #4708 - tagmail should allow . in tagname
6f229ee  Minimal fix for #4631 -- set implicit classes as in 0.25.x
021d534  Fixed #3707 - rpm, like dpkg-query exits 1 if the package is
not installed.  Returning nil in this provider had the effect that on
every run, puppet would end up calling yum erase .  Returning the
correct data structure resolves this.
216f663  Fixed Puppet Doc TOC generation
c3cb57c  Fixed versioncmp function typo
898a170  Fixed Reductive references in LICENSE file
996f14e  Documentation updates for Markdown conversion

Regards

James Turnbull
-- 
Puppet Labs - http://www.puppetlabs.com
C: 503-734-8571

-- 
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] mount type attempting remount when ensure => present

[John Warburton]

http://projects.puppetlabs.com/issues/4904

Can Felix & Rob update the ticket with your use cases and requests?

Thanks

John

On 1 October 2010 09:01, John Warburton  wrote:

> I'll file a bug
>
>
> On 1 October 2010 05:01, Nigel Kersten  wrote:
>
>> On Thu, Sep 30, 2010 at 11:13 AM, Rob McBroom 
>> wrote:
>> > On Sep 30, 2010, at 12:37 PM, Nigel Kersten wrote:
>> >
>> >>> I noticed similar behaviour in Linux, with catastrophic results.
>> >>> Ensure => present apparently always means "in fstab, but not mounted",
>> >>> which not only doesn't make much sense to me, but led me to never use
>> >>> any ensure setting besides "mounted".
>> >>
>> >> Anyone bug reported this yet?
>> >
>> > According to the documentation, that's how `ensure => present` is
>> supposed to work, though I can't imagine the use case for “put it in fstab
>> but make sure it's never mounted”. I would love it if that behavior were
>> changed to just “put it in fstab”. Then I could actually use it. :)
>>
>> It's perfectly reasonable to bug report something you think is broken,
>> even if it is consistent with provided documentation :)
>>
>> --
>>
>


-- 
John Warburton
Ph: 0417 299 600
Email: jwarbur...@gmail.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] puppet-dashboard - where do I put the .htaccess file?

[Tim Lank]

This is not working (no username/password prompt when directing my
browser to the site).   How do I troubleshoot this (where are the
access logs, etc...?)

On Thu, Sep 30, 2010 at 2:00 PM, Igal Koshevoy  wrote:
> On Thu, Sep 30, 2010 at 3:58 AM, Tim Lank  wrote:
>> puppet-users:
>>
>> I've got puppet-dashboard 1.0.3-3 setup using the rpm from here:
>> http://yum.puppetlabs.com/base/
>>
>> Everything seems to work fine using the instructions from here:
>> http://github.com/reductivelabs/puppet-dashboard
>>
>> I'm trying to setup basic security with the .htaccess file described
>> in the Security section - item#3.
>>
>> Where exactly do I need to put this?
>>
>> Thanks in advance for your help.
>
> You can create a "/usr/share/puppet-dashboard/public/.htaccess" file
> with contents similar to this:
>
>    AuthName "Puppet Dashboard"
>    AuthType Basic
>    AuthUserFile  /usr/share/puppet-dashboard/config/htpasswd
>    Require valid-user
>
> ,,.and then create the AuthUserFile specified above using `htpasswd`
> (run `htpasswd -h` for help).
>
> I've created issue #4890 to add some more documentation on this topic.
>
> -igal
>
> --
> 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] Cron Error Notification

[Daniel Pittman]

Felix Frank  writes:
> On 09/30/2010 02:36 PM, Jeff wrote:
>
>> I'd love to use puppet as a tool to manage cron jobs across the
>> enterprise. Ideally, I'd like to chuck our expensive enterprise scheduling
>> package.

Yeah, that isn't going to happen, unless you use essentially zero of the
features of that package.  (OTOH, I would recommend SGE[1], Torque, PBS, or
Condor as suitable non-big-dollars packages :)

>> To do that, I need to get job failure notifications to the network
>> operations center. Can someone suggest a way I can accomplish that?

You would have to write your own code to do that: puppet will create cron
records, but then cron runs them entirely outside the control of puppet.

Which means that unless cron does this for you (which it doesn't) you don't
get a darn thing of value from puppet other than sending the job.

> what's your specific problem with that? Cron generates mail with stdout
> content automatically. Puppet can control target addresses without problems.
>
> Sorry for the noise if your problem is more obvious than I realize.

I suspect it is only clear if you have used "enterprise scheduling" style
software, which does a whole lot of stuff to monitor and manage jobs. :)

Daniel

Footnotes: 
[1]  Presumably OGE now that Oracle own Sun and all. :)

-- 
✣ 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.

Re: [Puppet Users] mount type attempting remount when ensure => present

[John Warburton]

I'll file a bug

On 1 October 2010 05:01, Nigel Kersten  wrote:

> On Thu, Sep 30, 2010 at 11:13 AM, Rob McBroom 
> wrote:
> > On Sep 30, 2010, at 12:37 PM, Nigel Kersten wrote:
> >
> >>> I noticed similar behaviour in Linux, with catastrophic results.
> >>> Ensure => present apparently always means "in fstab, but not mounted",
> >>> which not only doesn't make much sense to me, but led me to never use
> >>> any ensure setting besides "mounted".
> >>
> >> Anyone bug reported this yet?
> >
> > According to the documentation, that's how `ensure => present` is
> supposed to work, though I can't imagine the use case for “put it in fstab
> but make sure it's never mounted”. I would love it if that behavior were
> changed to just “put it in fstab”. Then I could actually use it. :)
>
> It's perfectly reasonable to bug report something you think is broken,
> even if it is consistent with provided documentation :)
>
> --
> 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.
>
>


-- 
John Warburton
Ph: 0417 299 600
Email: jwarbur...@gmail.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] Nagios Module and use of the @@ and <<||>> notation

[Avi Miller]

Greg Haase wrote:

Are you aware of any documentation that clearly explains how this
collect/export functionality works?


Exporting and collecting resources relies on stored configuration[1] 
being enabled on your Puppet Master. You should ensure that the database 
is configured and working before trying to export and collect resources.


Cheers,
Avi

[1] 
http://projects.puppetlabs.com/projects/1/wiki/Using_Stored_Configuration


--
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] Nagios Module and use of the @@ and <<||>> notation

[Greg Haase]

Stephen, 

Ah the David Schmitt nagios module. This is what I based my work on. I used
it as a model. 

Are you aware of any documentation that clearly explains how this
collect/export functionality works?

Greg

On 9/30/10 3:31 PM, "Steven Wagner"  wrote:

> Hi Greg,
> 
> I'm on my phone at the moment so I don't have the exact link handy, but there
> is a module on GitHub that works.  I tinkered with it a lot in my old setup
> but found most of my problems were due to not really understanding how the
> collect/export functionality worked.
> 
> This is my favorite feature of Puppet.  When I got it working, I teared up a
> bit.  :)
> 
> I believe it's http://github.com/DavidS/puppet-nagios
> 
> 
> (mobile edition)
> 
> On Sep 30, 2010, at 3:04 PM, Greg Haase  wrote:
> 
>> Greetings, 
>> 
>> I am working on getting Nagios implemented with Puppet so that when I add a
>> node to Puppet a Nagios configuration file is generated.
>> 
>> I can get nagios installed and configured on the server and the client with
>> no problems.  Yet getting the client configuration file on to the server is
>> not happening. I did have it working at one point in time yet It seems that
>> I cannot get back to that configuration.
>> 
>> I am relying on notation using the @@ and <<||>> I found somewhere in the
>> documentation yet I did not find a proper discussion of exactly how it
>> works.  I don't feel that I have a proper understanding of how it works.
>> 
>> What I understand is that by using the
>> 
>> @@name {}
>> 
>> I can load data into a "global object" that is accessible from any puppet
>> member. Who uses the
>> 
>> name <<||>> 
>> 
>> Notation to call the data stored in that global object.
>> 
>> I believe that in the past I was able to view this information on my puppet
>> server with 
>> 
>> ralsh nagios_host
>> 
>> It would give me a listing of what was stored in nagios_host.  Now when I do
>> this I see nothing.
>> 
>> Here is a listing of what I understand as being a way to use this:
>> 
>> Is this correct?
>> 
>> 
>> -
>> class nagios-server{
>>    A bunch of other stuff ..
>>file { "/etc/nagios/":
>>ensure => 'directory',
>>mode => 755,
>>owner  => nagios,
>>group  => nagios,
>>recurse => true;
>>}
>> Nagios_host  <<|target == "/etc/nagios/nagios_hosts.${fqdn}.cfg"|>>
>> }
>> -
>> class nagios-client {
>>@@nagios_host { $fqdn:
>>target => "/etc/nagios/nagios_hosts.${fqdn}.cfg",
>>ensure => present,
>>alias => $hostname,
>>address => $ipaddress,
>>use => "my-servers",
>>check_command => "check-host-alive",
>>max_check_attempts => 3,
>>hostgroups => "my-servers",
>>contact_groups => "admins",
>>}
>> A bunch of other stuff ..
>> }
>> -
>> 
>> Could someone please point me in the right direction to some documentation
>> that could help clarify this  the use of the @@ and <<||>>?
>> 
>> 
>> I'd greatly appreciate it.
>> 
>> Thanks
>> 
>> Greg
>> Greg Haase
>> gha...@syntheticgenomics.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.
>> 

-- 
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] Nagios Module and use of the @@ and <<||>> notation

[Steven Wagner]

Hi Greg,

I'm on my phone at the moment so I don't have the exact link handy, but there 
is a module on GitHub that works.  I tinkered with it a lot in my old setup but 
found most of my problems were due to not really understanding how the 
collect/export functionality worked.

This is my favorite feature of Puppet.  When I got it working, I teared up a 
bit.  :)

I believe it's http://github.com/DavidS/puppet-nagios


(mobile edition)

On Sep 30, 2010, at 3:04 PM, Greg Haase  wrote:

> Greetings, 
> 
> I am working on getting Nagios implemented with Puppet so that when I add a
> node to Puppet a Nagios configuration file is generated.
> 
> I can get nagios installed and configured on the server and the client with
> no problems.  Yet getting the client configuration file on to the server is
> not happening. I did have it working at one point in time yet It seems that
> I cannot get back to that configuration.
> 
> I am relying on notation using the @@ and <<||>> I found somewhere in the
> documentation yet I did not find a proper discussion of exactly how it
> works.  I don't feel that I have a proper understanding of how it works.
> 
> What I understand is that by using the
> 
> @@name {}
> 
> I can load data into a "global object" that is accessible from any puppet
> member. Who uses the
> 
> name <<||>> 
> 
> Notation to call the data stored in that global object.
> 
> I believe that in the past I was able to view this information on my puppet
> server with 
> 
> ralsh nagios_host
> 
> It would give me a listing of what was stored in nagios_host.  Now when I do
> this I see nothing.
> 
> Here is a listing of what I understand as being a way to use this:
> 
> Is this correct? 
> 
> 
> -
> class nagios-server{
>    A bunch of other stuff ..
>file { "/etc/nagios/":
>ensure => 'directory',
>mode => 755,
>owner  => nagios,
>group  => nagios,
>recurse => true;
>}
> Nagios_host  <<|target == "/etc/nagios/nagios_hosts.${fqdn}.cfg"|>>
> }
> -
> class nagios-client {
>@@nagios_host { $fqdn:
>target => "/etc/nagios/nagios_hosts.${fqdn}.cfg",
>ensure => present,
>alias => $hostname,
>address => $ipaddress,
>use => "my-servers",
>check_command => "check-host-alive",
>max_check_attempts => 3,
>hostgroups => "my-servers",
>contact_groups => "admins",
>}
> A bunch of other stuff ..
> }
> -
> 
> Could someone please point me in the right direction to some documentation
> that could help clarify this  the use of the @@ and <<||>>?
> 
> 
> I'd greatly appreciate it.
> 
> Thanks
> 
> Greg
> Greg Haase
> gha...@syntheticgenomics.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.
> 

-- 
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] Nagios Module and use of the @@ and <<||>> notation

[Greg Haase]

Greetings, 

I am working on getting Nagios implemented with Puppet so that when I add a
node to Puppet a Nagios configuration file is generated.

I can get nagios installed and configured on the server and the client with
no problems.  Yet getting the client configuration file on to the server is
not happening. I did have it working at one point in time yet It seems that
I cannot get back to that configuration.

I am relying on notation using the @@ and <<||>> I found somewhere in the
documentation yet I did not find a proper discussion of exactly how it
works.  I don't feel that I have a proper understanding of how it works.

What I understand is that by using the

@@name {}

I can load data into a "global object" that is accessible from any puppet
member. Who uses the

name <<||>> 

Notation to call the data stored in that global object.

I believe that in the past I was able to view this information on my puppet
server with 

ralsh nagios_host

It would give me a listing of what was stored in nagios_host.  Now when I do
this I see nothing.

Here is a listing of what I understand as being a way to use this:
 
Is this correct? 


-
class nagios-server{
    A bunch of other stuff ..
file { "/etc/nagios/":
ensure => 'directory',
mode => 755,
owner  => nagios,
group  => nagios,
recurse => true;
}
Nagios_host  <<|target == "/etc/nagios/nagios_hosts.${fqdn}.cfg"|>>
}
-
class nagios-client {
@@nagios_host { $fqdn:
target => "/etc/nagios/nagios_hosts.${fqdn}.cfg",
ensure => present,
alias => $hostname,
address => $ipaddress,
use => "my-servers",
check_command => "check-host-alive",
max_check_attempts => 3,
hostgroups => "my-servers",
contact_groups => "admins",
}
 A bunch of other stuff ..
}
-

Could someone please point me in the right direction to some documentation
that could help clarify this  the use of the @@ and <<||>>?


I'd greatly appreciate it.

Thanks

Greg
Greg Haase
gha...@syntheticgenomics.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] mount type attempting remount when ensure => present

[Nigel Kersten]

On Thu, Sep 30, 2010 at 11:13 AM, Rob McBroom  wrote:
> On Sep 30, 2010, at 12:37 PM, Nigel Kersten wrote:
>
>>> I noticed similar behaviour in Linux, with catastrophic results.
>>> Ensure => present apparently always means "in fstab, but not mounted",
>>> which not only doesn't make much sense to me, but led me to never use
>>> any ensure setting besides "mounted".
>>
>> Anyone bug reported this yet?
>
> According to the documentation, that's how `ensure => present` is supposed to 
> work, though I can't imagine the use case for “put it in fstab but make sure 
> it's never mounted”. I would love it if that behavior were changed to just 
> “put it in fstab”. Then I could actually use it. :)

It's perfectly reasonable to bug report something you think is broken,
even if it is consistent with provided documentation :)

-- 
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] mount type attempting remount when ensure => present

[Rob McBroom]

On Sep 30, 2010, at 12:37 PM, Nigel Kersten wrote:

>> I noticed similar behaviour in Linux, with catastrophic results.
>> Ensure => present apparently always means "in fstab, but not mounted",
>> which not only doesn't make much sense to me, but led me to never use
>> any ensure setting besides "mounted".
> 
> Anyone bug reported this yet?

According to the documentation, that's how `ensure => present` is supposed to 
work, though I can't imagine the use case for “put it in fstab but make sure 
it's never mounted”. I would love it if that behavior were changed to just “put 
it in fstab”. Then I could actually use it. :)

-- 
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] puppet-dashboard - where do I put the .htaccess file?

[Igal Koshevoy]

On Thu, Sep 30, 2010 at 3:58 AM, Tim Lank  wrote:
> puppet-users:
>
> I've got puppet-dashboard 1.0.3-3 setup using the rpm from here:
> http://yum.puppetlabs.com/base/
>
> Everything seems to work fine using the instructions from here:
> http://github.com/reductivelabs/puppet-dashboard
>
> I'm trying to setup basic security with the .htaccess file described
> in the Security section - item#3.
>
> Where exactly do I need to put this?
>
> Thanks in advance for your help.

You can create a "/usr/share/puppet-dashboard/public/.htaccess" file
with contents similar to this:

AuthName "Puppet Dashboard"
AuthType Basic
AuthUserFile  /usr/share/puppet-dashboard/config/htpasswd
Require valid-user

,,.and then create the AuthUserFile specified above using `htpasswd`
(run `htpasswd -h` for help).

I've created issue #4890 to add some more documentation on this topic.

-igal

-- 
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] puppet-dashboard - where do I put the .htaccess file?

[Jacob Helwig]

On Thu, 30 Sep 2010 03:58:29 -0700, Tim Lank wrote:
> 
> puppet-users:
> 
> I've got puppet-dashboard 1.0.3-3 setup using the rpm from here:
> http://yum.puppetlabs.com/base/
> 
> Everything seems to work fine using the instructions from here:
> http://github.com/reductivelabs/puppet-dashboard
> 
> I'm trying to setup basic security with the .htaccess file described
> in the Security section - item#3.
> 
> Where exactly do I need to put this?
> 
> Thanks in advance for your help.
> 

That could be made a little clearer in the README.markdown.  Since
you've installed using the RPM, you should be able to put the .htaccess
in /usr/share/puppet-dashboard/public/.

-- 
Jacob Helwig


signature.asc
Description: Digital signature

Re: [Puppet Users] mount type attempting remount when ensure => present

[Nigel Kersten]

On Thu, Sep 30, 2010 at 1:31 AM, Felix Frank
 wrote:
> On 09/30/2010 08:57 AM, John Warburton wrote:
>> Hi All
>>
>> I am not sure if I am doing this right, or just meeting some Solaris
>> specific thing that hasn't been catered for.
>>
>> Solaris 10, with puppet 0.25.5, and trying to manage /tmp. Note that /tmp
>> can't be remounted on a live system (
>> http://wikis.sun.com/display/BigAdmin/Talking+about+RAM+disks+in+the+Solaris+OS
>> )
>>
>>     mount{ "/tmp":
>>         atboot  => "yes",
>>         device  => "swap",
>>         ensure  => present,
>>         pass    => "-",
>>         fstype  => "tmpfs",
>>         options => "size=4096m",
>>     }
>>
>> Changes /etc/vfstab as expected, but yields this error:
>>
>> err: //solaris/Mount[/tmp]/ensure: change from mounted to present failed:
>> Execution of '/usr/sbin/umount /tmp' returned 1: umount: /tmp busy
>>
>> notice: //solaris/Mount[/tmp]: Refreshing self
>> info: Mount[/tmp](provider=parsed): Remounting
>> err: //solaris/Mount[/tmp]: Failed to call refresh on Mount[/tmp]: Execution
>> of '/usr/sbin/umount /tmp' returned 1: umount: /tmp busy
>>
>> Seems that ensure => present (Set to present to add to fstab but not change
>> mount/unmount status) is being overridden by the fact the provider is deemed
>> refreshable.
>
> I noticed similar behaviour in Linux, with catastrophic results.
> Ensure => present apparently always means "in fstab, but not mounted",
> which not only doesn't make much sense to me, but led me to never use
> any ensure setting besides "mounted".

Anyone bug reported this yet?

-- 
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: Question regarding the SERVICE type

[Nan Liu]

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 the zabbix manifest
> 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="Zabbix agent"
> 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/zabbix status

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

-- 
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] certificate problem ; puppetca can't find cert request ?

[Nan Liu]

On Thu, Sep 30, 2010 at 6:20 AM, Daniel Maher  wrote:
> I removed /var/lib/puppet/ssl/certs/.pem , then ran
> puppetd with --waitforcert .  Unfortunately, when i run a
> puppetca --list --all ,  is not listed, even though there
> is very clearly a request pem in /var/lib/puppet/ssl/certificate_requests .

So first bbackup you ssl dir, then try the following command:

puppetca --clean 
puppetca --generate  --certdnsname="puppet;puppetmaster"

In certdnsname, provide a list of DNS cname to puppet master, and
include puppet for convenience.

> Executing puppetca --clean  removes the private key (as
> expected), but does not change the error condition.  I also tried puppetca
> --revoke  ; no change.

This will add a few more wrinkles, once the certificate is generated,
it will list as revoked:
# puppet cert --list --all
- 
(D7:B1:1B:33:80:51:2C:11:24:C5:EF:CE:92:04:4A:24) (certificate
revoked)

If you have a backup of the certificate revocation list restore it. I
don't know the command to undo a single revoke off hand.

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-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]

Here's the init script:

(by the way, I changed the service to rsyslog [in the zabbix manifest
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="Zabbix agent"
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


On 30 sep, 17:24, Nigel Kersten  wrote:
> Can you post the init script?
>
> Is it possible it's a PATH problem inside the script? Something that
> works under your environment, but not under the user puppet is running
> as?
>
> On Thu, Sep 30, 2010 at 8:16 AM, D.N. van der Meijden
>
>
>
>  wrote:
> > My bad!! I understand the puppet command now...
>
> > client:/tmp# puppet --verbose --debug --trace test.pp
> > 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'
> > /usr/lib/ruby/1.8/puppet/util/errors.rb:51:in `fail'
> > /usr/lib/ruby/1.8/puppet/provider/service/base.rb:122:in `texecute'
> > /usr/lib/ruby/1.8/puppet/provider/service/base.rb:134:in `ucommand'
> > /usr/lib/ruby/1.8/puppet/provider/service/base.rb:78:in `start'
> > /usr/lib/ruby/1.8/puppet/type/service.rb:61:in `set_running'
> > /usr/lib/ruby/1.8/puppet/property.rb:163:in `send'
> > /usr/lib/ruby/1.8/puppet/property.rb:163:in `call_valuemethod'
> > /usr/lib/ruby/1.8/puppet/property.rb:349:in `set'
> > /usr/lib/ruby/1.8/puppet/property.rb:421:in `sync'
> > /usr/lib/ruby/1.8/puppet/type/service.rb:72:in `sync'
> > /usr/lib/ruby/1.8/puppet/transaction/change.rb:54:in `go'
> > /usr/lib/ruby/1.8/puppet/transaction/change.rb:74:in `forward'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:118:in `apply_changes'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:111:in `collect'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:111:in `apply_changes'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:83:in `apply'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:239:in `eval_resource'
> > /usr/lib/ruby/1.8/puppet/util.rb:445:in `thinmark'
> > /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
> > /usr/lib/ruby/1.8/puppet/util.rb:444:in `thinmark'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:238:in `eval_resource'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:310:in `evaluate'
> > /usr/lib/ruby/1.8/puppet/util.rb:445:in `thinmark'
> > /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
> > /usr/lib/ruby/1.8/puppet/util.rb:444:in `thinmark'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:309:in `evaluate'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:303:in `collect'
> > /usr/lib/ruby/1.8/puppet/transaction.rb:303:in `evaluate'
> > /usr/lib/ruby/1.8/puppet/node/catalog.rb:124:in `apply'
> > /usr/bin/puppet:220
> > 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/test.pp:6
> > debug: Finishing transaction 6999270059 with 1 changes
>
> > On 30 sep, 17:03, "D.N. van der Meijden" 
> > wrote:
> >> No problem Luke, thanks for helping me out here.
> >> Since I'm still a puppet n00b, where should I place the test.pp? On
> >> the host I presume (I tried /etc/puppet/manifests/test.pp) ?
>
> >> test.pp:
> >> class test {
> >>    service { "rsyslog":
> >>       name      => "rsyslog",
> >>       enable    => true,
> >>       ensure    => running,
> >>       hasstatus => true,
> >>       subscribe => File["/etc/rsyslog.conf"],
> >>    }
>
> >> }
>
> >> If I start the command on the client, I get some weird output:
>
> >> client:/etc/init.d# puppet apply --verbose --debug --trace --summarize
> >> test.pp
> >> /usr/lib/ruby/1.8/puppet/parser/parser_support.rb:95:in `file='
> >> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:69:in `create_parser'
> >> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:54:in `parser'
> >> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:27:in `compile'
> >> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:68:in
>

Re: [Puppet Users] Re: Question regarding the SERVICE type

[James Lucas]

 Hi,

I previously had a similar problem trying to start a ruby app using 
bundler that I eventually found to be caused by the non existence of the 
$HOME environment variable, adding this using:

environment => "HOME=/home/user" to the exec command fixed it.

Could there be an environment difference between running via puppet and 
manually that could cause it not to run?


Regards

James

On 30/09/2010 15:33, D.N. van der Meijden wrote:

Hi Luke,

As mentioned it works manually:

'client:~# /etc/init.d/zabbix_agent start ; echo $?
Starting Zabbix agent: zabbix_agentd
0


By the way, this specific client is a lenny 5.05




--
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: Question regarding the SERVICE type

[Nigel Kersten]

Can you post the init script?

Is it possible it's a PATH problem inside the script? Something that
works under your environment, but not under the user puppet is running
as?



On Thu, Sep 30, 2010 at 8:16 AM, D.N. van der Meijden
 wrote:
> My bad!! I understand the puppet command now...
>
> client:/tmp# puppet --verbose --debug --trace test.pp
> 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'
> /usr/lib/ruby/1.8/puppet/util/errors.rb:51:in `fail'
> /usr/lib/ruby/1.8/puppet/provider/service/base.rb:122:in `texecute'
> /usr/lib/ruby/1.8/puppet/provider/service/base.rb:134:in `ucommand'
> /usr/lib/ruby/1.8/puppet/provider/service/base.rb:78:in `start'
> /usr/lib/ruby/1.8/puppet/type/service.rb:61:in `set_running'
> /usr/lib/ruby/1.8/puppet/property.rb:163:in `send'
> /usr/lib/ruby/1.8/puppet/property.rb:163:in `call_valuemethod'
> /usr/lib/ruby/1.8/puppet/property.rb:349:in `set'
> /usr/lib/ruby/1.8/puppet/property.rb:421:in `sync'
> /usr/lib/ruby/1.8/puppet/type/service.rb:72:in `sync'
> /usr/lib/ruby/1.8/puppet/transaction/change.rb:54:in `go'
> /usr/lib/ruby/1.8/puppet/transaction/change.rb:74:in `forward'
> /usr/lib/ruby/1.8/puppet/transaction.rb:118:in `apply_changes'
> /usr/lib/ruby/1.8/puppet/transaction.rb:111:in `collect'
> /usr/lib/ruby/1.8/puppet/transaction.rb:111:in `apply_changes'
> /usr/lib/ruby/1.8/puppet/transaction.rb:83:in `apply'
> /usr/lib/ruby/1.8/puppet/transaction.rb:239:in `eval_resource'
> /usr/lib/ruby/1.8/puppet/util.rb:445:in `thinmark'
> /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
> /usr/lib/ruby/1.8/puppet/util.rb:444:in `thinmark'
> /usr/lib/ruby/1.8/puppet/transaction.rb:238:in `eval_resource'
> /usr/lib/ruby/1.8/puppet/transaction.rb:310:in `evaluate'
> /usr/lib/ruby/1.8/puppet/util.rb:445:in `thinmark'
> /usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
> /usr/lib/ruby/1.8/puppet/util.rb:444:in `thinmark'
> /usr/lib/ruby/1.8/puppet/transaction.rb:309:in `evaluate'
> /usr/lib/ruby/1.8/puppet/transaction.rb:303:in `collect'
> /usr/lib/ruby/1.8/puppet/transaction.rb:303:in `evaluate'
> /usr/lib/ruby/1.8/puppet/node/catalog.rb:124:in `apply'
> /usr/bin/puppet:220
> 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/test.pp:6
> debug: Finishing transaction 6999270059 with 1 changes
>
>
> On 30 sep, 17:03, "D.N. van der Meijden" 
> wrote:
>> No problem Luke, thanks for helping me out here.
>> Since I'm still a puppet n00b, where should I place the test.pp? On
>> the host I presume (I tried /etc/puppet/manifests/test.pp) ?
>>
>> test.pp:
>> class test {
>>    service { "rsyslog":
>>       name      => "rsyslog",
>>       enable    => true,
>>       ensure    => running,
>>       hasstatus => true,
>>       subscribe => File["/etc/rsyslog.conf"],
>>    }
>>
>> }
>>
>> If I start the command on the client, I get some weird output:
>>
>> client:/etc/init.d# puppet apply --verbose --debug --trace --summarize
>> test.pp
>> /usr/lib/ruby/1.8/puppet/parser/parser_support.rb:95:in `file='
>> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:69:in `create_parser'
>> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:54:in `parser'
>> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:27:in `compile'
>> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:68:in
>> `compile'
>> /usr/lib/ruby/1.8/puppet/util.rb:217:in `benchmark'
>> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:66:in
>> `compile'
>> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:21:in `find'
>> /usr/lib/ruby/1.8/puppet/indirector/indirection.rb:210:in `find'
>> /usr/lib/ruby/1.8/puppet/indirector.rb:49:in `find'
>> /usr/bin/puppet:210
>> Could not parse for environment production: Could not find file /etc/
>> init.d/apply.pp
>>
>> On 30 sep, 16:45, "luke.bigum"  wrote:
>>
>>
>>
>> > My apologies, I thought you were saying it starts but were unaware of
>> > the exit code.
>>
>> > I'm now unsure... You could try run this:
>>
>> > puppet apply --verbose --debug --trace --summarize test.pp
>>
>> > where test.pp is the simplest form of your service as possible, and
>> > see if you get anything useful, although I've just done that on a
>> > CentOS system and it wasn't as helpful as I imagined (didn't blatantly
>> > tell me the exit code as I hoped).
>>
>> > On Sep 30, 3:33 pm, "D.N. van der Meijden" 
>> > wrote:
>>
>> > > Hi Luke,
>>
>> > > As mentioned it works manual

[Puppet Users] Re: Question regarding the SERVICE type

[D.N. van der Meijden]

My bad!! I understand the puppet command now...

client:/tmp# puppet --verbose --debug --trace test.pp
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'
/usr/lib/ruby/1.8/puppet/util/errors.rb:51:in `fail'
/usr/lib/ruby/1.8/puppet/provider/service/base.rb:122:in `texecute'
/usr/lib/ruby/1.8/puppet/provider/service/base.rb:134:in `ucommand'
/usr/lib/ruby/1.8/puppet/provider/service/base.rb:78:in `start'
/usr/lib/ruby/1.8/puppet/type/service.rb:61:in `set_running'
/usr/lib/ruby/1.8/puppet/property.rb:163:in `send'
/usr/lib/ruby/1.8/puppet/property.rb:163:in `call_valuemethod'
/usr/lib/ruby/1.8/puppet/property.rb:349:in `set'
/usr/lib/ruby/1.8/puppet/property.rb:421:in `sync'
/usr/lib/ruby/1.8/puppet/type/service.rb:72:in `sync'
/usr/lib/ruby/1.8/puppet/transaction/change.rb:54:in `go'
/usr/lib/ruby/1.8/puppet/transaction/change.rb:74:in `forward'
/usr/lib/ruby/1.8/puppet/transaction.rb:118:in `apply_changes'
/usr/lib/ruby/1.8/puppet/transaction.rb:111:in `collect'
/usr/lib/ruby/1.8/puppet/transaction.rb:111:in `apply_changes'
/usr/lib/ruby/1.8/puppet/transaction.rb:83:in `apply'
/usr/lib/ruby/1.8/puppet/transaction.rb:239:in `eval_resource'
/usr/lib/ruby/1.8/puppet/util.rb:445:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/lib/ruby/1.8/puppet/util.rb:444:in `thinmark'
/usr/lib/ruby/1.8/puppet/transaction.rb:238:in `eval_resource'
/usr/lib/ruby/1.8/puppet/transaction.rb:310:in `evaluate'
/usr/lib/ruby/1.8/puppet/util.rb:445:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/lib/ruby/1.8/puppet/util.rb:444:in `thinmark'
/usr/lib/ruby/1.8/puppet/transaction.rb:309:in `evaluate'
/usr/lib/ruby/1.8/puppet/transaction.rb:303:in `collect'
/usr/lib/ruby/1.8/puppet/transaction.rb:303:in `evaluate'
/usr/lib/ruby/1.8/puppet/node/catalog.rb:124:in `apply'
/usr/bin/puppet:220
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/test.pp:6
debug: Finishing transaction 6999270059 with 1 changes


On 30 sep, 17:03, "D.N. van der Meijden" 
wrote:
> No problem Luke, thanks for helping me out here.
> Since I'm still a puppet n00b, where should I place the test.pp? On
> the host I presume (I tried /etc/puppet/manifests/test.pp) ?
>
> test.pp:
> class test {
>    service { "rsyslog":
>       name      => "rsyslog",
>       enable    => true,
>       ensure    => running,
>       hasstatus => true,
>       subscribe => File["/etc/rsyslog.conf"],
>    }
>
> }
>
> If I start the command on the client, I get some weird output:
>
> client:/etc/init.d# puppet apply --verbose --debug --trace --summarize
> test.pp
> /usr/lib/ruby/1.8/puppet/parser/parser_support.rb:95:in `file='
> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:69:in `create_parser'
> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:54:in `parser'
> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:27:in `compile'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:68:in
> `compile'
> /usr/lib/ruby/1.8/puppet/util.rb:217:in `benchmark'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:66:in
> `compile'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:21:in `find'
> /usr/lib/ruby/1.8/puppet/indirector/indirection.rb:210:in `find'
> /usr/lib/ruby/1.8/puppet/indirector.rb:49:in `find'
> /usr/bin/puppet:210
> Could not parse for environment production: Could not find file /etc/
> init.d/apply.pp
>
> On 30 sep, 16:45, "luke.bigum"  wrote:
>
>
>
> > My apologies, I thought you were saying it starts but were unaware of
> > the exit code.
>
> > I'm now unsure... You could try run this:
>
> > puppet apply --verbose --debug --trace --summarize test.pp
>
> > where test.pp is the simplest form of your service as possible, and
> > see if you get anything useful, although I've just done that on a
> > CentOS system and it wasn't as helpful as I imagined (didn't blatantly
> > tell me the exit code as I hoped).
>
> > On Sep 30, 3:33 pm, "D.N. van der Meijden" 
> > wrote:
>
> > > Hi Luke,
>
> > > As mentioned it works manually:
>
> > > 'client:~# /etc/init.d/zabbix_agent start ; echo $?
> > > Starting Zabbix agent: zabbix_agentd
> > > 0
>
> > > By the way, this specific client is a lenny 5.05
>
> > > On 30 sep, 16:28, "luke.bigum"  wrote:
>
> > > > As Nigel indicated, the exit code for your init script is not what
> > > > puppet expects, it is not a file permission problem.
>
> > > > As Nigel suggested, shut down your

[Puppet Users] Re: Question regarding the SERVICE type

[D.N. van der Meijden]

My bad! Just checked out the puppet command :-s

Ok, output on my client is now:
client:/tmp# puppet --verbose --debug --trace test.pp
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'
/usr/lib/ruby/1.8/puppet/util/errors.rb:51:in `fail'
/usr/lib/ruby/1.8/puppet/provider/service/base.rb:122:in `texecute'
/usr/lib/ruby/1.8/puppet/provider/service/base.rb:134:in `ucommand'
/usr/lib/ruby/1.8/puppet/provider/service/base.rb:78:in `start'
/usr/lib/ruby/1.8/puppet/type/service.rb:61:in `set_running'
/usr/lib/ruby/1.8/puppet/property.rb:163:in `send'
/usr/lib/ruby/1.8/puppet/property.rb:163:in `call_valuemethod'
/usr/lib/ruby/1.8/puppet/property.rb:349:in `set'
/usr/lib/ruby/1.8/puppet/property.rb:421:in `sync'
/usr/lib/ruby/1.8/puppet/type/service.rb:72:in `sync'
/usr/lib/ruby/1.8/puppet/transaction/change.rb:54:in `go'
/usr/lib/ruby/1.8/puppet/transaction/change.rb:74:in `forward'
/usr/lib/ruby/1.8/puppet/transaction.rb:118:in `apply_changes'
/usr/lib/ruby/1.8/puppet/transaction.rb:111:in `collect'
/usr/lib/ruby/1.8/puppet/transaction.rb:111:in `apply_changes'
/usr/lib/ruby/1.8/puppet/transaction.rb:83:in `apply'
/usr/lib/ruby/1.8/puppet/transaction.rb:239:in `eval_resource'
/usr/lib/ruby/1.8/puppet/util.rb:445:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/lib/ruby/1.8/puppet/util.rb:444:in `thinmark'
/usr/lib/ruby/1.8/puppet/transaction.rb:238:in `eval_resource'
/usr/lib/ruby/1.8/puppet/transaction.rb:310:in `evaluate'
/usr/lib/ruby/1.8/puppet/util.rb:445:in `thinmark'
/usr/lib/ruby/1.8/benchmark.rb:308:in `realtime'
/usr/lib/ruby/1.8/puppet/util.rb:444:in `thinmark'
/usr/lib/ruby/1.8/puppet/transaction.rb:309:in `evaluate'
/usr/lib/ruby/1.8/puppet/transaction.rb:303:in `collect'
/usr/lib/ruby/1.8/puppet/transaction.rb:303:in `evaluate'
/usr/lib/ruby/1.8/puppet/node/catalog.rb:124:in `apply'
/usr/bin/puppet:220
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/test.pp:6
debug: Finishing transaction 6999270059 with 1 changes


On 30 sep, 17:03, "D.N. van der Meijden" 
wrote:
> No problem Luke, thanks for helping me out here.
> Since I'm still a puppet n00b, where should I place the test.pp? On
> the host I presume (I tried /etc/puppet/manifests/test.pp) ?
>
> test.pp:
> class test {
>    service { "rsyslog":
>       name      => "rsyslog",
>       enable    => true,
>       ensure    => running,
>       hasstatus => true,
>       subscribe => File["/etc/rsyslog.conf"],
>    }
>
> }
>
> If I start the command on the client, I get some weird output:
>
> client:/etc/init.d# puppet apply --verbose --debug --trace --summarize
> test.pp
> /usr/lib/ruby/1.8/puppet/parser/parser_support.rb:95:in `file='
> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:69:in `create_parser'
> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:54:in `parser'
> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:27:in `compile'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:68:in
> `compile'
> /usr/lib/ruby/1.8/puppet/util.rb:217:in `benchmark'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:66:in
> `compile'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:21:in `find'
> /usr/lib/ruby/1.8/puppet/indirector/indirection.rb:210:in `find'
> /usr/lib/ruby/1.8/puppet/indirector.rb:49:in `find'
> /usr/bin/puppet:210
> Could not parse for environment production: Could not find file /etc/
> init.d/apply.pp
>
> On 30 sep, 16:45, "luke.bigum"  wrote:
>
>
>
> > My apologies, I thought you were saying it starts but were unaware of
> > the exit code.
>
> > I'm now unsure... You could try run this:
>
> > puppet apply --verbose --debug --trace --summarize test.pp
>
> > where test.pp is the simplest form of your service as possible, and
> > see if you get anything useful, although I've just done that on a
> > CentOS system and it wasn't as helpful as I imagined (didn't blatantly
> > tell me the exit code as I hoped).
>
> > On Sep 30, 3:33 pm, "D.N. van der Meijden" 
> > wrote:
>
> > > Hi Luke,
>
> > > As mentioned it works manually:
>
> > > 'client:~# /etc/init.d/zabbix_agent start ; echo $?
> > > Starting Zabbix agent: zabbix_agentd
> > > 0
>
> > > By the way, this specific client is a lenny 5.05
>
> > > On 30 sep, 16:28, "luke.bigum"  wrote:
>
> > > > As Nigel indicated, the exit code for your init script is not what
> > > > puppet expects, it is not a file permission problem.
>
> > > > As

[Puppet Users] Re: Question regarding the SERVICE type

[luke.bigum]

>From what I understand using "puppet apply" will make no attempt to
contact the puppet master and so is useful for testing, but all your
Puppet config files must be local. The file you are applying should be
in CWD, or you can just:

puppet apply [options] /wherever/test.pp

As for your error output below, I'm not sure why it would be trying to
look for "apply.pp", has it parsed the "apply" sub command as if it's
expecting a file I wonder. It doesn't look like my output if I give it
the wrong location for test.pp, but I am using Puppet 2.6.1 and can't
help you with any other version. Run "puppet help" ?

On Sep 30, 4:03 pm, "D.N. van der Meijden" 
wrote:
> No problem Luke, thanks for helping me out here.
> Since I'm still a puppet n00b, where should I place the test.pp? On
> the host I presume (I tried /etc/puppet/manifests/test.pp) ?
>
> test.pp:
> class test {
>    service { "rsyslog":
>       name      => "rsyslog",
>       enable    => true,
>       ensure    => running,
>       hasstatus => true,
>       subscribe => File["/etc/rsyslog.conf"],
>    }
>
> }
>
> If I start the command on the client, I get some weird output:
>
> client:/etc/init.d# puppet apply --verbose --debug --trace --summarize
> test.pp
> /usr/lib/ruby/1.8/puppet/parser/parser_support.rb:95:in `file='
> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:69:in `create_parser'
> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:54:in `parser'
> /usr/lib/ruby/1.8/puppet/parser/interpreter.rb:27:in `compile'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:68:in
> `compile'
> /usr/lib/ruby/1.8/puppet/util.rb:217:in `benchmark'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:66:in
> `compile'
> /usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:21:in `find'
> /usr/lib/ruby/1.8/puppet/indirector/indirection.rb:210:in `find'
> /usr/lib/ruby/1.8/puppet/indirector.rb:49:in `find'
> /usr/bin/puppet:210
> Could not parse for environment production: Could not find file /etc/
> init.d/apply.pp
>
> On 30 sep, 16:45, "luke.bigum"  wrote:
>
> > My apologies, I thought you were saying it starts but were unaware of
> > the exit code.
>
> > I'm now unsure... You could try run this:
>
> > puppet apply --verbose --debug --trace --summarize test.pp
>
> > where test.pp is the simplest form of your service as possible, and
> > see if you get anything useful, although I've just done that on a
> > CentOS system and it wasn't as helpful as I imagined (didn't blatantly
> > tell me the exit code as I hoped).
>
> > On Sep 30, 3:33 pm, "D.N. van der Meijden" 
> > wrote:
>
> > > Hi Luke,
>
> > > As mentioned it works manually:
>
> > > 'client:~# /etc/init.d/zabbix_agent start ; echo $?
> > > Starting Zabbix agent: zabbix_agentd
> > > 0
>
> > > By the way, this specific client is a lenny 5.05
>
> > > On 30 sep, 16:28, "luke.bigum"  wrote:
>
> > > > As Nigel indicated, the exit code for your init script is not what
> > > > puppet expects, it is not a file permission problem.
>
> > > > As Nigel suggested, shut down your service then run this:
>
> > > > /etc/init.d/zabbix_agent start ; echo $?
>
> > > > And tell us what number is printed on the screen. If it prints 1, that
> > > > would explain your Puppet error message. Not sure what operating
> > > > system you use, but init scripts SHOULD return 0 when they run
> > > > successfully. If your init script is returning 1 on success, it's
> > > > broken.
>
> > > > -Luke
>
> > > > On Sep 30, 3:04 pm, "D.N. van der Meijden" 
> > > > wrote:
>
> > > > > Thanks for the quick reply Nigel.
> > > > > I understand that the puppet is reporting back the exit status, but
> > > > > what I don't understand is why it keeps failing when trying to start
> > > > > via puppet.
> > > > > All files are available on the client, permissions are ok and starting
> > > > > the daemon manually works without problems.
>
> > > > > On 30 sep, 15:57, Nigel Kersten  wrote:
>
> > > > > > On Thu, Sep 30, 2010 at 6:42 AM, D.N. van der Meijden
>
> > > > > >  wrote:
> > > > > > > I'm trying to get a service running, but I keep getting the 
> > > > > > > following
> > > > > > > error message:
> > > > > > > "err: //Node[debiannode]/zabbix/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 
> > > > > > > /etc/
> > > > > > > puppet/modules/zabbix/manifests/init.pp:62"
>
> > > > > > > The part of the init.pp script:
> > > > > > >   service { "zabbix_agent":
> > > > > > >      name      => "zabbix_agent",
> > > > > > >      enable    => true,
> > > > > > >      ensure    => running,
> > > > > > >      hasstatus => true,
> > > > > > >      subscribe => File["zabbix_agentd.conf"],
> > > > > > >      require   => [ File["/etc/zabbix"],
> > > > > > > File["zabbix_agentd.conf"] ],
> > > > > > >   }     # <-- line 62
>
> > > > > > > If I start the daemon manually [as root or n

[Puppet Users] Re: Question regarding the SERVICE type

[D.N. van der Meijden]

No problem Luke, thanks for helping me out here.
Since I'm still a puppet n00b, where should I place the test.pp? On
the host I presume (I tried /etc/puppet/manifests/test.pp) ?

test.pp:
class test {
   service { "rsyslog":
  name  => "rsyslog",
  enable=> true,
  ensure=> running,
  hasstatus => true,
  subscribe => File["/etc/rsyslog.conf"],
   }
}

If I start the command on the client, I get some weird output:

client:/etc/init.d# puppet apply --verbose --debug --trace --summarize
test.pp
/usr/lib/ruby/1.8/puppet/parser/parser_support.rb:95:in `file='
/usr/lib/ruby/1.8/puppet/parser/interpreter.rb:69:in `create_parser'
/usr/lib/ruby/1.8/puppet/parser/interpreter.rb:54:in `parser'
/usr/lib/ruby/1.8/puppet/parser/interpreter.rb:27:in `compile'
/usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:68:in
`compile'
/usr/lib/ruby/1.8/puppet/util.rb:217:in `benchmark'
/usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:66:in
`compile'
/usr/lib/ruby/1.8/puppet/indirector/catalog/compiler.rb:21:in `find'
/usr/lib/ruby/1.8/puppet/indirector/indirection.rb:210:in `find'
/usr/lib/ruby/1.8/puppet/indirector.rb:49:in `find'
/usr/bin/puppet:210
Could not parse for environment production: Could not find file /etc/
init.d/apply.pp


On 30 sep, 16:45, "luke.bigum"  wrote:
> My apologies, I thought you were saying it starts but were unaware of
> the exit code.
>
> I'm now unsure... You could try run this:
>
> puppet apply --verbose --debug --trace --summarize test.pp
>
> where test.pp is the simplest form of your service as possible, and
> see if you get anything useful, although I've just done that on a
> CentOS system and it wasn't as helpful as I imagined (didn't blatantly
> tell me the exit code as I hoped).
>
> On Sep 30, 3:33 pm, "D.N. van der Meijden" 
> wrote:
>
>
>
> > Hi Luke,
>
> > As mentioned it works manually:
>
> > 'client:~# /etc/init.d/zabbix_agent start ; echo $?
> > Starting Zabbix agent: zabbix_agentd
> > 0
>
> > By the way, this specific client is a lenny 5.05
>
> > On 30 sep, 16:28, "luke.bigum"  wrote:
>
> > > As Nigel indicated, the exit code for your init script is not what
> > > puppet expects, it is not a file permission problem.
>
> > > As Nigel suggested, shut down your service then run this:
>
> > > /etc/init.d/zabbix_agent start ; echo $?
>
> > > And tell us what number is printed on the screen. If it prints 1, that
> > > would explain your Puppet error message. Not sure what operating
> > > system you use, but init scripts SHOULD return 0 when they run
> > > successfully. If your init script is returning 1 on success, it's
> > > broken.
>
> > > -Luke
>
> > > On Sep 30, 3:04 pm, "D.N. van der Meijden" 
> > > wrote:
>
> > > > Thanks for the quick reply Nigel.
> > > > I understand that the puppet is reporting back the exit status, but
> > > > what I don't understand is why it keeps failing when trying to start
> > > > via puppet.
> > > > All files are available on the client, permissions are ok and starting
> > > > the daemon manually works without problems.
>
> > > > On 30 sep, 15:57, Nigel Kersten  wrote:
>
> > > > > On Thu, Sep 30, 2010 at 6:42 AM, D.N. van der Meijden
>
> > > > >  wrote:
> > > > > > I'm trying to get a service running, but I keep getting the 
> > > > > > following
> > > > > > error message:
> > > > > > "err: //Node[debiannode]/zabbix/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 /etc/
> > > > > > puppet/modules/zabbix/manifests/init.pp:62"
>
> > > > > > The part of the init.pp script:
> > > > > >   service { "zabbix_agent":
> > > > > >      name      => "zabbix_agent",
> > > > > >      enable    => true,
> > > > > >      ensure    => running,
> > > > > >      hasstatus => true,
> > > > > >      subscribe => File["zabbix_agentd.conf"],
> > > > > >      require   => [ File["/etc/zabbix"],
> > > > > > File["zabbix_agentd.conf"] ],
> > > > > >   }     # <-- line 62
>
> > > > > > If I start the daemon manually [as root or normal user zabbix] 
> > > > > > (i.e. /
> > > > > > etc/init.d/zabbix_agent start), it works.
> > > > > > I checked the permissions, but these are set at 755 so that 
> > > > > > shouldn't
> > > > > > be a problem.
>
> > > > > > client:~# /etc/init.d/zabbix_agent start
> > > > > > Starting Zabbix agent: zabbix_agentd
> > > > > > client:~# ps -ef | grep zabbix
> > > > > > zabbix    2116     1  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > > zabbix_agentd
> > > > > > zabbix    2117  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > > zabbix_agentd
> > > > > > zabbix    2118  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > > zabbix_agentd
> > > > > > zabbix    2119  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > > zabbix_agentd
> > > > > > zabbix    2120  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > > zabbix_

[Puppet Users] Looking for High Mid-Sr. Level Unix/Linux person with puppet skills in Los Angeles, CA, USA

[Joe McDonagh]

Please e-mail me off list if you're looking for a contract->perm 
position in LA, close to LAX near Boeing and the other defense 
companies. The role is fairly senior and involves mostly Linux and Unix 
systems. Puppet experience is a win, also is OpenBSD for 
routing/firewalling. More details to be given off list if you contact me.


--
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] Re: Question regarding the SERVICE type

[luke.bigum]

My apologies, I thought you were saying it starts but were unaware of
the exit code.

I'm now unsure... You could try run this:

puppet apply --verbose --debug --trace --summarize test.pp

where test.pp is the simplest form of your service as possible, and
see if you get anything useful, although I've just done that on a
CentOS system and it wasn't as helpful as I imagined (didn't blatantly
tell me the exit code as I hoped).

On Sep 30, 3:33 pm, "D.N. van der Meijden" 
wrote:
> Hi Luke,
>
> As mentioned it works manually:
>
> 'client:~# /etc/init.d/zabbix_agent start ; echo $?
> Starting Zabbix agent: zabbix_agentd
> 0
>
> By the way, this specific client is a lenny 5.05
>
> On 30 sep, 16:28, "luke.bigum"  wrote:
>
> > As Nigel indicated, the exit code for your init script is not what
> > puppet expects, it is not a file permission problem.
>
> > As Nigel suggested, shut down your service then run this:
>
> > /etc/init.d/zabbix_agent start ; echo $?
>
> > And tell us what number is printed on the screen. If it prints 1, that
> > would explain your Puppet error message. Not sure what operating
> > system you use, but init scripts SHOULD return 0 when they run
> > successfully. If your init script is returning 1 on success, it's
> > broken.
>
> > -Luke
>
> > On Sep 30, 3:04 pm, "D.N. van der Meijden" 
> > wrote:
>
> > > Thanks for the quick reply Nigel.
> > > I understand that the puppet is reporting back the exit status, but
> > > what I don't understand is why it keeps failing when trying to start
> > > via puppet.
> > > All files are available on the client, permissions are ok and starting
> > > the daemon manually works without problems.
>
> > > On 30 sep, 15:57, Nigel Kersten  wrote:
>
> > > > On Thu, Sep 30, 2010 at 6:42 AM, D.N. van der Meijden
>
> > > >  wrote:
> > > > > I'm trying to get a service running, but I keep getting the following
> > > > > error message:
> > > > > "err: //Node[debiannode]/zabbix/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 /etc/
> > > > > puppet/modules/zabbix/manifests/init.pp:62"
>
> > > > > The part of the init.pp script:
> > > > >   service { "zabbix_agent":
> > > > >      name      => "zabbix_agent",
> > > > >      enable    => true,
> > > > >      ensure    => running,
> > > > >      hasstatus => true,
> > > > >      subscribe => File["zabbix_agentd.conf"],
> > > > >      require   => [ File["/etc/zabbix"],
> > > > > File["zabbix_agentd.conf"] ],
> > > > >   }     # <-- line 62
>
> > > > > If I start the daemon manually [as root or normal user zabbix] (i.e. /
> > > > > etc/init.d/zabbix_agent start), it works.
> > > > > I checked the permissions, but these are set at 755 so that shouldn't
> > > > > be a problem.
>
> > > > > client:~# /etc/init.d/zabbix_agent start
> > > > > Starting Zabbix agent: zabbix_agentd
> > > > > client:~# ps -ef | grep zabbix
> > > > > zabbix    2116     1  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > zabbix_agentd
> > > > > zabbix    2117  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > zabbix_agentd
> > > > > zabbix    2118  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > zabbix_agentd
> > > > > zabbix    2119  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > zabbix_agentd
> > > > > zabbix    2120  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > zabbix_agentd
> > > > > zabbix    2121  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > zabbix_agentd
> > > > > zabbix    2122  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > > zabbix_agentd
> > > > > root      2124  1890  0 15:37 pts/2    00:00:00 grep zabbix
>
> > > > > What am I missing here?
>
> > > > The exit status of starting the daemon, which is what Puppet is
> > > > reporting back to you.
>
> > > > /etc/init.d/zabbix_agent start ; echo $?
>
> > > > It sounds like puppet is actually starting it but thinking the
> > > > operation failed because the init script exits non-zero.
>
> > > > > --
> > > > > 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.
>
> > > > --
> > > > nigel- 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+unsubsc

[Puppet Users] Re: Question regarding the SERVICE type

[D.N. van der Meijden]

Hi Luke,

As mentioned it works manually:

'client:~# /etc/init.d/zabbix_agent start ; echo $?
Starting Zabbix agent: zabbix_agentd
0


By the way, this specific client is a lenny 5.05



On 30 sep, 16:28, "luke.bigum"  wrote:
> As Nigel indicated, the exit code for your init script is not what
> puppet expects, it is not a file permission problem.
>
> As Nigel suggested, shut down your service then run this:
>
> /etc/init.d/zabbix_agent start ; echo $?
>
> And tell us what number is printed on the screen. If it prints 1, that
> would explain your Puppet error message. Not sure what operating
> system you use, but init scripts SHOULD return 0 when they run
> successfully. If your init script is returning 1 on success, it's
> broken.
>
> -Luke
>
> On Sep 30, 3:04 pm, "D.N. van der Meijden" 
> wrote:
>
>
>
> > Thanks for the quick reply Nigel.
> > I understand that the puppet is reporting back the exit status, but
> > what I don't understand is why it keeps failing when trying to start
> > via puppet.
> > All files are available on the client, permissions are ok and starting
> > the daemon manually works without problems.
>
> > On 30 sep, 15:57, Nigel Kersten  wrote:
>
> > > On Thu, Sep 30, 2010 at 6:42 AM, D.N. van der Meijden
>
> > >  wrote:
> > > > I'm trying to get a service running, but I keep getting the following
> > > > error message:
> > > > "err: //Node[debiannode]/zabbix/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 /etc/
> > > > puppet/modules/zabbix/manifests/init.pp:62"
>
> > > > The part of the init.pp script:
> > > >   service { "zabbix_agent":
> > > >      name      => "zabbix_agent",
> > > >      enable    => true,
> > > >      ensure    => running,
> > > >      hasstatus => true,
> > > >      subscribe => File["zabbix_agentd.conf"],
> > > >      require   => [ File["/etc/zabbix"],
> > > > File["zabbix_agentd.conf"] ],
> > > >   }     # <-- line 62
>
> > > > If I start the daemon manually [as root or normal user zabbix] (i.e. /
> > > > etc/init.d/zabbix_agent start), it works.
> > > > I checked the permissions, but these are set at 755 so that shouldn't
> > > > be a problem.
>
> > > > client:~# /etc/init.d/zabbix_agent start
> > > > Starting Zabbix agent: zabbix_agentd
> > > > client:~# ps -ef | grep zabbix
> > > > zabbix    2116     1  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > zabbix_agentd
> > > > zabbix    2117  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > zabbix_agentd
> > > > zabbix    2118  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > zabbix_agentd
> > > > zabbix    2119  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > zabbix_agentd
> > > > zabbix    2120  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > zabbix_agentd
> > > > zabbix    2121  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > zabbix_agentd
> > > > zabbix    2122  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > > zabbix_agentd
> > > > root      2124  1890  0 15:37 pts/2    00:00:00 grep zabbix
>
> > > > What am I missing here?
>
> > > The exit status of starting the daemon, which is what Puppet is
> > > reporting back to you.
>
> > > /etc/init.d/zabbix_agent start ; echo $?
>
> > > It sounds like puppet is actually starting it but thinking the
> > > operation failed because the init script exits non-zero.
>
> > > > --
> > > > 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.
>
> > > --
> > > nigel- 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: Question regarding the SERVICE type

[luke.bigum]

As Nigel indicated, the exit code for your init script is not what
puppet expects, it is not a file permission problem.

As Nigel suggested, shut down your service then run this:

/etc/init.d/zabbix_agent start ; echo $?

And tell us what number is printed on the screen. If it prints 1, that
would explain your Puppet error message. Not sure what operating
system you use, but init scripts SHOULD return 0 when they run
successfully. If your init script is returning 1 on success, it's
broken.

-Luke

On Sep 30, 3:04 pm, "D.N. van der Meijden" 
wrote:
> Thanks for the quick reply Nigel.
> I understand that the puppet is reporting back the exit status, but
> what I don't understand is why it keeps failing when trying to start
> via puppet.
> All files are available on the client, permissions are ok and starting
> the daemon manually works without problems.
>
> On 30 sep, 15:57, Nigel Kersten  wrote:
>
> > On Thu, Sep 30, 2010 at 6:42 AM, D.N. van der Meijden
>
> >  wrote:
> > > I'm trying to get a service running, but I keep getting the following
> > > error message:
> > > "err: //Node[debiannode]/zabbix/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 /etc/
> > > puppet/modules/zabbix/manifests/init.pp:62"
>
> > > The part of the init.pp script:
> > >   service { "zabbix_agent":
> > >      name      => "zabbix_agent",
> > >      enable    => true,
> > >      ensure    => running,
> > >      hasstatus => true,
> > >      subscribe => File["zabbix_agentd.conf"],
> > >      require   => [ File["/etc/zabbix"],
> > > File["zabbix_agentd.conf"] ],
> > >   }     # <-- line 62
>
> > > If I start the daemon manually [as root or normal user zabbix] (i.e. /
> > > etc/init.d/zabbix_agent start), it works.
> > > I checked the permissions, but these are set at 755 so that shouldn't
> > > be a problem.
>
> > > client:~# /etc/init.d/zabbix_agent start
> > > Starting Zabbix agent: zabbix_agentd
> > > client:~# ps -ef | grep zabbix
> > > zabbix    2116     1  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > zabbix_agentd
> > > zabbix    2117  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > zabbix_agentd
> > > zabbix    2118  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > zabbix_agentd
> > > zabbix    2119  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > zabbix_agentd
> > > zabbix    2120  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > zabbix_agentd
> > > zabbix    2121  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > zabbix_agentd
> > > zabbix    2122  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > > zabbix_agentd
> > > root      2124  1890  0 15:37 pts/2    00:00:00 grep zabbix
>
> > > What am I missing here?
>
> > The exit status of starting the daemon, which is what Puppet is
> > reporting back to you.
>
> > /etc/init.d/zabbix_agent start ; echo $?
>
> > It sounds like puppet is actually starting it but thinking the
> > operation failed because the init script exits non-zero.
>
> > > --
> > > 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.
>
> > --
> > nigel- 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: Question regarding the SERVICE type

[D.N. van der Meijden]

Thanks for the quick reply Nigel.
I understand that the puppet is reporting back the exit status, but
what I don't understand is why it keeps failing when trying to start
via puppet.
All files are available on the client, permissions are ok and starting
the daemon manually works without problems.



On 30 sep, 15:57, Nigel Kersten  wrote:
> On Thu, Sep 30, 2010 at 6:42 AM, D.N. van der Meijden
>
>
>
>
>
>  wrote:
> > I'm trying to get a service running, but I keep getting the following
> > error message:
> > "err: //Node[debiannode]/zabbix/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 /etc/
> > puppet/modules/zabbix/manifests/init.pp:62"
>
> > The part of the init.pp script:
> >   service { "zabbix_agent":
> >      name      => "zabbix_agent",
> >      enable    => true,
> >      ensure    => running,
> >      hasstatus => true,
> >      subscribe => File["zabbix_agentd.conf"],
> >      require   => [ File["/etc/zabbix"],
> > File["zabbix_agentd.conf"] ],
> >   }     # <-- line 62
>
> > If I start the daemon manually [as root or normal user zabbix] (i.e. /
> > etc/init.d/zabbix_agent start), it works.
> > I checked the permissions, but these are set at 755 so that shouldn't
> > be a problem.
>
> > client:~# /etc/init.d/zabbix_agent start
> > Starting Zabbix agent: zabbix_agentd
> > client:~# ps -ef | grep zabbix
> > zabbix    2116     1  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > zabbix_agentd
> > zabbix    2117  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > zabbix_agentd
> > zabbix    2118  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > zabbix_agentd
> > zabbix    2119  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > zabbix_agentd
> > zabbix    2120  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > zabbix_agentd
> > zabbix    2121  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > zabbix_agentd
> > zabbix    2122  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> > zabbix_agentd
> > root      2124  1890  0 15:37 pts/2    00:00:00 grep zabbix
>
> > What am I missing here?
>
> The exit status of starting the daemon, which is what Puppet is
> reporting back to you.
>
> /etc/init.d/zabbix_agent start ; echo $?
>
> It sounds like puppet is actually starting it but thinking the
> operation failed because the init script exits non-zero.
>
>
>
> > --
> > 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.
>
> --
> nigel- 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] Question regarding the SERVICE type

[Nigel Kersten]

On Thu, Sep 30, 2010 at 6:42 AM, D.N. van der Meijden
 wrote:
> I'm trying to get a service running, but I keep getting the following
> error message:
> "err: //Node[debiannode]/zabbix/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 /etc/
> puppet/modules/zabbix/manifests/init.pp:62"
>
> The part of the init.pp script:
>   service { "zabbix_agent":
>      name      => "zabbix_agent",
>      enable    => true,
>      ensure    => running,
>      hasstatus => true,
>      subscribe => File["zabbix_agentd.conf"],
>      require   => [ File["/etc/zabbix"],
> File["zabbix_agentd.conf"] ],
>   }     # <-- line 62
>
> If I start the daemon manually [as root or normal user zabbix] (i.e. /
> etc/init.d/zabbix_agent start), it works.
> I checked the permissions, but these are set at 755 so that shouldn't
> be a problem.
>
> client:~# /etc/init.d/zabbix_agent start
> Starting Zabbix agent: zabbix_agentd
> client:~# ps -ef | grep zabbix
> zabbix    2116     1  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> zabbix_agentd
> zabbix    2117  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> zabbix_agentd
> zabbix    2118  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> zabbix_agentd
> zabbix    2119  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> zabbix_agentd
> zabbix    2120  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> zabbix_agentd
> zabbix    2121  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> zabbix_agentd
> zabbix    2122  2116  0 15:37 ?        00:00:00 /etc/zabbix/sbin/
> zabbix_agentd
> root      2124  1890  0 15:37 pts/2    00:00:00 grep zabbix
>
>
> What am I missing here?

The exit status of starting the daemon, which is what Puppet is
reporting back to you.

/etc/init.d/zabbix_agent start ; echo $?

It sounds like puppet is actually starting it but thinking the
operation failed because the init script exits non-zero.

>
> --
> 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.

[Puppet Users] Question regarding the SERVICE type

[D.N. van der Meijden]

I'm trying to get a service running, but I keep getting the following
error message:
"err: //Node[debiannode]/zabbix/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 /etc/
puppet/modules/zabbix/manifests/init.pp:62"

The part of the init.pp script:
   service { "zabbix_agent":
  name  => "zabbix_agent",
  enable=> true,
  ensure=> running,
  hasstatus => true,
  subscribe => File["zabbix_agentd.conf"],
  require   => [ File["/etc/zabbix"],
File["zabbix_agentd.conf"] ],
   } # <-- line 62

If I start the daemon manually [as root or normal user zabbix] (i.e. /
etc/init.d/zabbix_agent start), it works.
I checked the permissions, but these are set at 755 so that shouldn't
be a problem.

client:~# /etc/init.d/zabbix_agent start
Starting Zabbix agent: zabbix_agentd
client:~# ps -ef | grep zabbix
zabbix2116 1  0 15:37 ?00:00:00 /etc/zabbix/sbin/
zabbix_agentd
zabbix2117  2116  0 15:37 ?00:00:00 /etc/zabbix/sbin/
zabbix_agentd
zabbix2118  2116  0 15:37 ?00:00:00 /etc/zabbix/sbin/
zabbix_agentd
zabbix2119  2116  0 15:37 ?00:00:00 /etc/zabbix/sbin/
zabbix_agentd
zabbix2120  2116  0 15:37 ?00:00:00 /etc/zabbix/sbin/
zabbix_agentd
zabbix2121  2116  0 15:37 ?00:00:00 /etc/zabbix/sbin/
zabbix_agentd
zabbix2122  2116  0 15:37 ?00:00:00 /etc/zabbix/sbin/
zabbix_agentd
root  2124  1890  0 15:37 pts/200:00:00 grep zabbix


What am I missing 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-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] Proposal to remove redundant info in source => parameters

[Nigel Kersten]

On Wed, Sep 29, 2010 at 9:22 PM, Jeff McCune  wrote:
> On Sat, Sep 25, 2010 at 2:45 PM, Nigel Kersten  
> wrote:
>> What implications of introducing a new syntactical element are there?
>
> Yet another inconsistency and confusion for newbies.
>
> With that said, I think the benefits _far_ outweigh the drawbacks.
> Especially since it brings consistency to the behavior of file()
> template() and source.
>
>> Where else could we use this? On import statements?
>
> Any function that needs to read data from the file system on the master.
>
> I'm looking at you, extlookup() ...
>
> Today I wrote a function called getconf() which is little more than
>
> Puppet::Parser::Functions.newfunction(:getconf, :type => :rvalue) do |args|
>  Puppet.settings[args[0]]
> end
>
> The motivation was to store extlookup data inside of confdir which is
> usually under version control and at different file system paths for
> development, testing, and production.
>
> $confdir = getconf("confdir")
> $extlookup_datadir = "${confdir}/extdata"
>
>> import "foo.pp" already looks in the current working directory, but is
>> there any point trying to add this throughout the language so you can
>> do:
>>
>> # modules/foo/manifests/a/b/c/d/contrived.pp
>> import "~/clean.pp"
>>
>> and it resolves to modules/foo/manifests/clean.pp ?
>
> I think no matter what the path expansion logic should be generalized
> into some utility method so types, providers, functions, report
> processors, and whatever else we cook up can take advantage of this.
>
> A quick win could be to add an path_to() function to the language
> which should give us the desired behavior for free.
>
> import path_to("~/clean.pp")

Please update the bug with this so it doesn't fall through the tracks,
agreed on all counts.

http://projects.puppetlabs.com/issues/4885

-- 
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: puppet error on cron w/ "complex" timing

[Daniel Maher]

On 09/29/2010 03:31 PM, Radek wrote:

maybe this will help:

minute =>  "2-57/5",



Lovely, thank you.

--
Daniel Maher 
"The Internet is completely over." -- Prince

--
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] Overwrite default settings in nodes using external nodes.

[Nigel Kersten]

2010/9/30 Héctor Rivas Gándara :
>>> We have simple inheritance in our external node classifier like this:
>>> We only allow one level, and includes cannot include other includes.
>>> Parameters specified in a node yaml override the same parameter in an
>>> include yaml.
>>> Oh, and we have a default node that all of this is appended to.
>>> This is a really simple classifier, less than 100 lines of real code.
>>
>> I will try to do something like that.
>
> I've just made a small python script that implements a simple external
> node manager with inheritance support.
>
> http://gist.github.com/604530
>
> It allows define "includes" to other nodes/definitions in yaml by
> adding classes named "external:" or adding a new attribute
> "include". It resolves references to other parameters using the sintax
> "%{parameter_name}".
>
> This way you can use something like:
>
>        - name: server
>          parameters:
>           guest_group: "guests"
>          classes:
>           - generic_server
>
>        - name: linux
>          parameters:
>           connect_allowed_groups: [ "group1", "group2" ]
>          classes:
>           - external:server
>
>        - name: node1.mydomain.com
>          parameters:
>           connect_allowed_groups: [ "%{connect_allowed_groups}", "group3"]
>          classes:
>           - dbserver
>           - external:linux
>
>        - name: node2.mydomain.com
>          parameters:
>           connect_allowed_groups:  ["group1","group3", "%{guest_group}"]
>          include:
>           - linux
>          classes:
>           - webserver
>
> And this is exactly what I was needing.
>
> $ ./simple-node-classifier.py node2.mydomain.com
> ---
> classes: [webserver, generic_server]
> include: [linux]
> name: node2.mydomain.com
> parameters:
>  connect_allowed_groups: [group1, group3, guests]
>  guest_group: guests
>
> $ ./simple-node-classifier.py node1.mydomain.com
> ---
> classes: [generic_server, dbserver]
> include: [linux]
> name: node1.mydomain.com
> parameters:
>  connect_allowed_groups: [group1, group2, group3]
>  guest_group: guests
>
>
>
> Right now it reads from a plain YAML file, but I will add code to
> allow delegate the node queries to other external command. This will
> allow add inheritance support to other external nodes implementations
> easily.
>
> Actually, I will use plain YAML files for a time. I think that is easy
> to manage and convenient to have all this configuration in a yaml
> file. And I can add it to a CVS repository. Later import it to other
> system (like dashboard) would be easy.
>
> In fact, I recomend all new users to start working with plain YAML
> files and a script like this one as external node classifier.

Absolutely. It's really easy to write a node classifier. You can pick
any language you want, you can do it however you want, you just need
to supply appropriate output.

Nice work on the array appending solution you came up with.

-- 
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] certificate problem ; puppetca can't find cert request ?

[Daniel Maher]

Hello,

We recently re-deployed puppet certificates in our environment.  I 
removed and regenerated the certificates for all of the clients save for 
one : the puppetmaster server itself.


As one might expect, when i run puppetd --test on the puppetmaster 
server, i get :


err: Could not request certificate: Retrieved certificate does not match 
private key; please remove certificate from server and regenerate it 
with the current key


I removed /var/lib/puppet/ssl/certs/.pem , then ran 
puppetd with --waitforcert .  Unfortunately, when i 
run a puppetca --list --all ,  is not listed, even 
though there is very clearly a request pem in 
/var/lib/puppet/ssl/certificate_requests .


Executing puppetca --clean  removes the private key 
(as expected), but does not change the error condition.  I also tried 
puppetca --revoke  ; no change.


I also tried removing every instance .pem from 
/var/lib/puppet/ssl/* ; this also did nothing.  Finally, i saw that 
 was listed in only one spot : 
/var/lib/puppet/ssl/ca/inventory.txt .  Removing the line from this file 
also does nothing (as expected).


In the archives, one solution proposed for this problem is to rm -rf 
/var/lib/puppet/ssl and let puppet regenerate it all ; this is fine on 
the clients, i suppose, but i hesitate to do it on the puppetmaster, as 
i'd rather not have to start from scratch with the certificates of all 
the clients again.


I'm running puppet 0.25.5 on CentOS 5.5 x86_64.

Any ideas ?

Thank you all.


--
Daniel Maher 
"The Internet is completely over." -- Prince

--
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] Overwrite default settings in nodes using external nodes.

[Héctor Rivas Gándara]

>> We have simple inheritance in our external node classifier like this:
>> We only allow one level, and includes cannot include other includes.
>> Parameters specified in a node yaml override the same parameter in an
>> include yaml.
>> Oh, and we have a default node that all of this is appended to.
>> This is a really simple classifier, less than 100 lines of real code.
>
> I will try to do something like that.

I've just made a small python script that implements a simple external
node manager with inheritance support.

http://gist.github.com/604530

It allows define "includes" to other nodes/definitions in yaml by
adding classes named "external:" or adding a new attribute
"include". It resolves references to other parameters using the sintax
"%{parameter_name}".

This way you can use something like:

- name: server
  parameters:
   guest_group: "guests"
  classes:
   - generic_server

- name: linux
  parameters:
   connect_allowed_groups: [ "group1", "group2" ]
  classes:
   - external:server

- name: node1.mydomain.com
  parameters:
   connect_allowed_groups: [ "%{connect_allowed_groups}", "group3"]
  classes:
   - dbserver
   - external:linux

- name: node2.mydomain.com
  parameters:
   connect_allowed_groups:  ["group1","group3", "%{guest_group}"]
  include:
   - linux
  classes:
   - webserver

And this is exactly what I was needing.

$ ./simple-node-classifier.py node2.mydomain.com
---
classes: [webserver, generic_server]
include: [linux]
name: node2.mydomain.com
parameters:
  connect_allowed_groups: [group1, group3, guests]
  guest_group: guests

$ ./simple-node-classifier.py node1.mydomain.com
---
classes: [generic_server, dbserver]
include: [linux]
name: node1.mydomain.com
parameters:
  connect_allowed_groups: [group1, group2, group3]
  guest_group: guests



Right now it reads from a plain YAML file, but I will add code to
allow delegate the node queries to other external command. This will
allow add inheritance support to other external nodes implementations
easily.

Actually, I will use plain YAML files for a time. I think that is easy
to manage and convenient to have all this configuration in a yaml
file. And I can add it to a CVS repository. Later import it to other
system (like dashboard) would be easy.

In fact, I recomend all new users to start working with plain YAML
files and a script like this one as external node classifier.

--
Atentamente
Héctor Rivas

-- 
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: why does puppet shuffle its ‘ph ases’ and how can I stop this?

[D.N. van der Meijden]

Thanks for clearing this up!

On 27 sep, 17:27, Richard Crowley  wrote:
> > With very few exceptions (that are all made for time savings so you
> > can ignore them safely) all resources (what you were calling phases)
> > must explicitly declare their dependencies on other resources using
> > before and require [1] [2].
>
> s/before and require/before or require/

-- 
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] Cron Error Notification

[Felix Frank]

On 09/30/2010 02:36 PM, Jeff wrote:
> Hi Puppeteers,
> 
> I'd love to use puppet as a tool to manage cron jobs across the
> enterprise. Ideally, I'd like to chuck our expensive enterprise
> scheduling package. To do that, I need to get job failure
> notifications to the network operations center. Can someone suggest a
> way I can accomplish that?

Hi,

what's your specific problem with that? Cron generates mail with stdout
content automatically. Puppet can control target addresses without problems.

Sorry for the noise if your problem is more obvious than I realize.

Regards,
Felix

-- 
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] Cron Error Notification

[Jeff]

Hi Puppeteers,

I'd love to use puppet as a tool to manage cron jobs across the
enterprise. Ideally, I'd like to chuck our expensive enterprise
scheduling package. To do that, I need to get job failure
notifications to the network operations center. Can someone suggest a
way I can accomplish that?

Cheers,
Jeff

-- 
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-dashboard - where do I put the .htaccess file?

[Tim Lank]

puppet-users:

I've got puppet-dashboard 1.0.3-3 setup using the rpm from here:
http://yum.puppetlabs.com/base/

Everything seems to work fine using the instructions from here:
http://github.com/reductivelabs/puppet-dashboard

I'm trying to setup basic security with the .htaccess file described
in the Security section - item#3.

Where exactly do I need to put this?

Thanks in advance for your help.

-- 
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] Overwrite default settings in nodes using external nodes.

[Héctor Rivas Gándara]

> We have simple inheritance in our external node classifier like this:

Actually, yaml itself allows the definition of Relational Trees
(http://en.wikipedia.org/wiki/YAML#Relational_trees) that allow you to
do something like:

- &linux
  name: linux
  parameters:
one_parameter: "value1"
other_parameter: "value2"
  classes:
   - linuxserver


- <<: *linux
  name: server.domain.com
  environment: test
  parameters:
   another_parameter2: " y2 "
   txt_parameter3: " y3 "
   array_parameter1: [ " y_a_1.1 ", " y_a_1.2 " ]
   array_parameter2: [ " y_a_2.1 ", " y_a_2.2 " ]
   array_parameter3: [ " y_a_3.1-", " y_a_3.2 " ]
   array_parameter4: [ " y_a_4.1 ", " y_a_4.2 " ]
  classes:
   - linuxserver
   - webserver

But you can not extend "classes" since it is a attribute, not a dictionary.


> We only allow one level, and includes cannot include other includes.
> Parameters specified in a node yaml override the same parameter in an
> include yaml.
>
> Oh, and we have a default node that all of this is appended to.
> This is a really simple classifier, less than 100 lines of real code.

I will try to do something like that.

--
Atentamente
Héctor Rivas


>
>
> We only allow one level, and includes cannot include other includes.
> Parameters specified in a node yaml override the same parameter in an
> include yaml.
>
> Oh, and we have a default node that all of this is appended to.
>
> This is a really simple classifier, less than 100 lines of real code.
>
> >
> > Something like this:
> >
> >   - name: linuxserver
> >      parameters:
> >       connect_allowed_groups: ["group1", "group2"]
> >      classes:
> >       - linux
> >
> >   - name: node1.mydomain.com
> >      super: linux
> >      parameters:
> >       connect_allowed_groups: %{connect_allowed_groups}+["group3"]
> >
> >   - name: node2.mydomain.com
> >      super: linux
> >      parameters:
> >       connect_allowed_groups: ["group1", "group3"]
> >
> > This way we could easily implement inheritance in all external nodes
> > implementations.
> > --
> > Atentamente
> > Héctor Rivas
> >
> > --
> > 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.
>

-- 
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] Accumulating values

[タイ シー]

(Sorry, long post, and .. I'm replying via copy & paste from Google Groups)

On Wed, 15 Sep 2010 19:59:35 -0700 (PDT), Patrick wrote:
>Sounds like a job for Augeas or puppet-concat.  I think puppet_concat =
>would be a better fit.

>Augeas: http://docs.puppetlabs.com/references/stable/type.html#augeas

>puppet_concat: http://github.com/ripienaar/puppet-concat=


Thank you Patrick for the suggestions. 
I explored puppet_concat further, and found that it:
- Requires files to be split into several pieces to be useful i.e. the head, 
body, then tail.
- Leaves fragment files (turds?) on client filesystems, however 
well-categorized they may be.

So I became motivated to see if I could develop an improved solution that did 
the string processing server-side, then returned the finished results to the 
client.

I wrote a custom type (for Puppet 0.25.5) named "concat". In short, you can 
make line-based contributions scattered across many places, and the concat type 
will join them together with newlines and *somehow* make the resulting string 
available. My first use-case is configuring an SNMP daemon.

But it's incomplete:
- Resulting concatenated strings are not available from within the Puppet DSL.
- I'm not confident concatenation is being done before Puppet ultimately 
provides the resulting string values for use.

The code is at the bottom of this message.

Let's look at how to use it. Although unnecessary, I envisioned the resulting 
concatenated strings would be defined in arbitrary scopes, like this:

# In file modules/jvm/manifests/init.pp :
concat { "JVM SNMP":
variable => "snmp::snmpd_conf_contributions",
lines => "proxy -m ${mib_file} -v 2c -c ${snmp_community} localhost:1161 
.1.3.6.1.4.1.42.2.145" ,
before => Class["snmp"],
}

# In file modules/postgres/manifests/init.pp :
concat { "PostgreSQL postmaster SNMP":
variable => "snmp::snmpd_conf_contributions",
lines => "proc postmaster",
before => Class["snmp"],
}

In one ideal, the custom type would:
1. Gather all lines for each given distinct variable,
2. Perform concatenation, joining lines with UNIX newlines "\n" into a single 
string value, and
3. Set the appropriate variable in the appropriate scope to the final value

Continuing the above example, $snmp::snmpd_conf_contributions would have the 
value "proxy -m ${mib_file} -v 2c -c ${snmp_community} localhost:1161 
.1.3.6.1.4.1.42.2.145\nproc postmaster". Note that the lines could be reversed; 
this implementation doesn't consider the order of multiple concat resources, 
but if the lines param is an array, order within that array is preserved.

Now, the value could be used:

# In file modules/snmp/manifests/init.pp:
file { "/etc/snmpd.conf":
content => "blah blah\n<%= snmpd_conf_contributions %>\nblah blah", # 
Easily extends to the use of template()
}

# Or, using some mechanism from within an ERB document:
<%= concatenated_value('snmpd_conf_contributions') %>

Well, even after studying type.rb, scope.rb, setvar.rb, and friends, I don't 
know how to finish the implementation.

Given my current level of understanding, this is about as far as I can take the 
code today.
Any hints, suggestions, ideas? Even without scoping? Can this be made to work 
at all?
Better yet, I hope some enterprising soul takes it from here ^_^

Ty

* I sense that modifying variable values, or appending to the value of 
variables out-of-scope, might be perceived as being counter to the spirit of 
Puppet. But this approach would cause me less pain and give greater control 
over the contents of configuration files in a way Augeas & other methods don't. 
Although, it might all be subjective, or I might be missing something .. It 
might even be a Bad Idea.

 8<  modules/common/lib/puppet/type/concat.rb  8< 

module Puppet

# Note: The following global variables cause namespace pollution

$concat_raw_map = {} # Maps identifiers to arrays of a mix of strings and 
arrays of strings
$concat_processed_map = {} # Maps identifiers to each of their final string 
representations

$concat_finalized = false
$concat_instance_count = 0
$concat_total_rule_count = 0

newtype(:concat) do
@doc = "Sets the string value of *TODO* to the concatenation of all
contributors. With multiple concat resources, order of 
appearance in the
final concatenated string is unspecified. Multiple content 
values are
concatenated by being joined together with UNIX newline \\n 
characters.
The implementation is partially patterned after iptables.rb."

newparam(:name) do
desc "The name of this concat resource. Does not influence 
concatenation behavior."
isnamevar
end

newparam(:variable) do
desc "Content is concatenated to the value of this variable 
identifier, typed as a string."
end

newparam(:lines) do
desc "A string, or an array of 

Re: [Puppet Users] Re: Setup 2.6 + apache, passenger

[Gavin]

On 30 September 2010 05:26, Nigel Kersten  wrote:
>
> We should be shipping the correct config.ru for you in the 2.6.x
> Debian packages. Did that not work?

Hi Nigel,

Yes, I got the new config.ru file with the Debian package, my mistake
was starting off with the Lenny packages then trying to selectively
install puppet and it's dependencies from the 'testing' branch.

I got fed up and uninstalled puppet and it's dependencies completely,
upgraded the entire server to testing, and installed puppet again.

All started working perfectly after that.

Thanks to all for the help and advice!!

Regards,
Gavin

-- 
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] mount type attempting remount when ensure => present

[Felix Frank]

On 09/30/2010 08:57 AM, John Warburton wrote:
> Hi All
> 
> I am not sure if I am doing this right, or just meeting some Solaris
> specific thing that hasn't been catered for.
> 
> Solaris 10, with puppet 0.25.5, and trying to manage /tmp. Note that /tmp
> can't be remounted on a live system (
> http://wikis.sun.com/display/BigAdmin/Talking+about+RAM+disks+in+the+Solaris+OS
> )
> 
> mount{ "/tmp":
> atboot  => "yes",
> device  => "swap",
> ensure  => present,
> pass=> "-",
> fstype  => "tmpfs",
> options => "size=4096m",
> }
> 
> Changes /etc/vfstab as expected, but yields this error:
> 
> err: //solaris/Mount[/tmp]/ensure: change from mounted to present failed:
> Execution of '/usr/sbin/umount /tmp' returned 1: umount: /tmp busy
> 
> notice: //solaris/Mount[/tmp]: Refreshing self
> info: Mount[/tmp](provider=parsed): Remounting
> err: //solaris/Mount[/tmp]: Failed to call refresh on Mount[/tmp]: Execution
> of '/usr/sbin/umount /tmp' returned 1: umount: /tmp busy
> 
> Seems that ensure => present (Set to present to add to fstab but not change
> mount/unmount status) is being overridden by the fact the provider is deemed
> refreshable.

I noticed similar behaviour in Linux, with catastrophic results.
Ensure => present apparently always means "in fstab, but not mounted",
which not only doesn't make much sense to me, but led me to never use
any ensure setting besides "mounted".

Regards,
Felix

-- 
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] Installing puppet 0.25.5 on SLES 9 64bit

[Sandor Szuecs]

On Sep 29, 2010, at 3:45 PM, Christian wrote:

> /usr/sbin/puppetd:159:in `require': No such file to load -- puppet/
> application/puppetd (LoadError)
>from /usr/sbin/puppetd:159
> 
> What went wrong here? Is there a bug in the rpm? Or do i have to set a
> path somewhere?

It seems you have to set the ruby loadpath, $:, yourself to the folder 
where the files puppet.rb and facter.rb are. 
You can add a load path with `ruby -Ipath/to/load` or add it to GEM_PATH 
env variable. You can add a path to $GEM_PATH separated with ':', like 
bash/zsh $PATH.


All the best, Sandor Szücs
--



-- 
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] Foreman barfs on startup.

[Ohad Levy]

Doug,

This was already fixed, but there was no official release since then.
You can either -
1. wait until a new version is released.. probably in 10 days to two weeks
time frame.
2. use the nightly snapshot, or directly from github (
http://theforeman.org/projects/foreman/wiki/Installation_instructions).

There probably going to be a RC before that, probably in an RPM format as
well.

Ohad
On Wed, Sep 29, 2010 at 11:44 PM, Douglas Garstang
wrote:

> All,
>
> First attempt at running foreman.
>
> [pax] prov01 /usr/share/foreman/script:# ./server -e production
> => Booting WEBrick
> => Rails 2.3.5 application starting on http://0.0.0.0:3000
> /usr/share/foreman/vendor/rails/activesupport/lib/active_support/dependencies.rb:443:in
> `old_load_missing_constant': uninitialized constant Puppet::Rails
> (NameError)
> from
> /usr/share/foreman/config/initializers/fix_already_loading_missing_dependencies.rb:9:in
> `load_missing_constant'
>  from
> /usr/share/foreman/vendor/rails/activesupport/lib/active_support/dependencies.rb:80:in
> `const_missing'
> from /usr/share/foreman/config/initializers/puppet.rb:1
>  from
> /usr/share/foreman/vendor/rails/activesupport/lib/active_support/dependencies.rb:147:in
> `load_without_new_constant_marking'
> from
> /usr/share/foreman/vendor/rails/activesupport/lib/active_support/dependencies.rb:147:in
> `load'
>  from ./../config/../vendor/rails/railties/lib/initializer.rb:622:in
> `load_application_initializers'
> from ./../config/../vendor/rails/railties/lib/initializer.rb:621:in `each'
>  from ./../config/../vendor/rails/railties/lib/initializer.rb:621:in
> `load_application_initializers'
>  ... 9 levels...
>  from /usr/share/foreman/vendor/rails/railties/lib/commands/server.rb:84
> from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
> `gem_original_require'
>  from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in
> `require'
> from ./server:3
>
> As per:
> http://theforeman.org/projects/foreman/wiki/Installation_instructions
>
> installed:
> foreman-0.1.5-1
> rubygem-rack-1.0.1-1
>
> 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-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.