Gentoo Archives: gentoo-dev

From: Stuart Herbert <stuart@g.o>
To: Max Kalika <max@g.o>, Troy Dack <tad@g.o>, gentoo-dev@g.o
Subject: Re: [gentoo-dev] [GLEP] Web Application Installation
Date: Tue, 05 Aug 2003 00:16:34
In Reply to: Re: [gentoo-dev] [GLEP] Web Application Installation by Max Kalika
1 'lo Max,
3 On Tuesday 05 August 2003 12:16 am, Max Kalika wrote:
4 > > a) A bit of mod_alias magic, and you make the /phpbb/ directories aliases
5 > > for /usr/share/webapps/phpBB-<version>/files/. If you do this, though,
6 > > how do you get each copy of phpBB to use a separate set of configuration
7 > > files? What happens when the app needs write-access to the directories?
8 > > The directories are on /usr, and we're all agreed that /usr should be
9 > > mountable read-only. And does every webserver have something like
10 > > mod_alias in the first place?
11 >
12 > If not mod_alias, then symlink to the DocRoot, but then we're back to not
13 > knowing where the user configured his/her/virtualhosts's DocRoot.
15 mod_alias provides aliases for URLs. Why would you need to know what DocRoot
16 is?
18 > > If I've understood your eclass correctly, this is what it tries to do,
19 > > yes?
20 >
21 > Yes.
23 Ah good.
25 > > b) A bit of .htaccess magic, and you have the directory structure of the
26 > > webapp on /var, but directives telling PHP where to find the .php files
27 > > by setting the include_path. The config file problem is solved, because
28 > > you can drop in local config files, and there are real directories that
29 > > can be made writable. Only problem with this approach is that not every
30 > > type of web server has the equivalent of .htaccess files - and the PHP
31 > > SAPI for each type of web server doesn't necessarily support
32 > > configuration directives in config files either. And that's before we
33 > > think about Perl, Python and other ways that webapps can be implemented.
34 >
35 > Local config files? Where would these be stored? How are these handled
36 > for virtual hosts?
38 They would be stored under the virtual DocRoot, for example (using the paths
39 for my example) in /var/www/
41 Putting the config file into the virtual DocRoot is where Robin's tools would
42 come in (Robin, are you following this thread at all?). We could put a
43 master copy - a skeleton if you like - in /etc/webapps/<app-name>/. It's the
44 skeleton that gets updated by portage.
46 > > Because that's what USE flags are there for. If the user puts '-apache2'
47 > > in their USE flags, it's the job of the ebuild to respect that.
48 > > Otherwise, the ebuild is broken - and probably in breach of policy too.
49 >
50 > Ok, this is debatable, but I'm willing to change the eclass to take
51 > -apache2 into effect.
53 [OT, but interesting] How is this debatable?
55 > We can still achieve flexibility along with smaller ebuilds. If we break
56 > down the eclass install function into smaller functions and optionally call
57 > them from install, we've got ourself a nice tidy system.
59 Good idea - I'll sign up to that.
61 > Here's the problem. First of all, SLOTing won't help that because it
62 > assumes that the versions of the packages *and* the files you are
63 > installing are _different_. I.e. db4 and db3 are SLOTted: they install
64 > and respectively and thus can run simultaneously.
66 I must be missing something. Why won't SLOTing help? The behaviour you've
67 described is *exactly* the behaviour that I want. Why can't phpBB-2.0.4 and
68 phpBB-2.0.5 run at the same time on the same box, but under different virtual
69 domains?
71 > Now, wrt to the whole virtual server thing. Personally if I was running a
72 > server with, as you say, a non-trivial number of virtual domains who have
73 > different needs, I probably wouldn't use a package management system to
74 > begin with, or truly virtualize everything and use something like
75 > user-mode-linux in which case we're back to single-domain installs.
77 UML is one solution, but the overhead is not insignificant.
79 If the package management system provided a viable solution, don't you think
80 that people would use it?
82 > Going along with your example, how can you do an 'emerge -u phpBB' _for a
83 > particular domain_?
85 Like this.
87 a) emerge -u 'webapp' installs the master copy of 'webapp' in /usr/webapps.
88 If the webapp is SLOT'ed, none of the domains are upgraded at this point.
89 b) Then, run 'webapp-config --upgrade <webapp> /path/to/domain/directories' to
90 upgrade the specific domain.
92 Two stage process. Finally, once all domains are upgraded, you can simply do
93 an 'emerge -C webapp-old-version' to remove the old SLOT'ed version that is
94 no longer required.
96 What's wrong with this as a solution?
98 > You're telling portage to maintain a package, and
99 > upgrade parts of it randomly.
101 Nope. I'm telling Portage to maintain the master copy of a package, and to
102 upgrade that master copy only.
104 > I simply don't think portage will ever have
105 > any way of handling multiple installs of a package in this manner.
107 Why does Portage have to do *everything*? We use portage to get the app +
108 dependencies onto the box, and we use additional tools to manage the virtual
109 domain upgrades.
111 > How
112 > about we (Gentoo) just provide single domain/host installs and maybe
113 > SLOTing different versions so they won't be overwritten on upgrades.
114 > Beyhond that, we have to let the sysadmins know to cp -l the installed
115 > files into their vhosts.
117 Because we can do better?
119 > AFAIK, no other distro has support for virtual hosting because of this very
120 > issue.
122 I have no idea whether other distros support virtual hosting, and if they
123 don't, why they don't. If you have any threads I can read on this, please
124 send them my way. Otherwise, your statement is an assumption, and
125 assumptions are the mother of all screw-ups.
127 > The most robust solution would be to create a new group (web?) and make all
128 > the webserver users be a part of that group and make these directory
129 > group-owned by said group. (Similar to the "mail" group for many
130 > mail-related services)
132 Why is that robust?
134 > Which takes me back to
135 > wanting to support a single instance install of an app that an admin has to
136 > copy in place if the default location is unacceptable.
138 It's one solution, sure. I think we can do better, and I'm willing to write
139 the code to do it if necessary.
141 > > * /usr/webapps/<app-name> as the main directory.
142 > > * /usr/webapps/<app-name>/public_html/ for files served by the web server
143 > > * /usr/webapps/<app-name>/cgi-bin/ for CGI-BIN files
144 > > * /etc/webapps/<app-name>/ to hold the box-default config files
145 > > * <app-name> is ${PN} for non-slotted packages
146 > > * <app-name> is ${P} for slotted packages
147 >
148 > I'd say <app-name> should just be ${PF} for both and not worry about what
149 > is SLOTed and what is not -- it works itself out.
151 (thinks about this) I'd want to test it to be sure, but I think ${PF} would
152 work out okay. Depends whether having the -rX part of the package name is
153 really important or not.
155 > Otherwise, this seems ok to me and is easy to implement in the eclass.
157 Good-o. So the two of us (ominously quiet in here ;-) are in agreement then?
158 Oh, thought it was too good to be true ;-)
160 > The only thing I would
161 > change is the names public_html and cgi-bin. There may be no html and not
162 > binary files in them (respectively). How's about 'public' and 'cgi'? (I
163 > know, I know, nitpicking).
165 Shrugs. I just picked 'public_html' because it's a recognised convention
166 (although not the only one I'm sure). 'public' is too generic for my liking.
167 'cgi-bin' *is* a recognised convention, and one we shouldn't break.
169 > Is the approach currently in the eclass unacceptable? (Check for the
170 > existance of the directory/configfile)
172 I think so. See how I determine which version of apache to use in
173 webapp-apache.eclass (as stolen/morphed from Robin's mod_php ebuild!)
175 > > b) you need to honour the 'apache2' USE flag
176 >
177 > Yup, see, higher than that. Ok there, stop!
179 Lol. For now, just make your eclass rely on mine, seeing as mine's already in
180 Portage ;-) and re-use what's already coded. No offence, but because of the
181 reasons in one of my earlier emails, I don't think your eclass should go into
182 Portage until the outcome of this GLEP is determined.
184 Take care,
185 Stu
186 --
187 Stuart Herbert stuart@g.o
188 Gentoo Developer
189 Beta packages for download
191 GnuGP key id# F9AFC57C available from
192 Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
193 --