Ian. Here is some information that might help. I have worked with the Sun Directory service and is running in our production environment. I am getting to know OpenLDAP and am studying the practical differences between the two these days. We are a Solaris, Linux, HP-UX shop with Solaris and Linux distributed in a networked desktop environment.
As you probably already know, there is the IETF RFC2307 that was adopted in the late 90's. A revised "RFC2307bis" was submitted in 2002. It was never formally adopted (that I could ever see and now no longer is accessible at the IETF). Sun had incorporated the additional attributes/objects interjected, namely the attributes "automountKey" and "automountInformation" used by objectclass "automount" in both the client (NSS LDAP lib) and their directory server. The OpenLDAP server base supports RFC2307, not RFC2307bis. RedHat, though, supplies a permutation of a schema definition to support the "automount" extension of the RFC2307bis. Both Sun and OpenLDAP both include the "RFC2307" nisMap and nisObject and are defined consistently between the two. Historically for us, the "nisObject" objectclass were used in our installation for automounter support, since it provided consistency in deployment and Solaris had good support for attribute mapping. (If I remember correctly, on Linux we initially implemented autofs v3.x and attribute mapping was not supported then -- I could be wrong here). We could support a "single line entry" in an automount map without having to "duplicate entries" by supporting both sets of objectclasses. There are differences in the way the "key attributes" are defined. To define a "nisObject", the "cn" is required. "cn" is a multi-value, case insensitive attribute (UTF-8 DirectoryString -- EQUALITY caseIgnoreMatch, SUBSTR caseIgnoreSubstringsMatch). "automountKey" is case sensitive and is a single-value attribute (IA5String -- EQUALITY caseExactIA5Match). Technically, by definition, the "cn" should lend to case sensitivity issues, though queried, will deliver a case oriented result. Sun apparently took the technically precise approach and worked around this dilemma (or some would argue they introduced it) by delimiting upper case letters with the % sign in order to read a "cn" mapped value and precisely understand its case sensitivity no matter how it is delivered. On Solaris, only the case defined definition appears as the mount. I guess they have programmed around receiving multiple values for an attribute and adopts the one if the % sign is used in one of the values. Over RHEL3/autofs 4.1.x, there is a mount per "cn" received. One with case sensitivity, one with the delimiters included. Not elegant, but the case sensitive path is preserved between platforms for the benefit of the common applications running cross-platform. Both mounted paths are accessible as mounted. With the above said, as a side note, the RedHat supplied schema (Fedora 7) included in their packaged OpenLDAP server uses "cn" as the key in the "automount" objectclass definition rather than the RFC2307bis "automountKey". Jeff would probably be able to interject some insight why. The mainstream version may not be, in fact, defined that way. I hope this helps. -----Original Message----- From: Ian Kent [mailto:[EMAIL PROTECTED] Sent: Friday, July 27, 2007 10:17 AM To: [EMAIL PROTECTED] Cc: Wolfe, Allan; [email protected] Subject: Re: [autofs] autofs5 duplicate entries On Fri, 2007-07-27 at 12:11 +0200, Nail El-Sourani wrote: > Hi Ian, > > since you asked for documentation on this issue, see the sourcecode of > the solaris automounter here: No, I won't be looking at Copyrighted source, sorry. External documentation or behavioral reports only thanks. > > http://src.opensolaris.org/source/xref/pef/phase_I/usr/src/cmd/fs.d/au > tofs/ns_ldap.c > > line 976 ++ > > as can be seen the % apply to the character following. JaVa would be > queried for as %Ja%Va. Seems to be the solaris automounter not ldap > retaining the case sensitivity. Yes, I'll think about this but multiple key values is still illegal from my point of view, so we will see what further discussion brings. > > i will try the patch u sent me shortly and report back if it helped. > > *nail > > Ian Kent wrote: > > On Wed, 2007-07-25 at 09:48 -0500, Wolfe, Allan wrote: > >> To add a comment here. . . The extra cn is for the benefit for > >> Solaris that requires the percent sign to qualify for the capital > >> letter in the string. We will have to contend with the same issue > >> as we move toward autofs version 5. > > > > OK, since the NIS schema isn't case sensitive, right. > > > > I know only what I need to know about LDAP and so I don't know what > > the % is supposed to do. Perhaps some of the LDAP folks here can help. > > > > Does it allow LDAP to retain the case sensitivity in a case > > insensitive attribute or does Solaris autofs do that bit? > > Does the % apply to the whole entry or just the character following it? > > > > Never the less I think it's wrong to allow multiple keys for a mount > > entry since the key is supposed to be unique. > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Nail > >> El-Sourani > >> Sent: Wednesday, July 25, 2007 7:54 AM > >> To: [email protected] > >> Subject: [autofs] autofs5 duplicate entries > >> > >> hi everyone, > >> > >> i seem to have a problem with autofs+ldap on duplicate entries. i > >> migrated from autofs4 settings over to autofs5 quite successfully > >> and in general everything seems to work fine. ill give u a working > >> and nonworking example. > >> > >> > >> auto.master contains: > >> /share ldap:nisMapName=auto_packages,ou=ivv5,dc=de -nosuid > >> > >> ldap queries on the path to automount give me: > >> > >> ldapsearch -x -LLL cn=java > >> > >> working: > >> objectClass: nisObject > >> objectClass: top > >> cn: Java > >> nisMapEntry: ... > >> nisMapName: auto_package... > >> > >> like the above, the autofs5 mounts with no problem. > >> > >> but this one, not working: > >> objectClass: nisObject > >> objectClass: top > >> cn: Java > >> cn: %Java > >> nisMapEntry: ... > >> nisMapName: auto_package... > >> > >> gives in /var/log/messages a > >> > >> Jul 25 14:22:45 SEMTEX automount[4872]: attempting to mount entry > >> /share/java Jul 25 14:22:45 SEMTEX automount[4872]: lookup_one: > >> lookup(ldap): key Java has duplicate entries Jul 25 14:22:45 SEMTEX > >> automount[4872]: failed to mount /share/java > >> > >> As I believe, there seems to be a Problem with cn:Java and cn:%Java > >> somehow. As I understand the % seems to be there to enable both > >> upper-and lowercase typing (java, Java) when entering the Path on > >> the commandline (cd /share/Java, /share/java). Anyhow. in autofs4 > >> this didnt seem to be a problem. > >> > >> Any help would be appreciated. > >> > >> *nail > >> > >> _______________________________________________ > >> autofs mailing list > >> [email protected] > >> http://linux.kernel.org/mailman/listinfo/autofs > >> ----------------------------------------- > >> > >> Anadarko Confidentiality Notice: > >> This electronic transmission and any attached documents or other > >> writings are intended only for the person or entity to which it is > >> addressed and may contain information that is privileged, > >> confidential or otherwise protected from disclosure. If you have > >> received this communication in error, please immediately notify > >> sender by return e-mail and destroy the communication. Any > >> disclosure, copying, distribution or the taking of any action > >> concerning the contents of this communication or any attachments by > >> anyone other than the named recipient is strictly prohibited. > >> > >> _______________________________________________ > >> autofs mailing list > >> [email protected] > >> http://linux.kernel.org/mailman/listinfo/autofs > > > > _______________________________________________ > > autofs mailing list > > [email protected] > > http://linux.kernel.org/mailman/listinfo/autofs ----------------------------------------- Anadarko Confidentiality Notice: This electronic transmission and any attached documents or other writings are intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. If you have received this communication in error, please immediately notify sender by return e-mail and destroy the communication. Any disclosure, copying, distribution or the taking of any action concerning the contents of this communication or any attachments by anyone other than the named recipient is strictly prohibited. _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
