Re: [Puppet Users] Update time in template file.

[Alan Barrett]

On Sun, 19 Dec 2010, Stefan Schulte wrote:
> If you really depend on your headerline consider the following: Don't
> use Time.now but use something like
> File.stat('/etc/puppet/modules/snmp/template/snmp.conf.erb').mtime.gmtime
> [Maybe theres a way to address the filename from the template itself,
> but I havent figured that out; __FILE__ and ARGV are not working]

Feature request #4359 asks for a way that templates can get their own
name.  It's not possible at the moment.

--apb (Alan Barrett)

-- 
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: Exit gracefully

[donavan]

On Dec 21, 4:38 pm, Douglas Garstang  wrote:
> I'd like to be able to put specific modules into 'maintenance' mode if a
> variable has been set. I can check the variable, but the only way I can see
> to have puppet skip processing is to use the fail() function, which stops
> everything with a nasty error message. Is there a return() function or
> similar???
>
> Doug.

There's no way to 'uninclude' a class once it's in the catalog. I'd
probably do this with an include one level up which determines whether
to do the work or not. Does this example make sense?

class service1 {
if $service1_state == "enabled" {
include service1::enabled
} else {
maintenance{ $name: } # $name refers to the class, issue #1104
}
}
class service1::enabled {
# Do actual work here
service { "service1": enabled => true }
}
# just a cheap wrapper to log on both client and server
define maintenance($message="in maintenance mode") {
notify{
"$name": loglevel => 'warning', message => "$name $message"
}
warning("$name $message")
}

-- 
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: run without puppet master

[donavan]

On Dec 20, 6:51 am, aaron prayther  wrote:
>
> does anyone have any examples of a "disconnected" configuration, not using a
> puppet master?
>


Aaron,

I know Jordan Sissel[1] runs his deployment very muhc like this.
There's no central puppet master, but packages that install/enforce a
particular configuration. As I recall he has a minimal 'base' set that
is responsible for ensuring a sane puppet environment, self updating,
etc.  Most of the traditional configuration is then managed in a
'content' set.

One immediate difference is that he's trusting the clients to define
which configuration is applied. It sounds like in your instance you'll
have a 'base' catalog with no per node definitions instead.

Matt Robinson also made a very interesting feature[2]. It uses a
puppet master to compile the clients catalog, but then packages the
catalog and all required resources in to a discrete tar file. The tar
is unpacked on the client then applied with a stand alone 'puppet
apply' run. As I recall this feature was actually created for a secure
environment where data had to be physically distributed on media.

Your use case could certainly package & version these complete catalog
sets using RPMs instead of tar.


[1] http://www.semicomplete.com/
[2] https://github.com/puppetlabs/puppet-compile-catalog-with-files

-- 
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: Yum Repos - Best Practice?

[DaveQB]

A less elegant way, but an alternative is to simply have a *.repo file
per use case (if you don't have too many) and simply include that file
in the class or node that needs it.


On Dec 21, 4:07 am, Felix Frank 
wrote:
> On 12/20/2010 07:26 PM, Matthew Macdonald-Wallace wrote:
>
>
>
> > Hi all,
>
> > I'm wondering how other people mange yum repositories using the yumrepo
> > type.
>
> > At the moment, we have a class called "repos" which has all of our repos
> > defined in it.
>
> > This class is included in our 'base' class which sets up things common
> > to all servers such as puppet, mcollective, nrpe etc.
>
> > The down side of this is that all of our repos are included on all of
> > our servers, leading to a complete mess in /etc/yum.repos.d/
>
> > I'm now thinking that I need to only call in the various repos for the
> > servers which require them, i.e. CentosBase and others would be included
> > in the 'base' class, however those which provide things such as php 5.3
> > would only be included on webservers etc.
>
> > What would be even nicer would be if there was a way to override certain
> > aspects of existing repos, for example:
>
> > class base{
> > # other yumrepo defines...
> > ...
> > ...
>
> > # stick with the php 5.1 in Centos Base
> > yumrepo{"epel":
> >         excludepkgs=>"php*",
> > }
>
> > }
>
> > class webserverphp52 {
> > # include php5.2 from epel
> >         yumrepo{"epel":
> >                 excludepkgs => "",
> >         }
> > }
>
> Hi,
>
> I'm not using yum, but this looks like a use case for either or both of
> virtual resources and inheritance:
>
> class yumrepos { # included by each and every node
>   @yumrepo {
>     "one": ...;
>     "two": ...;
>     ...
>     "epel": excludepkgs=>"php*", ...;
>   }
>
> }
>
> class base_repos { # also included by all (?)
>   realize(Yumrepo["foo", "bar"])
>
> }
>
> class php_repos {  # only for those who want
>   realize(Yumrepo["epel"])
>
> }
>
> class yumrepos_epel_enable_php inherits yumrepos {
>   Yumrepo["epel"] { excludepkgs => "" }
>
> }
>
> So your webserver class will probably
> include php_repos
> include yumrepos_epel_enable_php
> to get (in addition to the base repos) epel and include epel's PHP packages.
>
> HTH,
> 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] filebucket questions

