Im using AMPPS, I can't access my perl file, but I can every other file in the folder.
I'm getting a 403 forbidden.
Here's the code:
[Fri Jan 24 01:18:10.069985 2014] [cgi:error] [pid 38441] [client ::1:51823] Options
ExecCGI is off in this directory: /Applications/AMPPS/www/test/test1.pl, referer:
http://localhost/test/test1.html
I'm calling the perl file via an AJAX POST call
Things I have tried:
Adding +ExecCGI to every < Directory > structure I can find
Adding AddHandler cgi-script .cgi .pl to the aforementioned structures
Setting 777 permissions recursively the containing folder, along with the cgi-bin directory set by ScriptAlias in the httpd.conf.
Is there anyone that can give me some insight as to either:
What I'm doing wrong
How to configure the httpd.conf standard config file to run CGI scripts from the /www folder using AMPPS
Thanks in advance
Every thing looks fine. Just make sure that you include your httpd.conf in the apache2.conf file and recheck the directory path where you are giving your +ExecCGI and AddHandler options.
I am not sure about AMPPS, but thinking apache server settings will be same.
Looking at the log , looks like your directory path should be : /Applications/AMPPS/www/ .
And make sure you restart the server after each change you make.
Related
I want to be able to run my Mojolicious Lite app on shared hosting either from root (www.domain.com/) or subfolder (www.domain.com/misc/mymojoapp/).
The app's .pl file always goes to cgi-bin folder of the domain (www.domain.com/cgi-bin/myapp.pl) and I want to use mod_rewrite rules in .htaccess to point to the app. Images/css/js files would be under www.domain.com/misc/mymojoapp/support.
But I cannot figure out how I reliably get misc/mymojoapp/ part of the path so I can pass it into templates. Is there a way?
# set apache handler to treat your specified script name(s) as a CGI program
Options +ExecCGI
<Files ~ "(mymojoapp)$">
SetHandler cgi-script
</Files>
# rewrite any requests into the appRewriteEngine onRewriteCond %{REQUEST_FILENAME}
!-fRewriteRule ^(.*)$ misc/mymojoapp/$1 [L]
and in your App
# set env variable to use root for pretty URLs
$ENV{SCRIPT_NAME} = '/';
Change the above setting for pretty URL
Disclaimer: I know this questions sounds lame. But I am no n00b and I have done whatever I know and I could find help about this. I have already searched the forum for this and tried all the fixes given but none of them helped me hence this question.
The threads I have visited
https://askubuntu.com/questions/147348/bugzilla-testserver-pl-failing
http://www.thesitewizard.com/archive/addcgitoapache.shtml
Bugzilla error after installation: "TEST-FAILED Web Server is not executing CGI files"
Now with that
My Exact problem
I have installed bugzilla on a bitnamil lampstack. The lampstack already has two other applications up and running successfully. After my bugzilla installation when I am trying to visit the page I can see my whole perl script on the borwser.
Running it's own server check reveals me the following
TEST-OK Webserver is running under group id in $webservergroup.
TEST-OK Got padlock picture.
TEST-FAILED Webserver is fetching rather than executing CGI files.
What I have done in my setup
The bugzilla.conf file (which gets pulled in httpd.conf) has the
following settings enabled
> AddHandler cgi-script .cgi .pl
>
> Options +MultiViews +ExecCGI
>
> DirectoryIndex index.cgi
>
> AllowOverride All
The "AddHandler cgi-script .cgi .pl" is already enabled in my httpd.conf file.
I have not enabled separately +ExecCGI for all directories in httpd.conf but even that does not solve the problem
What am I doing wrong here?
You should have a directory block in your bugzilla.conf that looks something like this:
<Directory "/usr/local/apache2/htdocs/bugzilla">
AddHandler cgi-script .cgi
Options +ExecCGI +FollowSymLinks
DirectoryIndex index.cgi index.html
AllowOverride Limit FileInfo Indexes Options
AddType application/vnd.mozilla.xul+xml .xul
AddType application/rdf+xml .rdf
</Directory>
I believe you don't want the .pl to be 'handled'. And having All for AllowOverride is a security issue. The FollowSymLinks one is because my bugzilla directory in htdocs is a symlink to somewhere else on the system.
Did you run the checksetup.pl? It should have adjusted all the permissions for you, but check to see that the group that your web server runs as has read and execute permissions.
I had a similar problem with another package downloading the CGI files instead of executing them on the server. The answer to my problem was that on Ubuntu server 14.04, the module CGI on apache was disabled.
To fix:
sudo a2enmod cgi
sudo service apache2 restart
To check if the module is loaded, on Ubuntu:
apache2ctl -M | grep cgi
cgi_module (shared)
yellavon's answer solved my problem:
cgi script is not executing
Here's a copy of his answer:
Make sure you are loading the CGI module in the httpd.conf file:
LoadModule cgi_module modules/mod_cgi.so or LoadModule cgi_module modules/mod_cgid.so depending on which version of Apache you are running.
You can also read about additional solutions for Dynamic Content with CGI.
While configuring with apache and perl cgi scripts, don't know why index.cgi/index.pl are displayed as plain text instead of executing them.
When I put http://localhost in browser it displays below code, instead of executing it.
List item
#!C:/Dwimperl/perl/bin/perl.exe -w
print "Content-type: text/html\n\n";
print <<HTML;
<html>
<head>
<title>A perl web page</title>
</head>
<body>
<h3>A hello world form perl</h3>
</body>
HTML
exit;
This are parts of httpd.conf file which I have edited most of the times (after reading various online reference, tutorials)
# This should be changed to whatever you set DocumentRoot to.
<Directory "D:\webserver">
Listen 80
ServerName localhost:80
LoadModule cgi_module modules/mod_cgi.so
# First, we configure the "default" to be a very restrictive set of
# features.
<Directory />
Options FollowSymLinks +ExecCGI
AllowOverride None
</Directory>
DirectoryIndex index.html index.html.var index.cgi index.pl
AccessFileName .htaccess
# To use CGI scripts outside of ScriptAliased directories:
# (You will also need to add "ExecCGI" to the "Options" directive.)
#
#AddHandler cgi-script .cgi .pl
ScriptAlias /cgi-bin/ "C:/Apache/Apache2/cgi-bin/"
When browser is printing code of script that means it's unable to find the application to run the script. Below two lines should be your first steps to solve this. AddHandler will make sure files ending with .cgi and .pl to be treated as cgi scripts. And +ExecCGI option will allow to execute the script. Also make sure your script is pointing to correct perl binary location.
AddHandler cgi-script .cgi .pl
Options FollowSymLinks +ExecCGI
Also There are some mistakes/misconfiguration points in your httpd.conf
Alias line should point to cgi-bin directory where your cgi scripts are present.
ScriptAlias /cgi-bin/ "D:\webserver\cgi-bin"
For same cgi-bin directory following configuration should be in httpd.conf. You should replace your <Directory "D:\webserver"> part with below.
<Directory "D:\webserver\cgi-bin" />
AddHandler cgi-script .cgi .pl
Options FollowSymLinks +ExecCGI
AllowOverride None
</Directory>
Try running your cgi script from command line like below. It should print or run from command line first.
perl test.cgi
Make sure you have read-write recursive permissions to cgi-bin directory and your cgi script. And also you can create directory or file with write permissions. If not create a cgi-bin directory at some other place where you can have write permissions and provide rather its path in alias and directory attributes in httpd.conf instead.
Check apache error log for exact error message every time you run into apache conf issues. It will give you good insight into the problem.
Also this link should help you.
(Extra comment, not by the original answerer: You may also need to enable the cgi module. For me, the final step to getting cgi to work on a fresh install of Apache 2 was sudo a2enmod cgi. Before I did that, the website simply showed me the contents of the script.)
sudo a2enmod cgi
The directory/location/file doesn't have the right handler associated with it, or doesn't have the ExecCGI option enabled. See Apache Tutorial: Dynamic Content with CGI.
change new version of apache :
Options +FollowSymLinks +ExecCGI
on mac os x 10.8
i had to do this
<Directory />
Options FollowSymLinks +ExecCGI
AllowOverride None
</Directory>
and
uncomment this
#AddHandler cgi-script .cgi .pl
# use types www.site.com/visible-in-url
# Apache serves /var/path/to/dir
ScriptAlias /visible-in-url/ /var/path/to/dir/
# Note the order of the aliases matters - first cgi than static content
# Note this dir is a symlink pointing to the desirable directory
<Directory "/var/path/to/dir">
AddHandler cgi-script .cgi .pl
AllowOverride Indexes
Options +ExecCGI +MultiViews +SymLinksIfOwnerMatch
Require all granted
</Directory>
<Files ~ "\.(pl|cgi)$">
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
Options +ExecCGI +SymLinksIfOwnerMatch
PerlSendHeader On
</Files>
When browser is printing code of script that means it's unable to find
the application to run the script.
With Apache 2.4 (on OSX Yosemite, 10.10.5), if I use a shebang line with the wrong path, my browser displays:
Internal Server Error
But even with a valid shebang line, I could not get my cgi program to execute by following the advice in the accepted answer--Apache just served up the text of the program to my browser. After some experimenting, I found that the only change I needed to make to my /usr/local/apache2/conf/httpd.conf file was uncommenting the line:
LoadModule cgid_module modules/mod_cgid.so
My cgi programs have the extensions .pl, .py, and .rb depending on what language I'm programming in (and the apache cgi-bin directory contains a test cgi script with no extension), and they all execute without having to specify valid extensions anywhere in the httpd.conf file. My default httpd.conf file has only the following relevant lines:
<IfModule alias_module>
#Lots of comments here
ScriptAlias /cgi-bin/ "/usr/local/apache2/cgi-bin/"
</IfModule>
...
...
<Directory "/usr/local/apache2/cgi-bin">
AllowOverride None
Options None
Require all granted
</Directory>
The shebang line that I'm using is, depending on what language my cgi program is written in:
#!/usr/bin/env perl
or:
#!/usr/bin/env python
or:
#!/usr/bin/env ruby
A cgi program has to be an executable file as well, or else you will get an Internal Server error:
$ chmod a+x myprog.pl
a+x => all + executable. In other words, add the executable permission to each of owner, group, other.
And, at a minimum the cgi program has to generate a Content-Type header before outputting the body of the response:
print "Content-Type: text/html\n\n";
print "<h1>Hello, World.</h1>";
(By the way, that exact code will work in perl, python, or ruby.) Otherwise, once again you will get an Internal Server error.
The url to execute the cgi script:
http://localhost:8080/cgi-bin/myprog.pl
This is how I installed apache:
~/Downloads$ tar xvfz httpd-2.4.18.tar.bz2
...
...
~/Downloads$ cd httpd-2.4.18
...
...
~/Downloads/httpd-2.4.18$ ./configure --help
...
...
--enable-so DSO capability. This module will be automatically
enabled unless you build all modules statically.
...
...
I had no idea what the heck that meant, but the php docs say to install apache with that option, so I went ahead and did this:
~/Downloads/httpd-2.4.18$ ./configure --enable-so
...
...
~/Downloads/httpd-2.4.18$ make
...
...
~/Downloads/httpd-2.4.18$ sudo make install
Apache DSO docs here.
If nothing else has worked, be sure that you're displaying the HTML page that calls your executable script from the local server, e.g. http://192.168.0.15/yourPage.html. If you call it by opening the HTML page in your browser as a file, it will always display your executable script as a file.
How to disable mod_deflate for PHP using the.htaccess file
for files in a specific directory
for all files that have extension of, for example .php?
I have tried both:
# for URL paths that begin with "/foo/bar/"
SetEnvIf Request_URI ^/foo/bar/ no-gzip=1
# for files that end with ".php"
<FilesMatch \.php$>
SetEnv no-gzip 1
</FilesMatch>
They don't work, I can't figure out why. At this point I want to disable it completely for all files in the directory.
Check this out. and reply if it works for you:
SetEnvIfNoCase Request_URI ".php$" no-gzip dont-vary
Let's simplify the issue and slowly make it more complicated as you get each piece working.
First, you stated in a comment: "When I try to access a specific php file on the server FF tells me that that there is a compression problem"
First, see if the issue happens when you disable mod_deflate. Comment out the deflate lines from your apache configuration file(s).
If that indeed fixes it, re-enable mod_deflate, then add these to your virtualhost that is hosting your site (don't mess around with .htaccess yet, that just adds another level of complexity):
SetEnvIfNoCase Request_URI "\.(php)$" no-gzip dont-vary
Try PHP files and see if they are still compressed.
If this works, then add the other condition
SetEnvIfNoCase Request_URI "^/foo/bar/.*" !no-gzip !dont-vary
Finally - put this all in your .htaccess file and Ta-dah!
I am root on my own webserver and I did write a perl-script for maintaining my website. Called from a browser this script displayes a user-interface for maintainance. To be able to start this script from my browser, I must enter a username and a password, so nobody but me can run this script.
I want that this script renames some files on the server when I click on the according button. From the perl-script I call the shell-command `mv oldFilename newFilename`, but nothing happens. Apache's error log displays this message:
[timestring] [error] [client n.n.n.n] mv: cannot move oldFilename to newFilename: Permission denied, referer: referrer
filename's owner is root, permissions are set to 0644 (everybody can read, only root can write)
What is the best solution for this problem? Is there a better way than changing the files permissions to 0666? I want to refrain from changing the permissions. I would prefere a solution where the perl-script sayes to the shell something like: "Dear shell, here is the password for root. Now please rename file X to Y!"
Isn't this the exact problem that Unix groups were meant to solve? Set file permission to 0664, directory permissions to 0775, and assign the files and directories to a group that the webserver user belongs to.
Don't ignore security. Use sudo.
I maintain a Perl web site with html pages and Java script. All the program files are protected with root ownership.
Even if you limit access to this program through a username and password on the web site, then root should own the program chown root:root <full-path-to-your-program-name>, and the program file should be protected chmod 755 <full-path-to-your-program-name>.