Modular Package Support in Serviceguard for Linux and ECM Toolkit

6
1) #cmmigratepkg –p legacy_pkgname [-s] -o modular1.ascii
Create a modular ASCII file as shown above, from the already existing legacy package. The ‘–s’ is
optional and has been given to comment out the service part from the configuration file, so that the
pre-configured service parameters from the toolkit module can be included into the package
configuration file.
2) #cmmakepkg –i modular1.ascii -m tkit/<toolkit>/<toolkit_module> -t
<toolkit_conf_file> modular2.ascii
Here a modular ASCII file is created, taking input parameters from the already existing toolkit
configuration file, the toolkit module ADF and the originally created modular package configuration
file.
3) Configure a value for TKIT_DIR and other parameters in modular2.ascii that have to be unique
across the cluster. Examples are package name and service name. It is the responsibility of the
user to ensure that the configured resources do not conflict with the resources of the original legacy
package in the event that both would be up and running at the same time.
4) #cmapplyconf –P modular2.ascii
Apply the configuration file, so that the changes are reflected in the CDB.
The four migration use cases are listed below. Ensure that the legacy package is halted before the
migration.
1) Migration of a package that does not use legacy toolkits, or
2) Migration of packages that use legacy toolkits with other invocations in the customer defined
halt/run commands.
a) Create an external script with the cmmigratepkg command using the ‘-x’ option. This will
comprise of all the set of invocations with which the package was created. In case of pre-ip
legacy toolkit packages (using toolkit scripts of a previous release version which does not
include modular package support) like Samba, Sendmail and NFS, comment out the
service part from the legacy package configuration file before using the cmmigratepkg
command.
b) Copy the external script to all the nodes in the cluster.
c) Comment out those invocations in the external script that would start the application server.
For instance, if there is an invocation to start the Apache server in the external script, it has
to be commented. This is because the module scripts shall also start the server. And toolkit
usually throws out an error if tried to start twice.
d) Add the toolkit module to the new modular configuration file using "cmmakepkg -i -m [-t] "
option.
e) Edit TKIT_DIR and other toolkit specific parameters (if required) in the modular package
conf file.
f) Apply the modular package configuration file.
3) Migration of packages that use legacy toolkits with no other invocations in the customer
defined run/halt commands.
a) Use ‘cmmigratepkg’ to migrate a legacy package (-x option not required here except in
NFS). In case of pre-ip legacy toolkit packages (using toolkit scripts of a previous release
version which does not include modular package support) like Samba, Sendmail and NFS,