[Nicolas Aizier]

Hi everyone,

I've got several questions that are most probably obvious to some of
you but I'm actually a bit 'in the fog' about filebucket.

backup are done on a md5 basis so 1 file is generated whatever the
number of clients if it's the same md5. That a really good option.
On the other hand let's say that after 3 months I need to restore a /
etc/ntp.conf file for a specific server. How the hell I know the old
file md5 checksum ?
I'm actually using puppet dashboard and I'll not open all the reports
to find the md5 checksum, and as the file might have been taken from
another server perhaps the checksum didn.t even appear in the server
reports 

Hope you see my point. From my actual point of view it's a great
backup tool but restoring seems a bit tricky. But I'm sure someone
will enlighten my soon since everything is really good in puppet so I
guess problem come from me as usual ;-)

cheers !

-- 
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: client won't use remote file bucket

[Nicolas Aizier]

Oh my bad, I just realize that is is backuping by md5  so one
backup to rule them all 
Stupid me, forget about that. It's working fine.

On Dec 22, 12:41 pm, Nicolas Aizier 
wrote:
> Hi all,
>
> this solve the issue for me also but now even if it still do backup
> in /var/lib/puppet/bucketit doesn't mention it in the report ?
> Before that "path => false" line it was mentionning it but not doing
> it .
>
> Strange isn't it ?
>
> On Nov 23, 7:13 pm, Mikael Fridh  wrote:
>
>
>
>
>
>
>
> > On Nov 19, 10:56 am, Felix Frank 
> > wrote:
>
> > > On 11/19/2010 10:15 AM, luke.bigum wrote:
>
> > > > Felix,
>
> > > > That fixes the problem, my remotefilebucketnow works. I'll raise a
> > > > bug for this.
>
> > Fixes it for me as well, thanks!
>
> > --
> > Mikael

-- 
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: client won't use remote file bucket

[Nicolas Aizier]

Hi all,

this solve the issue for me also but now even if it still do backup
in /var/lib/puppet/bucket it doesn't mention it in the report ?
Before that "path => false" line it was mentionning it but not doing
it .

Strange isn't it ?

On Nov 23, 7:13 pm, Mikael Fridh  wrote:
> On Nov 19, 10:56 am, Felix Frank 
> wrote:
>
> > On 11/19/2010 10:15 AM, luke.bigum wrote:
>
> > > Felix,
>
> > > That fixes the problem, my remote file bucket now works. I'll raise a
> > > bug for this.
>
> Fixes it for me as well, thanks!
>
> --
> Mikael

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

[Douglas Garstang]

I'd like to be able to put specific modules into 'maintenance' mode if a
variable has been set. I can check the variable, but the only way I can see
to have puppet skip processing is to use the fail() function, which stops
everything with a nasty error message. Is there a return() function or
similar???

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.

Re: [Puppet Users] Re: Recent (unfun) experience with cron resource on Solaris 10 with puppet 0.25.5

[Brian Gallew]

In general, "cron != vixie-cron".  It turns out that most of the Unix world
pre-dates Linux and for various reasons (not the least of which are legal
issues, branding, and in-product compatibility) it is generally *extremely*
poor form to assume Linux-isms.  Clearly, the cron provider should be
updated to reflect this reality.  Perhaps filing a bug report is in order?

On Sat, Dec 18, 2010 at 11:02 AM, russell.fulton
wrote:

> little historical note for the record
>
> Solaris cron is old -- system V or BSD 4.2.  Most (all ?) Linux
> distros  and modern *BSDs use Paul Vixie's Cron which has all the
> flexibility that we know and love.
>
> I suspect that AIX will be similar to Solaris -- painful.
>
> Russell
>
> --
> 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] foreman issue

[Brian Gallew]

Foreman's report agent, for some reason, doesn't update as many of the
Foreman DB fields as one might wish.  I submitted a patch on this, but as
Mark pointed out, the approved way to do this is to run a rake periodically
to re-import all of the reports and/or classes.

If you are interested in hacking it for yourself, you should look at
app/models/report.rb.  You'll specifically be looking at self.import(yaml).
Here is the meat of my patch:

host.environment =
Environment.find_or_create_by_name(host.fv(:environment))
host.hostgroup =
Hostgroup.find_or_create_by_name(host.fv(:cprt_globalzone))
host.architecture =
Architecture.find_or_create_by_name(host.fv(:hardwareisa))

val = host.fv(:productname)
val = host.fv(:virtual) if val == nil
host.model = Model.find_or_create_by_name(val)

