[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



On Wed, 2008-01-09 at 22:59 +0800, Ed Greshko wrote:
> 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.
----
his question, you and I directed him to the openldap admin guide, mine
from openldap.org website and yours from huihoo.com website. These
answers seemed to be entirely responsive to OP.

the cryptic part I presume was your stating that you knew the answers
would be unresponsive to his needs but rather chase out into various
tangents which of course had already happened. This thread was proof of
that fact and I was remarking that it sometimes can't be helped. I only
sought to clarify the follow up to the now unresponsive (to OP) thread
because Timothy is trying to find out why in essence, Kmail (actually
Kontact) is exporting contacts into an LDIF that can't be imported into
LDAP server.

His confusion is very common...I admit that I too was confused by that
very notion when I first started mucking with LDAP. One would think that
if you use say OpenOffice to save say Test.DOC that Microsoft Word
should be able to open that file [1]. Likewise, since LDIF is the world
of LDAP, shouldn't one expect that an LDIF file exported by Kontact be
usable with openldap?

Of course all of this is entirely useless and unresponsive to OP's
original question.

Craig

[1] Another interesting tangent clearly not related to OP or follow-up,
Microsoft Office may not be able to open documents created by Microsoft
Office (or OpenOffice.org)...
http://www.news.com/Office-2003-update-blocks-older-file-formats/2100-1012_3-6224462.html


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