The FreeBSD Binary Updater Project aims to provide a secure mechanism for the distribution of binary updates for FreeBSD. This project is complementary to the Open Packages and libh projects efforts and there should be very little overlap.
This system is a client / server mechanism that allows clients to install any known "profile" or release of FreeBSD over the network. Where a specific profile might contain a specific set of FreeBSD software to install, additional packages, and configuration actions that make it more ideal for a specific environment (ie FreeBSD 4.3 Secure Web server profile)
Our current implementation aims to abstract the actual ontology of the FreeBSD software collections so that future development in the direction of a more fine grained base system can be leveraged effectively without unnecessary reimplementation.
What the user sees as "top level objects" in the upgrade system are canned profiles. A profile can represent a given user's system configuration or a generic system template (web server, mail server, etc) that we provide.
Each profile consists of file entries and/or collection entries. A collection entry represents a grouped set of files like a package or what sysinstall calls a "distribution." Profiles exist on the server machine, though the client can also choose to cache copies for "tripwire" types of activities. Some typical profiles and their contents might look like this:
[mysystem] [web-server]
bin 4.2 bin 4.2
bash 2.02 manpages 4.2
src 4.2 apache 2.1
xblaster 1.0
A collection can also have a specific version number associated with it or have a "floating" version number, meaning that it tracks whatever's newest for that entity.
Authentication
Users will authenticate with the server via a username / password scheme which allows them to access their custom profiles as well as any system-defined ones.
Binary packages from the server are signed using public key cryptography.
The client supports connecting to an upgrade server, authenticating a user, browsing existing profiles or creating new ones and downloading file data and "actions" from the server. New file data will be created in such a way that partial updates do not cause corruption and whole transactions are committed in reasonably atomic fashion.
The client will be implemented in a 3-stage process:
Since a system can also be "upgraded" from a standing start, a next-generation installation tool could take care of the disklabelling filesystem formatting, and network setup then make heavy use of the client library to actually bring up a menu of available software and perform the installation.
The server supports connections by arbitrary numbers of clients and authenticating a user (or "anonymous" if the server is configured to support anonymous connections) for determining the available profiles.
Once the server receives a manifest (e.g. a set of collections) from a client machine and a server-side profile name to match it with, it goes looking through each collection to see if a newer version of that collection exists on the server or if there are any change deltas pending against the collection which are greater than the corresponding patchlevel of the collection in the client manifest.
Deltas and/or entire collections are sent to the client for unpacking along with any before/after actions for each delta or collection which should be executed on the client. Once the client has confirmed that all before/after actions and extraction of a given collection has completed successfully, it updates the stored profile and goes on to the next. If the transfer is interrupted at any point, the process can therefore pick up where it left off.
The upgrade server provides local storage for a certain amount of profile data depending on disk space constraints and can also be used as a way of cloning machines. The user installs one machine entirely according to taste and then uploads its profile. Each subsequent machine is installed from this profile and voila, an army of clones.
The server will probably not keep any truly client-side data like /etc/master.passwd or anything else it doesn't offer out of its own collections, but we can leave this decision open for later or make it a configuration option.
The update server is for the most part in a usable state. Information about profiles, collections, and actions are stored in a SQL database. A database abstraction layer talks calls the relevant hooks (MySQL and PostgreSQL supported at the moment) to service client requests. Using a relational database has made it very easy for us to change the organization of the data without spending time rewriting code. As we finalize our data structures it might be more efficient to move to BerkeleyDB or another solution but for now SQL has saved a lot of development time.
The server can be used to successfully install or upgrade a system to FreeBSD 4.X but there is a lot of polishing up to do and many additional features are needed.
Server TODO list :
The update client is not currently usable. At the moment, it consists of some code to perform the actual updates, and some quick code to test the various functions of the updater. Also, the client does not currently handle packages. Once this capability has been added, and the various ugly bugs have been worked out, the existing code needs to be turned into a library.
From there, it will possible to easily create an installer as well as an end-user upgrade program, in forms of a text application, an X application, and maybe even big eye candy GNOME and KDE applications as well.
Client TODO list :
This project is currently being developed in main FreeBSD CVS repository. Its sources are located under projects/binup hierarchy. You can use the usual methods of retrieving FreeBSD sources to access it. NOTE: cvsup users should use projects-all cvsup collection to access projects under projects/ hierarchy
A mailing list has been setup for this project. Please post all questions, patches, etc to the freebsd-binup@FreeBSD.org - mailing list. For instructions on how to subscribe to thsi + mailing list. For instructions on how to subscribe to this list, please see the FreeBSD Handbook
&footer;