major, minor = host.fv(:operatingsystemrelease).split(".",2)
v = Operatingsystem.first(:conditions => "name =
\"#{host.fv(:operatingsystem)}\" and major = \"#{major}\" and minor =
\"#{minor}\"")
if v
  host.os = v
else
  host.os = Operatingsystem.create({:name =>
host.fv(:operatingsystem),
 :major => major,
 :minor => minor})
end

host.puppetclasses = host.fv(:cprt_classes).split(',').map() do |c|
  Puppetclass.find_or_create_by_name(c)
end



On Mon, Dec 20, 2010 at 5:05 AM, Mark Stanislav wrote:

> You need to run the rake again. Setup a cronjob to execute it every so
> often if you need new hosts regularly (e.g. Auto scaling)
>
> -Mark
>
>
>
> On Dec 20, 2010, at 6:58 AM, walexey  wrote:
>
> > Hello!
> > I try to use foreman. It's successfuly import current nodes from
> > puppet storeconfig. Nodes hostname stored in short form, without
> > domain.
> > After that, i run puppet on newly  created additional 5 nodes. They
> > shows in foreman with full fqdn. Os, environment, architecture for
> > this nodes not shown.
> > How can i fix this issue?
> >
> > --
> > 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.
>
>

-- 
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: "# Only restart if we're actually running"

[Craig Miskell]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick Moffitt wrote:
> Bill Proud:
>> I would have thought that the simplest solution would be to not use a
>> service at all but instead notify an exec from the file resource for
>> the configuration.  The exec could run a simple script that checks if
>> the application is running and restarts it if it is.
> 
> The trouble with execs is that they're so open-ended that a "puppet
> agent -t --noop" can't predict what will happen after one occurs.  With
> a service it can at least assume that the refresh happened successfully
> and any notifications can trickle onward from there.  With an exec it
> just says "um, except now we're noop.  You're on your own from here,
> mate."  It's like that old usenet rant about "given what you just did,
> it's perfectly within spec for the compiler to make demons fly out your
> nose!"  Anything at all could happen!
> 
> I feel like execs are something of a misfeature, but I'd be hard pressed
> to figure out how to live completely without them.  I'm glad I have them
> available to do things like generate quick unique ssl snakeoil
> certificates or ssh keys, but I would hate to rely on them for something
> as central as the service resource.

In that case, how about modifying the /etc/init.d/ script (assuming Linux
and a standard sort of init.d script here) that does the restart and/or status
check to behave differently in the two different cases.

In the case of a crashed/dead app, the PID file will exist, but there won't be a
process on that PID (or rather, there won't be a correctly named process with
that PID).  That's a dead app, so don't restart even if Puppet (or anyone else)
asks you to.

If there *is* an app at that PID, then the app is running and needs to be
restarted/reloaded as requested.

- --
Craig Miskell
Senior Systems Administrator
Opus International Consultants
Phone: +64 4 471 7209
OpenVMS: The OS with uptimes longer than MS Windows support policies
  -- Browser window title of the www.openvms.org website
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAk0Q/0IACgkQmDveRtxWqnY7RwCghes4alH1WCDzFXFGVuYYUEPX
b9sAoKCOCJQHbfi5JIb4DQh/rPmt0X2V
=qOXR
-END PGP SIGNATURE-

-- 
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] module critique request

[deet]

  Hello.
  I recently tried to improve a module I have which is used to create
one or more instances of mysql per node.  The original module had
lot's of code repetition to get around gaps in my skills.   The new
improved module has less code repetition but doesn't seem as clean as
I imagined it in my head:)

  The env is puppet 2.6.4, facter 1.5.8, solaris 10 x86 and nodes.pp
files not external nodes.

   I still find myself thinking shell scripting and not managed
resources.   So while the module does what I want it to I would
appreciate any feedback to help me stay in line with good practices
and approaching the problem in a more puppet like fashion.

   I put the module at https://github.com/someword/mysql-module and
included an example-nodes.pp file in the top level which illustrates
what a node would look like.

   The three key areas where I feel could be improved are:

1.  In the mysql::instance define the use of an "if/elsif/else" clause
to decide which version class to load to get the particular variables
for that version.
When i used the notation
include "mysql::$major"

the right class got included but the variables set in their were
not readily available for use in the mysql::instance define.   Also I
tried calling mysql::$major { "$instance": } but that failed syntax
checking.

2.  It's possible for 2 mysql instances on one node to use the same
version of software which causes duplicate resources.  To get around
this I used an if statement in the package.pp manifest to check if the
resource is defined so that it wouldn't get duplicated.  Having to
take this step makes me think I'm not doing something correctly.

3.  Resource ordering.
  I rely on alot of resource ordering to ensure the correct
application of resources.  I'm wondering if their are cleaner/better
approaches to ensure the desired ordering with out explicitly stating
them.

  Any input to help broaden my puppet horizons is welcome.
  TIA.  deet.

