Modular package support in Serviceguard for Linux Toolkits, August 2008

Migration from legacy to modular packages
Migration tools have been provided by Serviceguard for Linux to migrate legacy packages to
modular packages. The migration can be done in following steps:
1) #cmmigratepkg –p legacy_pkgname [-s] -o modular1.ascii
Create 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 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:
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.
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 user has to comment that out. 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 customer defined halt/run commands.
a) Use ‘cmmigratepkg’ to migrate a legacy package (-x option not required here except in
NFS).
b) Add the toolkit module to the new modular configuration file using "cmmakepkg -i -m [-t] "
option.
c) Modify TKIT_DIR and other toolkit specific parameters in the modular package conf file.
d) Apply the modular package configuration file.
4) Migration of modular packages that do not use toolkit modules.
a) The user has to comment out those invocations in the external script that shall start the
application server. For instance, if there is an invocation to start the apache server in the
external script user has to comment that out. This is because the module scripts shall also
start the server. And toolkit usually throws an error if tried to start twice.
b) Add the toolkit module to the new modular configuration file using "cmmakepkg -i -m [-t] "
option.
6