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 this - list, please see the FreeBSD - Handbook
- - &footer; - -