further details of my problem, it also occurred on password expiration,
and I have also gotten the shrug.
the only suggestion was on the managed server delete all profiles, delete
server and rebuild which
leaves me a little wary. what am I going to miss (especially as I did
not build it and it is not very well
documented)
The other thing that I noticed was that the profiles on the configuration
server were owned/last updated by
TSM admin who had moved on and I had removed them as admins. They
stopped working until I updated them
(I did so as admin so this would not happen again)
I have been able to get remote db backups working again by updating the
configuration servers passwords to match
what my record show the old passwords were but configuration replication
is still failing . I guess this is using
a password that I do not know.
Allan Mills | AIX and TSM Administrator
Business & Technology Services | New South Wales Police
8835 9286 (internal 29286)
"Allen S. Rout" <asr AT UFL DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
28/01/2006 02:31
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Re: [ADSM-L] Managed Server Passwords out of sync
>> On Fri, 20 Jan 2006 13:00:37 -0500, "Allen S. Rout" <asr AT ufl DOT edu>
>> said:
>> On Fri, 20 Jan 2006 08:05:42 +1100, Allan Mills
<mill2all AT POLICE.NSW.GOV DOT AU> said:
>> Folks
>> I have 2 TSM servers and a couple of days ago remote db backups
>> started to fail the error message is below:
> I have a PMR going about precisely this behavior, AIX 5.2, TSM
> 5.3.2.1 Will echo conclusions; so far the interaction has
> been... unedifying.
I've gotten what amounts to a shrug. I'm trying to escalate. Anybody
else have server volumes start to fail after a 5.3 upgrade? What
seems to happen in my case is that for the first server password
expiration after the upgrade, the automatic password update fails. If
you're using these remote volumes for DBBACKUPTRIGGER, then your
incremental at the trigger point fails. Result coredump in [mumble]
days. If you're not in rollforward, you might not notice the failure
unless you're checking recentness of DB backups.
Anyone else seeing a similar failure?
Here's a log snippet of a failure on the volume-client actlog
01/18/06 08:10:01 ANR4373E Session rejected by target server CTRL,
reason: Authentication Failure. (SESSION: 65036)
01/18/06 08:10:01 ANR4383E Session failure, target server CTRL has
aborted current transaction; reason: Transaction failed. (SESSION: 65036)
01/18/06 08:10:01 ANR4379E The source server was unable to update
the password on target server CTRL. (SESSION: 65036)
and here's the volume-server
01/18/06 08:10:01 ANR0406I Session 71109 started for node INT
(AIX-RS/6000) (Tcp/Ip tsm2en1.cns.ufl.edu(43034)). (SESSION: 71109)
01/18/06 08:10:01 ANR0425W Session 71109 for node INT (AIX-RS/6000)
refused - password has expired. (SESSION: 71109)
01/18/06 08:10:01 ANR0403I Session 71109 ended for node INT
(AIX-RS/6000). (SESSION: 71109)
01/18/06 08:10:01 ANR0406I Session 71110 started for node INT
(AIX-RS/6000) (Tcp/Ip tsm2en1.cns.ufl.edu(43036)). (SESSION: 71110)
01/18/06 08:10:01 ANR0500W Transaction failed for session 71110 for
node INT (AIX-RS/6000) - invalid password submitted. (SESSION: 71110)
01/18/06 08:10:01 ANR0479W Session 71110 for server INT
(AIX-RS/6000) terminated - connection with server severed. (SESSION:
71110)
That first rejection appears to be a "correct" failure, noting the
expiration. The second is the problem.
It seems almost like the volume-server is keeping more than one
version of the password around; one is used for ongoing operations,
and another different store is consulted when you go to update. The
same volume-client - volume-server combination had a successful backup
three hours before the failure quoted above.
- Allen S. Rout
All mail is subject to content scanning for possible violation of New
South Wales Police
electronic Mail Policy. All persons are required to familiarise themselves
with the
content of the policy located on the MEMO Bulletin Board and on the NSWP
Intranet.
This message and any attachment is confidential and may
be privileged or otherwise protected from disclosure. If you
have received it by mistake, please let us know by reply
and then delete it from your system; you should not copy
the message or disclose its contents to anyone.
|
