Re: [gentoo-dev] [GLEP] Web Application Installation

[Max Kalika]

Quoting Stuart Herbert <stuart@g.o>:

> Thanks for joining in.  I was getting worried that this was turning into
> the  'Max & Stuart Show' ;-)

Can we get a time slot on FOX?  I'm thinking 9:12AM. :-)

> Under the '+vhosts' approach, webapps would be SLOT'd, and would go into
>
> 	/usr/share/webapps/${PF}/

Just the SLOTed? Or all the webapps?  Why not all?

> and users would have to use the -config toolset to then make the app
> available  inside one or more vhosts.
>
> What would happen in the '-vhosts' world?
>
> I think it all pivots around one crucial design decision.  In the
> '-vhosts'  world, do we want 'emerge -u' to be all that the user has to
> do (i.e. no need  for the -config toolset)?  If not, then I can't see
> what '-vhosts' would  actually do, and I'd suggest dropping it.

I don't think we want emerge -u to touch anything other than the central
install.

> I think the webapp would have to be installed directly under the
> 'DocumentRoot' (/home/httpd/htdocs currently for Apache), instead of
> /usr/share/webapps/.  Would this create support hell if a user then
> wanted to  move to vhosting on the same box?  emerge -C <webapp> will
> clean up  correctly, so I'm not worried about that.  I think we could
> live with this.
>
> As for config-protecting a webapp's configuration files, I'd do it by
> making  the eclass add the config files to the CONFIG_PROTECT mask
> somehow.  The  webapp ebuild needs to be able to identify the package's
> config files as part  of the '+vhosts' solution, so the information would
> be available.  But I  wonder if we'd need a change to Portage to allow
> the eclass to dynamically  add these files to the CONFIG_PROTECT mask.
> It wouldn't need to be a  permanent addition - in fact, I'd argue against
> it.

Is it really necessary to separate the whole virtual/local?  Can we develop
the -config tool to take the following syntax?

  # webapp-config <application> <destination_dir>

The application can be specified by the currently supported portage syntax,
i.e. =web-dev/horde-2* or >=web-mail/imp-3 or simply web-db/phpmyadmin.
The tool then looks for a list of installed apps that match.  If more than
one is found it either bombs out or presents a choice menu.

Otherwise it goes ahead and configures the destination_dir to contain the
specified app.  First it checks for existence of the app already in the
destination.  If nothing exists, we create the directory, and copy the core
and conf files in.  If the app already exists, we switch to "upgrade" mode
where we overwrite all the core files and do dispatch-conf-type work to
protect the config files.

How do we know which files are config files and which are core files, I
hear you asking?  How about this:  Either use the Portage API or look at
the /var/db/pkg/$CATEGORY/$PF/CONTENTS file ourselves.  'obj' types stored
in '/usr/share/webapp' (or $WEBAPP_DEST or whatever) are "core" files;
'obj' types stored in '/etc/webapps' (or $WEBAPP_ETC) are "conf" files.
Everything else (docs, etc) doesn't need to go into the webserver space.

So if this is how things work, there's no need to worry about what is a
vhost and what is a single install.  Also we don't have to be concerned
where the DocRoot is -- the user just specifies the destination directory.

I guess this is a very rough first-draft proposal for the webapp-config.  I
am probably missing major chunks, but this is a braindump of what I thought
of so far.  Flog me for anything blatantly erroneous.


--mk

--
gentoo-dev@g.o mailing list