Fedora directory users - Feb 2008 - Help needed migrating from Sun ONE to Fedora DS 1.1

I''m reasonably new to LDAP and very new to Fedora''s
DirectoryServer.
I''m trying to "migrate" (I use the term loosely) from a Sun
ONE
(specifically, JES 2004Q2, which is Directory Server 5.2) LDAP server  
to a Fedora Core 8 server running DS 1.1.0 (installed from a yum  
respository''s binary).

My problems are twofold: I have custom schema authored by Bowdoin (a  
college, my employer), and I have schema that comes from Sun''s  
implementation of LDAP. For example, on the Sun server, 99user.ldif  
contains the following:

objectClasses: ( nsmsgCfgmtaautoreplyhandler-oid NAME  
''nsmsgCfgmtaautoreplyhan
  dler'' SUP top STRUCTURAL MUST cn MAY ( nsmsgDefaultecho $  
nsmsgDefaultreply
  $ nsmsgDefaultvacation ) X-ORIGIN ( ''iPlanet Messaging Server  
configuration''
   ''user defined'' ) )

(which is for iPlanet, a part of Sun''s... well, whatever)

As well as:

attributeTypes: ( majorname-oid NAME ''majorname'' DESC
''Major Full
Name'' SYNTAX
   1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN ''user defined'' )

Which is used to track students'' majors. I tried following the  
instructions I found here:
http://www.redhat.com/docs/manuals/dir-server/MigrateFromSun.html
  and "converting" the 99user.ldif file into a more typical LDIF and  
adding that with ldapmodify, but that didn''t work particularly well --
a lot of the Sun-specific schema was rejected by Fedora DS. Then I  
tried removing what I thought was the Sun schema extensions leaving  
Bowdoin''s extensions, and that seemed to work (with one or two strange
exceptions).

However, when I tried to import the LDIF full of users from the Sun  
system (which I dumped with db2ldif), I get a whole host of errors:  
mostly things like "Error adding object ''dn:  
cn=Administrators,o=Bowdoin College,c=US''.  The error sent by the  
server was ''Object class violation. attribute
"mgmanmembervisibility"
not allowed". I''m no expert, but I presume this is because the
LDIF of
users still contains references to the Sun schema attributes. So, here  
are my questions:

* why can''t I import the Sun schema if that''s what I want to
do?
* if I can''t import the Sun schema, is there an easy way of stripping  
out the Sun attributes from a 10,000-user LDIF file?

Thanks,


Chris

Chris Waltham wrote:
> I''m reasonably new to LDAP and very new to Fedora''s
DirectoryServer.
> I''m trying to "migrate" (I use the term loosely) from a
Sun ONE
> (specifically, JES 2004Q2, which is Directory Server 5.2) LDAP server 
> to a Fedora Core 8 server running DS 1.1.0 (installed from a yum 
> respository''s binary).
>
> My problems are twofold: I have custom schema authored by Bowdoin (a 
> college, my employer), and I have schema that comes from Sun''s 
> implementation of LDAP. For example, on the Sun server, 99user.ldif 
> contains the following:
>
> objectClasses: ( nsmsgCfgmtaautoreplyhandler-oid NAME 
> ''nsmsgCfgmtaautoreplyhan
>  dler'' SUP top STRUCTURAL MUST cn MAY ( nsmsgDefaultecho $ 
> nsmsgDefaultreply
>  $ nsmsgDefaultvacation ) X-ORIGIN ( ''iPlanet Messaging Server 
> configuration''
>   ''user defined'' ) )
>
> (which is for iPlanet, a part of Sun''s... well, whatever)
>
> As well as:
>
> attributeTypes: ( majorname-oid NAME ''majorname'' DESC
''Major Full
> Name'' SYNTAX
>   1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN ''user defined'' )
>
> Which is used to track students'' majors. I tried following the 
> instructions I found here: 
> http://www.redhat.com/docs/manuals/dir-server/MigrateFromSun.html and 
> "converting" the 99user.ldif file into a more typical LDIF and
adding
> that with ldapmodify, but that didn''t work particularly well -- a
lot
> of the Sun-specific schema was rejected by Fedora DS. Then I tried 
> removing what I thought was the Sun schema extensions leaving 
> Bowdoin''s extensions, and that seemed to work (with one or two
strange
> exceptions).
>
> However, when I tried to import the LDIF full of users from the Sun 
> system (which I dumped with db2ldif), I get a whole host of errors: 
> mostly things like "Error adding object ''dn: 
> cn=Administrators,o=Bowdoin College,c=US''.  The error sent by the 
> server was ''Object class violation. attribute
"mgmanmembervisibility"
> not allowed". I''m no expert, but I presume this is because
the LDIF of
> users still contains references to the Sun schema attributes. So, here 
> are my questions:
>
> * why can''t I import the Sun schema if that''s what I want
to do?
You should be able to do that.  It''s really odd that Sun defined schema
is in 99user.ldif - that file is reserved solely for user defined schema 
added via LDAP.  You''ll have to post the errors here so we can address 
the issues.
> * if I can''t import the Sun schema, is there an easy way of
stripping
> out the Sun attributes from a 10,000-user LDIF file?
If you are a Perl hacker, you could use Mozilla perldap (included with 
the fedora ds software) or Net::LDAP (probably bundled with your linux 
OS perl distribution).  If you prefer python, python-ldap also has an 
LDIF parser.
>
> Thanks,
>
>
> Chris
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

