Subject: Integrating OCF framework w/ (Net|Free)BSD rc.d
To: None <,,>
From: Brian A. Seklecki <>
List: tech-userlevel
Date: 05/16/2006 13:35:51
What is OCF? The extensions required to make any RC script register a 
system service as a Cluster Resource in the Linux-HA infrastructure.

For those of you unfamiliar with OCF, please refer to the draft standard 

Fortunately, our rc.d system infrastructure is sufficiently extensible in 
nature to easily mitigate the need for duplicate OCF script coding efforts 
by Port maintainers.  Existing in-tree and Ports-provided rc.d/ compliant 
scripts can be extended with very little effort.

However some discussion would be prudent as to how to best accomplish the 
task most conducive


*) Exit codes

We deviate slightly from LSB, as so does LSB from OCF.

Example: When we execute a "stop" command to run_rc_command() on an 
already stopped service, we return code "1", while OCF/LSB calls for code 
3.  We could put a conditional check around the return/exit statement, 
however OCF "compatibility mode" would need to be a variable we source in 
from the service's RC script.  like 'checkyesno $ofc_compat' at line 691 
in rc.subr

There are other adjustments to exit codes that would so need to be made 
(see the standards doc)

*) Environmental variables for per-instance services

Currently we don't have a uniform method for dealing with multiple 
instances of services.  The Apache2 method is nice ("Profiles"); -- 
" [instance] [argument]" syntax.  OCF scripts expect to be 
differentiate using exported environmental variables from the calling 
application: OCF_RESKEY_*, which is not an issue.

*) Additional arguments

The spec calls for additional arguments "monitor" (to augment the existing 
"status") as well as "metadata" (to describe the service using an XML DTD) 
and an optional "validate-all".

These can be very easily implemented using a $extra_commands="".

   extra_commands="monitor metadata"


Note: commands with hyphens (or function names) in them do not seem to be 
honored.  'monitor' should hypothetically be an intelligent service check, 
more than just checking if a TCP socket is open but also if the service is 
healthy -- which implies calling/exec'ing an outside program, like a 
Nagios health check.  Something that generates dynamic input and checks it 
against generated output.

Note: None of the included OCF examples do truely objective testing yet! 
(Sorry guys, systems that don't permitted fragmented packets to the 
network broadcast address aren't going to run Apache's mod_status by 
default }:> ).  We can leave the $servicename_monitor() symantics up to 
the port maintainer, plus the end user can always do more aggressive 

However, our current "status" routine checks for the existence of a PID 
file and cross-references it against the process list (which is a more 
extensive than most other RC systems).  Given that, as a temporary fix, 
"monitor" can be easily mapped to "status" using a small code snippit:

   slapd_monitor ()
    run_rc_command status

    case $? in
                   exit 7
                   exit 0


As for the "metadata" and "validate-all" routines, the XML DTD simply 
helps describe the command line and environmental variable arguments valid 
for the OCF service script, so we might be able to develop a reusable set 
of routines for generating the output without any crazy dependencies on 

The trickier question arises when we want to start making in-tree rc.d/ 
scripts OFC compliant/compatible (nfsd, named, inetd, sendmail, ntpd, 
etc. come to mind)

I'm interested in any discussion / thoughts on a strategy or apporach for 
coding OCF compatibility / integration into our rc.d/ system