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 17:11:41
Message-Id: 42620000.1060017099@valkyrie.lsit.ucsb.edu
1 Good morning!
2
3 Quoting Stuart Herbert <stuart@g.o>:
4
5 > Apache supports virtual hosting already. Tools such as phpBB and
6 > tikiwiki and phpMyAdmin (to give but three examples) don't need explicit
7 > virtual host support, because Apache handles that. To run a copy of
8 > phpBB under two different domains hosted on the same box, you install
9 > two copies of phpBB - or at least simulate that situation using symlinks
10 > or whatever.
11
12 See, I don't think that running two (or more) copies of an application is
13 supporting virtual hosts. Upgrading all the files is a pain. Why not have
14 one installation of the core files and multiple installations of the config
15 files? This is, of course, very application specific -- most of them will
16 still need database upgrades, but that has to be done by the sysadmin.
17
18 > Scary as I find it, one reason why many of my clients run Debian rather
19 > than Gentoo on their production hardware is because they do that from a
20 > cron script, and trust the results. Personally, I've always introduced
21 > staging platforms in environments where I've been wearing the Release
22 > Manager hat.
23
24 How do they handle db updates? How do they handle config file updates?
25
26 > Possibly. But I really wanted to clear out some outstanding bugs from
27 > Bugzilla, and adding the eclass made it easy to do.
28
29 Fair enough.
30
31 > 1) Your eclass doesn't correctly (as I understand correct usage to be!)
32 > support the apache2 USE flag. Easy enough to do - see my webapp-apache
33 > eclass for an example.
34
35 Why base it on the flag? If the webserver is installed and is supported,
36 configure for it.
37
38 > 2) Your eclass doesn't specify the permissions that the source files
39 > should be installed under. Again, easy enough to fix.
40
41 This is very straightforward to add.
42
43 > 3) Your eclass doesn't provide support for running multiple copies of the
44 > same app on the same machine. This is a showstopper.
45
46 This whole thing needs a separate discussion. There's no portage support
47 for dealing with more than one installation of the same version of the same
48 package.
49
50 > 4) Your eclass requires the admin to stop and start Apache as part of the
51 > install. This is a showstopper. Not every site will want to stop and
52 > start their web server just because they've installed a new app.
53 > Imagine a site hosting hundreds of domains, and having to take them
54 > *all* offline at the same time just because phpBB's been upgraded (for
55 > example!). Robin's idea of creating .htaccess files under the document
56 > root deals with this much more managably - although I think we're gonna
57 > end up using symlinks, as that'll make it easy to support multiple web
58 > servers.
59
60 ..htaccess files only work in already web-accessable directories (in your
61 case, DocumentRoot). If we're putting applications in /usr/share/webapps,
62 the webserver has no idea to look there. Which is what the Alias directive
63 does in all the .conf files that are generated. However, Alias is not
64 allowed in .htaccess AFAIK.
65
66 http://httpd.apache.org/docs-2.0/mod/mod_alias.html#alias
67
68 Besides that, the server doesn't have to be restarted -- just HUPed.
69
70 > 5) I'm against users having to run 'ebuild /var/.../something.ebuild'
71 > after installation to then complete the install. If you're emerging
72 > enough packages, it's easy to miss the notification that you need to do
73 > this. It's personal preference, I guess, but I've been caught out by
74 > this in the past.
75
76 Ok, if we can achieve the same thing without the post-install intervention,
77 all for the better.
78
79 > 6) I *like* the idea that check_php() is in this
80 > eclass, because that check is specific to mod_php under Apache. I'm
81 > gonna steal that and add it to my webapp-apache eclass ;-)
82
83 Steal away! Keep in mind it is not completely accurate if the per-package
84 USE flags goes into portage (http://bugs.gentoo.org/show_bug.cgi?id=13616).
85 Things in PUSE will also have to be taken into account. But this is a
86 completely different matter and will be easy to integrate.
87
88 > 7) Your variable names are not generic enough for my liking ;-)
89 > AWEB_CFG, for example, might be better off being WEBAPP_CFG.
90
91 Hey! I originally had them as WEBAPP_* but was told to change the eclass
92 to apache-webapp to distinguish from other servers so I wanted the
93 variables to reflect the name of the eclass. I'm as flexible on this as
94 playdoh. :-)
95
96 > 8) Instead of trying to supply an all-encompasing
97 > apache-webapp_src_install(), relying as it does on defining global
98 > variables, I'd have supplied a number of individual functions to do each
99 > bit. Say, a webapp-install-appconfig, webapp-install-serverconfig each
100 > taking parameters (this is off the top of my head here ;-) This is a
101 > personal preference thing.
102
103 Thats just more to call from the ebuild. My goal was to have very small
104 ebuilds -- just declare a few variables and inherit the eclass.
105
106 > 9) If I'm not mistaken, your eclass does nothing to ensure that the
107 > webapp can find the configuration files you've moved into
108 > /etc/webapps/$PN/. Personally, I'm coming to the conclusion that
109 > /etc/webapps/$PN/ isn't a good idea, because again it doesn't support
110 > the idea of running multiple copies of the same app on the same machine.
111
112 I'd say we should be shooting for an easy upgrade path first. If config
113 files aren't stored in /etc/webapps/${PN}, then we need to have a way of
114 generating an env.d/${PN} which contains a CONFIG_PROTECT line, otherwise
115 we're forcing sysadins to reconfigure the application at every upgrade.
116 And as I mentioned before, there's no way for portage to handle
117 multiple-copy installs, so I'm not sure the best way to go about achieving
118 this goal.
119
120 > 10) I'm coming to the conclusion that 'emerge -u <webapp>' shouldn't
121 > overwrite the older version, but should always install alongside, in a
122 > different slot, so that sites can easily run different versions of apps
123 > as required. Perhaps this should be configurable somehow? Your eclass
124 > doesn't make this possible.
125
126 Why should this be handled any different then the rest of apps handled by
127 portage? If a sysadmin doesn't want older versions removed, just add
128 AUTOCLEAN=no to make.conf. Granted, the current eclass doesn't use the
129 full ${PF} in the target directory, but that is easily changed.
130
131 > I'm not saying that my eclass is better. My eclass isn't trying to
132 > address this GLEP - it's just trying to make maintenance easier for now.
133 > The show must go on. Especially as this GLEP isn't even showing up on
134 > the GLEP list yet.
135
136 Ok. Hopefully we can get this thing hashed out and out the door so things
137 can start getting into shape soon.
138
139 >> Double Ugh!
140 >
141 > Lots of laughter. I'm gonna copyright that phrase, I think ;-)
142
143 I have my moments. ;-)
144
145 > 1) Apache1/Apache2 conundrum
146 >
147 > My eclass uses the detection technique adopted for mod_php, and no-one
148 > has complained about that. If this eclass is invalid, then so's the
149 > ebuild for mod_php. And I don't think it is.
150
151 Ok, this one is a keeper.
152
153 > 2) Support for multiple DocumentRoot configurations, and also
154 > 3) Binary packages installing on machines with different DocumentRoot
155 > values
156 >
157 > Until the GLEP is firmed up and approved, we don't have an agreed
158 > solution to implement.
159
160 Ah! Ok, so before we have this issues ironed out, the current status-quo
161 will just be maintained. Fair enough.
162
163 > Please excuse me, but I don't want to put support for existing ebuilds on
164 > hold while we debate the GLEP. I believe that we *have* to continue
165 > support until we're ready and able to switch. Stopping maintenance
166 > activities is *not* an option.
167
168 Since I'm the laziest person I know, I didn't want to do the work twice.
169 I'll just hold off on introducing more ebuilds which will have to be
170 converted later. :-)
171
172 > 4) Which user/group to use
173 >
174 > My class uses Robin's suggestion, and assumes that Apache is running with
175 > the default settings of apache.apache.
176
177 Right, but as we already agreed, not all apps need to have their files
178 owned by apache:apache. This should be configurable in the eclass.
179 Correct?
180
181 > 5) DocumentRoot pointing to a read-only mount
182 >
183 > As far as I'm concerned, that's like trying to do 'make bzlilo' with
184 > /boot not mounted, or run an 'emerge' with /usr mounted read-only. It's
185 > the sysadmin's job to make sure that any necessary filesystems are
186 > mounted read/write before an installation is attempted. This is not a
187 > problem unique to web applications.
188
189 The issue is not whether DocumentRoot is a read-only mount during the
190 install, but during the day-to-day operations. Running 'emerge' with /usr
191 mounted read-only is not the same as having apache running a webapp that
192 needs to write to /usr -- one is done seldomly, the other is all the time.
193
194 > 6) "it's weak"
195 >
196 > That's not an argument, it's an opinion ;-) Anyway, I've taken 5-10
197 > lines of broken and incorrectly duplicated code from a number of
198 > ebuilds, and moved them all into one place where they can be re-used and
199 > maintained for now. Reduced defects is a strong argument, not a weak
200 > one.
201
202 I never made the "weak" argument -- I don't believe in it myself. Things
203 need to be justified a bit better than that, so I'm completely with you on
204 this one.
205
206 > Then I'd argue that the GLEP is incomplete in its scope, and needs
207 > expanding. Unless you think that we can create the 'web-xxx' categories
208 > without a GLEP? If so, then fair enough ;-)
209 >
210 > Actually, I'd like to see a redrafting of the GLEP, with a clearly
211 > defined list of requirements for supporting webapps. We're debating
212 > implementation issues without a clear list of requirements to address.
213 > This is not the right way to go about it ;-)
214
215 Ok, agreed. Troy, is there any chance for another draft with some of these
216 things incorporated? (Thanks a bezillion, btw, for putting up with me) :-)
217
218 > It *was* fix-a-bug weekend ;-)
219
220 And a successful one at that from what I saw in my emerge --sync this
221 morning. :-) Thanks!
222
223 > I am going to be adding a webapp or two that use the new eclass, but the
224 > situation's no different to before the eclass existed. The code in the
225 > eclass would have had to have been duplicated in the new ebuilds.
226
227 All you! :-)
228
229 > If we *don't* do this, I reckon that the bugs about webapps running under
230 > Apache'll get addressed, and many of the other bugs won't - because it's
231 > too much effort.
232 >
233 > I agree that most people will just the webapps under Apache, and never
234 > care about other web servers. But either we just support webapps under
235 > Apache, or we do it properly, I'd argue. And I reckon that doing it
236 > properly is actually very easy to do.
237
238 If you say it is very easy to do, I'm on board. I can't personally speak
239 for other webservers, so I'll leave the decision of whether/how to support
240 others to those with the experience. So in any case, we have to pull the
241 apache-specific things out into a separate framework. Therefore things
242 like DocumentRoot can't even be considered. So a central location for
243 webapps must be once again taken into account. And from here stems the
244 problem of how to tell the webserver where to look for a specific
245 applications. The .htaccess approach isn't viable. For apache the .conf
246 system works, but yes, it requires the server to be HUPed after an upgrade
247 to an install of an application (not an upgrade -- once the app is
248 installed and running, upgrading doesn't require the server to be touched).
249
250 > See above. My eclass isn't attempting to solve the GLEP. It's there to
251 > help with existing packages for now, until the GLEP moves forward.
252
253 ok, I didn't realize that it wasn't a permanent solution. All is ok.
254
255 >> How is mod_php related to the way applications are installed?
256 >
257 > Erm, how about the whole 'do I use Apache 1 or Apache 2' conumdrum? See
258 > the mod_php ebuild for details.
259
260 Whichever is installed gets configured. Either or both get touched,
261 depending on what is detected. It is up to the sysadmin to start one or
262 the either automatically with rc-update. I don't see a problem if both are
263 configured (if detected), but only one is running.
264
265 --mk
266
267 --
268 gentoo-dev@g.o mailing list

Replies

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