Patching TCS components

A simple Configuration File Change

A simple configuration file change can be done based on the following example to modify the gcs.conf file:

Login into tcs1 or tcs2 as user tcs and run the following commands...

cd /lbt/tcs/current/gcs/etc

If this is the first time the file is changed, keep the original file intact, make a copy of it that will be edited, and create a symbolic link pointing to the changed file...

mv gcs.conf gcs.conf.<build_name>
cp gcs.conf.<build_name> gcs.conf.YYYYMMDDxx
ln -s gcs.conf.YYYYMMDDxx gcs.conf
vi gcs.conf
exit

If this is the nth time the file is changed and the symbolic link has already been established...

cp gcs.conf gcs.conf.YYYYMMDDxx
ln -sfT gcs.conf.YYYYMMDDxx gcs.conf
vi gcs.conf
exit

Have the operator restart the subsystem(s) that are affected by the change.

A simple Executable File Change

A simple executable file change can be done based on the following example to modify the GCS executable:

Run the following commands...

cd /lbt/tcs/current/gcs/bin

If this is the first time the file is changed, make a copy of it named for the build, and create a symbolic link pointing to the changed file...

mv GCS GCS.<build_name>
cp <source_path>GCS GCS.YYYYMMDDxx
ln -s GCS.YYYYMMDDxx GCS
exit

If this is the nth time the file is changed and the symbolic link has already been established...

cp <source_path>GCS GCS.YYYYMMDDxx
ln -sfT GCS.YYYYMMDDxx GCS
exit

Have the operator restart the subsystem(s) that are affected by the change.

Patching a Subsystem

If more than one executable or configuration file needs to be changed, the entire installed directory tree for the subsystem can be replaced. The basic scheme is to run the "./bundle.sh" from a working copy of the source (this can be any working copy of the source, but you must insure that you do not change reflective memory from standard, and the build name is correct):

./bundle.sh build_name subsystem_name

This will create a tarball that contain all the related configuration files, binary products, and helper files; following our example:

./bundle.sh 2014C aos

creates:

aos-2014C.tgz

If this is the first patch, make a copy of the existing subsystem directory named for the build, expand the tarball, rename it based on the date, and create a symbolic link pointing to the new directory...

cd /lbt/tcs/2014C
mv aos aos.2014C
tar -xzvf aos-2014C.tgz
mv aos aos.YYYYMMDDxx
ln -sfT aos.YYYYMMDDxx aos exit

The old copy of the aos will be located at "/lbt/tcs/2014C/aos.2014C" and the new (patched) copy will then be in "/lbt/tcs/2014C/aos.YYYYMMDDxx" (and "/lbt/tcs/2014C/aos") in this example.

If this is the nth patch, remove the old link, expand the tarball, rename it based on the date, and create a symbolic link pointing to the new directory...

cd /lbt/tcs/2014C
rm aos tar -xzvf aos-2014C.tgz
mv aos aos.YYYYMMDDxx
ln -sfT aos.YYYYMMDDxx aos exit

The old copy(s) of the aos will be located at "/lbt/tcs/2014C/aos.xxxx" and the new copy will then be in "/lbt/tcs/2014C/aos.YYYYMMDDxx" (and "/lbt/tcs/2014C/aos") in this example.
Topic revision: r14 - 01 May 2018, StephenHooper
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback