Apache CGI execution problems.

[bdalli]

We've installed the CSWS Apache 2.1 realease onto our VMS 8.2 Alpha cluster and can successfully serve up static web pages without a problem.
However we dont even get a response from the browser when we try executing a script of any kind. At the moment im simply tyrying to get a dcl which echo's the HTML header and a line of text but cant even get that to work.
Any clues would be greatly appreciated.
If it helps here is what we get in the error log.

"[notice] child pid 566294716 exit signal Illegal instruction (4)"


Thanks
Brad.

[Karl Rohwedder]

Brad,

was this an upgrade from a working V1.3 configuration or a new install?

We switched from SWS to WASD but had a V2.1 running, so I attached all lines regarding CGI from our HTTPD.CONF, may this helps.

Is something relevant in the logiles under APACHE$SPECIFIC:[000000]?


regards Kalle

[Robert Atkinson]

Brad - does the preinstalled procedure work? :-

htpp://node/cgi-bin/TEST-CGI-VMS

My guess is you've still got some code left over from a previous version, as that particular error is a 'catch all'.

Could you also send in your conf file.

Rob.

[bdalli]

Thanks for the quick response.

Kalle - The conf file is attached. I have tried a few things with this but nothing seems to fix it. I have installed it from scratch on a different (ODS-5 disk) than the previous V1.3 install.
I made sure that the previous webserver was not running first. That error came from the apache$specific logfile error_log.

Rob - The test http://node/cgi-bin/TEST-CGI-VMS procedure does not work either.
No scripts whatsoever.

[Robert Atkinson]

Have you rebooted in between? I'm wondering if there are some logicals or installed images left over?

Rob.

[bdalli]

This image wouldnt be a hangover from a previous install would it?
APACHE$HTTPD_SHR.EXE_ALPHA
I just ask as the disk it refers to is the one the old version was installed on, where all the other apache$ images reference the new ODS-5 disk we are using for the 2.1 install.

[Wim Van den Wyngaert]

Did you check the restrictions and known problems ?
http://h71000.www7.hp.com/openvms/products/ips/apache/csws_relnotes_21.html#newfeat

I've also read of flushing problems. The process dies before everything is flushed. If there are options for this try to toggle them (I'm using WASD, so no idea for CSWS).

Wim

[Robert Atkinson]

Should point to APACHE$SHARE :-

"APACHE$HTTPD_SHR" = "APACHE$SHARE:[000000]APACHE$HTTPD_SHR.EXE_ALPHA"

..which should point to your new ODS-5 disk :-

"APACHE$SHARE" = "$1$DGA1:[SYS0.SYSCOMMON.APACHE.]" (LNM$SYSTEM_TABLE)

If this isn't the case, looks like you may have found your problem!

I'd suggest a clean reboot, and then check the logicals.

Rob.

[Rick Retterer]

Brad,
It appears that you have not enabled your handlers for the CGI scripts in your cgi-bin directory.

Edit your httpd.conf file and search for the string "AddHandler"

Then when you find it, add the following entries just below that section like this:

# To use CGI scripts:
#
AddHandler cgi-script .cgi
AddHandler cgi-script .com
AddHandler cgi-script .exe


When you have completed this, save the file exit the editor and restart apache.

$@sys$startup:apache$startup restart

Then test it using this url:

http://localhost/cgi-bin/test-cgi-vms
http://localhost/cgi-bin/test-cgi-vms.com
-or-
http://localhost/cgi-bin/test-cgi-vms.exe


That should be all you need to do.

Cheers,
Rick Retterer
HP Services
SWS Support
Atlanta, GA.

[Robert Atkinson]

Rick - isn't CGI normally configured out-of-the-box, or has it changed in 2.1?

Rob.

[bdalli]

Rick - Yeah ive already tried that with no luck.

Rob - I tried reinstalling the package and noticed that the apache$httpd_shr.exe_alpha
image was not included.
So I uninstalled this image in case this was causing the problem but no luck with that either.

"APACHE$HTTPD_SHR" = "APACHE$SHARE:[000000]APACHE$HTTPD_SHR.EXE_ALPHA"

Was this from a 1.3 install or should the package contain these details in it?

[Steven Schweda]

I don't know if it's exclusive to 1.3, but
that's what I'm (still) running, and I have:

ALP $ sho log APACHE$HTTPD_SHR
"APACHE$HTTPD_SHR" = "APACHE$SHARE:[000000]APACHE$HTTPD_SHR.EXE_ALPHA;" (LNM$SYSTEM_TABLE)

[bdalli]

