Stefan Schulte <stefan.schu...@taunusstein.net> writes:
> On Fri, Nov 19, 2010 at 10:25:30AM -0800, Rudy Gevaert wrote:
>>
>> I'm trying to get around the following issue. I want to make sure if
>> a service is stopped. I'm trying to do this is solaris but I don't
>> think this is OS specific.
>>
>> If the software that provides the service (sendmail in my cause) is
>> installed the smf provider can make sure that the service is not
>> running.
>>
>> However, when the software is not installed it can not check:
>> info: Service[sendmail](provider=smf): Could not get status on service
>> sendmail
>
> So you want to remove a package and make sure that the service is
> stopped before that. I can think of a few options:
>
> - remove the service resource: When you remove a package there should be
> a pre_exec or something that stops your service. But I dont know if
> Solaris has any support for that
> - onlyif is only supported by the exec resource. You can define
> something like
> /etc/init.d/package stop ... onlyif => 'pkginfo | grep PACKAGE'
> - Request a feature that all service providers should return stopped
> if the state could not be determined. But that might raise other
> problems
I think this is actually the correct path, although it might not be the
expedient path: I ran into a similar issue with the 'runit' service provider,
which would raise an exception and abort the puppet run[1] if it couldn't find
the service directory.
In my eyes the providers should do something sensible, or as sensible as
possible, such as taking the view that if asked to ensure => stopped, and the
package is not present, you have done everything that was asked of you.
(At least, as much as programmaticly possible, anyhow. :)
> - Build a custom fact that will show you if your package is installed.
> Then you can build an if statement around your ressource. Not really
> great if you want to manage more than one package
>
> I prefer number one but that might not be possible. I'm curious what
> others think about your problem.
I view that sort of problem as a bug.
Daniel
Footnotes:
[1] ...back in the dark ages, when 0.24 was shiny and new, and I have not
actually checked it since, so this might well have gone away by now.
--
✣ 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.
