CGI problem with CSWS

[Jim Crafton]

Hi, I've been assigned the task of tracking down a problem with our Apache (version Apache/2.0.52) install on OpenVMS. The server seems to work fine, and I can access regular html files fine. However cgi scripts don't seem to work at all. When you enter a URL into the browser, or through a telnet session, you get nothing at all back. No entry is made in the access_log, error_log, or cgi_log files.

In our httpd.conf we have the default cgibin directory specified:

ScriptAlias /cgi-bin/ "/apache$root/cgi-bin/"

I have made sure that the directory is marked as [rwe, rwe, rwe, rwe] in terms of file protection. Ditto for the actual files inside that I'm trying to execute. The files will run from a command line, and output the expected text.

The directory spec in the conf file is as follows:


AllowOverride None
Options None
Order allow,deny
Allow from all


Loglevel is set at "debug"

suExec is *not* enabled if this matters.

I've installed Apache on unix and windows machiens before without a hitch, so I'm completely lost as to what's going on, and I'm not very familiar with OpenVMS.

Any help would be most appreciated!

Thanks

Jim

[Steven Schweda]

> [...] [rwe, rwe, rwe, rwe] [...]

This looks like a very bad idea, but
otherwise it all looks about like mine.
Around here (old version, 1.x):

alp $ dire /owne /prot APACHE$COMMON:[000000]CGI-BIN

Directory APACHE$COMMON:[000000]

CGI-BIN.DIR;1 [AP_HTTPD,APACHE$WWW] (RWE,RWE,,)

alp $ dire /owne /prot APACHE$COMMON:[CGI-BIN];

Directory APACHE$COMMON:[CGI-BIN]

AUTHOR.DLL;8 [AP_HTTPD,APACHE$WWW] (RWED,RWED,RE,RE)
AUTHOR.EXE;8 [AP_HTTPD,APACHE$WWW] (RWED,RWED,RE,RE)
[...]


I don't know about this one, but some
programs refuse to deal with executables to
which anyone on the planet can write.

[Jim Crafton]

Steven,

Thanks, I know the global rwe permissions aren't good, but I've been just trying things to get it to work at all. At this point I'm giving up in defeat unless someone else points something out. Even the simplest DCL script fails to run, i.e. a file like this:

test.cgi:
$write sys$output ""
$write sys$output "Hello World"
$write sys$output ""
$ exit

Works from a command line, but then accessed via URL, nothing is sent back, and nothing appears to be executed, it's as if the request just disappears into a black hole (unix's /dev/null).

[Hoff]

Reposting as ITRC (again) blew up. Apparently ITRC decided I wasn't logged in, in mid-submit. Go figure.

Given the gremlins I see after the websites I manage, any directories that are owned by or that are otherwise writable by the web server is a Bad Idea. A Very Bad Idea.

My preference is to use an ACE to grant the web server read access (or read and execute for the CGI pieces) to the web-related directories. I use the same technique on the Unix boxes.

As for your question, have a read through Neil Rieck's notes on OpenVMS Apache and Tomcat and such:

http://www3.sympatico.ca/n.rieck/docs/openvms_notes_apache.html

Then (also) check the Apache server logs.

If you're not specifically tied to Apache, then (like Unix offers nginx, lighttpd and such) OpenVMS has the WASD web server available:

http://wasd.vsm.com.au/

I have some DCL CGI posted to my site, but Neil's stuff and the Apache logs should get you going.

Stephen Hoffman
HoffmanLabs LLC

[Jim Crafton]

I'll check out the link. Unfortunately, absolutely *nothing* is being written to any of the apache logs for any cgi URL request. So access_log, error_log, and cgi_log are all unchanged. I have set the logging level to "debug", so theoretically I should be getting pretty much everything. And for normal URL requests I do see entries made in the access_log or error_log (if it's a bogus url). But for anything in the cgi-bin directory, absolutely nothing.
Is there no way to tell if the file is being executed?

Thanks

Jim

[Steven Schweda]

> [...] Unfortunately, absolutely *nothing*
> is being written to any of the apache logs
> for any cgi URL request. [...]

Are you flushing the logs? I'm still running
the older 1.x server, and it had a defect
where the obvious flush operation

@ SYS$STARTUP:APACHE$STARTUP.COM FLUSH

tended to lose log data, but

@ SYS$STARTUP:APACHE$STARTUP.COM graceful

is pretty effective.

> Works from a command line, but then
> accessed via URL, nothing is sent back,

Well, yeah, but it's not really sending back
a proper response, is it? I seem to have an

APACHE$COMMON:[CGI-BIN]TEST-CGI-VMS.COM

which, I assume, came with the Web server,
and which works as expected. If you don't
have one, let me know.

> [...] I'm not very familiar with OpenVMS.

