[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]


webbapps-common developer documentation
Chapter 3 - Advanced Techniques and Concepts


3.1 Automatic Configuration Generation

It's quite possible, that your application will need to access some configuration details at run-time, via an included configuration file. for example, it might need to know the name of the virtualhost on which it resides, or perhaps the root subdirectory from which it is being accessed. This can easily be done by setting the variable wc_generate_include, in your postinst and postrm scripts before calling wc_go. The format of this variable is mode:src:dest:

mode

the language format in question. for example, "php".

src

your provided config template. this file will look generally how you expect your application's configure to look, only it can contain various substitution expressions.

dest

The location where the includable configuration file should be placed. Your application should then only need to include this file ("require_once in php, for example). Note: this file will not actually contain the configuration template, but instead include a second (and also automatically generated) file unique to the "instance" of the application. for example a value of dest set to "settings.php" will also generate a settings-siteid.php that contains the configuration for the site associated with siteid.

for a quick example of this, please see the webapp-apache-example package in the examples subdirectory in the webapps-common documentation, and also the list of substitutable values in Configuration template substitution variables., Section 5.2.


3.2 Database Applications

Some web applications require an underlying database. This can be done by setting the hint variable wc_dbtype (in the case that your app supports only one database type) or wc_dbtypes (in the case that your app supports multiple database types). Note that this must be done in each of your maintainer scripts that call wc_go (config, postinst, prerm, and postrm). These variables will be used to influence and invoke dbconfig-common's database configuration support. Various other dbconfig-common hint variables can also be used to customize how your package handles database configuration; for more information, see the dbconfig-common Documentation

Note that due to the needs of multi-instance support, it is not currently possible to override the names for the database or database user name (dbc_dbuser and dbc_dbname).


3.3 Multiple Instance Support

Some web applications support (or can be easily extended to support) the concept of "multi instance" installations, where a single set of files can be used to serve up multiple versions of an application. For example, it might be desirable for a webserver providing multiple virtualhosts to provide a seperate instance of a webmail application on each virtualhost. Alternatively (or additionally) the ability to provide different instances of the same application under different subdirectories of the same virtulhost might be desirable.

webapps-common provides drop-in support for such applications, including support for generating unique configuration files for each instance (to allow for different passwords, different database configurations, etc). To take advantage of this feature, you need to simply hint webapps-common in your config script by setting the variable wc_multiple_instances="yes". example:

     	if [ -f /usr/share/debconf/confmodule ]; then
     		. /usr/share/debconf/confmodule
     	fi
     	if [ -f /usr/share/webapps-common/dpkg/config ]; then
     		. /usr/share/webapps-common/dpkg/config
     		wc_multiple_instances="yes"
     		wc_go mypackage "$@"
     	fi

Additionally, if you use the wc_generate_include feature for generating your configuration files, you will not need to worry about setting per-instance-configuration--this will be taken care of for you.

however, it is still the responsibility of the application (and by extension, you the package maintainer) to ensure that the application can function properly when having multiple instances configured in parallel. for example, if your web application requires a daemon running in the background for each instance, or a dedicated filesystem directory for each instance, that is currently outside the scope of webapps-common. note: this will probably change in the future, after getting feedback from some maintainers. and in the meantime you can probably hack in whatever support you need yourself using some of the webapps-common variable substitutions when generating your config.


3.4 Multiple Instances and Database Support

TODO


[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]


webbapps-common developer documentation

$Revision: 133 $

Sean Finney