[Puppet Users] Re: Problems with puppet agent on EL7 systems

[smalderma]

Mr. Bollinger, you sir are the winner!  I just wish I had a prize :)

Not so much a ruby version issue, but your point about the to_a method 
being removed got me looking into all the facts we've got rolling around, 
and there just happens to be one fact that uses this call. So I'm off to go 
repair that, and much appreciate that hint in the right direction!  Someone 
else mentioned getting rid of custom facts, but it didn't lead me to look 
at a ruby version issue.

Thanks a bunch to all!

On Tuesday, March 3, 2015 at 9:14:12 AM UTC-5, jcbollinger wrote:
>
>
>
> On Wednesday, February 25, 2015 at 3:43:18 PM UTC-6, smalderma wrote:
>>
>> Hi,
>>
>> I'm working on enabling our environment to support EL7 Linux systems.  We 
>> mostly run OracleLinux, but also have CentOS and RHEL.
>>
>> I've got a CentOS 6 PuppetMaster running Foreman 1.7.2, Puppet 3.6.2 
>> (from puppetlabs repo) doing my provisioning.  I have provisioning working 
>> for both Oracle Linux 7 and CentOS 7.  The systems kickstart, install 
>> puppet inform Foreman that they're done building and reboot.
>>
>> After the reboots, the puppet agent on both systems produce this:
>>
>> Failed to apply catalog: Could not retrieve local facts: undefined method 
>>> `to_a' for "ens33":String
>>>
>> and
>>
>>> Failed to apply catalog: Could not retrieve local facts: undefined 
>>> method `to_a' for "ens192":String
>>>
>>
>> I'm at something of a loss as to why.  While I'm new at the EL7 release, 
>> I know there have been issues with facter requiring net-tools to be 
>> installedand it is.  Both agents are installed out of EPEL 7 at version 
>> 3.6.2 with facter 2.2.  Would anyone happen to have an idea on this?
>>
>
>
> In Ruby 1.8.7, the String class has a 'to_a' method.  In Ruby 1.9 and 
> later, it does not.  I am inclined to think, therefore, that the messages 
> mean your Puppet and the Ruby it is running on are mismatched.
>
> Puppet claims compatibility with Ruby 1.8.7, Ruby 1.9.3, and Ruby 2.0.x 
> (and it half claims to support 2.1.x).  If you are using a different Ruby 
> then switch to one of those.  If you have more than one Ruby installed, 
> then look into the possibility that Puppet is running on a different one 
> than you intend, or worse: that it is somehow running on one Ruby, but 
> pulling some components from another.
>
>
> John
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/e40aec20-ab2d-48ed-afe8-7faf14181e07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Problems with puppet agent on EL7 systems

[smalderma]

Hi Red!

Thanks for the reply, I'm familiar with the new interface labelling, though 
I'd be hard pressed to translate it with out the docs :)

facter interfaces on both servers produces what one would expect...

[root@buildtest1]# cat /etc/system-release
> Oracle Linux Server release 7.0
> [root@buildtest1]# facter interfaces
> ens192,lo
>
> [root@buildtest2]# cat /etc/system-release
> CentOS Linux release 7.0.1406 (Core)
> [root@buildtest2]# facter interfaces
> ens33,lo
>

On Sunday, March 1, 2015 at 8:01:44 PM UTC-5, red wrote:
>
> ens33 and ens192 are the new style interface names, replacing eth0 eth1 
> ... 
> what do you get if you execute:
>
> facter interfaces
>
> On Wednesday, February 25, 2015 at 1:43:18 PM UTC-8, smalderma wrote:
>>
>> Hi,
>>
>> I'm working on enabling our environment to support EL7 Linux systems.  We 
>> mostly run OracleLinux, but also have CentOS and RHEL.
>>
>> I've got a CentOS 6 PuppetMaster running Foreman 1.7.2, Puppet 3.6.2 
>> (from puppetlabs repo) doing my provisioning.  I have provisioning working 
>> for both Oracle Linux 7 and CentOS 7.  The systems kickstart, install 
>> puppet inform Foreman that they're done building and reboot.
>>
>> After the reboots, the puppet agent on both systems produce this:
>>
>> Failed to apply catalog: Could not retrieve local facts: undefined method 
>>> `to_a' for "ens33":String
>>>
>> and
>>
>>> Failed to apply catalog: Could not retrieve local facts: undefined 
>>> method `to_a' for "ens192":String
>>>
>>
>> I'm at something of a loss as to why.  While I'm new at the EL7 release, 
>> I know there have been issues with facter requiring net-tools to be 
>> installedand it is.  Both agents are installed out of EPEL 7 at version 
>> 3.6.2 with facter 2.2.  Would anyone happen to have an idea on this?
>>
>> Thanks for the advice!
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/f89628d6-a566-4583-8ab9-c4246a108e92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Problems with puppet agent on EL7 systems

