Bug 815975 - regex used to create custom repository path should only sub arch in last dir of path
regex used to create custom repository path should only sub arch in last dir ...
Product: Red Hat Update Infrastructure for Cloud Providers
Classification: Red Hat
Component: RHUA (Show other bugs)
Unspecified Unspecified
high Severity unspecified
: ---
: 2.1.1
Assigned To: mkovacik
Depends On:
  Show dependency treegraph
Reported: 2012-04-24 18:32 EDT by mkovacik
Modified: 2013-02-27 11:59 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
When upgrading RHUI from 2.0.1 to 2.0.3, custom repositories resulted in mismatch errors from the client certificate and the repository CA certificate, blocking access to the custom repositories. This is caused by the regex used in creating custom repositories only using subarchitectures in the last part of the directory path. This patch prevents entitlement path guessing if there are different architectures involved. Custom repositories are now accessible after upgrades.
Story Points: ---
Clone Of:
Last Closed: 2013-02-27 11:59:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Screen log (27.21 KB, text/plain)
2012-04-24 18:32 EDT, mkovacik
no flags Details
rhua pulp client log (77.23 KB, text/plain)
2012-04-24 18:35 EDT, mkovacik
no flags Details
cds httpd ssl access log (9.85 KB, text/plain)
2012-04-24 18:36 EDT, mkovacik
no flags Details
cds httpd ssl error log (18.04 KB, text/plain)
2012-04-24 18:37 EDT, mkovacik
no flags Details
protected custom repo's working (9.71 KB, text/plain)
2012-04-27 14:19 EDT, wes hayutin
no flags Details
proposed patch (824 bytes, patch)
2012-05-16 10:46 EDT, wes hayutin
no flags Details | Diff
Disproving screen log (3.88 KB, text/plain)
2012-08-02 07:07 EDT, mkovacik
no flags Details
Proposed patch to replace one occurance (1.32 KB, patch)
2013-02-05 05:26 EST, Vitaly Kuznetsov
no flags Details | Diff
Verification log (9.53 KB, text/plain)
2013-02-12 06:05 EST, Vitaly Kuznetsov
no flags Details

  None (edit)
Description mkovacik 2012-04-24 18:32:05 EDT
Created attachment 580019 [details]
Screen log

Description of problem:
A 2.0.1 deployment containing a custom repository protected by entitlement was updated to 2.0.3. Then client configuration rpm and appropriate entitlement was generated and applied to a client. Client node wasn't able to access the custom repository repomd.xml. Httpd logs on CDSes contained entitlement certificate error:

  [Wed Apr 25 00:00:15 2012] [error] [client] Certificate to verify:
  [Wed Apr 25 00:00:15 2012] [error] [client] \tsubject=</CN=Red Hat Update Infrastructure>, issuer=</C=US/ST=NC/L=Raleigh/CN=dhcp-31-147.brq.redhat.com CA>, subject.as_hash=<2273005625>, issuer.as_hash=<1749001108>, fingerprint=<9CB4C04547D34462E5CEF9BB3EFDC927>, serial=<262>, version=<2>, check_ca=<0>, notBefore=<Apr 24 21:45:49 2012 GMT>, notAfter=<Apr 24 21:45:49 2013 GMT>
  [Wed Apr 25 00:00:15 2012] [error] [client] Using a CA Chain with 1 cert(s)
  [Wed Apr 25 00:00:15 2012] [error] [client] \tCA: subject=</C=US/ST=NC/L=Raleigh/CN=dhcp-31-147.brq.redhat.com CA>, issuer=</C=US/ST=NC/L=Raleigh/CN=dhcp-31-147.brq.redhat.com CA>, subject.as_hash=<1749001108>, issuer.as_hash=<1749001108>, fingerprint=<23B67DAEE91FFF63F3BC3BC8B931EAB8>, serial=<14139470956909992290>, version=<2>, check_ca=<1>, notBefore=<Apr 16 14:08:42 2012 GMT>, notAfter=<Apr 16 14:08:42 2013 GMT>
  [Wed Apr 25 00:00:15 2012] [error] [client] Using a CRL Stack with 0 CRL(s)Client certificate did not match the repo consumer CA certificate
  [Wed Apr 25 00:00:15 2012] [error] [client] user /CN=Red Hat Update Infrastructure: authentication failure for "/pulp/repos//gkrellm/x86_64/repodata/repomd.xml": Password Mismatch

