Ganymede 1.0 Released 41
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."
Re:Ganymede won't untar (Score:2)
Some vendor tar programs can't handle very long filenames. Try using gnu tar. If you still have problems, check to make sure you downloaded the whole thing successfully.
- jon
Re:Webserver won't play with netscape on linux (Score:2)
What, our web server? I run it, and I do everything from Linux. Works fine in Mozilla and Netscape 4.7. It might not work with IE, but then, that's someone else's problem, isn't it? ;-)
You're probably just seeing it saturated. I bumped the number of concurrent web clients it will serve, but the proud Slashdot legions can probably still overwhelm it if they care to.
- jon
Re:Java 1.2? A stupid question... (Score:2)
Ganymede comes out-of-the-box with support for using the Java plugin on Linux, Solaris, and Windows. You can plug a Java 1.3 JVM into Netscape 4.7 and IE and the Ganymede web launcher will do the magic to invoke the proper plug-in and/or ActiveX control. If you are using Mozilla on Linux or Windows with a recent JRE, you can just use the 'native' option in the Ganymede web launcher and it'll pick up the JVM itself.
- jon
Re:CORBA and replication (Score:2)
This must be the one of the few slashdot stories where the author of the story has more comments than the goat.se.cx trollers. ;-)
As far as CORBA, Ganymede depends on the object graph serialization and distributed garbage collection features of RMI to provide a really tight binding between the GUI client and the server. Plus, RMI is simpler to work with, the implementation that comes with the JDK has been stable for a long time, and there is pretty much ubiquitous support for it on the Java platform, making it possible to run the Ganymede client just about everywhere without a lot of hassles.
As far as support for Python/C/C++/Perl, etc., there is an XML client that allows for high volume transactional data loading, and I imagine evolving that XML interface towards something like SOAP would be a better investment of development resources at this stage of the game.
- jon
Re:metadirectory design (Score:4)
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... (Score:5)
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
Webserver won't play with netscape on linux (Score:1)
Re:what's with the name (Score:1)
F>r those of you who think I'm being homophobic
>ook up somewhere who Ganymede was in Greek
>ythology
Cup boy to the gods.
Seems an appropriate name for a serving system, all things considered...
-LjM
Re:1.0 -- But Not 'Out of the Box' Ready! (Score:2)
And?
I work for
Oh, and our software is *expensive*.
Ganymede is free and does a lot of what our propietary solution does.
Your point is what, exactly?
-LjM
Scalability, Reliability, Security... (Score:5)
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.
CORBA and replication (Score:1)
it looks nice and this is what people need to manage large systems
but RMI is in my opinion a bad choice and is the sun cut down corba it would be nice to use corba as the interconnect and it would allow codeing to be done in python/C/C++ for connecting to existing managment apps easly of which there are lots
replication of services and information to allow fail over and increase speed (I do my admin on the UK server the austin branch on the US server and they keep each other info and replicate) AND this means that if one falls over or the link goes down we dont lose the ability to manage systems
this is well addressed in lotus notes add on products
this kind of rocks so well done to all !!!!!
regards
john jones
Banyan Vines Streettalk? (Score:1)
Just wondering: does it support Banyan Vines Streettalk as well?
Arleo
what's with the name (Score:1)
For those of you who think I'm being homophobic look up somewhere who Ganymede was in Greek mythology.
Is there really a need? (Score:3)
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?
1.0 -- But Not 'Out of the Box' Ready! (Score:2)
"Um, no. Ganymede itself is an extensible and customizable system that can do a tremendous amount for you, but right now it is not an 'out-of-the-box' admin package. In order to make Ganymede useful, you need a schema kit, which consists of a database definition for the network information you want to manage, a set of custom Java plug-in classes that will make the Ganymede server smart about how your information is supposed to be connected together, and a set of classes and scripts that will take information from Ganymede and propagate it into your network."
Slashdot effect.... (Score:1)
JINI (Score:3)
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!
Java 1.2? A stupid question... (Score:1)
It's my impression that one of the goals of IE was to pollute Java with MS-specific extensions, and if that wasn't possible, to hold it back at a primitive level so that people will not like it.
So, once again. What does a developer have to do to deploy a Java 1.2 app?
I assume that the swing stuff can be downloaded in byte-code form and run that way, but performance would have to be nowhere near a native implementation.
Re:what's with the name (Score:1)
Re:too early (Score:1)
Say what? (Score:1)
"... we have just released Ganymede 1.0. Ganymede GPL'ed metadirectory, put an NDS Active Directory style concurrent GUI network's NIS, LDAP, Windows NT PDC, Samba, and even DNS directory services. Ganymede 1.0 userKit password synchronization to UNIX, Windows NT, and Samba. Ganymede Java Linux, BSD, Solaris, Windows NT, Mac OS, and OS/2."
-Erik
Enhancement suggestion: encryption (Score:1)
Re:FYI (Score:1)
More Reading (Score:2)
Nice to see (Score:2)
Very cool.
Re:Enhancement suggestion: encryption (Score:2)
Is it stable (Score:1)
I'd like to see if this solution is better on those fields. That would definitely be a big Thumbs Up for the Open Source movement.
Re:metadirectory design (Score:1)
metadirectory design (Score:4)
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.
Ganymede won't untar (Score:1)
[...]
ganymede-1.0/doc/javadoc/arlut/csd/ganymede/clien
tar: directory checksum error
Re:Ganymede won't untar (Score:1)
Re:Ganymede won't untar (Score:1)
That patch is for Solaris 2.6 on i386 and is dated 3/27/01. The xref'd SPARC patch was for 2.6 as well. I'm running Solaris 2.8 on a SPARC and I've installed all recommended patches since at least 3/27/01.
Re:too early (Score:1)
What makes you think they are waking up. More like they are still on their hacking session from the night before.
Does appear though that the link is already /. ed
Re:Ganymede won't untar (Score:1)
Re:Ganymede won't untar (Score:1)
It's not in the recommended cluster, either.
Good Thing for Small Business (Score:1)
Re:Slashdot effect.... (Score:1)
Most Excellent! (Score:2)
Hopefully I'll be in a position again where my company is looking to simplify their directory life and until then I may just have to play with it on my 10 computer network here :)
Re:Is it stable (Score:1)
Re:Good Thing for Small Business (Score:1)
I mirrored the screenshot page.. (Score:3)