[smalderma]

Michael,

Thanks for the reply.  I use Foreman as ENC, and my buildtest boxes are in 
a host group that applies our basic site-wide puppet classes.  I have set 
them to not be in a hostgroup and thus not have any classes applied, but 
the same error persists.  I'm just not sure of what the error even means at 
this point.

For a while I struggled with getting Foreman to provision the EL7 systems, 
I have a thread in that list about my issues.  But using virtualbox VMs on 
my laptop I was able to work through those issues and was able to run 
puppet successfully on the vboxes I provisioned from the same Centos7 and 
OL7 source repos and kickstart scripts as I am using on my production 
foreman server.  The provisioning issues for both OSes were related to the 
libselinux-ruby package, I had downloaded a Centos iso that didn't have the 
package to use as my source repo, and in OL7 the package is in a different 
repo (like RHEL i've heard), so I made a patch [1] to kickstart templates 
Foreman uses so that the repo gets added/enabled before puppet is installed.

In my virtualbox lab, the only puppet classes I was applying were a static 
files module that populates /root/.ssh/authorized_keys and example42-puppet 
+ dependencies from the Forge.  On my Produciton Puppetmaster we're using 
more of example42's modules but mostly out of git, and some are run off my 
own forks.  The site-wide modules the hostgroup had included the site 
files, puppet, razorsedge/puppet-vmwaretools, and our nagios agent 
monitoring wrapper class which is based on example42/puppet-nrpe.

Anyway, all the extras are now excluded and the errors still persist.

[1] 
https://github.com/theforeman/community-templates/compare/master...salderma:master

On Sunday, March 1, 2015 at 6:35:07 PM UTC-5, Michael Stanhke wrote:
>
> What does your catalog look like? Could you try basically something empty 
> (no node classification, no custom facts/plugins) and see if it works? We 
> certainly have lots of people running Puppet on EL7. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b059fded-1bed-4b6c-9320-679bcad82d62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Problems with puppet agent on EL7 systems

[smalderma]

I put a paste out there of a puppet --test --debug run if anyone wants to 
have a look-see - http://pastebin.com/X6rpgCgp

On Wednesday, February 25, 2015 at 4:43:18 PM UTC-5, smalderma wrote:
>
> Hi,
>
> I'm working on enabling our environment to support EL7 Linux systems.  We 
> mostly run OracleLinux, but also have CentOS and RHEL.
>
> I've got a CentOS 6 PuppetMaster running Foreman 1.7.2, Puppet 3.6.2 (from 
> puppetlabs repo) doing my provisioning.  I have provisioning working for 
> both Oracle Linux 7 and CentOS 7.  The systems kickstart, install puppet 
> inform Foreman that they're done building and reboot.
>
> After the reboots, the puppet agent on both systems produce this:
>
> Failed to apply catalog: Could not retrieve local facts: undefined method 
>> `to_a' for "ens33":String
>>
> and
>
>> Failed to apply catalog: Could not retrieve local facts: undefined method 
>> `to_a' for "ens192":String
>>
>
> I'm at something of a loss as to why.  While I'm new at the EL7 release, I 
> know there have been issues with facter requiring net-tools to be 
> installedand it is.  Both agents are installed out of EPEL 7 at version 
> 3.6.2 with facter 2.2.  Would anyone happen to have an idea on this?
>
> Thanks for the advice!
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/1c8293be-d257-4081-9b7e-901c8dfad727%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Problems with puppet agent on EL7 systems

[smalderma]

Hi,

I'm working on enabling our environment to support EL7 Linux systems.  We 
mostly run OracleLinux, but also have CentOS and RHEL.

