Description of problem: 4/9 build rhel 5 x86 Navigate to a package details page. Notice you can not see the sub items for Change Log and File List Click on Dependencies, now the two links appear. I *think* the two items should always be visible. recreated the issues while checking a few other packages like squid.. thanks
Page was converted from perl to java. Assume we forgot to update links/acls on the /rhn/software/packages/Details.do page vs old network/software/packages/details.pxt Should be easy to fix the links to display all 3 additional tabs and not just the # Dependencies sub tab. Cliff.
i looked at this before cperry assigned to jdobies. acls look ok in the navs on both perl/java stack. what is odd is after a restart or compile and restart the page displays ok. the package map that is returned by the java code does not have the archtype key in it for the refresh. the problem is either in the package acl handler or the code it calls.
commit a16f85fd6a4273cd1a4939660b9a65fe051ab455 tree 9475b6569e1a3a899095e8cdf06d65d5964415a2 ArchType.java ArchType needed a defined equals/hashCode method. Otherwise, the capability lookup by type was subject to object references and was non-deterministic.
Vader commit b58629a60a0d2432d1a72b5dc9967008a6242f5f tree 524286c26d57265391a10f00909f2070d2983847
not in the 422.2 build moving back to modified
Mass move to ON_QA for build on Apr 24.
same issue, may not have made it into the 4/24.1 build
fails.. not in 5/7.1 build
Master commit 3363f86e4acadcbbaedadc4e5f8076fb29aa27de tree 19d1435af088a67ded5c189d488e01f9c44352ef Vader commit 39143ce1015882ff163a16f1a62fffa8c675a09c tree f14f924ceef40ba99d38555136517ccc74da6c80 java/code/src/com/redhat/rhn/common/security/acl/PackageAclHandler.java java/code/src/com/redhat/rhn/domain/common/ArchType.java This only seems to occur on the first run of a new ISO installation. I temporarily increased the logging on why the ACL fails so we capture as much as possible on the rare occasion it fails. Will remove the logging (it's annoyingly chatty) after the next QA build.
Pitching back to QA. I've installed the latest ISO (May 29) twice locally and have not been able to reproduce it. I also asked jsherrill to give me a second pair of eyes on the code to see if we could find any issues, but everything looked good. I'm wondering if the equals/hashCode changes from above for some reason weren't in the last QA build this was found on. If you come across this again, please let me know as soon as you see it so I can take a look at the increased logging on the server.
lol... finally working in 5/29 ;)
broken again in 6/12.1
Master commit 3bb101ec6b46754611762c302647817cb3c105a5 tree 66152108cdcca065b51adf5aa0f07b8d277b7d0e Vader commit 273bb0b0e9439a8e3e54bc8a62842ea6843d12db tree 0de8d1f8b7aa0499b0bf7e574d1c737336843211 java/code/src/com/redhat/rhn/common/security/acl/PackageAclHandler.java java/code/src/com/redhat/rhn/domain/rhnpackage/PackageFactory.java Analysis: These links aren't being displayed because the PackageAclHandler.aclPackageTypeCapable method is returning false when checking the ACL for the pages. This method will return false under the following conditions: - The ACL does not provide any parameters. Those are defined in a static XML file that was double-checked to make sure the parameters exist. If this was the case, I doubt we'd see the non-deterministic nature of this bug. - Any of the user, pid, or package retrieved from the DB was null. We wouldn't see the page at all if the user was null. We wouldn't see the package details if the PID or package was null. So I'm pretty confident this isn't the issue. - The capability listing for the package's architecture is null. This is where I suspect the issue is, so more on this later. - The capability listing for the architecture is retrieved but does not contain the ACL parameter in question. The entries in the capability listings are hard coded in the Java code, so if these were wrong I doubt we'd see the non-deterministic nature of this bug. Given the above, I'm leaning towards the issue being in the retrieval of the capability listings for the given package architecture. These listings are returned in a map, where the key used to be (before this commit) the ArchType object itself. Previous attempts to fix this were to introduce the equals/hashCode method to this class, without which that retrieval by object is not guaranteed to be consistent. The lack of these methods was definitely a bug. Looking further, when the capability map is created the ArchType objects being used as the keys are read from the database and held as static final objects in the PackageFactory class (the point being, they are loaded when the class itself is loaded). While in theory this should work, I have reservations about combining a hibernate retrieval with static constants in this manner. Further investigation showed this retrieval isn't actually needed. The objects are being retrieved by the arch label which is hard coded in the PackageFactory class. Since this label is available at ACL checking time, the simpler approach is to use the label directly in the capability map. This avoids the initial DB hit to load and cache the ArchType objects (not that the queries were painful) but also makes the map retrieval simpler by simply using strings. I'm not 100% certain this will fix the bug. However, it does remove one of the more potentially fragile areas of this flow (the database call) and simplifies the map lookup. While I was in there, I changed the capability map to return sets instead of lists for the capabilities for a (very) minimal performance increase (and to feed my compulsion, a list just felt wrong there). If this fails again in a future build, please let me know the machine as soon as possible, since restarting the Satellite server seems to make the issue go away and it's getting hard to have any solid time on a box that manifests the bug.
SUCCESS.. looks good :) 6/19 build
Verified in stage -> RELEASE_PENDING
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html