Enable Perl / CGI on NV+ shared HTML directory

What happens if you call the URL

http://IPaddress/intranet/cgi-bin/helloworld.pl

with your browser?

Also, cgi-bin directories have to be set up in a special way like for example putting

<Location /intranet/cgi-bin>
  Options ExecCGI
</Location>

somewhere into your vhost confiuration.

-Stefan

Hi Stefan

the URL results in the Forbidden error as shown above.

I've not configured an Apache server before so am not sure where to find Vhosts. I have located a
nas:/etc/frontview/apache/Virtual.conf which contains:

SSLEngine off
RewriteEngine on
RewriteRule ^/$ /intranet [R,L]

RewriteRule ^/admin/(.*)$ https://%{SERVER_NAME}/admin/$1 [R,L]

Is this the file you mean ?

okay, I've tried adding the lines suggested

<Location /intranet/cgi-bin>
Options ExecCGI
</Location>

to nas:/etc/frontview/apache/httpd.conf
then stoppied / restarting the http service but the problem remains the same.

Sorry I didn't get notified of your replies to my post.
I guess there's something substantially wrong with your configuration of the files you want to display/call through Apache. It would help if you could post your setup as detailled as possible since especially the setup for the Apache server leaves a lot of room to do something the wrong way.

-Stefan

Its all at default settings with the exception of having the 'intranet' share set for http/s as read only and targetted as the default web access with authentication disabled in the services area. These settings were done using the frontview GUI - ie: I have not changed anything from the shell access related to Apache other than attempting the fix you suggested but I have put that back to normal now.

As I said, I'm no expert on Apache so please clarify which files would you like me to post here for you ?

Regards

Managed to figure it out, so here' show to Enable Perl / CGI on NV+ shared HTML directory for anyone else that is trying to figure it out:

httpd.conf includes a number of additional .conf files when it runs on reboot. We therfore need to add a CGI.conf
file to this list that will contain definitions for any new cgi-bin locations on shares.

1. edit httpd.conf to ensure the additional .conf files are loaded last.


SSH login using PuTTY or similar to root/admin.

cd /etc/frontview/apache/
vi httpd.conf

change the sequence of the last two lines
from :

	  Include /etc/frontview/apache/addons/*.conf
	  Include /etc/frontview/apache/Shares.conf

to:

	  Include /etc/frontview/apache/Shares.conf
	  Include /etc/frontview/apache/addons/*.conf

save the file.


2. Create a new .conf file for the cgi-bin's

cd /etc/frontview/apache/addons/

vi CGI.conf

Alias "/intranet/cgi-bin" "/c/intranet/cgi-bin"
<Location "/intranet/cgi-bin">
  Options ExecCGI
  Allow from all
</Location>

Save the file.

3. Reboot the Readynas to pick up the changes.

4. Create a test .pl file

SSH login using PuTTY or similar to root/admin.

cd intranet/cgi-bin
vi test.pl

#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "<H1>Hello 2 my World</H1>\n";

Save the file.


5. Go to a browser and run the file:

http://serverip/intranet/cgi-bin/test.pl

If it does not work, check the permissions on the file ( CHMOD if necessary ) and also that you created
the .pl file using vi. Files created by notepad or wordpad dont work properly because the EOL character
used in Windows is incorrect.

winsbury wrote:
1. edit httpd.conf to ensure the additional .conf files are loaded last. (...) change the sequence of the last two lines from : Include /etc/frontview/apache/addons/*.conf Include /etc/frontview/apache/Shares.conf to: Include /etc/frontview/apache/Shares.conf Include /etc/frontview/apache/addons/*.conf

Should not be necessary. At least I didn't have to make any changes in the loading of the config files to make it work.

winsbury wrote:
3. Reboot the Readynas to pick up the changes.

It's not necessary to reboot. Just do a

apache-ssl -k restart -f /etc/frontview/httpd.conf

winsbury wrote:
4. Create a test .pl file (...) cd intranet/cgi-bin vi test.pl #!/usr/bin/perl print "Content-type: text/html\n\n"; print "<H1>Hello 2 my World</H1>\n"; Save the file.

Since the file needs to be executable by the user the web server is running as, you should make that so immediately:

chmod 755 test.pl

Saves you the hassle of testing first, failing, and then changing the permissions anyway ;)

-Stefan

Thanks for the comments Stefan,

Changing the sequence of the last two lines in httpd.conf was needed on my system as the settings in Shares.conf were overriding those in CGI.conf possibly because /intranet is higher up the tree than /intranet/cgi-bin. Although I could have added the settings in Shares.conf to get around this issue I didnt go that route since this file is generated by Frontview so the changes might have been overwritten should any additional shares be edited/created. In any case, it seems counter-intuitive to me to load the definitions for the add-ons prior to the Shares so I figured this was a sensible change regardless.

Yes indeed you can reload without a full re-boot, however I prefer a full reboot as a final check to ensure the system will definitely come up again, better to find out now rather than later ! Its also worth noting also that stopping and starting the html service within Frontview will not force a reloading of the httpd.conf file.

winsbury wrote:
Changing the sequence of the last two lines in httpd.conf was needed on my system (...) it seems counter-intuitive to me to load the definitions for the add-ons prior to the Shares so I figured this was a sensible change regardless.

You're right there but keep in mind that httpd.conf will get overwritten on Firmware updates. So your changes will get lost in that case. That's why I'd recommend to search for an other solution there. Maybe adding a .conf file named ZZZ_whatever.conf so this would get loaded last or something along these lines.

winsbury wrote:
Yes indeed you can reload without a full re-boot, however I prefer a full reboot as a final check to ensure the system will definitely come up again, better to find out now rather than later !

Of course it's ok to do a reboot as a final check but I find it rather tedious to do a restart after every change to the apache config files ;)

winsbury wrote:
Its also worth noting also that stopping and starting the html service within Frontview will not force a reloading of the httpd.conf file.

Well, no. It will actually restart apache (at least it did for me). However, your current session won't be affected by that. Or in other words: the task you're connected to will only restart after you quit your browser session. And thus you're not going to see any real changes unless you quit and restart your browser.

-Stefan

Whocares? wrote:
httpd.conf will get overwritten on Firmware updates

yes this is quite true and quite a problem - especially since there are other changes to this file needed for wordpress / php / phplists and similar other popular add-ons. My solution is to carefully document all changes made to such files so that they can be repeated later if necessary but it would be MUCH neater if some level of customisation could be tollerated and still allow standard upgrades.

Whocares? wrote:
It will actually restart apache

I must admit I didnt test this aspect very thoroughly and certainly didnt restart the browser or flush the cache, so you are probably right.

Whocares? wrote:
it's ok to do a reboot as a final check

Assuming the steps are done correctly first time there should only be one reboot required but I totally accept that isnt usually the case when making system changes. particularly if you're anything like me :wink:

Regards

Dean.