For an explanation of what all that f$fao()
stuff is doing, try:

HELP Lexicals F$FAO *

In particular:
[...]
Special formatting:
!/ None Inserts a carriage return and a line
feed.
[...]

I believe that the CR may be important in
HTTP.

[Steven Schweda]

Oh, yeah.

> Is there no way to tell if the file is
> being executed?

It's DCL, so it could do things like create
a file, or send e-mail, or any number of
detectable things.

[Jim Crafton]

Yes, I have the "TEST-CGI-VMS.COM" file, and again, it does run correctly from the interactive commandline, but when requested in a URL, nothing happens, no data is returned at all, and no data is written to any of the logs, no matter what I do in terms of trying to execute cgi scripts.
In the 2.x apache series the flush option is non-existant, and the graceful option, according to the start.com file, is used to gracefully restart the server. It didn't make any difference.
I have no doubt this will be something mind-numbingly obvious once I find it, but until then I'm up the creek without a paddle.

[Hoff]

Please post (attach) the (whole) HTTPD.CONF file.

When "No entry is made in the access_log, error_log, or cgi_log files", is that no entries are made for anything, or is that no entries for (just) the CGI requests?

Are the directory ownership and protection settings correct, from the CGI directory all the way up? The upper levels will need at least execute-only access, or read-execute, for the Apache user.

[Jim Crafton]

the cgi-bin directory is marked (rwe,rwe,rwe,rwe). Yes I'm aware this is bad, but for the moment I'm just trying to get the damn thing to work.

No entries in the various log files are made for any cgi related request. A regular HTML request for a file from the htdoc dir will show as expected.

I've attached the httpd.conf file.

[Hoff]

Each directory has a protection setting (visible via the DIRECTORY /SECURITY command), as does each subdirectory, etc. Which means you need to check the protections on CGI-BIN.DIR, and every directory in the path above it. (The OpenVMS disk structures are completely different than those of the typical Unix file systems, so bear with me here...)

On the local TARGET:: box...

$ show log apache$common
"APACHE$COMMON" = "TARGET$DKA100:[SYS0.SYSCOMMON.APACHE.]" (LNM$SYSTEM_TABLE)
$

Here, this means SYS0.DIR, SYSCOMMON.DIR, APACHE.DIR and CGI-BIN.DIR must all have at least EXECUTE, if not READ access.

File and directory ownership is also subtly different than Unix, too.

Please don't set the file ownership and the protections wide open here. Ok, that was a reasonable test, and it didn't help, so please (re)set the protections correctly. (The better way to test for that sort of stuff is usually with the OpenVMS security alarms; with enabling and monitoring the file access failure auditing or alarms via the SHOW AUDIT and SET AUDIT commands.)

Here are the differences between your httpd.conf and one locally (that works)...


$ diff APACHE$COMMON:[CONF]HTTPD.CONF,SYS$LOGIN:X.X
************
File HTTPD.CONF;4
155 #Listen 80
156 Listen 10.1.2.1:80
157
******
File X.X;1
156 Listen 80
157
************
************
File HTTPD.CONF;4
437 #
******
File X.X;1
437 ScriptLog logs/cgi_log
438
439 #
************
************
File HTTPD.CONF;4
442 LogLevel warn
443
******
File X.X;1
444 LogLevel debug
445
446
************
************
File HTTPD.CONF;4
562 Options None
563 Order allow,deny
564 Allow from all
565
******
File X.X;1
565 Options ExecCGI
566 Order allow,deny
567 Allow from all
568 # AddHandler cgi-script .cgi .pl
569
************
************
File HTTPD.CONF;4
890 # Alias /error/ "apache$root/htdocs/error/"
891 #
892 #
893 # AllowOverride None
******
File X.X;1
894 # Alias /error/ "/apache$root/htdocs/error/"
895 #
896 #
897 # AllowOverride None
************
************
File HTTPD.CONF;4
1006 Include /apache$root/conf/mod_php.conf
******
File X.X;1
1010 Include /apache$common/conf/mod_perl.conf
1011 Include /apache$root/conf/mod_php.conf
1012
************
...
DIFFERENCES /IGNORE=()/MERGED=1-
HTTPD.CONF;4-
X.X;1

The CGI DCL also has the (poorly documented) APACHE$EXECUTE identifier assigned, if you're looking to override protections and ownerships. In very, very loose terms, adding this identifier to the ACL on the object is very roughly akin to setting a Unix group ID on the files involved that allows the web server access.

And for completeness, here's the invocation that I used to test this stuff:

http://target.example.com/cgi-bin/test-cgi-vms.com

[Willem Grooters]

Add a line

AddHandler cgi-script .cgi .com

in your configuration, alignged with the other AddHandler lines (and not within a block).

What happens now is that .COM is not recognized as a script so it won't be executed.