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

Hide all messages in topic

All messages in topic

Re: [Current-server] up2date stupidity

Reply

Author tomjennings
Full name Tom Jennings
Date 2003-03-18 15:25:26 PST
Message > > 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.

> I wondered if anything came of that.

Of what?!


> > 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...)

> What? No patches?

(mild embarassment) My best excuse is, I'm a mere luser of
the code, so far. I am testing clients against it, is all. I
did, however, submit a few doc changes, but that was early,
1.2? 1.3? Nothing of substance.


> > The approach I've taken is essentially a wrapper program, Up2us,
> > blah blah blah

> Brave man.

Huh, me? I think it's the lazy approach, eg. least impact and harm
potential. I leave all the XMLRPC and complexity to RH -- and
you :-) -- and manage config data, which is, you have to admit,
an incomplete abstraction of what the program is doing, so it's
the maximum leverage point. Of course they can do something that
foils me, but that's always true... and it seems much of the
Current work, no?!


> > I desparately want to eliminate this [rhn_register], 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?
> >

> Already exists. rhnreg_ks


Aww crap, I have it right in front of me, and overlooked it. I
just didn't spend enough time in rhn_register source (or do the
usual redhat game, in tcsh type "rhn" and hit tab)

I never knew rhnreg_ks existed. I utterly overlooked it.

Welp, I'm embarrassed, but now I have my tool. Thanks guys!

> Even though registration functionality has been (correctly, in my not so
> humble opinion) been absorbed into up2date itself, this little gem is
> still with us to support sites that use kickstart.
> I just confirmed that its still on a latest and greatest pheobe -
> naturally, I have no knowledge ahead of time about what RH's plans are,
> however I'd be shocked to see this or similar technology go away -
> kickstart is just too useful.


See, this is just great then. I don't care if RH incorporates
register functions into the up2date client -- where it belongs,
I agree -- I don't care about RH. I'm not writing up2us to support
RH, that's what stock up2date is for. I'm supporting the use of
Current for non-RH houses to distribute packages with a safe,
automatic mechanism (eg. up2date-ish).





> On the other hand, if you're willing to do some coding in python, look
> at the wrapper. A simple command line run of up2date is a fairly simple
> object run in wrapper.py. If you wrote your own "up2us" backend, that
> was a simple python program that LOOKED like up2date command line, you
> could have it do any kind of error handling / reporting that you like.

Hmm, I hadn't thought of turning it inside out.

I had/have a hacked up2date that does it all internally; the
additional information (multiple repository information, URLs,
certs, etc) in an additional file) but I abandoned it. In order
to do the job even half-right, I was going to have to add screens
(OK, Gtk windows), modify existing, and the changes are sprinkled
throughout the messy sources; and of course RH has 2.7, 2.8, and
the pyramid that dropped on the camels back, 3.0. Pushing rope
upstream became less fun, and writing to the developers elicited
silence. I took the hint.



> A patch for proper error codes would probably be easier, and I'd love to
> see that myself.

I will do this. But which client version :-)

BitTorrent support will require a new object in I forget which
module. I don't think RH will be interested in this patch.


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

> man rhnreg_ks
>
> Clocks ticking.... :)

Ayup! :-)

I'll post a (brief) URL to where the RPM is for a testable
version, should anyone care. It's a proper RPM, up2us correctly
works with PAM, and up2us can even update itself while running
without croaking.


tomj



rhnreg_ks, sheesh.



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

Re: [Current-server] up2date stupidity

Reply

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.

tomj



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

Re: [Current-server] up2date stupidity

Reply

Author hunterm
Full name Hunter Matthews
Date 2003-03-18 09:43:01 PST
Message > 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.
>

I wondered if anything came of that.

> 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...)
>

What? No patches?


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

Brave man.


> 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?
>

Already exists. rhnreg_ks

Even though registration functionality has been (correctly, in my not so
humble opinion) been absorbed into up2date itself, this little gem is
still with us to support sites that use kickstart.
I just confirmed that its still on a latest and greatest pheobe -
naturally, I have no knowledge ahead of time about what RH's plans are,
however I'd be shocked to see this or similar technology go away -
kickstart is just too useful.

rhnreg_ks --username=x --password=x --email=x --nohardware --nopackages

is what I use here, in my kickstart scripts.


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

Possibly not.

On the other hand, if you're willing to do some coding in python, look
at the wrapper. A simple command line run of up2date is a fairly simple
object run in wrapper.py. If you wrote your own "up2us" backend, that
was a simple python program that LOOKED like up2date command line, you
could have it do any kind of error handling / reporting that you like.

A patch for proper error codes would probably be easier, and I'd love to
see that myself.

>
> (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.)

Oh - the gui side isn't something I have much experience with myself.

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

man rhnreg_ks

Clocks ticking.... :)

--
Hunter Matthews Unix / Network Administrator
Office: BioScience 145/244 Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02 9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.


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

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

Re: [Current-server] up2date stupidity

Reply

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.

tomj

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
Messages per page: