uid-mapping using RFS (in loopback mode) (on Esix)
Leslie Mikesell
les at chinet.chi.il.us
Wed Mar 6 04:39:24 AEST 1991
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
More information about the Comp.unix.sysv386
mailing list