-- 
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: lsbmajdistrelease fact

[Arnau Bria]

Thanks to both..

> redhat-lsb

seems trivial now... an hour looking for diff and it was so easy...

thanks again!
Arnau

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

Re: [Puppet Users] Re: lsbmajdistrelease fact

[R.I.Pienaar]

- Original Message -
> On Tue, 21 Dec 2010 17:02:20 +0100
> Arnau Bria wrote:
> 
> > Hi all,
> >
> > I've noticed that facter version superior from epel do not
> > display lsbmajdistrelease fact:
> Sorry for the noise, that's not true.
> 
> it works in some systems and it doesn't in others. I'm sure I have
> some
> diff between systems, so, I have to change my question: anyone could
> tell me what package could be causing this diff behaivour between
> hosts?

redhat-lsb

-- 
R.I.Pienaar

-- 
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: lsbmajdistrelease fact

[Daniel Piddock]

On 21/12/10 17:48, Arnau Bria wrote:
> On Tue, 21 Dec 2010 17:02:20 +0100
> Arnau Bria wrote:
>
>> Hi all,
>>
>> I've noticed that facter version superior from epel do not
>> display lsbmajdistrelease fact:
> Sorry for the noise, that's not true.
>
> it works in some systems and it doesn't in others. I'm sure I have some
> diff between systems, so, I have to change my question: anyone could
> tell me what package could be causing this diff behaivour between hosts?

On Debian systems you need to specifically install the lsb-release
package, which provides the lsb_release command.

lsb_release is provided by redhat-lsb under Fedora (which is installed
by default.)

HTH

Dan

-- 
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: lsbmajdistrelease fact

[Arnau Bria]

On Tue, 21 Dec 2010 17:02:20 +0100
Arnau Bria wrote:

> Hi all,
> 
> I've noticed that facter version superior from epel do not
> display lsbmajdistrelease fact:
Sorry for the noise, that's not true.

it works in some systems and it doesn't in others. I'm sure I have some
diff between systems, so, I have to change my question: anyone could
tell me what package could be causing this diff behaivour between hosts?

TIA,
Arnau

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

Re: [Puppet Users] "# Only restart if we're actually running"

[Nigel Kersten]

On Tue, Dec 21, 2010 at 12:14 AM, Nick Moffitt  wrote:

> Nigel Kersten:
> > Can you use the "basic" service provider with fully-specified
> > start/stop/restart commands to achieve what you need?
>
> Are you suggesting that I override the start command to a noop, and make
> sure the restart command works in that scenario?  Thinking that over, it
> has potential.  I suppose it would refrain from starting a crashed
> service, but it would pass the test in type/provider.rb that's been
> causing me grief:
>
># Basically just a synonym for restarting.  Used to respond
># to events.
>def refresh
>  # Only restart if we're actually running
>  if (@parameters[:ensure] || newattr(:ensure)).retrieve == :running
>provider.restart
>  else
>debug "Skipping restart; service is not running"
>  end
>end
>
> I think I'll continue to use the fully-specified provider to gain the
> enablement features among other things.
>
> Thank you, that seems eminently sensible!
>

I guess I'm suggesting that you come up with a set of commands for
start/stop/restart that gives you the behavior you want. I'd try and see if
you can achieve this with provider => basic, and if you can, you can then
either:

* write a defined DSL type that abstracts away the complexity in the
commands you're specifying.
* write a native Ruby provider that does the same thing, deliver with
pluginsync.

The first is quicker to scaffold, but means you won't be using "service"
anymore for each resource instance, the second will be a matter of
specifying a specific provider with each "service" resource instance, or as
a resource default.


> --
> You are not entitled to your opinions.
>
> --
> 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] "# Only restart if we're actually running"

[Nick Moffitt]

Nick Moffitt:
> Are you suggesting that I override the start command to a noop, and make
> sure the restart command works in that scenario?  Thinking that over, it
> has potential.  I suppose it would refrain from starting a crashed
> service, but it would pass the test in type/provider.rb that's been
> causing me grief:
> 
> # Basically just a synonym for restarting.  Used to respond
> # to events.
> def refresh
>   # Only restart if we're actually running
>   if (@parameters[:ensure] || newattr(:ensure)).retrieve == :running
> provider.restart
>   else
> debug "Skipping restart; service is not running"
>   end
> end

Unfortunately that doesn't seem to work:

