From: Max Kalika <max@gentoo.org>
To: stuart@gentoo.org, Paul de Vrieze <pauldv@gentoo.org>,
gentoo-dev@gentoo.org
Subject: Re: [gentoo-dev] [GLEP] Web Application Installation
Date: Tue, 05 Aug 2003 14:00:54 -0700 [thread overview]
Message-ID: <12930000.1060117254@valkyrie.lsit.ucsb.edu> (raw)
In-Reply-To: <200308051219.49435.stuart@gentoo.org>
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
next prev parent reply other threads:[~2003-08-05 21:00 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-04 23:16 [gentoo-dev] [GLEP] Web Application Installation Max Kalika
2003-08-05 0:14 ` Stuart Herbert
2003-08-05 2:30 ` Donny Davies
2003-08-05 10:12 ` Stuart Herbert
2003-08-06 4:01 ` Donny Davies
2003-08-05 3:04 ` Max Kalika
2003-08-05 10:39 ` Stuart Herbert
2003-08-05 9:34 ` Paul de Vrieze
2003-08-05 11:19 ` Stuart Herbert
2003-08-05 11:37 ` Paul de Vrieze
2003-08-05 21:00 ` Max Kalika [this message]
2003-08-05 23:43 ` Cal Evans
2003-08-06 1:54 ` Stuart Herbert
2003-08-06 2:16 ` Robin H.Johnson
2003-08-06 2:44 ` Stuart Herbert
2003-08-06 4:37 ` [gentoo-dev] [GLEP] Web Application Installation. Plotting a VHOST config tool Robin H.Johnson
2003-08-06 12:48 ` Stuart Herbert
-- strict thread matches above, loose matches on Subject: below --
2003-08-07 1:08 [gentoo-dev] [GLEP] Web Application Installation Troy Dack
2003-08-04 17:11 Max Kalika
2003-08-04 22:16 ` Stuart Herbert
2003-08-05 9:49 ` Michael Cummings
2003-08-02 16:50 Troy Dack
2003-08-02 20:39 ` Robin H.Johnson
2003-08-02 23:11 ` [gentoo-dev] Re: [gentoo-core] " Max Kalika
2003-08-02 23:51 ` Stuart Herbert
2003-08-03 2:26 ` [gentoo-dev] " Max Kalika
2003-08-03 14:46 ` Stuart Herbert
2003-08-03 15:20 ` Max Kalika
2003-08-03 17:43 ` Stuart Herbert
2003-08-03 19:03 ` Max Kalika
2003-08-03 19:43 ` Stuart Herbert
2003-08-04 4:29 ` Max Kalika
2003-08-04 10:43 ` Stuart Herbert
2003-08-03 0:30 ` Austin Frank
2003-08-03 7:50 ` Tal Peer
2003-08-03 14:45 ` Don Seiler
2003-08-05 8:12 ` Troy Dack
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=12930000.1060117254@valkyrie.lsit.ucsb.edu \
--to=max@gentoo.org \
--cc=gentoo-dev@gentoo.org \
--cc=pauldv@gentoo.org \
--cc=stuart@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox