Bug 825028 - Service lookups by port number doesn't work on s390x/ppc64 arches
Service lookups by port number doesn't work on s390x/ppc64 arches
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Stephen Gallagher
IDM QE LIST
:
Depends On:
Blocks: 826592
  Show dependency treegraph
 
Reported: 2012-05-24 16:57 EDT by Kaushik Banerjee
Modified: 2012-06-20 07:45 EDT (History)
4 users (show)

See Also:
Fixed In Version: sssd-1.8.0-32.el6
Doc Type: Bug Fix
Doc Text:
No documentation required
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 07:45:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kaushik Banerjee 2012-05-24 16:57:35 EDT
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!
Comment 3 Dmitri Pal 2012-05-24 18:54:27 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1348
Comment 4 Stephen Gallagher 2012-05-25 08:53:46 EDT
Patch committed upstream.
Comment 7 Gowrishankar Rajaiyan 2012-05-29 13:10:59 EDT
# 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
Comment 8 Stephen Gallagher 2012-05-29 13:26:19 EDT
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.
Comment 9 Gowrishankar Rajaiyan 2012-05-30 02:55:57 EDT
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
[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
Comment 10 Stephen Gallagher 2012-06-12 10:00:16 EDT
    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
Comment 12 errata-xmlrpc 2012-06-20 07:45:06 EDT
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

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