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. Craig
