Bug 1112702
| Summary: | Broken dereference control with the FreeIPA 4.0 ACIs | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Martin Kosek <mkosek> | |
| Component: | 389-ds-base | Assignee: | Noriko Hosoi <nhosoi> | |
| Status: | CLOSED ERRATA | QA Contact: | Sankar Ramalingam <sramling> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | high | |||
| Version: | 6.6 | CC: | dpal, jgalipea, jhrozek, lkrispen, mkosek, nhosoi, nkinder, rcritten, rmeggins, spoore, tlavigne | |
| Target Milestone: | rc | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | 389-ds-base-1.2.11.15-45.el6 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | 1112698 | |||
| : | 1112824 1140888 (view as bug list) | Environment: | ||
| Last Closed: | 2014-10-14 07:56:19 UTC | Type: | --- | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | 1112698 | |||
| Bug Blocks: | 990143, 1109379, 1112824 | |||
|
Description
Martin Kosek
2014-06-24 13:56:59 UTC
This bug is a high priority for IPA as without it, users would have an outage when migrating from RHEL-6 to RHEL-7.1 and still having clients connected to RHEL-6.6 IPA master. Upstream ticket: https://fedorahosted.org/389/ticket/47825 Hi Martin, The problem is in RHEL-6.x (389-ds-base-1.2.11.X) or RHEL-7.0 (389-ds-base-1.3.1.X)? It'd affect the target flag of this bug... Flags: mkosek: rhel-6.6.0 Thanks, --noriko (In reply to Noriko Hosoi from comment #3) > Hi Martin, > > The problem is in RHEL-6.x (389-ds-base-1.2.11.X) or RHEL-7.0 > (389-ds-base-1.3.1.X)? > > It'd affect the target flag of this bug... > Flags: > mkosek: rhel-6.6.0 > > Thanks, > --noriko Never mind. Nathan gave me a clear explanation. We need to have this fix on all the supported version (1.2.11 and up) And Ludwig is already working on this issue. Was this issue found after failure of ssh? We're discussing where to automate testing for this one. With ssh tests? General install tests? Or, can it cause even more widespread issues? that could affect many different functions other than just login? When the issue was occurring, I reproduced it with ssh tests, sudo tests and with the ldapsearch mentioned in the Description. The ldapsearch seems as the most straightforward test to do as "ssh" test is more functional and could be broken by many others things but this particular bug. Also CCing Jakub in case he has other ideas for reproduction. SSSD uses dereference for fetching group members in one go and for HBAC. So anything that exercises HBAC (any login with a PAM service pretty much) should test the dereference code. Ok, so sounds like this one affects a lot. I think I'm missing something though for how to reproduce this. I tried installing older version of ipa and 389-ds-base: ipa-server-3.0.0-41.el6.x86_64 389-ds-base-1.2.11.15-36.el6.x86_64 But when I try to lookup the master, I'm seeing expected, not failure (I think): ldapsearch -Y GSSAPI -h $MASTER -b "fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test" -E 'deref=managedBy:objectclass' ... dn: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example, dc=test control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEOMIQAAAEIBAltYW5hZ2VkQnkEUWZxZ G49bWFzdGVyLmlwYTEuZXhhbXBsZS50ZXN0LGNuPWNvbXB1dGVycyxjbj1hY2NvdW50cyxkYz1pcG ExLGRjPWV4YW1wbGUsZGM9dGVzdKCEAAAApDCEAAAAngQLb2JqZWN0Y2xhc3MxhAAAAIsEA3RvcAQ JaXBhb2JqZWN0BAZuc2hvc3QEB2lwYWhvc3QECmlwYXNlcnZpY2UEB3BraXVzZXIED2tyYnByaW5j aXBhbGF1eAQMa3JicHJpbmNpcGFsBBJrcmJ0aWNrZXRwb2xpY3lhdXgECmlwYXNzaGhvc3QEFGlwY VNzaEdyb3VwT2ZQdWJLZXlz # managedBy: <objectclass=top>;<objectclass=ipaobject>;<objectclass=nshost>;< objectclass=ipahost>;<objectclass=ipaservice>;<objectclass=pkiuser>;<objectc lass=krbprincipalaux>;<objectclass=krbprincipal>;<objectclass=krbticketpolic yaux>;<objectclass=ipasshhost>;<objectclass=ipaSshGroupOfPubKeys>;fqdn=maste r.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test I even tried installing a separate client in case this didn't affect master: dn: fqdn=client1.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example ,dc=test control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEKMIQAAAEEBAltYW5hZ2VkQnkEUmZxZ G49Y2xpZW50MS5pcGExLmV4YW1wbGUudGVzdCxjbj1jb21wdXRlcnMsY249YWNjb3VudHMsZGM9aX BhMSxkYz1leGFtcGxlLGRjPXRlc3SghAAAAJ8whAAAAJkEC29iamVjdGNsYXNzMYQAAACGBAlpcGF vYmplY3QEBm5zaG9zdAQHaXBhaG9zdAQHcGtpdXNlcgQKaXBhc2VydmljZQQPa3JicHJpbmNpcGFs YXV4BAxrcmJwcmluY2lwYWwEDWllZWU4MDJkZXZpY2UECmlwYXNzaGhvc3QEA3RvcAQUaXBhU3NoR 3JvdXBPZlB1YktleXM= # managedBy: <objectclass=ipaobject>;<objectclass=nshost>;<objectclass=ipahos t>;<objectclass=pkiuser>;<objectclass=ipaservice>;<objectclass=krbprincipala ux>;<objectclass=krbprincipal>;<objectclass=ieee802device>;<objectclass=ipas shhost>;<objectclass=top>;<objectclass=ipaSshGroupOfPubKeys>;fqdn=client1.ip a1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test Is there something else I need to do in order for the ldapsearch to show the failure? the problem became only visible in recent version of IPA where new acis were introduced. The problem is triggered if access to the managedby attribute is granted by an aci containing a targetfilter rule How can I confirm those acis are or aren't in place? And, can I manually add one to test with? Should I be able to add the aci with ipa permission-add command? Do we have an example I could use for that? Thanks, Scott No, this depends on a permission/ACI refactoring done in FreeIPA 4.0 (http://www.freeipa.org/page/V4/Permissions_V2). I think the easiest way is to: 1) Install RHEL-6.6 IPA server 2) Install FreeIPA 4.0 replica (http://www.freeipa.org/page/Releases/4.0.0) 3) Test that the deref LDAP works or do functional tests as advised in Comment 7 and Comment 8 Alternatively, you could verify this as sanity only and only verify that current deref LDAP searches are not broken. Ok, great. I've been able to reproduce with RHEL 6.5 master and Fedora 20 replica running freeipa 4.0.1. With 389-ds-base-1.2.11.15-29.el6.x86_64: [root@rhel6-1 ~]# ldapsearch -Y GSSAPI -h $MASTER -b "fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test" -E 'deref=managedBy:objectclass' SASL/GSSAPI authentication started SASL username: host/master.ipa1.example.test.TEST SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test> with scope subtree # filter: (objectclass=*) # requesting: ALL # with dereference control # # master.ipa1.example.test, computers, accounts, ipa1.example.test dn: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example, dc=test control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAABkMIQAAABeBAltYW5hZ2VkQnkEUWZxZ G49bWFzdGVyLmlwYTEuZXhhbXBsZS50ZXN0LGNuPWNvbXB1dGVycyxjbj1hY2NvdW50cyxkYz1pcG ExLGRjPWV4YW1wbGUsZGM9dGVzdA== # managedBy: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,d c=example,dc=test So, I'll update and verify. Thanks for the help here. Verified.
Version ::
389-ds-base-1.2.11.15-38.el6.x86_64
Results ::
[root@rhel6-1 ~]# yum update 389-ds-base
Loaded plugins: product-id, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package 389-ds-base.x86_64 0:1.2.11.15-29.el6 will be updated
---> Package 389-ds-base.x86_64 0:1.2.11.15-38.el6 will be an update
--> Processing Dependency: 389-ds-base-libs = 1.2.11.15-38.el6 for package: 389-ds-base-1.2.11.15-38.el6.x86_64
--> Running transaction check
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-29.el6 will be updated
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-38.el6 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
=======================================================================================================
Package Arch Version Repository Size
=======================================================================================================
Updating:
389-ds-base x86_64 1.2.11.15-38.el6 beaker-rhel-6.6-latest-server 1.5 M
Updating for dependencies:
389-ds-base-libs x86_64 1.2.11.15-38.el6 beaker-rhel-6.6-latest-server 414 k
Transaction Summary
=======================================================================================================
Upgrade 2 Package(s)
Total download size: 1.9 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): 389-ds-base-1.2.11.15-38.el6.x86_64.rpm | 1.5 MB 00:01
(2/2): 389-ds-base-libs-1.2.11.15-38.el6.x86_64.rpm | 414 kB 00:00
-------------------------------------------------------------------------------------------------------
Total 545 kB/s | 1.9 MB 00:03
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Updating : 389-ds-base-libs-1.2.11.15-38.el6.x86_64 1/4
Updating : 389-ds-base-1.2.11.15-38.el6.x86_64 2/4
Cleanup : 389-ds-base-1.2.11.15-29.el6.x86_64 3/4
Cleanup : 389-ds-base-libs-1.2.11.15-29.el6.x86_64 4/4
beaker-rhel-6.6-latest-server/productid | 1.6 kB 00:00
beaker-rhel65-server/productid | 1.7 kB 00:00
Verifying : 389-ds-base-libs-1.2.11.15-38.el6.x86_64 1/4
Verifying : 389-ds-base-1.2.11.15-38.el6.x86_64 2/4
Verifying : 389-ds-base-1.2.11.15-29.el6.x86_64 3/4
Verifying : 389-ds-base-libs-1.2.11.15-29.el6.x86_64 4/4
Updated:
389-ds-base.x86_64 0:1.2.11.15-38.el6
Dependency Updated:
389-ds-base-libs.x86_64 0:1.2.11.15-38.el6
Complete!
[root@rhel6-1 ~]# ipactl restart
Restarting Directory Service
Shutting down dirsrv:
IPA1-EXAMPLE-TEST... [ OK ]
PKI-IPA... [ OK ]
Starting dirsrv:
IPA1-EXAMPLE-TEST... [ OK ]
PKI-IPA... [ OK ]
Restarting KDC Service
Stopping Kerberos 5 KDC: [ OK ]
Starting Kerberos 5 KDC: [ OK ]
Restarting KPASSWD Service
Stopping Kerberos 5 Admin Server: [ OK ]
Starting Kerberos 5 Admin Server: [ OK ]
Restarting DNS Service
Stopping named: . [ OK ]
Starting named: [ OK ]
Restarting MEMCACHE Service
Stopping ipa_memcached: [ OK ]
Starting ipa_memcached: [ OK ]
Restarting HTTP Service
Stopping httpd: [ OK ]
Starting httpd: [ OK ]
Restarting CA Service
Stopping pki-ca: [ OK ]
Starting pki-ca: [ OK ]
[root@rhel6-1 ~]# ldapsearch -Y GSSAPI -h $MASTER -b "fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test" -E 'deref=managedBy:objectclass'
SASL/GSSAPI authentication started
SASL username: host/master.ipa1.example.test.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# with dereference control
#
# master.ipa1.example.test, computers, accounts, ipa1.example.test
dn: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,
dc=test
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEOMIQAAAEIBAltYW5hZ2VkQnkEUWZxZ
G49bWFzdGVyLmlwYTEuZXhhbXBsZS50ZXN0LGNuPWNvbXB1dGVycyxjbj1hY2NvdW50cyxkYz1pcG
ExLGRjPWV4YW1wbGUsZGM9dGVzdKCEAAAApDCEAAAAngQLb2JqZWN0Y2xhc3MxhAAAAIsEA3RvcAQ
JaXBhb2JqZWN0BAZuc2hvc3QEB2lwYWhvc3QECmlwYXNlcnZpY2UEB3BraXVzZXIED2tyYnByaW5j
aXBhbGF1eAQMa3JicHJpbmNpcGFsBBJrcmJ0aWNrZXRwb2xpY3lhdXgECmlwYXNzaGhvc3QEFGlwY
VNzaEdyb3VwT2ZQdWJLZXlz
# managedBy: <objectclass=top>;<objectclass=ipaobject>;<objectclass=nshost>;<
objectclass=ipahost>;<objectclass=ipaservice>;<objectclass=pkiuser>;<objectc
lass=krbprincipalaux>;<objectclass=krbprincipal>;<objectclass=krbticketpolic
yaux>;<objectclass=ipasshhost>;<objectclass=ipaSshGroupOfPubKeys>;fqdn=maste
r.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test
Unfortunately, SSSD team discovered that current deref fixes are not sufficient and SSSD will fail to enumerate groups with users having a special IPA RBAC role assigned. The root cause of the issue is that user contains some memberOf attributes to entries which are not visible to SSSD and DS returns incomplete results in the deref call. This problem makes SSSD to fail in resolving such user groups. We plan to solve this issue both on server side - in 389-ds-base component, i.e. this bug. Upstream tracks the problem in ticket https://fedorahosted.org/389/ticket/47885 This should be done for RHEL-6.6 as it is already a minimal IPA server version to use when RHEL-7.1 replica is being added due to this Bugzilla. Second part is a fix on SSSD client to be more robust in the deref call and fall back properly - tracked in Bug 1135432 targeted on later RHEL release. Moving this bug back to ASSIGNED so that we can add the additional fix so that RHEL clients can work with RHEL-6.6 servers replicating with RHEL-7.1 servers. Looks like newer build has come for 389-ds-base. I am not sure whether the same can be verified by DS QE team... Can this fix be verified by SSSD team? (In reply to Sankar Ramalingam from comment #23) > Looks like newer build has come for 389-ds-base. I am not sure whether the > same can be verified by DS QE team... Can this fix be verified by SSSD team? This fix for the ticket 47885 can be verified just on the directory server. Ludwig, could you please put the steps to verify? Thanks!! steps to verify 0. enabel deref and memberof plugin (use member as memberof attr) 1. create a suffix dc=example,dc=com 2. remove all acis 3, create a public and privaet subtree: dn: ou=public,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: public aci: (targetattr!="userPassword")(version 3.0; acl "Anonymous access"; allow (read,search,compare) userdn="ldap:///anyone";) dn: ou=private,dc=example,dc=com objectClass: organizationalUnit objectClass: top ou: private 4. add a public and private group dn: cn=g1,ou=private,dc=example,dc=com objectClass: groupofnames objectClass: top member: uid=user.9999,ou=People,dc=example,dc=com cn: g1 dn: cn=g1,ou=public,dc=example,dc=com member: uid=user.9999,ou=People,dc=example,dc=com objectClass: groupofnames objectClass: top cn: g1 5. do search with deref control as dirctory manager, you will get both groups: ldapsearch .....-D "cn=directory manager" -w ... -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" memberof dn: uid=user.9999,ou=People,dc=example,dc=com # memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=private,dc=example,dc=com # memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=example,dc=com memberof: cn=g1,ou=private,dc=example,dc=com memberof: cn=g1,ou=public,dc=example,dc=com 6. do the same search as an ordinary user, it should only deref the public group: ldapsearch -LLL -o ldif-wrap=no -x -h localhost -p 30522 -D "uid=user.9998,ou=People,dc=example,dc=com" -w password -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" memberof dn: uid=user.9999,ou=People,dc=example,dc=com # memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=example,dc=com memberof: cn=g1,ou=private,dc=example,dc=com memberof: cn=g1,ou=public,dc=example,dc=com Created ou, groups and users as given in comment #25. But, there are few modifications to be done to get the exact result. Step 0: use memberof as memberof attr in memberOf plug-in. Not member as memberof attr. Before doing step4, you need to create user.9999 dn: uid=user.9999,ou=public,dc=example3,dc=com telephoneNumber: 989898199 mail: user.9999 uid: user.9999 givenName: user.9999 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: inetUser sn: user.9999 cn: user.9999 userPassword: Secret123 Step 4: use public instead of people for member attr in private and public groups. dn: cn=g1,ou=private,dc=example,dc=com objectClass: groupofnames objectClass: top member: uid=user.9999,ou=public,dc=example,dc=com cn: g1 dn: cn=g1,ou=public,dc=example,dc=com member: uid=user.9999,ou=public,dc=example,dc=com objectClass: groupofnames objectClass: top cn: g1 Step 5: ldapsearch -x -p 1289 -h localhost -D "cn=Directory Manager" -w Secret123 -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" "# memberof:" Result: # user.9999, public, example.com dn: uid=user.9999,ou=public,dc=example,dc=com control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAADNMIQAAABhBAhtZW1iZXJvZgQjY249Z zEsb3U9cHJpdmF0ZSxkYz1leGFtcGxlMyxkYz1jb22ghAAAACwwhAAAACYEC29iamVjdGNsYXNzMY QAAAATBAxncm91cG9mbmFtZXMEA3RvcDCEAAAAYAQIbWVtYmVyb2YEImNuPWcxLG91PXB1YmxpYyx kYz1leGFtcGxlMyxkYz1jb22ghAAAACwwhAAAACYEC29iamVjdGNsYXNzMYQAAAATBAxncm91cG9m bmFtZXMEA3RvcA== # memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=private,dc= example,dc=com # memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=e xample,dc=com Step 6: Add user.9993 to ou=public as user.9999. Run ldapsearch as user.9993 ldapsearch -x -p 1289 -h localhost -D "uid=user.9993,ou=public,dc=example,dc=com" -w Secret123 -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" "deref=memberof:objectclass" "# memberof:" Result: # user.9999, public, example.com dn: uid=user.9999,ou=public,dc=example,dc=com control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAABmMIQAAABgBAhtZW1iZXJvZgQiY249Z zEsb3U9cHVibGljLGRjPWV4YW1wbGUzLGRjPWNvbaCEAAAALDCEAAAAJgQLb2JqZWN0Y2xhc3MxhA AAABMEDGdyb3Vwb2ZuYW1lcwQDdG9w # memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=e xample,dc=com Ldapsearch as normal user with deref control produces results only with public groups. Hence, marking the bug as verified. can I know the reason why it has been changed to POST? Is there anything changing from what I posted in the verification steps? (In reply to Sankar Ramalingam from comment #27) > can I know the reason why it has been changed to POST? Is there anything > changing from what I posted in the verification steps? Because of a regression by the ticket 47885, another build is coming including the fix. This final verification can be done by IPA, I think. Please see also https://bugzilla.redhat.com/show_bug.cgi?id=1139361 Bug 1139361 - RHEL6.6 ssh as admin on ipa server fails after 389-ds-base update Reopening due to regressions encountered (described in bug 1139361). *** Bug 1139361 has been marked as a duplicate of this bug. *** This version seems to fix my issue from bug #1139361 for ssh as admin: [root@rhel6-1 ~]# rpm -q 389-ds-base 389-ds-base-1.2.11.15-43.el6.x86_64 [root@rhel6-1 ~]# ssh admin@$(hostname) admin.test's password: Connection closed by UNKNOWN After upgade to release -45, it works: [root@rhel6-1 yum.local.d]# yum update 389-ds-base Loaded plugins: product-id, subscription-manager This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. Setting up Update Process mylocal | 2.9 kB 00:00 ... mylocal/primary_db | 36 kB 00:00 ... Resolving Dependencies --> Running transaction check ---> Package 389-ds-base.x86_64 0:1.2.11.15-44.el6 will be updated ---> Package 389-ds-base.x86_64 0:1.2.11.15-45.el6 will be an update --> Processing Dependency: 389-ds-base-libs = 1.2.11.15-45.el6 for package: 389-ds-base-1.2.11.15-45.el6.x86_64 --> Running transaction check ---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-44.el6 will be updated ---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-45.el6 will be an update --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Updating: 389-ds-base x86_64 1.2.11.15-45.el6 mylocal 1.5 M Updating for dependencies: 389-ds-base-libs x86_64 1.2.11.15-45.el6 mylocal 417 k Transaction Summary ======================================================================================================= Upgrade 2 Package(s) Total download size: 1.9 M Is this ok [y/N]: y Downloading Packages: ------------------------------------------------------------------------------------------------------- Total 102 MB/s | 1.9 MB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Updating : 389-ds-base-libs-1.2.11.15-45.el6.x86_64 1/4 Updating : 389-ds-base-1.2.11.15-45.el6.x86_64 2/4 Cleanup : 389-ds-base-1.2.11.15-44.el6.x86_64 3/4 Cleanup : 389-ds-base-libs-1.2.11.15-44.el6.x86_64 4/4 Verifying : 389-ds-base-1.2.11.15-45.el6.x86_64 1/4 Verifying : 389-ds-base-libs-1.2.11.15-45.el6.x86_64 2/4 Verifying : 389-ds-base-libs-1.2.11.15-44.el6.x86_64 3/4 Verifying : 389-ds-base-1.2.11.15-44.el6.x86_64 4/4 Updated: 389-ds-base.x86_64 0:1.2.11.15-45.el6 Dependency Updated: 389-ds-base-libs.x86_64 0:1.2.11.15-45.el6 Complete! [root@rhel6-1 yum.local.d]# ipactl restart Restarting Directory Service Shutting down dirsrv: PKI-IPA... [ OK ] TESTRELM-TEST... [ OK ] Starting dirsrv: PKI-IPA... [ OK ] TESTRELM-TEST... [ OK ] Restarting KDC Service Stopping Kerberos 5 KDC: [ OK ] Starting Kerberos 5 KDC: [ OK ] Restarting KPASSWD Service Stopping Kerberos 5 Admin Server: [ OK ] Starting Kerberos 5 Admin Server: [ OK ] Restarting DNS Service Stopping named: . [ OK ] Starting named: [ OK ] Restarting MEMCACHE Service Stopping ipa_memcached: [ OK ] Starting ipa_memcached: [ OK ] Restarting HTTP Service Stopping httpd: [ OK ] Starting httpd: [ OK ] Restarting CA Service Stopping pki-ca: [ OK ] Starting pki-ca: [ OK ] [root@rhel6-1 yum.local.d]# ssh admin@$(hostname) admin.test's password: Last login: Tue Sep 9 08:10:00 2014 from rhel6-1.testrelm.test Could not chdir to home directory /home/admin: No such file or directory -bash-4.1$ exit logout I'm still running other tests but, that issue does seem to be resolved. Thank you! Changing the status to ON_QA as per Noriko's comment #30. Based on comment #32, marking the bug as Verified. Thanks Scott! 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-2014-1385.html |