This stuff looks pretty interesting to me. http://developer.novell.com/linux/index.htm One thing I feel confident about regarding LDAP is XML (or someting very similer) has a big role to play. LDAP schemas should be XMLized. I'm almost positive Netscape/IPlanet has their schema definitions completely specified in XML. I don't believe it was actually XML schema the last time I looked. I believe this Novell/SuSE integration has great potential. I still feel bad that SuSE is not independent anymore, but they couldn't have gone to a better company. STH
On Sat, 2004-02-07 at 00:36, Steven T. Hatton wrote:
One thing I feel confident about regarding LDAP is XML (or someting very similer) has a big role to play. LDAP schemas should be XMLized. I'm almost positive Netscape/IPlanet has their schema definitions completely specified in XML. I don't believe it was actually XML schema the last time I looked. Say no to XML LDAP---LDAP is quite fine the way it is and XML version of LDAP files are a total pain. I convert companies from Novell to OpenLDAP and let me tell you Novell directories are being replaced because Novell talks a good game but their directories are piecemeal and impossible to maintain (type checking even gets disabled as Novell semms tpo work better that way.) -- David Blomberg AIS, APS, ASE, CCNA, LCP, LCA, Linux+, LPI I, MCP, MCSA, MCSE, RHCE, Server+ dblomber@davelinux.com www.davelinux.com
Nihon Libertec dblomber@libertec.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 10 February 2004 08:10 am, David Alan Blomberg wrote:
On Sat, 2004-02-07 at 00:36, Steven T. Hatton wrote:
One thing I feel confident about regarding LDAP is XML (or someting very similer) has a big role to play. LDAP schemas should be XMLized. I'm almost positive Netscape/IPlanet has their schema definitions completely specified in XML. I don't believe it was actually XML schema the last time I looked.
Say no to XML LDAP---LDAP is quite fine the way it is and XML version of LDAP files are a total pain. I convert companies from Novell to OpenLDAP and let me tell you Novell directories are being replaced because Novell talks a good game but their directories are piecemeal and impossible to maintain (type checking even gets disabled as Novell semms tpo work better that way.) -- David Blomberg
In the off chance I finally got my e-mail straightened out, I'm using my new and improved self to send this. There are several advantages to XML over LDAP schema and LDIF. It's been a few years since I worked with LDAP on a regular basis, but I do have a considerable background in the area. The two biggest advantages to XML from my perspective are that it 1) allows for extensive annotation, 2) is (ideally) easier to parse and validate. When you are working with simple directories, this may not be an issue, but when you start dealing with things as complex as access control for the Command and Control, and Combat Support of a deployed Joint Forces mission, there are several limitation one encounters when working with the traditional directory structures. I know very well that people at Novell understand these issues, at least at a theoretical level. When I stopped working in that area (I am incapable of defending people against their own stupidity), LDAP and XML were just beginning to mix. I don't know what others have done with it, but I know what I wanted to do. I will grant that XML can add complexity, and obfuscate certain aspects of LDAP, but this can, and should be handled by tools which parse the XML and present the user/administrator with only the essential data in such a way that it is easily understood and manipulated. I recently installed Novell's eDirectory on a SuSE box. It took a few false starts, but I finally got something up and running. This is really a 'back burner' project for me right now. It isn't inconsistent with my primary focus, but it isn't identical either. I'm trying to really get a handle on workign with stuff such as JAXB and Xindice. I believe object oriented databases have a significant role to pay in creating the Great Mother of all Directories. But that is a subject I keep kicking down the road. STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFAKXvzH2SF0i7rrGwRAupVAKCSA3qrRTOVgLDrwouImvj0eH2S8QCfUHKE Fw13cId0/NPj4l1j56+setM= =mC/Y -----END PGP SIGNATURE-----
On Wed, 2004-02-11 at 09:48, Steven T. Hatton wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday 10 February 2004 08:10 am, David Alan Blomberg wrote:
On Sat, 2004-02-07 at 00:36, Steven T. Hatton wrote:
Say no to XML LDAP---LDAP is quite fine the way it is and XML version of LDAP files are a total pain. I convert companies from Novell to OpenLDAP and let me tell you Novell directories are being replaced
There are several advantages to XML over LDAP schema and LDIF. It's been a few years since I worked with LDAP on a regular basis, but I do have a considerable background in the area. The two biggest advantages to XML from my perspective are that it 1) allows for extensive annotation, 2) is (ideally) easier to parse and validate. unfortunately these annotations seem to never make it in so instead of gaining documentation we only add complexity
When you are working with simple directories, this may not be an issue, but when you start dealing with things as complex as access control for the Command and Control, and Combat Support of a deployed Joint Forces mission, there are several limitation one encounters when working with the traditional directory structures. The above only helps for Novells design many others keep the access control in other areas (which is where I also believe it belongs putting all ACIs in the LDAP system are begging to get cracked and you would never even notice.) I agree it sounds nice but from a security standpoint it is a lot harder to actually troubleshoot the ACIs you are talking about then having access controls in the config files.
I know very well that people at Novell understand these issues, at least at a theoretical level. When I stopped working in that area Novell did a lot for the theory but their system was another story. Their documentation is among the best LDAP reading I have read.
I will grant that XML can add complexity, and obfuscate certain aspects of LDAP, but this can, and should be handled by tools which parse the XML and present the user/administrator with only the essential data in such a way that it is easily understood and manipulated. Heres the largest problem the tools do not exist to clear up the obfuscation. so as was the case 3+ years ago we still have to go back write or adjust our scripts to go through the code. I have yet to find a really nice LDAP admin tool set.
I recently installed Novell's eDirectory on a SuSE box. It took a few false starts, but I finally got something up and running. This is really a 'back burner' project for me right now. It isn't inconsistent with my primary focus, but it isn't identical either. I'm trying to really get a handle on workign with stuff such as JAXB and Xindice. I believe object oriented databases have a significant role to pay in creating the Great Mother of all Directories. But that is a subject I keep kicking down the road. I install OpenLDAP and have only one false start I can recall the rest of the time it has just worked (I have even made some pretty boneheaded mistakes and it still worked) Novell eDirectory is too complex and too bloated. LDAP systems are supposed to be fast and reliable eDirectory is neither. -- David Blomberg AIS, APS, ASE, CCNA, LCP, LCA, Linux+, LPI I, MCP, MCSA, MCSE, RHCE, Server+ dblomber@davelinux.com www.davelinux.com
Nihon Libertec dblomber@libertec.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 11 February 2004 02:13 am, David Alan Blomberg wrote:
On Wed, 2004-02-11 at 09:48, Steven T. Hatton wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Please foregive the failure to prune the original message, but this discussion has become a bit stale due to my failure to respond.
On Tuesday 10 February 2004 08:10 am, David Alan Blomberg wrote:
On Sat, 2004-02-07 at 00:36, Steven T. Hatton wrote:
Say no to XML LDAP---LDAP is quite fine the way it is and XML version of LDAP files are a total pain. I convert companies from Novell to OpenLDAP and let me tell you Novell directories are being replaced
There are several advantages to XML over LDAP schema and LDIF. It's been a few years since I worked with LDAP on a regular basis, but I do have a considerable background in the area. The two biggest advantages to XML from my perspective are that it 1) allows for extensive annotation, 2) is (ideally) easier to parse and validate.
unfortunately these annotations seem to never make it in so instead of gaining documentation we only add complexity
This is not always the case. I do know sun has made use of that feature in some of their J2EE schemas, and IIRC, iPlanet did the same with their LDAP server. You still gain the ease of parsing the XML when writing code, even if the XML is not annotated.
When you are working with simple directories, this may not be an issue, but when you start dealing with things as complex as access control for the Command and Control, and Combat Support of a deployed Joint Forces mission, there are several limitation one encounters when working with the traditional directory structures.
The above only helps for Novells design many others keep the access control in other areas (which is where I also believe it belongs putting all ACIs in the LDAP system are begging to get cracked and you would never even notice.) I agree it sounds nice but from a security standpoint it is a lot harder to actually troubleshoot the ACIs you are talking about then having access controls in the config files.
I can't say a lot about this, but I really wasn't talking about putting the ACLs in the LDAP directory.
I know very well that people at Novell understand these issues, at least at a theoretical level. When I stopped working in that area
Novell did a lot for the theory but their system was another story. Their documentation is among the best LDAP reading I have read.
I can't comment on the implementation since I have little road experience with it.
I will grant that XML can add complexity, and obfuscate certain aspects of LDAP, but this can, and should be handled by tools which parse the XML and present the user/administrator with only the essential data in such a way that it is easily understood and manipulated.
Heres the largest problem the tools do not exist to clear up the obfuscation. so as was the case 3+ years ago we still have to go back write or adjust our scripts to go through the code. I have yet to find a really nice LDAP admin tool set.
People tend to think of UI as a trivial end of programming, but my experience tells me it can be damn difficult. I'm trying to learn the art with XUL, Swing, and QT.
I recently installed Novell's eDirectory on a SuSE box. It took a few false starts, but I finally got something up and running. This is really a 'back burner' project for me right now. It isn't inconsistent with my primary focus, but it isn't identical either. I'm trying to really get a handle on workign with stuff such as JAXB and Xindice. I believe object oriented databases have a significant role to pay in creating the Great Mother of all Directories. But that is a subject I keep kicking down the road.
I install OpenLDAP and have only one false start I can recall the rest of the time it has just worked (I have even made some pretty boneheaded mistakes and it still worked) Novell eDirectory is too complex and too bloated. LDAP systems are supposed to be fast and reliable eDirectory is neither.
eDirectory does seem to be resource hungry. It's one of the few services I've run on my development box that noticeably slows it down. Un fortunately, that is going to stay on the back burner for a while. When I said false starts, I meant shot in the dark installations that went bad. I really didn't put a whole bunch of effort into OpenLDAP this time around. The ouch was regarding the general picture of what I was looking at. It just happens the OpenLDAP what the point where I threw in the towel.
-- David Blomberg
STH -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQFALk82H2SF0i7rrGwRAoPPAKC2DRfKIGEkDUdcoFSBK2NX/i9JtQCfbteS sXnx7zDSAJ2hN18eLeJ86/g= =UcuY -----END PGP SIGNATURE-----
participants (3)
-
David Alan Blomberg -
Steven T. Hatton -
Steven T. Hatton