I am trying to run a script via apache on a shared linux server, like
#!/usr/bin/perl
print "Content-type: text/html\n\n";
foreach $i (keys %ENV) {
print "$i $ENV{$i}\n";
}
But I want to run it via. a symlink created like this
ln -s printenv.pl linkedprintenv.pl
It runs fine directly but I got a 500 server error when executing via the symlink from a web browser. I understand the solution may be to create a .htaccess file containing
Options +FollowSymLinks
but I tried and that didn't work. Is there extra configuration needed for that single line htaccess file to take effect?
Related
So basically my apache server is not using the same perl version as what I have in the os environment and that's why some modules did not get to be used properly. When I checked my error-log, it showed that my intended module cannot be located and it is pointing at /users/local/perl6.
When I do perl -v in the terminal, it says that this is perl 5, version 16. What's the best way to reset my apache server to use the right version of perl?
The right way is to configure PATH env variable right. To see what current env variables are use:
#!/usr/bin/env perl
print "Content-Type: text/plain\n";
print "\n\n";
use Data::Dumper qw/ pp /;
print pp \%ENV;
How to setup env variables from apache config
For example if you want to install specific version of perl for apache you setup it into /home/www/perl directory (Here we use www user to run apache sever) and set PATH:
SetEnv PATH /home/www/perl/bin
Do not override current PATH value if you require it.
If you want to see what perl is used - run:
#!/usr/bin/env perl
print "Content-Type: text/plain\n";
print "\n\n";
print `which perl`
The particular OS running Apache might have some bearing on the best way. However, assuming no mod_perl, one way that I have used on *nix systems and Windows is to include the entire path to the desired interpreter in the shebang line of the script. That is, the first line of the script should start with "#!" followed by the desired interpreter. For your server, it should be:
#!/path/to/Perl5/perl
I'm setting up an Amazon Web Service Stack and I'd like to configure the Document Root in /etc/apache2/sites-enabled/000-default.conf which I currently do by modifying the document's DocumentRoot. I then reflect this change in /etc/apache2/apache2.conf. Is it possible to make these changes with command lines as opposed to opening and editing files? Thanks in advance.
You can do it with sed. I use following wrapper function, to make it more convenient:
replace_string () {
while :; do
case $1 in
file=?*) local file=${1#*=} ;;
replace=?*) local replace=${1#*=} ;;
with=?*) local with=${1#*=} ;;
*) break ;;
esac
shift
done
sudo sed -i -- "s/$replace/$with/ig" $file
}
replace_string file='/etc/apache2/sites-enabled/000-default.conf' \
replace='.*DocumentRoot.*' \
with='DocumentRoot path-to-your-document-root'
replace_string file='/etc/apache2/apache2.conf' \
replace='.*DocumentRoot.*' \
with='DocumentRoot "path-to-your-document-root"'
Mind that user running this script should be capable of using sudo without a password.
If you have httpd.conf file
I don't know if this is supported by the documentation or not (I couldn't see reference to it) but I found that appending will replace previous directives.
I stumbled upon this experimentally after becoming disillusioned with the cocophony of sed, grep and awk scripts that usually accompany this kind of question (see Modify config file using bash script).
In my case, I have a file called httpd_changes.conf which looks like this:
DocumentRoot "/my/new/web/dir"
<Directory "/my/new/web/dir">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
Then when I set up the webserver (in my case it's in my Dockerfile) I run this prior to starting the httpd service:
cat httpd_changes.conf >> /etc/apache2/httpd.conf
If you don't have a httpd.conf file
This isn't my situation but as far as I can tell you can just put a new config file in your conf.d directory. Those files are read in alphabetically (according to this page https://superuser.com/questions/705297/in-what-order-does-apache-load-conf-files-and-which-ones) which is obviously much nicer than my hack.
You could try the following:
sed "s,/var/www/html,/my/new/web/dir,g" /etc/apache2/sites-enabled/000-default.conf
This will display the modification that would be made on your file.
The , is used as a custom delimiter to make the regex easier to read.
This example with replace all occurences of /var/www/html with /my/new/web/dir.
Add the -i flag to actually modify the file:
sed -i "s,/var/www/html,/my/new/web/dir,g" /etc/apache2/sites-enabled/000-default.conf
Apache on Windows gives me the following error when I try to access my Perl script:
Server error!
The server encountered an internal error and was unable to complete your request.
Error message:
End of script output before headers: sample.pl
If you think this is a server error, please contact the webmaster.
Error 500
localhost
Apache/2.4.4 (Win32) OpenSSL/1.0.1e PHP/5.5.3
this is my sample script
#!"C:\xampp\perl\bin\perl.exe"
print "Hello World";
but not working on browser
Check file permissions.
I had exactly the same error on a Linux machine with the wrong permissions set.
chmod 755 myfile.pl
solved the problem.
If this is a CGI script for the web, then you must output your header:
#!"C:\xampp\perl\bin\perl.exe"
print "Content-Type: text/html\n\n";
print "Hello World";
The following error message tells you this End of script output before headers: sample.pl
Or even better, use the CGI module to output the header:
#!"C:\xampp\perl\bin\perl.exe"
use strict;
use warnings;
use CGI;
print CGI::header();
print "Hello World";
For future reference:
This is typically an error that occurs when you are unable to view or execute the file, the reason for which is generally a permissions error. I would start by following #Renning 's suggestion and running chmod 755 test.cgi (obviously replace test.cgi with the name of your cgi script here).
If that doesn't work there are a couple other things you can try. I once got this error when I created test.cgi as root in another user's home. The fix there was to run chmod user:user test.cgi where user is the name of the user who's home you're in.
The last thing I can think of is making sure that your cgi script is returning the proper headers. In my ruby script I did it by putting puts "Content-type: text/html" before I actually outputted anything to the page.
Happy coding!
Probably this is an SELinux block. Try this:
# setsebool -P httpd_enable_cgi 1
# chcon -R -t httpd_sys_script_exec_t cgi-bin/your_script.cgi
Had the same error on raspberry-pi. I fixed it by adding -w to the shebang
#!/usr/bin/perl -w
You may be getting this error if you are executing CGI files out of a home directory using Apache's mod_userdir and the user's public_html directory is not group-owned by that user's primary GID.
I have been unable to find any documentation on this, but this was the solution I stumbled upon to some failing CGI scripts. I know it sounds really bizarre (it doesn't make any sense to me either), but it did work for me, so hopefully this will be useful to someone else as well.
Since no answer is accepted, I would like to provide one possible solution. If your script is written on Windows and uploaded to a Linux server(through FTP), then the problem will raise usually. The reason is that Windows uses CRLF to end each line while Linux uses LF. So you should convert it from CRLF to LF with the help of an editor, such Atom, as following
If using Suexec, ensure that the script and its directory are owned by the same user you specified in suexec.
In addition, ensure that the user running the cgi script has permissions execute permissions to the file AND the program specified in the shebang.
For example if my cgi script starts with
#! /usr/bin/cgirunner
Then the user needs permissions to execute /usr/bin/cgirunner.
Internal error is due to a HIDDEN character at end of shebang line !!
ie line #!/usr/bin/perl
By adding - or -w at end moves the character away from "perl" allowing the path to the perl processor to be found and script to execute.
HIDDEN character is created by the editor used to create the script
So for everyone starting out with XAMPP cgi
change the extension from pl to cgi
change the permissions to 755
mv test.pl test.cgi
chmod 755 test.cgi
It fixed mine as well.
In my case I had a similar problem but with c ++ this in windows 10, the problem was solved by adding the environment variables (path) windows, the folder of the c ++ libraries, in my case I used the codeblock libraries:
C:\codeblocks\MinGW\bin
This is my case.
Only two line in the script:
#!/usr/bin/sh
echo "Content-type: text/plain"
give the error 500.
adding this line, after the first echo:
echo ""
don't give the error.
Basing above suggestions from all, I was using xampp for running cgi scripts.
Windows 8 it worked with out any changes, but Cent7.0 it was throwing errors like this as said above
AH01215: (2)No such file or directory: exec of '/opt/lampp/cgi-bin/pbsa_config.cgi' failed: /opt/lampp/cgi-bin/pbsa_config.cgi, referer: http://<>/MCB_HTML/TestBed.html
[Wed Aug 30 09:11:03.796584 2017] [cgi:error] [pid 32051] [client XX:60624] End of script output before headers: pbsa_config.cgi, referer: http://xx/MCB_HTML/TestBed.html
Try:
Disabled selinux
Given full permissions for script, but 755 will be ok
I finaly added like -w like below
#!/usr/bin/perl -w*
use CGI ':standard';
{
print header(),
...
end_html();
}
-w indictes enable all warnings.It started working, No idea why -w here.
I have migrated my project from Windows IIS to Mint Apache2.
Unfortunately I am getting an error:
HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfil the request.
I have changed permissions on the files to 755. Normally if there is a CI error (connecting to db etc) it throws an error.
I have opened my index.php with VI, and I have noticed ^M on the end of each line in EACH FILE. This doesn't show in Aptana though.
I have spent last half a year writing this app and I'm not very excited about this.
Does anybody have any experience with this?
Thank you.
If you have access to the shell on your server and it's running Linux/Unix, try this:
for i in `find . -type f` ; do dos2unix $i $i; done
The for i in `find . -type f` ; part finds all FILES within the current directory.
Then, do dos2unix $i $i; done runs dos2unix which will convert all your ^M's to the Unix standard which is just \r.
If you want to test it out on a single file, make a copy of a file and replace find . with find filename.ext
Try adding this to your php.ini.
display_errors = On
This should show a proper error instead of just throwing a 500. From therein it should be relatively simple to debug.
I have set up a php file to run that just echos hello.
<?php
echo hello;
?>
My cron job looks like this:
/usr/local/bin/php -f “/home/username/public_html/mls/test.php”
when my script runs i get a confirmation email that says:
Could not open input file: /home/username/public_html/mls/test.php
I don't know what is causing this. I am using godaddy's virtual private server with cpanel x installed. I have used the ssh to set permissions 777 on folder and file and still can not get it to run.
Any advice would be helpful. Thanks.
For some reason PHP cannot open the file. Try replacing /usr/local/bin/php -f with "ls -la" to try to crib some more information. Remember to NOT quote the file name in the crontab: php -f filename.php, not php -f "filename.php", unless it contains spaces -- and then it's better to use single quotes.
Possibly, try "ls -la /home", "ls -la /home/username", "ls -la ~/public_html" and so on.
Also try appending
2>&1
to the command line, in case only stdout is mailed to you (I don't really think so, but being sure costs little).
One other possibility
The crontab as it is refers /home/username/public_html/mls/test.php - that is, a public HTML directory inside username's commonest value for a home directory.
It is possible that the cron job is either not running with the appropriate user and privileges, or that the user it "sees" is actually a virtual user - there is no "/home/username" at all - and the "home directory" is elsewhere, possibly even existing just as long as the cron job runs. In this case the solution might be to refer to
~/public_html/mls/test.php
or, as described above, to first run a command such as pwd or ls -la to determine exactly where the cron job's current working directory is.
If this, too, fails, then another workaround could be to invoke the PHP HTTP handler via curl or lynx:
/usr/bin/curl http://www.thishostname.com/mls/test.php
Possibly using either some environment variable or curl header or _GET option to authenticate to the script as the cron job, and avoid it being accessible from the outside.