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 |