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.
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'm trying to connect to a website via HTTPS, by sending a WWW::Mechanize get request and whenever I try and run my script I get this error:
This Application has faile to start because libeay32_.dll was not found. Re-installing the application may fix this problem
And inside the command prompt I get:
Error GETing http...: can't load 'C:/strawberry/perl/vendor/lib/auto/Crypt/SSLeay/SSLeay.dll for module Crypt::SSLeay: load_file: The specified module could not be found (Crypt::SSLeay or IO::Socket::SSL no installed) at ...
I don't understand the problem because I'm very new to programming with Perl. Crypt::SSLeay is installed, the .dll is in the proper location and IO::Socket::SSL is also installed, or whenever I try to install it via cpan i get the libeay error again. The libeay32_.dll is located in the C:\straberry\c\bin. I don't have full access right to the computer because I am doing this from work. If someone could explain to me the reason for the problem it would be appreciated.
I make an answer out of my comments so you can check this question as answered:
Add "C:\straberry\c\bin" to the PATH-environment variable
Close the explorer- and/or commandline-windows since running processes aren't notified if the environment changes and thus keep the old environment active (okay, in the command line you could apply the update manually by set PATH=...new path...).
Have you read the README.SSL file that comes with LWP? (WWW::Mechanize uses LWP to make the actual HTTP requests).
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).
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.
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