| 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 |
Archives