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."

Comments

Re:metadirectory design

[jonabbey]

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

Re:Scalability, Reliability, Security...

[jonabbey]

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

Scalability, Reliability, Security...

[rleyton]

I read the docs with interest - it's a superb system that will hopefully add another great product to the growing GNU toolset, but I can't help but worry the first version isn't addressing some key demands which would make it "fit" for widespread (commercial?) use.

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.

Is there really a need?

[dzeanah]

Great timing -- I spent a big chunk of yesterday trying to figure out which directory solutions were available for Linux.

I guess my question is: will anyone use this?

Looking at the pricing offered at novell.com shows that you can use Novell's NDS on Linux for $2 per seat. At that price, I'll take NDS (proven solution, fast, shown to be scalable beyond 1 *billion* objects, good management tools are available, etc).

What am I missing here? It's open source, but it's apparently going to require some hacking (to set up your schema) before you can use it, which will limit the number of people capable of deploying it.

Would anyone here take this over NDS/eDirectory? Why?

JINI

[Nyarly]

I have to say, of all the questions I felt like asking when I first read the Ganymede documentation, and white papers, and presentations (I came upon Ganymede at 0.9, and it was, I'll admit, fascinating), is why not have used JINI for a lot of this.

I understand that the answer is that, when GASH needed extension, JINI wasn't a twinkle in Bill Joy's eye, but the degree to which JINI could improve and extend the parts of Ganymede that it would be applicable to is incredible.

JINI's gotten almost no press, and it seems like it's worth discussing. For instance, JINI provides an Attributes class that would go a long way to improving the weird hash hack that underlies the Ganymede data model. JavaSpaces perfectly provide the data management fascility, and with a little work can be made to buffer a database. JINI includes a transaction engine that can be used to drive a very flexible set of transaction properties on any class that implements an extra interface. And, finally, not only does it allow the application to scale, components can be simply added to the system without having to be integrated by hand.

On the other hand, it's still using RMI, but last I checked, there were free solutions for securing RMI, so I dubious about how much of an issue that is.

The downside to this is that, although I reviewed the Ganymede code briefly, I could give a great estimate of how much code would be reused with a JINI rewrite (although it could be quite incremental) and I wonder if it would be almost easier to start from scratch.

On the whole, though, Ganymede is most impressive. You've done a man's job, sir!

metadirectory design

[duckpond]

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.

I mirrored the screenshot page..

[opnotic]

I was bored so I mirrored the screenshot page here. The expanded images still link to the main server tho.. so they will be slow..