1 |
Quoting Stuart Herbert <stuart@g.o>: |
2 |
|
3 |
> Here's an example. Imagine hosting (oh, I don't know) www.iammax.com and |
4 |
> www.maxisgreat.com on the same physical box. Document roots for each are |
5 |
> /var/www/<host>/public_html/ for arguments sake. |
6 |
|
7 |
Love those names. I wonder if they're taken? ;-) |
8 |
|
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? |
16 |
|
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. |
19 |
|
20 |
> If I've understood your eclass correctly, this is what it tries to do, |
21 |
> yes? |
22 |
|
23 |
Yes. |
24 |
|
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? |
37 |
|
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. |
44 |
|
45 |
Ok, I'll pool some replies below... |
46 |
|
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. |
53 |
|
54 |
Ok, this is debatable, but I'm willing to change the eclass to take |
55 |
-apache2 into effect. |
56 |
|
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. |
68 |
|
69 |
Keep reading, going to answer this below. :-) |
70 |
|
71 |
>> Keep in mind it is not completely accurate if the per-package |
72 |
>> USE flags goes into portage |
73 |
>> (http://bugs.gentoo.org/show_bug.cgi?id=13616). 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 ;-) |
80 |
|
81 |
Cool! |
82 |
|
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. |
89 |
|
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. |
93 |
|
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. |
108 |
|
109 |
There's nothing I can think of that will make this work, but see below for |
110 |
some arguments... |
111 |
|
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. |
117 |
|
118 |
They certainly are. :-) |
119 |
|
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. |
136 |
|
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 |
libdb-4.so and libdb-3.so 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. |
146 |
|
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. |
155 |
|
156 |
AFAIK, no other distro has support for virtual hosting because of this very |
157 |
issue. |
158 |
|
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. |
162 |
|
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). |
165 |
|
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? |
172 |
|
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) |
177 |
|
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. |
180 |
|
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. |
185 |
|
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 |
200 |
|
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). |
207 |
|
208 |
> a) you need a standard way of detecting which one is installed, and |
209 |
|
210 |
Is the approach currently in the eclass unacceptable? (Check for the |
211 |
existance of the directory/configfile) |
212 |
|
213 |
> b) you need to honour the 'apache2' USE flag |
214 |
|
215 |
Yup, see above...no higher...no, higher than that. Ok there, stop! |
216 |
|
217 |
--mk |
218 |
|
219 |
-- |
220 |
gentoo-dev@g.o mailing list |