Bug 645726 - nss_ldap fails to get netgroup from ldap
nss_ldap fails to get netgroup from ldap
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: nss_ldap (Show other bugs)
14
Unspecified Unspecified
low Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-22 06:05 EDT by David Jansen
Modified: 2012-08-16 15:36 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-16 15:36:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/etc/nss_ldap.conf (9.59 KB, text/plain)
2010-10-22 11:12 EDT, David Jansen
no flags Details

  None (edit)
Description David Jansen 2010-10-22 06:05:34 EDT
Description of problem:
We have a setup here where every fedora desktop system has a partion shared over nfs, giving access to machines in a certain netgroup, which is defined in ldap. 
Up to Fedora 12 and RHEL 5.5, it works to have
netgroup:   files ldap
in /etc/nsswitch.conf and the netgroup is automatically picked up and used.
Contents of /etc/exports:
/data1	@netname(rw,root_squash,sync,secure)

Now with Fedora 14 beta, the nfs share is not accessible from other computers, error is:
Oct 22 10:54:45 eendracht rpc.mountd[1354]: refused mount request from xx.xx.xx.xx for /data (/data): unmatched host
(where xx is ip address of nfs client attempting to acces the disk).

Temporary workaround: a small script which uses ldapsearch to retrieve the netgroup from ldap, and write it to /etc/netgroup . So that also shows, that netgroup support in the nfs server is not the issue, it must be something in nss_ldap that fails to read the netgroup and pass it on to programs that request it.
Apart from some sanity checking, my script does this to create the netgroup file:
ldapsearch -LLL -x 'cn=netname'|egrep '^cn:|^nisNetgroupTriple:' | awk -F: 'ORS=" " {print $2}'

Version-Release number of selected component (if applicable):
nss_ldap-265-6.fc14.i686
Comment 1 Nalin Dahyabhai 2010-10-22 10:30:38 EDT
Can you attach a copy of your /etc/ldap.conf?  I'm wondering if you're using TLS and are running into a problem stemming from the switch from OpenSSL to NSS for the crypto.
Comment 2 David Jansen 2010-10-22 11:12:42 EDT
Created attachment 455107 [details]
/etc/nss_ldap.conf

There is no /etc/ldap.conf. Do you mean /etc/nss_ldap.conf? I'll attatch that file, just to be sure.
Anyway, TLS is being used, and all other information from ldap is working (users, passwords, groups, automount info)
Comment 3 Nalin Dahyabhai 2010-10-22 11:52:22 EDT
(In reply to comment #2)
> Created attachment 455107 [details]
> /etc/nss_ldap.conf
> 
> There is no /etc/ldap.conf. Do you mean /etc/nss_ldap.conf? I'll attatch that
> file, just to be sure.

Yes, that's right.  I can't believe I forgot that I changed the name of the configuration file to remove that ambiguity.

> Anyway, TLS is being used, and all other information from ldap is working
> (users, passwords, groups, automount info)

TLS makes this sound vaguely like bug #636956, also in part because rpc.mountd uses fork().  Does the workaround from https://bugzilla.redhat.com/show_bug.cgi?id=636956#c36, made to the "nfs" init script, make a difference?
Comment 4 Dmitri Pal 2010-10-22 16:28:19 EDT
Also just FYI. SSSD has released 1.4 that will be available as a 0 day errata for F14 that will support netgroups. Would you mind considering it as an alternative to using nss_ldap in your deployment?
Comment 5 David Jansen 2010-10-25 08:56:00 EDT
The workaround in the nfs init script doesn't seem to make a difference. But if SSSD can do netgroups, that would be fine too.
Comment 6 Moritz Baumann 2010-10-31 05:32:00 EDT
I wasn't sure if its better to post here or to create a bug report against the rawhide package:

The field ldap_netgroup_search_base does not get evaluated.

in /etc/sssd/sssd.conf:
...
ldap_search_base = ou=isg,ou=inf,ou=auth,o=ethz,c=ch
ldap_netgroup_search_base = ou=netgroup,ou=inf,ou=auth,o=ethz,c=ch
...

and /var/log/sssd/sssd_D.ETHZ.CH.log shows after a "getent netgroup baumanmo":


(Sun Oct 31 10:25:14 2010) [sssd[be[D.ETHZ.CH]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(cn=baumanmo)(objectclass=nisNetgroup))][ou=isg,ou=inf,ou=auth,o=ethz,c=ch].


How to reproduce (was running on RHEL6 Beta 2 refresh):
   * rebuild ding-libs-0.1.2-3.fc15.src.rpm, sssd-1.4.0-2.fc15.src.rpm on system and install it.
   * configure sssd.conf with the lines above (+ have a otherwise running config)
   * in /etc/nsswitch.conf change settings to netgroup:  files sss
   * restart service sssd
   * do your netgroup query and watch how it uses ldap_search_base rather than ldap_netgroup_search_base.
Comment 7 Stephen Gallagher 2010-11-01 06:49:32 EDT
(In reply to comment #6)
> I wasn't sure if its better to post here or to create a bug report against the
> rawhide package:
> 

BZ #648150 is tracking this issue in SSSD.
Comment 8 Fedora End Of Life 2012-08-16 15:36:48 EDT
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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, you are encouraged to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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

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