On Dec 15, 2:08 pm, jcbollinger <john.bollin...@stjude.org> wrote:
> On Dec 14, 4:37 pm, Jo Rhett <jrh...@netconsonance.com> wrote:
>
> > Try
> > notify => Service['autofs']
>
> Right. As far as I know, classes do not forward signals to resources
> they contain.
>
Are you absolutely sure about that? My understanding was to use
something like Class['zmfs::service'] only to avoid running individual
services separately in that class.
> Furthermore, you should consider whether it would be appropriate to
> combine your two classes. That a resource belonging to one wants to
> signal a resource belonging to the other is a hint in that direction
> (but no more than that). I'm not seeing what you gain by defining
> such fine-grained classes, especially with the implicit dependencies
> among them (see next).
>
Those three code snippets are in three different files, namely
definition.pp, config.pp and service.pp respectively. And there is a
"config.pp" where
The "line_check" definition gets reused for various files in the
module. [re]Starting zmfs is not just enough, it's needs some other
services to be restarted, "autofs" being one of the most important
ones. So, what I want is to restart "autofs" as soon as the "/zmfs /
etc/auto.zmfs" is added to the auto.master file, say for example for
the very first time. "zmfs" itself still just works without restarting
(even starting) the "autofs" but it won't be completely usable. So, in
fact, this is the actual service.pp file:
*******************************************
class zmfs::service {
service {
'zmfs':
enable => true,
ensure => running,
hasstatus => true,
hasrestart => true,
#status => '/etc/zmfs/service_zmfs',
require => Package['zmfs','zmfs-init-scripts'];
'autofs':
enable => true,
ensure => running,
hasstatus => true,
hasrestart => true,
status => 'service zmfs probe',
require => Package['zmfs','zmfs-init-scripts'];
}
}
*******************************************
I wrote (at least trying to) this module to use by the several other
sys-admins, where either "autofs" is already running and in some cases
the "auto.master" itself is being maintained by another puppet module.
So, I had to make sure my module must restart autofs after adding the
appropriate line to the file. but that's not happening.
On the other hand, if I take the 'service autofs' out of the equation
and use an external script (service_zmfs) with "status"
****************************************
#!/usr/bin/perl
# file: service_zmfs
use strict;
use warnings;
my @checks = (
"serviceautofs restart",
"service zmfs probe",
);
for my $check ( @checks ) {
$check .= " 2>&1 > /dev/null"; # suppress output
system( $check ) == 0 or exit 1;
}
*************************************
it works. Still don't fully get it.
Cheers!!
> Also, if you do not combine classes, then be sure each class
> 'include's the other classes whose resources it references. For
> instance, class zmfs::service should contain "include 'zmfs::config'"
> at the beginning of its body. Class zmfs::service should 'include'
> whatever class(es) declares the the 'zmfs' and 'zmfs-init-scripts'
> packages. On the practical side, this protects you from catalog
> compilation failures arising from varying parse order. On the
> conceptual side, it's the Right Thing for classes to formally declare
> their dependencies.
>
> John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
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.
