Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rice!uw-beaver!milton!ogicse!intelhf!ichips!inews!iwarp.intel.com!gargoyle!chinet!les From: les@chinet.chi.il.us (Leslie Mikesell) Newsgroups: comp.unix.sysv386 Subject: Re: uid-mapping using RFS (in loopback mode) (on Esix) Message-ID: <1991Mar05.183924.15581@chinet.chi.il.us> Date: 5 Mar 91 18:39:24 GMT References: <1991Mar2.155055.304@unixland.uucp> Organization: Chinet - Chicago Public Access UNIX Lines: 43 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