On Feb 7, 2008, at 4:33 PM, Rich Megginson wrote:
> Chris Waltham wrote:
>> * why can''t I import the Sun schema if that''s what I
want to do?
> You should be able to do that.  It''s really odd that Sun defined  
> schema is in 99user.ldif - that file is reserved solely for user  
> defined schema added via LDAP.  You''ll have to post the errors
here
> so we can address the issues.
I did one better: I simply copied the entire config/schema/ directory  
from the Sun box to the Fedora box, and tried to restart Fedora DS. I  
got some non-fatal errors:

[root@hebron slapd-hebron]# /etc/init.d/dirsrv start
Starting dirsrv:
     hebron...[07/Feb/2008:16:41:00 -0500] - Entry "cn=SNMP,cn=config"
-- attribute "nssnmpname" not allowed
[07/Feb/2008:16:41:00 -0500] - Entry "cn=PAM Pass Through  
Auth,cn=plugins,cn=config" has unknown object class "pamConfig"
[07/Feb/2008:16:41:00 -0500] - Entry "cn=Kerberos uid  
mapping,cn=mapping,cn=sasl,cn=config" has unknown object class  
"nsSaslMapping"
[07/Feb/2008:16:41:00 -0500] - Entry "cn=rfc 2829 dn  
syntax,cn=mapping,cn=sasl,cn=config" has unknown object class  
"nsSaslMapping"
[07/Feb/2008:16:41:00 -0500] - Entry "cn=rfc 2829 u  
syntax,cn=mapping,cn=sasl,cn=config" has unknown object class  
"nsSaslMapping"
[07/Feb/2008:16:41:00 -0500] - Entry "cn=uid  
mapping,cn=mapping,cn=sasl,cn=config" has unknown object class  
"nsSaslMapping"
[07/Feb/2008:16:41:00 -0500] - Entry "cn=SNMP,cn=config" -- attribute
"nssnmpname" not allowed
                                                            [  OK  ]

That gave me some hope, so then I tried to import my database from an  
LDAP. FWIW, this is how I generated the LDIF on the Sun box:

db2ldif ''o=Bowdoin College, c=US''

Then I just tried this in Fedora:

/usr/lib/dirsrv/slapd-hebron/ldif2db -s ''o=Bowdoin College,
c=US'' -i /
path/to/dumpfile.ldif

And I got the following errors:

importing data ...
[07/Feb/2008:16:41:08 -0500] - Entry "cn=SNMP,cn=config" -- attribute
"nssnmpname" not allowed
[07/Feb/2008:16:41:08 -0500] - Entry "cn=PAM Pass Through  
Auth,cn=plugins,cn=config" has unknown object class "pamConfig"
[07/Feb/2008:16:41:08 -0500] - Entry "cn=Kerberos uid  
mapping,cn=mapping,cn=sasl,cn=config" has unknown object class  
"nsSaslMapping"
[07/Feb/2008:16:41:08 -0500] - Entry "cn=rfc 2829 dn  
syntax,cn=mapping,cn=sasl,cn=config" has unknown object class  
"nsSaslMapping"
[07/Feb/2008:16:41:08 -0500] - Entry "cn=rfc 2829 u  
syntax,cn=mapping,cn=sasl,cn=config" has unknown object class  
"nsSaslMapping"
[07/Feb/2008:16:41:08 -0500] - Entry "cn=uid  
mapping,cn=mapping,cn=sasl,cn=config" has unknown object class  
"nsSaslMapping"
[07/Feb/2008:16:41:08 -0500] - Entry "cn=SNMP,cn=config" -- attribute
"nssnmpname" not allowed
[07/Feb/2008:16:41:08 -0500] - ERROR 2: There is no backend instance  
to import to.

