239 lines
9.9 KiB
Text
239 lines
9.9 KiB
Text
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
|
|
<!ENTITY base CDATA "..">
|
|
<!ENTITY date "$FreeBSD: www/en/projects/updater.sgml,v 1.8 2002/06/29 09:07:08 nik Exp $">
|
|
<!ENTITY title "FreeBSD Binary Updater Project (binup)">
|
|
<!ENTITY email 'freebsd-binup'>
|
|
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
|
|
|
|
<!ENTITY done "<font color='green'>Done</font>">
|
|
<!ENTITY inprogress "<font color='blue'>In Progress</font>">
|
|
<!ENTITY notstarted "<font color='red'>Not Started</font>">
|
|
]>
|
|
|
|
|
|
<html>
|
|
&header;
|
|
|
|
<h2>Contents</h2>
|
|
<ul>
|
|
<li><a href="#goals">Goals</a></li>
|
|
<li><a href="#design">Design</a></li>
|
|
<li><a href="#implementation">Implementation</a></li>
|
|
<li><a href="#code">Code</a></li>
|
|
</ul>
|
|
|
|
<a name="goals"></a>
|
|
<h2>Goals</h2>
|
|
|
|
<p>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 <a
|
|
href="http://www.openpackages.org">Open Packages</a> and
|
|
<a href="libh.html">libh</a> projects efforts and there should be
|
|
very little overlap.</p>
|
|
|
|
<p>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)</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<a name="design"></a>
|
|
<h2>Design</h2>
|
|
|
|
<h3>"Profiles"</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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:</p>
|
|
|
|
<pre>
|
|
[mysystem] [web-server]
|
|
bin 4.2 bin 4.2
|
|
bash 2.02 manpages 4.2
|
|
src 4.2 apache 2.1
|
|
xblaster 1.0
|
|
</pre>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Authentication</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>Binary packages from the server are signed using public key
|
|
cryptography.</p>
|
|
|
|
<h3>Upgrade Client</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>The client will be implemented in a 3-stage process:</p>
|
|
|
|
<ul>
|
|
<li>A set of libraries which implement the bulk of the
|
|
client<->server mutt functionality.</li>
|
|
|
|
<li>A command-line version of the client which supports all
|
|
available library functions.</li>
|
|
|
|
<li>A GUI version of the client which either wraps around the
|
|
client or calls the library routines directly, depending on
|
|
whichever makes the most sense.</li>
|
|
</ul>
|
|
|
|
<p>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.</p>
|
|
|
|
<h3>Upgrade Server</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>The server will probably not keep any truly client-side data
|
|
like <tt>/etc/master.passwd</tt> 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.</p>
|
|
|
|
<a name="implementation"></a>
|
|
<h2>Implementation Details</h2>
|
|
|
|
<a name="update-server"></a>
|
|
<h3>Update Server</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<a name="update-server-todo"></a>
|
|
<p>Server TODO list :</p>
|
|
|
|
<ul>
|
|
<li>Add ability to manage packages as they are currently defined
|
|
and used in FreeBSD</li>
|
|
|
|
<li>Add mechanism to read the ontology of the FreeBSD src tree
|
|
from an XML file, instead of hard coding this into a Perl
|
|
script which generates the necessary database tables. This
|
|
will provide much needed flexibility in the creation of
|
|
profiles and software components. There should also provide a
|
|
description for packages that can obviate subsets of what
|
|
sysinstall currently calls the "base system" (e.g, a profile
|
|
with Postfix instead of Sendmail, and all of the configuration
|
|
dependencies that go along with that)</li>
|
|
|
|
<li>Add checksum information and provide a "tripwire"-like
|
|
service to clients.</li>
|
|
</ul>
|
|
|
|
<a name="update-client"></a>
|
|
<h3>Update Client</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<a name="update-client-todo"></a>
|
|
<p>Client TODO list :</p>
|
|
|
|
<ul>
|
|
<li>add copyright/license information to all various source
|
|
files</li>
|
|
<li>conform to style(9)</li>
|
|
<li>serious bug removal</li>
|
|
<li>add ability to manage packages</li>
|
|
<li>turn into a library</li>
|
|
</ul>
|
|
|
|
<a name="code"></a>
|
|
<h2>Where's the Code?</h2>
|
|
|
|
<p>This project is currently being developed in main FreeBSD
|
|
CVS repository. Its sources are located under <tt>projects/binup</tt>
|
|
hierarchy. You can use the usual methods of retrieving FreeBSD sources
|
|
to access it. <b>NOTE:</b> cvsup users should use <tt>projects-all</tt>
|
|
cvsup collection to access projects under <tt>projects/</tt> hierarchy</p>
|
|
|
|
<p>A mailing list has been setup for this project. Please post
|
|
all questions, patches, etc to the <a
|
|
href="mailto:freebsd-binup@FreeBSD.org">freebsd-binup@FreeBSD.org</a>
|
|
mailing list. For instructions on how to subscribe to this
|
|
list, please see the <a
|
|
href="../doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">FreeBSD
|
|
Handbook</a></p>
|
|
|
|
&footer;
|
|
</body>
|
|
</html>
|