rfs_nssd − remotefs server for id-mapping
rfs_nssd [OPTIONS]
−r RFS_HOST
Host of remotefs connection
−s
Start server and/or increase connections counter
−k
Stop server and/or decrease connections counter
-a
Allow other users to use this instance of server (normally used with FUSE’s -oallow_other)
−f
Run in foreground
The purpose of NSS server is to replace id-matching in an automatic way. It provides temporary uids and gids for names retrieved from rfsd by remotefs client. This way systems connected with remotefs don’t need to be fully synced: all names from server will be known on client for remotefs connection life-time.
Technically, rfs process will start one rfs_nss server for each rfs connection (if "ugo" option is used for mounted export). Hovewer, rfs_nss can group several servers in one instance, so you won’t see the same number of rfs_nssd processes as rfs connections.
For example, if user "alex" is running two rfs connections, it’s possible for him to use only one rfs_nss server for both connections. rfs_nss server will count how many rfs connections it handles and will terminate only after all connections are closed.
This is "connections counting" mentioned in options description.
If you’re not sure if you need this, then read rfs(1) man page section "KNOWN ISSUES" for possible side-effects.
Basically, you
need it with the following conditions:
1) you’re using remotefs export with "ugo"
enabled
2) remote and local systems’ users and groups are not
completely synced
$ ls -l
mount_point/
total 20
-rw-r--r-- 1 root@10.0.0.1 root@10.0.0.1 0 2009-07-10 17:51
example
drwx------ 2 alex alex@10.0.0.1 4096 2009-07-10 17:39
orbit-alex
This is typical representation of remote names provided by rfs_nssd. It consists of remote username and rfs host joined with ’@’.
Make note that file owner ’alex’ isn’t transformed by this rule - that’s because remotefs client is running with ’alex’ privileges and logged in as owner of ’orbit-alex’ dir. So to declare ownership of this file to local OS, remotefs transformed its owner to local user.
As said above, rfs_nss provides temorary uids and gids for rfs connection life-time. This applies that you can use these ids as all other ids. For example, to chown(1) files and so on.
rfs_nss can’t check if file you’re chowning is local or remote, so it can’t prevent you to change local file’s owner to someone like alex@10.0.0.1.
This side-effect is somehow similar to ’chown 15000:16000 localfile’: you’ll get localfile with some probably unassigned (yet) uid and gid.
This is possible security threat. Please don’t do so.
Feel free to chown remote files with remote usernames though.
rfs will freely accept "short" remote names as in ’chown alex:alex file’ instead of ’chown alex@10.0.0.1:alex@10.0.0.1 file’. Hovewer, user ’alex’ should be present in local users database.
If he’s not, then you need to use "full" remote name with ’@rfs_host’ after actual username.
Jean−Jacques
Sarton: jjsarton@users.sourceforge.net
Aleksey Tulinov: aleksey_t@users.sourceforge.net
See remotefs project on SourceForge: http://remotefs.sourceforge.net/
GNU General Public License (GPL)
rfsd(8), rfspasswd(8), rfs(1), nsswitch.conf(5)