> The reason we are doign this is to make sure that we have sufficient free
> disk space on various mountpoints to actually run the application on the
> server.

Oh - and your monitoring doesn't do this already?

> So this is something I'd like to enforce (or "ensure") as part of the
> configuration. Which would best point to integrate this Facter-based check
> into a Puppet configuration for a node?

I guess so ... facter can be used as variables to decide if a
configuration can be applied. You could use conditionals to decide if
and service has ensure => running/stopped based on something from
facter using conditional. But this is during Puppet runtime only ...

> @Doug: Thanks heaps for your Facter script =). Hmm, the only thing is,
> ideally I'd like it to be cross-platform (Linux, Solaris and Windows) - it
> seems there isn't really a abstracted way of checking this in-built into
> Facter/Puppet, which is a shame.

Not necessarily. You can make decisions in Facter based on other
facts. 'operatingsystem' can be one of those facts. For example:

case Facter.value(:operatingsystem)
when "Solaris"
  # ... Solaris related lookup code
when "centos", "redhat"
  # ... centos/redhat related df lookup code
else
  # ... some default behaviour
end

> We also need to check the file permissions on certain files, to make sure
> the application will run correctly. I searched and found this:
> http://projects.puppetlabs.com/projects/1/wiki/File_Permission_Check_Patterns
>
> which seems to do the job.
> I would have thought these two things (checking free disk space on various
> network mountpoints, and checking file/directory permissions) would be two
> fairly common tasks when configuring out boxes. How do people normally
> tackle this with Puppet?

I don't personally for application stop/start scripts. If I wanted to
I would put it in the system V startup script or whatever mechanism is
kicking around. That way it works for Puppet and human users who just
jump on a box and want to use the systems standard stop/start
mechanism.

Problem is - you do it all in Puppet ... only Puppet can stop and
start it. You could write start.pp and a stop.pp script if you wanted
and write all the scripting logic in Puppet I guess. Not normally done
though.

I can't say I have tested mount space before application start. I
usually rely on monitoring to tell me there is a problem there. Is
there a specific reason you need this, ie. avoid some odd corruption
during disk fulls or something? I would imagine the chances of
corruption during a "disk full" are much higher _after_ the
application has started and been running for a while though :-). Hence
why I guess I rely on monitoring more often ... monitoring will alert
me to a disk full even when I'm not trying to start the application.

ken.

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

Reply via email to