AMDS NOPRIV error

[Aaron Sakovich]

I just installed AMDS v3.4 across all 3 nodes in my cluster. One node, a satellite with only 1 enet i/f, works. The other 2 (each with 3 enets, only 2 of which are connected per server) deny access.

I've verified the info in the AMDS$Device_Access.dat file is identical on all 3 nodes -- *\{password}\c -- and that there were no errors during startup. Matter of fact, my PeeCee sees all 3 nodes, it just says NOPRIV, Not allowed to monitor node x|y. I get an alert in OpCom saying:

%%%%%%%%%%% OPCOM 28-FEB-2005 16:31:41.11 %%%%%%%%%%% (from node BUZZ at
28-FEB-2005 16:31:41.12)
Message from user RMDRIVER on BUZZ
RMA0: - No privilege to access from hardware address 00-08-C7-8A-E3-CC

So, I diligently added that MAC address to the list, no joy. I checked for AMDS$Device, but there was no such logical. I edited the AMDS$Logicals.com file to first point to EWA0, then EWB0 and did an @AMDS$Startup Restart in between.... No joy.

Checking further, the Restart did not define the logical! So I tried @AMDS$Startup NoDriver. No joy. I defined the logical manually. No change in the characteristics.

HELP! What am I not understanding here? Does a restart not really restart? Does a NoDriver not really load the logicals like it says it's supposed to? Why is it a wildcard security triplet won't allow access from my workstation on a system with 2 connected interfaces, but will on a node with 1?

I'm so confused...

TIA,
Aaron

[Andy Bustamante]

Tpassword in amds$driver_access.dat,needs to match the password on the PC side as well. There is a global password under "customize -- VMS -- Security"

[Aaron Sakovich]

Password: note my previous reference in paragraph 2, "... the AMDS$Device_Access.dat file is identical on all 3 nodes...". That includes the security triplet as indicated therein.

[Aaron Sakovich]

Correction: AMDS$Driver_Access.dat, not "device".

[Volker Halle]

Aaron,

the logical AMDS$DEVICE is only needed to direct RMDRIVER to use a specific LAN interface. You don't need that logical, if there's only one LAN interface or if the first LAN interface found by AMDS is the right one for your config.

You can check with

$ ANAL/SYS
SDA> SHOW LAN

on which LAN interface AMDS is running (look for string AMDS in the Client column).

If you change AMDS$DRIVER_ACCESS.DAT or AMDS$DEVICE, you need to stop and start AMDS using @SYS$STARTUP:AMDS$STARTUP RESTART

The logical and security file will only be read once during startup.

Volker.

[Aaron Sakovich]

That helps a little. So I now know that AMDS is bound to my EWA device. However, I'm still receiving the "RMA0: - No privilege to access from hardware address 00-08-C7-8A-E3-CC" errors.

Since there's no obvious reason to me why the system should be rejecting connection from this system when my security triplet says "*\password\c", I thought I'd try the other interface. But I don't see where that is necessary any more, as I know the driver is running and attached to an interface, and I am getting confirmation (of sorts) that my PeeCee is talking to the VMS host, by way of the no priv message.

I've run a Diff on the AMDS$Driver_Access.dat files, and there are NO differences in the security triplets between the system that works and those that don't.

Aaron

[Volker Halle]

Aaron,

try to stop AMDS using @AMDS$STARTUP STOP and then verify with SDA> SHOW LAN, that the AMDS protocol has disappeared.

Then restart with @AMDS$STARTUP START

If AMDS would not disappear, then the restart might not have read the modified AMDS$DRIVER_ACCESS.DAT

You can check, whether the security file will be accessed during start by using SET WATCH FILE

$ SET WATCH FILE/CLASS=MAJOR
$ @SYS$STARTUP:AMDS$STARTUP START
$ SET WATCH FILE/CLASS=NOMAJOR

Volker.

[Aaron Sakovich]

Hi Volker,

It did indeed remove the AMDS protocol. So that tells me that this portion is at least working properly.

Still no joy from the PeeCee side of things -- I still am only allowed to manage 1 of the 3 nodes.

Aaron

[Volker Halle]

Aaron,

you know my favourite OpenVMS tool ? It's SDA.

With SDA, you can easily locate the security triplets in nonpaged pool, so you can check, whether they are correctly stored and you can compare them between your working and failing systems.

My example is based on AMDS for E8.2, but it should work for you as well. If not, we'll need to add one step:

There seems to be a linked list (queue) of security triplets stored at UCB+170 (of the RMA0 UCB):

$ ANAL/SYS
SDA> SHOW DEV RMA0
SDA> VALI QUE/LIS UCB+170

Each security triplet entry in the queue is 0x40 bytes long. You can look at the first one with:

SDA> exa @(ucb+170);40
xxxxxxxx 00000040 825E0370 82618400 ..a.p.^.@.. FFFFFFFF.82618380
^^^^^^^^ MAC address of your PeeCee (0 would be *)
00000003 00575344 4D414345 443182FD ý.1DECAMDSW..... 82618390
FFFFFFFF 821252C8 826183BA 7BE93720 7é{º.a.à R...... 826183A0
00010072 4B0D0D0A 00000000 7B0C0480 ...{.......Kr... 826183B0

and the next one(s) with:

SDA> exa @.;40
...

One can easily see the password and access code R/W/C. Please check this on your systems.

Please note that being able to access this data with SDA is not a security problem, as you need CMKRNL and READALL ...

[Aaron Sakovich]

Cool, but I'm not SDA wiz, unfortunately. What does the following mean?

SDA> valid que/lis ucb+170

Entry Address Flink Blink
----- ------- ----- -----
Header 814701B0 00000000 814701B4

Error in forward queue linkage at address FFFFFFFF.814701B0, after tracing 0 ele
ments
%SDA-W-NOREAD, unable to access location 00000000.00000000

[Volker Halle · Accepted solution]

Aaron,

... this means that the offset to the security triplet queue (0x170) is different on your system/version of DECamds.

Could you please mail me the contents of the RMA0 UCB on your system ?

SDA> exa 81470040;300

Assuming that 81470040 is the UCB address of your RMA0 device as shown by SDA> SHOW DEV RMA0

Volker.

PS: You should be able to guess my mail address from my forum profile.

[Lawrence Czlapinski]

Aaron,
1. If you have an Alpha, you could try setting up AVAIL_MAN on the Alpha and see which nodes it sees. RMA0 should be the same ethernet device that the node uses to see the Alpha. I run an Alpha excursions window on my PC. It's more secure than running it directly on a PC. That is important for us since I can fix any node in our 2 site WAN.
2. There is a small possiblity that you may have AMDS$DRIVER_ACCESS.DAT in multiple directories. The directory used for the AMDS$DRIVER_ACCESS.DAT file was changed from AMDS$SYSTEM (V7.1 and earlier) to SYS$MANAGER (V7.2 and later).
$SET DEF AMDS$SYSTEM
$DIR AMDS*.DAT

Since you are seeing no privilege for that MAC, that suggests that you are on the right ethernet interface.
Lawrence

[Aaron Sakovich]

Whooha! You both win!

Volker showed me how to find out what the password being sent was, which turned out to be an old one from a prior version. Lawrence nailed it -- the old Driver_Access file was still in the old directory!

Thanks guys!

(I like your idea about running it off the VMS hosts, too -- I use both eXcursion and tunnel with SSH, so that would be the ultimate in a secure solution.)

[Volker Halle]

For documentation purposes:

The offset in the RMA0 UCB to the security triplet queue for AMDS V2.4 is UCB+100

Volker.