Provided by: sfs-common_0.8-0+pre20060720.1-1.1_i386
 

NAME

        sfs_environ - SFS environment variables
 

DESCRIPTION

        The following environment variables affect many of SFS’s component pro‐
        grams.  (Note that for security reasons, the setuid programs suidcon     
        nect 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 gen‐
            erally 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 han‐
            dle 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 allow‐
            able 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 vari‐
            ables 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 dae‐
            mon, 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 con‐
            nected 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 con‐
            figuration file.
 
        SFS_HOSTNAME
            Overrides SFS’s default algorithm for figuring out the local host‐
            name.  Several SFS programs must know the machine’s fully-qualified
            hostname.  In particular, this name constitutes the official Loca‐
            tion in a server’s self-certifying pathname (since a given file
            system should have only one self-certifying hostname).  The host‐
            name 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 fol‐
            lows.  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 path‐
            names.
 
        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_con‐
            fig, 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 envi‐
            ronment 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.
        dirsearch(1), newaid(1), rex(1), sfsagent(1), sfskey(1), ssu(1),
        sfs_config(5), sfs_hosts(5), sfs_srp_params(5), sfs_users(5),
        sfsauthd_config(5), sfscd_config(5), sfsrosd_config(5), sfsrwsd_con‐
        fig(5), sfssd_config(5), funmount(8), nfsmounter(8), sfsauthd(8),
        sfscd(8), sfsrosd(8), sfsrwcd(8), sfsrwsd(8), sfssd(8), vidb(8)
 
        The full documentation for SFS is maintained as a Texinfo manual.  If
        the info and SFS programs are properly installed at your site, the com‐
        mand 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