I've got a CentOS 6 PuppetMaster running Foreman 1.7.2, Puppet 3.6.2 (from 
puppetlabs repo) doing my provisioning.  I have provisioning working for 
both Oracle Linux 7 and CentOS 7.  The systems kickstart, install puppet 
inform Foreman that they're done building and reboot.

After the reboots, the puppet agent on both systems produce this:

Failed to apply catalog: Could not retrieve local facts: undefined method 
> `to_a' for "ens33":String
>
and

> Failed to apply catalog: Could not retrieve local facts: undefined method 
> `to_a' for "ens192":String
>

I'm at something of a loss as to why.  While I'm new at the EL7 release, I 
know there have been issues with facter requiring net-tools to be 
installedand it is.  Both agents are installed out of EPEL 7 at version 
3.6.2 with facter 2.2.  Would anyone happen to have an idea on this?

Thanks for the advice!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/4cf140de-6629-4247-97cf-197f982f643d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Custom Fact Help? Works in ruby, but not facter...

[smalderma]

John,
  Thanks for the assist.  I guess I was working from a less than stellar 
example.

On Thursday, May 29, 2014 9:53:14 AM UTC-4, jcbollinger wrote:
>
>
>
> On Wednesday, May 28, 2014 9:16:47 AM UTC-5, smalderma wrote:
>>
>> Hi,
>>
>> I'm working on custom fact that uses Facter::Util::Resolution.exec to run 
>> a command that returns output I want to parse with regex.  If I write up a 
>> ruby shell script like:
>>
>> #!/usr/bin/ruby
>>
>> out = ``
>> out = out.gsub!(//, "\\1\\3")
>> puts "#{out}"
>>
>> The desired output comes to the screen, every time, and on every system I 
>> run it.
>>
>> If I modify the script to be a fact like so:
>>
>> # custom fact
>> require 'facter'
>> Facter.add(:newfact) do
>>   out = Facter::Util::Resolution.exec("")
>>   out = out.gsub!(//, "\\1\\3")
>>   secode { out }
>> end
>>
>> A puppet run actually prints the full output of the command twice after 
>> syncing the fact.  Running facter -p newfact does the same.  On top, the 
>> printed output is the raw output not the regex filtered.
>>
>> What am I doing wrong here?
>>
>>
>
> For one thing, you are performing your fact evaluation outside the setcode 
> {} block.  The part in the block passed to Facter.add() but outside setcode 
> {} runs when the fact is added to Facter, but the part inside the setcode 
> {} block is run when the fact is evaluated.  I speculate that you are 
> getting output both times.  
>
> There are very few statements that should ever appear in that middle 
> area.  The one that comes first to mind is 'confine', and others would be 
> similar Facter-specific things.
>
> Your fact should look more like this:
>
> require 'facter'
> Facter.add(:newfact) do
>   setcode {
> out = Facter::Util::Resolution.exec('')
>
> # F::U::R::exec() may return nil
> out or out.gsub(//, "\\1\\3")
>   }
> end
>
>
> Note that whatever value is returned by the setcode {} block is taken as 
> the value of the fact.  There is no particular advantage to assigning it to 
> a variable first, though it is harmless to do so.
>
>
> John
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/8e04eee8-ff63-47ca-9221-e225dd6ec5f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Custom Fact Help? Works in ruby, but not facter...

[smalderma]

Hi,

I'm working on custom fact that uses Facter::Util::Resolution.exec to run a 
command that returns output I want to parse with regex.  If I write up a 
ruby shell script like:

#!/usr/bin/ruby

out = ``
out = out.gsub!(//, "\\1\\3")
puts "#{out}"

The desired output comes to the screen, every time, and on every system I 
run it.

If I modify the script to be a fact like so:

# custom fact
require 'facter'
Facter.add(:newfact) do
  out = Facter::Util::Resolution.exec("")
  out = out.gsub!(//, "\\1\\3")
  secode { out }
end

A puppet run actually prints the full output of the command twice after 
syncing the fact.  Running facter -p newfact does the same.  On top, the 
printed output is the raw output not the regex filtered.

What am I doing wrong here?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/33d2348e-7d0e-40ec-9adf-ba894bb83f79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Dynamic Nagios Hostgroup members via collected resources?

[smalderma]

Greetings All,

I've referenced a few older discussions about nagios hostgroups and the 
nagios_hostgroup resource.  I admit I'm somewhat new to this game, so 
please excuse my ignorance on the complexities.  I'm looking for a way that 
puppet can use collections / exported resources to create nagios host 
groups.  For instance, I'd like a hostgroups for osfamilies, puppet 
environments, domains, and perhaps virtual or hardware platform.

It seems like using @@nagios_hostgroup on the nodes, and collecting the 
resources on the Nagios server is not sufficient, when what I'm looking for 
is one hostgroup named RedHat with members of this osfamily, and another 
hostgroup named Solaris whose members are of the solaris osfamily.  I've 
not had much success writing this into puppet, so is this just not 
possible?  Would I be better served creating custom resource(s) that simply 
collect lists of node names by the facts I'm interested and then the Nagios 
server uses those collections as data to populate its set of 
nagios_hostgroup resources?

Thanks for your thoughts and wisdom.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/3bf39a40-53c1-4de7-8e22-22ab45121927%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] Is it possible to evaluate a string as a parameter name?

[smalderma]

Thanks guys!  That was simpler than I thought.  I had not had an reason to 
dive into an inline template before, so it was a feature that I've read 
about, but not leveraged.

I ended up applying John's method of using an inline template for the ip, 
mac, and netmask.  The inline template seems to do the trick!

On Monday, November 18, 2013 12:50:32 PM UTC-5, Ygor wrote:
>
> Here is what I did along the same lines:
>
> I made a custom fact that makes a fact of all user home directories:
>
> modules/users/lib/facter/user_home.rb 
> require 'etc'
>
> Etc.passwd { |user|
>
> Facter.add("home_#{user.name}") do
> setcode do
> user.dir
> end
> end
>
> }
>
> Then, in a dot-pp file, I did this:
>
> $home_fact = "home_${user_name}"
> $homedir = inline_template("<%= scope.lookupvar('::${home_fact}') %>")
>
> Going with this, you should be able to pass in your NIC label and then :
>
> $my_ip_setup = "ipaddress_${my_default_nic}"
> $my_ip = inline_template("<%= scope.lookupvar('::${my_ip_setup}') %>")
>
> Hope this works for you.  Let us all know, please.
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere 
> in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> *From: *"smalderma" >
> *To: *puppet...@googlegroups.com 
> *Sent: *Monday, November 18, 2013 11:50:44 AM
> *Subject: *[Puppet Users] Is it possible to evaluate a string as a 
> parameter name?
>
> Hi,
>   I'm looking to combine a couple of fact names with the value of a class 
> parameter to create and lookup the resulting fact's value.  Is that 
> possible?  For example, my class will take the parameter "my_default_nic" 
> from beyond.  So I know that as long as $my_default_nic exists on the 
> client, then so will facts like macaddress_, netmask_, and 
> ipaddress_.  So I'm looking for a way to formulate those fact names 
> and evaluate the result...
>
> Is this at all possible?  Thanks for your thoughts!
>
> $my_default_nic = 'eth1'
>> $ip_method = 'static'
>> $my_ip = ???###  <-  should end up 
>> looking like the value of $::ipaddress_eth1 with out hardcoding eth1
>> $my_netmask = ? ###  <- 
>>
>> case $ip_method {
>>   'static': {
>> network::static { $my_default_nic:
>>   ensure  => up,
>>   ipaddress => $my_ip,
>>   netmask  => $my_netmask,
>>  }
>>   }
>>   /(?i:dhcp|dynamic)': {
>> network::dynamic { $my_default_nic: 
>>   ensure => up,
>> }
>>   }
>>   default: {
>> network::dynamic { $my_default_nic:
>>   ensure => down,
>>}
>> }
>>
>  -- 
> You received this message because you are subscribed to the Google Groups 
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to puppet-users...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/puppet-users/fc39aa90-27f9-44dc-b478-3a288ff2%40googlegroups.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/ed82b03a-659c-48b5-a6b0-d92f093b100c%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Is it possible to evaluate a string as a parameter name?

[smalderma]

Hi,
  I'm looking to combine a couple of fact names with the value of a class 
parameter to create and lookup the resulting fact's value.  Is that 
possible?  For example, my class will take the parameter "my_default_nic" 
from beyond.  So I know that as long as $my_default_nic exists on the 
client, then so will facts like macaddress_, netmask_, and 
ipaddress_.  So I'm looking for a way to formulate those fact names 
and evaluate the result...

Is this at all possible?  Thanks for your thoughts!

$my_default_nic = 'eth1'
> $ip_method = 'static'
> $my_ip = ???###  <-  should end up looking 
> like the value of $::ipaddress_eth1 with out hardcoding eth1
> $my_netmask = ? ###  <- 
>
> case $ip_method {
>   'static': {
> network::static { $my_default_nic:
>   ensure  => up,
>   ipaddress => $my_ip,
>   netmask  => $my_netmask,
>  }
>   }
>   /(?i:dhcp|dynamic)': {
> network::dynamic { $my_default_nic: 
>   ensure => up,
> }
>   }
>   default: {
> network::dynamic { $my_default_nic:
>   ensure => down,
>}
> }
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/fc39aa90-27f9-44dc-b478-3a288ff2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet Users] Looking for alternative to fail function

[smalderma]

Greetings,
  I was just reading this thread "Early clean exit from module?" 
[1]on 
the idea of having an alternative to the fail function.  I believe that 
like the OP of that post, I am looking to replace modules usage of the fail 
function when choosing to bail on the puppet run for some reasonable cause.

  For example:

  case $::operatingsystem {
> 'Solaris': {
>   fail("Unsupported platform: ${::operatingsystem}")
> }
>

  I am hoping to discover a means bail on the module but not on the entire 
puppet run.  Consider this use case...


   1. Using Foreman as an ENC, node classifications are defined by host 
   group and at the node level.  
   2. Host groups are useful because they can identify groups of similar 
   systems.  
   3. Suppose I have a host group for Virtual Machines, this group requires 
   that all its nodes use Razorsedge/puppet-vmwaretools 
[2]. 
   
   4. A new customer determines the need to run a platform like Solaris, 
   which is unsupported by the puppet module.
   5. Options -
  1. Within Foreman, redefine host group classifications, and host 
  memberships to create a VMWare group just for the 1 off platform.
  2. Fork the module and devote time to add platform support to the 
  module.
  3. Fork the module and notify/warn but quit processing module instead 
  of fail/bail on the puppet run.
  4. Fork the module and wrap the entire module in a conditional to 
  avoid unsupported platforms.
   
The Razorsedge module is well crafted, and does a gigantic conditional to 
avoid all hosts that do not have the fact virtual = vmware set.  Seems like 
a much better means of accomplishing this would be...

  case $::operatingsystem {
> 'Solaris': {
>   quit_nicely_and_continue_puppet_run("Unsupported platform: 
> ${::operatingsystem}")
> }
>

I understand the arguments about being declarative, but if I can declare 
myself a failure, shouldn't I also be able to declare myself a success, 
even if in reality, I'm still a failure?

Thanks,

P.S. Ok, that last bit was far too personal.  :)



-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [Puppet Users] restarting the smf services on solaris 10

[smalderma]

Sorry, I know this is an old posting, that I'm trying to resurrect.

So I have a module for solaris similar to what's described below for the 
system-log service.  Basically when we load a server, system-log is already 
enabled with a stock /etc/syslog.conf file.  Using the openvpn example 
below, I've noticed that when my module pushes a new syslog.conf file - say 
for remote logging - the puppet agent does not restart the smf service.

Can that be forced?  I thought the subscribe would make that happen.  I 
have have hasrestart => true as well, but updating the file does not force 
the service to restart.

Thanks.

On Wednesday, March 14, 2012 3:04:48 AM UTC-4, jerry wrote:
>
> Why would you like to do this? With the following service provider (as a 
> sample) openvpn would be restarted if the service is in a maintenance state 
> (if possible) or disabled. Or do I miss your point?
>
> service { 'openvpn':
> ensure=> running,
> provider  => smf,
> enable=> true,
> require   => File['/var/svc/manifest/application/network/openvpn.xml'],
> subscribe => File['/etc/openvpn/server.conf'],
> manifest  => '/var/svc/manifest/application/network/openvpn.xml',
> }
>
> HTH.
>
> Am 13.03.2012 um 20:03 schrieb Afroz Hussain:
>
> > Hi,
> > 
> > Is there any way to restart a service based on the status of the
> > service using Puppet service resource? I want to check the status of
> > the service first then disable it , and make sure that the service has
> > disable successfully then start the service.
> > 
> > Any help will be appreciated.
> > 
> > Thanks in advance
> > Afroz Hussain
>
>

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