1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Chris Lieb wrote: |
5 |
> I have read the guide on gentoo-wiki about setting up portage to work |
6 |
> over NFS[0] and have it mostly working. I have two issues that I would |
7 |
> like to work out: |
8 |
> |
9 |
> 1) I use sync-eix to update portage and my overlays (via layman). I |
10 |
> want the client to still be able to run sync-eix, but have it only run |
11 |
> `emerge --metadata` (no `emerge --sync` or `layman --sync ALL`). What |
12 |
> do I need to change in the eix-sync.conf? (Man, that's a long man page :) ) |
13 |
> |
14 |
> Better yet, since my overlays are all in the exported NFS filesystem |
15 |
> (hence, the eix database would be the same across all clients), is it |
16 |
> possible to export my eix cache by hardlinking it into the NFS share? |
17 |
> If so, how do I make the client's eix use this database instead of the |
18 |
> one at /var/cache/eix? |
19 |
|
20 |
I got eix working by hardlinking the cache on the server into the NFS |
21 |
share and setting EIX_CACHEFILE in /etc/eixrc on the client to point to |
22 |
the mounted NFS share. All tests show that eix on both the client and |
23 |
server works fine after changing this. |
24 |
|
25 |
> 2) I use the buildpkg feature on both the server and the client since |
26 |
> the client can usually use the packages for its own installations |
27 |
> (getbinpkg). However, sometimes I require different use flags for the |
28 |
> client, but I still want to keep the package locally so I can restore it |
29 |
> later if I need to. I have the NFS share mounted ro to keep the client |
30 |
> from overwriting what is on the server, so I am guessing that portage |
31 |
> will throw some kind of error when it tries to save the package to disk. |
32 |
> |
33 |
> I was thinking of getting around this by using some kind of union mount. |
34 |
> However, I don't understand how union mounts work or if they can be |
35 |
> used for my situation. What I would like is to have some directory, |
36 |
> lets say /var/lib/portage/packages, that I union mount on top of the |
37 |
> exported NFS share, at /mnt/nfs_portage/packages. I noticed in the |
38 |
> Portage w/ SquashFS/aufs howto[1], they used aufs to create a rw layer |
39 |
> on top of a ro SquashFS. This sounds kind of what I want, except it |
40 |
> appears that aufs is memory-backed instead of disk-backed. Is this so? |
41 |
> The clients are all strapped for memory, so a memory-backed fs won't be |
42 |
> feasible. |
43 |
> |
44 |
> [0] http://en.gentoo-wiki.com/wiki/Sharing_Portage_over_NFS |
45 |
> [1] http://en.gentoo-wiki.com/wiki/Squashed_Portage_Tree |
46 |
|
47 |
After looking into aufs a little more and trying it, I discovered that, |
48 |
in it's current state in the sunrise overlay, cannot fulfill my |
49 |
requirements. The most recent version of aufs does not have support for |
50 |
mounting NFS filesystems (there might be a patch out there for it, but I |
51 |
don't know how to configure this in an ebuild), and the last version of |
52 |
aufs that supports NFS mounts doesn't work with newer kernels. |
53 |
|
54 |
I don't want to do UnionFS since that requires me to patch the kernel, |
55 |
which is more work than I have the time for. |
56 |
|
57 |
Since I don't see any other options for stackable filesystems, I think |
58 |
I'll just set the clients to not produce binpackages and wait for |
59 |
UnionFS to get into the kernel or the Gentoo patchset. |
60 |
|
61 |
Chris Lieb |
62 |
-----BEGIN PGP SIGNATURE----- |
63 |
Version: GnuPG v1.4.9 (MingW32) |
64 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
65 |
|
66 |
iQEcBAEBAgAGBQJJjGwWAAoJEJWxx7fgsD+CxlcIAJwnlPvibmcdMGW/eNyaekYe |
67 |
U1aGhsi09DoMU43aicKXNQ8p/rC2qwqXfocaxSXiBc4rrkrNpFhfTzPCDjwlhOSb |
68 |
6fLtBpY7xo3m8CgP+g/Sv2tLFs4T/Gx4EqZ3TxfJh/xnvgUtFdlry+1BDqLPMsnl |
69 |
XMJ5zetuJYZiOujoL4ZG8dS4Od0rVkomKegV0kP5pdiUbcdUN3tNMGMpa4pLvuIA |
70 |
5DJtUfZk3Iyi5CyEqB/zNlUCmNS9z2hXHNw9y3pOVDQoeSCiufo+fGE8pUr6wXr9 |
71 |
sOy6EmmPvO5NQN/Z244smeWCgP8wNG6YSWEZik3lLU3Edw23VdeWA9KhOgNXAiQ= |
72 |
=ypMH |
73 |
-----END PGP SIGNATURE----- |