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

Back to topic list

Re: [Current-server] up2date stupidity


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.


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

« Previous message in topic | 5 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: