Login | Register
My pages Projects Community openCollabNet
Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

Reply to message

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author tomjennings
Full name Tom Jennings
Date 2003-03-17 15:50:56 PST
Message > On Sat, 01 Feb 2003, Jonathan S. Shapiro wrote:

> > Does anybody *else* think that it was short-sighted that up2date will
> > consult only a single server?
> > ..
> > Conceptually, it shouldn't be hard to modify up2date to associate a
> > server with each channel individually. Am I missing something painfully
> > obvious?

On Sat, 1 Feb 2003, John Berninger wrote:

> If you look at it from a purely Open Source point of view, I would tend
> to agree. Looking at it from Red Hat's point of view, I disagree - the
> client was designed to take advantage of a business offering from Red
> Hat, and so there would only ever be a single authoritative package
> source.

In fact I've been working on this very thing for
some months, funded by the Public Software Foundation
(http://www.pubsoft.org). It's quite far along.

The goal is two-pronged, and totally Open Source devoted:
to provide RHN-like update capabilities (anonymously) in the
obvious manner, and to incorporate the BitTorrent protocol, a
secure peer-to-peer file transfer/download protocol that should
eliminate the "slashdot effect", eg. I can host downloads of
package FOO from my wimpy home server, and not die if slashdotted.

It's quite NOT trivial, as John points out. I spent a coupla months
trying to coerce up2date to do multiple repositories (as I ended up
calling them) but abandoned that, in favor of a different approach.

We predicated the whole project on the existence of [the quite
excellent, thank you] Current server. I've been lurking here for
some months (just catching up with older mail, as you can see...)

The approach I've taken is essentially a wrapper program, Up2us,
that manages the environment that Up2date runs in (the junk up in
/etc/sysconfig/rhn, and certs, keyring, etc) and invokes Up2date
per repository. It's conceptually not quite as pretty as integral
support within Up2date for multiple repositories, but it mostly
(see below) isolates me from the whims and fashions of RH.

Basically, up2us shuffles files around before invoking Up2date,
creating /etc/sysconfig/rhn/up2date on the fly from repository
data stored elsewhere. All of that is working just fine. I have
one sticky problem that I was about to post to this list when I
saw Jonathan & John's messages.

**** Registration. Right now the only way I have to create
a systemid file is to invoke rhn_register after fiddling it's
config to point to the right server.

The systemid file data is checksummed (SHA1) with the server
secret, so I can't make one up at the client, so the server has
got to give one to me. I'm obviously avoiding reverse-engineering
rhn_register's guts just to get a systemid.

I desparately want to eliminate this, preferably make Up2us do
it directly, or invoke an external command-line rhn_register
workalike. Any ideas here before I embark on this journey? Words
of wisdom? Rotten apples thrown?

There are a few other relatively minor problems that need to be
fixed within Up2date: it always terminates with the same exit
code regardless, so that Up2us can't tell normal termination from
a CANCEL from a "server error". RH hasn't been too excited with
my ideas for multi-repository, but they might not get upset with
a patch for this.

(One unfortunate structural issue with Up2date is that if there
are no packages available, eg. you are already-up-to-date, you must
click CANCEL to exit Up2date and continue with the next repository
in Up2us. I'm toying with the idea of editing the gladexml file
before each invokation of Up2date to customize it's Gtk interface.)

Once I solve the registration problem I should have a releasable
version out pretty quick.

I would think an instant-register client tool would be really handy
for Current; has anyone come up with one? If I end up makingone,
of course I'll let everyone know.


PSL: Sorry for the long message.

To unsubscribe, e-mail: dev-unsubscribe@curr​ent.tigris.org
For additional commands, e-mail: dev-help at current dot tigris dot org