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 10.34.31.144] Certificate to verify: [Wed Apr 25 00:00:15 2012] [error] [client 10.34.31.144] \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 10.34.31.144] Using a CA Chain with 1 cert(s) [Wed Apr 25 00:00:15 2012] [error] [client 10.34.31.144] \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 10.34.31.144] 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 10.34.31.144] 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:
Created attachment 580020 [details] rhua pulp client log
Created attachment 580021 [details] cds httpd ssl access log
Created attachment 580022 [details] cds httpd ssl error log
any updates on a recreate?
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.. logout 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 exit Connected: dhcp-31-161.brq.redhat.com ------------------------------------------------------------------------------ rhui (repo) => c Unique ID for the custom repository (alphanumerics, _, and - only): protected_x68_64 Display name for the custom repository [protected_x68_64]: Path at which the repository will be served [protected_x68_64]: protected_x86_64/x86_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) y Based on the repository's relative path, the suggested entitlement path is: protected_$basearch/$basearch 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]: protected_x86_64/x86_64 **** [protected_$basearch/$basearch]: I don't ** think ** the yum plugin w/ translate the first x86_64.. not sure yet
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.
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.
flipping to 2.1
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.
we need to make sure to add a unit test for this
Created attachment 584992 [details] proposed patch
cloude commit 4cb387a93d1789d111545e4964d61d849e7f7b81
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. Version - rh-rhui-tools: 2.0.68 - build: RHEL-6.3-RHUI-2.1-20120705.0-Server-x86_64-DVD1.iso Status -> ON_DEV
<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
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
Providing something like /i386/i386 leads to the same problem: rhui (repo) => c Unique ID for the custom repository (alphanumerics, _, and - only): custom/i386/i386 Only alphanumerics, underscore (_), and hyphen (-) are valid in a repository ID. Unique ID for the custom repository (alphanumerics, _, and - only): custom-i386-i386 Display name for the custom repository [custom-i386-i386]: Path at which the repository will be served [custom-i386-i386]: custom/i386/i386 ... Based on the repository's relative path, the suggested entitlement path is: custom/$basearch/$basearch ... I'll attach a simple patch to replace one and only one arch occurance.
Created attachment 693298 [details] Proposed patch to replace one occurance
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: 35e77160e81cc8f17fccca5a2598c8dbdba16b59 I'll move this to ON_QA once we get a new iso build out.
Created attachment 696464 [details] Verification log
Verified in # rpm -q rh-rhui-tools rh-rhui-tools-2.1.16-1.el6_3.noarch
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. http://rhn.redhat.com/errata/RHBA-2013-0571.html