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-18 15:04:12 PST
Message re: up2us
> > RHN-like update capabilities (anonymously) [...]
> > ... to incorporate the BitTorrent protocol, a
> > secure peer-to-peer file transfer/download protocol ...

> Ok, my first reaction... "ew! ew! ew! YEECH!"

Wait, I showered today!

> Why? I don't like p2p stuff, and I can't see any way that a
> home connection, even a T1, *won't* die if it's slashdotted.

p2p I agree, is generally not even a good *idea*. I share none of
the fanaticism with popular p2p claims. But BitTorrent is quite
different. I won't bore you with the details, but it essentially
centrally coordinates p2p between concurrent downloaders. File
chunks are checksummed, it's sufficiently paranoid, etc. And in
any case, the p2p stuff hasn't received any attention from me,
whilst I untangle the logistics of up2date/current.

Up2date/Current are useful/trustworthy because of the SSL cert
and package sigs/keyrings. We want to generalize that usefulness.

> > The approach I've taken is essentially a wrapper program, Up2us,
> > that manages the environment that Up2date runs in

> A valid solution, but I have trouble accepting a program that
> shuffles the configurations of other, possibly more critical, programs
> around...

Eh. It's not like I'm redirecting stdin/stdout like some expect
script or something. There's exposure to revisionitis no matter
the approach. First, it's hard to do any harm in this instance; if
I get up2date's config wrong, it doesn't talk, not rm -r *. I've
got good error recovery (eg. you kill -9 up2us, of course *my*
programs never crash :-), and the underlying work just isn't that
hard -- it's what you describe in installation.txt, essentially,
but instead of overwriting cert files I point config at 'em, and
manage multiple repository sets (URL, cert, keyring, blah blah)
in pythonesque config, and Gtk to config and operate it.

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

Well, the D'OH! is from Hunter's response, I'll grovel in next Reply.

> Well, your next problem is that rhn_register has disappeared as
> of RHL 8.0.

Good riddance! Yay!

> good news is that there are command-line clients for just about
> everything the GUI does - look at the options in the man pages, esp
> --nox and --rhn-register for this.

Up2us doesn't play that game w/stdin and stdout, it's too messy
and untrustworthy. --nox and --rhn-register invoke curses-type
interfaces, it's not useful. rhnreg_ks is useful (aargh).

Right now I'm concentrating on the Gtk up2us. It's the most
obvious, but not the most useful. It invokes the GUI up2date. The
command-line up2us is more useful, and a functional subset of
the Gtk version. Unlike up2date, I won't intertwingle the two
interfaces (sheesh); the modules/functions are properly tiered.

I will likely redo it in python. It's perl now. I am
language-agnostic; I can write perl in my sleep, and python is
new to me. Eh.

> > 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
> > [...]

> Again, from Red Hat's point of view, "We don't care that you
> can't tell how it exits, because we're the only authoritative source of
> packages". And the GUI always exits normally, even if there's a server
> error, so the exit code is both politically and logically correct. From
> Current's point of view, try the command-line client. It should be
> fairly easy to slurp in it's output and look for telltale strings...

I realize all this, I'm quite politically pragmatic (read: numb
& bruised). I may offer them patches to the 2.x and 3.x clients,
anyways. It can't be worse than tossing pennies in a fountain.

> Depends on what you mean by "instant-register" -

Sorry, too brief: to register non-interactively. Read next message
to revel in my embarrassment.


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