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