1 |
Uh oh. I think we are talking about the same thing. It seems to me that |
2 |
we're going towards the same ends but by a different means. I think we're |
3 |
getting really close. I know you're dying of anticipation so ... read on! |
4 |
|
5 |
Quoting Stuart Herbert <stuart@g.o>: |
6 |
|
7 |
>> If not mod_alias, then symlink to the DocRoot, but then we're back to not |
8 |
>> knowing where the user configured his/her/virtualhosts's DocRoot. |
9 |
> |
10 |
> mod_alias provides aliases for URLs. Why would you need to know what |
11 |
> DocRoot is? |
12 |
|
13 |
Lets skip this...see below. |
14 |
|
15 |
>> Local config files? Where would these be stored? How are these handled |
16 |
>> for virtual hosts? |
17 |
> |
18 |
> They would be stored under the virtual DocRoot, for example (using the |
19 |
> paths for my example) in |
20 |
> /var/www/www.iammax.com/public_html/phpbb/config.php. |
21 |
> |
22 |
> Putting the config file into the virtual DocRoot is where Robin's tools |
23 |
> would come in (Robin, are you following this thread at all?). We could |
24 |
> put a master copy - a skeleton if you like - in |
25 |
> /etc/webapps/<app-name>/. It's the skeleton that gets updated by |
26 |
> portage. |
27 |
|
28 |
Ok, I'm following now. |
29 |
|
30 |
>> Ok, this is debatable, but I'm willing to change the eclass to take |
31 |
>> -apache2 into effect. |
32 |
> |
33 |
> [OT, but interesting] How is this debatable? |
34 |
|
35 |
Seems to me that if the server is installed, it should be taken into |
36 |
account. But that's entirely personal opinion. USE flags are more correct |
37 |
for the general public. |
38 |
|
39 |
>> We can still achieve flexibility along with smaller ebuilds. If we break |
40 |
>> down the eclass install function into smaller functions and optionally |
41 |
>> call them from install, we've got ourself a nice tidy system. |
42 |
> |
43 |
> Good idea - I'll sign up to that. |
44 |
|
45 |
Right-o. I'll make a note to do this in the eclass. |
46 |
|
47 |
> I must be missing something. Why won't SLOTing help? The behaviour |
48 |
> you've described is *exactly* the behaviour that I want. Why can't |
49 |
> phpBB-2.0.4 and phpBB-2.0.5 run at the same time on the same box, but |
50 |
> under different virtual domains? |
51 |
|
52 |
I think I missed something. I thought you wanted to use SLOTs for somehow |
53 |
maintaining the same version of the same package. I think we are on the |
54 |
same page, now. In the eclass we can go ahead and do something similar to |
55 |
the kernel ebuilds -- make SLOT="${PV}" or even SLOT="${PV}-${PR}". |
56 |
|
57 |
> If the package management system provided a viable solution, don't you |
58 |
> think that people would use it? |
59 |
|
60 |
Certainly. |
61 |
|
62 |
>> Going along with your example, how can you do an 'emerge -u phpBB' _for a |
63 |
>> particular domain_? |
64 |
> |
65 |
> Like this. |
66 |
> |
67 |
> a) emerge -u 'webapp' installs the master copy of 'webapp' in |
68 |
> /usr/webapps. If the webapp is SLOT'ed, none of the domains are |
69 |
> upgraded at this point. b) Then, run 'webapp-config --upgrade <webapp> |
70 |
> /path/to/domain/directories' to upgrade the specific domain. |
71 |
|
72 |
This is where I misunderstood. I thought you wanted portage to take care |
73 |
of everything -- i.e. emerge -u 'webapp' would somehow magically upgrade |
74 |
all the copies. This is actually a more elegant version of the cp -a thing |
75 |
that I mentioned in the previous post. I think we have our answer. Next |
76 |
step would be to write up the necessary functionality for the webapp-config |
77 |
utility. |
78 |
|
79 |
> Two stage process. Finally, once all domains are upgraded, you can |
80 |
> simply do an 'emerge -C webapp-old-version' to remove the old SLOT'ed |
81 |
> version that is no longer required. |
82 |
> |
83 |
> What's wrong with this as a solution? |
84 |
|
85 |
Nothing. It just took 16 posts to get it through my dense skull. :-) |
86 |
|
87 |
> Nope. I'm telling Portage to maintain the master copy of a package, and |
88 |
> to upgrade that master copy only. |
89 |
|
90 |
Ding Ding Ding! |
91 |
|
92 |
>> I simply don't think portage will ever have |
93 |
>> any way of handling multiple installs of a package in this manner. |
94 |
> |
95 |
> Why does Portage have to do *everything*? We use portage to get the app |
96 |
> + dependencies onto the box, and we use additional tools to manage the |
97 |
> virtual domain upgrades. |
98 |
|
99 |
It doesn't and can't. The one instance/configure is definitely the way to |
100 |
go. |
101 |
|
102 |
>> AFAIK, no other distro has support for virtual hosting because of this |
103 |
>> very issue. |
104 |
> |
105 |
> I have no idea whether other distros support virtual hosting, and if they |
106 |
> don't, why they don't. If you have any threads I can read on this, |
107 |
> please send them my way. Otherwise, your statement is an assumption, |
108 |
> and assumptions are the mother of all screw-ups. |
109 |
|
110 |
Well then, lets the the first. :-) |
111 |
|
112 |
>> The most robust solution would be to create a new group (web?) and make |
113 |
>> all the webserver users be a part of that group and make these directory |
114 |
>> group-owned by said group. (Similar to the "mail" group for many |
115 |
>> mail-related services) |
116 |
> |
117 |
> Why is that robust? |
118 |
|
119 |
Because we have the one group that we know all webservers are going to run |
120 |
as (yes yes, the sysadmin can change what group the server runs as, and if |
121 |
he/she does, then he/she can also change the ownership of the directory). |
122 |
If we assume that all webservers will run as the same group, then |
123 |
configuring those apps which need a writeable directory becomes easy indeed. |
124 |
|
125 |
>> Which takes me back to |
126 |
>> wanting to support a single instance install of an app that an admin has |
127 |
>> to copy in place if the default location is unacceptable. |
128 |
> |
129 |
> It's one solution, sure. I think we can do better, and I'm willing to |
130 |
> write the code to do it if necessary. |
131 |
|
132 |
Yup. We were talking about the same thing. Just a different way of doing |
133 |
the post-install config. I'd like to help with the design/code of the |
134 |
webapp-config utility. |
135 |
|
136 |
>> I'd say <app-name> should just be ${PF} for both and not worry about what |
137 |
>> is SLOTed and what is not -- it works itself out. |
138 |
> |
139 |
> (thinks about this) I'd want to test it to be sure, but I think ${PF} |
140 |
> would work out okay. Depends whether having the -rX part of the package |
141 |
> name is really important or not. |
142 |
|
143 |
I'd say it is important because -rX releases may have added |
144 |
functionality/features that some may not want, etc. |
145 |
|
146 |
>> Otherwise, this seems ok to me and is easy to implement in the eclass. |
147 |
> |
148 |
> Good-o. So the two of us (ominously quiet in here ;-) are in agreement |
149 |
> then? Oh, thought it was too good to be true ;-) |
150 |
|
151 |
It could happen! |
152 |
|
153 |
> Shrugs. I just picked 'public_html' because it's a recognised convention |
154 |
> (although not the only one I'm sure). 'public' is too generic for my |
155 |
> liking. 'cgi-bin' *is* a recognised convention, and one we shouldn't |
156 |
> break. |
157 |
|
158 |
I thought those were apache conventions. It really doesn't matter one way |
159 |
or another. :-) |
160 |
|
161 |
>> Is the approach currently in the eclass unacceptable? (Check for the |
162 |
>> existence of the directory/configfile) |
163 |
> |
164 |
> I think so. See how I determine which version of apache to use in |
165 |
> webapp-apache.eclass (as stolen/morphed from Robin's mod_php ebuild!) |
166 |
|
167 |
checking...still checking...done! It could probably be simplified to |
168 |
something like the following: (I'm just the nitpick mongrel, aren't I?) |
169 |
|
170 |
if [ "`has_version '=net-www/apache-2*'`" -a "`use apache2`" ] ; then |
171 |
APACHEVER=2 |
172 |
elif [ "`has_version '=net-www/apache-1*'`" ] ; then |
173 |
APACHEVER=1 |
174 |
else |
175 |
# no apache version detected |
176 |
return 1 |
177 |
fi |
178 |
|
179 |
> Lol. For now, just make your eclass rely on mine, seeing as mine's |
180 |
> already in Portage ;-) and re-use what's already coded. No offence, but |
181 |
> because of the reasons in one of my earlier emails, I don't think your |
182 |
> eclass should go into Portage until the outcome of this GLEP is |
183 |
> determined. |
184 |
|
185 |
No offense taken of course. Lets just evolve yours overtime to do |
186 |
everything that's needed because, as you say, it is already in portage. :-) |
187 |
|
188 |
--mk |
189 |
|
190 |
-- |
191 |
gentoo-dev@g.o mailing list |