Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: Patch against 1.7.4 > Reply to message

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

Reply to message

2020-03-13: This site is going to be decommissioned and shut down very soon. Please copy and archive any data you wish to keep ASAP

* = Required fields
* Subject
* Body
Send reply to
Author (directly in email)
Please type the letters in the image above.

Original message

Author theslack
Full name Jack Neely
Date 2006-08-11 06:20:45 PDT
Message Pauline,

Abosultely awesome. Thanks a bunch. I've actually been struggling
with how to handle user authentication for a while. You'd think this
is common and there would be libraries or best practices or something
similarly googlable.

Let's see...if you handle an exception in most cases you also want to
call logException() in the except clause so that the exception get in
the log file.

I'm not sure I want to implenent random creation of new users via
up2date's registration thing. But that's very minor and the code is
definitely needed. One of the bigger things I'm aiming for is to
bring what RHN should be with the up2date client to Yum. (Especially
since up2date is going away.) In the long run that probably means a
replacement for rhn_check. But we might be able to get some code from
Red Hat's RHN Yum plugin when that is available.

Hmmm...I probably haven't explained well to my user/devel community my
"vision" (*chuckle*) for supporting Yum.

Few comments inline.

This is fantastic. Thanks a bunch!


On 8/11/06, Pauline Middelink <middelink at polyware dot nl> wrote:
> Hi Jack,
> Attached a patch for 1.7.4. I tried to add some user handeling to
> current.
> In essence it creates a USER table, with for now only a user_id,
> username and password. During registration up2date will check
> if the user/passwd already exists, and if not make a new user for
> it. This works. Then the patch adds a user_id to the profiles,
> making the systems 'owned' by the user. This seems to work in
> my little testcases ok.

*Happy Dance*

> Second thing the patch does is implement functionality for the
> add/del/update package list which is maintained my up2date/rhn_check.
> It uses the INSTALLED database, which has been changed to include
> name,version,release and epoch fields. In my opinion there was
> a thinko in the previous design, it assumed all the packages the
> client has installed could be matched to a package_id. Does not
> work in the real-world :). So the package_id became optional.
> The patch tries to maintain a mapping from the INSTALLED.nvre
> tuple to the current PACKAGE list (during deleteRPMS and addPackage).
> Thus, for the packages which ARE known to current, the
> INSTALLED.package_id is/should be correct.

You're correct. The thinko was one reason (besides the whole working
for a living) that the INSTALLED table stuff was not implemented.

Your database foo may be stronger than mine. Does it make since to
have an unknown packages table and make INSTALLED a mapping between
profile_ids and package_id or unknownpkg_id?

> !!!
> Something you might want to look at (python is not my native
> language) is the way I handle the two types of tuples add_package
> needs to process. During registration the tuple contains a arch
> and a cookie, but in later updates on these two fields are missing.
> I used a boolean and a try/except to switch between the two. There
> might be a smarter way of handeling this.

Hmmm...I forget what the cookie is. I probably have that written down
someplace. You might want to use len(tuple) and do this based off how
many elements you find in the tuple. I'll look at it in more detail

> Some TODO's, which i'm willing to work on:
> - crypt/md5 the password before putting it in database or using it.

SHA1 I think is best.

> - store hardware info in HARDWARE table. Need better format than
> current table scheme.

Not high priority....the database info that up2date shoves at Current
is fun to handle. A bunch of random dicts. The only commonality is
that they all have a 'class' field.

Need to figure out how (or if possible) we can do this with Yum.

> - add some fields to PROFILE so we can check if the system logs
> in, and if so, how often.

Yes...needed soon. Also look at the webpage stuff that's now in
trunk. I'm using the TurboGears toolkit.

> - setup a QUEUE, so we can tickle a system to resend profile etc.
> Queue itself is not difficult, all you need to do is sent a
> properly formatted (python serialized) method to the client.
> [i could invision a cadmin queue command for this :) ]

Again, need support for Yum. Red Hat may be workiing on a solution
here as well.

> Some nagging questions:
> Why is PROFILE not called SYSTEM?

Because I am horrible at keeping names consistant. :-) I imagine all
profile/system things should refer to a "system".

> Met vriendelijke groet,
> Pauline Middelink
> --
> GPG Key fingerprint = 2D5B 87A7 DDA6 0378 5DEA BD3B 9A50 B416 E2D0 C3C2
> For more details look at my website http://www.polyware.​nl/~middelink