Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

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."
This discussion has been archived. No new comments can be posted.

Ganymede 1.0 Released

Comments Filter:
  • 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
  • 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
  • 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
  • This must be the one of the few slashdot stories where the author of the story has more comments than the 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
  • by jonabbey ( 2498 ) <> on Thursday June 07, 2001 @09:13AM (#169909) Homepage

    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
  • 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
  • Their webserver won't play with netscape on linux... I wouldn't be supprised if it dosen't play with anything but IE.
  • >Why did they have to pick such a gay name?

    F>r those of you who think I'm being homophobic
    >ook up somewhere who Ganymede was in Greek

    Cup boy to the gods.

    Seems an appropriate name for a serving system, all things considered...


  • And?

    I work for ... a major network management software company ... and our flagship product is pretty much useless if you just install it with the default options. You need to do a fair amount of customization, and some of the modules that go with it won't even install without having a commercial RDBMS to back them up.

    Oh, and our software is *expensive*.

    Ganymede is free and does a lot of what our propietary solution does.

    Your point is what, exactly?

  • by rleyton ( 14248 ) on Thursday June 07, 2001 @02:57AM (#169914) Homepage
    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.

  • ok well done !!

    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 !!!!!


    john jones

  • Just wondering: does it support Banyan Vines Streettalk as well?

  • Why did they have to pick such a gay name?

    For those of you who think I'm being homophobic look up somewhere who Ganymede was in Greek mythology.
  • 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 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?
  • From the FAQ, Question 2 []: Great! Then I can just jump right in and use it, right?

    "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."
  • Mirrors anywhere .... can't reach the site from here....
  • by Nyarly ( 104096 ) <> on Thursday June 07, 2001 @07:31AM (#169921) Homepage Journal
    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!

  • Is Java 1.2 included by default in any browser today?

    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.
  • I always thought that the moon under the "G" in the logo was indicative of inspiration for the name being Jupiter's giant slushy moon, Ganymede.
  • What makes you think it's 5 AM? It's nearly lunchtime...
  • This article reads like a glossary. I vote it the most incomprehensible-for-non-tech-heads article I've ever seen on Slashdot:

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

  • Another thing that is important is security. The FAQ says that communication between Ganymedes clients and servers is not encrypted. A very rudimentary encryption (e.g. supplying a MD5 checksum based on parameters together with a secret word) would be nice, and the option of letting the users implement their own encryption (open-sourced of course!), would be even nicer.
  • If you read the FAQ, you might find some correct information.
  • Since the Ganymede site is /.ed, LinuxToday has short article [] that offers a bit more information.
  • Ganymede has been a long time in the making, but well worth the wait and (somewhat) rocky ride. If you haven't checked it yet, head right over to their website, neat stuff if you have Java VMs installed on your machines. The TODO lists some cool new features for some upcoming versions and it appears 1.1 will bring it up to full enterprise-scalability.

    Very cool.
  • Better than that would be to just set the whole thing up to tunnel over SSH using public keys by default. This has the advantage of being dead easy to do. While you could set this up very easily today it would be cool it have to set it up to do something else. I think if this was the default far more people would use it and the world would be a better place.
  • At my company we use software from IBM to manage these things. We always seem to be having stability and performance problems however.

    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.

  • BTW I think this project is a good deal. Didn't mean to be negative towards it in the previous post
  • by duckpond ( 198930 ) on Thursday June 07, 2001 @08:35AM (#169933) Homepage

    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.

  • Anyone else having this problem when trying to untar the thing?

    ganymede-1.0/doc/javadoc/arlut/csd/ganymede/client /JTreeTable.ListToTreeSelectionModelWrapper.html, 15932 bytes, 32 tape blocks
    tar: directory checksum error
  • Thanks. I was using Sun's tar. GNU tar worked just fine.
  • Are you sure that's the right patch?

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

  • This is a known problem, bug ID# 4064315...Sun has a patch for it [].
  • Well, the same patch exists for all versions. I kind of assumed you could hunt down the appropriate patch.

    It's not in the recommended cluster, either.

  • Large Corporations will probably stay clear of this for a while.. but this is terrif news for small businesses. I think we sometimes forget how much Open Source / Free Software products help the little guys.
  • The FTP server is still reasonably quick and has a lot of documentation and promotional material available. It's at [] for those of you who want to see if it can walk-the-walk by giving it a go instead of just talk-the-talk by looking at, admittedly impressive, pictures.
  • For v1.0 - this is quite impressive. I chuckle to think how badly we could have used a system like this at my old job. We had numerous systems handling all sorts of directories and dozens of people hacking tools together to get them to talk to each other in a limited way. Its nice o see someone try to link it all together.

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

  • Notice it uses a fair amount of Java. How's Java performance on the majority of Un*xes these days - is it up to the job?
  • Open Source / Free Software was huge for the small companies that I have worked for. We ran as many Linux servers as we could, we choose MySql for our DBs and Apache of course etc ... The best part is that we could get our projects out fast becuase our tools where free/inexpensive which allowed us developers to make our own decisions without waiting for the ok to buy things from above. In the end it help our company meet its bottom line, beat our competion out the door and allowed us to produce some great systems many times less expensive than companies that where not empowered with our tools/software could.
  • by opnotic ( 458165 ) on Thursday June 07, 2001 @02:28AM (#169945) Homepage
    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..

The unfacts, did we have them, are too imprecisely few to warrant our certitude.