OSU won't startup - Proxy problem?

[Willem Grooters]

I have a problem with starting OSU on a new system, and I think it has to do with DECNet and proxies.
The system is very basic (just for testing), VMS 7.3-2, DECNet-Plus and TCPIP 5.3,m stanalone; the only real diference is that the files concering authorisation (SYSUAF, RIGHTSLIST, NETPROXY and NET$PROXY) need to reside off the system disk. Redefining the system logicals for these files is done in SYLOGICALS.COM (after the disk on which they reside has been mounted), and the system has rebooted.

After that, I installed OSU (3.8, since my customers use that version) following the book on Webservers on VMS. The test ran Ok. After that, I created a user and proxies (OSU_38) and attempted a start of the server. But that fails. I also tried specifying the passowrd (should not be needed) and that fails as well, but different.
Given that output, I suspect that the proxies are not used, for some reason. But none of the files on their usual location - on the system disk, are open.

Details on the installation and results are mentioned in the attachement.

Is there anything I missed?

(I tried the OSU mailing list, it's not off-line (mail isn't rejected) but it seems no longer active????)

[Wim Van den Wyngaert]

Willem,

The accounting record says that the remote id is OTWILLEM. For this user you didn't setup a proxy.
You have to login as OSU_38 to use the proxy or add another one.

Wim

[Wim Van den Wyngaert]

And I think the script is not able to handle parameters that contain spaces.

Wim

[Willem Grooters]

I thought about that but it doesn't help, see attachement.

What use would a password be? That's what proxies are all about, isn't it?

[Kris Clippeleyr]

Wim,
I think there's something wrong with the proxies. On our systems with the OSU webserver, we run it under WWW_SERVER, and have the following proxies:

$ mc authorize
UAF> show/prox *::www_server

Default proxies are flagged with (D)

VMS02::WWW_SERVER
WWW_SERVER (D) SYSTEM

LOCAL:.VMS02::WWW_SERVER
WWW_SERVER (D) SYSTEM
UAF>

Hope this helps.
Kris (aka Qkcl)

[Wim Van den Wyngaert]

Intrusion active ?
Which decnet ? Default settings for session control ?

Wim

[Wim Van den Wyngaert · Accepted solution]

Or try to setup a proxy using *::user
to see if it has something to do with node naming servers.

Wim

[Willem Grooters]

Proxy problem - that's my idea.
Kris, I added a few that make sense but it doesn't help at all. Same problem, no matter what.
Wim, DECNetPlus - VERY basic. I just configured name translation (MOMAIN,LOCAL), and done nothing more than that. See attachement for your question.

[Wim Van den Wyngaert]

Willem,

In accountng I see
Remote full name: 1025

On mynode (no DNS) I see LOCAL:.NODE.

Is that normal ? Should the proxy not mention that number ? Did you try the *::us ?

Wim

[Willem Grooters]

Added *::osu_38 osu_38/default - no change
Added *::system osu_38 and *::otwillem osu_38.

Now the server starts, but I still have to find out what caused it: the SYSTEM entry or my own. I don't like the wildcard idea but for the moment, I can live with it.

Next question: how to find out what is the RIGHT entry I should add?

[Willem Grooters]

The machine requires the domain as stated since it is foreseen that "outside users" (Dutch Police) will access the machine to preview changes we've made to the application and the web-interface.
B3ecause the machine is in TCPIP-DNS I haven't enabled DECdns as a resolver in DECnet. Nor has anything been added in the local database (since there is no need to do so). Perhaps a better idea to specify just LOCAL for resolving names?

[Wim Van den Wyngaert]

In the operator log file I get a detailed error message for each violation. Could that help ?

Wim

[Kris Clippeleyr]

Willem,
Did you register the node in its "LocalFile" (DECNET_REGISTER)?
Did you enable Phase IV aliasing?
Just some thoughts.
Kris (aka Qkcl)

[Willem Grooters]

Kris:
No
Yes (1.1 - and that may cause a problem if the same has been used elsewhere - which is quite likely ;-)))

I think I'll make DECnet resolve LOCAL only, because I don't need anything else; the machine will not be accessed by a DECNet connection anyway; Just OSU that requires it.

[Willem Grooters]

Works - not entirely as I want it but I can get on for the time being

[Willem Grooters]

Rejoiced too early. OSU ran but I have trouble setting up the mapping and security on the files (which has nothing to do with this issue). I had to reboot the machine, and in the process of booting, OSU is started. It seems to work fine, there is a process named "WWW server 80" but after some time this is renamed to sever_. analyzing it, this process is running NET$SERVER.EXE, not HHTP_SERVER.EXE, what I would expect. Any attempt to access the server fails it cannot find the server, and privreauest - thec ommandline interface, cannot access it either - it keeps telling me that the connection is refused. Analyzing the process reveales no connection to TCPIP nor DECNet.

I tried removing the process and all installed images, residing on the server directory structure, and restart the server by hand - very much the same.

It's not a proxy issue, since the proces does start up. It just wont get so far as accepting rquests.

Next, I removed ALL of OSU and rebuild from scratch - except DECNEt has now been set up so I would expect the server to startup. But no: the very same problem.

No chnages in DECNet (IIRC).

[David Jones_21]

I stay away from DECnet-plus. Proxies in phase IV is tempermental enough, especially if you try turning it on after you've already had an authentication failure with them turned off. Once everything is setup and propagated through the system, it should be fine.

If the process changes its name from "WWW server 80" to server_xxxxxxxx, then the server program is failing and the process is reverting to a DECnet netserver process. There should be an http_startup.log file in the login directory of the OSU_38 account and possibly an http_server.log in www_root:[system] that you can look at for clues.

[David Jones_21]

Kris Clippeleyr writes:
" Wim,
On our systems with the OSU webserver, we run it under WWW_SERVER, and have the following proxies:

$ mc authorize
UAF> show/prox *::www_server

Default proxies are flagged with (D)

VMS02::WWW_SERVER
WWW_SERVER (D) SYSTEM

LOCAL:.VMS02::WWW_SERVER
WWW_SERVER (D) SYSTEM
"
The server does not normally need to run processes as system, so the proxy from WWW_SERVER to SYSTEM is not needed and potentially dangerous. The SYSTEM to WWW_SERVER proxy is so system startup can get the server process created with the right username. The WWW_SERVER (default) proxy to itself is needed so the DECnet tasks used for scripts can be created. You possibly could have a situation where a script directory runs the scripts as SYSTEM, but that is not the default configuration.

[Willem Grooters]

David,
It shouldn't matter whether it's DECNet IV or DECNetPlus - I got the system with DECNetPlus installed, and it DID work. It's just after reboot that I didn't get it running.

[Willem Grooters]

It turned out that the script that starts up the server, defined WWW_ROOT and WWW_SYSTEM, as /SYSTEM, without /EXEC. HTTP_STARTUP.COM defines them again, as /SYSTEM/EXEC. References are EXACTLY the same, but causing havoc, as it showed. After I removed the definitions of these logicals in the startup script, all went flawlessly, even after reboot.

(BTW: Alan Winston's book talks about "Brian Reed's TEST_SERVER.COM procedure. I tried to locate that but www.iron.net seems no longer existing. Google didn't show it up either.)