ADSM-L

Re: password caches on shared disk?

2001-08-03 00:42:47
Subject: Re: password caches on shared disk?
From: Steve Harris <STEVE_HARRIS AT HEALTH.QLD.GOV DOT AU>
Date: Fri, 3 Aug 2001 14:26:54 +1000
Don't forget to set a long password change period.

If you leave it at 30 days, the password will change on the "usual" node, and 
when you fail over the password on the failover node will be out of date.

Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia

>>> bbullock <bbullock AT MICRON DOT COM> 03/08/2001 7:38:29 >>>
        Your experience is the same as ours. We encounter the same thing on
some HACMP pairs when we roll services between the hosts. It took us a while
to figure out why some would fail and others not, but we eventually found
that the encrypted password would not work on the a host whenever we would
change the hostname (such as we have to do on our Oracle hosts when we do an
HA roll).

        We too deduced that the TSM password is encrypted using the hostname
as a key (or something along those lines).

        Looking at your situation, I don't think you can get away with a
shared/encrypted password.

        Here's the only plan I can think of: Because the hosts mounting the
GPFS filesystem never change hostnames, why don't you point the passworddir
to a local directory on each GPFS client (as it is by default). You will
need to log into each host that mounts the GPFS filesystem initially to
set/encrypt the password, but never again because your hostname will not
change. The only issue is that you have to do this on all the hosts, and it
adds an extra step when you add new hosts into the configuration.

Ben Bullock
Unix system manager
Micron Technology Inc.


> -----Original Message-----
> From: asr AT ufl DOT edu [mailto:asr AT ufl DOT edu] 
> Sent: Thursday, August 02, 2001 2:58 PM
> To: ADSM-L AT VM.MARIST DOT EDU 
> Subject: password caches on shared disk?
>
>
> We've got some shared disk (GPFS, on a SP) which we are
> trying to back up in
> such a way that any of the sharing machines can perform the backup.
>
> Most pieces of this appear to be working well, but the cached password
> (passwordaccess generate) does not.
>
> Here's what I've done:
>
> All clients use identical copies of a dsm.sys that includes a
> stanza like:
>
> server GPFS
>        nodename gpfs_node
>        commethod...
>        [....]
>        passwordaccess generate
>        passworddir        /shared/disk/directory/
>
>
> And then I type
>
> dsmc q sched -se=GPFS
>
> and everything works.  So long as I stay on the same machine.
>  If I move to
> another machine, then I am re-prompted for a password.
>
> What I think is happening is that the passwordaccess generate
> transaction is
> NOT really a password for a _node_.  It is, instead, a sort of _host_
> authenticator, and thus is calculated (or whatever)
> differently on different
> hardware.
>
> Can anyone else shed some light on this?  Am I just missing a
> trick somehwere?
> Has anyone ever set up a password cache file that is visible
> to multiple
> boxes?
>
>
>
> - Allen S. Rout
>
<Prev in Thread] Current Thread [Next in Thread>