Updating NETPROXY.DAT and NET$PROXY.DAT problems

[VMSdude]

I am currenlty cloning a two node VMScluster (V7.2-1) lets call them node1 & node2
The new nodes are called k1 and k2 I need to update 3,000 user proxies and replace the node1 and node2 with the new node names.

This is how I do it:-
$ ana/rms/fdl netproxy.dat
$ edit netproxy.dat/out=netproxy.txt
do a search and replace on the nodes with k1 and k2. Save the file and convert the txt file back to .dat format. No problems so far.

When you go into authorize and try view the updated proxyies. You get some very strange results. It like you are looking at a cached version of the file. You can't find any of the new DECnet proxies.

I also tries deleting the old files and also found an open file link to an old version, But you can sort this with a $SET SERVER /restart command to pickup the new file.

You can confirm the file are ok with a search and ana/rms you can see the new node names.

Backout the update to old files (these are the orignal file) but still doesn't work.

Some 16/17 hours later I can see the old nodes again.

Any ideas?

[Hein van den Heuvel]

Are you using the term 'netproxy.dat' as a shorthand, or is that the file you are dealing with?

Did you check around woth google?
It quickly leads to a faq entry suggesting you should be working on net$proxy.dat:

MGMT33.
:
"o the new NET$PROXY.DAT file that is initially created based
on the contents of the NETPROXY.DAT during the OpenVMS VAX
V6.1 upgrade and during the OpenVMS Alpha V6.2 upgrade.
This file is maintained in parallel with NETPROXY.DAT."

The new, NET$PROXY has counted strings in zero-filled columns. Those would be next to impossible to fix with an editor, unless your new node names have the same length.

I woudl recommend writing a script to to the changes in bulk through the proper command interface, and entry at a time.

Good luck!
Hein.

[VMSdude]

$ dir netproxy.dat, net$proxy.dat

Directory SYS$SYSROOT:[SYSEXE]

NETPROXY.DAT;1 18/18 8-JUN-2000 12:17:57.24
NET$PROXY.DAT;1 18/18 24-JAN-2001 11:56:43.99

Total of 2 files, 36/36 blocks.

$ uaf add /proxy xzy::system system/def
%UAF-I-NAFADDMSG, proxy from XZY::SYSTEM to SYSTEM added

$! Just checking!!!!!
$!
UAF> show /proxy xzy::system
Default proxies are flagged with (D)

XZY::SYSTEM
SYSTEM (D)

Authorize.exe appears to update both file together.
$ search netproxy.dat, net$proxy.dat xzy /stat /noout

Files searched: 2 Buffered I/O count: 7
Records searched: 18 Direct I/O count: 8
Characters searched: 1634 Page faults: 25
Records matched: 2 <<< Elapsed CPU time: 0 00:00:00.01
Lines printed: 0 Elapsed time: 0 00:00:00.00


Now edit both files and replace XZY with ZZZ

$ EDIT NETPROXY.DAT /OUT=NETPROXY.TXT
$ EDIT NET$PROXY.DAT/OUT=NET$PROXY.TXT

$ CONVERT/FDL=NET$PROXY.FDL
_Input: SYS$SYSROOT:[SYSEXE]NET$PROXY.TXT;1
_Output: SYS$SYSROOT:[SYSEXE]NET$PROXY.DAT

$ CONVERT/FDL=NETPROXY.FDL
_Input: NETPROXY.TXT
_Output: NETPROXY.DAT

$ SEARCH NETPROXY.DAT,NET$PROXY.DAT XZY
%SEARCH-I-NOMATCHES, no strings matched

$!
UAF> SHOW /PROXY ZZZ::SYSTEM
%SECSRV-E-NOSUCHPROXY, no proxy record matches your specification

Yet both file have been correctly updated.

$ SEARCH NETPROXY.DAT,NET$PROXY.DAT zzz /stat/noout

Files searched: 2 Buffered I/O count: 7
Records searched: 18 Direct I/O count: 9
Characters searched: 1634 Page faults: 27
Records matched: 2<<< Elapsed CPU time: 0 00:00:00.01
Lines printed: 0 Elapsed time: 0 00:00:00.00

$! search for the old node names after update
$!
$ SEARCH netproxy.dat, NET$PROXY.DAT; XZY
%SEARCH-I-NOMATCHES, no strings matched

$! This is what authorize thinks....
$!
UAF> show/proxy xzy::system
Default proxies are flagged with (D)

XZY::SYSTEM
SYSTEM (D)

I have over the past years updated thousand of rms file via this method never had a problem. Who is caching the files?

[Hein van den Heuvel]

>> %SECSRV-E-NOSUCHPROXY, no proxy record matches your specification

>> I have over the past years updated thousand of rms file via this method never had a problem.

But apparently none with this kind of interface.

>> Who is caching the files?

Uh... the security server "SECSRV" according the the error message reported?!

Proxies have a proper command line interface, as well as a fine API (SYS$DELETE_PROXY... http://h30266.www3.hp.com/odl/i64os/opsys/vmsos83/4527/4527pro_036.html#bottom_036 )

They appear to be using indexed files for permanent storage.

You thought you could use a backdoor and directly manipulate the file. It didn't work. So though! Use the front door, ring the darn bell already. It's easier! There's a nice, documented walkway versus the heap of discarded file you had to climb over to get to the backdoor.

A 'just curious' is of course fine at this point, but beyond that...

fwiw, If this was my production system, then I would be very unhappy if I learned that someone tried to 'manage' it this way.
It's unsupported, unsupportable, and reeks like security evasion.
You would need all your smarts to look for the next job.

Just an opinion!

Cheers,
Hein.

[Hein van den Heuvel]

Ah, I just noticed the topic subject line.

Most of the times I always pay close attention to the subject line, but this time I missed the fact that it mentioned netproxy as well as net$proxy.
Too bad that information was not repeated in the body and made me go of on the 'update the other file' tangent.

Anyway... just generate the darn update script like a good SA and move on.

Cheers,

Hein.

[VMSdude]

Update update the the two files by this method. Will write a script to replace and update with the new proxies. -Proxy thing!