--- name: "sfs_environ" section: "7" platform: "linux" package: "sfs-common" version: "1:0.8-0+pre20060720.1-1" release: "Debian 4.0 (Etch)" platforms: ["linux"] url: "https://new.carta.tech/sfs_environ" --- # sfs\_environ(7) SFS environment variables ## NAME sfs\_environ - SFS environment variables ## DESCRIPTION The following environment variables affect many of SFS's component programs. (Note that for security reasons, the setuid programs **suidconnect** and **newaid** interpret some of these slightly differently--ignoring some and dropping privilege if others are set.) - ACLNT\_TRACE Used mostly for debugging, *ACLNT\_TRACE* causes most SFS commands to print a trace of all the RPCs they make. The environment variable must be set to an integer. The higher the value, the more trace information. The value 1 causes only anomalous situations such as retransmissions to be reported. 2 causes every RPC to be printed. 4 causes both RPC calls and replies to be printed. Arguments over 5 cause the actual RPC argument and result data structures to be pretty-printed-the higher the number the greater the depth to which recursive data structures will be expanded. A value of 10 is generally sufficient to get a very complete RPC trace. - ACLNT\_TIME A boolean value. When this environment variable and *ACLNT\_TRACE* are both set, the trace includes timestamps as well, which can be useful in debugging. - ASRV\_TRACE - ASRV\_TIME These perform an analogous function to **ACLNT\_TRACE** and **ACLNT\_TIME**, but print out RPCs received (as a server), rather than ones made. - BINDADDR If set, must contain an IPv4 address. Whenever SFS creates a socket that would be bound to **INADDR\_ANY**, it will be bound to *BINDADDR* instead (unless *BINDADDR* is no longer a valid local address). - FDLIM\_HARD - FDLIM\_SOFT Most of the daemons that comprise SFS use asynchronous I/O to handle multiple network connections concurrently. In order to be able to handle as many concurrent connections as possible, the library raises the per-process file descriptor limit to the maximum allowable value. For privileged processes, this additionally means raising the so-called \`\`hard'' file descriptor limit. When raising these values, if the **FDLIM\_SOFT** and **FDLIM\_HARD** environment variables are not set, SFS saves their the old limit values in the environment variables. An example of how this is used is by **rexd**, the remote execution daemon. **rexd** reduces the file descriptor limits to the original values specified by these environment variables before spawning an unprivileged user program. These variables ordinarily should not be of concern to users of SFS, and are documented here mostly for people who notice them and are curious. - SFS\_AGENTSOCK Ordinarily **sfskey** connects to **sfsagent** through the SFS client daemon, **sfscd**. However, by passing the **-S** option to **sfsagent**, it is possible to have **sfsagent** bind an arbitrary Unix domain socket for connections. **SFS\_AGENTSOCK** can be set to such a pathname, and **sfskey** will then connect to that socket. As a special case, if **SFS\_AGENTSOCK** is set to a negative number, this is interpreted to mean a file descriptor number already connected to the agent. This feature is particularly useful when atomically killing and starting **sfsagent** with the **-k** flag. In this case, and program specified on the command line, or the default */usr/local/share/sfs/agentrc* script, will be run with **SFS\_AGENTSOCK** set to a file descriptor. Thus, if the script loads keys into the agent by running **sfskey**, these keys will be loaded into the new agent (before it takes over), rather than into the old agent. - SFS\_CONFIG The location in which to find the *sfs\_config* file. By default, SFS uses configuration files in */usr/local/share/sfs/sfs\_config* and */etc/sfs/sfs\_config*. **sfssd** sets this environment variable when given the **-S** option, so that subsidiary daemons read the same configuration file. - SFS\_HOSTNAME Overrides SFS's default algorithm for figuring out the local hostname. Several SFS programs must know the machine's fully-qualified hostname. In particular, this name constitutes the official *Location* in a server's self-certifying pathname (since a given file system should have only one self-certifying hostname). The hostname of an SFS server must exist in the DNS (as opposed to just */etc/hosts*) for many of the servers to work. The algorithm used by SFS is to determine a host's name is as follows. It checks the system's name with the **gethostname** system call, and if it is fully-qualified (i.e., has a \`\`.domain'' at the end) uses that. Otherwise, it appends the default domain name to the system name. Sometimes SFS's algorithm will not produce the correct hostname. In that case, you can specify the real hostname for each individual daemon such as **sfsrwsd** and **sfsauthd** in their confiruation files. Or, you can just set the environment variable **SFS\_HOSTNAME** before running **sfssd**. Note that if you do not have a DNS name, you can also set **SFS\_HOSTNAME** to the numeric IPv4 address of your host, and then use the IP address as the *Location* in self-certifying pathnames. - SFS\_PORT This variable, if set, specifies official port number of an SFS server--i.e. the *%port* that clients must append to the hostname in the *Location* of the self-certifying pathname. By default (or if **SFS\_PORT** is set to 0), the self-ceritying pathname contains no port number, which means to check DNS for SRV records, and if none are found to use port 4. Because servers have only one canonical self-certifying pathname, setting **SFS\_PORT** to 4 is not the same thing as setting it to 0, even without SRV records. If you set **SFS\_PORT** to 4, then clients who do not specify **%4** in the self-certifying pathname will need to be redirected to a pathname containing *%4* via a symbolic link, and **pwd** run on a client will show the **%4** as part of the self-certifying pathname. Note further that the effects of this environment variable should not be confused with the **BindAddr** option in *sfssd\_config*. For example, if you set up SRV records pointing to TCP port 5 on your server, you might want to specify **BindAddr** **0.0.0.0 5** in *sfssd\_config*, but you almost certainly would not want to set the **SFS\_PORT** environment variable to 5, as setting **SFS\_PORT** to anything other than 0 means the self-certifying pathname contains *%5*, which in turn means DNS SRV records should not be used. (I.e., a client accessing *@host.domain,hostid* would be redirected to *@host.domain%5,hostid*, which would bypass any SRV records for *host.domain* and, depending on DNS data, might not even resolve to the same IP address as the pathname without a *%*.) - SFS\_ROOT Sets the root directory of the SFS file system, which is usually */sfs*. Changing this for anything other than debugging purposes is not recommended, as many symbolic links will break. - SFS\_RUNINPLACE SFS consists of a large number of interacting daemons. Ordinarily, these are launched by **sfscd** and **sfssd**. If you wish to run SFS without installing it, however, these commands will not be able to find the subsidiary daemons they are supposed to launch. Setting **SFS\_RUNINPLACE** to the root of your build directory allows SFS to be run without installing it. Because this option is mainly used for development, however, several programs behave slightly differently when it is set. **sfscd** and **sfssd** both remain in the forground and send their output to standard error, rather than to the system log. Moreover, **sfsagent** does take steps to protect itself from the **ptrace** system call, so that you can attach to it with the debugger when running in place. - TMPDIR Some SFS programs need to create temporary files or Unix-domain sockets in the local file system. By default, these programs use the */tmp* directory or created protected subdirectories of */tmp*. However, you can override the location by setting the **TMPDIR** environment variable. - USER In various places SFS needs a default username--for example, when running **sfskey login**. SFS looks first at the **USER** environment variable, then uses the **getlogin** system call, and if that fails, looks up the current user ID in the system password file. ## SEE ALSO [*dirsearch*(1)](/dirsearch/1.md), [*newaid*(1)](/newaid/1.md), [*rex*(1)](/rex/1.md), [*sfsagent*(1)](/sfsagent/1.md), [*sfskey*(1)](/sfskey/1.md), [*ssu*(1)](/ssu/1.md), *sfs\_config*(5), [*sfs\_hosts*(5)](/sfs_hosts/5.md), [*sfs\_srp\_params*(5)](/sfs_srp_params/5.md), [*sfs\_users*(5)](/sfs_users/5.md), [*sfsauthd\_config*(5)](/sfsauthd_config/5.md), [*sfscd\_config*(5)](/sfscd_config/5.md), *sfsrosd\_config*(5), [*sfsrwsd\_config*(5)](/sfsrwsd_config/5.md), [*sfssd\_config*(5)](/sfssd_config/5.md), [*funmount*(8)](/funmount/8.md), *nfsmounter*(8), [*sfsauthd*(8)](/sfsauthd/8.md), [*sfscd*(8)](/sfscd/8.md), *sfsrosd*(8), *sfsrwcd*(8), [*sfsrwsd*(8)](/sfsrwsd/8.md), [*sfssd*(8)](/sfssd/8.md), [*vidb*(8)](/vidb/8.md) The full documentation for **SFS** is maintained as a Texinfo manual. If the **info** and **SFS** programs are properly installed at your site, the command **info SFS** should give you access to the complete manual. For updates, documentation, and software distribution, please see the **SFS** website at *http://www.fs.net/*. ## AUTHOR sfsdev@redlab.lcs.mit.edu