On Nov 13, 2017, at 11:44 AM, Alexander Bokovoy <aboko...@redhat.com> wrote:
On ma, 13 marras 2017, Charles Hedrick wrote:
Sure. We use netgroups for /etc/exports. The most natural format for triples is
(host,,)
That’s the format Netapp documents. By default, ipa netgroup-add-member uses
(host,-,domain)
where domain seems to come from our Kerberos domain. Netapp
documentation requests leaving that field blank, though some
documentation suggests that if it’s filled in, they will ignore triples
where the domain doesn’t match the Netapp’s domain. We are no longer
using NIS, so as far as we know, the Netapp doesn’t have a NIS domain.
I think it’s safest to leave the field blank.
IPA sets NIS domain by default to its primary domain (equal to IPA
realm in lower case). This is just a default value.
I can do this in IPA. —nisdomain= will leave it blank. That results in
(host,-,)
That works with the Netapp. (I haven’t actually tried putting a domain in.)
Unfortunately it won’t work with sssd, because sssd won’t show any
triples if the nisdomain isn’t set for that net group.
So, the real issue is SSSD's inability to support empty netgroup domain
part, right?
This is the code in ipa_netgr_process_all():
...
ret = sysdb_attrs_get_string(state->netgroups[i], SYSDB_NETGROUP_DOMAIN,
&domain);
if (ret != EOK) {
goto done;
}
...
DEBUG(SSSDBG_TRACE_INTERNAL, "Putting together triples of "
"netgroup %d\n", i);
for (j = 0; j < uids_count; j++) {
for (k = 0; k < hosts_count; k++) {
triple = talloc_asprintf(state, "(%s,%s,%s)",
hosts[k], uids[j],
domain);
if (triple == NULL) {
ret = ENOMEM;
goto done;
}
ret = sysdb_attrs_add_string(state->netgroups[i],
SYSDB_NETGROUP_TRIPLE,
triple);
if (ret != EOK) {
goto done;
}
}
}
So, if no domain is retrieved, no netgroup triple is generated by SSSD
IPA provider. Note that this does not utilize compatibility netgroups
subtree as generated by schema compatibility plugin (in
cn=ng,cn=compat,$SUFFIX) but instead works directly with IPA netgroups.
So our discussion about RFC2307bis is not really applicable here. If we
consider the use case with a blank nisDomainName a valid one (and I
think we can consider it), the code above needs to be fixed to allow
such use. It is a fairly simple fix.
In general I don’t understand why IPA and sssd are using a nonstandard
representation of net groups. Why not just a collection of triples and
subgroups? As far as I can see RFC 2307bis has the same schema for net
groups as RFC 2307.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-howard-rfc2307bis-02&data=02%7C01%7Chedrick%40rutgers.edu%7Cf9646a8052604f1a986208d52ab5d7d0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636461882863604783&sdata=f9gYACLOOqGX5J5tNizDcOIzLgIc8hIHkxjCm5Z4p%2BI%3D&reserved=0.
Is there a
later version of RFC 2307bis that I haven’t been able to find? Draft 2
is the latest at
tools.ietf.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org&data=02%7C01%7Chedrick%40rutgers.edu%7Cf9646a8052604f1a986208d52ab5d7d0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636461882863604783&sdata=U7g%2B9P0tpyoUKDR%2BXMT%2FZv%2ByMOE54h8m%2BFE8SLcLGxA%3D&reserved=0>.
( 1.3.6.1.1.1.2.8 NAME 'nisNetgroup' SUP top STRUCTURAL
DESC 'Abstraction of a netgroup. May refer to other
netgroups'
MUST cn
MAY ( nisNetgroupTriple $ memberNisNetgroup $ description ) )
The representation used by IPA seems to be non-standard. I’d expect IPA
and sssd to allow me to add any triple I want that’s valid in a normal
net group file.
You can read (old) explanation on why IPA has schema as it has:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freeipa.org%2Fpage%2FFreeIPAv2%3ADS_Design_Summary%23Netgroups&data=02%7C01%7Chedrick%40rutgers.edu%7Cf9646a8052604f1a986208d52ab5d7d0%7Cb92d2b234d35447093ff69aca6632ffe%7C1%7C0%7C636461882863604783&sdata=%2FrI6y%2FfFnmbCFN51ythOlxpgu72%2Fgku6fR4xT0Tow%2BQ%3D&reserved=0
One problem with the IPA representation is that there are no actual
triples. There’s a list of hosts, a list of users, and a domain. Not
all triples can be represented that way. Something like (host1, user1,)
(host2, user2,)
has to be represented by a user list of user1, user2 and a host list of
host1, host2. But the pairing isn’t always well defined. E.g. I added
to that group an external host3 and an internal user3. I ended up with
(host3, user1,)
(host1, user2,)
(host2, user3,)
I don’t know whether there are applications that use the pairing of
hosts and users, but the original design was intended to support that.
With IPA it’s dangerous, because I have to know just how IPA generates
the triples from the entires.
Frankly speaking, original RFC2307bis design had very little explanation
on the actual semantics. It just listed attributes and demonstrated
their use in examples. Actual semantical meaning wasn't defined.
In addition, NIS and NIS+ never had any RFC defined for them.
Is there a way to get the RFC-defined behavior from IPA and SSSD?
Can you point me to what you call RFC-defined behavior? Because I don't
see RFC defining a behavior but rather a storage format (which is
suboptimal but that's another story).
We don’t actually have a user case for pairing. We just need a host
list. So for the moment the plan is to add hosts with nisdomain=, and
use nslcd in nsswitch.conf for net groups on the Linux systems that are
NFS servers.
Right now IPA allows you to associate a hostgroup with a specific
netgroup and schema compat plugin will automatically generate triples
expressing this set. However, as I showed above, SSSD doesn't actually
use this compatibility information at all. IPA provider sets netgroup
search base to cn=ng,cn=alt,$SUFFIX, not cn=ng,cn=compat,$SUFFIX, so
RFC2307bis-specific details are irrelevant in the case IPA provider is
used.
I don’t have any specific use case for distinguishing between space and
-. But the spec says they mean something different. I don’t know why
you would adopt a representation that doesn’t allow for every valid
triple.
I believe we do allow that and compat plugin actually generates them --
except for empty nisDomainName attribute -- for which I provided a
possible solution in my previous email.
I'm yet to see your actual example. Let us set SSSD bug aside here.
Please show a sequence of 'ipa netgroup-*' commands that demonstrate
configuration that is not generating a set of triples you need in the
compat tree. Will that set be generated with a solution I provided in
the previous email?
If we can get these samples, I'm sure it will be easy for Pavel to
provide SSSD fix as well, and these samples can be then used to generate
a test cases to prevent possible regressions in future.
On Nov 13, 2017, at 4:25 AM, Pavel Březina
<pbrez...@redhat.com<mailto:pbrez...@redhat.com>> wrote:
Can you send us some example of what you are trying to achieve and what
does not work? I'm also ccing Alexander Bokovoy to see why IPA adds
somewhere dash and somewhere blanks.
--
/ Alexander Bokovoy
