Password History Files

[Warren G Landrum]

I've got an Integrity Cluster (2 rx6600 nodes) running VMS 8.3 and DecNet Phase V and TCPIP 5.6-9.

Having a problem in that it seems as tho the Password History File is out of sync between the 2 nodes, even though there is only 1 file out there in the common area.

I'm basing this largely on what the Application (Trendstar) manager tells me is happening.

Now I KNOW I am having Decnet problems 9Can't set host to anywhere including self from one node) and when I try to run Net$configure to reconfig it on that node, I get a "NET$CONFIGURE-E-CKSREADERR", checksum read error, so I know I've got to get that fixed.

But my root question is, would the Password History file be using decnet in any way between nodes to keep itself in sync? I don't believe this is the case since there is only 1 file, but I'm jst trying to cover all bases and not rule anything out unless I'm absolutely sure it can/should be ruled out.

If anyone has any ideas, I can possibly supply more data, like errpr messages, etc.

Thx,

Warren

[Hein van den Heuvel · Accepted solution]

My guess is that there is a confusion between the OpenVMS password history file and some application file.
The VMS file is SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA, or whereever the(/system/exec) logical name VMS$PASSWORD_HISTORY might point to.

Is it NOT accessed with any network protocol, it should simply be a file on shared storage.

It is a simple indexed file with primary key being the username and the data a list of dates and password hashes. There is no NODE information in there best I know... allthough maybe the hash is node dependent. Dunno. I suppose that could be.

>> even though there is only 1 file out there in the common area.

Prove it to me!

On BOTH boxes issue:

$ dir 'f$parse("VMS$PASSWORD_HISTORY","SYS$SYSTEM:.DATA") /FILE/DATE=(CRE,MOD)

There is just 1 SYSUAF I hope?
'f$parse("SYSUAF","SYS$SYSTEM:.DAT")

The contructs above will do the logical name if it is there.

>> I'm basing this largely on what the Application (Trendstar) manager

Is that manager person or a piece of software?
Not that I would trust either..
I have yet to hear about software understanding OpenVMS password history, but I suppose that could be.

>> "NET$CONFIGURE-E-CKSREADERR", checksum read error, so I know I've got to get that fixed.

Hmmm.. you may have to 'blow away' some files and start from scratch.

>> would the Password History file be using decnet in any way between nodes to keep itself in sync

NO.

hth,
Hein.

[Warren G Landrum]

Thanks Hein,

The manager is a person - and I DO take what he says with a grain of salt. I'm sure the problem probably has to do with the App, but as usual, I've got to PROVE that it's not VMS.

Which files do you think I may need to blow away? - net$proxy.dat perhaps? - or some other ones? I don't want to make things any worse than they are - altho decnet is lightky used on this cluster, I still don't want to go backwards.

Thanks again...

Warren

[Hoff]

The NET*PROXY.DAT files are among the only ones that aren't directly part of the DECnet stack.

The shared files for a cluster are (at a minimum) those set forth in SYLOGICALS.TEMPLATE.

The easiest way to sort out which files are part of the DECnet-Plus database is to tip the DCL upside down and give it a good shake. A quick SEARCH and an EDIT or a vim pass shows how the CHECKSUM error is detected and reported, too.

To get close to the list of files:

$ search sys$manager:net*.com f$parse,.dat /match=and

But take a look at the code that generates the CKSREADERR and see why that's spewing.

I've also occasionally used the expediency of downgrading from DECnet-Plus to DECnet Phase IV. That can work for some cases, particularly if you don't need DECnet over IP.

And if random files are questionable or corrupt or missing here, then all bets are off.

(If you have a support contract, you could avail yourself of that. HP may well have a procedure to delete all of the files of the DECnet-Plus database for you.)

[Hoff]

ps: The password history file *is* one of the files that should be common. On a shared system disk, it is usually common.

$ sear sys$manager:sylogicals.template password
$! DEFINE/SYSTEM/EXECUTIVE VMS$PASSWORD_HISTORY SYS$SYSTEM:VMS$PASSWORD_HISTORY.DATA
$! DEFINE/SYSTEM/EXECUTIVE VMS$PASSWORD_DICTIONARY SYS$LIBRARY:VMS$PASSWORD_DICTIONARY.DATA
$! DEFINE/SYSTEM/EXECUTIVE VMS$PASSWORD_POLICY SYS$LIBRARY:VMS$PASSWORD_POLICY.EXE
$

[Hoff]

Another thread on this same topic points to MULTALLOC errors from an ANALYZE /DISK. There can be any number of triggers. This error can imply a disk or controller error, a rogue privileged application, a partitioned cluster, or a disk volume that is somewhere between partially and completely corrupt.