OSU won't startup - Proxy problem?

[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.)