Jeri,
Darn you for asking this question!
I have two AIX machines doing failover for an Oracle application. Machine A is
application development and standby, Machine B is production.
I have set up 5 clients, (when I say shared I mean failed-over : they never
access the data simultaneously)
Machine A non-shared BA client
Machine B non-shared BA clinet
Production shared BA client
Machine A Oracle backup agent
Production Oracle backup agent.
The Oracle client can't use passwordaccess Generate so for the production Oracle
agent I've got the encripted password file on a shared file-system.
There is a dsm.opt also on shared file system for each client, and I have a
script which sets up approprate environmment variables for all of this.
The dsm.sys on both systems lives in the usual ADSM directory and is the same on
both systems.
The reason for the cussin' is that I know I tested the Oracle portion of this
and had no problem. I'm sure that I must have tested the BA client part too,
but I can't actually remember doing so - so I'm gonna havfta do it again im my
next maint slot. This may not be for a couple of weeks, but I'll let you know
either way.
Steve
AIX/ADSM/Oracle/HACMP Guy
The Wesly Hospital, Brisbane Australia
"Bush, Jeri" <jbush AT TI DOT COM> on 02/02/2000 08:42:37
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: Steve Harris/Wesley)
Subject: Hostname change requires pswd validation
Fax to:
We have two Sun clients running Solaris 2.6 which we operate in a failover
mode. The clients are similar in configuration. These are running ADSM
client 3.1.0.7 backing up to server version 3.1.2.50. These clients use the
same password value. We use PASSWORDGENERATE for all of our clients.
ClientB's dsm.sys file contains:
- server stanza points to ADSM server name of 'BACKUP'
- nodename is coded as 'CLIENTB' for stanza 'BACKUP'
When operating in standard mode, ClientB backs up as expected to client node
'CLIENTB'. When we first set this up we use the admin command line to
'load' the password in the '/etc/adsm/BACKUP' file (again as expected). The
scheduler can then be started automatically.
When ClientA fails over to ClientB, it carries the hostname of 'ClientA'
with it. Unfortunately something in this causes the password verification
to fail the next time ADSM tries to do a backup..... even though the
hardcoded nodename of 'CLIENTB' did not change AND the password is the same
for both clients. Once we run the client app and enter the password, the
backups go to node 'CLIENTB' as desired. The password is updated in the
same file '/etc/adsm/BACKUP'.
When ClientB fails back to ClientA, we have to re-enter the password again
for ClientB since the hostname changed back to 'ClientB'.
Note: We realize that these backups are essentially 'stepping' on each
other but that is OK for the few instances when a failover occurs.
Before we write scripts to maintain multiple copies of the 'BACKUP' file and
move the appropriate one to the '/etc/adsm' directory I wanted to see if
anyone had a better suggestion for how to address this issue. I haven't
found anything in the documentation that says the the hostname is recorded
in the '/etc/adsm/....' file but it appears to be the case, unless something
else is happening to make this occur.
FYI: This scenario can be tested just by
1) add the 'NODENAME' parameter to your dsm.sys file
2) execute the backup client and 'q sched' to confirm your nodename
3) change the hostname on that client via 'uname -S newnodename'
4) execute the backup client (will be prompted to enter a new password for
the original nodename as entered in step 1)
We appreciate any assistance you can provide in this situation.
Regards,
Jeri Bush
Texas Instruments, Inc.
ADSM Enterprise Support
jbush AT ti DOT com
===========================================
This email message has been swept by MIMESweeper
===========================================
This email message has been swept by MIMESweeper
|
