please help! I'm really going nuts with this problem!
I have a CGI perl script and it always fails at the following line when executed from the Apache HTTP server:
tie %db, 'MLDBM', "$data_path/$db_name.db", O_RDONLY, 0640 or die $!
and the error is Permission denied:
Software error:
Permission denied at /var/www/cgi-bin/rich/pages/display line 381.
For help, please send mail to the webmaster (root#localhost), giving this error message and the time and date of the error.
But when executed from the command line, it works without any problem.
I have ensured that the directories and the file to tie have the correct permissions.
So what else have I missed? What configurations in the Apache's httpd.conf I could be getting wrong? Admittedly, I didn't have any previous experience with the Apache HTTP server, so this is pretty much my first time playing around with it. However, I have read the manuals more than once to look for things I could be wrong at, but I didn't notice anything. But I could be wrong of course.
Thanks!!
Have you verified that $data_path and $db_name contain what you think they do?
Is $data_path an absolute path which is not reliant on the active user's identity or home directory?
What does ls -l $data_path/$db_name.db show for the file's ownership and permissions?
I've never run across (or heard of) anything in apache that would prevent a CGI process from having permission to open files, so I highly doubt that it's an apache config issue. Most likely it's either looking for the wrong file or the file's permissions are incorrect for the user that apache is running the CGI process as.
Related
I came across this error that is apparently pretty common among Linux Systems.
"Too many files Open"
In my code I tried to set the Python open file limit to unlimited and it threw an error saying that I could not exceed the system limit.
import resource
try:
resource.setrlimit(resource.RLIMIT_NOFILE, (500,-1))
except Exception as err:
print err
pass
So...I Googled around a bit and followed this tutorial.
However, I set everything to 9999999 which I thought would be as close to unlimited as I could get. Now I cannot open a session as root on that machine. I can't login as root at all and am pretty much stuck. What can I do to get this machine working again? I need to be able to login as root! I am running Centos 6 and it's as up to date as possible.
Did you try turning it off and on?
If this doesn't help you can supply init=/bin/bash as kernel boot parameter to enter a root shell. Or boot from a live cd and revert your changes.
After performing an 'strace su -', I looked for the 'No such file or directory' error. When comparing the output, I found that some of those errors are ok, however, there were other files missing on my problem system that existed on a comparison system. Ultimately, it led me to a faulty line in /etc/pam.d/system-auth-ac referencing an invalid shared object.
So, my recommendation is to go through your /etc/pam.d config files and validate the existence of the shared object libraries, or, look in /var/log/secure and it should give some clue to missing shared objects as well.
I have managed successfully to server my Catalyst app on my development machine using Plack + Starman, using a daemon script I based on one I found in Dave Rolsky's Silki distribution.
I then set up nginx to reverse proxy to my Starman server, and aliased the static directory for nginx to serve. So far, so good. However, I am at a loss as to where my application STDERR is supposed to be logging to. It isn't reaching nginx (I suppose that makes sense) but I can't find much documentation as to where Starman may be logging it - if anywhere. I did have a look at Plack's Middleware modules but only saw options for access logs.
Can someone help me?
It's going nowhere. Catalyst::Log is sending data to STDERR, and the init script is sending STDERR to /dev/null.
You have a few basic choices:
Replace Catalyst::Log with something like Catalyst::Log::Log4perl or simply a subclass of Catalyst::Log with overridden _send_to_log -- either one will allow you to send the logging output somewhere other than STDERR.
Write some code that runs at the PSGI level to manage a logfile and reopen STDERR to it. I tried this, it wasn't very pleasant. Logfiles are harder than they look.
Use FastCGI instead, and you'll have an error stream that sends the log output back to the webserver. You can still use Plack via Plack::Handler::FCGI / Plack::Handler::FCGI::Engine (I'd recommend the latter, because the FCGI::Engine code is much newer and nicer than FCGI.pm).
I realise it is a long time since the question was asked, but I've just hit the same problem...
You actually have one more option than Hobbs mentioned.
It isn't quite the "init script" that is sending STDERR to /dev/null, it is Starman.
If you look at the source code for Starman, you would discover that, if you give it the --background flag, it uses MooseX::Daemonize::Core.
And once you know that, its documentation will tell you that it deliberately closes STDERR, STDOUT and STDIN and re-directs them to /dev/null, AND that it takes the environment variables MX_DAEMON_STDERR and MX_DAEMON_STDOUT as names of files to use instead.
So if you start your catalyst server with MX_DAEMON_STDERR set to a file name, STDERR will go to that file.
Today Starman has a --error-log command line option which allows you to redirect error messages to a file.
See documentation of starman:
--error-log
Specify the pathname of a file where the error log should be written. This enables you to still have access to the errors when using --daemonize.
I'm using MAMP-pro to serve my domain to the outside world.
I'm not a very experienced sys-admin, though I've slogged my way through a few basic things. I know what apache is, and I can read-most-of but not generate-without-guide related .conf files.
I've got a perl script which I've tested from the command line and it works (outputs as desired.)
When I try to access said script from the browser, I get 404.
I've tried placing the script at:
/Users/me/Sites/mydomain.com/htdocs/mycgi.pl
/Users/me/Sites/mydomain.com/cgi-bin/mycgi.pl
/Users/me/Sites/mydomain.com/htdocs/cgi-bin/mycgi.pl
and accessing it as:
http://www.mydomain.com/mycgi.pl
http://www.mydomain.com/cgi-bin/mycgi.pl
and all the various combinations, all to no avail (404.)
The script and its container directory have permissions 755.
So, what other steps am I missing? Are there any good set-up guides? I tried the MAMP-Pro manual, but it is filled with such information as "the cancel button cancels the current operation" and not really anything useful. Google turned up several hits that all seem to talk about how to make this work on localhost, but I'm trying to serve this to the outside world.
Any hints?
Thanks!
The official online documentation has a section on virtual hosts. When creating a host for www.mydomain.com you can choose the DocumentRoot which is called "Disk location" within MAMP PRO. If you still get a 404 error, take a look into the error_log for a more specific reason (i.e., where Apache tries to find the file in question).
I'm working on a Perl script which is called from a server side include on an Apache 2 server. The script is displaying the generic "Internal Server Error" page rather than showing me the actual error. When I check the Apache error log, I see these messages:
unable to include "/foobar/index.pl" in parsed file /home/foouser/domains/foosite.com/public_html/foobar/index.shtml, referer: http://www.foosite.com/foobar/
suexec policy violation: see suexec log for more details, referer: http://www.foosite.com/foobar/
Premature end of script headers: settings.pl, referer: http://www.foosite.com/foobar/
How do I get a Perl script to show an error rather than "Internal Server Error"?
Update:
I should have asked a separate question for this, because I have since learnt that this does send errors to the browser (thanks brian):
use CGI::Carp qw(fatalsToBrowser);
However, if the problem is with the Apache config rather than the Perl script, then the error will not be sent to the browser because the Perl code is not being interpreted. In this case, we can tell that I am experiencing an Apache error (rather than a Perl error) because of this line:
suexec policy violation: see suexec log for more details
This occurs when Apache is running in SUexec mode (which seems to be common for shared hosting). I'm not sure what exactly has been changed to cause this error, but that's what I'm trying to find out.
Probably you are using shared hosting and you have this problem because your scripts directory or the script file does have other rights than 755.
Here is one case translated from Dutch.
Use CGI::Carp's fatalsToBrowser.
use CGI::Carp qw(fatalsToBrowser);
You might also want to see my Troubleshooting Perl CGI scripts.
From the error message, I'm guessing that you aren't allowed to execute CGI scripts from server side includes. Which version of your Apache are you running? If it's an old apache, see the suexec docs for apache 1.3, or if it's a newer apache, see the suexec docs for apache 2.0.
It's not for user friendliness, but often for security that we don't show users the exact error when the user can't do anything about it. For example, imagine that a back end server is unavailable. What can I, as a user, do to fix that in your web application?
In some cases, error messages will contain useful information, like "SQL Error: illegal syntax. Unmatched ' ". If the user had input a quote in their input, this feedback would indicate a SQL injection vulnerability.
Other benign looking messages are bad to show to users, as well. The key thing that the attacker wants is to know "something different happened." If the application prints out one error for one input,and another error for another iinput, then the attacker knows that something different has gone wrong, and that this is an interesting place to focus.
In a production site, errors should be logged to file, and, if appropriate, downloadable through your web interface - but be very careful to sanitize any output to the browser to avoid cross site scripting. And there should be no user-submitted option to reconfigure this between debug and production (don't control it via a POST or CGI parameter, but by a configuration file option).
This could be 3 factors:
Permissions level rwx set wrong (execution/writeness level)
UUID/GUID do not match Apache settings
Combination of 2 above.
Check apache suexec+errorlog for details
I've moved a WebBBS board from one server to another. Ever since the board doesn't work.
I'm getting an Apache error whenever I try to access the board. Don't even know where to start the debugging, I'm not a Perl person. The file paths remained the same and there isn't any DB involved.
http://gammonline.com/members/board/
Any ideas?
After a bit of testing I believe that the problem has something to do with the index.cgi which is located in that folder (not getting the error when renaming it).
Thanks,
Roy.
More information about this error may be available in the server error log.
Says it all. You will have to find the error log and look at it.
If you are using CGI, the first step is to check you have given it the right permissions so it is an executable script at all.
chmod 755 index.cgi
This is caused by Apache config errors. Set LogLevel debug and tail -f the error log. It will probably be something to do with .htaccess permission for override, or, it's requiring a module which isn't loaded. The error log will tell you instantly.