Hi there,

I was just wondering if there are any news on this regarding autofs5?

Thanks,
*nail

Wolfe, Allan wrote:
> 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

_______________________________________________
autofs mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/autofs

Reply via email to