Version-Release number of selected component (if applicable):
2.0.1-->2.0.3 upgrade; RHEL-6.2-RHUI-2.0.3-20120416.0-Server-x86_64-DVD1.iso

How reproducible:
1 of 1

Steps to Reproduce:
1. deploy 2.0.1 RHUI
2. create custom repository protected by entitlement, make sure it is accessible by client
3. upgrade to 2.0.3
4. generate fresh client entitlements for the custom repository and generate appropriate configuration rpm
5. having applied fresh configuration rpm, client can't access the custom repository 
Actual results:
Having upgraded from 2.0.1 to 2.0.3, error accessing custom repository

Expected results:
Accessing custom repositories should work having performed an upgrade

Additional info:
Comment 1 mkovacik 2012-04-24 18:35:54 EDT
Created attachment 580020 [details]
rhua pulp client log
Comment 2 mkovacik 2012-04-24 18:36:54 EDT
Created attachment 580021 [details]
cds httpd ssl access log
Comment 3 mkovacik 2012-04-24 18:37:25 EDT
Created attachment 580022 [details]
cds httpd ssl error log
Comment 4 wes hayutin 2012-04-26 08:52:27 EDT
any updates on a recreate?
Comment 5 wes hayutin 2012-04-27 12:59:06 EDT
The issue was found in 2.0.1, I suspect it has to do w/ how the repopath is define d by the user. With the help of jmatthews, I noticed that the repo path had x86_64 in the path name, but not quite were it should be..

       removes stored authentication credentials and exits

   <   move to the previous screen
   ^, home
       move to the home screen
   /, clear
       clears the screen
   ?, help
       display help
   q, quit, exit

                                         Connected: dhcp-31-161.brq.redhat.com
rhui (repo) => c

Unique ID for the custom repository (alphanumerics, _, and - only):

Display name for the custom repository [protected_x68_64]:

Path at which the repository will be served [protected_x68_64]:

Algorithm to use when calculating the checksum values for repository metadata:
  1  - sha256
  2  - sha1
Enter value (1-2) or 'b' to abort: 1

Should the repository require an entitlement certificate to access? (y/n)

Based on the repository's relative path, the suggested entitlement path is:

Path that should be used when granting an entitlement for this repository. This
may use yum variable substitutions (e.g. $basearch) to group this together with
other repositories that share the entitlement [protected_$basearch/$basearch]:

NOTICE.. if you include the key word x86_64 or i386 in the path.. it will get translated to $basearch when the entitlement is define 

Path at which the repository will be served [protected_x68_64]:


I don't ** think ** the yum plugin w/ translate the first x86_64.. not sure yet
Comment 6 wes hayutin 2012-04-27 14:19:18 EDT
Created attachment 580826 [details]
protected custom repo's working

In this txt file you will see the entitlement cert on the server and client.  The cert contains custom protected repo's and the content is available to the clients.

I also used x86_64 in the path of the repo, but not the name and it worked fine.

I suspect the issues were caused in both 2.0.1 and 2.0.3 by the name and patch convention you used.  The regex that changes x86_64 will change it through out the path not just the last dir of the path.
Comment 7 wes hayutin 2012-04-27 14:24:03 EDT
I was able to recreate the same issue by creating a custom protected repo using the path in https://bugzilla.redhat.com/show_bug.cgi?id=815975#c5.  

We should probably change this bug to fix the regex that changes x86_64/i386 to only change in the last part of the path so "[protected_$basearch/$basearch]:" can not happen.
Comment 8 wes hayutin 2012-04-27 14:24:18 EDT
flipping to 2.1
Comment 9 mkovacik 2012-05-02 04:01:26 EDT
Just a note: in the original report, the path was: gkrellm/x86_64 and repo ID gkrellm-x86_64 i.e. there was only one spot for the regex to fire. If there are other requirements for the path/repo ID shape, they should be checked and documented properly.
Comment 10 James Slagle 2012-05-08 15:06:59 EDT
we need to make sure to add a unit test for this
Comment 11 wes hayutin 2012-05-16 10:46:35 EDT
Created attachment 584992 [details]
proposed patch
Comment 12 wes hayutin 2012-05-18 14:59:08 EDT
cloude commit 4cb387a93d1789d111545e4964d61d849e7f7b81
Comment 13 mkovacik 2012-08-02 07:07:09 EDT
Created attachment 601923 [details]
Disproving screen log

