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

current
Discussion topic

Back to topic list

Re: [Current-server] up2date stupidity

Reply

Author jwbernin
Full name John Berninger
Date 2003-03-18 06:03:32 PST
Message On Mon, 17 Mar 2003, Tom Jennings wrote:

> 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.
        Ok, my first reaction... "ew! ew! ew! YEECH!"

        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. You either
kill the clients trying to connect, which upsets people and makes them
go away, or you kill the server, achieving the same effect on the
clients. I'm quite willing to be proven incorrect, as this is only my
opinion of p2p things.

> 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.
        A valid solution, but I have trouble accepting a program that
shuffles the configurations of other, possibly more critical, programs
around... again, though, water under the bridge as it's personal
opinion.

> **** 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?
        Well, your next problem is that rhn_register has disappeared as
of RHL 8.0. The up2date client includes the registration bits. The
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.

> 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.)
        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 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.
        Depends on what you mean by "instant-register" - register and
update all in the same shot? Already being done with the new up2date
3.x clients (in RHL 8.0). Start up the machine, plug in the ethernet
cable, and it's registered? Very unlikely to happen anytime soon, at
least based on my understanding of how things work.

--
John Berninger

GPG Key ID: A8C1D45C
        Fingerprint: B1BB 90CB 5314 3113 CF22 66AE 822D 42A8 A8C1 D45C

Sit vis nobiscum.
--

--------------------​--------------------​--------------------​---------
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 | 2 of 5 | Next message in topic »

Messages

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: