[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
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:
the language format in question. for example, "php".
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.
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.
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).
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.
TODO
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ next ]
webbapps-common developer documentation
$Revision: 133 $