To be honest, I am a little confused at the relationship between  
instances and backends. From what I can see, Sun includes the  
following instances: userRoot, internetdb, pab and netscapeRoot (and  
possibly others?). But, I only have one suffix that I need, which is  
o=Bowdoin College, c=US.


Chris
>
>> * if I can''t import the Sun schema, is there an easy way of  
>> stripping out the Sun attributes from a 10,000-user LDIF file?
> If you are a Perl hacker, you could use Mozilla perldap (included  
> with the fedora ds software) or Net::LDAP (probably bundled with  
> your linux OS perl distribution).  If you prefer python, python-ldap  
> also has an LDIF parser.
>>
>> Thanks,
>>
>>
>> Chris

Chris Waltham wrote:
> On Feb 7, 2008, at 4:33 PM, Rich Megginson wrote:
>
>> Chris Waltham wrote:
>>> * why can''t I import the Sun schema if that''s
what I want to do?
>> You should be able to do that.  It''s really odd that Sun
defined
>> schema is in 99user.ldif - that file is reserved solely for user 
>> defined schema added via LDAP.  You''ll have to post the errors
here
>> so we can address the issues.
>
> I did one better: I simply copied the entire config/schema/ directory 
> from the Sun box to the Fedora box, and tried to restart Fedora DS.
It would probably be better to only copy the files not already in the 
Fedora DS schema directory e.g. pseudocode

