Slashdot Mirror
Ganymede 1.0 Released
jonabbey writes: "After five and a half years of development, we have just released Ganymede 1.0. Ganymede is a GPL'ed metadirectory system, that allows you to put an NDS or Active Directory style concurrent GUI in front of your network's NIS, LDAP, Windows NT PDC, Samba, and even DNS directory services. Ganymede 1.0 comes with a userKit to support password synchronization to UNIX, Windows NT, and Samba. The Ganymede clients work anywhere Java does, and have been tested on Linux, BSD, Solaris, Windows NT, Mac OS, and OS/2."
Many thanks for the comments, Jeff. I agree with you about the difficulty of handling transactions. Ganymede and GASH before it are both really obsessed with providing a lot of interactive hand holding for the user, and Ganymede is especially obsessed with providing really fine grained concurrency, and transactions seemed like the way to handle that, especially since things like NIS and DNS tend to require complete rebuilds when you make updates.
Ganymede is completely and totally my "second system", to quote Frederick Brooks. It is bigger and more complicated than it needs to be because I chose to optimize for some peculiar things. Ganymede is great for what it is, but what it is is in many ways kind of an odd duck. Its good points come out of our experience with GASH, so I do know that it works really very well for managment of a single domain network environment.
When I started writing Ganymede, I had never heard of the word 'metadirectory'. I only applied it after the fact, to try and express the fact that I intended Ganymede to manage other directory services, and not to be the primary directory service consulted by everything.
Thanks very much for your insights, I would have loved to have kicked these ideas around with you about five years ago. ;-)
- jon
- jon
Ganymede, a GPL'ed metadirectory for UNIX
All reasonable, excellent, and obvious points.
I chose the back-end approach that I did for several reasons. First, when I started designing Ganymede back at the tail end of 1995, there were no GPL'ed SQL servers that supported transactions and appropriate locking. Second, from the predecessor project I developed a very strong fear of having to have my code deal with external files that could be corrupted/edited by someone. While the backend in Ganymede may not be terribly scalable for enterprise needs, I do at least have the assurance that the data has no real chance of being changed behind my back, and I can focus on controlling the changes made rather than trying to worry about trying to make sense out of a random mess. Third, I wanted to be able to provide a reasonable object-based schema editing facility that could be used during runtime, and figuring out how to migrate object relational schemas with the tools that existed at the start of the project seemed forbidding. Fourth, I wanted to make Ganymede portable, and very easy to install and maintain with the limited resources I had to build the thing.
Similar reasons hold for the non-encrypted, non-PKI transport layer.
All that said, no, obviously the current choice of back-end is not appropriate for "enterprise" use if enterprise use means more than 50,000 users, say. I do imagine there are a lot of sites out there that could use some assistance dealing with their 10,000 users, though, which is sort of where I am aiming at with 1.0. I'd love to work with interested developers to try hack SleepyCat's Berkeley DB into Ganymede using JNI for 1.1, say. There's only so much that I can do myself, though, as I've got a lot of non-related systems administration tasks to do at work this summer for the people I work for. First up this morning, of course, was to increase MaxClients on our Apache server. ;-)
- jon
- jon
Ganymede, a GPL'ed metadirectory for UNIX
Why did the developers choose an unscalable approach, ie, a single back end server that tries to do everything itself (why not offload much of the raw data management to a GPL'd SQL server?), this would go a long way to addressing scalability and reliability. Even though they have (sensibly) got a journaled event log in the back end, i still worry about what would happen if the journal itself got corrupted after a failure.
Large scale RDBMS' address this issue head on, and if properly setup, will deal with that sort of issue transparantly. ie. solve only the core problem you're trying to address. And having a data store that multiple systems can connect to opens up redundancy - a key requirement in a system that's managing your directories.
Security is painfully weak outside of the internal model (which sounds strong), limited as they are to the Java RMI implementation. I certainly don't want admin id's, passwords and RMI's for something as crucial as this wizzing over my networks, trusted or not - it's a risk. VPN's, IP6 and SSH could ultimately be unleashed on this problem, but i fear the developers have decided to leave it on the backburner for now.
All said and done, it sounds like a great version 1.0 (and I take my hat off to the developers, despite my criticisms above), but I think it needs some solid progress in the areas above before it becomes a commonly used infrastructure tool.
ooooooh! What does this button do? - DeeDee, Dexters Lab.
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.