Hide Forgot
Description of problem: Service lookups by port number doesn't work on s390x/ppc64 arches Version-Release number of selected component (if applicable): sssd-1.8.0-28.el6.ppc64 How reproducible: Always Steps to Reproduce: 1. Configure sssd as follows: # cat /etc/sssd/sssd.conf [sssd] config_file_version = 2 services = nss, pam domains = LDAP [nss] filter_groups = root filter_users = root debug_level=0xFFF0 [pam] [domain/LDAP] debug_level=0xFFF0 id_provider = ldap ldap_uri = ldap://openldapserv.example.com ldap_search_base = dc=example,dc=com 2. On ldap server, add a service as follows: # Svc5, Services, example.com dn: cn=Svc5,ou=Services,dc=example,dc=com objectClass: ipService cn: svc5_alias1 cn: SVC5_Alias2 cn: Svc5 ipServicePort: 12345 ipServiceProtocol: SCtp ipServiceProtocol: Dummy_proto5 3. Lookup service: # getent -s sss services Svc5 Svc5 12345/SCtp svc5_alias1 SVC5_Alias2 # getent -s sss services 12345/SCtp <== returns blank output # getent -s sss services 12345 <== returns blank output Actual results: Lookup of service by port number returns nothing. Expected results: Lookup of service by port number should work. Additional info: /var/log/sssd/sssd_nss.log shows: (Thu May 24 16:15:06 2012) [sssd[nss]] [get_client_cred] (0x4000): Client creds: euid[0] egid[0] pid[11554]. (Thu May 24 16:15:06 2012) [sssd[nss]] [accept_fd_handler] (0x0100): Client connected! (Thu May 24 16:15:06 2012) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Thu May 24 16:15:06 2012) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Thu May 24 16:15:06 2012) [sssd[nss]] [nss_cmd_getservbyport] (0x0400): Requesting info for service on port [0/<ANY>] (Thu May 24 16:15:06 2012) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/SERVICE/LDAP/0l:<ANY>] (Thu May 24 16:15:06 2012) [sssd[nss]] [getserv_send] (0x0400): Checking cache for [0:<ANY>@LDAP] (Thu May 24 16:15:06 2012) [sssd[nss]] [nss_cmd_getserv_done] (0x0040): getservbyname failed (Thu May 24 16:15:06 2012) [sssd[nss]] [client_recv] (0x0200): Client disconnected!
Upstream ticket: https://fedorahosted.org/sssd/ticket/1348
Patch committed upstream.
# named, Services, example.com dn: cn=named,ou=Services,dc=example,dc=com objectClass: ipService objectClass: top cn: Named_Alias cn: bind cn: named ipServicePort: 53 ipServiceProtocol: udp # ssh, Services, example.com dn: cn=ssh,ou=Services,dc=example,dc=com objectClass: ipService cn: ssh_alias1 cn: SSH_alias2 cn: ssh ipServicePort: 22 ipServiceProtocol: tcp # Svc5, Services, example.com dn: cn=Svc5,ou=Services,dc=example,dc=com objectClass: ipService cn: svc5_alias1 cn: SVC5_Alias2 cn: Svc5 ipServicePort: 12345 ipServiceProtocol: SCtp ipServiceProtocol: Dummy_proto5 [root@ibm-js22-04 ~]# getent -s sss services ssh ssh 22/tcp ssh_alias1 SSH_alias2 [root@ibm-js22-04 ~]# getent -s sss services 22/tcp ssh 22/tcp ssh_alias1 SSH_alias2 [root@ibm-js22-04 ~]# getent -s sss services 22 ssh 22/tcp ssh_alias1 SSH_alias2 [root@ibm-js22-04 ~]# [root@ibm-js22-04 ~]# ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb name=ssh asq: Unable to register control with rootdse! # record 1 dn: name=ssh,cn=services,cn=LDAP,cn=sysdb createTimestamp: 1338301618 name: ssh nameAlias: ssh_alias1 nameAlias: SSH_alias2 objectClass: service servicePort: 22 serviceProtocol: tcp lastUpdate: 1338301618 dataExpireTimestamp: 1338307018 distinguishedName: name=ssh,cn=services,cn=LDAP,cn=sysdb # returned 1 records # 1 entries # 0 referrals [root@ibm-js22-04 ~]# [root@ibm-js22-04 ~]# getent -s sss services named named 53/udp Named_Alias bind [root@ibm-js22-04 ~]# getent -s sss services 53 named 53/udp Named_Alias bind [root@ibm-js22-04 ~]# getent -s sss services 53/udp named 53/udp Named_Alias bind [root@ibm-js22-04 ~]# getent -s sss services 22 ssh 22/tcp ssh_alias1 SSH_alias2 [root@ibm-js22-04 ~]# getent -s sss services 22/tcp ssh 22/tcp ssh_alias1 SSH_alias2 [root@ibm-js22-04 ~]# [root@ibm-js22-04 ~]# getent -s sss services Svc5 Svc5 12345/SCtp svc5_alias1 SVC5_Alias2 [root@ibm-js22-04 ~]# getent -s sss services 12345/SCtp [root@ibm-js22-04 ~]# getent -s sss services 12345 [root@ibm-js22-04 ~]# getent -s sss services 22/tcp [root@ibm-js22-04 ~]# /var/log/sssd/sssd_nss.log: (Tue May 29 10:43:11 2012) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Tue May 29 10:43:11 2012) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Tue May 29 10:43:11 2012) [sssd[nss]] [nss_cmd_getservbyport] (0x0040): Could not parse request (Tue May 29 10:43:11 2012) [sssd[nss]] [client_recv] (0x0200): Client disconnected! Tested in version: sssd-1.8.0-31.el6.ppc64
The original fix made a mistake with processing the length of the packet, causing the 'protocol' field to be truncated. sssd-1.8.0-32.el6 corrects this mistake.
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# [root@ibm-z10-11 ~]# arch s390x [root@ibm-z10-11 ~]# [root@ibm-z10-11 ~]# getent -s sss services Svc5 Svc5 12345/SCtp svc5_alias1 SVC5_Alias2 [root@ibm-z10-11 ~]# getent -s sss services 12345 Svc5 12345/SCtp svc5_alias1 SVC5_Alias2 [root@ibm-z10-11 ~]# getent -s sss services 12345/SCtp Svc5 12345/SCtp svc5_alias1 SVC5_Alias2 [root@ibm-z10-11 ~]# [root@ibm-z10-11 ~]# getent -s sss services 22 ssh 22/tcp ssh_alias1 SSH_alias2 [root@ibm-z10-11 ~]# [root@ibm-z10-11 ~]# getent -s sss services 53/udp named 53/udp Named_Alias bind [root@ibm-z10-11 ~]# #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# [root@ibm-js22-04 ~]# arch ppc64 [root@ibm-js22-04 ~]# [root@ibm-js22-04 ~]# getent -s sss services Svc5 Svc5 12345/SCtp svc5_alias1 SVC5_Alias2 [root@ibm-js22-04 ~]# getent -s sss services 12345 Svc5 12345/SCtp svc5_alias1 SVC5_Alias2 [root@ibm-js22-04 ~]# getent -s sss services 12345/SCtp Svc5 12345/SCtp svc5_alias1 SVC5_Alias2 [root@ibm-js22-04 ~]# #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~# Verified in version: sssd-1.8.0-32.el6.ppc64 sssd-1.8.0-32.el6.s390x
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: No documentation required
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-2012-0747.html