man 5 webapp.eclass says: webapp_server_configfile server file newfile Use this function to install a webserver configuration file. The configuration file is installed into ${MY_SERVERCONFIGDIR}, and webapp-config will install this file during install (-I mode). But if you try to use it in an ebuild, e.g., like this: webapp_server_configfile apache "${FILESDIR}/${PV}/vhost.conf" And if you do run webapp-config -I -s apache -h somehost -d someapp someapp someversion after the ebuild had installed successfully, then actually nothing is installed from ${MY_SERVERCONFIGDIR}. I see several problems: 1.) The webapp-config python code base makes no provisions for installing these files 2.) At least an apache vhost.conf is per virtual server. Hence the file passed to "webapp_server_config_file()" had to be a template. 3.) Due to sandbox restrictions, a script hooked via "webapp_hook_script()" isn't allowed to write to /etc/apache2/vhosts.d, so this installation should be handled uniformly by a webapp-config. A vhost configuration template for apache could look like this: <VirtualHost *:80> DocumentRoot ${VHOST_ROOT} <Directory ${VHOST_HTDOCSDIR}/${VHOST_APPDIR}> Order allow,deny Allow from all </Directory> <Files *.ini> Order deny,allow Deny from all </Files> ServerName ${VHOST_HOSTNAME} ServerAlias http://${VHOST_HOSTNAME} </VirtualHost>
I'm thinking about how to solve these issues and would welcome your comments. For a turnkey installation of a typical web-application, you need to able to automatically 1.) configure the application itself (already supported by hooked scripts) 2.) configure a user selectable dbms (support incomplete) 3.) configure a user selectable http server (support incomplete) My proposal is this: select a specific set of templates matching the actually installed type of http- and database server types, pipe them through a sandboxed shell for VHOST_* pattern substition, and use their respective output to generate a vhost configuration file and database setup script(s). Thus the main burden to support a variety of server types would be with the ebuild author, while webapp-admin would provide a rigid framework, knowing only about where to place vhost config files, which DBMS interpreter to run, or how to enforce some basic safety rules (e.g. run the equivalent of apache -t for syntax checking of vhost.conf files, embed the generated database setup script within transaction on targets which supports it with DDL, ask before overwrite existing files and so on.) Luckily, "server.py" (in usr/lib/python2.6/site-packages/WebappConfig) already uses an inheritance scheme to implement support for different http server types, so extending that framework a bit shouldn't be too difficult. In detail: - flag webapp_server_configfile and webapp_sqlscript as deprecated. - create a new webapp.eclass function webapp_config_template(), having three parameters: <"http"|"dbms"> <http-type>|dbms-type> filename where "http-type" maps to the list of web servers supported by webapp-config, and dbms-type likewise for supported DBMS (see below) - add a webapp-config command line option "--dbms-type" to select a database system, analogous to the already existing"--server" option, which specifies the http server type. - add a webapp-config command line option "--dbms-host" and pass it's value to a a newly created "VHOST_DBMS_HOST" environment variable. - a general form of the template would be flexible and simple: #!/bin/sh cat <<- EOF some statement ${SOMEVAR} EOF - such a template would use the documented set of environment variables already passed to hooked scripts (see man 5 webapp.eclass) plus VHOST_DBMS_HOST, but not something like VHOST_DBMS_TYPE. - during the webapp-admin install phase, pipe these templates through a sandboxed shell -- much like it is already done with hooked scripts, except that the output written to stdout is used to * create an application+user specific vhost configuration within the particular configuration space (in /etc/apache/vhost.d/, e.g.) * feed it as a database setup script the dbms specific interpreter implicitely selected by "--dbms-type", addressing the database service running on the host specified by "--dbms-host"
Devan, can you test this and see if it is still an issue.
