I'm looking to package a CGI application for installation by others and want to minimize the amount of web server reconfiguration required by the admin. The target platform is Linux or another UNIX-like OS and Apache.
Lets say we're starting with an application with the following directories: cgi/ lib/ templates/ html/ In one traditional approach the cgi/ files get copied to a directory under cgi-bin/, templates/ might be a subdirectory below that, and html/ is copied to some directory under the docroot. Then the main CGI script is often modified to tell it where to find lib/ in the file system. Not only is this ugly, it creates several dependencies. The CGI code needs to know where the libraries are (unless they're installed into standard Perl library directories, though that may be undesirable if the libraries are only used for the CGI application). The CGI code also needs to know where the static images (html/) are located, and it needs to know where to find templates/, but that problem is usually lessened by using a relative path. On top of that there is usually a configuration file that the CGI needs to know where to find so it can know how to connect to the database. It's tempting to make use of relative paths for as much as possible, but some files, for security reasons, you don't want to appear in any directory that the web server might think is under its docroot. I remember at the last meeting a few people were discussing the static file plug-in for Catalyst, and I was wondering what the significant interest was in serving up static files through a dynamic app. Now I'm wondering if that approach might be used to eliminate some of these dependency issues. Personally I lean towards the Dan Bernstein-ish (http://cr.yp.to/slashpackage.html) approach to application installation where all the app's files are kept together in one subdirectory, and then symlinks (or Apache aliases) are used to point to them. It also makes upgrading/downgrading easier. But for that approach to work requires that Apache be configured with a type handler for the script's extension and for FollowSymlinks to be enabled, or for the application directory to be declared a script alias and the html directory to be aliased or symlinked to. I believe by default Apache doesn't come with a type handler enabled for .cgi or .pl, and likewise FollowSymlinks is off. It seems with Apache 2.0 the latter problem - adding a custom script alias - can more easily be addressed, as the application's installer can drop a custom configuration file into the conf.d directory. This seems to be the closest way to achieve the ideal of not having to embed any paths into the CGI script at installation time. You let the user pick a URL prefix (defaulting to the app-name) and then use that to generate an Apache conf file with the necessary ScriptAlias and Alias directives, as well as stashing the prefix in the application's configuration file so dynamically generated paths to static content will be correct. Everything else, such as the path to the config file or the libraries, is relative to the cgi/ directory. Years ago there was cgi-bin and everyone piled their scripts in that one directory, or at best made a subdirectory from it. Thankfully that ugliness is behind us. Though now it is less clear what the most popular conventions are for installing plain old CGI applications on modern systems. I'd be curious to hear what other people are doing to address this and tricks for minimizing the dependencies. -Tom _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
