[Infrastructures] Found some software.

[Luke A. Kanies]

On Mon, 24 Feb 2003 pac@fortuitous.com wrote:

>   Thanks for the reply. Do your remarks about Debian's Apt also apply
> to the Apt-RPM that Conectiva uses? I've had good luck admining
> boxes like Redhat and Conectiva with Apt, since they usually resolve
> ugly dependency issues. Maybe apt can be used on the gold servers,
> and then propagated to the clients via whatever package tool they use?

I'm a relative newbie at apt, but I had to stop using most of the features
of HP's package management system, because it would autoselect appropriate
packages, which meant I got different systems depending on the state of
the package depot, rather than on my configs.

I ended up moving all of the packages into individual files, and then
having all of the dependency info in ISconf, instead of in the package
system.

You'll find that if you depend on your package system to take care of
dependencies for you, you will get different results from the same config.
Imagine the following situation:

You add OpenSSL and OpenSSH to your package system.
You build HostA.
You upgrade OpenSSL in the archive.
You build HostB.

Now, HostB has the latest OpenSSL, but HostA doesn't.  Yeah, you'll want
to upgrade it anyway, but now it's out of order, and if you don't remember
to upgrade all of your hosts, you've introduced an inconsistency.

Frankly, though, this kind of problem is essentially unavoidable.  You can
have ordering conflicts with cron, for instance, if one host runs the
cronjob before running the next stanza, but the next host doesn't run the
cron first (based on the time that the cronjob was installed relative to
when it runs).

>   Also, can the gold server be host for several distro types as well via
> chroot, or say uml?
>  I'm thinking that you can support several distros by installing packages
> in a chroot or User Mode Linux shell and once they are correctly install,
> propagate the results out.

Hmmm.  I maintain all of my packages as separate files.  I currently
separate them based on platform, but that's just for ease; I could just as
easily store them all on a central server.

I still need multiple hosts for creating the packages, so it's no real
extra work.

If you're talking about the install images, well, on the one hand, you
shouldn't modify your install image once it's created (although I've had
problems buying systems that weren't supported by the existing image), and
on the other hand, just let the systems take care of adding packages, and
use the gold server purely for package storage.

> Another issue that came up was CVSup or CVS repository size. How large
> do these get? Do they store change in the actual configuration info, or
> actual binary/file changes?

Just configuration changes.  You shouldn't version control your package
archive; if you need a new version, name the package something different,
or give it a different rev number.  I usually create my package
directories with the following structure:

$(uname -s)/$(uname -r)/$pkg/$pkgversion/packagefile

Luke

-- 
oH for Pete's sake, use a real filter. ;-)
                -- Tom Christiansen
Look, I refuse to install any filter which looks like it's more highly
evolved than homo sapiens, it will just get embarassing when it starts
critiquing the literrary style of my friends mail to me.
                -- Richard Caley, in comp.lang.perl.misc