1 |
All -- |
2 |
|
3 |
Curious what various suggestions you can offer for the following problem: |
4 |
|
5 |
I have a large cluster of machines that I will be building using Gentoo. I |
6 |
will be using partimage for the initial installation (build one gold server |
7 |
and clone the rest from it) and cfengine for ongoing configuration |
8 |
management of things like /etc/ files, etc. |
9 |
|
10 |
The one area I'm stuck on is how to manage package upgrades. I don't want |
11 |
to have to run 'emerge -u world' on each machine. In fact, I don't want to |
12 |
have to compile things on each machine. Ideally, I want to only have to |
13 |
upgrade one machine and have those changes propogate out automatically to |
14 |
the other machines from there. (All hardware will be identical) |
15 |
|
16 |
I've looked at rdist, but I've never used that before, so I'm not sure how |
17 |
well it would work. |
18 |
|
19 |
Another suggestion was maintaining a custom portage tree and running a |
20 |
nightly 'emerge -u --usepkg world' on all the boxes. Then, by making a |
21 |
change to the portage tree (which the other servers would sync from), it |
22 |
would propogate out to the servers automatically the next time the cron job |
23 |
ran. This is an option and probably the best one I have at this point, but |
24 |
it seems somewhat fragile -- one slip-up in the portage tree and I'm hosed. |
25 |
This also wouldn't work for installing new kernels |
26 |
|
27 |
A third suggestion was simply to use rsync. This has some undesirable CPU |
28 |
overhead, however, as rsync recurses through the various directories. |
29 |
|
30 |
A final solution would be to simply re-image machines each time we want to |
31 |
upgrade them. This is a rather brutal solution and requires on-site |
32 |
presence, but I actually kind of like it, otherwise. |
33 |
|
34 |
So, what other suggestions do you have? |
35 |
|
36 |
--kurt |