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 byte-swapped. Version-Release number of selected component (if applicable): nss_ldap-259-3.fc9.i386 openldap-servers-2.4.8-3.fc9.i386 How reproducible: Always Steps to Reproduce: 1. Set up an ldap server and enter a skeleton for /etc/services (i.e. via PADL tools) 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...
Wow, that looks.. so broken.
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?
It almost works: # getent services | grep some-service some-service 10000/tcp # getent services some-service some-service 4135/tcp
No wait, I'm wrong, it doesn't work at all. I cleared out my nscd cache and now both commands report '4135'.
(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.
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.
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?
"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.
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
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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!