On Tue, Jan 14, 2003 at 09:03:59AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: > On Mon, 2003-01-13 at 23:13, Steve Traugott wrote: > > > - Clusters, web farms, trading floors, call centers, etc. where you > > want multiple production machines to be the same. (This is the case > > which people usually think of.) > > > > > However, in such a case, you could simply execute apt-get install > > > foo on all such machines with the same results. Hence, a large file > > > won't be required. > > > > > > However, if you need to install .deb files from date-XXX later when > > > packages were replaced by more recent or security fixed versions of > > > those packages, the above won't work. > > > > Exactly. Unless you execute 'apt-get install' on all machines at the > > same time, identical results are not guaranteed. There needs to be a > > way to encapsulate both the action and the data at that instant in > > time. > > I think what I'd do if I were to maintain a cluster: > > create a local debian repository, with a local 'beta' and 'final' > distribution (like testing and stable, but I think it's better not to > use those names). > > The test machine(s) obviously point to beta, the cluster to final. So, > every new package would be put into beta, where it could be tested and > then it would be propagated into final (totally manual process. Could be > semi-automated by syncing beta to (for instance) Debian stable+security > on a regular basis). > > The only remaining problem would then be distributing debconf data. I'm > not familiar enough with that to have a proposal here, but I'm sure you > can come up with something. > > A cron job on all production machines would then look like: > - sync debconf db with master > - apt-get update && apt-get dist-upgrade > > (Hmmm. this does only cover installed pkgs. So a way to make sure new > packages are installed is required, too. But, since I would only expect > to-be-installed packages in the local 'final' repository, this is easy. > grep the Packages file and install everything available). Using 'beta' and 'final' trees in an apt repository is an interesting idea. If you're interested in this sort of thing, also see other methods, including heterogeneous environments where not everything is apt-able, installation of new packages as well as non-packaged operations such as installation of tarballs, user and business data administration, and miscellaneous configuration file changes -- see http://isconf.org, http://infrastructures.org, and past LISA papers at http://www.usenix.org. But I'm not trying to address that layer in this thread. The problem I need to solve right now is encapsulation of Debian packages and related debconf data for a given apt-get action per http://www.infrastructures.org/papers/turing/turing.html. Steve -- Stephen G. Traugott UNIX/Linux Infrastructure Architect, TerraLuna LLC stevegt@TerraLuna.Org http://www.stevegt.com
Attachment:
pgpHS8SJuPuf6.pgp
Description: PGP signature