Scripts for ServiceGuard (chown, chmod)

[Fernando Boza]

I have a customer with a ServiceGuard cluster (two nodes), HP-UX 11.11

He frecuently creates logical volumes on that cluster, but he forgets do the followings tasks:
vgexport
vgimport
chmod
chown

I need scripts for automaticaly do that task for client.

Any idea??

[Steven E. Protter]

Shalom,

Honestly:

I'd create a checklist on paper and make him put it up where he can see it in the office.

failing that:

I'd create a script that does these tasks and accepts the volume group name as $1 and disks involved as $2 etc.

SEP

[Doug O'Leary]

Hey;

While it'd be great if the customer would remember, everyone makes mistakes. The more people you have managing systems, the more likely those mistakes are too.

My client has a number of clusters some of which use EMC timefinder to copy the data to remote systems for backups.

This client's issue was that the map files on the backup servers weren't always in sync with the ones actually running production. Go figure on how well that made database backups work.

I wrote a script that runs on all the clusters that reads in a data file formatted as follows:

########################################################################
# vgs.tbl: Table of volume group information used by /root/bin/get_maps
# to obtain vg maps and transfer them to other clustser nodes
# and to the backup server.
########################################################################
# Pri Alt VG Minor Sid Pkg Bdir
########################################################################

The script runs preview exports for each of the volume groups, then using a null passphrased ssh key, secure copies the map files to the other node. Then, if the system uses EMC timefinder (Bdir != N/A is the flag), it secure copies the map files up to the two netbackup media servers.

Finally, as a last step, it runs another script called reimport on the other node which uses that same vgs.tbl as input to reimport the volume groups associated with the SAP sid.

This script runs every day at 1700 right before the backups are scheduled to kick off. We haven't had a bit of problems with teh map files not being in sync since then.

Another problem we've had in the past is raw volumes not having the ownership updated on them. vgimport sets ownership on all lv devs to root:sys. If you're using raw devs in oracle or informix, this poses a problem - particularly if you automatically import the vgs as described above.

I define a function in package control scripts that updates the ownership of all raw devices in the appropriate volume groups. Fortunately, the basis/dba folk keep the raw devices in distinct volume groups; easier to script that way.

function update_owner
{ Inst=$1
owner=$2
set -A vgs $(vgdisplay | grep -i 'vg name' | grep -v vg00 | \
grep data | grep -i ${Inst} | awk '{print substr($NF,6)}')
owner="${owner}:dba"
Date=$(date "+%x %X")

for vg in ${vgs[*]}
do
printf "%-18s Updating ownership of %s raw volumes\n" "${Date}" ${vg}
for lv in $(vgdisplay -v ${vg} | grep -i 'lv name' | awk '{print $NF}')
do
chown ${owner} ${lv%/*}/r${lv##*/}
done
done
}

Calling it looks like:

function customer_defined_run_cmds
{
update_owner E1P orae1p
/etc/cmcluster/E1P/sapdb.cntl startDB E1P
... rest snipped.

Like I said, remembering and/or not making mistakes would be the best bet, but we're all human. Automating repetitious tasks helps prevent human error mistakes and forgetfulness.

HTH;

Doug O'Leary

[Viktor Balogh]

A script for syncing the LVM state? Instead of I'd suggest you a check-script that compare the control-scripts for the packages, counts the disks on each node, etc...
vgexport/vgimport in a script can be very dangerous, i'd prefer just a check-script and manual intervention in case of failures.
This is the way we do it, we wrote some scripts and that we are using nagios.

[Viktor Balogh]

It is clear that key-based authentication is required, you need at least a central server with keys to every machine.

Anyway, it is very hard to write a script for an unknown environment....
(and please don't attach any specs here, I won't write this script, I don't like 'remote developing', there's too much to test, etc...)

[nightwich]

Hi Fernando


Take in consideration that if you create new LV's you need to change your package configuration.

I also think that you must consider do this manually.