1 |
'lo Max, |
2 |
|
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. |
14 |
|
15 |
mod_alias provides aliases for URLs. Why would you need to know what DocRoot |
16 |
is? |
17 |
|
18 |
> > If I've understood your eclass correctly, this is what it tries to do, |
19 |
> > yes? |
20 |
> |
21 |
> Yes. |
22 |
|
23 |
Ah good. |
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 |
They would be stored under the virtual DocRoot, for example (using the paths |
39 |
for my example) in /var/www/www.iammax.com/public_html/phpbb/config.php. |
40 |
|
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. |
45 |
|
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. |
52 |
|
53 |
[OT, but interesting] How is this debatable? |
54 |
|
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. |
58 |
|
59 |
Good idea - I'll sign up to that. |
60 |
|
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 |
> libdb-4.so and libdb-3.so respectively and thus can run simultaneously. |
65 |
|
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? |
70 |
|
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. |
76 |
|
77 |
UML is one solution, but the overhead is not insignificant. |
78 |
|
79 |
If the package management system provided a viable solution, don't you think |
80 |
that people would use it? |
81 |
|
82 |
> Going along with your example, how can you do an 'emerge -u phpBB' _for a |
83 |
> particular domain_? |
84 |
|
85 |
Like this. |
86 |
|
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. |
91 |
|
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. |
95 |
|
96 |
What's wrong with this as a solution? |
97 |
|
98 |
> You're telling portage to maintain a package, and |
99 |
> upgrade parts of it randomly. |
100 |
|
101 |
Nope. I'm telling Portage to maintain the master copy of a package, and to |
102 |
upgrade that master copy only. |
103 |
|
104 |
> I simply don't think portage will ever have |
105 |
> any way of handling multiple installs of a package in this manner. |
106 |
|
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. |
110 |
|
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. |
116 |
|
117 |
Because we can do better? |
118 |
|
119 |
> AFAIK, no other distro has support for virtual hosting because of this very |
120 |
> issue. |
121 |
|
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. |
126 |
|
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) |
131 |
|
132 |
Why is that robust? |
133 |
|
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. |
137 |
|
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. |
140 |
|
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. |
150 |
|
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. |
154 |
|
155 |
> Otherwise, this seems ok to me and is easy to implement in the eclass. |
156 |
|
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 ;-) |
159 |
|
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). |
164 |
|
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. |
168 |
|
169 |
> Is the approach currently in the eclass unacceptable? (Check for the |
170 |
> existance of the directory/configfile) |
171 |
|
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!) |
174 |
|
175 |
> > b) you need to honour the 'apache2' USE flag |
176 |
> |
177 |
> Yup, see above...no higher...no, higher than that. Ok there, stop! |
178 |
|
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. |
183 |
|
184 |
Take care, |
185 |
Stu |
186 |
-- |
187 |
Stuart Herbert stuart@g.o |
188 |
Gentoo Developer http://www.gentoo.org/ |
189 |
Beta packages for download http://dev.gentoo.org/~stuart/packages/ |
190 |
|
191 |
GnuGP key id# F9AFC57C available from http://pgp.mit.edu |
192 |
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C |
193 |
-- |