Roderick Johnstone wrote: > On 29/01/15 21:43, Roderick Johnstone wrote: >> On 29/01/2015 17:32, Jakub Hrozek wrote: >>> On Wed, Jan 28, 2015 at 01:57:28PM +0000, Roderick Johnstone wrote: >>>> On 28/01/15 10:57, Jakub Hrozek wrote: >>>>> On Tue, Jan 27, 2015 at 10:03:37PM +0000, Roderick Johnstone wrote: >>>>>> Hi >>>>>> >>>>>> I'm migrating from a legacy NIS setup to ipa. I have a number of NIS >>>>>> netgroups (of hosts) that are being used to export (non-kerberos) >>>>>> nfs shares >>>>>> to which I would like to migrate to ipa. >>>>>> >>>>>> I've create a new netgroup in ipa (for testing) and added some >>>>>> hosts to it >>>>>> (using ipa netgroup-add and ipa netgroup-add-member). I'm hoping >>>>>> that when >>>>>> exporting an nfs share using the @netgroup syntax in /etc/exports >>>>>> that the >>>>>> netgroup will be looked up in ipa and the share will be exported to >>>>>> the >>>>>> hosts in the netgroup. >>>>>> >>>>>> /etc/nsswitch.conf has a line: >>>>>> netgroup: files nis sss >>>>>> >>>>>> /etc/exports has a line: >>>>>> /var/tmp/testexport @rmjnetgroup1(ro) >>>>>> >>>>>> I haven't, so far, been able to mount the exported share on a >>>>>> client so I'm >>>>>> wondering if this setup would be expected to work? >>>>>> >>>>>> What is confusing to me is that the section in the Redhat 6 Identity >>>>>> Management guide on netgroups also has information on running the NIS >>>>>> listener plugin so I'm wondering if perhaps this only works when >>>>>> running the >>>>>> nis listener. I'm trying to avoid that. >>>>>> >>>>>> I'd welcome any clarification on how to do non-kerberised nfs >>>>>> exports to >>>>>> groups of hosts. >>>>> >>>>> Does getent netgroup rmjnetgroup1 show the hosts you'd expect? >>>>> >>>> >>>> Indeed it does. >>>> >>>> The individual triples listed for the netgroup contain entries like: >>>> (host,-,domain) >>>> where host is a fully qualified hostname which is dns resolvable. >>>> >>>> (For info if I do ypcat on one of my NIS netgroups I get a triple >>>> like this: >>>> (host,,) >>>> where host is the fully qualified host name, and nothing in the domain >>>> field. >>>> >>>> I've actually tried two netgroups with different domains set. The >>>> first one >>>> (rmjnetgroup) I made without specifying the --nisdomain option to ipa >>>> netgroup-add and domain in the output above shows as my dns domain >>>> (which is >>>> a lower case version of my kerberos realm). >>>> >>>> I couldn't mount nfs shares when exporting to @rmjnetgroup. I checked >>>> that I >>>> could mount the shares when I exported explicitly to the fully >>>> qualified >>>> host name, and that worked ok. >>>> >>>> So, thinking that the problem was with the domain name I made a new >>>> netgroup >>>> (rmjnetgroup1) with the option --nisdomain=xxx where xxx is the >>>> proper name >>>> for our nis domain as shown with the domainname command. >>>> >>>> I couldn't mount nfs shares when exporting to @rmjnetgroup1 either. >>>> >>>> Roderick >>> >>> Thank you for your reply, then we know the SSSD's netgroup handling is >>> correct. To be honest, we're getting a bit out of my comfort zone into >>> the NFS area. >>> >>> Maybe Roland (CC) knows how to debug the issue further? >>> >> >> Thanks for your interest Jakub. >> > > Just to round this thread out I did get the exporting to netgroups > defined in ipa working. My problems were, I think, related to reverse > name lookups resolving to short hostnames coming from /etc/hosts rather > than FQDN names that were being used in /etc/exports (as well as some > other things). > > Interestingly, the setting of the nis domain name by the domainname > command on the nfs server doesn't seem to have to match the nisdomain > setting for the netgroup for the export to work. > > In further testing using a netgroup in /etc/hosts.allow to control ssh > access like this: > sshd : @rmjnetgroup : ALLOW > ALL : ALL : DENY > > it seems that the nis domain name set with the domainname command must > match the nis domain set in the netgroup in IdM or else access is not > allowed. > > Hoping this might be of use to someone else one day. > > Roderick >
Great news, thanks for the follow-up. Note that our preferred way of managing access to services is using HBAC. You get a centralized solution rather than having to modify each system (if they're running sssd of course). rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
