Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Patch against 1.7.4 > Reply to message

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

Reply to message

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.

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

Original message

Author Pauline Middelink <middelink@polyware.nl>
Full name Pauline Middelink <middelink@polyware.nl>
Date 2006-08-11 03:42:51 PDT
Message Hi Jack,

Attached a patch for 1.7.4. I tried to add some user handeling to

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.

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.

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.

Some TODO's, which i'm willing to work on:
 - crypt/md5 the password before putting it in database or using it.
 - store hardware info in HARDWARE table. Need better format than
   current table scheme.
 - add some fields to PROFILE so we can check if the system logs
   in, and if so, how often.
 - 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 :) ]

Some nagging questions:
  Why is PROFILE not called 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