Making changes to package scripts

[Brian Bientz]

We had consultants configure our cluster and service guard software. Now, we want to make a few changes to the run and halt scripts.

From what we can tell, the consultants used the standard template for creating our single package. In the control script, the customer_defined_run_cmd section contains the follwing lines:

/etc/cmcluster/prodora1.pkg/prodora1.check
test_return 51

In the customer_defined_halt_cmd section, the following lines:

su - oracle -c "/etc/cmcluster/prodora1.pkg/prodora1.stop"
test_return 52

My question is this: Can we make modifications to the shell scripts prodora1.stop and prodora1.check (and scripts called from these scripts) without recreating the package (cmhaltpkg, cmcheckconf, cmapplconf, etc.)?

There are some concerns from members of our staff, that any changes requires a complete rebuild of the package. If so, why would you use shell scripts in the first place?

[Vincenzo Restuccia]

cmhaltpkg package,modify the script,and cmrunpkg -n node package,cmmodpkg -e package.

[Jim Mulshine]

There are two files associated with a package...(1) the control script and (2) the configuration file. Mine usually end with .cntl and .conf. You can change the control scipt without a necessary package rebuild, but you may want to halt the package first. If you change the configuration file, then you must rebuild.

[Mike Taylor_3 · Accepted solution]

In theory you don't have to execute any cm* commands. Any changes you make to your start/stop scripts will take effect the next time the package does a start/stop.

In practice, however, it may be a good idea to test the package start/stop on all nodes using cm* commands. FYI, we have a simple script for moving packages you may find helpful:

#!/usr/bin/ksh
# $1 = packagename
# $2 = nodename
date
cmhaltpkg $1
cmrunpkg -n $2 $1
date
cmmodpkg -e $1
exit

If you are going to be supporting an MCSG environment, I would highly recommend attending the MCSG training. In 13 years with HP it is the best class I've ever attended, and I'd say it is essential for supporting an MCSG cluster.

Hope this helps...

Best regards,
Mike Taylor
HP Corvallis

[Rajeev Tyagi]

Ideally speaking you do not have to stop start or recreate the package for changing these scripts but if you want changes to be applied immediately then you can stop and start the package and also this will confirm your modification.

[Stephen Doud]

The short answer is "possibly".

If the desired script alterations do not require modifications to
the package configuration file, then it is possible to alter
the package control script while the package is running because
the script is only accessed when the package is started or
stopped.

If the alteration includes the addition of resources such as LVM
volume groups and/or logical volumes or relocatable IPs, they
should be activated (and mounted) manually, so that the updated
control script will be able to (umount and) deactivate them when
the package is halted.

If the updated script no longer references certain resources,
manually deactivate them so as not to hinder the script from
completing when the package is eventually halted.


Altering the package script file name or adding / removing
/ modifying package SERVICEs generally requires a new
cmapplyconf with the package down.

The cmcheckconf and cmapplyconf commands read the package
configuration file (not the package control script). cmapplyconf
loads the package configuration file variable declarations into
the cluster binary cmclconfig.

The variables in the package configuration file that reference
the package control script are:

RUN_SCRIPT
HALT_SCRIPT (usually the same as RUN_SCRIPT)
SERVICE_NAME
SERVICE_FAIL_FAST_ENABLED YES/NO
SERVICE_HALT_TIMEOUT
SUBNET

NOTE: the SUBNET reference is validated during cmcheckconf
and cmapplyconf activities. If legitimate, it is listed as a
monitored resource in the cluster binary. It is not necessary to have
a matching reference in the package control script. Likewise, it is
possible to have no SUBNET reference in the package configuration
file, but list SUBNET/Relocatable IP pairs in the package control
script.


A word to the wise - complex modifications to the package control
script should be tested immediately!

Don't forget to copy the altered form of the script to the adoptive
nodes.