5/8 I noticed the posting about about CGI being enabled again, but
my CGI files don't seem to work. Has the setup changed in some
way, are others also still having problems? Thanks
\_ CGI scripts don't seem to be working for me either. --jameslin
\_ They were enabled, but due to a misconfiguration, i.e. choice of
user/group for CSUA home page, someone used a random hoser's badly
written cgi to deface the CSUA web page. Thus, they were disabled.
-dans
\_ ouch! thanks for the info. So is CGI not going to be available
any more, then? Should we be using PHP or something else instead?
\_ I'm not on soda root, I'm just filling in folks on current
history. As tom indicates, PHP suffers from similar
problems. My understanding is that they are working on it,
but, being students, have lots of other obligations that
supercede making improvements to our little playground. -dans
\_ The solution to that is to do a find and fix files owned by
nobody/www, not disable CGI. You can do the same thing w/ PHP!
\_ Yes, and now the web server is running as "nobody", which I
think is not ideal practice ("nobody" is used by too many
things; the web server user should be unique to the web
server), but should remove the concern about CGIs (which
are no more problematic than PHP). -tom
\_ Ed claims he just enabled CGI's. -dans
\_ Okay, now I'm getting "Premature end of script headers" errors,
but these scripts worked fine on the old FreeBSD iteration of
soda. I'm basically just doing:
#!/bin/sh
echo "Content-type: text/html"
echo ""
echo "<html><body><p>blah</p></body></html>"
Also, are the permissions on the apache logs going to be changed?
It's sometimes useful to be able to read the error log to figure
out what's failing.
\_ It's really hard to say without seeing your script. Maybe
your path to echo is not set properly? I'm not root, and as
far as I know, root doesn't read the motd (at least not as a
source of the more things to do). Why don't you try mailing
root? -dans
\_ Perl cgi is working fine. Most likely, path is not set
properly.
\_ No, it's not a path problem. The problem went away when
I made the script world-readable instead of just
world-executable. Why should that matter?
\_ because the web server can't read the script if it's
not readable. duh. -tom
\_ You're begging the question. Why does the web server
need to read it? It doesn't need to read it to
execute it, and it did it fine in the previous
incarnation of soda, so I'm still curious what the
rationale is. Does the web server do some analysis
of the script beforehand to see if it does unsafe
things?
\_ It's a *script*. You need to be able to read
a script to execute it; how else will the web
server see #!/bin/sh? -tom
\_ not only that, scripts are INTERPRETED. You
can't read shit out of them unless they're
read.
\_ Yes, that makes total sense. I'm an idiot.
I guess I was misled by it working before, but
I suppose that's because soda used to use
suexec?
\_ yes, probably suexec was su'ing to the
user before it tried to read the script,
therefore it was using the user permissions
instead of the world permissions. -tom |
http://csua.com/feed/