I have tried installing 1.3 and I do get those logicals APACHE$SHARE etc, but still the same problem.
Static pages are ok but no scripts. :(

I might try getting the sys admin to reboot as you suggest Rob. See if that makes a difference.

[Robert Atkinson]

Brad, a couple more thoughts.

A long shot, but try changing "Group #-1" to "## Group #-1".

I'm also wondering if this is a permissions problem. Can you send over a listing of the APACHE$WWW UAF account.

Can you also log in through this account and check you can see the CGI scripts. You'll probably need to temporarily give it LOCAL access.

Alternatively, try granting a DEFPRIV of BYPASS and trying the script.

Rob.

[Robert Atkinson]

P.S. Remember to restart the Apache service to pick up the new privs!

[bdalli]

Still no go.
I have attached the uaf details for apache$www but im pretty sure these are all ok.
I checked all the identifers and things and it all seems to be in order.
The files all seem to have the same identifiers and permissions on them as well.
Ive also included an example of the file attributes in the attachment.


Cheers
Brad.

[bdalli]

We gave the apache$www account CMKRNL and SYSNAM priv's and all sorted out.
Interestingly we have this version running on a similar cluster elsewhere without these account priv's. Not sure about that one but we're up and running and thats the main thing.


Thanks for the help guys.

Brad.

[Robert Atkinson]

Brad - good to see you got to the bottom of your problem :)

Cheers, Rob.

[Jan van den Ende]

Brad,

I have VERY ill feelings about CMKRNL and/or SYSNAM for an account like APACHE$WWW !!

For the time being tou are running again, but I STRONGLY suggest what exactly is different between this, and the other systems, then modify ASAP and revoke those privs again!
Right now anybody a little knowledgeable and with access to that webserver has GODLIKE CONTROL OVER YOUR MACHINE!

fwiw,

Proost.

Have one on me.

jpe

[Robert Atkinson]

Ooops !!!

Username: APACHE$WWW Owner: APACHE WEB SERVER
.....
Default Privileges:
CMKRNL NETMBX OPER SYSPRV TMPMBX


Good job we're only running an Intranet, but Jan is completely right in what he's saying.

Rob.

[Willem Grooters]

Brad,

APACHE$WWW requires no more than the normal VMS privilges TMPMBX and NETMBX to work properly. Any other privilege should be removed - ASAP.

That being said: Since it seems you have to raise privilege to get it to work, I guess something is wrong in access rights.
You should check the ownership and access rights of directory APACH$COMMON:[CGI-BIN] and APACHE$ROOT:[CGI_BIN], and of the commandprocedures in there, and all executables and other files involved. APACHE$WWW requires at least READ+EXECUTE on both directory, commandprocedures and executables. Usually that is accomplished by making APACHE$WWW owner of all that is based on APACHE$COMMON - one of the entries (IIRC the seecond) in APACHE$CONFIG deals with that.
More or less besides the point, but worthwhile to mention:
Another security precaution you can take is to set APACHE$COMMON and everything below, as "read-only" or even "No_access" for World and Group, and for those that really require WRITE or DELETE accesss, define rights-identifiers, give that the required access mdoes to the directroies and files where needed, and grant these identifiers to those that require them.

[Michael Yu_3]

Hi Brad,

From the V2.1 release notes.

Replacement for APACHE$FIXBG() Routine

In Version 2.x of the Secure Web Server, the apache$fixbg() routine has been replaced by the new apache$$setsocketopt() routine.

The apache$$setsockopt() entry point resides in APACHE$APR_SHRP.EXE.
.
.
.

This routine requires that the caller possess CMKRNL privilege, or have either the APACHE$APR_ALL or APACHE$APR_SETSOCKOPT rights identifier.

Thanks and regards.

Michael

[Ian Miller.]

Its much safer to grant those identifiers than CMKRNL

[bdalli]

Thanks for the help everyone.

We found that 1.3 looked like it was installed on the other node so once that node was rebooted and 1.3 completely removed we were able to get apache up running on both nodes. Albeit with CMKRNL privs.

I have since stripped back the APACHE$WWW account to contain only NETMBX and TMPMBX as suggested but am now having a problem starting the server. It seems that now I have to give the account SYSPRV to start the server. so we are progressing very slowly. Any ideas why the server wont start without SYSPRV?

[Willem Grooters]

APACHE neds to be started from a system account (or any other with suficient privileges) because it will INSTALL some software and create SYSTEM logicals. As stated in the manuals (and in the log of the installation) you can add the startup of Apache into the startup sequence (SYSTARTUP.COM or something called by that).

Once started, the installed image (that holds teh requied privileges) will be used to do everything that requires more than just the normal privilges (like assigning ports < 1024)