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

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.