Bug 867029 - Update to the latest Essex stable release 2012.1.3
Summary: Update to the latest Essex stable release 2012.1.3
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone
Version: 1.0 (Essex)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: Alan Pevec
QA Contact: Jaroslav Henner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-10-16 15:08 UTC by Alan Pevec
Modified: 2022-07-09 05:52 UTC (History)
1 user (show)

Fixed In Version: openstack-keystone-2012.1.3-1.el6
Doc Type: Rebase: Bug Fixes and Enhancements
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-12-10 21:03:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker OSP-16323 0 None None None 2022-07-09 05:52:27 UTC
Red Hat Product Errata RHSA-2012:1556 0 normal SHIPPED_LIVE Moderate: openstack-keystone security, bug fix, and enhancement update 2012-12-11 02:00:40 UTC

Description Alan Pevec 2012-10-16 15:08:26 UTC
Last official stable/essex release 2012.1.3 is available, which contains, in addition to security fixes already included in openstack-keystone-2012.1.2-4, following bugfixes:

* return roles from authenticate in ldap backend (lp#1035428)
* utf-8 encode user keys in memcache (lp#1056373)

Comment 2 Jaroslav Henner 2012-10-23 11:50:48 UTC
lp#1056373 
keystone user-role-add --user 'e279fc407631463399c5b87efda602e4' --role 0a2dc9d4a87d487b8edb97450fe26af5 --tenant 625c84d3fad745c785f1ab64fdc45047

returned nothing, user got added, however what I would expect is that following should work:

 keystone user-role-add --user 'Příliž luťoučký kůň zahýkal' --role admin --tenant admin
'ascii' codec can't decode byte 0xc5 in position 22: ordinal not in range(128)

but this is another story -- it accepts ids instead of names, as option-names would suggest.

Comment 3 Jaroslav Henner 2012-10-23 12:18:16 UTC
I ran our tests with this. No regressions found.

Comment 4 Alan Pevec 2012-10-23 14:21:06 UTC
(In reply to comment #2)
> but this is another story -- it accepts ids instead of names, as
> option-names would suggest.

Yeah, during the Folsom cycle, all parameter names were renamed to include -id to make this clear:
usage: keystone user-role-add --user-id <user-id> --role-id <role-id>
                              [--tenant-id <tenant-id>]

BTW this breaks old scripts, so it's one of the things for the E->F upgrade notes.

Comment 5 Jaroslav Henner 2012-10-25 10:30:43 UTC
Atilla Fazekasz was verifying the LDAP&roles bug. It is working -- roles are in the response to POST for the token, but he had other problems:

# 1. email - default email attribute instead of the standard mail
# 2. without specifieing the *_tree_dn , it concretenesses in the wrong order
# 3. tenantId is not the member of either  ['person', 'inetOrgPerson']
# 4. "enabled" is not the member of the groupOfObjects Class

IMHO we can let this proceed to VERIFIED and raise other bugs about the other problems.

Comment 7 errata-xmlrpc 2012-12-10 21:03:02 UTC
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/RHSA-2012-1556.html


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