Re: [Ganymede Dev] Re: many G... questions

[Jonathan Abbey <jonabbey@arlut.utexas.edu>]

On Fri, Jul 05, 2002 at 11:59:31PM +0200, Stephan Wiesand wrote:
| On Thu, 4 Jul 2002, Jonathan Abbey wrote:
| 
| > I'm not familiar with the JAAS.  I imagine the issues would revolve
| > around how the client would get access to the TGT if it is run from a
| > browser.  By default, of course, a downloaded Java applet has almost
| > no privileges to access anything of the local environment.  The
| > ganymede GUI client and xmlclients might benefit from that if run as
| > an application from a command line, but the ganymede GUI client is
| > dual-mode, and when run as an applet has very restricted privileges.
| 
| Yes that's a problem. I think these restrictions are relaxed for signed
| applets?

Yes, I believe they can be, with an appropriate policy file.

| > An additional question is how to represent the privileges that the
| > Kerberos ticket is authenticating for.  Ganymede is designed to have
| > its own record of the user account, and to rely on it to decide login
| > and personae availability.  I imagine that changing Ganymede so that
| > it referenced an external authenticator could certainly be done if
| > need be, but I'm afraid I don't have enough experience with Kerberos
| > to understand the advantages over simply entering the
| > username/password pair.
| 
| Not having to do it is an obvious advantage at least for frequent users.
| By the way, is there an option to allow changing Admin Personae without
| having to type a password? After all, the user has authenticated himself
| once he's got a session.

The purpose of having a separate password for the admin personae is to
protect the elevated privileges from compromise of the user's primary
password.  As long as the user's network password is propagated into
NIS, etc., we felt that it would be appropriate to require an
additional password to access any admin privileges.

