1 |
%% Paul de Vrieze <pauldv@g.o> writes: |
2 |
|
3 |
pdv> On Wednesday 24 March 2004 15:44, Paul Smith wrote: |
4 |
|
5 |
>> This isn't what I'm looking for, actually. I want to be able to |
6 |
>> build an install area with complete freedom from my "real" desktop. |
7 |
>> I want to build with completely different versions of all sorts of |
8 |
>> tools than the ones on my "real" system, without having to install |
9 |
>> them on my real system. |
10 |
|
11 |
pdv> This is exactly what chroot does. |
12 |
|
13 |
No, chroot does more than this. Chroot also (a) requires root |
14 |
privileges which I don't want to require, and (b) makes my real system |
15 |
unavailable to me. Right now we avoid a lot of the overhead of the |
16 |
"build" image by using "emerge inject" and relying on the natively |
17 |
installed tools like wget, python, perl, shell, native compiler, etc. etc. |
18 |
|
19 |
pdv> There is not really a way to avoid it either as there are many |
20 |
pdv> packages which rely on certain locations for certain files. In |
21 |
pdv> many cases it is possible to say those files exist in $ROOT but |
22 |
pdv> then it would not work if that root would become the real root. |
23 |
|
24 |
I'm not proposing that these alternate images should be _runnable_ as |
25 |
they are. I only want them to be _created_ that way. Before they are |
26 |
run they will be transferred to a target system and placed in "/". |
27 |
|
28 |
>> The other change I would like to see is a way to avoid the requirement |
29 |
>> for root access. These extra "images" I'm creating don't need to be |
30 |
>> installed as root, because I'm creating them in my own area. Not only |
31 |
>> that, but if there's a personal BUILDROOT then even _THAT_ doesn't |
32 |
>> require root access; it could also be an image I've built myself. |
33 |
|
34 |
pdv> We need root access for being able to give packages the right |
35 |
pdv> permissions. There might possibly be a way around it for creating |
36 |
pdv> binary packages, but that would probably require either some |
37 |
pdv> LD_PRELOAD magic (like sandbox) or custom kernel modules to |
38 |
pdv> record the owners of files. |
39 |
|
40 |
During the transfer of our images into the target we take care of |
41 |
the permission problems. But, we need end-users to be able to run these |
42 |
builds without requiring root privileges. |
43 |
|
44 |
It _would_ be cool, though, if we could track the chown operations that |
45 |
Portage would normally run, rather than actually doing them; say, in a |
46 |
file in the EDB. Then we could have a more generic way of setting the |
47 |
right permissions during the transfer operation. |
48 |
|
49 |
pdv> What you might try is user mode linux. What I understand from it |
50 |
pdv> it is possible to run it as a normal user. |
51 |
|
52 |
We are using UML to test our built images, but we don't want to use it |
53 |
for building the image itself. It's much slower for one thing, and our |
54 |
builds are already quite long enough, thanks! :). |
55 |
|
56 |
pdv> Some files in the apache package are owned by the apache |
57 |
pdv> user. There are many other packages with non-default owned |
58 |
pdv> files. That is essential for the security, and it is not possible |
59 |
pdv> without big changes to those ebuilds to actually use them when |
60 |
pdv> install is not performed as root. |
61 |
|
62 |
I understand these issues, but we have already solved them locally. |
63 |
First, we only use a very strict subset of packages and the ones we use |
64 |
do not, as a rule, have this problem. Second, as I mentioned above we |
65 |
manage the permissions change during the transfer of the image to the |
66 |
target. |
67 |
|
68 |
pdv> Before you do, try to build a full system with what you have. I |
69 |
pdv> think you will meet many of the above problems. |
70 |
|
71 |
We've been using our system to build complete setups since last |
72 |
summer... in fact they are deployed and running on our targets right now. |
73 |
|
74 |
I admit that it's possible our needs are too specialized for inclusion |
75 |
in the generic Portage. I'm willing to keep a locally modified version |
76 |
if that ends up being the case. However, all things being equal I'd |
77 |
prefer to see standard Portage be flexible enough for what we want |
78 |
(saves merge effort on our part--and who knows, some other folks might |
79 |
find it useful as well). |
80 |
|
81 |
So far I'm proposing two changes: |
82 |
|
83 |
1) Addition of BUILDROOT to replace "/" for the build system lookups. |
84 |
|
85 |
2) Ability to install without root privileges. |
86 |
|
87 |
|
88 |
It seems like the first might be more easily adopted by Portage than the |
89 |
second, which might require a little more fleshing out. |
90 |
|
91 |
Any interest in patches for either or both of these? |
92 |
|
93 |
-- |
94 |
------------------------------------------------------------------------------- |
95 |
Paul D. Smith <psmith@××××××××××××××.com> HASMAT--HA Software Mthds & Tools |
96 |
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist |
97 |
------------------------------------------------------------------------------- |
98 |
These are my opinions---Nortel Networks takes no responsibility for them. |
99 |
|
100 |
-- |
101 |
gentoo-dev@g.o mailing list |