Red Hat Bugzilla – Bug 215783
Verify that Installation Numbers can be supplied in the "dashed" format
Last modified: 2007-03-29 11:58:14 EDT
The current format in which we display Subscription Numbers or Registration
Numbers is in gorups of 4 hex characters separated by dashes:
Example from the mail received after registering for an Eval on redhat.com:
The following registration number has been assigned to your email@example.com Red
Hat login account.
To activate your evaluation subscription, go to http://www.redhat.com/activate:
This is the format we use publicly and that OEMs use for printing registration
It currently works in RHEL5 B2 but we need to make sure it continues to work and
make sure we test for it.
So rhn_register and anaconda need to understand both formats:
All of the logical parsing to determine if an installation number is valid or
not happens server side in RHN. So, both formats would be supported by
rhn_register, since it's just going to send it up to the server and wait for a
response as to whether it's valid or not. Keeping in mind, however, that for
beta2, no numbers will appear valid to RHN.
Not in the client side packages, it is in the backend. Not a blocker.
Adjusting priority to P1.
The issue is that this has to work end-to-end. So if you enter a dashed format
in anaconda or rhn_register, it has to work correctly. This might mean removing
the dashes in rhn_register.
Anaconda currently supports the dashed format while the inderlying rhel-instnum
implementation does not. This indicates that Anaconda removes the dashes before
using the number.
I still consider this a RHEL5 GA blocker.
What are you asking for specifically? Please read what I wrote in comment #1.
It does not matter if the user inputs the number with dashes or not. We did
that to make the usability easier.
I'll be adding support to the underlying library (rhel-instnum) to handle dashed
numbers. Once that's done, this should be a non-issue.
While I'm messing around in the parsing code, are there any other formats I
should add support for? maybe 'xxxx xxxx xxxx xxxx'? Or can we say with some
certainty that the two formats described in comment #0 are the only ones we are
Here's a wild and crazy idea . . . what about having 4 boxes, separated by
dashes in the UI. Each box capable of having 4 chars entered and the cursor
automatically jumping to the next in the series once 4 chars are entered. This
would not only force the correct format entry, but also makes it far easier for
the user to determine if they are in-fact entering the correct number.
Well, we also plan to use 24 and 32 digit numbers at some point (although I
don't think the plan includes making users enter them manually). Then there's
kickstart. But still, that sounds worth doing if it's not deemed too late.
On comment 6: What I ask for is that entering the number in dashed format works.
For anaconda it makes sense to actually strip it. I am not sure about
rhn_register because of the Dell Service Tag issue. I assmue that just sending
everything to the backend and have that take care is a valid approach. But this
makes it a requirement for the backend.
On comment 10: The problem here would be the longer number we want to be able to
support at a later point and immediately the Dell Servie Tag wich is a
This bug is a server side bug so no client changes are required. In other
words, this bug will not affect any RHEL5 packages. This functionality will be
deliver with RHN Hosted 500.
this bug should have been blocking rhn500h-must, since it was in that release.