os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Import the binary updates project ("binup") web site into the web tree

Browse source 
so that others can update it.
This commit is contained in:
Murray Stokely 2001-09-17 05:32:49 +00:00
parent f4dc14c80c
commit 6328ba5e50
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/www/; revision=10710
3 changed files with 247 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
en/projects/Makefile
View file

@ -1,4 +1,4 @@
# $FreeBSD: www/en/projects/Makefile,v 1.6 1999/09/06 07:02:48 peter Exp $
# $FreeBSD: www/en/projects/Makefile,v 1.7 2000/11/07 04:05:21 kuriyama Exp $
.if exists(../Makefile.conf)
.include "../Makefile.conf"
@ -9,6 +9,7 @@
DOCS= projects.sgml
DOCS+= mozilla.sgml
DOCS+= updater.sgml
DOCS+= newbies.sgml
INDEXLINK= projects.html

13
en/projects/projects.sgml
View file

@ -1,6 +1,6 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD: www/en/projects/projects.sgml,v 1.111 2001/08/02 04:51:59 chris Exp $">
<!ENTITY date "$FreeBSD: www/en/projects/projects.sgml,v 1.112 2001/08/23 13:44:07 kuriyama Exp $">
<!ENTITY title "FreeBSD Development Projects">
<!ENTITY % includes SYSTEM "../includes.sgml"> %includes;
]>
@ -563,6 +563,17 @@ examples). </li>
backend. Libh also includes a new package system that uses Zip
archives and various per-package scripts among other things. It also
includes the beginnings of a new sysinstall.</li>
<li><A name="binup" HREF="updater.html">Binary Updater
(binup)</A>. The FreeBSD Binary Updater Project aims to
provide a secure mechanism for the distribution of binary
updates for FreeBSD. 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).</li>
</ul>

233
en/projects/updater.sgml Normal file
View file

@ -0,0 +1,233 @@
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" [
<!ENTITY base CDATA "..">
<!ENTITY date "$FreeBSD$">
<!ENTITY title "FreeBSD Binary Updater Project (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;
<!-- <h1>Project Status</h1>-->
<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 Open Packages and libh
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, dependinng 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>
<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>
<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>
<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>
<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 a CVS repo on
usw4.freebsd.org. Unfortunately, this machine was recently
upgraded and the CVS pserver was removed. The administrator
have been notified and the code should be available through
anonymous CVS in the very near future. For the time being, you
can download a snapshot of the code <a
href="http://www.FreeBSD.org/~murray/updated.tgz">here.</a></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</a>
mailing list. For instructions on how to subscribe to thsi
list, please see the <a
href="http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/eresources.html#ERESOURCES-MAIL">FreeBSD
Handbook</a></p>
</body>
</html>