Hi, I have currently been given the task of migrating our current LDAP environment from Sun DSEE (6.3.1) to OpenLDAP.
I have done some research on this topic, and suspect its not a trivial task, and am hoping for some pointers/advise from anyone that may have attempted this in the past...
I'm not sure that replication between the two is an option (although would love it if it was :), so I have looked into exporting the current DSEE environment to a LDIF, and attempted to then import it into openldap (using slapadd), but ran into a few issues...
The issue I'm currently stuck on is getting the data in the LDIF into a format that can be imported using slapadd. Currently, I have issues with automounts, pwdReset attribs etc etc...
Any help would be appreciated.
Cheers,
I am currently having same problems. What I thought that transition from sun dsse to redhat Directory Server is more easy since it is both Netscape ldap based (no need to rewrite your schema files.)
On Mon, Mar 21, 2011 at 8:29 AM, adam@spoontech.biz wrote:
Hi, I have currently been given the task of migrating our current LDAP environment from Sun DSEE (6.3.1) to OpenLDAP.
I have done some research on this topic, and suspect its not a trivial task, and am hoping for some pointers/advise from anyone that may have attempted this in the past...
I'm not sure that replication between the two is an option (although would love it if it was :), so I have looked into exporting the current DSEE environment to a LDIF, and attempted to then import it into openldap (using slapadd), but ran into a few issues...
The issue I'm currently stuck on is getting the data in the LDIF into a format that can be imported using slapadd. Currently, I have issues with automounts, pwdReset attribs etc etc...
Any help would be appreciated.
Cheers,
--On Monday, March 21, 2011 11:48:54 AM +0200 Omer Faruk SEN omerfsen@gmail.com wrote:
I am currently having same problems. What I thought that transition from sun dsse to redhat Directory Server is more easy since it is both Netscape ldap based (no need to rewrite your schema files.)
It would surprise me if getting schemas that work will be the big issue for this transition.
On Mon, Mar 21, 2011 at 8:29 AM, adam@spoontech.biz wrote:
Hi, I have currently been given the task of migrating our current LDAP environment from Sun DSEE (6.3.1) to OpenLDAP.
I have done some research on this topic, and suspect its not a trivial task, and am hoping for some pointers/advise from anyone that may have attempted this in the past...
I'm not sure that replication between the two is an option (although would love it if it was :), so I have looked into exporting the current DSEE environment to a LDIF, and attempted to then import it into openldap (using slapadd), but ran into a few issues...
The issue I'm currently stuck on is getting the data in the LDIF into a format that can be imported using slapadd. Currently, I have issues with automounts, pwdReset attribs etc etc...
Why can't you just use ldapsearch on the existing directory and use that as input to slapadd?
Of course, that only gets you the data. I would bet that the real issue will be getting the access controls correct.
Bill
Any help would be appreciated.
Cheers,
Bill MacAllister wrote:
I'm not sure that replication between the two is an option (although would love it if it was :), so I have looked into exporting the current DSEE environment to a LDIF, and attempted to then import it into openldap (using slapadd), but ran into a few issues...
The issue I'm currently stuck on is getting the data in the LDIF into a format that can be imported using slapadd. Currently, I have issues with automounts, pwdReset attribs etc etc...
Why can't you just use ldapsearch on the existing directory and use that as input to slapadd?
slapadd is meant for well-formed LDIF input, mainly from slapcat. DSEE is known to not support schema checking of any kind, therefore any LDIF you obtain from it will most likely be full of garbage and not well-formed. As such, you should only use ldapadd to import it, so you get full error checking on the import.
Of course, that only gets you the data. I would bet that the real issue will be getting the access controls correct.
Thanks to all of you for the advise.
Howard is correct, when using dsconf to export the DSEE catalog, you get some "special" SUN-ONLY attributes, which are not supported/formatted correctly, and therefore cant be imported using slapadd. I read somewhere about stripping those out before performing the import, although I'm not sure whether I would actually need the data stored in these attributes...
Using ldapadd sounds like the way to go, although I'm not sure how this helps me "filter" the special SUN-ONLY attributes... Just ensures I don¹t feed garbage into my new shiny openldap catalog :)
Bills idea of performing a ldapsearch from the openldap box, and somehow feeding that to slapadd/ldapadd sounds like a good plan, but not sure about the best way to get this done...
Will do some more reading, but if anyone has some tips, I'm all ears.
Thanks again,
On 21/03/11 8:55 PM, "Howard Chu" hyc@symas.com wrote:
Bill MacAllister wrote:
I'm not sure that replication between the two is an option (although would love it if it was :), so I have looked into exporting the current DSEE environment to a LDIF, and attempted to then import it into openldap (using slapadd), but ran into a few issues...
The issue I'm currently stuck on is getting the data in the LDIF into a format that can be imported using slapadd. Currently, I have issues with automounts, pwdReset attribs etc etc...
Why can't you just use ldapsearch on the existing directory and use that as input to slapadd?
slapadd is meant for well-formed LDIF input, mainly from slapcat. DSEE is known to not support schema checking of any kind, therefore any LDIF you obtain from it will most likely be full of garbage and not well-formed. As such, you should only use ldapadd to import it, so you get full error checking on the import.
Of course, that only gets you the data. I would bet that the real issue will be getting the access controls correct.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Mon, 21 Mar 2011 03:25:03 -0700 Howard Chu hyc@symas.com wrote:
slapadd is meant for well-formed LDIF input, mainly from slapcat. DSEE is known to not support schema checking of any kind, therefore any LDIF you obtain from it will most likely be full of garbage and not well-formed.
Having just been through this process, I heartily agree. I had to write scripts to go through the output LDIF from DSEE and remove (for example) lines that had attribute names but no values, e.g.
telephoneNumber:
And there were a couple of attribute types (like telephoneNumber and, I believe, 'manager') where I had to go into the schema files and change the syntax type to something more forgiving (directoryString, I think), since DSEE had cheerfully accepted all kinds of arbitrary values for these attributes.
Michael Smith wrote:
And there were a couple of attribute types (like telephoneNumber and, I believe, 'manager') where I had to go into the schema files and change the syntax type to something more forgiving (directoryString, I think), since DSEE had cheerfully accepted all kinds of arbitrary values for these attributes.
You should not change the schema files shipped with OpenLDAP. You should find another solution for sanitizing the data.
(eDirectory is similar fun too...)
Ciao, Michael.
On Mon, 21 Mar 2011 19:44:00 +0100 Michael Ströder michael@stroeder.com wrote:
Michael Smith wrote:
And there were a couple of attribute types (like telephoneNumber and, I believe, 'manager') where I had to go into the schema files and change the syntax type
You should not change the schema files shipped with OpenLDAP. You should find another solution for sanitizing the data.
Of course not. It's a dirty business, computing.
This was largely an organizational culture issue; people had gotten used to putting all kinds of crazy stuff in telephoneNumber, and nobody but nobody understood that 'manager' was supposed to be a DN.
Apart from that, of course, one could have written scripts to canonicalize telephoneNumber and maybe convert a certain number of common names to DNs for the 'manager' attribute. But the amount of manual cleaning-up that would have been required, even after the scripts had done their work, would have been prohibitive.
It was an interesting and enlightening experience. Organizations get used to using their technology in a certain way and for certain purposes. One they've formed their praxis around a lax standard, it's very hard to tighten up. It feels to the users like you're taking something away and imposing rules for rules' sake, without any practical need.
Is this what economists mean by "path dependency"?
openldap-technical@openldap.org
-
Adam Nye -
adam＠spoontech.biz
-
Bill MacAllister -
Howard Chu -
Michael Smith -
Michael Ströder -
Omer Faruk SEN