import – import a name space from a remote system

import [ options ] system file [ mountpoint ]

import –m [ options ] system mountpoint

import –B [ options ] mountpoint [ cmd [ args ... ] ]

Import allows an arbitrary file on a remote system to be imported into the local name space. Usually file is a directory, so the complete file tree under the directory is made available.

A process is started on the remote machine, with authority of the user of import, to perform work for the local machine using the exportfs(4) service. The default port used is TCP 17007. If mountpoint is omitted, import uses the name of the remote file as the local mount point.

The options are:
a –b –c –CControl the construction of union directories, as in mount and bind(1). Only valid when file is a directory.
A          Skip the authentication protocol. This is useful for connecting to foreign systems like Inferno.
B          Run in ``backwards'' mode, described below.
E enc       Push an authentication protocol on its network connection. The supported protocols are clear (no protocol), ssl, and tls. The default is to try tls, ssl, and clear until one succeeds or they all fail.
e 'enc auth'Specify the encryption and authentication algorithms to use for encrypting the wire traffic (see ssl(3)) if using SSLv2. The defaults are rc4_256 and sha1.
k keypattern   Use keypattern to select a key to authenticate to the remote side (see auth(2)).
p          Push the aan(8) filter onto the connection to protect against temporary network outages.
s name      Post the connection's mountable file descriptor as /srv/name.

The –m option mounts a file exported by exportfs(4) with its –r or –S options, which skip the part of its protocol that allows the importer to specify the file to export. Instead, the file or name space is selected by exportfs, and import mounts it on mountpoint as guided by the other options.

The –B option runs import in ``backwards'' mode. In this mode, import runs a p9any authentication (as server) over its file descriptor 0 (expected to be an incoming network connection from exportfs –B), mounts the connection onto mntpt, and optionally runs cmd args.

Assume a machine kremvax that has IP interfaces for the company intranet and the global internet mounted on /net and /net.alt respectively. Any machine inside the company can get telnet out to the global internet using:
import –a kremvax /net.alt
telnet /net.alt/tcp!ucbvax

Suppose that the machine moscvax has access to a private file server containing public web pages that need to be served by the less–trusted server webvax. Webvax runs the following listener (see listen(8)) on TCP port 999:
import –B –s rowebfs /usr/web /bin/restarthttpd

When moscvax boots, it runs
exportfs –R –r /usr/web –B tcp!webvax!999

to serve a read–only copy of /usr/web to webvax. When webvax gets the call, import mounts the served tree onto its own /usr/web and then runs /bin/restarthttpd to restart httpd(8).


bind(1), ssl(3), tls(3), exportfs(4), srv(4), intro(5), aan(8), listen(8), cs in ndb(8)

mnt(3) seems to interfere with mounting a srv(3) channel which is itself mounted via an encrypted import, probably by breaking up long records, thus requiring `–E clear' in

import –E clear moscvax / /n/moscvax &&
mount /n/moscvax/srv/kremlin /n/kremlin

Currently, pipes and tls(3) have iounits of 65536 but tls's (implementation–specific) maximum record length is 16384, and MAXRPC in mnt(3) is 16384 plus 9P overhead. Something needs to give to make mounting srv(3) channels imported via TLS–encrypted 9P sessions work. The tls iounit of 65536 seems like false advertising.

SSLv2 and RC4 are deprecated.

Copyright © 2024 Plan 9 Foundation. All rights reserved.