Question

I’m maintaining some CGI web applications, which I’m migrating to a new Linux web server, on which I have a non-admin account, say www_maintainer. So I am installing the CGI applications inside /home/www_maintainer/, and I’d like to take the opportunity to clean things up, in particular the cgi-bin/ directory could be better organized; I’d like to learn about a best-practice standard for that.

For instance, is it normal to have subdirs called bin/ and lib/ inside cgi-bin/, with the binaries and libraries of auxiliary things?

I will describe a specific example, namely with the math- and data plot application gnuplot and its dependencies (libfontconfig, libpng , libgd, libjpeg, libreadline.so, …).
Python could be another example (the distro provides 2.4 but I need >2.6), however I hope the admin can install 2.6 from a package so I don’t have to worry about it.

The new web server has Scientific Linux (SL), which is based on Redhat RHEL. Unfortunately the distro repository for our current SL version does not provide gnuplot version 4.4 which I need, so it cannot be installed in the normal place like /usr/bin/, so I could build and install it and its dependencies in a non-system location, for example cgi-bin/tools/. The actual CGI web applications are binary executables launched by the scripts launch1.sh or launch2.sh.

Here is a illustration of the directory tree and some of the files in there (many dirs and files omitted of course).

cd /home/www_maintainer/www_root/

|-- html/
|   |-- index.html
|   `-- info.html
|-- cgi-bin/
|   |-- gen/
|   |   |-- status.sh*
|   |   `-- sybase/
|   |       `-- DataAccess64/
|   |           `-- ODBC/
|   |               |-- lib/
|   |               |-- samples/
|   |               `-- spl/
|   |-- exe1/
|   |   `-- launch1.sh*
|   |-- exe2/
|   |   `-- launch2.sh*
|   |-- javascript/
|   |   `-- check-input.js
|   |-- scripts/
|   |   |-- decode.pl*
|   |   |-- generate-random-string.bash*
|   |   |-- gnuplot -> ../tools
|   |   `-- upload.php*
|   |-- tools
|   |   |-- bin/
|   |   |   |-- gnuplot*
|   |   |   |-- python -> python2.6
|   |   |   |-- python-config -> python2.6-config
|   |   |   |-- python2.6*
|   |   |   |-- python2.6-config*
|   |   |   `-- xmlwf*
|   |   |-- etc
|   |   |   `-- fonts/
|   |   |-- include/
|   |   |-- info/
|   |   |-- lib/
|   |   |   |-- libfontconfig.so
|   |   |   |-- libpdf.so
|   |   |   |-- libreadline.so
|   |   |   |-- libpng15.so
|   |   |   |-- libpng15.so
|   |   |   |-- pkgconfig/
|   |   |   |-- libpng.so
|   |   |   |-- libjpeg.so
|   |   |   |-- libreadline.so
|   |   |-- libexec/
|   |   |-- man/
|   |   `-- share/
|-- tests/
|   `-- results/
|       `-- info/
|           |-- readme.pdf
|           `-- readme.html
|-- fonts/
|-- index.html -> html/index.html
|-- log/
|   `-- log.txt
`-- tmp -> /tmp/

Would it be better to install outside the www_root, e.g.in the directory /home/www_maintainer/bin/ and /home/www_maintainer/lib/ and configure the web server to allow that?

Answer 1

EDIT: 05/23/2012 3pm PT US

If you’re restricted to the user’s directory, you can do pretty much whatever you want.

What used to be the common case was that you put all of the CGI-using files (Perl, etc) into the cgi-bin directory and you can (and probably should) put those in subdirectories based on the purpose or application.

Then you put the non-CGI files outside of the cgi-bin directory, which includes any bare HTML files, graphics files, CSS files, JS files, etc.

For any programs that are used by the CGI files but not directly by the web user, do not put them in the webroot at all as that is not necessary and could be a security hole if the web user can submit values into those programs in some fashion.

Directory tree example:

/home/www_maintainer/public_html/index.html
/home/www_maintainer/public_html/images/logo.png
/home/www_maintainer/public_html/scripts/something.js
/home/www_maintainer/public_html/cgi-bin/application1/app1.cgi
/home/www_maintainer/public_html/cgi-bin/application2/app2.cgi
/home/www_maintainer/public_html/cgi-bin/application2/app2helper.cgi
/home/www_maintainer/tools/gnuplot/gnuplot
/home/www_maintainer/tools/python/python -> python2.6
/home/www_maintainer/tools/python/python2.6
/home/www_maintainer/tools/python/python2.6-config

Then in your CGI files, make sure that the paths to the tools are set correctly as needed. It is not necessary for web users to access those tools directly, so keep those out of access. If you’re doing python via CGI (which I assume, in this case), make sure your shebang line shows the correct path; #!/home/www_maintainer/tools/python/python, for example.

---

Original answer:

What a lot of applications do, such as the ones distributed with Debian, is put their applications in the /usr/share/lib/programname directory and then use an Apache Alias and ScriptAlias to map them to a base URL. This is how I used to run our own internally-developed applications as well and that worked very well.

For your situation, I’d recommend changing as little as possible unless you plan to enhance the code or the system more and more over time. Making changes could bring headache if paths change, especially if any are bookmarked, unless you want to get cozy with some mod_rewrite in your config.

Do you have any specific examples that I could use to demonstrate what I’ve described?

Also, with regard to ancient /usr/bin/python, is your system completely up-to-date? Or is the problem that your Linux distribution just doesn’t push a newer version? I’d avoid installing a version of Python that isn’t managed by your distro’s package management system.