[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference humane::scheduler

Title:	SCHEDULER
Notice:	Welcome to the Scheduler Conference on node HUMANEril
Moderator:	RUMOR::FALEK

Created:	Sat Mar 20 1993
Last Modified:	Tue Jun 03 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1240
Total number of notes:	5017

1091.0. "Agent proxy problem" by COMICS::MILLSS (Dr Who : He's Back... And Its About Time !) Tue May 07 1996 08:30

I have a problem with a customer who is using V2.1B-1 of the Scheduler Agent and
V2.1B-7 of the server, both are VMS systems. The agent does a look up in
NETPROXY of the incoming user and node name and rejects the connection with the
following -

411:            in validate_proxy
411:            clientname: loncmvs1575.uk.paribas.com
411:    in RUSEROK (check proxy)
411:    checking NETPROXY.DAT for remote user SYSTEM  from node LONCMVS1575 
matching local user system
411:    proxy check - nodes or users are the different
411:    proxy check - checking NETPROXY.DAT for user: SYSTEM   from node:
LONCMVS1575
411:    proxy check - failed to find record matching user: SYSTEM  from node
LONCMVS1575; check fails
411:            status of ruserok: -1
remote proxy access denied411:          status of validate proxy = -1
*** validation error: -8
Job failed to execute


The server and agent are both VMS systems, but because they are running Unix and
VMS systems on a global scale all systems have a Unix "style" hostname with the
VMS systems having aliases for their DECnet nodename.

The question I have is, would the agent reject the connection based solely on
the fact that the incoming nodename is seen to be more than the 6 character
DECnet nodename standard ? They have created proxies for all possible
combinations of the incoming nodename but to no avail. A proxy for
LONCMVS1575::SYSTEM *does* exist.

Any hints/answers/suggestions/etc greatly appreciated.

Regards,

Simon R. Mills
South UK CSC

T.R	Title	User	Personal Name	Date	Lines
1091.1	Maybe you should upgrade	IJSAPL::PEURSUM	Systems Specialist, EIS Holland	`Tue May 07 1996 12:05`	16
	Simon, I'm not sure if this helps, but i know that there were some problems regarding proxy's, like only looking at netproxy.dat in sys$system instead of evaluating the logical netproxy etc.. The latest kits that should solve these problems are: * agent : V2.1B-5 * server : V2.1B-9 Ask Bob Puishuys (MUZICK::PUISHUYS) for a pointer and a proxy to a customer kit. Regards, Paul.
1091.2		COMICS::MILLSS	Dr Who : He's Back... And Its About Time !	`Tue May 07 1996 12:28`	12
	Paul, Thanks for your suggestion, but I'd already thought of telling my customer to upgrade. I don't want to suggest this unless I can be certain that it will fix the problem. I am running server V2.1B-4 and agent V2.1B-1 and can get it all to work properly. The same setup on my customer's system doesn't work. The only difference being their ucx hostnames are longer/different than their DECnet nodenames. Simon.
1091.3	Its IPMT time again.	COMICS::MILLSS	Dr Who : He's Back... And Its About Time !	`Wed May 08 1996 08:54`	3
	I have just IPMTed this problem. If I remember, I'll post the resolution here. Simon.
1091.4	NETPROXY.DAT ?	IJSAPL::PEURSUM	Systems Specialist, EIS Holland	`Wed May 08 1996 12:04`	10
	Simon, I found out yesterday with Agent V2.1b-5 that he/she is only looking at NETPROXY.DAT in SYS$SYSTEM... it ignores the logical. Maybe worth to try out? Regards, Paul.
1091.5	confused........	CSC32::G_BURTT		`Wed May 08 1996 12:16`	3
	I thought that the logical issue was what AGENT 2.1B-5 was supposed to fix???? Gary Burtt
1091.6	Still a bug ?	IJSAPL::PEURSUM	Systems Specialist, EIS Holland	`Wed May 08 1996 13:30`	30
	Gary, My thoughts exactly... But when we tried, i continously got the following errors : Running job 100 on remote node BVGAXP... SEND_REMOTE_RUN failed, status : 211192466 %NSCHED-E-EXEBADPROX, executor: invalid proxy Remote Node=<BVGAXP> Remote User=<DEC_BEHEER> When we copied the file NETPROXY.DAT to SYS$SYSTEM, it worked instantly: Running job 100 on remote node BVGAXP... SEND_REMOTE_RUN: success The logical was defined as : "NETPROXY" [exec] = "SYSFILES:NETPROXY.DAT" (LNM$SYSTEM_TABLE) So, it still seems to be a problem... I know that V2.1B-5 should fix another proxy problem, being if the two usernames were not of equal length.. Still a bug ??! Regards, Paul.
1091.7	It works on VAX/DECnet Phase IV	IJSAPL::PEURSUM	Systems Specialist, EIS Holland	`Wed May 08 1996 15:04`	14
	By the way... I've installed an Agent V2.1B-5 on a VAX with OpenVMS V6.2/DECnet Phase IV, and there it works OK with NETPROXY logical... On the AXP with OpenVMS V6.2/DECnet Phase V is didn't work !! So, is the architecture the problem, or DECnet/OSI ? Regards, Paul.
1091.8	Confused ? You will be, after this week's episode of Soap !	COMICS::MILLSS	Dr Who : He's Back... And Its About Time !	`Thu May 09 1996 08:22`	12
	WAG: I think that there is a fundamental problem with the agent making some rather large assumptions about the format of incoming usernames and nodenames. Also, FWIW, NETPROXY.DAT is in SYS$SYSTEM (on mine and my customer's systems) with no logicals pointing anything anywhere else. Simon P.S. WAG = Wild A**d Guess, a phrase I learned from our American cousins in another conference ! I like it, so I use it a lot now !!! P.P.S. I shall definitely* post the outcome of my IPMT here.
1091.9		MRBASS::PUISHYS	Project Leader Scheduler V3.0 for Digital UNIX	`Mon May 13 1996 14:19`	23
	The vms agent is a direct port of the unix based agents code :^( It looks into the netproxy.dat I also posted a response to the IPMT case. The VMS agent will not accept a proxy whos node name is longer than 6 char. thats the deal and nothing you all try will solve it. for customers who have unix type names you have a big problem. You have to use ucx for network communication, but the proxyies are check in netproxy.dat, just like the v2.1 server. if you look debug in .o the node name sent is to long. 411: proxy check - checking NETPROXY.DAT for user: SYSTEM from node: LONCMVS1575 I am not sure of all the bugs fixed in -5 of the agent. I do know -5 fixes a problem with the lengths of the username being differenet. But I think there are still outstanding ipmt cases where the logical is not being translated correctly. bob
1091.10	Wrapping up the discussion... (Thanks, Bob)	COMICS::MILLSS	Dr Who : He's Back... And Its About Time !	`Tue May 14 1996 09:43`	4
	I got my customer to reconfigure his UCX setup to use 6 character host names and now everything works perfectly. Customer "happy". Simon.
1091.11		MRBASS::PUISHYS	Project Leader Scheduler V3.0 for Digital UNIX	`Tue May 14 1996 14:01`	4
	Great glad to here it. Once we move every thing to v3.0 someday we will deal with this. Bob
1091.12	i still have a problem	CSC32::G_BURTT		`Wed May 22 1996 14:41`	8
	I have a customer that is running 2.1B-9 on a VAX4000 and 2.1B-5 on an ALPHA agent. Server name is OMRVCS client name is OMRDB4. The proxy file was not in SYS$SYSTEM on the client - operations failed. Copied the netproxy.dat file to SYS$COMMON:[SYSEXE] and everything worked. Appears that it is still a problem or am I missing something????? Gary Burtt Colorado CSC