On Tue, Jul 29, 2003 at 06:35:48PM +0200, Steffen Neumann wrote:
> Exporting and importing the pdb I had to do manually,
> since pdbtool import complained about users for a group 
> it couldn't find.

Interesting, I though pdbtool import added groups first before trying to
import any users. So something like that shouldn't happen, except if the
exported data didn't have the group information.

> The realms awareness without backwards compatibility 
> is a pain in the a**. To exagerate it: why bother
> about compatibility with 5.3.x clients, if neither
> installed programs (-rpath /coda/vol/gnu/lib)
> nor configuration (ln -s /coda/homes/sneumann/.fvwmrc /homes/sneumann)
> files work anymore ?!

Because there are no server-side changes for realms. The only reason
we're backwards compatibile is because the client-server protocol is
still the same. I agree that it is a pain to switch to the new scheme,
not just the name changes, but also the kernel patching.

However, there are some advantages. There is no need to set up a client
for a specific realm, it is impossible to get a conflict on /coda that
can only be repaired by created a temporary rootvolume, and forcing the
client to mount the temporary root. Pathnames are always globally
unique, I could send you a script that refers to something in
/coda/coda.cs.cmu.edu/usr/jaharkes/bin/* and it will work.

> I'd like to see some soft migration, 
> and the coda/realms hack with a zillion links
> is no solution, since all links clutter
> the /coda root volume on 5.3.x clients.

Possible alternatives that were discussed were, each of these needs
only a couple of changes.

reintroduce 'rootvolume='
-------------------------

  /coda				- either pre-6.0, or 6.0

  required changes:
  - codaconf option to indicate volume_at_realm to be mounted on /coda.
    defaults to "CodaRoot_at_localhost", which is the fake rootvolume.
    
  problems:
  - have to configure a client for a specific realm
  - can get a conflict on /coda
  - impossible to access other realms.
  - because everything keeps using /coda, nothing will ever migrate to
    the new scheme.


'exports' (imports?) volume
---------------------------

  /coda/ 		- same as pre-6.0
  /coda/exports/	- 'magic realm volume'

  required changes:
  - codaconf option to indicate volume_at_realm to be mounted on /coda,
    empty volumename already maps to the current rootvolume.
  - either persistently map /coda/exports, or have the local admin
    create a mountpoint to mount the "CodaRoot_at_localhost" volume (remove
    venus check that currently blocks the mount).

  problems:
  - have to configure a client for a specific realm
  - can get a conflict on /coda
  - need to special case /coda/exports/local.realm -> /coda to avoid
    having the same directory show up in more than one location.
  - most users/scripts will keep using /coda/usr/foo because
    /coda/exports/local.realm/usr/foo is a lot more typing.
  
NFS like
--------

  /coda/			- same as pre-6.0
  /coda/foo -> #volume_at_realm 	- user/admin created mount (cfs mkm vol_at_realm)

  required changes:
  - codaconf option to indicate volume_at_realm to be mounted on /coda
  - remove a check that disables cross-realm mounts.

  problems:
  - have to configure a client for a specific realm
  - can get a conflict on /coda
  - every realm can mount things wherever, chaotic, no uniform
    pathnames, /coda/usr/jaharkes could be mounted in a totally
    different location in your domain.
  - need some way to detect duplicate directories and infinite loops.
  - the path doesn't give a clue to where files really are located.

New mountpoint
--------------

    /coda-realms/			- normal 6.0 root
    /coda -> /coda-realms/local.realm	- a symlink for our current realm

    (New programs/scripts should be modified to use /coda-realms/local.realm)
    
    required changes:
    - There should be no changes necessary in the venus code.
    - codaconfedit venus.conf mountpoint /coda-realms
    - mkdir /coda-realms ; restart venus
    - rmdir /coda ; ln -s /coda/local.realm /coda

    problems:
    - Adds more to the already long pathnames.
    - I don't like the /coda-realms mountpoint name, but can't come up
      with anything better. (maybe /realms ?)

There were more, but I forgot what the proposals were. Basically this
stuff had been discussed over and over, many times over a period of 4-5
years (maybe more). Nobody could really come to an agreement. At some
point I started implementing some core functionality that could support
many/most of the proposed schemes. Once we had something running we
finally could get an idea of how usable various solutions were. After
that it was just a matter of adding some checks to reject all
'inappropriate' uses.

> Is there a way to overcome the read-only-ness
> of 6.0 /coda and place *forward* links like 
> 
> 	ln -s /coda/aipc1.tech ... .de/homes /coda/homes

No, that is impossible. The fake rootvolume has no backend to store such
things. I don't like how similar shortcuts have been used/abused in afs.
(I'm sure that /afs/cs/ does not map to /afs/cs.cmu.edu at your uni).

> (1) today was the first time I had a look into 
>     the testserver, you might want to clean it up a bit;-)

I run tmpreaper once in a while. It doesn't look as cluttered as it
was when I brought the first realm-aware client up.

Jan