1 |
On 10/02/2014 20:30, Kerin Millar wrote: |
2 |
> On 10/02/2014 16:05, Stroller wrote: |
3 |
>> Hello all, |
4 |
>> |
5 |
>> I'm a little bit rusty, but my recollection is that I should be able |
6 |
>> to perform `eix-sync` (or `emerge --sync`?) as a user to synchronise |
7 |
>> my local copy of the portage tree with Gentoo's master portage tree. |
8 |
>> |
9 |
>> User is in the portage group: |
10 |
>> |
11 |
>> $ whoami |
12 |
>> stroller |
13 |
>> $ groups stroller |
14 |
>> wheel audio video portage cron users |
15 |
>> $ |
16 |
>> |
17 |
>> Yet I get these permissons denied errors: |
18 |
>> |
19 |
>> $ eix-sync |
20 |
>> * Running emerge --sync |
21 |
>>>>> Synchronization of repository 'gentoo' located in '/usr/portage'... |
22 |
>>>>> Starting rsync with rsync://91.186.30.235/gentoo-portage... |
23 |
>>>>> Checking server timestamp … |
24 |
>> … |
25 |
>> receiving incremental file list |
26 |
>> rsync: delete_file: |
27 |
>> unlink(app-accessibility/caribou/caribou-0.4.12.ebuild) failed: |
28 |
>> Permission denied (13) |
29 |
>> rsync: delete_file: |
30 |
>> unlink(app-accessibility/emacspeak/files/emacspeak-33.0-respect-ldflags.patch) |
31 |
>> failed: Permission denied (13) |
32 |
>> rsync: delete_file: |
33 |
>> unlink(app-accessibility/emacspeak/files/emacspeak-33.0-greader-garbage.patch) |
34 |
>> failed: Permission denied (13) |
35 |
>> |
36 |
>> (full output attached) |
37 |
>> |
38 |
>> |
39 |
>> Googling the problem I see a bunch of Gentoo Forums posts talking |
40 |
>> about changing at random the permissions of /var/tmp/ or |
41 |
>> /var/tmp/portage/, but no rationale is given, and I don't think this |
42 |
>> is the cause: |
43 |
>> |
44 |
>> $ emerge --info | grep -i tmpdir |
45 |
>> PORTAGE_TMPDIR="/var/tmp" |
46 |
>> $ ls -ld /var/tmp/ |
47 |
>> drwxrwxrwt 3 root root 4096 Feb 5 13:47 /var/tmp/ |
48 |
>> $ ls -ld /var/tmp/portage/ |
49 |
>> drwxrwxr-x 5 portage portage 4096 Feb 5 12:32 /var/tmp/portage/ |
50 |
>> $ |
51 |
>> |
52 |
>> |
53 |
>> More likely seems to be the permissions of /usr/portage/: |
54 |
>> |
55 |
>> $ ls -ld /usr/portage/ |
56 |
>> drwxr-xr-x 167 portage portage 4096 Jan 5 02:31 /usr/portage/ |
57 |
>> $ ls -ld /usr/portage/app-accessibility/caribou/caribou*.ebuild |
58 |
>> -rw-r--r-- 1 portage portage 2432 Aug 25 23:11 |
59 |
>> /usr/portage/app-accessibility/caribou/caribou-0.4.12.ebuild |
60 |
>> -rw-r--r-- 1 portage portage 2431 Dec 8 18:01 |
61 |
>> /usr/portage/app-accessibility/caribou/caribou-0.4.13.ebuild |
62 |
>> $ |
63 |
>> |
64 |
>> This would seem to allow portage itself to synchronise the Portage |
65 |
>> tree, but not members of the portage group. |
66 |
>> |
67 |
>> |
68 |
>> I am able to run `emerge --sync` as root, but it doesn't solve the |
69 |
>> solve the problem - next time I run `eix-sync` as user, I'm |
70 |
>> permissions denied, again. |
71 |
>> |
72 |
>> Shouldn't a sync reset the permissions of the portage tree to be correct? |
73 |
>> |
74 |
>> |
75 |
>> `emerge --info | grep -i feature` shows that FEATURES="userfetch |
76 |
>> userpriv usersandbox usersync" (and some others - see attached) are set. |
77 |
>> |
78 |
>> I can reproduce this on a second AMD64 machine, both are running |
79 |
>> portage-2.2.7. |
80 |
>> |
81 |
>> Thanks in advance for any help, advice or suggestions you can offer, |
82 |
> |
83 |
> This should work:- |
84 |
> |
85 |
> PORTAGE_RSYNC_EXTRA_OPTS="--chmod=g+w" |
86 |
> |
87 |
|
88 |
Please excuse the reply-to-self but this issue piqued my interest and I |
89 |
think that I now have a better answer. |
90 |
|
91 |
1) chown -R portage:portage "$(portageq envvar PORTDIR)" |
92 |
2) find "$(portageq envvar PORTDIR)" -type f -exec chmod 0664 {} + |
93 |
3) find "$(portageq envvar PORTDIR)" -type d -exec chmod 2775 {} + |
94 |
4) Add to make.conf: PORTAGE_RSYNC_EXTRA_OPTS="--no-p --chmod=g+w" |
95 |
5) Sync as yourself thereafter (as root should work equally well!) |
96 |
|
97 |
The reason for using --no-p is to prevent rsync from spewing errors |
98 |
about not being able to set the file modes when you sync as a regular |
99 |
user. These errors don't necessarily indicate that a file cannot be |
100 |
written - merely that the mode couldn't be set. |
101 |
|
102 |
Such errors would occur because, though you are in the portage group, |
103 |
you are not necessarily the owner of the files that rsync is in the |
104 |
course of modifying. However, as long as the g+w bit is set for all |
105 |
newly created files/directories, I would posit that it doesn't actually |
106 |
matter. Instead, you can simply avoid synchronizing the permissions with |
107 |
the remote. |
108 |
|
109 |
Finally, having the setgid bit set on directories ensures that files |
110 |
written out by your user beneath PORTDIR will always inherit the portage |
111 |
group rather than whatever your primary group happens to be. |
112 |
|
113 |
I am still in the course of testing this out but I am fairly certain |
114 |
that it will work. |
115 |
|
116 |
--Kerin |