You can actually log into Ganymede directly into your admin persona by
specifying a user name of username:persona name (i.e., 'broccol:GASH
Admin'), and providing your persona password.

| I understand JAAS would allow for many different authentication
| mechanisms including passwords, without changing the login code once it's
| used. But then, I'm no more familiar with it than you. But if we find or
| pay someone who is to do the change, would you accept the patch?

I'm currently contemplating branching Ganymede at the 1.1 version.
Any changes that require Java 1.2, 1.3, or 1.4 for the server and/or
clients would go into a new branch.

I'm looking at the JAAS documentation now, and at first glance, it
doesn't seem like it would be that hard to use, but adopting it into
Ganymede might make for an additional dependency on external services,
which I have tried to avoid with Ganymede.

If JAAS can be incorporated into the Ganymede server and client
without getting in the way of people who are not using Kerberos, I
wouldn't mind having that done.  I still believe that having Ganymede
consult with external data sources to authenticate users to itself is
somewhat counter-intuitive, as in theory all authentication data is
going to be mastered from Ganymede to those other services, but I
understand that motivation in the specific case of Kerberos.

| > | But at the time DBEditObject.finalize...() is called, we know exactly
| > | what changes if the transaction is committed, don't we? And we are allowed
| > | to create new objects and add them to the current DBEditSet.
| >
| > The DBEditObject.finalize...() methods are called to finalize changes
| > to individual fields, not to all changes to a given object.
| 
| So one would have to check whether the change event object already
| exists, create it if not, then set the information for the respective
| field. Not as clean as it could be, but it would also make the problem
| you line out in the next paragraph a non-issue, right?

Sure, assuming that we don't provide a new and more fundamental
mechanism for tracking change events.  If we wanted to support delta
tracking in the fashion you suggest, I'd want a more basic mechanism
to be put in place that was integrated into the overall design.  If
change events were given a special status in the server, and did not
have the right to have custom plugins associated with the change
events reject a transaction commit, then it would be reasonable to add
the change event objects from a custom method in DBEditObject
subclasses late in the transaction commit process.  We might want to
integrate these change event objects into the GUI client in some
fashion to allow simple lookup of pending updates, as well.

| > We'd probably want to have some sort of appropriate object queueing
| > and ordering mechanism, for instance.  Right now, neither the GUI
| > client nor the server API provides a method for reordering items
| > within a Vector field, which would probably be important if you wanted
| > to maintain object queues, unless you simply used date fields for
| > everything.
| 
| I'm not sure whether object queues or vectors of change events would be
| needed at all. Ordering is important, though, since successfully
| processing events out of order on the platform will not generally
| possible. If change event objects were labelled by transaction ID+object
| name, would it be simple for the builder/scheduled task to process them
| in the right order?

Again, I would contemplate defining a new mechanism in the server,
with a single change event object type built-in to the server.  Any
specialized logic dealing with these change events would be handled by
custom task plugins.

| One might even want dependencies between events (within a single
| transaction) to allow deferral of execution of those that depend on
| others (no way to add a user to a pts group before it exists, for
| instance).

As long as that only applied to external processing of the change
events, fine.  Once Ganymede commits a transaction, that transaction
_is_ committed, and further user actions will be made on the basis
that the server is already in a committed, transaction-consistent
state.  As long as the delay in processing of the change events will
eventually succeed, there should be no problem.  If a change event
failed to process properly, then Ganymede's transaction consistency
becomes fraudulent with respect to the external network environment,
and getting the database back into consistency with the external
environment could be problematic.

| If it was totally trivial, you'd probably have done it...
| 
| > The one place I've seen problems with heavy linkages is when you have
| > certain objects that lots of objects get symmetrically linked to.  In
| > such cases, only one transaction at a time can make or break a link to
| > the common object, which may well limit concurrency.  By making it an
| > anonymous link, the current Ganymede server core can handle tons of
| > concurrent link and unlink operations, though.
| 
| Aren't owner groups prone to this?

They are at present, yes.  I have not adapted the owner group
definition to use the concurrent anonymous linking logic that was
added to Ganymede in the last year or two.  The owner group case can
be ameliorated by defining a hierarchical structure of owner groups,
such that the odds of any one owner group having objects added to or
removed from it wouldn't be too great.

| > Mm, no, perhaps not.  You're thinking that there would be a User
| > folder, which you would open and see 'UNIX Users', 'NT Users',
| > 'UNIX&NT Users' each as separate subfolders, along with all plain
| > Users listed thereunder?
| 
| Close. Just the "Unix" and "NT" subfolders within the "Accounts" folder.
| Those would be linked to the "Accounts" vector field of the "User"
| object. If there were plain "Account" objects as well, I wouldn't mind
| seeing them at the same level as the subfolders. Having subfolders listed
| first would probably be convenient.

Ah, I see.  We have discussed abstracting our user accounts into a
Person object and discrete Account objects here, as well.  That seems
reasonable to me.

| > | Would it be possible to allow a *list* of object types as reference
| > | targets instead of just one? That would solve most cases I have in mind
| > | nicely.
| >
| > Sure, the DBEditObject class already has methods that you can override
| > to generate custom choice lists for InvidDBFields.  Right now, though,
| > the GUI client doesn't show any kind of type identifier for listed
| > objects, and if you had two objects of differing kinds with the same
| > name, it would probably get confused.
| 
| Labels could be kept unique, for example by having a hidden label
| field set to <prefix>.<object name> by the plugin. In my example, one of
| my unix accounts would read "unix.wiesand".

Well, sure.  In fact, Invid's are by their nature guaranteed to be
unique, so there's already enough information for the client's Invid
selector to tell the items apart, but without providing some cue to
tell identically named objects apart, the situation would be confusing
to the user.

| The pity is that the schema editor seems to choke on these things.
| It won't allow me to set up bidirectional links unless I specify the
| target object type. Ok, using vi on schema.xml would do the trick
| as long as I keep Field Names and IDs consistent, but touching such
| an object definition with the schema editor would break it, and
| being unable to use this fine tool is a *major* loss.

The reason for that is that a bidirectional link has to provide
information on both the target object and the target field, so that
the target field on the target object could automatically be updated.
The server does not have a rich enough data definition model to be
able to handle symmetric linking across variant object types.

Using vi on schema.xml *wouldn't* solve this problem.  This isn't just
a restriction on the schema editor, the DBObjectBaseField class in the
server itself can't handle such a situation.

That's not to say it couldn't be made to do so, but it would be a
significant complication with the current flat type system.

If Ganymede had derivable types, this problem would go away, of
course.  That will be a significant change, however.

| > I've thought about making the Invid selector widget in the GUI client
| > be tree-based in some fashion, to reflect the types of mixed choice
| > lists.  Or, alternatively, at least show an icon of some sort and
| > track and display the type identity to distinguish things that might
| > not have a shared namespace.
| 
| I consider the requirement to have objects in one list share one namespace
| very reasonable and acceptable.

Sure, it's reasonable, but enforcing it is tricky.  Ganymede right now
does not even require that object labels be unique among objects of a
single type.  There are a number of places in the Ganymede system
where enforcing MORE constraints on the data might make for a more
practical and useful system.

Heck, the DBEditObject plugin is flexible enough to actually calculate
labels for objects on the fly.. there's nothing to prevent a
customizer from making an object's label be produced from a random
number generator, and to change each time the object was viewed.

| > Derivable types aside, the major extension I've tried to consider to
| > Ganymede's type system is to allow for hierarchical object containment.
| >
| > That would also complicate the GUI, especially considering that at
| > present an object may have more than one owner.  If ownership was made
| > congruent with containership, the client's object tree could not
| > literally be a tree, as individual objects could appear under multiple
| > container-owners.  The XML file format that Ganymede uses currently
| > would need to be changed as well, along with the query engine, and so
| > on.
| 
| I can't think of anything that could be accomplished by hierarchical
| object containment, but not by derivable types and embedded objects
| as available today. But maybe that's because it's getting late...

The advantage of hierarchical containment would be if one wanted to
support multiple discrete NIS or DNS domains, or if one wanted to
manage users at multiple OU levels of an LDAP organizational tree.
The NIS domain or the OU entity could be a container, and users and
groups could be contained underneath such containers.

You can obviously do this now using object links to create whatever
sort of object graph you like in the database, but without having an
explicit, constrained container relationship, the GUI client wouldn't
be able to represent the database in a tree (or a non-cyclic graph)
form.

Having a real container model could also allow location-dependent
permissions handling as well.  That's why I had considered making
ownership and containment congruent, but that seemed to require
derivable types (so both an NIS domain and an LDAP OU could derive
from owner groups), and would require a reworking both of the client's
GUI and the XML file format.

Trying to extend Ganymede to a multiple-domain model really would
require a pretty fundamental reworking of things, however.  Having
Ganymede do complete rebuilds rather than deltas (as you are
suggesting) makes no sense if you're trying to manage multiple domains.

| > Especially if you're thinking of going away from doing complete builds
| > at each build time, I would think the scalability should be all right.
| 
| I dumped the data of some 2500 real accounts, plus groups, into the
| example UserKit. The GUI copes very well with lists of that size, both the
| tree widget and the edit forms do just fine.

Wonderful.

| Creating a schema vaguely similar to what we'll finally want to have
| (sans plugins) and writing a perl script to fill it with twice the
| anticipated amount of data via xmlclient shouldn't be too much work,
| thanks to ganymede's maturity and documentation, and we'll hopefully do
| that soon. I'll let you know the result.
| 
| Have you ever run a series of such tests?

I'm embarassed to say that I have never run synthetic, large-scale
capacity tests.  I would be very interested to learn how yours go.

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

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