Xoxo 2014 Release 3.2 web app, deploying under Apache2, Ubuntu. What’s the secret?
Here’s the situation:
64 bit Ubuntu 14.04.1 (GNU/Linux 3.13.0-37-generic)
Apache2.
When I attempt to go to the app in Safari, I get ‘Internal Server Error’. Tracking down the apache error log, the entry is ‘End of script output before headers: test.cgi’
However, if I, as root, manually run the test.cgi, THEN use the browser, I get the desired behavior.
It sure seems like a permissions problem, but I can’t figure out the ‘magic’.
I created a ‘first.pl’ file, which was only a ‘hello world’ kind of thing, set the ownership and perms the same as the Xojo web app, and it works just fine. It’s obvious that the actual ‘test’ executable isn’t kicking off by apache.
Can’t use an undefined value as a symbol reference at /usr/lib/cgi-bin/test.cgi line 118
End of script output before headers: test.cgi
It’s clearly trying to run the cgi file, but seems to fail to launch the binary (that’s my theory, anyway).
Hoping to figure this out, to finish a set of instructions to deploy on Ubuntu 64bit with Apache, which I’ll happily share when finished. This issue is the last problem to resolve.
Hi Norma. Yes, I’m sure the 32 bit compat libs are there. Just was testing various runs from the command line:
as ‘root’, runs from the command line.
/usr/lib/cgi-bin/test.cgi
However, when I attempt to run as ‘www-data’ (the apache user):
sudo -u www-data /usr/lib/cgi-bin/test.cgi
Same error message ‘Use of uninitialized value…’
I’m beginning to think that the permission issue resides at a lower level. Not sure which log to check to figure it out, but there must be one that contains the answer.
the fact you dont get a “Cannot read config at path …” error means the config looks to be correctly readable
and you dont get a “cant write” which is also good
if you cat the config file is there a specific port set ?
or is it left as autoport = 1 and port = 0 ?
it strikes me either port or autoport is not set and so problems ensue but I cant image why they would not be
OK, This is resolved - mostly. As it turns out, it was a permissions issue. The app was owned properly by the ‘www-data’ user, but the group ‘www-data’ did not have permissions to execute binaries. - or rather, no access to the libraries needed.
My other server, which was working, had the group set differently, which I replicated to the new server, and lo and behold, things started working.
I’m not 100% satisfied, though, as I think the security may be too broad at the moment, and if this was a public facing server, might be an attack vector.
