1 |
Sancho2k.net Lists wrote: |
2 |
> The reason I relate this is that I would like to get input on whether |
3 |
> our process can be streamlined past this point. Our goals are as follows: |
4 |
> |
5 |
> 1. Centralize build source |
6 |
> 2. Rapid deployment (installation and packages) |
7 |
> 3. Control software/system versions |
8 |
> |
9 |
> The intention is to set up a local rsync mirror on the LAN and use this |
10 |
> as the source of updating portage across all systems. Then even if |
11 |
> someone gets a wild hair and decides to emerge sync out of the blue, |
12 |
> they have the latest portage available per our discretion. Then our |
13 |
> build server and all "clients" will update thier Portage trees from this |
14 |
> mirror. All packages will be compiled and built on the build server and |
15 |
> possibly burned in prior to rollout on the production servers. This |
16 |
> seems to fit the need of #1 and #3. #2 is proving to be a bit more |
17 |
> difficult, as described above. Maybe if we used a more recent livecd |
18 |
> (currently 1.4.? from 09/03) it would have a more current portage and |
19 |
> allow us to take the system from untarring stage3 directly to emerge |
20 |
> sync and system in less time. |
21 |
> |
22 |
|
23 |
Although the 2004.0 LiveCD will solve your problem, all you need is the |
24 |
2004 stage2 or stage3 .tar.bz2. |
25 |
|
26 |
>>>> 2) Not running 'emerge sync' from each server is actually harmful to |
27 |
>>>> the |
28 |
>>>> server. You might be able to use 'emerge regen' to mitigate most of |
29 |
>>>> this, but I haven't investigated it that fully (since I switched from |
30 |
>>>> NFS /usr/portage to a BINHOST). |
31 |
> |
32 |
> |
33 |
> Taking this advice to heart. I now see that trying to share /usr/portage |
34 |
> across all hosts via NFS was foolish as Portage was not designed to |
35 |
> operate like that. |
36 |
> |
37 |
|
38 |
It used to work better, but Portage has matured and has provided better |
39 |
management which has made NFS less and less workable. |
40 |
|
41 |
> I've heard recommendations to run fixpackages at times. What is the |
42 |
> exact purpose of that? It appears to handle moving packages to different |
43 |
> categories as Portage changes. Is it recommended to run this often, or |
44 |
> after a new emerge sync, for example? |
45 |
> |
46 |
|
47 |
Yes, I'd run it on a cron job daily on your build server -- just in case. |
48 |
|
49 |
> Another thing we're investigating is the need to use emerge with the -D |
50 |
> and -U options to make sure that all packages and dependencies on the |
51 |
> build server are always kept current. At this point, it sounds like a |
52 |
> fine idea to me. Are there compelling reasons why this might not be a |
53 |
> good idea? |
54 |
> |
55 |
|
56 |
Using -D and -e regularly are great ways to keep your build server busy |
57 |
and should prevent dependancy problems when building a new server. |
58 |
|
59 |
jbw |