Date: Sun, 22 Dec 2002 15:53:07 +0100 From: "Simon L. Nielsen" <simon@nitro.dk> To: freebsd-binup@freebsd.org Subject: Re: status? Message-ID: <20021222145307.GC375@nitro.dk> In-Reply-To: <Pine.LNX.4.30.0212211659070.23020-100000@linux17.zdv.uni-tuebingen.de> References: <Pine.LNX.4.30.0212211659070.23020-100000@linux17.zdv.uni-tuebingen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
--kXdP64Ggrk/fb43R
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On 2002.12.21 17:02:05 +0000, Friedemann Becker wrote:
> > Well, I'm interested in writing code at the moment. ;)
> Are you in need of any assistance?
> Maybe you could need a more or lessed skilled programemr?
>
> I'd like to help.... ;-)
It appears that there are some people who want to get this project
started again - so I think we should try to get this going...
Somebody had started making a document about some kind of package
abstraction layer (about a year ago) - does anyone know if anything came
out of that?
I have attached the doucmentation I have on the "old" code - I can't
remeber if there is more, but I think there was homepage with some more
documentation...
Btw. The Anarcat just wrote to me that the binup CVS tree was saved from
usw1 so and is now on the server the libh project uses.
--
Simon L. Nielsen
--kXdP64Ggrk/fb43R
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=NOTES
FreeBSD Binary Updates Project
To setup your database to run the server :
1. Create a database for this application, 'updates' is the default used by the server if you don't specify another name.
2. Run the `setupdb' program to create 4 tables in your database that the server application will use to store information about the files.
3. Run the 'extract' program on a distribution to copy the dists from a CD set onto a directory tree
- OR -
3. Realize that this has already been done and simply NFS mount mother's /a and look in /a/projects/updates
4. Run populate on the directory hierarchy created in step 3 and send the output to a temporary file. This file will contain a list of INSERT statements for every file in the hierarchy to setup your tables.
5. `cat sql.out | mysql -u updates updates' to actually populate the database
6. Build and execute the server process.
An `ACTION' is a stream of data that is to be executed by the client.
This stream is saved by the client as a file in a temporary directory
so that a user can inspect scripts/binaries before they are executed.
can be a shell script, perl script, binary, or any
Miscellaneous design issues
---------------------------
o Profiles
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.
A collection is represented by a base delta and n change deltas, new
base deltas being created periodically as the size of the last base
and n change deltas exceeds the cost of a new base delta.
o 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.
o Crypto
Transport between the server and client will be done via a secure
means with encryption of all data and proper sanity checking to
prevent data corruption and/or man-in-the-middle attacks.
Upgrade Client:
---------------
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:
o A set of libraries which implement the bulk of the client<->server
functionality.
o A command-line version of the client which supports all available
library functions.
o 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.
Since a system can also be "upgraded" from a standing start, a special
version of sysinstall will also be generated which basically just does
the disklabelling and filesystem formatting part, selects a server,
handles authentication and then brings up a menu of available
profiles. From that point the upgrade system takes over and the
system is "upgraded" into place rather than installed in the usual
fashion. This version of sysinstall will also be a major consumer of
the upgrade client library.
Upgrade Server:
---------------
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.
Did I miss anything?
- Jordan
--[ Server Implementation ]---
The current implementation of the update server is a C program
running on callisto.osd.bsdi.com port 31337 (no this will not be the
permanent port number). The source code for this server is available
from cvs /usr/local/cvsrep/updated.
You can telnet to
. Authentication / Encryption
OpenSSL?
--[ Dependencies ]---
In addition to requiring a database package to function, this
software currently uses the GNU readline library to get its initial
configuration information from a users terminal. This dependency will
be removed soon.
Murray
--kXdP64Ggrk/fb43R--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-binup" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021222145307.GC375>