Ganymede Release 0.99.7 October 13, 1999 FAQ --------------------------------------------- 1) What is Ganymede? Ganymede is a system for managing network directories. A network directory is something like NIS, LDAP, or DNS. Ganymede has its own built-in object database that holds authoritative information and which is fed into NIS, DNS, etc., when things change. Unlike stock NIS, DNS, or LDAP, Ganymede is designed to be very smart about what changes are allowed to the network information. Customizers can write Java classes to provide very sophisticated data checking and inter-object relationship maintenance. The Ganymede server does a lot to keep everything sane.. if you delete a user, the user is automatically removed from all groups, email lists, systems, etc., that refer to the user. If any of those secondary changes would violate permissions, the whole operation is refused. With Ganymede's sophisticated permissions system, you can give different levels of authority to different kinds of users, over distinct portions of Ganymede's database, making it possible for administrators to take care of their own portions of your network directories without getting in each others' way. Ganymede logs all changes and has an extensive system for sending email notification to various interested parties when things change. Objects in the database can be set to expire or be removed at a later date, making it possible to create temporary user accounts and so forth. Customizers/adopters can write code to take the data from Ganymede and propagate it into NIS, DNS, or anything else when changes are made in the Ganymede database. At ARL, we take the data from Ganymede and propagate it into NIS, DNS, tacacs+ for router configuration, Samba, NT, Sendmail, LDAP, and more. In addition to maintaining the directory services, Ganymede also triggers external scripts to create users' home directories, handle user rename, NFS volume creation, etc. Having a central point through which all network information changes go through before fanning out to all of your network distribution mechanisms is extremely powerful. Ganymede is much more than a simple directory system like LDAP, NIS, or even DNS. Ganymede is a total system for managing your directory information, and is designed with the goal of making it possible to let even untrained clerical staff handle things like user and DNS record creation and maintenance. 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. Ganymede comes with a few demonstration schema kits, and one very complex schema kit that manages the ARL laboratory environment, but if you are serious about Ganymede you're going to need to do some work to design your network environment management system. Hopefully as time goes on, people will produce a variety of schema kits that will be useful for a variety of common scenarios (like managing DNS at an ISP, for instance), but whenever you get into an environment as complex as Ganymede is designed to be able to handle, you're likely to get a lot of details that will be different for each network. 3) Who should be thinking of using Ganymede? From reading the above, you can tell that Ganymede is probably overkill for a small network. If you start getting hundreds of users and/or hundreds of systems, Ganymede will make your life a lot better, but for less than a couple dozen systems or users, you may find that Ganymede is a bit much. Ganymede is not at all a good fit for managing things on a single system.. the Ganymede server takes up a lot of memory and you just wouldn't need its features for something so small. 4) Is Ganymede secure from packet-sniffing? No. Ganymede has an effective internal security model, but all communications between the client/console and the Ganymede server are carried unencrypted. 5) That's dumb. I'm an ISP, I can't use this.. what were you thinking? Ganymede is being developed in a laboratory in which a relatively high level of trust is assumed behind the firewall. Ganymede's security and permissions model in this environment are designed for administrative separation rather than to prevent hacking, although everything possible short of transport-layer encryption has been done to keep everything as safe as possible. 6) Any hope of a secure Ganymede for use in insecure networks? Quite possibly, yes. The Java 1.2 platform includes support for RMI over custom socket types, which could theoretically include SSL encrypted sockets. Sun has put out an early access version of their Java Secure Socket Extension (JSSE) which provides SSL and TLS socket encryption. No word on whether anyone has gotten RMI to run over it successfully yet. See http://developer.java.sun.com/developer/earlyAccess/jsse/ for this. A number of other organizations have done work on implementing SSL sockets within Java.. there is at least one free implementation underway, being done by Claymore Systems, Inc. You can read about their free implementation at http://www.rtfm.com/puretls/ It looks as though they have a good bit of work left to do for a turn-key SSL socket implementation on Java, but when this work is further along is should be fairly straight-forward to implement a secure Ganymede. People interested in spending some cash can get working SSL on Java today. Here are some links to SSL implementors for Java.. note that some of these links include explicit details on how to support RMI over SSL. http://vonnieda.org/jSSL/ - Another free work.. still in progress? http://www.ixworld.com/javassl/ - Not portable, requires binary NT SSLeay libs http://www.phaos.com/ - Commercial, their SSLava stuff mentions RMI 7) What do I need to run Ganymede? The Ganymede distribution is packaged as a gzipped UNIX tar file, and requires GNU tar to decompress it, due to extremely long file/path names in the archive. Because the Ganymede distribution includes various symbolically linked files, it is best unpacked and used on a UNIX system. The Ganymede server and clients should have no UNIX-specific code in them, but all the build and install scaffolding requires Bourne shell and Perl 5. To run the Ganymede server on UNIX systems, you need Java 1.1.7 or better for your system. Since Ganymede supports running the Ganymede client and admin console on Windows browsers with Sun's Plug-In (see http://java.sun.com/products/jdk/1.2/jre/), you can get away with just the basic Java environment on your UNIX system to run the server on. To run the Ganymede client and admin console on your UNIX system, you will either need Java 1.2 or better for your system, or Java 1.1.7 or better and Swing version 1.1 or better. Ganymede does not currently have much in the way of text-mode clients, so X Windows is essential. The Ganymede server is memory intensive, as all data registered in Ganymede is kept in an in-memory database backed by disk. A 64 meg system dedicated to Ganymede is adequate to run a lab like ours, with DNS for a couple thousand systems, and user, group, and email records for around 1000 users. More memory is better. You'll probably want a Pentium 200 or better for good performance on something like Linux. JITs are great, anything with a good generational garbage collector like Sun's HotSpot VM are super-great. To run the Ganymede client and admin console on Windows 95/98/NT, you'll want Sun's Java Plug-In version 1.2.2 or later, and at least a P133 with 32 megs. 8) How scalable is Ganymede, with its memory-based database? An excellent question. The Ganymede server is extensively multi-threaded and optimized, but memory is a fairly hard limit to get around. Without any data loaded, and using the latest JVM for Solaris on UltraSPARC, the Ganymede server has a 57 meg memory image with 17 megs resident. With all of ARL's data loaded and an admin console attached, the server takes 58 megs memory image with 28 megs in-memory resident. That data comprises: 780 user/passwd records 240 group records 524 nfs volume definitions 238 nis netgroup records 1321 email alias records 2676 i.p. addresses 2553 dns records ~600 room/network connectivity records or about 1.5 megs of data in the binary ganymede.db file. At least with Sun's VM, memory usage seems to go up fairly closely as the amount of data in the ganymede.db file. Even if we take the memory resident measurement as a better indication of how much the data in ganymede.db expands in memory, that's looking to be memory usage of 10 times the size of the binary ganymede.db file. Systems with 1 gig of RAM are not at all rare these days, so a hundred meg database seems at least conceivable, or a database with nearly 80,000 users and 255,000 systems. Ganymede has not been tested to this level, and it would take an extremely well tuned VM to handle garbage collection for that size database, but Sun's HotSpot VM on a multi-processor machine might have a decent go at it. Whether the JVM would handle i/o and threading for as many clients as is implied by such a scale, and whether Ganymede's hashing data structures would function efficiently at that scale are open questions. The client would certainly have scaling problems before that point, from a user-interface standpoint if nothing else.. I personally wouldn't bet on 80,000 users and 255,000 systems, but 8,000 users and 25,000 systems, or vice-versa should be very doable. Going to a disk-based database makes things a bit difficult in Java, since Java doesn't make it possible to re-use memory buffers intelligently.. a Ganymede server reading items out of an on-disk database during run-time would be constantly creating new objects in memory anyway, with garbage collection required to re-use the memory. Java 1.2 supports a weak-references API that could be useful in allowing more effective use of memory, but given the common database access patterns (scanning all objects of a type to emit passwd, group, dns files), it's unclear how much of a benefit this would bring. 9) Why isn't Ganymede LDAP-based? What about replication? For a number of reasons, most having to do with the fact that development on Ganymede started in early 1996, before LDAP was as prominent as it is today. Ganymede provides a lot of intelligence and customizability that you don't get with a stock LDAP solution, and its transaction and permissions models are superior to that of LDAP. The point of Ganymede is as much intelligent management of changes and relationships as it is mass storage of data. Because Ganymede has a richer data model (object id's, symmetrical object pointers, explicit representations of IP address data types), reworking Ganymede on-top of LDAP would be difficult. A lot of the intelligent management of Ganymede would have to be sacrificed in such a move, although the resulting system would probably be more scalable and would have higher performance at the high end. Going to a multi-server Ganymede system, a la Active Directory and NDS and LDAP servers generally might be interesting, but that would be Hard. All of the namespace indices used for unique-value management and object locking would have to be coordinated across servers, and in such a way that a server could go down and be brought back up without losing such run-time state. Also, the scripts to emit data from Ganymede server's into local DNS, NIS, and the like would be complex. Generally speaking, Ganymede is not intended to be the service that operating system (PAM) and/or application code consults directly. Instead, Ganymede is intended to feed things like NIS, DNS, and LDAP, which have their own means of doing replication and redundant servers for backups. 10) What's up with DNS management? The current stuff is weak. Yes, that's true. We're working on code to support arbitrary DNS management. Instead of the current hosts_info file-of-evil that we inherited from GASH, we're developing an XML-based DNS system that will allow us to do both bulk and incremental DNS updates and, if we play our cards right, even flexible BIND file importing. It's coming. 11) What's this rpcpass thing in the client bin directory? It's a proxy utility to allow integrating the NIS rpc.yppasswd daemon with Ganymede, so users can change their Ganymede (Samba, NT, whatever else you're supporting with Ganymede) password through the UNIX NIS passwd command. This works with version 1.3.6.92 or later of the Linux NISkit's rpc.yppasswdd daemon using the --x or --execute option. See the rpcpass entry in doc/glossary.html file for details, and the entry for 0.99.1 in the CHANGES file. 12) Where's the documentation? What documentation do you want? I know more and better docs are needed, but feedback is pretty scarce. Are the current docs adequate at all? Where does it break? Ask questions, send mail to the Ganymede mailing list (ganymede@arlut.utexas.edu). Code development is like a child's brain, it needs input. If you haven't seen it, look on the Ganymede web page (http://www.arlut.utexas.edu/gash2/) for the 1998 LISA paper we wrote on Ganymede. It provides a very good conceptual and technical overview. It's not so good as an operational manual, but we're struggling to get more operational documentation written. 13) How can I help? Send in bug reports and success reports, to jonabbey@arlut.utexas.edu or, preferably, ganymede@arlut.utexas.edu to send it to the mailing list. If you are having problems or see an issue, it's likely people on the list will be interested and have something to say about it as well. Help is always welcome. Ganymede is designed to be a generic engine that can be customized with schema kits for differing environments.. if you want to work to customize Ganymede for some environment, let the list know. If you see things in the basic engine or client that you think you could contribute to improving, let me know. 14) Why is it called Ganymede? It's actually an acronym, standing for GAsh Network Manager, Deluxe Edition. I wanted a name that connected this project to GASH, and I just couldn't come up with any great names that involved GASH in some fashion (I did come up with a lot of really bad names, though...) 15) What is Ganymede's development history like? Ganymede is the successor to GASH, the Group Admin Shell, which was developed at ARL starting in early 1993, and which was presented at the USENIX LISA VIII conference in San Diego, CA in September, 1994. Refinements and further development of GASH continued into mid-1995, before we decided that the GASH design wouldn't carry us much further without massive pain and effort. Initial work on spec'ing Ganymede started in late 1995. After several months of planning on pen and paper, active code development started around June 1996. In March 1998, the first binary developer's pre-release was put on the ftp site. In December 1998, we presented Ganymede at the USENIX LISA XII conference in Boston, MA. The first full source distribution, under GPL licensing, was sent out in January, 1999. Development and refinement has continued since then. For the majority of that time, there has probably been on average 1.5 developers working on the code. Doing Ganymede in Java rather than in something like C or C++ made it possible. We still wound up with the massive pain and effort, however. Hopefully it'll be useful to people. 16) Where's the Ganymede web site? http://www.arlut.utexas.edu/gash2/