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 [EMAIL PROTECTED] to be mounted on /coda.
defaults to "[EMAIL PROTECTED]", 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 [EMAIL PROTECTED] 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 "[EMAIL PROTECTED]" 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 -> [EMAIL PROTECTED] - user/admin created mount (cfs mkm [EMAIL
PROTECTED])
required changes:
- codaconf option to indicate [EMAIL PROTECTED] 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