It is still possible to fool with the educated guess of $basearch selection; e.g. these paths failed to be guessed correctly: x86_64/custom/i386 and custom/i386/x86_64. Looking at the patch I think only the last x86_64 or i386 should match when deciding the $basearch part of the path so this looks like a failure. See the screen log attached.

- rh-rhui-tools: 2.0.68
- build: RHEL-6.3-RHUI-2.1-20120705.0-Server-x86_64-DVD1.iso

Status -> ON_DEV
Comment 14 wes hayutin 2012-08-02 10:02:29 EDT
<slagle> not sure. that's what i was getting at that it might break
<weshay> the example is /path/i386/x86_64/content
<slagle> probably just straight string substitution
<slagle> thing is, the entitlement path is a suggestion, they can override it
<weshay> right..
<weshay> so maybe if both are detected we can warn? 
<slagle> so if they want to do somethign funky like that, the suggestion might not look right, but if they correct it, it would work fine
<weshay> right
<slagle> weshay: i think a warning would be fine, but that would need to be in 2.1.1
<weshay> slagle, so.. https://bugzilla.redhat.com/show_bug.cgi?id=815975  was failed do to that issue..
<weshay> should we push it to 2.1.1
<weshay> pretty simple just to warn the user
<slagle> weshay: i'm not sure about a warning tbh. what would it say?
<slagle> warning: don't follow our suggestion
<slagle> it's up to them to choose the right path.  with the examples from the bz, we don't really have any idea what they meant
<weshay> slagle, something like... "path contains both the i386 and x86_64 key words, which is not recommended"
<weshay> the other option is just to close the issue.. 
<weshay> I'm ok w/ either really
<slagle> i'm leaning towards leaving it for now, and finding a better solution for 2.1.1
<weshay> k.. I'll push the bug to 2.1.1
Comment 15 James Slagle 2013-01-11 07:39:48 EST
I actually don't like the idea of trying to guess what the user meant in this case.  We propose a path for the common case when one arch is specified, and this covers 99% of what most people would do.

If they have a path with > 2 arch's they're obviously trying to imply something, but I don't like guessing that maybe they want the first one to be $basearch, or the last one, or the middle one, etc.  So, in this case, I updated the code to not show a suggested entitlement path any different than what they've already entered.

committed to cloude 94b5ecaf49fe8759cb061d58a94abef6cb238ee5
Comment 16 Vitaly Kuznetsov 2013-02-05 05:24:47 EST
Providing something like /i386/i386 leads to the same problem:

rhui (repo) => c

Unique ID for the custom repository (alphanumerics, _, and - only):

Only alphanumerics, underscore (_), and hyphen (-) are valid in a repository ID.

Unique ID for the custom repository (alphanumerics, _, and - only):

Display name for the custom repository [custom-i386-i386]:

Path at which the repository will be served [custom-i386-i386]:


Based on the repository's relative path, the suggested entitlement path is:


I'll attach a simple patch to replace one and only one arch occurance.
Comment 17 Vitaly Kuznetsov 2013-02-05 05:26:09 EST
Created attachment 693298 [details]
Proposed patch to replace one occurance
Comment 18 James Slagle 2013-02-06 08:48:14 EST
I was only thinking of 2 different arch's being a problem, so thanks for pointing this out.  

I applied your patch, committed to cloude:

I'll move this to ON_QA once we get a new iso build out.
Comment 19 Vitaly Kuznetsov 2013-02-12 06:05:36 EST
Created attachment 696464 [details]
Verification log
Comment 20 Vitaly Kuznetsov 2013-02-12 06:07:37 EST
Verified in
# rpm -q rh-rhui-tools
Comment 22 errata-xmlrpc 2013-02-27 11:59:02 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.