for file in sun/config/schema/*.ldif
  name=`basename $file`
  if [ ! -f /etc/dirsrv/slapd-instancename/schema/$name ] ; then
    cp $file /etc/dirsrv/slapd-instancename/schema/$name
  fi
done

Because the Fedora DS schema has changed someone.  For starters, our new 
00core.ldif contains only the very core essential schema required to 
start the server - the non-essential schema has been moved to 
01common.ldif.  Their 00core.ldif probably still contains everything.  
So if you overwrite the fedora ds 00core.ldif with theirs, chaos will
ensue.
> I got some non-fatal errors:
>
> [root@hebron slapd-hebron]# /etc/init.d/dirsrv start
> Starting dirsrv:
>     hebron...[07/Feb/2008:16:41:00 -0500] - Entry
"cn=SNMP,cn=config"
> -- attribute "nssnmpname" not allowed
> [07/Feb/2008:16:41:00 -0500] - Entry "cn=PAM Pass Through 
> Auth,cn=plugins,cn=config" has unknown object class
"pamConfig"
> [07/Feb/2008:16:41:00 -0500] - Entry "cn=Kerberos uid 
> mapping,cn=mapping,cn=sasl,cn=config" has unknown object class 
> "nsSaslMapping"
> [07/Feb/2008:16:41:00 -0500] - Entry "cn=rfc 2829 dn 
> syntax,cn=mapping,cn=sasl,cn=config" has unknown object class 
> "nsSaslMapping"
> [07/Feb/2008:16:41:00 -0500] - Entry "cn=rfc 2829 u 
> syntax,cn=mapping,cn=sasl,cn=config" has unknown object class 
> "nsSaslMapping"
> [07/Feb/2008:16:41:00 -0500] - Entry "cn=uid 
> mapping,cn=mapping,cn=sasl,cn=config" has unknown object class 
> "nsSaslMapping"
> [07/Feb/2008:16:41:00 -0500] - Entry "cn=SNMP,cn=config" --
attribute
> "nssnmpname" not allowed
>                                                            [  OK  ]
>
> That gave me some hope, so then I tried to import my database from an 
> LDAP. FWIW, this is how I generated the LDIF on the Sun box:
>
> db2ldif ''o=Bowdoin College, c=US''
>
> Then I just tried this in Fedora:
>
> /usr/lib/dirsrv/slapd-hebron/ldif2db -s ''o=Bowdoin College,
c=US'' -i
> /path/to/dumpfile.ldif
>
> And I got the following errors:
>
> importing data ...
> [07/Feb/2008:16:41:08 -0500] - Entry "cn=SNMP,cn=config" --
attribute
> "nssnmpname" not allowed
> [07/Feb/2008:16:41:08 -0500] - Entry "cn=PAM Pass Through 
> Auth,cn=plugins,cn=config" has unknown object class
"pamConfig"
> [07/Feb/2008:16:41:08 -0500] - Entry "cn=Kerberos uid 
> mapping,cn=mapping,cn=sasl,cn=config" has unknown object class 
> "nsSaslMapping"
> [07/Feb/2008:16:41:08 -0500] - Entry "cn=rfc 2829 dn 
> syntax,cn=mapping,cn=sasl,cn=config" has unknown object class 
> "nsSaslMapping"
> [07/Feb/2008:16:41:08 -0500] - Entry "cn=rfc 2829 u 
> syntax,cn=mapping,cn=sasl,cn=config" has unknown object class 
> "nsSaslMapping"
> [07/Feb/2008:16:41:08 -0500] - Entry "cn=uid 
> mapping,cn=mapping,cn=sasl,cn=config" has unknown object class 
> "nsSaslMapping"
> [07/Feb/2008:16:41:08 -0500] - Entry "cn=SNMP,cn=config" --
attribute
> "nssnmpname" not allowed
> [07/Feb/2008:16:41:08 -0500] - ERROR 2: There is no backend instance 
> to import to.
>
> To be honest, I am a little confused at the relationship between 
> instances and backends. From what I can see, Sun includes the 
> following instances: userRoot, internetdb, pab and netscapeRoot (and 
> possibly others?). But, I only have one suffix that I need, which is 
> o=Bowdoin College, c=US.
You might try the migrate-ds-admin.pl script.  It might be able to 
handle the Sun data.  Use -o /opt/iplanet or whatever they use for their 
server root directory.

If migration does not work, then you will at least have to create a 
database and configure a suffix for o=Bowdoin College, c=US
See - 
http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Configuring_Directory_Databases.html
>
>
> Chris
>
>>
>>> * if I can''t import the Sun schema, is there an easy way
of
>>> stripping out the Sun attributes from a 10,000-user LDIF file?
>> If you are a Perl hacker, you could use Mozilla perldap (included 
>> with the fedora ds software) or Net::LDAP (probably bundled with your 
>> linux OS perl distribution).  If you prefer python, python-ldap also 
>> has an LDIF parser.
>>>
>>> Thanks,
>>>
>>>
>>> Chris
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Also you may not even need to copy the SUN schema unless you really
need it. Use the default FDS schema and then add your custom schema.
Then import some data, if your just importing common objects they
might not even require that schema.

Edward

On Feb 7, 2008 4:56 PM, Rich Megginson <rmeggins@redhat.com>
wrote:
> Chris Waltham wrote:
> > On Feb 7, 2008, at 4:33 PM, Rich Megginson wrote:
> >
> >> Chris Waltham wrote:
> >>> * why can''t I import the Sun schema if
that''s what I want to do?
> >> You should be able to do that.  It''s really odd that Sun
defined
> >> schema is in 99user.ldif - that file is reserved solely for user
> >> defined schema added via LDAP.  You''ll have to post the
errors here
> >> so we can address the issues.
> >
> > I did one better: I simply copied the entire config/schema/ directory
> > from the Sun box to the Fedora box, and tried to restart Fedora DS.
> It would probably be better to only copy the files not already in the
> Fedora DS schema directory e.g. pseudocode
>
> for file in sun/config/schema/*.ldif
>   name=`basename $file`
>   if [ ! -f /etc/dirsrv/slapd-instancename/schema/$name ] ; then
>     cp $file /etc/dirsrv/slapd-instancename/schema/$name
>   fi
> done
>
> Because the Fedora DS schema has changed someone.  For starters, our new
> 00core.ldif contains only the very core essential schema required to
> start the server - the non-essential schema has been moved to
> 01common.ldif.  Their 00core.ldif probably still contains everything.
> So if you overwrite the fedora ds 00core.ldif with theirs, chaos will
ensue.
>
> > I got some non-fatal errors:
> >
> > [root@hebron slapd-hebron]# /etc/init.d/dirsrv start
> > Starting dirsrv:
> >     hebron...[07/Feb/2008:16:41:00 -0500] - Entry
"cn=SNMP,cn=config"
> > -- attribute "nssnmpname" not allowed
> > [07/Feb/2008:16:41:00 -0500] - Entry "cn=PAM Pass Through
> > Auth,cn=plugins,cn=config" has unknown object class
"pamConfig"
> > [07/Feb/2008:16:41:00 -0500] - Entry "cn=Kerberos uid
> > mapping,cn=mapping,cn=sasl,cn=config" has unknown object class
> > "nsSaslMapping"
> > [07/Feb/2008:16:41:00 -0500] - Entry "cn=rfc 2829 dn
> > syntax,cn=mapping,cn=sasl,cn=config" has unknown object class
> > "nsSaslMapping"
> > [07/Feb/2008:16:41:00 -0500] - Entry "cn=rfc 2829 u
> > syntax,cn=mapping,cn=sasl,cn=config" has unknown object class
> > "nsSaslMapping"
> > [07/Feb/2008:16:41:00 -0500] - Entry "cn=uid
> > mapping,cn=mapping,cn=sasl,cn=config" has unknown object class
> > "nsSaslMapping"
> > [07/Feb/2008:16:41:00 -0500] - Entry "cn=SNMP,cn=config" --
attribute
> > "nssnmpname" not allowed
> >                                                            [  OK  ]
> >
> > That gave me some hope, so then I tried to import my database from an
> > LDAP. FWIW, this is how I generated the LDIF on the Sun box:
> >
> > db2ldif ''o=Bowdoin College, c=US''
> >
> > Then I just tried this in Fedora:
> >
> > /usr/lib/dirsrv/slapd-hebron/ldif2db -s ''o=Bowdoin College,
c=US'' -i
> > /path/to/dumpfile.ldif
> >
> > And I got the following errors:
> >
> > importing data ...
> > [07/Feb/2008:16:41:08 -0500] - Entry "cn=SNMP,cn=config" --
attribute
> > "nssnmpname" not allowed
> > [07/Feb/2008:16:41:08 -0500] - Entry "cn=PAM Pass Through
> > Auth,cn=plugins,cn=config" has unknown object class
"pamConfig"
> > [07/Feb/2008:16:41:08 -0500] - Entry "cn=Kerberos uid
> > mapping,cn=mapping,cn=sasl,cn=config" has unknown object class
> > "nsSaslMapping"
> > [07/Feb/2008:16:41:08 -0500] - Entry "cn=rfc 2829 dn
> > syntax,cn=mapping,cn=sasl,cn=config" has unknown object class
> > "nsSaslMapping"
> > [07/Feb/2008:16:41:08 -0500] - Entry "cn=rfc 2829 u
> > syntax,cn=mapping,cn=sasl,cn=config" has unknown object class
> > "nsSaslMapping"
> > [07/Feb/2008:16:41:08 -0500] - Entry "cn=uid
> > mapping,cn=mapping,cn=sasl,cn=config" has unknown object class
> > "nsSaslMapping"
> > [07/Feb/2008:16:41:08 -0500] - Entry "cn=SNMP,cn=config" --
attribute
> > "nssnmpname" not allowed
> > [07/Feb/2008:16:41:08 -0500] - ERROR 2: There is no backend instance
> > to import to.
> >
> > To be honest, I am a little confused at the relationship between
> > instances and backends. From what I can see, Sun includes the
> > following instances: userRoot, internetdb, pab and netscapeRoot (and
> > possibly others?). But, I only have one suffix that I need, which is
> > o=Bowdoin College, c=US.
> You might try the migrate-ds-admin.pl script.  It might be able to
> handle the Sun data.  Use -o /opt/iplanet or whatever they use for their
> server root directory.
>
> If migration does not work, then you will at least have to create a
> database and configure a suffix for o=Bowdoin College, c=US
> See -
>
http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Configuring_Directory_Databases.html
>
> >
> >
> > Chris
> >
> >>
> >>> * if I can''t import the Sun schema, is there an easy
way of
> >>> stripping out the Sun attributes from a 10,000-user LDIF file?
> >> If you are a Perl hacker, you could use Mozilla perldap (included
> >> with the fedora ds software) or Net::LDAP (probably bundled with
your
> >> linux OS perl distribution).  If you prefer python, python-ldap
also
> >> has an LDIF parser.
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> Chris
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>

Rich Megginson wrote:
> Chris Waltham wrote:
>> * if I can''t import the Sun schema, is there an easy way of
stripping
>> out the Sun attributes from a 10,000-user LDIF file?
> If you are a Perl hacker, you could use Mozilla perldap (included with 
> the fedora ds software) or Net::LDAP (probably bundled with your linux 
> OS perl distribution).  If you prefer python, python-ldap also has an 
> LDIF parser.
python-ldap also has a schema parser with which you could follow 
cross-references between schema elements programmatically...

Ciao, Michael.