notice: 
/Stage[main]/Haproxy::Config/File[/etc/default/haproxy]/content: content 
changed '{md5}a1f2deb7c7a10e55dc7c971a2288f5d4' to 
'{md5}9854e65621b62147b91ebc2c02cce1c2'
notice: /Stage[main]/Haproxy::Config/File[/etc/default/haproxy]/mode: 
mode changed '644' to '444'
info: /Stage[main]/Haproxy::Config/File[/etc/default/haproxy]: 
Scheduling refresh of Service[haproxy]
info: /Stage[main]/Haproxy::Config/File[/etc/default/haproxy]: 
Scheduling refresh of Service[haproxy]
debug: Service[haproxy](provider=debian): Executing 
'/etc/init.d/haproxy status'
debug: Service[haproxy](provider=debian): Executing '/bin/true'
notice: /Stage[main]/Haproxy::Service/Service[haproxy]/ensure: ensure 
changed 'stopped' to 'running'
debug: Service[haproxy](provider=debian): Executing 
'/etc/init.d/haproxy status'
debug: /Stage[main]/Haproxy::Service/Service[haproxy]: Skipping 
restart; service is not running
notice: /Stage[main]/Haproxy::Service/Service[haproxy]: Triggered 
'refresh' from 4 events


So it really is checking the currently-running status of the service,
and not whether you have set ensure => running.  And this happens up in
the type code, well outside the provider's bailiwick.  I'm rather
disappointed.  

Nearly every init script I use will start a downed service if you run
/etc/init.d/foo restart (often by running an unneeded stop, followed by
a start), but it seems that Puppet has engineered the service type not
to follow this behavior.

Of course I could override the status command to /bin/true as well, but
that saddens me greatly:

info: /Stage[main]/Haproxy::Config/File[/etc/haproxy/haproxy.cfg]: 
Scheduling refresh of Service[haproxy]
info: /Stage[main]/Haproxy::Config/File[/etc/haproxy/haproxy.cfg]: 
Scheduling refresh of Service[haproxy]
debug: Service[haproxy](provider=debian): Executing '/bin/true'
debug: Service[haproxy](provider=debian): Executing '/bin/true'
debug: Service[haproxy](provider=debian): Executing 
'/etc/init.d/haproxy restart'
notice: /Stage[main]/Haproxy::Service/Service[haproxy]: Triggered 
'refresh' from 4 events

I suppose if I'm only interested in unconditional restarts and
enablement, neutering the status command is probably not that diastrous.
It just seems a bridge too far to me, somehow.  Still, I guess that's
the path I'm taking now.

-- 
BitKeeper, how quaint.
-- Alan Cox

-- 
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: puppetmasterd --compile: repeatable YAML output?

[Chris May]

Perfect - that's exactly what I needed.  Thanks!

Chris


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

[Arnau Bria]

Hi all,

I've noticed that facter version superior from epel do not
display lsbmajdistrelease fact:

# facter lsbmajdistrelease
5
# rpm -qa|grep facter
facter-1.5.5-1.el5
# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.5 (Tikanga)



# facter lsbmajdistrelease
#  cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
# rpm -qa|grep facter
facter-1.5.8-1.el5 

package from
http://download.fedora.redhat.com/pub/epel/5/x86_64/facter-1.5.8-1.el5.noarch.rpm


I've looked at bugtracker and seen no ref to this behaviour ... am I
doing something wrong? is it a real bug?


TIA,
Arnau

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

[Puppet Users] Re: puppetmasterd --compile: repeatable YAML output?

[deet]

 Failing
> that, does anyone have a recommendation for a "YAML diff" tool that can show
> substantive differences between the compiled manifests ?

  Chris.
  We are doing a big refactor and migration from .25 to 2.6.  I just
started looking into using https://github.com/ripienaar/puppet-catalog-diff
to do some catalog comparisons before I roll out the upgraded puppet/
manifests.
  This sounds pretty close to what your looking for.
  HTH.  Derek.

>
> Cheers,
>
> Chris

-- 
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] puppetmasterd --compile: repeatable YAML output?

[Chris May]

Hi all,

I've recently started using "puppetmasterd --compile" to validate changes to 
my manifests before I push them out onto the puppetmaster, which is a great 
help in spotting syntax errors, missing resources and the like.

However, something I'd really like to be able to do, is to make a change 
which _should_ have no effect on the manifest for a particular node, and 
verify that it _does_ have no effect. This is hard to do at present, because 
the ordering of elements inside the generated YAML is unpredictable - it 
appears to change even between subsequent runs of an identical manifest, and 
certainly between runs where the manifest has changed due to a 
side-effect-free refactoring. This means that text-based diffing of the 
generated YAML doesn't work.

Is there a way to force a consistent order on the generated YAML? Failing 
that, does anyone have a recommendation for a "YAML diff" tool that can show 
substantive differences between the compiled manifests ?

Cheers,

Chris


-- 
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] RFC: Puppet Docs

[Felix Frank]

On 12/21/2010 03:55 PM, Michael Stahnke wrote:
> One of the questions I have is who do you expect to work on
> documentation?  If you really expect developers to do it primarily,
> then having it in the code repository is fine.  If you want
> tech-writers, or users who might be a little more scared of working
> with the code in puppet proper, having it separate may encourage more
> contributions.  It can be a bit daunting to a person just getting
> started in open source to have to create a branch, send a patch,
> rebase etc to get a typo fixed.  It's not all-together easier in a
> separate repository, but the speed at which things change is different
> so rebases, and such may be easier or less scary.
> 
> That being said, for me it doesn't make much of difference.  Having
> one more repository to work in out of the dozens I spend time doesn't
> really add incremental cost.

