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_D...
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_D...
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.
389-users@lists.fedoraproject.org