9p services using srv, listen, exportfs, import D1362236873 Amiller # #INSTANT 9P CONNECTION BETWEEN TWO MACHINES # #The following should be used only on secure private networks or by #machines with no private data. It provides a read-only public 9p #service of the full namespace of the invoking user: # #! server% aux/listen1 -tv tcp!*!9999 /bin/exportfs -R -r / # #To dial and mount this service from another machine: # #! client% srv tcp!ip.of.server!9999 server /n/server # #The client machine will print "post..." and following this, the #client may # #! client% ls /n/server # #and use other commands to work with the mounted filesystem. After #this connection has been made, you may terminate the listener on the #server machine. It is not needed once the mount has been made. # #STANDARD 9P SERVICES FROM FILE AND CPU SERVERS # #There are two main types of 9p service provided in a typical #installation. Disk fileservers such as fossil(4) serve 9p on port #564. This is used for tcp boot of other machines or general purpose #disk storage. The Bell Labs "sources" server is an example. The #commands srv(4) and the 9fs script connect to this type of 9p server. # #CPU servers serve 9p via exportfs(4) on port 17007 and clients #connect by means of import(4). Exportfs enables serving arbitrary #namespace, not simply on-disk file servers. The cpu(1) command makes #use of exportfs to let the cpu server use the devices and filesystem #of the client terminal. Cpu export/import traffic is encrypted by #default. 9p file service on port 564 is not. The normal usage for #import(4) requires specifying what portion of the cpu namespace to #attach. An example: # #! client% import cpuserver /srv /n/cpusrv # #This selects only the /srv of the target cpuserver and mounts it to #/n/cpusrv. Some of the most important targets for import are /srv #and /proc. A grid of cpu servers running from a common file server #and which all import /srv and /proc and certain /dev files from each #other behaves very much like single large machine. This is the #prototypical form of a "Plan 9 Grid" of machines. # #SERVICES ON DEMAND: USING AUX/LISTEN1 AND EXPORTFS # #In a standard configuration of installed machines, file servers #listen on port 564 and cpus listen on port 17007. The file listener #is the responsibility of the disk fs, but the cpu listener is #started by the aux/listen(8) command which starts listeners for #every service found in /rc/bin/service. The aux/listen1 command #allows users to start individual service listeners on demand. # #Using this effectively requires understanding the additional options #for exportfs. There is an important caveat - the -a flag for #authentication of exportfs is in conflict with the -r and -S flags #for specifying a root or /srv to mount. If you wish to use exportfs #to provide secure non-root service exportfs publicly, additional #measures such as the use of tlssrv(8) would be necessary. # #When exportfs is used with the flag -r to specify a root or -S to #specify a /srv, it becomes compatible with the operation of srv(4) #and mount(1). An exportfs done with these flags may be used via srv #and mount of the address. Srv may not be used to attach to standard #exportfs listeners running the full protocol. # #The example at the beginning of this page shows the basic formula #for using exportfs and srv together in this manner. If you wish to #use exportfs for authenticated connections, use import for the #client, like this: # #! server% aux/listen1 -v tcp!*!9999 /bin/exportfs -a #! client% import tcp!server!9999 /remote/path /local/mountpoint # #Note the absence of the -t flag from this listen1 command. # #SRV IN DETAIL: MORE THAN JUST 9P # #The srv(4) command as used above is actually two commands in one. An #initial srv to dial a connection and post a file descriptor in /srv, #and a mount command to attach to that file descriptor as a 9p fs. If #you use srv in this manner: # #! server% srv tcp!server!port srvname # #Then srv acts to dial server and post that network connection as a #file descriptor in /srv. If that file descriptor is a 9p fs, it can #be mounted. If it is not a 9p fs, it can still be interacted with. #An example to show the principles: # #! server% aux/listen1 -tv tcp!*!9999 /bin/cat /lib/namespace #! client% srv tcp!server!9999 remotens #! client% cat /srv/remotens # #The output will be the output of the cat command on the server #machine. In the case of a 9p service, you can separate the srv and #the mount as follows: # #! client% srv tcp!server!564 server #! client% mount /srv/server /n/server # #Note that the action of srv simply dials and places a file #descriptor. If authentication is required, that occurs when the #mount command is issued. # #LISTEN1 AND NAMESPACES: THE -T FLAG # #Most of the examples on this page use the -t flag for listen1. This #means that the service listener is running as the invoking user. #Without the -t flag, the listener runs as user "none". This is a #significant difference because your user account has a different #namespace than the "generic" namespace of "none". When you need to #share a namespace that includes mounts and binds that are not part #of the generic namespace, the -t flag is necessary. # #However, this does make the listener more vulnerable to malicious #security threats. As user "none" a listener which is subverted can #do much less harm than a user listening under the identity of the #invoking user, especially if that user is the hostowner. Be aware of #the difference between -t and listening as none. It is usually #easier and more convenient to listen as your user account, but this #is not recommended for public facing services or services which may #be connected to by untrusted users. # #Also understand that some processes, such as the server side of #cpu(1), may be able to change user identity even when the invoking #listener is none. # #OTHER ISSUES # #This page does not address the configuration of ndb(8) and the #configuration of factotum(4) and auth(8). It is crucial to have a #correct /lib/ndb/local and correct authentication between grid nodes #for standard use of these tools as described by the manpages and #this article. # #Mounting and serving 9p can also be done with Inferno, plan9port, #and many other libraries and tools. In general correctly implemented #clients and servers should all be compatible, but in practice issues #like support for the exportfs protocol may require adjustments and #compromises. The initial author of this wiki page recommends u9fs, #9pfuse, plan9port, and Inferno as the best supported non-plan9 9p #clients and servers. #