The use of the main repository still allows for documentation bugs to be
filed, no?

No need for the user to clone any repo, or is the intent indeed to make
the users submit per patch only?

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] Re: puppet 2.6.3 (kick.rb) error after install

[ed ruk]

Puppet not supporting Ruby 1.9 caught me out too. I am just evaluating
whether Chef or Puppet will work best for my setup.

Puppet was definitely the simplest solution of the two to get up and
running on an old dev box ( which uses Ruby 1.8.7 ) , but then fell
over as soon as I tried the manifest file on a production box ( all
Ruby 1.9.2 ).

Any roadmap for how soon Ruby 1.9.2 support will come or a git branch
I can perhaps use in the meantime ?


On Nov 30, 7:57 pm, Nigel Kersten  wrote:
> On Tue, Nov 30, 2010 at 11:54 AM, monte  wrote:
> > Hello, I've just installed Ruby, Facter and Puppet from source
> > (versions listed below) and am getting the following error, when
> > trying to run Puppet 2.6.3:
>
> > [r...@localhost puppet]# ruby --version
> > ruby1.9.2p0 (2010-08-18 revision 29036) [i686-linux]
>
> Puppet doesn't support Ruby1.9yet.
>
>
>
>
>
> > [r...@localhost puppet]# ruby -ropenssl -e "puts :installed"
> > installed
> > [r...@localhost puppet]# ruby -rxmlrpc/client -e "puts :installed"
> > installed
> > [r...@localhost puppet]# facter --version
> > 1.5.8
> > [r...@localhost puppet]# puppet --version
> > /usr/local/lib/ruby/site_ruby/1.9.1/puppet/util/log/destinations.rb:
> > 97: warning: class variable access from toplevel
> > /usr/local/lib/ruby/site_ruby/1.9.1/puppet/application/kick.rb: /usr/
> > local/lib/ruby/site_ruby/1.9.1/puppet/application/kick.rb:107: Invalid
> > next (SyntaxError)
>
> > I've looked around and have not seen other posts regarding this so
> > either I'm missing something or no one has installed the newest
> > packages from source yet (I doubt that).  Please advise, thank you.
>
> > --
> > 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 Kersten - Puppet Labs -  http://www.puppetlabs.com

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

Re: [Puppet Users] RFC: Puppet Docs

[Michael Stahnke]

One of the questions I have is who do you expect to work on
documentation?  If you really expect developers to do it primarily,
then having it in the code repository is fine.  If you want
tech-writers, or users who might be a little more scared of working
with the code in puppet proper, having it separate may encourage more
contributions.  It can be a bit daunting to a person just getting
started in open source to have to create a branch, send a patch,
rebase etc to get a typo fixed.  It's not all-together easier in a
separate repository, but the speed at which things change is different
so rebases, and such may be easier or less scary.

That being said, for me it doesn't make much of difference.  Having
one more repository to work in out of the dozens I spend time doesn't
really add incremental cost.



stahnma

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

Re: [Puppet Users] how to disable runinterval option

[Mark Stanislav]

I believe Stefan's answer is probably the correct one if you really need/want 
the service still enabled (for perhaps puppetrun). Alternatively you could 
disable the Puppet service altogether and utilize mCollective or otherwise it 
initiate runs manually when needed. There is also a Puppet Commander plugin for 
mCollective you may want to look at 
http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/ToolPuppetcommander

A second route to this would be setting runinterval to a large enough amount of 
seconds that it makes the runinterval essentially moot.

-Mark

On Dec 21, 2010, at 9:00 AM, Stefan Schulte wrote:

> On Tue, Dec 21, 2010 at 01:50:00AM -0800, sanjiv.singh wrote:
>> 
>> hi all ,
>>i  want to disable  runinterval option on  puppetd .
>> as i know , after every  1800 sec.( 30 mins)  , puppet client  pull
>> configuration  from  puppet master .
>> 
>> I want configuration to be pushed to puppet client
>> when i wwould  fire  puppetrun  on puppet master rather than after
>> every 30 min , configuration pulled puppet client.
>> 
>> 
>> runinterval  :How often puppetd applies the client configuration; in
>> seconds.
>> �· Default: 1800
>> 
>> 
>> how can I do this ?
>> where do i need to change in  puppet configuration?
>> 
> 
> I just ran pupet agent --help and this one looks pretty good to me
> 
> no-client:  Do not create a config client. This will cause the
>daemon to run without ever checking for its
>configuration automatically, and only makes sense
>when used in conjunction with --listen.
> 
> Never tried it though.
> 
> -Stefan

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

