On Tue, Jan 10, 2012 at 12:36:24PM +0000, Brett Parker wrote:
On 09 Jan 17:16, Chris Green wrote:
In the default apache2 installation on Ubuntu you get the following setting in the default virtual host:-
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/This means that CGI scripts are in the /usr hierarchy which doesn't seem very helpful. Is the the norm for apache2 or is it just Ubuntu's doing?
It's a debian thing, really...
And the main reason is because that's where packages will drop their cgi files by default.
Yes, I suppose so, but that works on the assumption that any CGI is cast in stone rather than something that might need configuration or tuning.
Similarly config files for gallery2 for example get put in /usr/share and then the ones that need local configuration are made into symbolic links and are put somewhere else, all a bit of a bodge.
I've given www-data a proper home directory under /home and have made /var/www a symbolic link to /home/www-data/www.
I'm thinking I either want to point it to some suitable /home/<user> directory or possibly somewhere below /var/www, is there anything wrong with doing either of these (assuming suitable security protection of course).
Really /var/www should be taken out back and shot, it was a bodge in the first place, and has just managed to stay there. These days I tend to serve from /srv/http/<websitename>, as the /srv heirarchy is gauranteed to be in sysadmin control, and packages are not allowed to touch it (at least in theory!).
Yes, it's a bit odd /var/www isn't it, but there's other stuff down there (under /var I mean) that's similar in its intent, stuff such as crontabs and mysql databases which are local configuration/data that you want to preserve as opposed to real /var stuff such as cache data and /tmp.
I've wondered about using /srv but it's not much use unless standard setups start using it, I'm trying my best to minimise how much customisation I do.
I also tend to write wrapper scripts for cgis and use apache2-suexec-custom to set the cgi root to a sensible ish place, and run the cgis as a different user to the webserver...
At the moment I have only one CGI script which is for local use only, if someone off site clicks on the link it won't work.