Re: Importing Netscape LDIF address book into OpenLDAP

[Thomas Brown <twb0@lymenet.org>]

Yes, it does seem that the inetOrgPerson objectclass is the most
appropriate for this type of entry.  Unfortunately, Netscape has
taken a Microsoftish approach of creating funky custom LDIF
entries when you export an address book.  For instance, here is a
sample exported LDIF entry with all possible fields filled in:

dn: cn=DisplayName,mail=email@address.net
modifytimestamp: 20020215201642Z
cn: DisplayName
mail: email@address.net
xmozillausehtmlmail: TRUE
givenname: FirstName
sn: LastName
o: Organization
xmozillanickname: Nickname
description:: Tm90ZXMNCk5vdGVzDQpOb3Rlcw==
locality: City
st: State
title: Title
streetaddress: Address
postalcode: Zip
countryname: Country
telephonenumber: Work
homephone: Home
facsimiletelephonenumber: Fax
pagerphone: Pager
cellphone: Cellular
ou: Department
homeurl: URL
xmozillaanyphone: Work
objectclass: top
objectclass: person

The first thing you'll notice is the DN with the "mail=" field,
which would automatically have to be modified to fit into any
sort of LDAP tree.  Then there are all the "xmozillablahblahblah"
entries, locality, cellphone, etc.  Also, 'inetOrgPerson'
requires a sn: entry, which may not exist in all cases.  I
suppose one would have to steal the inetOrgPerson schema which
Netscape supplies with its Directory Server product.  They
describe it here:

http://devedge.netscape.com/docs/manuals/directory/schema2/41/oc_dir30.htm#1305824

It looks like the only way to make a an address book exported by
Netscape Communicator available for public consumption in an LDAP
tree is to write a script to hack the DN by including some unique
serial number and adding a suffix to the end, at least for
starters...

I think reality is starting to set in.  :-(

-Tom


Philip Kizer wrote:
> 
> Thomas Brown <twb0@lymenet.org> wrote:
> >I suspect there is something that needs to be tweaked in the schema before
> >that can happen, as the 'ldifadd' command chokes on the 'mail' field:
> >
> ># /opt/openldap/bin/ldapadd -f import.ldif -x -D
> >"cn=Manager,o=mydomain.com" -W
> >Enter LDAP Password:
> >adding new entry "o=mydomain.com"
> >adding new entry "cn=Manager, o=mydomain.com"
> >adding new entry "cn=username, o=mydomain.com"
> >ldap_add: Object class violation
> >        additional info: attribute 'mail' not allowed
> 
> >dn: cn=username, o=mydomain.com
> >cn: username
> >sn: Firstname
> >mail: username@mydomain.com
> >objectclass: person
> 
> >The business-end of my slapd.conf file looks like this:
> >
> >include         /opt/ldap/etc/openldap/schema/core.schema
> 
> Note that core.schema defines 'person' as:
>         MUST ( sn $ cn )
>         MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
> 
> There's no 'mail' (which is also rfc822mailbox) in there at all.
> 
> I think the most direct route would be to add to your LDIF as such:
>   dn: cn=username, o=mydomain.com
>   [ ... ]
>   objectClass: inetOrgPerson
> 
> since that objectClass (inetOrgPerson) includes a:
>   MAY ( mail )
> 
> although you would then need to include in your slapd.conf:
>   include         /opt/ldap/etc/openldap/schema/inetorgperson.schema
> 
> Note:
>   inetOrgPerson is in inetorgperson.schema, and
>   depends on (from the SUP): organizationalPerson
> and:
>   organizationalPerson is in core.schema, and
>   depends on (from it's SUP): person
> which is already included with your include of core.schema.
> 
> Make sense?
> 
> -philip
> 
> --
> Philip Kizer, Senior Lead Systems Engineer, Texas A&M University
> USENIX Liaison to Texas A&M University         <usenix@tamu.edu>
> Texas A&M CIS Operating Systems Group, Unix   <pckizer@tamu.edu>