Re: [Puppet Users] how to disable runinterval option

[Stefan Schulte]

On Tue, Dec 21, 2010 at 01:50:00AM -0800, sanjiv.singh wrote:
> 
> hi all ,
> i  want to disable  runinterval option on  puppetd .
> as i know , after every  1800 sec.( 30 mins)  , puppet client  pull
> configuration  from  puppet master .
> 
> I want configuration to be pushed to puppet client
> when i wwould  fire  puppetrun  on puppet master rather than after
> every 30 min , configuration pulled puppet client.
> 
> 
> runinterval  :How often puppetd applies the client configuration; in
> seconds.
> �· Default: 1800
> 
> 
> how can I do this ?
> where do i need to change in  puppet configuration?
> 

I just ran pupet agent --help and this one looks pretty good to me

no-client:  Do not create a config client. This will cause the
daemon to run without ever checking for its
configuration automatically, and only makes sense
when used in conjunction with --listen.

Never tried it though.

-Stefan


pgp8SPOsOJs8O.pgp
Description: PGP signature

Re: [Puppet Users] [puppet-users] run without puppet master

[aaron prayther]

Actually CLIP is exactly what i am using and we have stripped out all but
the CLIP puppet content and have started modifying that to better adhere to
STIG.

what i'm trying to understand now is a good way to structure puppet content
to now go beyond STIG and add host and application level puppet content in a
flexible/scalable way.

we host what we are calling SLIM (SPAWAR Linux Installation & Management) at
software.forge.mil/DoDBastille and this question of how to structure puppet
is about the last major hurdle i have to put slim in operation.

thanks for any input.

Aaron

On Mon, Dec 20, 2010 at 1:41 PM, Jennings, Jared L CTR USAF AFMC 46 SK/CCI <
jared.jennings@eglin.af.mil> wrote:

> > i want to use red hat satellite server to deliver to the clients of
> > puppet an rpm containing puppet content a a few different packages.
> >
> > 1 for base lockdown, in this case STIG
> > 1 for project customization
> > 1 for applications
> >
> > or something along those lines.
>
> Aaron, you should check out CLIP, the Certifiable Linux Integration
> Platform, from Tresys.  It uses
> puppet without a puppetmaster, to lock down a RHEL system. I believe the
> lockdown they do is a superset of what the STIG requires.
>
> --
> 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.
>
>


-- 
aa...@linux.com | (858) 334 3171 | 78 Princeton Rd, Goose Creek, SC 29445

-- 
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: "# Only restart if we're actually running"

[Nick Moffitt]

Bill Proud:
> I would have thought that the simplest solution would be to not use a
> service at all but instead notify an exec from the file resource for
> the configuration.  The exec could run a simple script that checks if
> the application is running and restarts it if it is.

The trouble with execs is that they're so open-ended that a "puppet
agent -t --noop" can't predict what will happen after one occurs.  With
a service it can at least assume that the refresh happened successfully
and any notifications can trickle onward from there.  With an exec it
just says "um, except now we're noop.  You're on your own from here,
mate."  It's like that old usenet rant about "given what you just did,
it's perfectly within spec for the compiler to make demons fly out your
nose!"  Anything at all could happen!

I feel like execs are something of a misfeature, but I'd be hard pressed
to figure out how to live completely without them.  I'm glad I have them
available to do things like generate quick unique ssl snakeoil
certificates or ssh keys, but I would hate to rely on them for something
as central as the service resource.

-- 
Though the great song return no more
There's keen delight in what we have:
The rattle of pebbles on the shore
Under the receding wave.  -- W. B. Yeats

-- 
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: "# Only restart if we're actually running"

[Bill Proud]

On Dec 20, 7:57 pm, Nick Moffitt  wrote:
> I'd like to know the best way to fix the refresh/restart behavior of
> Service resources without using ensure => running.
>
> I know that this is an unpopular requirement, but I do not want puppet
> to restart dying services before my monitoring system notices.  If a
> service is fragile, I want to be woken up at 3am.  In the worst case,
> ensure => running could restart my service every ten minutes, nagios
> could check it a few seconds after, and it could die again a few seconds
> past that.  With the right harmonics a service could be effectively 99%
> downtime and ensure => running would prevent me from finding out.
>
> I looked into writing a provider to fix this, but it appears that the
> provider.restart doesn't even get *called* by the core service type
> unless we're ensure => running or status comes back as running.  Now I
> *do* want the system to enforce the running state at the moment a
> configuration change has sent a refresh to the service, but not
> otherwise!
>
> So how can I best do this?  Ideally I'd like for the ensure => running
> behavior to obey something like the Exec resource's "refreshonly"
> parameter.  It seems like this is up at the type level, but is there a
> simple way to monkey-patch this for now?  
>
> --
> Hey, how come nobody here in the future
> has a time machine except me?

