ADSM-L

Re: Gene - syntax/punctuation for an object in a schedule

2006-01-20 21:36:23
Subject: Re: Gene - syntax/punctuation for an object in a schedule
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 20 Jan 2006 21:35:47 -0500
On Jan 20, 2006, at 5:08 PM, Gene Shaffer wrote:

Sadly enough, on the AIX system that this lives on, /backupset IS the
full
path to gen_backupset2.sh.

Then by all means have that in your specification.  Your original
posting
said  "./backupset/gen_backupset2.sh"  which is a relative, rather than
absolute, specification.  It's a great security risk for root to be
incited
to execute things from uncertain locations.  When constructing run
specs in
TSM, cron, or any other facility, use full, absolute paths to avoid
jeopardizing your system.  Getting root to run things it's not
expecting is
a classic security exploit.

I'm beginning to lose heart and start considering alternatives like
throwing this in crontab or maybe
some administrative immediate action schedule. I have tried a simple
test
script that merely does
[# cat  test.sh]

ID=blah
PASS=blahblah
dsmadmc -id=$ID -password=$PASS 'query node' >/backupset/test2.out

And still no reaction.

Perform some basic checks, in particular whether the test.sh file has
executable permissions set on it (as via 'chmod'), whereupon 'ls -l'
will
show permissions like "rwxr-xr-x".
Whereas schedules are managed by the TSM server, look in its Activity
Log,
where there should be ANR messages reporting problems with the schedule.
Naturally, there must be some kind of TSM receptor on the client node
which
is to run the scheduled command, being 'dsmc schedule' or dsmcad.
If the schedule seems fine to the server and there is a receptor
running on
the client, then look in the client schedule and dsmerror.log files for
indications of problems.

Figuring this out is just a normal part of becoming familiar with TSM
facilities.  We all do this at one time or another.  When something
doesn't
work, look around at all the points where evidence may be had: logs,
file
system object timestamps, accounting records, etc.  For example, when an
executable is run, it has to be read, and that updates its last-access
timestamp.

   Richard Sims