[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]