I have two perl scripts; one acts like the client (and queries); the other acts like the server and returns information. On an Apache server (not my own) they work perfectly.
However, on my ubuntu/Linux_box with Apache2 (that I set up) they do not; I get a 404 not found error. The cgi-bin directory is located at usr/lib/cgi-bin. What specific files/settings etc have to be changed/altered/etc. And, what specific changes/alterations/etc. need to be made?
Edit:
I changed the httpd.conf and tried both of the following (but neither worked):
ScriptAlias /diag/ /usr/lib/cgi-bin
ScriptAlias /diag/ /usr/lib/cgi-bin/
I am using a perl script as the client, and it did not work. For illustration purposes I attempted to locate the file with the browser shown in the 2nd pic.
If they are receiving 404, it means that the file does not even exist in the correct location. In the httpd.conf look for the "ScriptAlias" directive that has an entry for cgi-bin, should be something like
ScriptAlias /cgi-bin/ /some_folder/cgi-bin
Once you know the correct folder, the 404 error should go away.
Two other points -
1. For cgi files, ensure that the execute bit is set.
2. Verify that the location of perl matches the one in the perl script.
Related
my client side has counter.pl script running on homepage. that displays visitors counter
the client wants to change the visitor counter value.
when i checked the code in index.html,it points cgi-bin/counter.pl script
But wen i try to search cg-bin folder ther are only two files counter.jpg and .htaccess
now how to find the counter.pl script and edit ...!!!??
thanks in advance for any help
Check the web server configuration to see where the cgi-bin directory really is. If you're using apache then you want to look for something like this:
ScriptAlias /cgi-bin/
in the httpd.conf and related files. The actual cgi-bin directory is often located somewhere outside the DocumentRoot directory.
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 run Apache web server on windows in order to work on some Perl CGI scripts. in production these scripts run on a linux box, and in the source code repository they all have shebangs like: #!/usr/bin/perl, but on my windows machine the shebangs would be #!c:\perl\bin\perl.exe, so i have a conflict with the source code base.
enter the Apache ScriptInterpreterSource directive.
i've been trying to make it work, based on what i can google. but so far no luck. i have:
added these things to the appropriate directive
AllowOverride None
Options Indexes FollowSymLinks ExecCGI
Order allow,deny
Allow from all
ScriptInterpreterSource Registry-Strict
added:
AddHandler cgi-script .cgi
edited my registry and added a new String to
HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command=C:\Perl\bin\perl.exe
now, i know that CGIs work on this server as long as they have the right shebang.
but when i try to access a CGI without a shebang the apache log spits out:
No Exec CGI Verb found for files of
type '.cgi'
any thoughts, insights, or even wild-ass guesses would be appreciated.
thanks.
It sounds like the ScriptInterpreterSource line is being ignored. If it's set to Registry or Registry-Strict, it should ignore the shebang lines and use the registry only.
Also, the Apache 2.2 docs have a slightly different location for the registry key:
HKEY_CLASSES_ROOT\.cgi\Shell\ExecCGI\Command\(Default) => C:\Perl\bin\perl.exe -wT
This works for Python scripts as well. I did the following to fix my Apache install to ignore the shebang requirement in my scripts. Without this the shebang is required in the current version of Apache 2.4 - or at least it was in mine.
# tell apache to use registry - this requried a registry hack
# to the following:
# [HKEY_CLASSES_ROOT\.py\Shell\ExecCGI\Command] = "c:\\python\\python.exe"
ScriptInterpreterSource Registry-Strict
Instead of running your perl code in separate CGI processes, consider using mod_perl (See http://perl.apache.org).
Mod_perl is a lot more efficient, as the Perl code is loaded and parsed only once and then runs directly within the Apache processes with no need to start or communicate with other processes.
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.