LDAP be killing me. I need a good step by step

[Ed Greshko]

Craig White wrote:
> On Wed, 2008-01-09 at 22:49 +0800, Ed Greshko wrote:
>> Craig White wrote:
>>> On Wed, 2008-01-09 at 22:39 +0800, Ed Greshko wrote:
>>>> Craig White wrote:
>>>>> On Wed, 2008-01-09 at 14:16 +0000, Timothy Murphy wrote:
>>>>>> Brian Millett wrote:
>>>>>>
>>>>>>> I have a file of names, phone numbers, etc. that has the following format
>>>>>>> that is used at my work:
>>>>>>> Name|Email|Ext.|Home #|Cellular #|Pager|Title
>>>>>>>
>>>>>>> sample data:
>>>>>>>
>>>>>>> Baker, Steve B.|sbb|15|314-215-4141|314-591-8181|| Director of Technology
>>>>>>> Bowland, Chris|cyb|33|314-835-1216||314-663-3132|Java Developer
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I wrote a perl script to parse this and put it into a valid ldif format:
>>>>>> Thanks for your script, which I shall study.
>>>>>>
>>>>>> But one problem with setting up an address book in this way
>>>>>> is that there seems to be no standard LDAP format for addresses,
>>>>>> and an email client probably will not understand a particular format.
>>>>>>
>>>>>> For example, I use kmail, which claims to understand LDAP.
>>>>>> But if you export your kmail (or kaddressbook) list in LDIF format
>>>>>> it is more of less useless for putting on an openldap server.
>>>>>>
>>>>>> As far as I can see, the only reasonably general format for this is vCard
>>>>>> (which is more or less what kmail uses)
>>>>>> but there doesn't seem to be any standard way
>>>>>> of translating vCard to LDAP (or LDIF) format.
>>>>>>
>>>>>> It's amazing to me that there is not a standard way
>>>>>> of putting an address book on an openldap server
>>>>>> which can be understood by all email clients
>>>>>> since this seems to be the major use of openldap.
>>>>>>
>>>>>> But I am far from expert in this subject;
>>>>>> perhaps I have misunderstood the situation?
>>>>> ----
>>>>> On Fedora (I think, for certain on RHEL), the openldap-servers comes
>>>>> with many 'migration' scripts from padl that can take static file
>>>>> entries (/etc/passwd, /etc/shadow, /etc/group, /etc/hosts...) and
>>>>> migrate them into an LDIF which you can then import. Their scripts are
>>>>> very, very good and should be the basis for anyone looking to migrate to
>>>>> LDAP.
>>>>>
>>>>> Address Book clients such as Kontact (which is what Kmail would use), or
>>>>> Thunderbird, Evolution, Outlook, etc. all have differing notions of
>>>>> which attributes LDAP should offer. Let me repeat this another
>>>>> way...THERE ARE NO STANDARDS for attributes that Address Book client
>>>>> applications will use. This can be viewed as a negative or a positive.
>>>>> Positive because you can support a variety of address book clients in a
>>>>> variety of ways. Negative because if you don't know what you're doing,
>>>>> it's confusing.
>>>>>
>>>>> Therefore, whatever any program exports as an LDIF will differ from each
>>>>> other program and it's up to the 'administrator' to do find/replace for
>>>>> the attributes that they intend to use on the LDAP server...the only
>>>>> other way is the Microsoft way which is prescribed. Once you absorb the
>>>>> methodology, it becomes clear that the Microsoft way is limiting.
>>>> Funny....  I knew that Ric's extremely general question was going to fan out 
>>>> to be much more than he thought he was asking......
>>>>
>>>> I'd dump all that I know about ldap here....but it would take me too long to 
>>>> type it all and maybe never answer the question that Ric thinks he is 
>>>> asking.  :-)
>>> ----
>>> lateral answer, I directed him to the Administrator's Guide on the
>>> OpenLDAP's website.
>>>
>>> This was simply a clarification on why different address book clients
>>> write different attributes in an exported LDIF file which probably will
>>> fail when you try to ldapadd/slapadd them into LDAP
>> Right....but he can't even get as far as getting an ldap server running. 
>> Or, that is my take from his initial query.  So, getting into depth about 
>> what clients are expecting from the ldap server is putting the cart before 
>> the horse....so to speak.
> ----
> hence my previous direction to Administrator Guide
> 
> useless and unresponsive answers is not the exclusive domain of a select
> few.

Sorry...don't understand that cryptic message.