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)
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.
Anyone else have any success?
Make sure the .cfg and .cgi file next to your app has read/write permissions for Apache.
Files are owned by www-data, 755 permission.
755 is owner read write execute & group & others only have read execute
what if you set it to 775 ?
Hi Norman (been a while!)
Same result. Apache error log says:
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.
Long time no see
You have all the required 32 bit compat libraries installed (ie the app when you run it directly at the cmd line runs?)
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.
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.
but yeah that certainly seems to be the trick
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
Whoops. Sorry, Norman, forgot the ‘n’. LOL.
[quote=169409:@Darryl Snover]Hi Greg,
Files are owned by www-data, 755 permission.[/quote]
Try changing the config.cfg file to 666 permissions.
[quote=169513:@Darryl Snover]Whoops. Sorry, Norman, forgot the ‘n’. LOL.
and debugging the perl script I sent you privately ?
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.