Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: [Current-server] up2date stupidity

Project highlights: Stable Version: 1.6.1, Development Version: 1.7.6

Discussion topic

2020-04-07: This site is going to be decommissioned and shut down on 2020-07-01. Please copy and archive any data you wish to keep before that date.

Back to topic list

Re: [Current-server] up2date stupidity


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

« Previous message in topic | 3 of 5 | Next message in topic »


Show all messages in topic

Re: [Current-server] up2date stupidity tomjennings Tom Jennings 2003-03-17 15:50:56 PST
     Re: [Current-server] up2date stupidity jwbernin John Berninger 2003-03-18 06:03:32 PST
         Re: [Current-server] up2date stupidity tomjennings Tom Jennings 2003-03-18 15:04:12 PST
     Re: [Current-server] up2date stupidity hunterm Hunter Matthews 2003-03-18 09:43:01 PST
         Re: [Current-server] up2date stupidity tomjennings Tom Jennings 2003-03-18 15:25:26 PST
Messages per page: