[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Ganymede Dev] Re: many G... questions
|
On Wed, Jul 03, 2002 at 10:15:33PM +0200, Stephan Wiesand wrote:
| Dear Jonathan Abbey,
|
| we here at DESY (a german High Energy Physics research lab)
| are about to launch a project to implement a new system dealing with
| our users and their access to resources - not limited to login on some
| computers but in a more general sense. Our main targets are Unix and W2K,
| NIS, Kerberos, AFS, LDAP and the like, but for example we'd also like to
| be able to administer the privileges for operating the accelerators vacuum
| system, using Ganymede's excellent permissions system for delegation.
Wonderful, how exciting!
| After listing our requirements - some of which are pretty weird , s.a. -
| we evaluated several directory service products and found that Ganymede
| is the only one that would be flexible enough to help us get the job done.
| You beat some big, expensive names there - congratulations, and heartfelt
| thanks for making this available!
I'm very happy to hear it. Ganymede is pretty unique, I'm happy that
there are others out there who may see an advantage to its heavily
programmable object design.
| There are however some things we'd like to do that seem difficult even for
| Ganymede to achieve, and for those I'd like to ask whether I've overlooked
| a simple way provided by Ganymede and - if not - how you'd go about
| enhancing Ganymede to do them, and whether you'd accept such a feature
| as a contribution to Ganymede:
|
| 1) Kerberos(V) authentication
I don't know enough to be able to comment very inteligently on this
one, unfortunately. Could you elaborate on how you'd like to see
Ganymede interact with Kerberos?
| 2) RMI over SSL
|
| I've seen this on your road map already. How much work would it
| actually be to implement? Sun claims with the JDK 1.4 it's not
| too hard - do you agree? Would you accept a 1.4+ only solution?
I don't believe it would take any significant amount of work at all,
as long as you are willing to restrict your clients to using JDK 1.4.
A student here has recently demonstrated a proof of RMI over SSL, and
it appears that it would be on the order of a 10 line patch to the
server, and a one or two line patch to the client. Essentially the
only change that would be required for the client would be the setting
of the RMI security manager, to allow downloading of the appopriate
socket factory classes from the server.
We have not actually tried running Ganymede over SSL yet, though, so I
can't comment on the CPU or memory requirements that running over SSL
will take. It's possible that it would be better for performance to
only SSL-protect certain communications, mostly those having to do
with passwords. Whether such performance improvements would be worth
the potential for intercepting and spoofing a command stream is an
open question.
| 3) Enhanced command line interface and/or external API:
|
| The xmlclient seems to do a good job when writing to the directory,
| but queries aren't possible, just a complete dump of the DB. Would it
| be feasible to enhance xmlclient to allow querying for the value of
| particular attributes of particular objects? Could the very nice query
| mechanism in the GUI client be reused?
This is an obvious enhancement, and one I'd love to see happen. The
GUI client's submits queries to the server using a serialized boolean
logic tree. Probably the easiest path to what you're suggesting would
be to define an XML mapping for the serialized data structures that
are currently used for querying, and the addition of a new entry point
in the GanymedeSession class (or one in the GanymedeXMLSession) that
would take an XML query representation, internally regenerate the
current logic tree structure, and then pass it to the existing query
engine. The results from the query would then be converted to XML for
the return to the xmlclient.
That's only if you needed to have an externally scriptable XML
interface. It would also be possible to write a custom client to
perform whatever sort of querying would be appropriate.
So, very doable, but a bit of design effort should need to be
undertaken before starting to code anything, I think, especially if
you wanted a convenient command-line shortcut for queries rather than
having to generate XML for each query.
| 4) Incremental, asynchronous propagation of data to target platforms:
|
| The example schema coming with Ganymede does full builds on every
| transaction commit, right? What we'd like to do instead is, on commit,
| create an "event" with the information what changed and put it into
| a queue read by the mechanism actually doing the work on the platform
| (we call that a "platform adaptor"), which should then acknowledge
| reading the event, do the work - possibly after querying for additional
| information from Ganymede through an enhanced xmlclient - and finally
| confirm the event's execution.
Right, I've been thinking about something along those lines for quite
some time. I've always come back to the problem of how to let the
Ganymede server know which changes have been successfully propagated
to the exterior environment. Ganymede doesn't (currently) have the
database scalability to remember older versions of objects, so it's
hard to tell Ganymede to generate a delta for service X since time Y.
There already exists code to generate transaction-by-transaction
differential change records. The database journal file (handled by
the DBJournal class) is based on that kind of differential logic.
I can certainly see having the Ganymede server generate an XML delta
description summarizing changes made during a transaction, and then
having an external interface (your platform adaptor) process the XML
chunk and process the delta.
The challenge would be to make sure that those XML chunks are
successfully processed, and to report success or failure back to
Ganymede as you suggest. If it took any significant time to process
the delta chunks, then the rate of transaction commits in the Ganymede
server would be drastically slowed down. Right now, Ganymede uses its
scheduler to asynchronously decouple transaction commits from external
builds. If the Ganymede server could not finish a transaction commit
until an external process of unknown duration completed, it could
severely reduce the server's concurrency.
If you anticipate managing several unlinked types of data in Ganymede,
running multiple Ganymede servers could reduce the impact on
concurrency, of course.
| I believe all of this would be possible without touching the Ganymede
| core: Either by making commitPhase2() talk to some external daemon
| actually doing the queuing and pushing the status information back
| into Ganymede by creating and manipulating objects of type "Platform
| Event" via xmlclient, or by directly creating the "Platform Event"
| objects from DBEditObject's set...() or finalize...() methods, and
| have scheduled tasks check for existing event objects and do the
| talking to the platforms.
Hm. I'd need to know more about your schema design to be able to
comment on this.
| Am I right? Could we do that? Is it allowed/possible to create new
| objects from within DBEditObject methods and check them into the
| current DBEditSet? Can scheduled tasks manipulate/create/delete
| objects? And: could you imagine having such a mechanism tied more
| closely to the core?
Unfortunately, the commitPhase2() method is not allowed to create new
objects in the DBEditSet. The various non-commit-time methods in
DBEditObject are allowed to create new objects, and scheduled tasks
most certainly could.
| 5) Work flow
|
| If, say, a user wants to request a quota increase for his home
| directory, our new system should allow him to do so electronically,
| bring the request to the attention of the right persons (those with the
| privileges needed to grant or deny it), and escalate the process if
| none of these persons has reacted within a certain time.
|
| Again, I figure we could implement this by defining object types
| for such requests, creatable by any user, with the "done" boolean
| attribute editable by the right owner group, a many-to-many relation
| from request objects to a "pending requests" vector of object
| references we add to the "User" object type, and a scheduled task
| caring for escalation. Right?
Yes, that seems reasonable.
| But this seems rather clumsy. Some request mechanism coupled to
| the "Admin Persona" concept would be nice, wouldn't it?
It's an interesting idea, but it's a bit beyond the scope of how we
have used Ganymede here. I can certainly imagine an external system
being built around Ganymede to provide such functions, but I'm not
sure how tightly such a function would need to be integrated.
Ganymede is at its heart simply a transactional engine with
asynchronous build execution. Any new functionality added into the
core would need to be carefully considered, taking into account the
possible limitations of Ganymede's RAM database.
| 6) Expirable relations
|
| The concept of object references and their handling in the schema
| editor is great! So is the handling of expiration dates for objects.
|
| But when I started to try creating our data model in the editor,
| I realized that in many cases of two objects tied together by
| object references, it's not the objects that should expire eventually,
| but just the link between them. For example, users changing from one
| project/experiment to another are a very common case here, and
| what typically should happen is that new group memberships etc.
| become effective immediately, while the old ones should expire after,
| say, 3 months.
|
| Hence it would be extremely useful to be able to set expiration dates
| for object references much the same way as for objects. Would this
| be feasible to implement?
This could certainly be done. Here at ARL:UT, we have locally added a
password expiration field, that specifies an expiration date for the
user's password field. We have a custom task that runs once a day and
scans the database for any passwords that have expired or that will
soon expire, and which sends out warning email and/or actually
inactivates the account.
It would be easy to add expiration date fields to objects, and to
create a custom task that would edit the objects and handle any
unlinking required.
There might be a user interface issue, in that you wouldn't want to
have a ton of date fields visible at the bottom of the object in the
GUI client. We have just started to discuss evolving the server and
client to allow the schema editor to cluster fields by tabs, so that
you could create a User object with an 'Authorization' tab, and an
'Identity' tab, for instance. Such an enhancement would make it more
feasible to add lots of custom fields to handle such housekeeping.
| 7) Derived object types
|
| Not each of our users has accounts on all platforms, access to all
| resources etc. To model this, it would be very useful to be able
| to define an "Account" object type, with a one-to-many relation
| from "User" to "Account", a "Resource" object type wit a many-to-many
| relation between "Account" and "Resource". Ganymede makes that
| amazingly simple.
|
| But: Unix accounts will for example have a different set of attributes
| than W2K account or others. Is there a way to define "Unix Account"
| and "W2K Account" sharing some set of attributes (including the
| 2-way object reference to "User") by being derived from "Account"
| while extending the base object with additional attributes (like a
| 2-way object reference to "Unix Group" or "W2K Group", which may
| themselves be derived from "Group")?
|
| I figure this one wouldn't be easy.
No, it's not that easy, but not, perhaps, for the reason you'd expect.
The big difficulty I've had in trying to figure out a way to support
derived object types is in the user interface side of things. The
Ganymede GUI client's tree display currently shows all objects of a
given type in a folder, and the query engine executes queries based on
an object type. It's an open design question to decide how the
Ganymede client should handle the object tree when there is a type
hierarchy for the objects.
That said, having derivable types would be a wonderful enhancement,
and one I've wished I had designed into Ganymede at the start for some
time now.
On the other hand, the DBEditObject class is powerful enough that you
can define all the fields you might want to have in the user class,
and then have a pull-down toggle or a series of checkboxes for the
user type, and the DBEditObject plugin could hide the inappropriate
fields based on the selected user type. We do something very similar
to this in a number of our classes.. see the Task object class in the
default Ganymede schema for an example of this.
| I hope I made at least some of our ideas and thoughts clear. Any
| kind of response is much appreciated. And again, thanks for making Ganymede
| available under the GPL!
Of course. A non-open source Ganymede wouldn't make sense, as it is
designed to encourage very extensive customization and custom-coding.
Putting it under the GPL makes it possible that others could develop
very highly customized management systems, and that's the real value
in Ganymede.
| We have to throw a lot of manpower at implementing our new system, and
| would much rather spend as much as possible of it on contributing to
| Ganymede than on reinventing the wheel. What do you think?
I'm pleased and excited, and I would love to hear more about your
goals. How large a dataset do you imagine you would eventually want
to manage with Ganymede?
| Cheers,
| Stephan Wiesand
|
| --
|
| ----------------------------------------------------
| | Stephan Wiesand | |
| | | |
| | DESY Zeuthen | phone +49 33762 7 7370 |
| | Platanenallee 6 | fax +49 33762 7 7216 |
| | D-15738 Zeuthen | mobile +49 171 317 6367 |
| | Germany | email stephan.wiesand@desy.de |
| ----------------------------------------------------
--
-------------------------------------------------------------------------------
Jonathan Abbey jonabbey@arlut.utexas.edu
Applied Research Laboratories The University of Texas at Austin
Ganymede, a GPL'ed metadirectory for UNIX http://www.arlut.utexas.edu/gash2
----------------------------------------------------------------------------
To make changes to your subscription to the Ganymede Dev mailing list, send
mail to majordomo@arlut.utexas.edu.
To unsubcribe, include the line
unsubscribe ganymede-dev
in the body of your mail message
Visit the Ganymede web page at http://www.arlut.utexas.edu/gash2
----------------------------------------------------------------------------