uid-mapping using RFS (in loopback mode) (on Esix)

[Leslie Mikesell]

In article <1991Mar2.155055.304 at unixland.uucp> bill at unixland.uucp (Bill Heiser) writes:

>Following is an excerpt from the Esix Release Notes:
>
>  idload
>    Many ID mapping features do not function properly with the loopback
>    function.  Only use "global" blocks of information in mapping files
>    (uid.rules and gid.rules).  Within global blocks only "default
>    transparent" works as intended.  Specific mapping (map lines) or
>    attempts to use "host" blocks will result in users and groups being
>    mapped to 60002.

>Basically I guess they're saying that the RFS loopback mode is broken 
>(read: useless except for read-only file systems, and only those world
>readable).

No, "default transparent" is probably what you want, since it maps
the uid's on the RFS mount into the same uid number when it is
interpreted.

>My questions, though concern "global blocks", "uid.rules", "gid.rules",
>"default transparent", "map lines", and "host blocks".
>What do these mean?  Is there some way to "use" these to get around
>the aforementioned bugs?

Based on AT&T's RFS:
/usr/nserve/auth.info/uid.rules
should contain:
global
default transparent

and so should /usr/nserve/auth.info/gid/rules.

Then if you do "idload" (as root) or re-boot, the uid's should look the
same through the loop-back RFS as locally.

BTW, I've considered setting up a loop-back mount just to be able to
get a read-only mount so I could do a backup without touching the
atime or ctime of the files, but I've been too lazy to try it.  What
kind of performance do you get?

Les Mikesell
  les at chinet.chi.il.us