Bug 450634 - ipServicePort is byte-swapped in 'services' map
Summary: ipServicePort is byte-swapped in 'services' map
Alias: None
Product: Fedora
Classification: Fedora
Component: nss_ldap
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-10 01:14 UTC by Carl Roth
Modified: 2009-06-10 15:19 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-06-10 15:19:31 UTC
Type: ---

Attachments (Terms of Use)

Description Carl Roth 2008-06-10 01:14:58 UTC
Description of problem:

I tried to create a 'services' entry in my ldap server and I noticed that the
value reported by nss_ldap is wrong.  At least, I *think* this is an nss_ldap
issue; it could be an issue with an inter-related package.

In any case, I created the service entry using an LDIF file and 'ldapadd'.  The
returned value from nss_ldap looked like that the ipServicePort field was

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Set up an ldap server and enter a skeleton for /etc/services (i.e. via PADL
2. Create LDIF for a new service entry (see example included)
3. Add the entry with 'ldapadd'
4. Change the 'services' entry in /etc/nsswitch.conf to read 'files ldap'
5. Read back the entry with 'getent'
Actual results:

Expected results:

Additional info:

On my system, the base DN is 'dc=ursus,dc=net' and the services entries are
under 'ou=Services,dc=ursus,dc=net'.

Here is a sample LDIF file to add a new service:

  dn: cn=some-service,ou=Services,dc=ursus,dc=net
  objectClass: ipService
  objectClass: top
  ipServicePort: 10000
  ipServiceProtocol: tcp
  cn: some-service

I added the service as follows:

  # ldapadd -x -wMY-PASSWORD -D MY-ADMIN,dc=ursus,dc=net -f service.ldif

When I read out the service entry with 'ldapsearch' it looks fine:

  # ldapsearch ... 'ipServicePort=10000'

  # some-service, Services, ursus.net
  dn: cn=some-service,ou=Services,dc=ursus,dc=net
  objectClass: ipService
  objectClass: top
  ipServicePort: 10000
  ipServiceProtocol: tcp
  cn: some-service

Then when I retrieve the entry with 'getent':

  # getent services some-service
  some-service          4135/tcp

Note that 10000 == 0x2710, whereas 4135 == 0x1027...

Comment 1 Nalin Dahyabhai 2008-10-17 18:35:19 UTC
Wow, that looks.. so broken.

Comment 2 Nalin Dahyabhai 2008-10-17 20:43:00 UTC
It's broken, of course, because I botched a patch.  Does the package at http://koji.fedoraproject.org/koji/taskinfo?taskID=886788 fix it on your system?

Comment 3 Carl Roth 2008-10-17 21:30:49 UTC
It almost works:

  # getent services | grep some-service
  some-service          10000/tcp

  # getent services some-service
  some-service          4135/tcp

Comment 4 Carl Roth 2008-10-17 21:32:00 UTC
No wait, I'm wrong, it doesn't work at all.  I cleared out my nscd cache and now both commands report '4135'.

Comment 5 Carl Roth 2008-10-17 21:32:53 UTC
(In reply to comment #4)
> No wait, I'm wrong, it doesn't work at all.  I cleared out my nscd cache and
> now both commands report '4135'.

Ignore that comment.  Comment #3 still stands.

Comment 6 Nalin Dahyabhai 2008-10-29 19:39:18 UTC
You're sure the cache was cleared correctly?  How about if you temporarily stop nscd, and wipe the contents of /var/db/nscd?  I've got the 261-4 here, and I can look up entries which specify ports 22, 26000, and 10000 without problems, both as a group and individually, so I'm kind of at a loss here.

Comment 7 Carl Roth 2008-10-29 19:54:43 UTC
I tried the steps you suggested:

# service nscd stop
# rm /var/db/nscd/*
# service nscd start
# getent services some-service
some-service          10000/tcp

So it appears that nss_ldap is doing the right thing now.

Can some one explain to me why 'nscd -i' doesn't invalidate the cache like it's advertised to?

Comment 8 Nalin Dahyabhai 2008-10-29 19:59:59 UTC
"nscd -i services" seems to do the right thing on my development box.  After running that, does "nscd -g" indicate a "current number of cached values" for services that's other than zero?  If it does, that's got to be an nscd bug.

Comment 9 Fedora Update System 2009-01-29 23:00:53 UTC
nss_ldap-264-1.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update nss_ldap'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1075

Comment 10 Bug Zapper 2009-06-10 01:30:52 UTC
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 11 Nalin Dahyabhai 2009-06-10 15:19:31 UTC
Marking as closed, as this should have been fixed by versions 264-1.fc9 and 264-1.fc10.  If you find that you can still reproduce this bug after clearing nscd's caches and restarting it, please reopen the bug report.  Thanks!

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