In the past I haved developed a modular metadirectory for a
large enterprise and have a few comments about your design. I have not
looked through the source code, so correct my where I am wrong, but have
scanned the documentation. The comments of this message are things that
I would have done differently (that is not to say better). It depends
on what you are trying to accomplish with your metadirectory.
Transactions: I would not have put these in. In practice, the
number of changes in a directory service is very low compared to its
size. The chances of the same account being modified independently are
remote and the problem is *easily* solved. Also, for transactions to be
effective, the methods in the custom modules have to be atomic (that is
they cannot abort half way through without cleaning up after
themselves). This adds to the development overhead of the directory and
is not realistic.
Applications Support: It looks like you are focused on general
directory support (such as LDAP or NIS). The big payoff for a
metadirectory is in application support. Most of the user
authentication at an enterprise is to custom applications which have
their own login / passwords. The management overhead of these is much
larger than the management of your OS level user directory services.
Also, many of these applications are now located at remote ASP's instead
of inhouse. Remote ASP's are reluctant to trust your LDAP/Active
Directory Services.
Self Checking: When you start to manage many (20+) different types
of accounts. You will see your central metadirectory database slowly
become out of sync with the remote directories and applications. You
need to incorporate into your design, the ability for your metadirectory
to query the remote directories and applications to check itself. Some
of these sync issues will be due to independent systems/application
administrators. Some will be due to imperfect programmers.
We are currently deploying a few hundred LDAP servers to administer several thousand email accounts and several thousand Linux NCs (IBM 2800's). We decided to go with Netscape's LDAP server for a few reasons.
A. NDS was only in Beta on Linux at the time.
B. LDAP compatibility. In our test pilot, we did run into some LDAP compatibility issues. They seem to occur in the way in which NDS classes and attributes are mapped to/from LDAP.
C. The Netscape LDAP Server has a simpler and more open design that better fits our work philosphy. NDS relies on a multi-master approach for replication. This has many advantages, but it raises the complexity of the directory network. By staying with a simple Master/Client model for replication and controlling the directory writes (we are fortunate that we are able to do this), we will have a directory service which will be extremely stable and have nearly zero administrative costs. Our design philosophy is basically to keep everything stateless and easily replaceable.
Where the multi-master replication model has the strong advantage is when data in the directory needs to be changed often and at several different locations. In short if you have to change your data often and at several different locations then you are not looking at an optimal directory service.
Slashdot Mirror
North Dakota is a bad idea for no particular reason. Come to South Dakota instead.
BTW I think this project is a good deal. Didn't mean to be negative towards it in the previous post
In the past I haved developed a modular metadirectory for a large enterprise and have a few comments about your design. I have not looked through the source code, so correct my where I am wrong, but have scanned the documentation. The comments of this message are things that I would have done differently (that is not to say better). It depends on what you are trying to accomplish with your metadirectory.
Transactions: I would not have put these in. In practice, the number of changes in a directory service is very low compared to its size. The chances of the same account being modified independently are remote and the problem is *easily* solved. Also, for transactions to be effective, the methods in the custom modules have to be atomic (that is they cannot abort half way through without cleaning up after themselves). This adds to the development overhead of the directory and is not realistic.
Applications Support: It looks like you are focused on general directory support (such as LDAP or NIS). The big payoff for a metadirectory is in application support. Most of the user authentication at an enterprise is to custom applications which have their own login / passwords. The management overhead of these is much larger than the management of your OS level user directory services. Also, many of these applications are now located at remote ASP's instead of inhouse. Remote ASP's are reluctant to trust your LDAP/Active Directory Services.
Self Checking: When you start to manage many (20+) different types of accounts. You will see your central metadirectory database slowly become out of sync with the remote directories and applications. You need to incorporate into your design, the ability for your metadirectory to query the remote directories and applications to check itself. Some of these sync issues will be due to independent systems/application administrators. Some will be due to imperfect programmers.
We are currently deploying a few hundred LDAP servers to administer several thousand email accounts and several thousand Linux NCs (IBM 2800's). We decided to go with Netscape's LDAP server for a few reasons.
A. NDS was only in Beta on Linux at the time.
B. LDAP compatibility. In our test pilot, we did run into some LDAP compatibility issues. They seem to occur in the way in which NDS classes and attributes are mapped to/from LDAP.
C. The Netscape LDAP Server has a simpler and more open design that better fits our work philosphy. NDS relies on a multi-master approach for replication. This has many advantages, but it raises the complexity of the directory network. By staying with a simple Master/Client model for replication and controlling the directory writes (we are fortunate that we are able to do this), we will have a directory service which will be extremely stable and have nearly zero administrative costs. Our design philosophy is basically to keep everything stateless and easily replaceable.
Where the multi-master replication model has the strong advantage is when data in the directory needs to be changed often and at several different locations. In short if you have to change your data often and at several different locations then you are not looking at an optimal directory service.