bill@unixland.uucp (Bill Heiser) (03/02/91)
I have set up RFS in loopback mode on my Esix Rev D system.
I have a directory /usr2/src mounted as /sources. When I ls the
files in /sources, they show as uid and gid 60002. (they are owned
by me in /usr2/src).
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).
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?
Bill
--
home: ...!{uunet,bloom-beacon,esegue}!world!unixland!bill
bill@unixland.uucp The Think_Tank BBS & Public Access Unix
508-655-3848 (2400) 508-651-8723 (9600-HST) 508-651-8733 (9600-PEP-V32)
other: heiser@world.std.comles@chinet.chi.il.us (Leslie Mikesell) (03/06/91)
In article <1991Mar2.155055.304@unixland.uucp> bill@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@chinet.chi.il.us