Bug 825028 - Service lookups by port number doesn't work on s390x/ppc64 arches
Summary: Service lookups by port number doesn't work on s390x/ppc64 arches
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks: 826592
TreeView+ depends on / blocked
 
Reported: 2012-05-24 20:57 UTC by Kaushik Banerjee
Modified: 2020-05-02 16:53 UTC (History)
4 users (show)

Fixed In Version: sssd-1.8.0-32.el6
Doc Type: Bug Fix
Doc Text:
No documentation required
Clone Of:
Environment:
Last Closed: 2012-06-20 11:45:06 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Github SSSD sssd issues 2390 None None None 2020-05-02 16:53:59 UTC
Red Hat Product Errata RHBA-2012:0747 normal SHIPPED_LIVE sssd bug fix and enhancement update 2012-06-19 19:31:43 UTC

Description Kaushik Banerjee 2012-05-24 20:57:35 UTC
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 22:54:27 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1348

Comment 4 Stephen Gallagher 2012-05-25 12:53:46 UTC
Patch committed upstream.

Comment 7 Gowrishankar Rajaiyan 2012-05-29 17:10:59 UTC
# 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 17:26:19 UTC
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 06:55:57 UTC
#~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~#
[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 14:00:16 UTC
    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 11:45:06 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/RHBA-2012-0747.html


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