Gentoo Archives: gentoo-dev

From: Max Kalika <max@g.o>
To: stuart@g.o, Max Kalika <max@g.o>, Troy Dack <tad@g.o>, gentoo-dev@g.o
Subject: Re: [gentoo-dev] [GLEP] Web Application Installation
Date: Mon, 04 Aug 2003 23:16:19
1 Quoting Stuart Herbert <stuart@g.o>:
3 > Here's an example. Imagine hosting (oh, I don't know) and
4 > on the same physical box. Document roots for each are
5 > /var/www/<host>/public_html/ for arguments sake.
7 Love those names. I wonder if they're taken? ;-)
9 > a) A bit of mod_alias magic, and you make the /phpbb/ directories aliases
10 > for /usr/share/webapps/phpBB-<version>/files/. If you do this, though,
11 > how do you get each copy of phpBB to use a separate set of configuration
12 > files? What happens when the app needs write-access to the directories?
13 > The directories are on /usr, and we're all agreed that /usr should be
14 > mountable read-only. And does every webserver have something like
15 > mod_alias in the first place?
17 If not mod_alias, then symlink to the DocRoot, but then we're back to not
18 knowing where the user configured his/her/virtualhosts's DocRoot.
20 > If I've understood your eclass correctly, this is what it tries to do,
21 > yes?
23 Yes.
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.
35 Local config files? Where would these be stored? How are these handled
36 for virtual hosts?
38 > c) A bit of find and cp -l, and you've got the directory structure of the
39 > webapp on /var, plus links back to the original on /usr. Again, the
40 > config file problem is solved, because local copies can be parachuted
41 > in, and again there are real directories that can be made writable. No
42 > webserver-specific tricks are required - as far as the web server is
43 > concerned, each domain has its own installation of phpBB.
45 Ok, I'll pool some replies below...
47 >> Why base it on the flag? If the webserver is installed and is supported,
48 >> configure for it.
49 >
50 > Because that's what USE flags are there for. If the user puts '-apache2'
51 > in their USE flags, it's the job of the ebuild to respect that.
52 > Otherwise, the ebuild is broken - and probably in breach of policy too.
54 Ok, this is debatable, but I'm willing to change the eclass to take
55 -apache2 into effect.
57 >> This whole thing needs a separate discussion. There's no portage support
58 >> for dealing with more than one installation of the same version of the
59 >> same package.
60 >
61 > Why a separate discussion? If this GLEP isn't here to address this
62 > fundamental issue, then I'd say that the GLEP has the wrong scope.
63 >
64 > You're right - Portage currently can't do all of this on its own.
65 > Perhaps it never will be able to. As I understand it, that's why
66 > Robin's volunteered to write and maintain additional tools to bridge the
67 > gap.
69 Keep reading, going to answer this below. :-)
71 >> Keep in mind it is not completely accurate if the per-package
72 >> USE flags goes into portage
73 >> ( Things in PUSE will also
74 >> have to be taken into account. But this is a completely different
75 >> matter and will be easy to integrate.
76 >
77 > It's a nice start though. Ideally, we need a programatic interface to
78 > portage, an API we can use to handle these types of queries. karltk is
79 > working on one ;-)
81 Cool!
83 >> Thats just more to call from the ebuild. My goal was to have very small
84 >> ebuilds -- just declare a few variables and inherit the eclass.
85 >
86 > Hmm ... there's a tradeoff here. Smaller ebuilds and less flexible (and
87 > re-usable) eclasses. Or larger ebuilds, but more re-usable eclasses. I
88 > guess I prefer the latter.
90 We can still achieve flexibility along with smaller ebuilds. If we break
91 down the eclass install function into smaller functions and optionally call
92 them from install, we've got ourself a nice tidy system.
94 >> If config
95 >> files aren't stored in /etc/webapps/${PN}, then we need to have a way of
96 >> generating an env.d/${PN} which contains a CONFIG_PROTECT line, otherwise
97 >> we're forcing sysadins to reconfigure the application at every upgrade.
98 >
99 > Yeah, but if each instance of the installed app has its own config files,
100 > then what's the relevance of /etc/webapps at all?
101 >
102 >> And as I mentioned before, there's no way for portage to handle
103 >> multiple-copy installs, so I'm not sure the best way to go about
104 >> achieving this goal.
105 >
106 > This is the problem that I think we should be solving - how to support
107 > the installation, configuration, and upgrading of multiple-copy installs.
109 There's nothing I can think of that will make this work, but see below for
110 some arguments...
112 >> Why should this be handled any different then the rest of apps handled by
113 >> portage?
114 >
115 > Because most of the rest of the apps handled by portage don't run in a
116 > virtual domain environment. Webapps really are a different beast.
118 They certainly are. :-)
120 > Here's an example. Imagine you're running your own hosting firm, and you
121 > have a non-trivial number of customers using the same webapp (say, phpBB
122 > for arguments sake). A new version of phpBB comes out. Some customers
123 > will ask for the upgrade, and some explicitly will ask you not to
124 > upgrade. So, in this situation, you need to have two copies of phpBB
125 > installed on the same box at the same time.
126 >
127 > Now let's look at what happens when you run 'emerge -u phpBB', with the
128 > appropriate ACCEPT_KEYWORDS of course. Portage goes and installs the new
129 > version of phpBB over the top of the old phpBB files. The old version of
130 > phpBB gets overwritten, yes? I don't see how AUTOCLEAN will prevent that
131 > from happening.
132 >
133 > The whole point of SLOTing apps (as I understand it) is to allow you to
134 > have multiple versions installed alongside each other. This is the
135 > mechanism that Portage offers us.
137 Here's the problem. First of all, SLOTing won't help that because it
138 assumes that the versions of the packages *and* the files you are
139 installing are _different_. I.e. db4 and db3 are SLOTted: they install
140 and respectively and thus can run simultaneously.
141 Now, wrt to the whole virtual server thing. Personally if I was running a
142 server with, as you say, a non-trivial number of virtual domains who have
143 different needs, I probably wouldn't use a package management system to
144 begin with, or truly virtualize everything and use something like
145 user-mode-linux in which case we're back to single-domain installs.
147 Going along with your example, how can you do an 'emerge -u phpBB' _for a
148 particular domain_? You're telling portage to maintain a package, and
149 upgrade parts of it randomly. I simply don't think portage will ever have
150 any way of handling multiple installs of a package in this manner. How
151 about we (Gentoo) just provide single domain/host installs and maybe
152 SLOTing different versions so they won't be overwritten on upgrades.
153 Beyhond that, we have to let the sysadmins know to cp -l the installed
154 files into their vhosts.
156 AFAIK, no other distro has support for virtual hosting because of this very
157 issue.
159 > That's up to you. If you're maintaining webapp ebuilds currently in
160 > portage, though, I'd urge you not to stop maintaining them just because
161 > you're waiting for a design solution via this GLEP.
163 Not in charge of anything else in portage. Though I'd like to help out
164 with Horde down the road (seeing as I'm on the horde dev team as well).
166 >> Right, but as we already agreed, not all apps need to have their files
167 >> owned by apache:apache. This should be configurable in the eclass.
168 >> Correct?
169 >
170 > Do we need a new user/group to own most of the files? And then we just
171 > make the files that need write-access owned by the webserver?
173 The most robust solution would be to create a new group (web?) and make all
174 the webserver users be a part of that group and make these directory
175 group-owned by said group. (Similar to the "mail" group for many
176 mail-related services)
178 > In his email in that thread you pointed me at, Robin was explicitly
179 > talking about /var being a read-only NFS mount at install time.
181 Ok, install-time aside, the installed, writeable directories cannot exist
182 on a readonly mount for day-to-day operations. Which takes me back to
183 wanting to support a single instance install of an app that an admin has to
184 copy in place if the default location is unacceptable.
186 >> So in any case, we have to pull the
187 >> apache-specific things out into a separate framework. Therefore things
188 >> like DocumentRoot can't even be considered. So a central location for
189 >> webapps must be once again taken into account.
190 >
191 > Yep. How does this sound as the design of the central layout? Let's
192 > agree a design, so that it can be added to the GLEP.
193 >
194 > * /usr/webapps/<app-name> as the main directory.
195 > * /usr/webapps/<app-name>/public_html/ for files served by the web server
196 > * /usr/webapps/<app-name>/cgi-bin/ for CGI-BIN files
197 > * /etc/webapps/<app-name>/ to hold the box-default config files
198 > * <app-name> is ${PN} for non-slotted packages
199 > * <app-name> is ${P} for slotted packages
201 I'd say <app-name> should just be ${PF} for both and not worry about what
202 is SLOTed and what is not -- it works itself out. Otherwise, this seems ok
203 to me and is easy to implement in the eclass. The only thing I would
204 change is the names public_html and cgi-bin. There may be no html and not
205 binary files in them (respectively). How's about 'public' and 'cgi'? (I
206 know, I know, nitpicking).
208 > a) you need a standard way of detecting which one is installed, and
210 Is the approach currently in the eclass unacceptable? (Check for the
211 existance of the directory/configfile)
213 > b) you need to honour the 'apache2' USE flag
215 Yup, see, higher than that. Ok there, stop!
217 --mk
219 --
220 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] [GLEP] Web Application Installation Stuart Herbert <stuart@g.o>