Ganymede Release 1.0.5
July 24, 2001
FAQ
---------------------------------------------

Questions Answered:

1) What is Ganymede?
2) Great!  Then I can just jump right in and use it, right?
3) Who should be thinking of using Ganymede?
4) Is Ganymede secure from packet-sniffing?
5) That's dumb.  I'm an ISP, I can't use this.. what were you thinking?
6) Any hope of a secure Ganymede for use in insecure networks?
7) What do I need to run Ganymede?
8) How scalable is Ganymede, with its memory-based database?
9) Why isn't Ganymede LDAP-based?  What about replication?
10) What's up with DNS management?  The current stuff is weak.
11) What's this rpcpass thing in the client bin directory?
12) Where's the documentation?
13) How can I help?
14) Why is it called Ganymede?
15) What is Ganymede's development history like?
16) I see a bunch of messages about missing fonts when I run the
    Ganymede client or admin console GUI under Linux, what's up?
17) Where's the Ganymede web site?
18) What's the best way to report bugs?  How should I ask questions?

--====================================================================--

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.

   We have had luck running Ganymede clients through both the Nortel
and Cisco VPN products, so if you are using a VPN system today, you
should be able to leverage that to at least be able to access
Ganymede safely from outside your trusted network.

     ------------------------------------------------------------

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

  I am hoping to look at running Ganymede over SSL sockets in the
Ganymede 1.1 timeframe.

     ------------------------------------------------------------

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/plugin/), 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.

   Newer versions of Java are just about always better.  Use the
latest production release of Java 1.3 if you can.

   Ganymede 1.0.5 and later also includes support for launching the
Ganymede clients using the JNLP protocol, which is supported by Sun's
Java Web Start product at http://java.sun.com/products/javawebstart/.

     ------------------------------------------------------------

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 61 meg memory image with 19
megs resident.  With all of ARL's data loaded and an admin console
attached, the server takes 62 megs memory image with 32 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, using the
'gasharl' schema definition.

   This is an interesting data point, but not a reliable guide.  Many
JVM's will grow their heap until they reach the maximum defined heap
size before commencing garbage collection.  To the extent that the
Ganymede server creates a lot of temporary objects during runtime, the
memory usage will increase possibly a good deal more quickly than the
heap fills up with actual database objects.

   Further, the memory usage patterns may be significantly different on
different VM's.  On an Athlon box running Linux and Sun's HotSpot VM,
the server with no data loaded takes up 11 megabytes, and only 23
megabytes with all of the above data loaded.

   Because of this variability, and because of the effects of delayed
garbage collection, really testing Ganymede's scalability will require
direct testing under the necessary load, rather than attempting to
scale up the memory usage seen before GC is taken into account.

   We can, however, perhaps take the Athlon/Linux case as a minimum
bound, where data in the ganymede.db file grows by slightly less than
ten times when expanded into linked objects in memory.

   If we take this as a minimum bound, and if we imagine a system that
can dedicate 1 gigabyte of RAM and/or swap for the JVM, a database
hundred times that of the size we use at ARL seems at least
conceivable, or an NIS/DNS-style 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 money on the viability on 80,000 users
and 255,000 systems without specifically testing at that level, but I
think 8,000 users and 25,000 systems, or vice-versa should be very
doable.  This should serve to scale to as large a size as you would
realistically want for a single domain.  If you want to put enough
data into Ganymede that a flat namespace would be difficult to live
with, you'd probably want to go ahead and split things up into
multiple servers for separate domains.

   It might be possible to rearchitect Ganymede to be more scalable by
going to a disk-based database runtime and using the Java 1.2 weak
references API to manage in-process object caching, but given the
current Ganymede design of doing complete dataset rebuilds when
transactions are committed, it seems that most data would be
continuously brought back in-process during the build phase after a
transaction was committed.  Garbage collection should keep everything
viable, but the i/o overhead would be very much greater.

     With the current design, the server should degrade gracefully if
the heap usage gets to be too much.  As the amount of data loaded into
the server increases towards the upper limits that can be held in the
the JVM's maximum allocated heap, garbage collection activity will
increase significantly.  If there is simply too much data to fit into
the set heap size, an OutOfMemoryError will eventually be thrown and
the server will be unable to handle new logins, new object creation,
and such.  With the current design an OutOfMemoryError would not cause
precipitous data loss.  At the worst, the server would have to be shut
down, the amount of heap dedicated to the jvm increased, and the
server re-started.  If the heap size is bumping up against the maximum
available on a given machine, it would be necessary to export the
server's data to XML, split the data, and create separate Ganymede
servers for separate subdomains or separate object types.

   News: As of version 1.0, the Ganymede server reports its internal
memory usage.  The Ganymede server tends to require around three times
as much heap space in RAM as the binary ganymede.db file takes up on
disk.  For our purposes we pre-allocate 32 megs of RAM for the
Ganymede server's heap, with an upper limit of 128 megs defined.  We
have never exceeded the minimum heap size for our data set.  Ganymede
1.0 in general is far, far better about memory usage in the server.

   The final word on scalability remains that you should be sure and
test with a representative dataset before committing to Ganymede, and
if you find that it doesn't scale adequately, report your findings to
the Ganymede mailing list.

     ------------------------------------------------------------

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 in some ways (object id's, symmetrical object
pointers, explicit representations of IP address data types), and
poorer in others (Ganymede's current lack of support for an object
type hierarchy), 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) I see a bunch of messages about missing fonts when I run the
    Ganymede client or admin console GUI under Linux, what's up?

   The common implementations of the JVM provided by both Sun and the
Blackdown organization include an AWT library that expects a number of
fonts to be present on the X display.  Many of those fonts are
available on a Sun Workstation but are generally not available on
common X servers such as that from XFree86.org.  The lack of those
fonts shouldn't get in the way of using the Ganymede GUI clients, but
some font displays will appear a bit off, including the 'About Ganymede'
and 'Credits' dialogs.

   The Blackdown JDK FAQ addresses this question at

http://www.blackdown.org/java-linux/docs/support/faq-release/FAQ-java-linux-6.html#ss6.4

     ------------------------------------------------------------

17) Where's the Ganymede web site?

    http://www.arlut.utexas.edu/gash2/

     ------------------------------------------------------------

18) What's the best way to report bugs?  How should I ask questions?

    We have a bugzilla database running at the Ganymede web site.  You should
visit the bugzilla database and report bugs there.  

    If you want a more interactive experience, or if you want to email
questions, you should send email to the Ganymede Discussion mailing
list at ganymede@arlut.utexas.edu, and your mail will be seen by
a decently large number of people with an interest in Ganymede.
Sending mail to ganymede@arlut.utexas.edu also results in an online
web archive of your questions, so that others will later be able to
see the question you asked or bug you reported.

    Thanks!

-------------------------------------------------------------------------------
Ganymede FAQ
Author: Jonathan Abbey
Release: $name:  $
Version: $Revision: 1.17 $
Last Mod Date: $Date: 2001/07/26 19:51:51 $
-------------------------------------------------------------------------------
