Re: DBIS commentary
Jordan Brown <[email protected]> Tue, 1 Dec 2015 09:52:56 -0800
| Newsgroups | gmane.ietf.ldapext |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============6210990181122224924==
Content-Type: multipart/alternative;
boundary="------------080908010309080803020209"
This is a multi-part message in MIME format.
--------------080908010309080803020209
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
On 12/1/2015 2:13 AM, Bannister, Mark wrote:
>
> > On the case-sensitivity front: we have a pretty fundamental disagree=
ment. I=20
> believe that UNIX names
>
> > must eventually become case-insensitive, that it is only a matter of =
time=20
> until they do.
>
> Yes, you're right, this is a pretty fundamental disagreement. As I don=
't see=20
> anyone else entering the
>
> debate supporting case sensitivity, I fear this will fail on a standard=
s track. =20
> I may just keep the
>
> software available as an alternative, and those who want it can use it,=
but I=20
> think any hopes I had
>
> that DBIS might one day be a standard have just been dashed. I will co=
ntinue to=20
> answer some
>
> of your points anyway, just for completion. Those who agree with me ar=
e either=20
> a) not speaking
>
> up or b) not reading this mailing list.
>
Do note again that RFC 4876 mapping would let you redirect the clients to=
use a=20
custom case-sensitive attribute, or attributes from different auxiliary c=
lasses.
> However, I would point out that you will meet resistance (and/or disgru=
ntled=20
> customers after the
>
> fact) if you attempt to change UNIX to be case-insensitive.
>
For the particular case of user names, I'll note that you're the first pe=
rson I've=20
talked to who isn't working directly on Solaris LDAP development who has =
even=20
noticed that LDAP user names are case-insensitive, much less complained.
> Btw, what was your plan for casesensitivity in filesystems?
>
Baby steps :-)
I do think that that's inevitable too, just not as soon as user names. U=
ser names=20
have more cross-platform impact, a more direct association to human names=
, and get=20
typed by hand more often in many environments.
Any environment that interoperates with Windows will end up with case-ins=
ensitive=20
file names, at least in data file systems. Case-insensitivity is already =
an option=20
on ZFS, and a "mixed" mode is the default on our storage appliances.
> > UNIX is not the whole world, and the entire rest of the world is clea=
r that=20
> MARK, Mark, and mark
>
> > are the same person.
>
> With people, perhaps. With people vs. service accounts perhaps not. P=
erhaps I=20
> have a user with
>
> a login name of 'sheila' but I also have a service account called 'SHEI=
LA'. I=20
> suppose next you will
>
> be proposing to redefine the English language by saying that case is un=
important=20
> when starting
>
> sentences, or when writing proper nouns vs nouns? Be careful when you =
say "the=20
> entire rest
>
> of the world", be sure you really know the entire rest of the world. I=
don't=20
> claim to, but I do have
>
> real examples of problems that DBIS is solving today.
>
I'd suggest that having a login name that duplicates a service account na=
me,=20
except for case, is asking for trouble. Even in a relative bastion of UN=
IX like=20
Oracle, we noticed that some of the corporate UIs present user names as a=
ll upper=20
case. Case sensitivity is really quite unnatural for humans. There's no=
shortage=20
of commercial systems that change the case of the left side of e-mail add=
resses,=20
which will really mess you up if you're using the natural username@domain=
=20
construction and your usernames are case-sensitive. They're wrong, but t=
hey're=20
common. (And, importantly, almost nobody *notices* that they are wrong.)
I doubt we'd want to go too far off into the weeds on English semantics, =
but I'd=20
argue that case *is* unimportant when starting sentences. It helps to ma=
rk the=20
beginning of the sentence, but does not otherwise affect the meaning of t=
he word. =20
When I say "Cars drive on roads" or "The cars are on the road", "Cars" an=
d "cars"=20
mean the same thing. For proper nouns you have a point - Oracle and an o=
racle are=20
two different things. (Though even there, note the proper noun does not =
take an=20
article.) However, user names are always proper nouns. Come to think of=
it,=20
there's something interesting there. "Mark" and "Bannister" are both pro=
per=20
nouns, yet "mark" and "bannister" are common nouns. The only reason that=
we=20
tolerate using "mark" and "bannister" as user names is that we internally=
convert=20
them into their capitalized forms; treating them as common nouns as stand=
ard=20
English would have us do wouldn't make any sense.
> > My key point here is that DBIS should specify what attribute should r=
eplace=20
> it, what attribute
>
> > clients are expected to use to populate the pw_gecos field in struct =
passwd.
>
> draft-bannister-dbis-passwd provides a suggestion already in 2.1.3.1:
>
> The posixUserAccount object class is auxiliary and must always be
>
> associated with another structural class. One such class is
>
> inetOrgPerson [RFC2798]. If user accounts were given the
>
> inetOrgPerson class, then displayName might be an appropriate value
>
> for the dbisMapGecos attribute.
>
> Given that the gecos field can encode anything in any format, I didn't =
think I=20
> could realistically
>
> do any better than provide a suggestion.
>
I think you could safely specify displayName as a MAY attribute, and let =
people=20
use RFC 4876 mapping if for some reason they want to use something else.
Having two attribute-mapping mechanisms - RFC 4876 mapping and dbisMapGec=
os -=20
seems bothersome.
> > >> posixGroup / posixGroupAccount
>
> > >>
>
> > >> X.521 groupOfNames seems like a more appropriate basis for the def=
inition=20
> of a group.
>
> > > But that doesn't allow for GID number.
>
> >
>
> > A subclass does.
>
> I have people telling me groupOfNames doesn't work well for them becaus=
e it can=20
> be a group
>
> of anything. Extra LDAP searches are required to figure out what type =
of object=20
> the members
>
> are. That leads to a rather inefficient system.
>
There are two problems there:
1) A group could contain anything, even when you want it to only contain=
one=20
type. Administrator error could lead to incorrect configurations. In=20
programming-ese, it's not type-safe. One might hope that you could set u=
p=20
metadata limiting the types of objects that could be added to a group, li=
ke you=20
can set up limits on the types of objects that can be put in a container,=
but I=20
don't know if you can. One hopes that your administration UIs will help =
here - if=20
you're defining a group of users, the administration UI presumably knows =
that and=20
only lets you add users. At the same time, this flexibility enables nest=
ed=20
groups, which can be very useful.
2) You have to do "extra" searches to get any real information on the me=
mber. =20
Yes, that's a very big problem. The particular pain point is that getgrn=
am and=20
getgrgid are defined to return a list of the members of the group, necess=
itating a=20
search for *each* member. That gets pretty painful when a group has thous=
ands of=20
members. I think the truly right answer there is to add new APIs that do=
n't=20
retrieve the members, and even to redefine the existing APIs to not retri=
eve the=20
members, because there are almost no cases where it actually makes sense =
to=20
retrieve the list of members of a UNIX group. The standards provide some=
help in=20
that there are hints in the UNIX standard that the list of members return=
ed may=20
not be complete. Also: Caching is your friend. Note also that the PADL =
version=20
of nss_ldap has a "nss_getgrent_skipmembers" option that disables returni=
ng the=20
list of members.
As long as we're talking about flaws in groupOfNames: there's also the p=
roblem=20
that "member" is a MUST attribute, and that makes empty groups problemati=
c. =20
Active Directory uses the same basic structure, but uses the "group" clas=
s instead=20
of groupOfNames, and for "group" the "member" attribute is a MAY. RFC230=
7bis-02=20
replaces groupOfNames with groupOfMembers, again with "member" as a MAY.
(One might have hoped that you could have an attribute with a empty list =
of=20
values, but X.501 does not allow that.)
> See previous reservations regarding groupOfNames. Imagine trying to co=
nstruct a=20
> search
> operation to find just host members, or just user members.
Do note that the queries that you normally need are "is this host (or use=
r) a=20
member of this group" and "what groups is this user a member of". It's h=
ard to=20
find cases where you really want to ask "what are the members of this gro=
up". The=20
"is this X a member" and "what groups is this X a member of" queries aren=
't bad at=20
all with groupOfNames - you have to do a lookup on X to get its DN, but t=
hen you=20
just do a natural (and efficient) search.
> > Having two names that differ only in case lead to different port numb=
ers seems=20
> like a
> > spectacularly bad idea. If there's an organization that has somehow =
found=20
> themselves
> > in such a mess then I'm very sorry for them
>
> <rant>
>
> Wait. NIS permitted this. If folk have done what NIS allowed them to =
do, and it
>
> fitted their working practice, then you can't blame them for that. If =
you don't=20
> like it
>
> and want to label it "a mess", that's fine you can do that, but I do no=
t want to=20
> leave
>
> people behind. If you wish to call it a mess, then Sun Microsystems cr=
eated the=20
> mess,
>
> but it's infrastructure and we're stuck with it. Imagine if the electr=
onics=20
> industry in America
>
> started selling devices with only English three-pin plugs=20
> <https://www.google.co.uk/url?sa=3Dt&rct=3Dj&q=3D&esrc=3Ds&source=3Dweb=
&cd=3D2&cad=3Drja&uact=3D8&ved=3D0ahUKEwiQzfjRs7rJAhUCKiYKHY6eCZoQFggiMAE=
&url=3Dhttp%3A%2F%2Fwww.fastcodesign.com%2F3032807%2Fwhy-england-has-the-=
best-wall-sockets-on-earth&usg=3DAFQjCNEP4sremkvI56BoTb7D7rJhFaRbgg>,=20
> citing that the original was a
>
> =E2=80=9Cbad design=E2=80=9D and anyone who has found themselves in suc=
h a mess as to have
>
> incompatible wall sockets, well very sorry for them but that=E2=80=99s =
just tough luck.
>
> Right. You=E2=80=99d cause an outcry. Same thing applies here. With =
NIS a particular
>
> working practice was absolutely fine. Now it isn=E2=80=99t. And people=
are left to fix it
>
> themselves. I think that=E2=80=99s very bad. (And for those who say =E2=
=80=9CNIS is dead=E2=80=9D, that=E2=80=99s
>
> absolutely not true, there are large organisations still using NIS and =
who haven=E2=80=99t
>
> yet migrated to LDAP, perhaps because the migration to LDAP is too hard=
for
>
> them in the present climate).
>
> </rant>
>
Well, kind of. Yes, you were allowed to do it. That doesn't necessarily=
mean=20
that it was ever a good idea.
The structure of extension cords and power strips lets you daisy-chain th=
em=20
together to any length. That doesn't mean that it's a good idea to do it=
, or that=20
the fire marshal won't cite you on your next office inspection.
Also, remember that IANA, not NIS, is the authority on the definition of =
service=20
names, and it defines them as case-insensitive. There's a very good argu=
ment that=20
NIS treating them in a case-sensitive way is a bug.
--------------080908010309080803020209
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DUTF-8" http-equiv=3D"Content-Ty=
pe">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 12/1/2015 2:13 AM, Bannister, Mark
wrote:<br>
</div>
<blockquote
cite=3D"mid:[email protected].=
com"
type=3D"cite">
<!-- Template generated by Exclaimer Template Editor on 05:13:31 Tu=
esday, 1 December 2015 -->
<style type=3D"text/css">P.cafa858c-a64a-4018-b357-eb8084b6b267 {
MARGIN: 0cm 0cm 0pt
}
LI.cafa858c-a64a-4018-b357-eb8084b6b267 {
MARGIN: 0cm 0cm 0pt
}
DIV.cafa858c-a64a-4018-b357-eb8084b6b267 {
MARGIN: 0cm 0cm 0pt
}
TABLE.cafa858c-a64a-4018-b357-eb8084b6b267Table {
MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
page: Section1
}
</style>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DU=
TF-8">
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Calibri","sans-serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
p.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
{mso-style-priority:1;
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Calibri","sans-serif";
color:black;}
span.Code
{mso-style-name:Code;
mso-style-priority:1;
font-family:"Courier New";}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";
color:black;
mso-fareast-language:EN-GB;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
<p>
</p>
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">> On the case-sensitivity front:=C2=A0=
we
have a pretty fundamental disagreement.=C2=A0 I believe that UN=
IX
names<o:p></o:p></p>
<p class=3D"MsoPlainText">> must eventually become
case-insensitive, that it is only a matter of time until they
do.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoPlainText">Yes, you're right, this is a pretty
fundamental disagreement.=C2=A0 As I don't see anyone else ente=
ring
the<o:p></o:p></p>
<p class=3D"MsoPlainText">debate supporting case sensitivity, I
fear this will fail on a standards track.=C2=A0 I may just keep=
the<o:p></o:p></p>
<p class=3D"MsoPlainText">software available as an alternative,
and those who want it can use it, but I think any hopes I had<o=
:p></o:p></p>
<p class=3D"MsoPlainText">that DBIS might one day be a standard
have just been dashed.=C2=A0 I will continue to answer some<o:p=
></o:p></p>
<p class=3D"MsoPlainText">of your points anyway, just for
completion.=C2=A0 Those who agree with me are either a) not
speaking<o:p></o:p></p>
<p class=3D"MsoPlainText">up or b) not reading this mailing list.=
<o:p></o:p></p>
</div>
</blockquote>
<br>
Do note again that RFC 4876 mapping would let you redirect the
clients to use a custom case-sensitive attribute, or attributes from
different auxiliary classes.<br>
<br>
<blockquote
cite=3D"mid:[email protected].=
com"
type=3D"cite">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">However, I would point out that you wil=
l
meet resistance (and/or disgruntled customers after the<o:p></o=
:p></p>
<p class=3D"MsoPlainText">fact) if you attempt to change UNIX to
be case-insensitive.</p>
</div>
</blockquote>
<br>
For the particular case of user names, I'll note that you're the
first person I've talked to who isn't working directly on Solaris
LDAP development who has even noticed that LDAP user names are
case-insensitive, much less complained.<br>
<br>
<blockquote
cite=3D"mid:[email protected].=
com"
type=3D"cite">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Btw, what was your plan for case<o:p></=
o:p>
sensitivity in filesystems?<o:p></o:p></p>
</div>
</blockquote>
<br>
Baby steps :-)<br>
<br>
I do think that that's inevitable too, just not as soon as user
names.=C2=A0 User names have more cross-platform impact, a more direc=
t
association to human names, and get typed by hand more often in many
environments.<br>
<br>
Any environment that interoperates with Windows will end up with
case-insensitive file names, at least in data file systems.=C2=A0
Case-insensitivity is already an option on ZFS, and a "mixed" mode
is the default on our storage appliances.<br>
<br>
<blockquote
cite=3D"mid:[email protected].=
com"
type=3D"cite">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText"><o:p>=C2=A0</o:p>> UNIX is not the w=
hole
world, and the entire rest of the world is clear that MARK,
Mark, and mark<o:p></o:p></p>
<p class=3D"MsoPlainText">> are the same person.<o:p></o:p></p=
>
<p class=3D"MsoPlainText"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoPlainText">With people, perhaps.=C2=A0 With people=
vs.
service accounts perhaps not.=C2=A0 Perhaps I have a user with<=
o:p></o:p></p>
<p class=3D"MsoPlainText">a login name of 'sheila' but I also hav=
e
a service account called 'SHEILA'.=C2=A0 I suppose next you wil=
l<o:p></o:p></p>
<p class=3D"MsoPlainText">be proposing to redefine the English
language by saying that case is unimportant when starting<o:p><=
/o:p></p>
<p class=3D"MsoPlainText">sentences, or when writing proper nouns
vs nouns?=C2=A0 Be careful when you say "the entire rest<o:p></=
o:p></p>
<p class=3D"MsoPlainText">of the world", be sure you really know
the entire rest of the world.=C2=A0 I don't claim to, but I do =
have<o:p></o:p></p>
<p class=3D"MsoPlainText">real examples of problems that DBIS is
solving today.<o:p></o:p></p>
</div>
</blockquote>
<br>
I'd suggest that having a login name that duplicates a service
account name, except for case, is asking for trouble.=C2=A0 Even in a
relative bastion of UNIX like Oracle, we noticed that some of the
corporate UIs present user names as all upper case.=C2=A0 Case
sensitivity is really quite unnatural for humans.=C2=A0 There's no
shortage of commercial systems that change the case of the left side
of e-mail addresses, which will really mess you up if you're using
the natural username@domain construction and your usernames are
case-sensitive.=C2=A0 They're wrong, but they're common.=C2=A0 (And,
importantly, almost nobody *notices* that they are wrong.)<br>
<br>
I doubt we'd want to go too far off into the weeds on English
semantics, but I'd argue that case *is* unimportant when starting
sentences.=C2=A0 It helps to mark the beginning of the sentence, but =
does
not otherwise affect the meaning of the word.=C2=A0 When I say "Cars
drive on roads" or "The cars are on the road", "Cars" and "cars"
mean the same thing.=C2=A0 For proper nouns you have a point - Oracle=
and
an oracle are two different things.=C2=A0 (Though even there, note th=
e
proper noun does not take an article.)=C2=A0 However, user names are
always proper nouns.=C2=A0 Come to think of it, there's something
interesting there.=C2=A0 "Mark" and "Bannister" are both proper nouns=
,
yet "mark" and "bannister" are common nouns.=C2=A0 The only reason th=
at
we tolerate using "mark" and "bannister" as user names is that we
internally convert them into their capitalized forms; treating them
as common nouns as standard English would have us do wouldn't make
any sense.<br>
<br>
<blockquote
cite=3D"mid:[email protected].=
com"
type=3D"cite">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText"><o:p></o:p>> My key point here is
that DBIS should specify what attribute should replace it,
what attribute<o:p></o:p></p>
<p class=3D"MsoPlainText">> clients are expected to use to
populate the pw_gecos field in struct passwd.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoPlainText">draft-bannister-dbis-passwd provides a
suggestion already in 2.1.3.1:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoPlainText">=C2=A0=C2=A0 The posixUserAccount objec=
t class is
auxiliary and must always be<o:p></o:p></p>
<p class=3D"MsoPlainText">=C2=A0=C2=A0 associated with another st=
ructural
class.=C2=A0 One such class is<o:p></o:p></p>
<p class=3D"MsoPlainText">=C2=A0=C2=A0 inetOrgPerson [RFC2798].=C2=
=A0 If user
accounts were given the<o:p></o:p></p>
<p class=3D"MsoPlainText">=C2=A0=C2=A0 inetOrgPerson class, then =
displayName
might be an appropriate value<o:p></o:p></p>
<p class=3D"MsoPlainText">=C2=A0=C2=A0 for the dbisMapGecos attri=
bute.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoPlainText">Given that the gecos field can encode
anything in any format, I didn't think I could realistically<o:=
p></o:p></p>
<p class=3D"MsoPlainText">do any better than provide a suggestion=
.<o:p></o:p></p>
</div>
</blockquote>
<br>
I think you could safely specify displayName as a MAY attribute, and
let people use RFC 4876 mapping if for some reason they want to use
something else.<br>
<br>
Having two attribute-mapping mechanisms - RFC 4876 mapping and
dbisMapGecos - seems bothersome.<br>
<br>
<blockquote
cite=3D"mid:[email protected].=
com"
type=3D"cite">
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">> >> posixGroup /
posixGroupAccount<o:p></o:p></p>
<p class=3D"MsoPlainText">> >><o:p></o:p></p>
<p class=3D"MsoPlainText">> >> X.521 groupOfNames seems
like a more appropriate basis for the definition of a group.<o:=
p></o:p></p>
<p class=3D"MsoPlainText">> > But that doesn't allow for GI=
D
number.<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> A subclass does.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoPlainText">I have people telling me groupOfNames
doesn't work well for them because it can be a group<o:p></o:p>=
</p>
<p class=3D"MsoPlainText">of anything.=C2=A0 Extra LDAP searches =
are
required to figure out what type of object the members<o:p></o:=
p></p>
<p class=3D"MsoPlainText">are.=C2=A0 That leads to a rather ineff=
icient
system.<o:p></o:p></p>
</div>
</blockquote>
<br>
There are two problems there:<br>
<br>
1)=C2=A0 A group could contain anything, even when you want it to onl=
y
contain one type.=C2=A0 Administrator error could lead to incorrect
configurations.=C2=A0 In programming-ese, it's not type-safe.=C2=A0 O=
ne might
hope that you could set up metadata limiting the types of objects
that could be added to a group, like you can set up limits on the
types of objects that can be put in a container, but I don't know if
you can.=C2=A0 One hopes that your administration UIs will help here =
- if
you're defining a group of users, the administration UI presumably
knows that and only lets you add users.=C2=A0 At the same time, this
flexibility enables nested groups, which can be very useful.<br>
2)=C2=A0 You have to do "extra" searches to get any real information =
on
the member.=C2=A0 Yes, that's a very big problem.=C2=A0 The particula=
r pain
point is that getgrnam and getgrgid are defined to return a list of
the members of the group, necessitating a search for *each* member.=C2=
=A0
That gets pretty painful when a group has thousands of members.=C2=A0=
I
think the truly right answer there is to add new APIs that don't
retrieve the members, and even to redefine the existing APIs to not
retrieve the members, because there are almost no cases where it
actually makes sense to retrieve the list of members of a UNIX
group.=C2=A0 The standards provide some help in that there are hints =
in
the UNIX standard that the list of members returned may not be
complete.=C2=A0 Also:=C2=A0 Caching is your friend. Note also that th=
e PADL
version of nss_ldap has a "nss_getgrent_skipmembers" option that
disables returning the list of members.<br>
<br>
As long as we're talking about flaws in groupOfNames:=C2=A0 there's a=
lso
the problem that "member" is a MUST attribute, and that makes empty
groups problematic.=C2=A0 Active Directory uses the same basic struct=
ure,
but uses the "group" class instead of groupOfNames, and for "group"
the "member" attribute is a MAY.=C2=A0 RFC2307bis-02 replaces
groupOfNames with groupOfMembers, again with "member" as a MAY.<br>
<br>
(One might have hoped that you could have an attribute with a empty
list of values, but X.501 does not allow that.)<br>
<br>
<blockquote
cite=3D"mid:[email protected].=
com"
type=3D"cite">
<div class=3D"WordSection1">See previous reservations regarding
groupOfNames.=C2=A0 Imagine trying to construct a search
<br>
operation to find just host members, or just user members.</div>
</blockquote>
<br>
Do note that the queries that you normally need are "is this host
(or user) a member of this group" and "what groups is this user a
member of".=C2=A0 It's hard to find cases where you really want to as=
k
"what are the members of this group".=C2=A0 The "is this X a member" =
and
"what groups is this X a member of" queries aren't bad at all with
groupOfNames - you have to do a lookup on X to get its DN, but then
you just do a natural (and efficient) search.<br>
<br>
<blockquote
cite=3D"mid:[email protected].=
com"
type=3D"cite">
<div class=3D"WordSection1">> Having two names that differ only
in case lead to different port numbers seems like a
<br>
> spectacularly bad idea.=C2=A0 If there's an organization tha=
t
has somehow found themselves<br>
> in such a mess then I'm very sorry for them<br>
<p class=3D"MsoPlainText"><o:p>=C2=A0</o:p></p>
<p class=3D"MsoPlainText"><rant><o:p></o:p></p>
<p class=3D"MsoPlainText">Wait.=C2=A0 NIS permitted this.=C2=A0 I=
f folk have
done what NIS allowed them to do, and it<o:p></o:p></p>
<p class=3D"MsoPlainText">fitted their working practice, then you
can't blame them for that.=C2=A0 If you don't like it<o:p></o:p=
></p>
<p class=3D"MsoPlainText">and want to label it "a mess", that's
fine you can do that, but I do not want to leave<o:p></o:p></p>
<p class=3D"MsoPlainText">people behind.=C2=A0 If you wish to cal=
l it a
mess, then Sun Microsystems created the mess,<o:p></o:p></p>
<p class=3D"MsoPlainText">but it's infrastructure and we're stuck
with it.=C2=A0 Imagine if the electronics industry in America<o=
:p></o:p></p>
<p class=3D"MsoPlainText">started selling devices with only <a
moz-do-not-send=3D"true"
href=3D"https://www.google.co.uk/url?sa=3Dt&rct=3Dj&q=3D&esrc=
=3Ds&source=3Dweb&cd=3D2&cad=3Drja&uact=3D8&ved=3D0ah=
UKEwiQzfjRs7rJAhUCKiYKHY6eCZoQFggiMAE&url=3Dhttp%3A%2F%2Fwww.fastcode=
sign.com%2F3032807%2Fwhy-england-has-the-best-wall-sockets-on-earth&u=
sg=3DAFQjCNEP4sremkvI56BoTb7D7rJhFaRbgg">English
three-pin plugs</a>, citing that the original was a<o:p></o:p=
></p>
<p class=3D"MsoPlainText">=E2=80=9Cbad design=E2=80=9D and anyone=
who has found
themselves in such a mess as to have<o:p></o:p></p>
<p class=3D"MsoPlainText">incompatible wall sockets, well very
sorry for them but that=E2=80=99s just tough luck.<o:p></o:p></=
p>
<p class=3D"MsoPlainText">Right.=C2=A0 You=E2=80=99d cause an out=
cry.=C2=A0 Same
thing applies here.=C2=A0 With NIS a particular<o:p></o:p></p>
<p class=3D"MsoPlainText">working practice was absolutely fine.=C2=
=A0
Now it isn=E2=80=99t.=C2=A0 And people are left to fix it<o:p><=
/o:p></p>
<p class=3D"MsoPlainText">themselves.=C2=A0 I think that=E2=80=99=
s very bad.=C2=A0
(And for those who say =E2=80=9CNIS is dead=E2=80=9D, that=E2=80=
=99s<o:p></o:p></p>
<p class=3D"MsoPlainText">absolutely not true, there are large
organisations still using NIS and who haven=E2=80=99t<o:p></o:p=
></p>
<p class=3D"MsoPlainText">yet migrated to LDAP, perhaps because
the migration to LDAP is too hard for<o:p></o:p></p>
<p class=3D"MsoPlainText">them in the present climate).<o:p></o:p=
></p>
<p class=3D"MsoPlainText"></rant><o:p></o:p></p>
</div>
</blockquote>
<br>
Well, kind of.=C2=A0 Yes, you were allowed to do it.=C2=A0 That doesn=
't
necessarily mean that it was ever a good idea.<br>
<br>
The structure of extension cords and power strips lets you
daisy-chain them together to any length.=C2=A0 That doesn't mean that
it's a good idea to do it, or that the fire marshal won't cite you
on your next office inspection.<br>
<br>
Also, remember that IANA, not NIS, is the authority on the
definition of service names, and it defines them as
case-insensitive.=C2=A0 There's a very good argument that NIS treatin=
g
them in a case-sensitive way is a bug.<br>
<br>
</body>
</html>
--------------080908010309080803020209--
--===============6210990181122224924==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext
--===============6210990181122224924==--