Bug 294229 – app-admin/webapp-config-1.50.16-r3 does not install http server config files

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Hugo Mildenberger 2009-11-23 17:05:43 UTC]

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>

[Comment 1 Hugo Mildenberger 2009-11-24 14:10:55 UTC]

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"

[Comment 2 Anthony Basile 2013-08-03 14:43:22 UTC]

Devan, can you test this and see if it is still an issue.