Item Subject: cc:Mail Text
Question, if an ADSM developer is listening... was running misc
integration tests the other day and had some oddities and was
wondering if the code was designed this way or just happened. Here is
the environment:
(sorry for the lack of specifics, security ya'know...)
server: rs/6000 390, Aix 4x, ADSM 2x, ethernet card to real world,
fddi card for test; ethernet x.x.83.x fddi x.x.26.x
client: Netframe, Novell Netware 4.x, ADSM client 2x, ethernet card to
real world (x.x.70.y); fddi for test (x.x.26.y)
we ran fiber between the two fddi cards.
The real stumpper was that after the server contacted the client for a
scheduled backup the server locked out the client & kept rejecting the
connection (until... I unplugged the ethernet line from the server?).
Here is my guess'ta'mation:
name server knew of client as x.x.70.y DID NOT KNOW x.x.26.y
ADSM server, in hosts file had client as nodenamT @ x.x.26.y
ADSM client in dsm.opt had nodenamT x.x.26.y (which in the manuals
states this is mainly to RETRIEVE files to another node)
It SEEMED that the server launched a packet to nodenamt x.x.26.y to
start a scheduled back up, when it got a packet back it seemed like it
saw REALNODENAME @ x.x.26.y and REALNODENAME <> nodenamT... (here is
what I guessed and worked so I'm wondering if I'm right) Sooo I
unplugged the ethernet link making the name server unreachable... What
I assume is:
server launched a packet to nodenamt x.x.26.y to start a scheduled
back up, when it got a packet back it saw REALNODENAME @ x.x.26.y
(REALNODENAME <> nodenamT), cked name server (ns) for REALNODENAME and
got back x.x.70.y, and/or cked ns for ip x.x.26.y and via local hosts
table got back nodenamT, thinking something was foul since
nothing=anything it broke off communications (foul as in disgruntled
employee trying to wipe out prod files from home pc via blank files
with production names)
YES, passwords were OK; YES, I cked server log... saw NOTHING! no
errors, no anything other than sched event starting, client session
started, client session ended. to continue... by breaking
path to ns server did: (more guess work)
server launched a packet to nodenamt x.x.26.y to start a scheduled
back up, when it got a packet back it saw REALNODENAME @ x.x.26.y
(REALNODENAME <> nodenamT), all paths to ns gone so had to use local
hosts file, did a lookup of REALNODENAME got back not found, did
lookup of ip x.x.26.y (which was ip of incomming packet) and got back
nodenamT (a match with the node definition), figured since node names
are just text entered by humans that the one in the packet was in
error and continued with the scheduled backup...
Am I close ? If you didn't design it this way you should advertise it
this way... "We even protect your backups from accidental overlay from
another node!" **********
Like, right, some person could accidentally screw things up so bad as
to have like file names on a totally different node and happen to know
a real node name and password and get the one machine offline while
his accidental machine took over the ip address...
Or did I just let out the secret that only the big corporate bosses
who make my yearly salary in a day know ? .... no matter... once
again, ADSM proves to me that we made the right choice in backup
software!
later
Dwight
Dwight Cook
Storage Administration
AMOCO Corp.
|
