Hi,
currently I am redesigning the ldap server for a site which has about 700 users, with approximatly 200 new user per year, and maybe a little less dropping out every year.
The information about the lifetime of an account is kept in a different database(mysql). Thus, in order to check if an account is expired, I need to check with that database. While this might not be the happiest situation, it is partly due to historical rereasons, partly due to other restrictions beyond my reach. In any case, there is nothing I can do about it.
Now I would like to have a way to make shure that usernames and numerical uids will never get reused. Also, I would like to keep trac of who had an account, sort of a history.
Two ideas came to my mind: 1. Have an "expired" flag in the schema. Records with the expired flag would be blocked from login with an appropriate acl. 2. Have an archive subtree, where expired records get moved to.
The beauty of the first idea seems to me that it is very simple. The downside is that there would be two places where the expired flag would live, the ldap server and the other database (see above). Also, over the years, the number of records in the people subtree would grow and grow (not shure if this is an disadvantage though).
The beauty of the second idea is that the people subtree would be "clean", containing only active accounts. The downside seems to me that it looks a bit more involved.
Now I was wondering how other people have solved this, or if anyone would favor on of the solution.
thank you, Isaac
On 07/22/10 12:49 AM, Isaac Hailperin wrote:
Hi,
currently I am redesigning the ldap server for a site which has about 700 users, with approximatly 200 new user per year, and maybe a little less dropping out every year.
The information about the lifetime of an account is kept in a different database(mysql). Thus, in order to check if an account is expired, I need to check with that database. While this might not be the happiest situation, it is partly due to historical rereasons, partly due to other restrictions beyond my reach. In any case, there is nothing I can do about it.
Now I would like to have a way to make shure that usernames and numerical uids will never get reused. Also, I would like to keep trac of who had an account, sort of a history.
Two ideas came to my mind:
- Have an "expired" flag in the schema. Records with the expired flag
would be blocked from login with an appropriate acl. 2. Have an archive subtree, where expired records get moved to.
The beauty of the first idea seems to me that it is very simple. The downside is that there would be two places where the expired flag would live, the ldap server and the other database (see above). Also, over the years, the number of records in the people subtree would grow and grow (not shure if this is an disadvantage though).
The beauty of the second idea is that the people subtree would be "clean", containing only active accounts. The downside seems to me that it looks a bit more involved.
Now I was wondering how other people have solved this, or if anyone would favor on of the solution.
I work with an organisation of similar size and we delete leavers form the LDAP server and just archive their home directories.
One disadvantage of 1 is your database will grow and your searches will become slower.
LDAP isn't really the place for archival data, if you want to preserve it export the LDIF for the user and archive that.
One disadvantage of 1 is your database will grow and your searches will become slower.
LDAP isn't really the place for archival data, if you want to preserve it export the LDIF for the user and archive that.
Exporting each "deleted" user to a seperate LDIF file will make the server faster for regular searches, but it will be much slower if I want to check if a new username has ever been used (something which I want to avoid).
But if I understand correct, the search can be restricted to a certain subtree. So if I would archive in a different subtree, the frequent, regular searches will stay fast. And the not so frequent searches for all usernames that have ever been issued will be a bit slower, because it will also incorporate the archive subtree. But that archive subtree should still be much faster to query then hundreds of files, because they all live in a single file (or maybe just a few, depending on the db backend I guess).
Any thoughts on this?
Isaac
On 07/23/10 03:28 AM, Isaac Hailperin wrote:
One disadvantage of 1 is your database will grow and your searches will become slower.
LDAP isn't really the place for archival data, if you want to preserve it export the LDIF for the user and archive that.
Exporting each "deleted" user to a seperate LDIF file will make the server faster for regular searches, but it will be much slower if I want to check if a new username has ever been used (something which I want to avoid).
But if I understand correct, the search can be restricted to a certain subtree. So if I would archive in a different subtree, the frequent, regular searches will stay fast. And the not so frequent searches for all usernames that have ever been issued will be a bit slower, because it will also incorporate the archive subtree. But that archive subtree should still be much faster to query then hundreds of files, because they all live in a single file (or maybe just a few, depending on the db backend I guess).
Any thoughts on this?
I still think you are using the wrong tool for the job. LDAP isn't a general database tool, keep your archives and user management logic in a separate application.
You could move leavers to another branch, but you would have to delete the entries and create new ones to update their dn, so you may as well move them somewhere else!
Ian Collins wrote:
On 07/23/10 03:28 AM, Isaac Hailperin wrote:
One disadvantage of 1 is your database will grow and your searches will become slower.
LDAP isn't really the place for archival data, if you want to preserve it export the LDIF for the user and archive that.
Exporting each "deleted" user to a seperate LDIF file will make the server faster for regular searches, but it will be much slower if I want to check if a new username has ever been used (something which I want to avoid).
But if I understand correct, the search can be restricted to a certain subtree. So if I would archive in a different subtree, the frequent, regular searches will stay fast. And the not so frequent searches for all usernames that have ever been issued will be a bit slower, because it will also incorporate the archive subtree. But that archive subtree should still be much faster to query then hundreds of files, because they all live in a single file (or maybe just a few, depending on the db backend I guess).
Any thoughts on this?
I still think you are using the wrong tool for the job. LDAP isn't a general database tool, keep your archives and user management logic in a separate application.
You could move leavers to another branch, but you would have to delete the entries and create new ones to update their dn, so you may as well move them somewhere else!
You don't have to delete and re-create - just Move.
Frankly in OpenLDAP either approach would work fine and there would be no measurable performance difference assuming your cache and indexing are configured properly.
LDAP *is* a database. Not "general" in that it is optimized for hierarchical data instead of tabular data, but aside from that, there's no reason not to use it as a long term store. (And relational databases are by no means general either, since they are only optimal for tabular data, not hierarchical or recursive data...)
openldap-technical@openldap.org
-
Howard Chu -
Ian Collins -
Isaac Hailperin