| 1 |
On Tue, 2004-12-21 at 20:20 -0600, William Kilian wrote: |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
|
| 5 |
Welcome! |
| 6 |
|
| 7 |
> |
| 8 |
> All the servers run basically the same software so that administration |
| 9 |
> is consistent across machines, but hardware varies from pentium mmx's to |
| 10 |
> dual xeons. So apparently I should build a generic x86 stage1 or just |
| 11 |
> use a precompiled one, then build custom stage2/3s from it with spec |
| 12 |
> files that only differ by their CFLAGS, etc. I can build those on one |
| 13 |
> machine (I have a nice dual-xeon ready and waiting), then perform the |
| 14 |
> installs by setting up my fs's, booting to a floppy and wget -O - |
| 15 |
> http://build-box/stage3.subarch.tar.bz2 | tar -xjPps -C / ... or |
| 16 |
> something like that. But then I suppose I should use tinderboxes to |
| 17 |
> build upgrade binary packages so that I can install binary packages on |
| 18 |
> the slow machines and do all my building in one, very secure, place. |
| 19 |
> |
| 20 |
|
| 21 |
Sounds like a good plan, although there is really no need to build your |
| 22 |
own stage1 (unless you are doing fun things like pie/ssp (hardened |
| 23 |
stuff)). I assume that you are planning on using the tarballs solely for |
| 24 |
installs, correct? The binary packages that you build can be installed |
| 25 |
via Portage over an NFS share or something. |
| 26 |
|
| 27 |
Instead of tinderboxes, consider using the "grp" target. Tinderboxes are |
| 28 |
used more for building a set of packages and then logging the successes/ |
| 29 |
failures. The "grp" target will do exactly what you are looking for and |
| 30 |
will organize all of the binary packages by profile type, arch, etc. Let |
| 31 |
me know if you need help on how to setup a grp build. |
| 32 |
|
| 33 |
> That's the scenario. Questions: |
| 34 |
> |
| 35 |
> Where do I put all my custom use flags? |
| 36 |
> I specify use flags on a per-package basis most of the time, in |
| 37 |
> /etc/portage/packages.use. I also have to use custom masks, etc. to |
| 38 |
> install certain packages that I need. I can't tell when or how I'm |
| 39 |
> supposed to specify all those customizations. As far as I can tell, only |
| 40 |
> stuff that will eventually go in /etc/make.conf belongs in a catalyst |
| 41 |
> spec file. If I should just add the /etc/portage files after the stage1 |
| 42 |
> is built, when and where do I put add them? In the stage1 image before |
| 43 |
> doing the stage2? |
| 44 |
> |
| 45 |
|
| 46 |
Catalyst supports the configuration files in /etc/portage. Just add the |
| 47 |
following to your spec file (works for any build target): |
| 48 |
|
| 49 |
portage_confdir: /etc/portage |
| 50 |
|
| 51 |
> Should I really build my own stage1 or just use stage1s from gentoo mirrors? |
| 52 |
|
| 53 |
Answered above - just use the stage1 from the mirrors. |
| 54 |
|
| 55 |
> What's the best way to perform upgrades and incorporate them into my |
| 56 |
> stage3 images? |
| 57 |
> Obviously I will want to build upgrade packages using tinderboxes with |
| 58 |
> package caching. |
| 59 |
|
| 60 |
Use GRP Luke! |
| 61 |
|
| 62 |
> I would use a separate package cache for each subarch. |
| 63 |
|
| 64 |
Catalyst does this automatically for you with GRP. |
| 65 |
|
| 66 |
> Can I do an emerge -u style upgrade to a package in a tinderbox if the |
| 67 |
> stage3 for the tinderbox already has an old version of the package |
| 68 |
> installed? Will I need to uninstall the old version from the stage3 |
| 69 |
> first? Would it be better to simply use package-caching and build a |
| 70 |
> whole new series of stages 1, 2, and 3 if I'm upgrading packages, then |
| 71 |
> install the binary packages on existing systems? |
| 72 |
> |
| 73 |
|
| 74 |
To keep your GRP up-to-date, all that you will have to do is regenerate |
| 75 |
your snapshot and rebuild the GRP set. Catalyst will take care of the |
| 76 |
upgrades automatically by only rebuilding the packages that have been |
| 77 |
upgraded. |
| 78 |
|
| 79 |
> What's the best way to automate custom configurations of system files |
| 80 |
> (e.g. /etc/profile)? |
| 81 |
> Should I build my own ebuild or customize existing ebuilds using a |
| 82 |
> /usr/local/portage overlay? |
| 83 |
> |
| 84 |
|
| 85 |
Hmm. At this time, an ebuild would probably be the easiest solution. |
| 86 |
|
| 87 |
> I have more questions about using catalyst to automate server |
| 88 |
> maintenance as much as possible, but answers to some of the above |
| 89 |
> questions would help a lot. |
| 90 |
> |
| 91 |
|
| 92 |
Ask away :) |
| 93 |
|
| 94 |
Cheers, |
| 95 |
-- |
| 96 |
John Davis <zhen@g.o> |
| 97 |
The Gentoo Foundation |
| 98 |
Trustee | Release Engineering Manager | Catalyst code monkey |
| 99 |
|
| 100 |
--- |
| 101 |
"When people learn no tools of judgement and merely follow their hopes, |
| 102 |
the seeds of political manipulation are sown" |
| 103 |
- Stephen Jay Gould |
Archives