Leagacy SG to Modular ??

[MikeL_4]

I am changing our Service Guard implementation from Leagacy to Modular format...

I ran the cmmigratepkg to generate the new package file, and had a couple of questions...

1)The leagacy customer defined area, we called a script with either 'start' or 'stop' parameter...

              How is this handled with the Modular format ? will the Package start or stop automatically

              pass this parameter, or is there something I need to do special ??

2) Besides the Package control file changing, is there anything else that needs to be configured special ??

[Matti_Kurkela · Accepted solution]

1.) In the modular format, the customer_defined_run|halt_commands functions are replaced by the external_script configuration keyword. You can use it to make Serviceguard call custom script(s) at package startup and shutdown. At package startup, the script is called with the "start" parameter; at package shutdown, it is called with the "stop" parameter. So your existing script would be a good candidate to be configured as an external_script.

However, you must add one more piece of functionality to your script before you can use it as an external_script in the Modular package configuration. When cmcheckconf or cmapplyconf is used for the package, the external_scripts in it are called with a third parameter: "validate". You can use this to implement extra configuration checks to your package. But if you don't want to make any special checks, just make sure that your script exits with result code 0 and without printing any unnecessary messages when called with the "validate" parameter.

In other words, if your script uses a typical "case" clause to handle the parameters, the external_script needs a third possible case, even if it does nothing:

#!/bin/sh

case "$1" in
    start)
        # add commands here to start the packaged application
        ;;
    stop)
        # add commands here to stop the packaged application
        ;;
    validate)
        # if there is nothing specific to validate, just exit
        exit 0
        ;;
    *)
        # if we end up here, the script has been called incorrectly
        # or using an unknown parameter (maybe added in a future version of
        # Serviceguard?)
        echo "${0##*/}: ERROR: unknown script parameter \"$1\"" >&2
        exit 1
        ;;
esac

2.) If your package configuration includes any Serviceguard Toolkits, read their documentation to see what is changed.

There is also another package configuration keyword: external_pre_script. It runs a script like external_script, but before the package filesystems have been mounted. This might make it simpler to implement some complex package configurations.

[MikeL_4]

Thanks MK...

I guess I should try to start using the Serviceguard tollkit eventualy...

Do they have manuals for this product ? or just in the README files ??

[Matti_Kurkela]

Serviceguard has a very good manual: it's a book titled Managing Serviceguard.

You used to get a physical copy of this book along with each Serviceguard license, although this may have been changed when HP started the electronic delivery option for licensed software.

The book is also available as a PDF:

http://www.hp.com/go/hpux-serviceguard-docs -> HP Serviceguard -> User guide

If you configure Serviceguard, you should read this book at least once, and then refer to the appropriate sections as necessary.

The documentation for the various Serviceguard toolkits and extensions is also available from the above-mentioned URL.

[Stephen Doud]

The legacy package customer_defined_*_cmds functions section are replaced by the external_scripts module in the modular package.

Search the HPSC portal for a document titled, "HPUX Serviceguard - Implementing external scripts in modular packages".   It discusses how to implement external scripts.