Interesting requirement.

I would have thought that the simplest solution would be to not use a
service at all but instead notify an exec from the file resource for
the configuration.  The exec could run a simple script that checks if
the application is running and restarts it if it is.

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

[Puppet Users] how to disable runinterval option

[sanjiv.singh]

hi all ,
i  want to disable  runinterval option on  puppetd .
as i know , after every  1800 sec.( 30 mins)  , puppet client  pull
configuration  from  puppet master .

I want configuration to be pushed to puppet client
when i wwould  fire  puppetrun  on puppet master rather than after
every 30 min , configuration pulled puppet client.


runinterval  :How often puppetd applies the client configuration; in
seconds.
�· Default: 1800


how can I do this ?
where do i need to change in  puppet 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] Yum Repos - Best Practice?

[Felix Frank]

On 12/20/2010 07:26 PM, Matthew Macdonald-Wallace wrote:
> Hi all,
> 
> I'm wondering how other people mange yum repositories using the yumrepo
> type.
> 
> At the moment, we have a class called "repos" which has all of our repos
> defined in it.
> 
> This class is included in our 'base' class which sets up things common
> to all servers such as puppet, mcollective, nrpe etc.
> 
> The down side of this is that all of our repos are included on all of
> our servers, leading to a complete mess in /etc/yum.repos.d/
> 
> I'm now thinking that I need to only call in the various repos for the
> servers which require them, i.e. CentosBase and others would be included
> in the 'base' class, however those which provide things such as php 5.3
> would only be included on webservers etc.
> 
> What would be even nicer would be if there was a way to override certain
> aspects of existing repos, for example:
> 
> class base{
> # other yumrepo defines...
> ...
> ...
> 
> # stick with the php 5.1 in Centos Base
> yumrepo{"epel":
> excludepkgs=>"php*",
> }
> 
> }
> 
> 
> class webserverphp52 {
> # include php5.2 from epel 
> yumrepo{"epel":
> excludepkgs => "",
> }
> }

Hi,

I'm not using yum, but this looks like a use case for either or both of
virtual resources and inheritance:

class yumrepos { # included by each and every node
  @yumrepo {
"one": ...;
"two": ...;
...
"epel": excludepkgs=>"php*", ...;
  }
}

class base_repos { # also included by all (?)
  realize(Yumrepo["foo", "bar"])
}

class php_repos {  # only for those who want
  realize(Yumrepo["epel"])
}

class yumrepos_epel_enable_php inherits yumrepos {
  Yumrepo["epel"] { excludepkgs => "" }
}

So your webserver class will probably
include php_repos
include yumrepos_epel_enable_php
to get (in addition to the base repos) epel and include epel's PHP packages.

HTH,
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] RFC: Puppet Docs

[Matthew Macdonald-Wallace]

On Tue, 2010-12-21 at 09:43 +0100, Felix Frank wrote:
> On 12/20/2010 06:38 PM, James Turnbull wrote:
> > We're now discussing whether it is a good idea to separate our
> > documentation from the Puppet Core.  What we're proposing is to move all
> > the content from Puppet Docs (barring MCollective - which will stay in
> > the Mcollective repository) into the Puppet Core repository, probably
> > under a directory called "docs".
> 
> I'm in favor of this.

+1

M.

-- 
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] RFC: Puppet Docs

[Felix Frank]

On 12/20/2010 06:38 PM, James Turnbull wrote:
> Hi all
> 
> Some time ago we created a new project called Puppet Docs.  This took
> our existing reference documentation (which is auto-generated from the
> Puppet Core source code) and added together some pages from the Wiki and
> some new content.  That content was published at http://docs.puppetlabs.com.
> 
> We're now discussing whether it is a good idea to separate our
> documentation from the Puppet Core.  What we're proposing is to move all
> the content from Puppet Docs (barring MCollective - which will stay in
> the Mcollective repository) into the Puppet Core repository, probably
> under a directory called "docs".

I'm in favor of this.

 - 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] "# Only restart if we're actually running"

[Nick Moffitt]

Nigel Kersten:
> Can you use the "basic" service provider with fully-specified
> start/stop/restart commands to achieve what you need?

Are you suggesting that I override the start command to a noop, and make
sure the restart command works in that scenario?  Thinking that over, it
has potential.  I suppose it would refrain from starting a crashed
service, but it would pass the test in type/provider.rb that's been
causing me grief:

# Basically just a synonym for restarting.  Used to respond
# to events.
def refresh
  # Only restart if we're actually running
  if (@parameters[:ensure] || newattr(:ensure)).retrieve == :running
provider.restart
  else
debug "Skipping restart; service is not running"
  end
end

I think I'll continue to use the fully-specified provider to gain the
enablement features among other things.

Thank you, that seems eminently sensible!

-- 
You are not entitled to your opinions.

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