From owner-freebsd-net@freebsd.org Tue Dec 15 15:28:18 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E5A6A43D79 for ; Tue, 15 Dec 2015 15:28:18 +0000 (UTC) (envelope-from jmc@cs.rit.edu) Received: from pony-express.cs.rit.edu (pony-express.cs.rit.edu [129.21.30.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2BC911077 for ; Tue, 15 Dec 2015 15:28:17 +0000 (UTC) (envelope-from jmc@cs.rit.edu) Received: (qmail 24859 invoked by uid 56003); 15 Dec 2015 15:28:10 -0000 Received: from 129.21.36.151 by pony-express (envelope-from , uid 20003) with qmail-scanner-1.25st (spamassassin: 3.3.2. perlscan: 1.25st. Clear:RC:1(129.21.36.151):SA:0(-1.0/4.5):. Processed in 0.665378 secs); 15 Dec 2015 15:28:10 -0000 X-Spam-Status: No, hits=-1.0 required=4.5 X-Spam-Report: SA TESTS -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Received: from starfury.cs.rit.edu (HELO starfury) (129.21.36.151) by mailhost.cs.rit.edu with ESMTPS (DHE-RSA-AES256-SHA encrypted); 15 Dec 2015 15:28:10 -0000 Date: Tue, 15 Dec 2015 10:28:10 -0500 (EST) From: James Craig To: Mark Johnston cc: freebsd-net@freebsd.org Subject: Re: Netgroups in FreeBSD10 In-Reply-To: <20151211193915.GC98922@wkstn-mjohnston.west.isilon.com> Message-ID: References: <20151210201621.GC34692@wkstn-mjohnston.west.isilon.com> <20151211193915.GC98922@wkstn-mjohnston.west.isilon.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2015 15:28:18 -0000 On Fri, 11 Dec 2015, Mark Johnston wrote: > On Fri, Dec 11, 2015 at 10:16:50AM -0500, James Craig wrote: >> On Thu, 10 Dec 2015, Mark Johnston wrote: >> >>> On Thu, Dec 10, 2015 at 10:58:11AM -0500, James Craig wrote: >>>> >>>> >>>> Hey all! >>>> >>>> I am migrating some of our services to freeBSD, and in the process of this, >>>> I have discovered something that seems odd to me; netgroups don't seem to work >>>> as expected. >>>> >>>> I am trying to set up a machine that will eventually be a file server >>>> (running 10.2-RELEASE) and getent netgroup doesn't return anything, >>>> even if it is a valid name. >>>> >>>> We have been using openldap, and on the old solaris server, I was able to >>>> query netgroups for information, and use netgroups to limit some access to NFS. >>>> >>>> getent passwd, and other lookups seem to work fine. >>>> >>>> >>>> I had truss running on the ldap server, and when I try to >>>> getent netgroup there is no action. So I ran a truss on the getent on >>>> the FreeBSD machine, and sifting through the system calls the system will only >>>> search the file /etc/netgroup (which is empty), despite that >>>> my /etc/nsswitch.conf looks like this: >>> >>> Unfortunately, the NSS documentation is wrong: the netgroup database isn't >>> implemented. The netgroup NSS methods always read /etc/netgroup and >>> ignore the sources configured in /etc/nsswitch.conf. >> >> I am glad I wasn't screwing up; thanks for the insight. >> >> Since this note I have also discovered that trying to use netgroups >> in login.access fails because I am not using NIS -- regardless of >> the /etc/netgroup file being populated. > > Yes, it looks like the system needs to belong to an NIS domain > containing the specified netgroups in order for login.access support to > work. > >> >> Is this something that will get implemented? (where would I go to >> find out?) > > It's not really clear what "this" is. :) > If you want to be able to specify an NIS domain in login.access, some > syntax for doing so would need to be proposed. A bugzilla PR would be > the way to do so: https://bugs.freebsd.org > > You can search for existing PRs to see if something similar has already > been submitted. > Sorry for not being clear. What 'this' is -- ultimately, is to be able to use netgroups. Right now I have netgroups populated in my openldap directory. Wherever I would use a netgroup, the nsswitch would direct the host to look it up through LDAP, and it would find it's answer there. I don't really want to create a NIS domain, I just want to the system to know that if it sees a reference to a netgroup it knows how to look it up -- for me, that's through the nsswitch.conf and an LDAP back end. I don't think there should be any syntax changes needed -- just the ability for the OS to look in LDAP for the information instead of a NIS domain or the /etc/netgroup file. >> >>> I have a libc patch (missing man page updates) that fixes this: >>> https://people.freebsd.org/~markj/patches/netgroup_nss.diff >>> It also adds a getnetgrent_r() implementation. If you're able to rebuild >>> libc in your environment, this patch should fix the problem you're >>> encountering - please let me know if it doesn't! >> >> I'll be honest; I have never done that before, so I am not sure >> what it will take, or what the ramifications on the system would >> be. >> >> I can look into it. (pointers would be appreciated, if there are any) > > I'll send some instructions in a separate mail. > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- James Craig, Department of Computer Science, RIT 102 Lomb Memorial Drive, Rochester, NY 14623 mailto:jmc@cs.rit.edu, voice: (585) 475-5254 CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.