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

Reply via email to