[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 05: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.RTitleUserPersonal
Name		DateLines
1091.1Maybe you should upgradeIJSAPL::PEURSUMSystems Specialist, EIS HollandTue May 07 1996 09:0516
    
    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.2COMICS::MILLSSDr Who : He's Back... And Its About Time !Tue May 07 1996 09:2812
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.3Its IPMT time again.COMICS::MILLSSDr Who : He's Back... And Its About Time !Wed May 08 1996 05:543
I have just IPMTed this problem. If I remember, I'll post the resolution here.

Simon.
1091.4NETPROXY.DAT ?IJSAPL::PEURSUMSystems Specialist, EIS HollandWed May 08 1996 09:0410
    
    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.5confused........CSC32::G_BURTTWed May 08 1996 09:163
I thought that the logical issue was what AGENT 2.1B-5 was supposed to fix????

Gary Burtt
1091.6Still a bug ?IJSAPL::PEURSUMSystems Specialist, EIS HollandWed May 08 1996 10:3030
    
    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.7It works on VAX/DECnet Phase IVIJSAPL::PEURSUMSystems Specialist, EIS HollandWed May 08 1996 12:0414
    
    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.8Confused ? You will be, after this week's episode of Soap !COMICS::MILLSSDr Who : He&#039;s Back... And Its About Time !Thu May 09 1996 05:2212
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.9MRBASS::PUISHYSProject Leader Scheduler V3.0 for Digital UNIXMon May 13 1996 11:1923
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.10Wrapping up the discussion... (Thanks, Bob)COMICS::MILLSSDr Who : He&#039;s Back... And Its About Time !Tue May 14 1996 06:434
I got my customer to reconfigure his UCX setup to use 6 character host names and
now everything works perfectly. Customer "happy".

Simon.
1091.11MRBASS::PUISHYSProject Leader Scheduler V3.0 for Digital UNIXTue May 14 1996 11:014
Great glad to here it.  Once we move every thing
to v3.0 someday we will deal with this.

Bob
1091.12i still have a problemCSC32::G_BURTTWed May 22 1996 11:418
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