* Re: [gentoo-dev] [GLEP] Web Application Installation
@ 2003-08-05 21:00 99% ` Max Kalika
0 siblings, 0 replies; 1+ results
From: Max Kalika @ 2003-08-05 21:00 UTC (permalink / raw
To: stuart, Paul de Vrieze, gentoo-dev
Quoting Stuart Herbert <stuart@gentoo.org>:
> 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@gentoo.org mailing list
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2003-08-04 23:16 [gentoo-dev] [GLEP] Web Application Installation Max Kalika
2003-08-05 0:14 ` Stuart Herbert
2003-08-05 9:34 ` Paul de Vrieze
2003-08-05 11:19 ` Stuart Herbert
2003-08-05 21:00 99% ` Max Kalika
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox