slattach

title: slattach(8)

text:
# slattach(8)

## NAME
slattach - attach a network interface to a serial line

## SYNOPSIS
slattach [-dehlLmnqv] [-c command] [-p proto] [-s speed] [tty]

## DESCRIPTION
Slattach is a tiny little program that can be used to put a normal terminal ("serial") line into one of several "network" modes, thus allowing you to use it for point-to-point links to other computers.

## OPTIONS
[-c command]

Execute command when the line is hung up. This can be used to run scripts or re-establish connections when a link goes down.

[-d]

Enable debugging output. Useful when determining why a given setup doesn't work.

[-h]

Exit when the carrier is lost. This works on both /dev/tty and /dev/cua devices by directly monitoring the carrier status every 15 seconds. [-v] Enable verbose output. Useful in shell scripts.

[-q]

Operate in quiet mode - no messages at all.

[-l]

Create an UUCP-style lockfile for the device in /var/lock/serial.

[-n]

Equivalent to the "mesg n" command.

[-m]

Do not initialize the line into 8 bits raw mode.

[-e]

Exit right after initializing device, instead of waiting for the line to hangup.

[-L]

Enable 3 wire operation. The terminal is moved into CLOCAL mode, carrier watching is disabled.

[-p proto]

Set a specific kind of protocol to use on the line. The default is set to cslip , i.e. compressed SLIP. Other possible values are slip (normal SLIP), adaptive (adaptive CSLIP/SLIP), ppp (Point-to-Point Protocol) and kiss (a protocol used for communicating with AX.25 packet radio terminal node controllers). The special argument tty can be used to put the device back into normal serial operation. Using 'ppp' mode is not normally useful as ppp requires an additional ppp daemon pppd to be active on the line. For kiss connections the axattach program should be used.

[-s speed]

Set a specific line speed, other than the default.

If no arguments are given, the current terminal line (usually: the login device) is used. Otherwise, an attempt is made to claim the indicated terminal port, lock it, and open it.

## FILES
/dev/cua* /var/lock/serial/LCK.*

## BUGS
None known.

## SEE ALSO
axattach(8), dip(8) pppd(8), sliplogin(8).

## AUTHORS
Fred N. van Kempen, <waltje@uwalt.nl.mugnet.org>

Alan Cox, <Alan.Cox@linux.org>

Miquel van Smoorenburg, <miquels@drinkel.ow.org>

George Shearer, <gshearer@one.net>

Yossi Gottlieb, <yogo@math.tau.ac.il>


afpd

package: netatalk

title: afpd(8)

summary: Apple Filing Protocol daemon

text:
# afpd(8)

## NAME
afpd - Apple Filing Protocol daemon

## SYNOPSIS
afpd [-d] [-F configfile]

afpd -v | -V | -h

## DESCRIPTION
afpd provides an Apple Filing Protocol (AFP) interface to the Unix file system. It is normally started at boot time by netatalk(8).

@pkgconfdir@/afp.conf is the configuration file used by afpd to determine the behavior and configuration of a file server.

## OPTIONS
-d

Specifies that the daemon should not fork.

-v

Print version information and exit.

-V

Print verbose information and exit.

-h

Print help and exit.

-F configfile

Specifies the configuration file to use. (Defaults to @pkgconfdir@/afp.conf.)

## SIGNALS
To shut down a user's afpd process it is recommended that SIGKILL (-9) NOT be used, except as a last resort, as this may leave the CNID database in an inconsistent state. The safe way to terminate an afpd is to send it a SIGTERM (-15) signal and wait for it to die on its own.

SIGTERM and SIGUSR1 signals that are sent to the main afpd process are propagated to the children, so all will be affected.

SIGTERM

Clean exit. Propagates from master to childs.

SIGQUIT

Send this to the master afpd, it will exit leaving all children running! Can be used to implement AFP service without downtime.

SIGHUP

Sending a SIGHUP to afpd will cause it to reload its configuration files.

SIGINT

Sending a SIGINT to a child afpd enables max_debug logging for this process. The log is sent to the file /tmp/afpd.PID.XXXXXX. Sending another SIGINT will revert to the original log settings.

SIGUSR1

The afpd process will send the message "The server is going down for maintenance." to the client and shut itself down in 5 minutes. New connections are not allowed. If this is sent to a child afpd, the other children are not affected. However, the main process will still exit, disabling all new connections.

SIGUSR2

The afpd process will look in the message directory configured at build time for a file named message.pid. For each one found, a the contents will be sent as a message to the associated AFP client. The file is removed after the message is sent. This should only be sent to a child afpd.

## FILES
@pkgconfdir@/afp.conf

configuration file used by afpd

/var/lib/netatalk/afp_signature.conf

list of server signature

/var/lib/netatalk/afp_voluuid.conf

list of UUID for Time Machine volume

@pkgconfdir@/extmap.conf

file name extension mapping

@pkgconfdir@/msg/message.pid

contains messages to be sent to users.

## SEE ALSO
netatalk(8), hosts_access(5), afp.conf(5), afp_signature.conf(5), afp_voluuid.conf(5), extmap.conf(5), dbd(1).

## AUTHOR
See CONTRIBUTORS[1]

## NOTES
1.

CONTRIBUTORS

https://github.com/Netatalk/netatalk/blob/main/CONTRIBUTORS


title: cnid_dbd(8)

text:
# cnid_dbd(8)

## NAME
cnid_dbd - implement access to CNID databases through a dedicated daemon process

## SYNOPSIS
cnid_dbd

cnid_dbd -v | -V

## DESCRIPTION
cnid_dbd provides an interface for storage and retrieval of catalog node IDs (CNIDs) and related information to the afpd daemon. CNIDs are a component of Macintosh based file systems with semantics that map not easily onto Unix file systems. This makes separate storage in a database necessary. cnid_dbd is part of the CNID backend framework of afpd and implements the dbd backend.

cnid_dbd is never started via the command line or system startup scripts but only by the cnid_metad daemon. There is one instance of cnid_dbd per netatalk volume.

cnid_dbd uses the Berkeley DB database library and uses transactionally protected updates. The dbd backend with transactions will avoid corruption of the CNID database even if the system crashes unexpectedly.

cnid_dbd inherits the effective userid and groupid from cnid_metad on startup, which is normally caused by afpd serving a netatalk volume to a client. It changes to the Berkeley DB database home directory dbdir that is associated with the volume. If the userid inherited from cnid_metad is 0 (root), cnid_dbd will change userid and groupid to the owner and group of the database home directory. Otherwise, it will continue to use the inherited values. cnid_dbd will then attempt to open the database and start serving requests using filedescriptor clntfd. Subsequent instances of afpd that want to access the same volume are redirected to the running cnid_dbd process by cnid_metad via the filedescriptor ctrlfd.

cnid_dbd can be configured to run forever or to exit after a period of inactivity. If cnid_dbd receives a TERM or an INT signal it will exit cleanly after flushing dirty database buffers to disk and closing Berkeley DB database environments. It is safe to terminate cnid_dbd this way, it will be restarted when necessary. Other signals are not handled and will cause an immediate exit, possibly leaving the CNID database in an inconsistent state (no transactions) or losing recent updates during recovery (transactions).

The Berkeley DB database subsystem will create files named log.xxxxxxxxxx in the database home directory dbdir, where xxxxxxxxxx is a monotonically increasing integer. These files contain the transactional database changes. They will be removed regularly, unless the logfile_autoremove option is specified in the db_param configuration file (see below) with a value of 0 (default 1).

## OPTIONS
-v, -V

Show version and exit.

## CONFIGURATION
cnid_dbd reads configuration information from the file db_param in the database directory dbdir on startup. If the file does not exist or a parameter is not listed, suitable default values are used. The format for a single parameter is the parameter name, followed by one or more spaces, followed by the parameter value, followed by a newline. The following parameters are currently recognized:

logfile_autoremove

If set to 0, unused Berkeley DB transactional logfiles (log.xxxxxxxxxx in the database home directory) are not removed on startup of cnid_dbd and on a regular basis. Default: 1.

cachesize

Determines the size of the Berkeley DB cache in kilobytes. Default: 8192. Each cnid_dbd process grabs that much memory on top of its normal memory footprint. It can be used to tune database performance. The db_stat utility with the -m option that comes with Berkeley DB can help you determine whether you need to change this value. The default is pretty conservative so that a large percentage of requests should be satisfied from the cache directly. If memory is not a bottleneck on your system you might want to leave it at that value. The Berkeley DB Tutorial and Reference Guide has a section Selecting a cache size that gives more detailed information.

flush_frequency, flush_interval

flush_frequency (Default: 1000) and flush_interval (Default: 1800) control how often changes to the database are checkpointed. Both of these operations are performed if either i) more than flush_frequency requests have been received or ii) more than flush_interval seconds have elapsed since the last save/checkpoint. Be careful to check your harddisk configuration for on disk cache settings. Many IDE disks just cache writes as the default behaviour, so even flushing database files to disk will not have the desired effect.

fd_table_size

is the maximum number of connections (filedescriptors) that can be open for afpd client processes in cnid_dbd. Default: 512. If this number is exceeded, one of the existing connections is closed and reused. The affected afpd process will transparently reconnect later, which causes slight overhead. On the other hand, setting this parameter too high could affect performance in cnid_dbd since all descriptors have to be checked in a select() system call, or worse, you might exceed the per process limit of open file descriptors on your system. It is safe to set the value to 1 on volumes where only one afpd client process is expected to run, e.g. home directories.

idle_timeout

is the number of seconds of inactivity before an idle cnid_dbd exits. Default: 600. Set this to 0 to disable the timeout.

## UPDATING
Note that the first version to appear after Netatalk 2.1 i.e. Netatalk 2.1.1, will support Berkeley DB updates on the fly without manual intervention. In other words Netatalk 2.1 does contain code to prepare the Berkeley DB database for upgrades and to upgrade it in case it has been prepared before. That means it can't upgrade a 2.0.x version because that one didn't prepare the database.

In order to update between older Netatalk releases using different Berkeley DB library versions, follow this steps:

•Stop the to be upgraded old version of Netatalk

•Using the old Berkeley DB utilities run db_recover -h <path to .AppleDB>

•Using the new Berkeley DB utilities run db_upgrade -v -h <path to .AppleDB> -f cnid2.db

•Again using the new Berkeley DB utilities run db_checkpoint -1 -h <path to .AppleDB>

•Start the the new version of Netatalk

## SEE ALSO
cnid_metad(8), afpd(8), dbd(1)

## AUTHOR
See CONTRIBUTORS[1]

## NOTES
1.

CONTRIBUTORS

https://github.com/Netatalk/netatalk/blob/main/CONTRIBUTORS


title: cnid_metad(8)

summary: start cnid_dbd daemons on request

text:
# cnid_metad(8)

## NAME
cnid_metad - start cnid_dbd daemons on request

## SYNOPSIS
cnid_metad [-d] [-F configuration file]

cnid_metad -v | -V

## DESCRIPTION
cnid_metad waits for requests from afpd to start up instances of the cnid_dbd daemon. It keeps track of the status of a cnid_dbd instance once started and will restart it if necessary. cnid_metad is normally started at boot time by netatalk(8) and runs until shutdown.

## OPTIONS
-d

cnid_metad will remain in the foreground and will also leave the standard input, standard output and standard error file descriptors open. Useful for debugging.

-F configuration file

Use configuration file as the configuration file. The default is @pkgconfdir@/afp.conf.

-v, -V

Show version and exit.

## CAVEATS
cnid_metad does not block or catch any signals apart from SIGPIPE. It will therefore exit on most signals received. This will also cause all instances of cnid_dbd's started by that cnid_metad to exit gracefully. Since state about and IPC access to the subprocesses is only maintained in memory by cnid_metad this is desired behaviour. As soon as cnid_metad is restarted afpd processes will transparently reconnect.

## SEE ALSO
netatalk(8), cnid_dbd(8), afpd(8), dbd(1), afp.conf(5)

## AUTHOR
See CONTRIBUTORS[1]

## NOTES
1.

CONTRIBUTORS

https://github.com/Netatalk/netatalk/blob/main/CONTRIBUTORS


netatalk

title: netatalk(8)

text:
# netatalk(8)

## NAME
netatalk - Netatalk AFP server service controller daemon

## SYNOPSIS
netatalk [-F configfile]

netatalk -v | -V

## DESCRIPTION
netatalk is the service controller daemon responsible for starting and restarting the AFP daemon afpd and the CNID daemon cnid_metad. It is normally started at boot time by init system (BSD-style init, SysV-sytle init, systemd, Upstart, OpenRC, SMF and so on).

## OPTIONS
-v | -V

Print version information and exit.

-F configfile

Specifies the configuration file to use. (Defaults to @pkgconfdir@/afp.conf.)

## SIGNALS
SIGTERM

Stop Netatalk service, AFP and CNID daemons

SIGHUP

Sending a SIGHUP will cause the AFP daemon reload its configuration file.

## FILES
@pkgconfdir@/afp.conf

configuration file used by netatalk(8), afpd(8) and cnid_metad(8)

## SEE ALSO
afpd(8), cnid_metad(8), afp.conf(5).

## AUTHOR
See CONTRIBUTORS[1]

## NOTES
1.

CONTRIBUTORS

https://github.com/Netatalk/netatalk/blob/main/CONTRIBUTORS


netatopd

package: netatop

title: netatopd(8)

text:
# netatopd(8)

## NAME
netatopd - log network statistics of finished processes

## DESCRIPTION
This manual page documents the netatopd daemon. This daemon reads the counters of exited processes delivered by the netatop module and writes the counters to a logfile.

The 'usual' state of this daemon is the getsockopt() command NETATOP_GETCNT_EXIT. With this command, netatopd blocks until an exited task is available on the exitlist of the netatop module. The obtained netpertask struct that countains the counters of an exited process is written to a logfile (similar to the process accounting info provided by the base kernel itself). The daeon stops logging when there is only 5% of free space left in the filesystem of the logfile.

The logfile starts with a small header struct that contains a.o. a sequence number indicating how many netpertask structs are currently logged. This header is mmapped and can be consulted by analysis processes like atop that consult the logfile. Behind the header, the netpertask structs can be found in compressed form. Every compressed netpertask struct is preceeded by one byte specifying the size of the compressed netpertask struct.

Before an analysis process starts using the logfile, it has to subscribe itself by decrementing a semaphore owned by the netatopd daemon. In this way, netatopd knows how many analysis processes are currently using the logfile. When no processes use the logfile any more, netatopd truncates the logfile and start building a new one as soon as a new subscription of an analysis process is noticed.

## FILES
/var/run/netatop.log

File in which netatopd writes the compressed accounting records about processes that have finished.

## SEE ALSO
netatop(4), atop(1), atopsar(1), atoprc(5)

http://www.atoptool.nl

## AUTHOR
Gerlof Langeveld (gerlof.langeveld@atoptool.nl)


netdate

package: netdate

title: netdate(8)

text:
# netdate(8)

## NAME
netdate - set date and time by ARPA Internet RFC 868

## SYNOPSIS
netdate [ -v ] [ -l limit ] [ protocol ] hostname...

## DESCRIPTION
Netdate takes a list of names of Internet hosts as arguments, selects the one which supplies the best time, and sets the system time accordingly. The invoker must be the super-user for the time to be set. Protocol names (either udp or tcp) may be interspersed with the host names, and determine the protocol which will be used to connect to the hosts whose names follow, up to the next protocol name or the end of the arguments. The default protocol is udp.

The ``best'' time is chosen by polling the named hosts once each to find their times and taking their differences from the local host's time. These differences are used to find the largest group of hosts whose times agree with each other within a certain limit. The first host in the largest group is picked as the best host. (The assumption is that the hosts which are usually most accurate will be named first.) That host is polled again and the local host's time is set to the result. The chosen host's time is checked on this second poll to insure that its difference from the local host's time has not varied more than the limit from its difference at the first poll.

The default limit is five seconds. It may be set with the -l option. The -v option causes the groups to be shown. The host name localhost is recognized as a synonym for the name of the local host, no network connection is made for it, and its time difference is always zero. If localhost is chosen as having the best time, the system time will not be set. Hosts which do not respond are not counted in the groups. If the limit is set to zero, the time is set to that of the first host to respond and no other checking is done. Supplying only one host name argument also sets the limit to zero.

While the RFC868 protocol only returns 32 bits of data, containing the time in seconds, netdate will accept an extra 32 bits, containing microseconds (expected to be accurate to no more than milliseconds). Delays on long haul networks may make this extra precision useless, but it is useful on local area networks. The extra precision is not used on the first poll of a host, but it is used on the second poll of the chosen host, if that host supplies it.

## EXAMPLE
The most accurate hosts are named first in each example. Some such call on netdate should be put at the end of /etc/init.d/boot.local, so that the time will be set properly on system startup. It is also useful to have a shell script, e.g., /sbin/timehosts, which contains a call on netdate with arguments appropriate to the local system, so that it is easy to set the time manually.

## netdate -l 30 udp dcn-gate tcp neighbor
Dcn-gate is a hypothetical host which usually keeps time accurate to within milliseconds of Coordinated Universal Time, but may occasionally be eight hours off. Neighbor is a neighbor of the local host which keeps time with moderate accuracy. The time will be set to that of dcn-gate if that and neighbor agree to within thirty seconds, else it will not be set at all. This is almost good enough for most circumstances, but won't do when the local host's time is known to be wrong (e.g., after a long downtime or a bad crash) and must be set to something. If one of the hosts named is inaccurate or not responding, there is a problem.

## netdate -l 30 udp dcn-gate tcp neighbor neighbor2
Only two of the three hosts named must agree on the time. The time will still be set (to that of the first neighbor), even if dcn-gate is far off as long as the two neighbors agree. This is probably good enough for most cases. One can arbitrarily gerrymander the vote for more insurance (and less clarity), as in the following example.

## netdate udp dcn-gate dcn1 tcp bbn-unix localhost neighbor
Here dcn1 and bbn-unix are more hypothetical very accurate timekeepers, at least one of which keeps time independently from dcn-gate, one hopes. It is very likely that the time will be set to that one of those three very accurate hosts, as long as at least two of them agree, or at least one of them agrees with the neighbor or the local host's time. If all the foreign hosts disagree, the time will not be set, since localhost will be chosen as best.

## netdate -l 3 localhost localhost udp dcn-gate dcn1 tcp bbn-unix
This example gives localhost two votes and declares it to usually have the most accurate time. All three foreign hosts must agree within three seconds and also differ from localhosts by more than three seconds for the time to be set. Thus the time will be set only if it really needs to be.

## FILES

```
/etc/services	for the time service port number
/etc/protocols	for the protocol numbers
/var/log/wtmp	to record time-setting
```

## SEE ALSO
ARPANET Request for Comments 868, gettimeofday(2), date(1), WWV (USA): 2.5,5,10,15 MHz AM for Coordinated Universal Time (UCT).


nethogs

package: nethogs

title: nethogs(8)

text:
# nethogs(8)

## NAME
nethogs - Net top tool grouping bandwidth per process

## SYNOPSIS
nethogs [-h] [-V] [-d] [-v] [-t] [-c] [-p] [-s] [device(s)]

## DESCRIPTION
NetHogs is a small 'net top' tool. Instead of breaking the traffic down per protocol or per subnet, like most such tools do, it groups bandwidth by process - and does not rely on a special kernel module to be loaded. So if there's suddenly a lot of network traffic, you can fire up NetHogs and immediately see which PID is causing this, and if it's some kind of spinning process, kill it.

### Options
-h

display available commands usage.

-V

prints Version info.

-d

delay for refresh rate.

-v

select view mode

-p

sniff in promiscious mode (not recommended).

-t

tracemode.

-c

limit number of refreshes

-s

sort by traffic sent

device(s) to monitor. By default eth0 is being used.

## INTERACTIVE CONTROL
m

cycle between display modes (kb/s, kb, b, mb)

r

sort by 'received'

s

sort by 'sent'

q

quit

## SEE ALSO
netstat(8) tcpdump(1) pcap(3)

## AUTHOR

```
Written by Arnout Engelen <arnouten@bzzt.net>.
```


netlabel-config

title: netlabel-config(8)

summary: NetLabel configuration utility

text:
# netlabel-config(8)

## NAME
netlabel-config - NetLabel configuration utility

## SYNOPSIS
netlabelctl reset| load

## DESCRIPTION
The NetLabel configuration utility, netlabel-config, is a script designed to make it easier for system administratiors to create, manage, and use complex NetLabel configurations. The netlabel-config script uses the netlabelctl(8) tool and /etc/netlabel.rules configuration file to load a saved NetLabel configuration into the kernel and reset the kernel's NetLabel configuration to the default state when needed.

reset

Removes any NetLabel configuration loaded into the kernel and resets the kernel's NetLabel state to the default.

load

Loads the NetLabel configuration specified by /etc/netlabel.rules into the kernel.

## EXIT STATUS
Returns zero on success, errno values on failure.

## NOTES
The NetLabel subsystem is supported on Linux Kernels version 2.6.19 and later. The static, or fallback, labels are only supported on Linux Kernels version 2.6.25 and later. The domain mapping address selectors are only supported on Linux Kernels 2.6.28 and later and CALIPSO/RFC5570 is only supported on Linux Kernels 4.8.0 and later.

The NetLabel project site, with more information including the source code repository, can be found at https://github.com/netlabel. Please report any bugs at the project site or directly to the author.

## AUTHOR
Paul Moore <paul@paul-moore.com>

## SEE ALSO
netlabelctl(8)


netlabelctl

title: netlabelctl(8)

summary: NetLabel management utility

text:
# netlabelctl(8)

## NAME
netlabelctl - NetLabel management utility

## SYNOPSIS
netlabelctl [<global_flags>] <module> [<module_commands>]

## DESCRIPTION
The NetLabel management utility, netlabelctl, is a command line program designed to allow system administrators to configure the NetLabel system in the kernel. The utility is based around different "modules" which correspond to the different types of NetLabel commands supported by the kernel.

## OPTIONS

### Global Flags
-h

Help message

-p

Attempt to make the output human readable or "pretty"

-t <seconds>

Set a timeout to be used when waiting for the NetLabel subsystem to respond

-v

Enable extra output

-V

Display the version information

### Modules and Commands
mgmt

The management module is used to perform general queries about the NetLabel subsystem within the kernel. The different commands and their syntax are listed below.

version

Display the kernel's NetLabel management protocol version.

protocols

Display the kernel's list of supported labeling protocols.

map

The domain mapping module is used to map different NetLabel labeling protocols to either individual LSM domains or the default domain mapping. It is up to each LSM to determine what defines a domain. With SELinux, the normal SELinux domain should be used, i.e. "ping_t". In addition to protocol selection based only on the LSM domain, it is also possible to select the labeling protocol based on both the LSM domain and destination address. The network address selectors can specify either single hosts or entire networks and work for both IPv4 and IPv6, although the labeling protocol chosen must support the IP version chosen. When specifying the labeling protocol to use for each mapping there is an optional "extra" field which is used to further identify the specific labeling protocol configuration. When specifying the unlabeled protocol, "unlbl", an extra value of either "4" or "6" may be used. This restricts the mapping to IPv4 or IPv6 addresses. Omitting the extra value will result in a mapping for all address families. When specifying the CIPSO/IPv4 or the CALIPSO/IPv6 protocol, "cipso" or "calipso", the DOI value should be specified; see the EXAMPLES section for details. The different commands and their syntax are listed below.

add default|domain:<domain> [address:<ADDR>[/<MASK>]] protocol:<protocol>[,<extra>]

Add a new LSM domain / network address to NetLabel protocol mapping.

del default|domain:<domain>

Delete an existing LSM domain to NetLabel protocol mapping.

list

Display all of the configured LSM domain to NetLabel protocol mappings.

unlbl

The unlabeled (unlbl) module controls the unlabeled protocol which is used both when labeling outgoing traffic is not desired as well as when unlabeled traffic is received by the system. This module allows administrators to block all unlabeled packets from the system through the "accept" flag and assign static, or fallback, security labels to unlabeled traffic based on the inbound network interface and source address.

accept on|off

Toggle the unlabeled traffic accept flag.

add default|interface:<dev> address:<addr>[/<mask>] label:<label>

Add a new static/fallback entry.

del default|interface:<dev> address:<addr>[/<mask>]

Delete an existing static/fallback entry.

list

Display the status of the unlabeled accept flag.

cipso

The CIPSO/IPv4 (cipso) module controls the CIPSO/IPv4 labeling engine in the kernel. The CIPSO/IPv4 engine provided by NetLabel supports multiple Domains Of Interpretation (DOI) and the CIPSO/IPv4 module allows for different configurations for each DOI. At present there are three types of configurations, the "trans" configuration which allows on-the-fly translation of MLS sensitivity labels, the "pass" configuration which does not perform any translation of the MLS sensitivity label and the "local" configuration which conveys the full LSM security label over localhost/loopback connections. Regardless of which configuration type is chosen a DOI value must be specified and if the "trans" or "pass" configurations are specified then a list of the CIPSO/IPv4 tag types to use when generating the CIPSO/IPv4 packet labels must also be specified. The list of CIPSO/IPv4 tags is ordered such that when possible the first tag type listed is used when a CIPSO/IPv4 label is generated. However, if it is not possible to use the first tag type then each tag type is checked, in order, until a suitable tag type is found. If a valid tag type can not be found then the operation causing the CIPSO/IPv4 label will fail, typically this occurs whenever a new socket is created. The different commands and their syntax are listed below.

add trans doi:<DOI> tags:<T1>,<Tn> levels:<LL1>=<RL1>,<LLn>=<RLn> categories:<LC1>=<RC1>,<LCn>=<RCn>

Add a new CIPSO/IPv4 configuration using the standard/translated mapping with the given level and category translations. The levels are translated in such a way that the local level "LLn" is translated to the remote, on-the-wire level of "RLn"; the reverse translation is done for incoming packets. The same translation is done for the categories using "LCn" and "RCn". In order for a packet to be accepted, or a socket created by an application, there must be a translation for the sensitivity level and all the categories present in the MLS sensitivity label; if the entire requested sensitivity label can not be translated the application will fail.

add pass doi:<DOI> tags:<T1>,<Tn>

Add a new CIPSO/IPv4 configuration without any level or category translations.

add local doi:<DOI>

Add a new CIPSO/IPv4 configuration for localhost/loopback connections.

del doi:<DOI>

Delete an existing CIPSO/IPv4 configuration with the given DOI value. If any LSM domain mappings are present which make use of this DOI they will also be deleted.

list [doi:<DOI>]

Display a list of all the CIPSO/IPv4 configurations or just the configuration matching the optionally specified DOI.

calipso

The CALIPSO/IPv6 (calipso) module controls the CALIPSO/IPv6 labeling engine in the kernel. This behaves in a very similar way to the CIPSO/IPv4 engine, however the protocol only specifies one tag-type (equivalent to CIPSO tag-type 1) and so the tag-type should not be specified. In addition there is no support for the "local" or "trans" configuration. The different commands and their syntax are listed below.

add pass doi:<DOI>

Add a new CALIPSO/IPv6 configuration without any level or category translations.

del doi:<DOI>

Delete an existing CALIPSO/IPv6 configuration with the given DOI value. If any LSM domain mappings are present which make use of this DOI they will also be deleted.

list [doi:<DOI>]

Display a list of all the CALIPSO/IPv6 configurations or just the configuration matching the optionally specified DOI.

## EXIT STATUS
Returns zero on success, errno values on failure.

## EXAMPLES
netlabelctl cipso add pass doi:16 tags:1

Add a CIPSO/IPv4 configuration with a DOI value of "16", using CIPSO tag "1" (the permissive bitmap tag). The CIPSO and LSM levels/categories are passed through the NetLabel subsystem without any translation.

netlabelctl cipso add trans doi:8 tags:1 levels:0=0,1=1 categories:0=1,1=0

Add a CIPSO/IPv4 configuration with a DOI value of "8", using CIPSO tag "1" (the permissive bitmap tag). The specified mapping converts local LSM levels "0" and "1" to CIPSO levels "0" and "1" respectively while local LSM categories "0" and "1" are mapped to CIPSO categories "1" and "0" respectively.

netlabelctl -p cipso list

Display all of the CIPSO/IPv4 configurations in a human readable format.

netlabelctl -p cipso list doi:16

Display specific information about the CIPSO/IPv4 DOI 16 configuration.

netlabelctl cipso del doi:8

Delete the CIPSO/IPv4 configuration assigned to DOI 8. In addition to removing the CIPSO/IPv4 configuration any domain mappings using this configuration will also be removed.

netlabelctl map add domain:lsm_domain protocol:cipso,8

Add a domain mapping so that all outgoing packets sent from the "lsm_domain" will be labeled according to the CIPSO/IPv4 protocol using DOI 8.

netlabelctl map add domain:lsm_domain address:192.168.1.0/24 protocol:cipso,8

Add a mapping so that all outgoing packets sent from the "lsm_domain" to the 192.168.1.0/24 network will be labeled according to the CIPSO/IPv4 protocol using DOI 8.

netlabelctl -p map list

Display all of the domain mappings in a human readable format.

netlabelctl del domain:lsm_domain

Delete the domain mapping for the "lsm_domain", packets sent from the "lsm_domain" will fallback to the default NetLabel mapping.

netlabelctl unlbl add interface:lo address:::1 label:foo

Add a static/fallback label to assign the "foo" security label to unlabeled packets entering the system over the "lo" (loopback) interface with an IPv6 source address of "::1" (localhost).

netlabelctl unlbl add default address:192.168.0.0/16 label:bar

Add a static/fallback label to assign the "bar" security label to unlabeled packets entering the system over any interface with an IPv4 source address in the 192.168.0.0/16 network.

## NOTES
The NetLabel subsystem is supported on Linux Kernels version 2.6.19 and later. The static, or fallback, labels are only supported on Linux Kernels version 2.6.25 and later. The domain mapping address selectors are only supported on Linux Kernels 2.6.28 and later and CALIPSO/RFC5570 is only supported on Linux Kernels 4.8.0 and later.

The NetLabel project site, with more information including the source code repository, can be found at https://github.com/netlabel. Please report any bugs at the project site or directly to the author.

## AUTHOR
Paul Moore <paul@paul-moore.com>

## SEE ALSO
netlabel-config(8)


netplan-apply

package: netplan

title: netplan-apply(8)

text:
# netplan-apply(8)

## NAME
netplan-apply - apply configuration from netplan YAML files to a running system

## SYNOPSIS
netplan [--debug] apply -h | --help

netplan [--debug] apply

## DESCRIPTION
netplan apply applies the current netplan configuration to a running system.

The process works as follows:

1.

The backend configuration is generated from netplan YAML files.

2.

The appropriate backends (systemd-networkd(8) or NetworkManager(8)) are invoked to bring up configured interfaces.

3.

netplan apply iterates through interfaces that are still down, unbinding them from their drivers, and rebinding them. This gives udev(7) renaming rules the opportunity to run.

4.

If any devices have been rebound, the appropriate backends are re-invoked in case more matches can be done.

For information about the generation step, see netplan-generate(8). For details of the configuration file format, see netplan(5).

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

## KNOWN ISSUES
netplan apply will not remove virtual devices such as bridges and bonds that have been created, even if they are no longer described in the netplan configuration. That is due to the fact that netplan operates statelessly and is not aware of the previously defined virtual devices.

This can be resolved by manually removing the virtual device (for example ip link delete dev bond0) and then running netplan apply, by rebooting, or by creating a temporary backup of the YAML state in /etc/netplan before modifying the configuration and passing this state to netplan (e.g. mkdir -p /tmp/netplan_state_backup/etc && cp -r /etc/netplan /tmp/netplan_state_backup/etc/ then running netplan apply --state /tmp/netplan_state_backup)

## SEE ALSO
netplan(5), netplan-generate(8), netplan-try(8), udev(7), systemd-networkd.service(8), NetworkManager(8)

## AUTHORS
Daniel Axtens (<daniel.axtens@canonical.com>).


netplan-dbus

title: netplan-dbus(8)

text:
# netplan-dbus(8)

## NAME
netplan-dbus - daemon to access netplan's functionality via a DBus API

## SYNOPSIS
netplan-dbus

## DESCRIPTION
netplan-dbus is a DBus daemon, providing io.netplan.Netplan on the system bus. The /io/netplan/Netplan object provides an io.netplan.Netplan interface, offering the following methods:

•

Apply() -> b: calls netplan apply and returns a success or failure status.

•

Generate() -> b: calls netplan generate and returns a success or failure status.

•

Info() -> a(sv): returns a dict "Features -> as", containing an array of all available feature flags.

•

Config() -> o: prepares a new config object as /io/netplan/Netplan/config/<ID>, by copying the current state from /{etc,run,lib}/netplan/*.yaml

The /io/netplan/Netplan/config/<ID> objects provide a io.netplan.Netplan.Config interface, offering the following methods:

•

Get() -> s: calls netplan get --root-dir=/run/netplan/config-ID all and returns the merged YAML config of the the given config object's state

•

Set(s:CONFIG_DELTA, s:ORIGIN_HINT) -> b: calls netplan set --root-dir=/run/netplan/config-ID --origin-hint=ORIGIN_HINT CONFIG_DELTA

CONFIG_DELTA can be something like: network.ethernets.eth0.dhcp4=true and ORIGIN_HINT can be something like: 70-snapd (it will then write the config to 70-snapd.yaml). Once Set() is called on a config object, all other current and future config objects are being invalidated and cannot Set() or Try()/Apply() anymore, due to this pending dirty state. After the dirty config object is rejected via Cancel(), the other config objects are valid again. If the dirty config object is accepted via Apply(), newly created config objects will be valid, while the older states will stay invalid.

•

Try(u:TIMEOUT_SEC) -> b: replaces the main netplan configuration with this config object's state and calls netplan try --timeout=TIMEOUT_SEC

•

Cancel() -> b: rejects a currently running Try() attempt on this config object and/or discards the config object

•

Apply() -> b: replaces the main netplan configuration with this config object's state and calls netplan apply

For information about the Apply()/Try()/Get()/Set() functionality, see netplan-apply(8)/netplan-try(8)/netplan-get(8)/netplan-set(8) accordingly. For details of the configuration file format, see netplan(5).

## SEE ALSO
netplan(5), netplan-apply(8), netplan-try(8), netplan-get(8), netplan-set(8)

## AUTHORS
Lukas Märdian (<lukas.maerdian@canonical.com>).


netplan-generate

title: netplan-generate(8)

text:
# netplan-generate(8)

## NAME
netplan-generate - generate backend configuration from netplan YAML files

## SYNOPSIS
netplan [--debug] generate -h | --help

netplan [--debug] generate [--root-dir ROOT_DIR] [--mapping MAPPING]

## DESCRIPTION
netplan generate converts netplan YAML into configuration files understood by the backends (systemd-networkd(8) or NetworkManager(8)). It does not apply the generated configuration.

You will not normally need to run this directly as it is run by netplan apply, netplan try, or at boot.

Only if executed during the systemd initializing phase (i.e. "Early bootup, before basic.target is reached"), will it attempt to start/apply the newly created service units. Requires feature: generate-just-in-time

For details of the configuration file format, see netplan(5).

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--root-dir ROOT_DIR

Instead of looking in /{lib,etc,run}/netplan, look in /ROOT_DIR/{lib,etc,run}/netplan

--mapping MAPPING

Instead of generating output files, parse the configuration files and print some internal information about the device specified in MAPPING.

## HANDLING MULTIPLE FILES
There are 3 locations that netplan generate considers:

•

/lib/netplan/*.yaml

•

/etc/netplan/*.yaml

•

/run/netplan/*.yaml

If there are multiple files with exactly the same name, then only one will be read. A file in /run/netplan will shadow - completely replace - a file with the same name in /etc/netplan. A file in /etc/netplan will itself shadow a file in /lib/netplan.

Or in other words, /run/netplan is top priority, then /etc/netplan, with /lib/netplan having the lowest priority.

If there are files with different names, then they are considered in lexicographical order - regardless of the directory they are in. Later files add to or override earlier files. For example, /run/netplan/10-foo.yaml would be updated by /lib/netplan/20-abc.yaml.

If you have two files with the same key/setting, the following rules apply:

•

If the values are YAML boolean or scalar values (numbers and strings) the old value is overwritten by the new value.

•

If the values are sequences, the sequences are concatenated - the new values are appended to the old list.

•

If the values are mappings, netplan will examine the elements of the mappings in turn using these rules.

## SEE ALSO
netplan(5), netplan-apply(8), netplan-try(8), systemd-networkd(8), NetworkManager(8)

## AUTHORS
Daniel Axtens (<daniel.axtens@canonical.com>).


netplan-get

title: netplan-get(8)

text:
# netplan-get(8)

## NAME
netplan-get - read merged netplan YAML configuration

## SYNOPSIS
netplan [--debug] get -h | --help

netplan [--debug] get [--root-dir=ROOT_DIR] [key]

## DESCRIPTION
netplan get [key] reads all YAML files from /{etc,lib,run}/netplan/*.yaml and returns a merged view of the current configuration

You can specify all as a key (the default) to get the full YAML tree or extract a subtree by specifying a nested key like: [network.]ethernets.eth0.

For details of the configuration file format, see netplan(5).

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--root-dir

Read YAML files from this root instead of /

## SEE ALSO
netplan(5), netplan-set(8), netplan-dbus(8)

## AUTHORS
Lukas Märdian (lukas.maerdian@canonical.com).


netplan-set

title: netplan-set(8)

text:
# netplan-set(8)

## NAME
netplan-set - write netplan YAML configuration snippets to file

## SYNOPSIS
netplan [--debug] set -h | --help

netplan [--debug] set [--root-dir=ROOT_DIR] [--origin-hint=ORIGIN_HINT] [key=value]

## DESCRIPTION
netplan set [key=value] writes a given key/value pair or YAML subtree into a YAML file in /etc/netplan/ and validates its format.

You can specify a single value as: "[network.]ethernets.eth0.addresses=[1.2.3.4/24, 5.6.7.8/24]" or a full subtree as: "[network.]ethernets.eth0={dhcp4: true, dhcp6: true}".

For details of the configuration file format, see netplan(5).

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--root-dir

Write YAML files into this root instead of /

--origin-hint

Specify a name for the config file, e.g.: 70-netplan-set => /etc/netplan/70-netplan-set.yaml

## SEE ALSO
netplan(5), netplan-get(8), netplan-dbus(8)

## AUTHORS
Lukas Märdian (lukas.maerdian@canonical.com).


netplan-try

title: netplan-try(8)

text:
# netplan-try(8)

## NAME
netplan-try - try a configuration, optionally rolling it back

## SYNOPSIS
netplan [--debug] try -h | --help

netplan [--debug] try [--config-file CONFIG_FILE] [--timeout TIMEOUT]

## DESCRIPTION
netplan try takes a netplan(5) configuration, applies it, and automatically rolls it back if the user does not confirm the configuration within a time limit.

A configuration can be confirmed or rejected interactively or by sending the SIGUSR1 or SIGINT signals.

This may be especially useful on remote systems, to prevent an administrator being permanently locked out of systems in the case of a network configuration error.

## OPTIONS
-h, --help

Print basic help.

--debug

Print debugging output during the process.

--config-file CONFIG_FILE

In addition to the usual configuration, apply CONFIG_FILE. It must be a YAML file in the netplan(5) format.

--timeout TIMEOUT

Wait for TIMEOUT seconds before reverting. Defaults to 120 seconds. Note that some network configurations (such as STP) may take over a minute to settle.

## KNOWN ISSUES
netplan try uses similar procedures to netplan apply, so some of the same caveats apply around virtual devices.

There are also some known bugs: if netplan try times out or is cancelled, make sure to verify if the network configuration has in fact been reverted.

As with netplan apply, a reboot should fix any issues. However, be sure to verify that the config on disk is in the state you expect before rebooting!

## SEE ALSO
netplan(5), netplan-generate(8), netplan-apply(8)

## AUTHORS
Daniel Axtens (<daniel.axtens@canonical.com>).


nfacct

package: nfacct

title: nfacct(8)

text:
# nfacct(8)

## NAME
nfacct - command line tool to create/retrieve/delete accounting objects

## SYNOPSIS
nfacct command [name] [options]

## DESCRIPTION
nfacct is the command line tool that allows to manipulate the Netfilter's extended accounting infrastructure.

## COMMANDS
These commands specify the action that nfacct performs. Only one of them can be specified at any given time.

list

List the existing accounting object in table.

restore

Restore accounting object table by reading from stdin. Input format is the one used as output by the list command.

add

Add new accounting object.

delete

Delete accounting object.

get

Get existing accounting object.

flush

Delete all unused accounting objects.

version

Displays the version information.

help

Displays the help message.

## OPTIONS
This tool also allows a couple of options with the get and list commands that are:

reset

That atomically obtains and resets the counters.

xml

That displays the output in XML format. json That displays the output in JSON format.

## SEE ALSO
iptables(8)

## BUGS
Please, report them to netfilter-devel@vger.kernel.org or file a bug in Netfilter's bugzilla (https://bugzilla.netfilter.org).

## AUTHORS
Pablo Neira Ayuso wrote and maintains the nfacct tool.

Man page written by Pablo Neira Ayuso <pablo@netfilter.org>.


blkmapd

package: nfs-clients

title: blkmapd(8)

summary: pNFS block layout mapping daemon

text:
# blkmapd(8)

## NAME
blkmapd - pNFS block layout mapping daemon

## SYNOPSIS
blkmapd [-h] [-d] [-f]

## DESCRIPTION
The blkmapd daemon performs device discovery and mapping for the parallel NFS (pNFS) block layout client [RFC5663].

The pNFS block layout protocol builds a complex storage hierarchy from a set of simple volumes. These simple volumes are addressed by content, using a signature on the volume to uniquely name each one. The daemon locates a volume by examining each block device in the system for the given signature.

The topology typically consists of a hierarchy of volumes built by striping, slicing, and concatenating the simple volumes. The blkmapd daemon uses the device-mapper driver to construct logical devices that reflect the server topology, and passes these devices to the kernel for use by the pNFS block layout client.

## OPTIONS
-h

Display usage message.

-d

Performs device discovery only then exits.

-f

Runs blkmapd in the foreground and sends output to stderr (as opposed to syslogd)

## CONFIGURATION FILE
The blkmapd daemon recognizes the following value from the [general] section of the /etc/nfs.conf configuration file:

pipefs-directory

Tells blkmapd where to look for the rpc_pipefs filesystem. The default value is /var/lib/nfs/rpc_pipefs.

## SEE ALSO
nfs(5), dmsetup(8), nfs.conf(5)

RFC 5661 for the NFS version 4.1 specification.

RFC 5663 for the pNFS block layout specification.

## AUTHORS
Haiying Tang <Tang_Haiying@emc.com>

Jim Rees <rees@umich.edu>


gssd

title: gssd(8)

summary: RPCSEC_GSS daemon

text:
# gssd(8)

## NAME
rpc.gssd - RPCSEC_GSS daemon

## SYNOPSIS
rpc.gssd [-DfMnlvrHC] [-k keytab] [-p pipefsdir] [-d ccachedir] [-t timeout] [-T timeout] [-U timeout] [-R realm]

## INTRODUCTION
The RPCSEC_GSS protocol, defined in RFC 5403, is used to provide strong security for RPC-based protocols such as NFS.

Before exchanging RPC requests using RPCSEC_GSS, an RPC client must establish a GSS security context. A security context is shared state on each end of a network transport that enables GSS-API security services.

Security contexts are established using security credentials. A credential grants temporary access to a secure network service, much as a railway ticket grants temporary access to use a rail service.

A user typically obtains a credential by providing a password to the kinit(1) command, or via a PAM library at login time. A credential acquired with a user principal is known as a user credential (see kerberos(1) for more on principals).

Certain operations require a credential that represents no particular user or represents the host itself. This kind of credential is called a machine credential.

A host establishes its machine credential using a service principal whose encrypted password is stored in a local file known as a keytab. A machine credential remains effective without user intervention as long as the host can renew it.

Once obtained, credentials are typically stored in local temporary files with well-known pathnames.

## DESCRIPTION
To establish GSS security contexts using these credential files, the Linux kernel RPC client depends on a userspace daemon called rpc.gssd. The rpc.gssd daemon uses the rpc_pipefs filesystem to communicate with the kernel.

### User Credentials
When a user authenticates using a command such as kinit(1), the resulting credential is stored in a file with a well-known name constructed using the user's UID.

To interact with an NFS server on behalf of a particular Kerberos-authenticated user, the Linux kernel RPC client requests that rpc.gssd initialize a security context with the credential in that user's credential file.

Typically, credential files are placed in /tmp. However, rpc.gssd can search for credential files in more than one directory. See the description of the -d option for details.

### Machine Credentials
rpc.gssd searches the default keytab, /etc/krb5.keytab, in the following order for a principal and password to use when establishing the machine credential. For the search, rpc.gssd replaces <hostname> and <REALM> with the local system's hostname and Kerberos realm.

<HOSTNAME>$@<REALM>

root/<hostname>@<REALM>

nfs/<hostname>@<REALM>

host/<hostname>@<REALM>

root/<anyname>@<REALM>

nfs/<anyname>@<REALM>

host/<anyname>@<REALM>

rpc.gssd selects one of the <anyname> entries if it does not find a service principal matching the local hostname, e.g. if DHCP assigns the local hostname dynamically. The <anyname> facility enables the use of the same keytab on multiple systems. However, using the same service principal to establish a machine credential on multiple hosts can create unwanted security exposures and is therefore not recommended.

Note that <HOSTNAME>$@<REALM> is a user principal that enables Kerberized NFS when the local system is joined to an Active Directory domain using Samba. The keytab provides the password for this principal.

You can specify a different keytab by using the -k option if /etc/krb5.keytab does not exist or does not provide one of these principals.

### Credentials for UID 0
UID 0 is a special case. By default rpc.gssd uses the system's machine credentials for UID 0 accesses that require GSS authentication. This limits the privileges of the root user when accessing network resources that require authentication.

Specify the -n option when starting rpc.gssd if you'd like to force the root user to obtain a user credential rather than use the local system's machine credential.

When -n is specified, the kernel continues to request a GSS context established with a machine credential for NFSv4 operations, such as SETCLIENTID or RENEW, that manage state. If rpc.gssd cannot obtain a machine credential (say, the local system has no keytab), NFSv4 operations that require machine credentials will fail.

### Encryption types
A realm administrator can choose to add keys encoded in a number of different encryption types to the local system's keytab. For instance, a host/ principal might have keys for the aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, and arcfour-hmac encryption types. This permits rpc.gssd to choose an appropriate encryption type that the target NFS server supports.

These encryption types are stronger than legacy single-DES encryption types. To interoperate in environments where servers support only weak encryption types, you can restrict your client to use only single-DES encryption types by specifying the -l option when starting rpc.gssd.

## OPTIONS
-D

The server name passed to GSSAPI for authentication is normally the name exactly as requested. e.g. for NFS it is the server name in the "servername:/path" mount request. Only if this servername appears to be an IP address (IPv4 or IPv6) or an unqualified name (no dots) will a reverse DNS lookup will be performed to get the canoncial server name. If -D is present, a reverse DNS lookup will always be used, even if the server name looks like a canonical name. So it is needed if partially qualified, or non canonical names are regularly used.

Using -D can introduce a security vulnerability, so it is recommended that -D not be used, and that canonical names always be used when requesting services.

-f

Runs rpc.gssd in the foreground and sends output to stderr (as opposed to syslogd)

-n

When specified, UID 0 is forced to obtain user credentials which are used instead of the local system's machine credentials.

-k keytab

Tells rpc.gssd to use the keys found in keytab to obtain machine credentials. The default value is /etc/krb5.keytab.

-l

When specified, restricts rpc.gssd to sessions to weak encryption types such as des-cbc-crc. This option is available only when the local system's Kerberos library supports settable encryption types.

-p path

Tells rpc.gssd where to look for the rpc_pipefs filesystem. The default value is /var/lib/nfs/rpc_pipefs.

-d search-path

This option specifies a colon separated list of directories that rpc.gssd searches for credential files. The default value is /tmp:/run/user/%U. The literal sequence "%U" can be specified to substitue the UID of the user for whom credentials are being searched.

-M

By default, machine credentials are stored in files in the first directory in the credential directory search path (see the -d option). When -M is set, rpc.gssd stores machine credentials in memory instead.

-v

Increases the verbosity of the output (can be specified multiple times).

-r

If the RPCSEC_GSS library supports setting debug level, increases the verbosity of the output (can be specified multiple times).

-R realm

Kerberos tickets from this realm will be preferred when scanning available credentials cache files to be used to create a context. By default, the default realm, as configured in the Kerberos configuration file, is preferred.

-t timeout

Timeout, in seconds, for kernel GSS contexts. This option allows you to force new kernel contexts to be negotiated after timeout seconds, which allows changing Kerberos tickets and identities frequently. The default is no explicit timeout, which means the kernel context will live the lifetime of the Kerberos service ticket used in its creation.

-T timeout

Timeout, in seconds, to create an RPC connection with a server while establishing an authenticated gss context for a user. The default timeout is set to 5 seconds. If you get messages like "WARNING: can't create tcp rpc_clnt to server %servername% for user with uid %uid%: RPC: Remote system error - Connection timed out", you should consider an increase of this timeout.

-U timeout

Timeout, in seconds, for upcall threads. Threads executing longer than timeout seconds will cause an error message to be logged. The default timeout is 30 seconds. The minimum is 5 seconds. The maximum is 600 seconds.

-C

In addition to logging an error message for threads that have timed out, the thread will be canceled and an error of -ETIMEDOUT will be reported to the kernel.

-H

Avoids setting $HOME to "/". This allows rpc.gssd to read per user k5identity files versus trying to read /.k5identity for each user. If -H is not set, rpc.gssd will use the first match found in /var/kerberos/krb5/user/$EUID/client.keytab and will not use a principal based on host and/or service parameters listed in $HOME/.k5identity.

## CONFIGURATION FILE
Many of the options that can be set on the command line can also be controlled through values set in the [gssd] section of the /etc/nfs.conf configuration file. Values recognized include:

verbosity

Value which is equivalent to the number of -v.

rpc-verbosity

Value which is equivalent to the number of -r.

use-memcache

A Boolean flag equivalent to -M.

use-machine-creds

A Boolean flag. Setting to false is equivalent to giving the -n flag.

avoid-dns

Setting to false is equivalent to providing the -D flag.

limit-to-legacy-enctypes

Equivalent to -l.

context-timeout

Equivalent to -t.

rpc-timeout

Equivalent to -T.

keytab-file

Equivalent to -k.

cred-cache-directory

Equivalent to -d.

preferred-realm

Equivalent to -R.

upcall-timeout

Equivalent to -U.

cancel-timed-out-upcalls

Setting to true is equivalent to providing the -C flag.

set-home

Setting to false is equivalent to providing the -H flag.

In addtion, the following value is recognized from the [general] section:

pipefs-directory

Equivalent to -p.

## SEE ALSO
rpc.svcgssd(8), kerberos(1), kinit(1), krb5.conf(5)

## AUTHORS
Dug Song <dugsong@umich.edu>

Andy Adamson <andros@umich.edu>

Marius Aamodt Eriksen <marius@umich.edu>

J. Bruce Fields <bfields@umich.edu>


nfsconf

title: nfsconf(8)

text:
# nfsconf(8)

## NAME
nfsconf - Query various NFS configuration settings

## SYNOPSIS
nfsconf --dump [-v|--verbose] [-f|--file infile.conf] [outfile]

nfsconf --entry [--arg subsection] section tag

nfsconf --get [-v|--verbose] [-f|--file infile.conf] [-a|--arg subsection] section tag

nfsconf --isset [-v|--verbose] [-f|--file infile.conf] [-a|--arg subsection] section tag

nfsconf --set [-v|--verbose] [-m|--modified Modified by text] [-f|--file infile.conf] [-a|--arg subsection] section tag value

nfsconf --unset [-v|--verbose] [-f|--file infile.conf] [-a|--arg subsection] section tag

## DESCRIPTION
The nfsconf command can be used to test for and retrieve configuration settings from a range of nfs-utils configuration files.

### Modes
The following modes are available:

-d, --dump

Output an alphabetically sorted dump of the current configuration in conf file format. Accepts an optional filename in which to write the output.

-e, --entry

retrieve the config entry rather than its current expanded value

-i, --isset

Test if a specific tag has a value set.

-g, --get

Output the current value of the specified tag.

-s, --set

Update or Add a tag and value to the config file in a specified section, creating the tag, section, and file if necessary. If the section is defined as '#' then a comment is appended to the file. If a comment is set with a tag name then any exiting tagged comment with a matching name is replaced.

-u, --unset

Remove the specified tag and its value from the config file.

## OPTIONS

### Options valid in all modes
-v, --verbose

Increase verbosity and print debugging information.

-f, --file infile

Select a different config file to operate upon, default is /etc/nfs.conf

### Options only valid in --entry and --get and --isset modes.
-a, --arg subsection

Select a specific sub-section

### Options only valid in --set mode.
-m, --modified "Modified by nfsconf" Set the text on the Modified date comment in the file. Set to empty to remove.

## EXIT STATUS

### --isset mode
In this mode the command will return success (0) if the selected tag has a value, any other exit code indicates the value is not set, or some other error has occurred.

### all other modes
Success is indicated by an exit status of zero, any other status indicates an error. Error messages are output on stderr, and increasing verbosity will give more detailed explanations if any are available.

## EXAMPLES
nfsconf -v --dump --file /tmp/testconf.conf sorted.conf

Check a new config file for syntax errors and output a sorted version for ease of comparison with existing settings.

if ! nfsconf --isset gssd preferred-realm ; then echo 'No preferred realm configured for gss'; fi

The tool allows for easy testing of configuration values from shell scripts, here we test if a specific value has been set.

nfsconf --file /etc/nfsmount.conf --get --arg /home MountPoint background

Show default value for background option for NFS mounts of the /home path.

nfsconf --file /etc/nfs.conf --set nfsd debug 1

Enable debugging in nfsd

## FILES
/etc/nfs.conf

## SEE ALSO
nfsd(8), exportfs(8), idmapd(8), statd(8)

## AUTHOR
Justin Mitchell <jumitche@redhat.com>


nfsidmap

title: nfsidmap(8)

summary: The NFS idmapper upcall program

text:
# nfsidmap(8)

## NAME
nfsidmap - The NFS idmapper upcall program

## SYNOPSIS
nfsidmap [-v] [-t timeout] key desc

nfsidmap [-v] [-c]

nfsidmap [-v] [-u|-g|-r user]

nfsidmap -d

nfsidmap -l

nfsidmap -h

## DESCRIPTION
The NFSv4 protocol represents the local system's UID and GID values on the wire as strings of the form user@domain. The process of translating from UID to string and string to UID is referred to as "ID mapping."

The system derives the user part of the string by performing a password or group lookup. The lookup mechanism is configured in /etc/idmapd.conf.

By default, the domain part of the string is the system's DNS domain name. It can also be specified in /etc/idmapd.conf if the system is multi-homed, or if the system's DNS domain name does not match the name of the system's Kerberos realm.

When the domain is not specified in /etc/idmapd.conf the local DNS server will be queried for the _nfsv4idmapdomain text record. If the record exists that will be used as the domain. When the record does not exist, the domain part of the DNS domain will used.

The /sbin/nfsidmap program performs translations on behalf of the kernel. The kernel uses the request-key mechanism to perform an upcall. /sbin/nfsidmap is invoked by /sbin/request-key, performs the translation, and initializes a key with the resulting information. The kernel then caches the translation results in the key.

nfsidmap can also clear cached ID map results in the kernel, or revoke one particular key. An incorrect cached key can result in file and directory ownership reverting to "nobody" on NFSv4 mount points.

In addition, the -d and -l options are available to help diagnose misconfigurations. They have no effect on the keyring containing ID mapping results.

## OPTIONS
-c

Clear the keyring of all the keys.

-d

Display the system's effective NFSv4 domain name on stdout.

-g user

Revoke the gid key of the given user.

-h

Display usage message.

-l

Display on stdout all keys currently in the keyring used to cache ID mapping results. These keys are visible only to the superuser.

-r user

Revoke both the uid and gid key of the given user.

-t timeout

Set the expiration timer, in seconds, on the key. The default is 600 seconds (10 mins).

-u user

Revoke the uid key of the given user.

-v

Increases the verbosity of the output to syslog (can be specified multiple times).

## CONFIGURING
The file /etc/request-key.conf will need to be modified so /sbin/request-key can properly direct the upcall. The following line should be added before a call to keyctl negate:

create id_resolver * * /sbin/nfsidmap -t 600 %k %d

This will direct all id_resolver requests to the program /sbin/nfsidmap. The -t 600 defines how many seconds into the future the key will expire. This is an optional parameter for /sbin/nfsidmap and will default to 600 seconds when not specified.

The idmapper system uses four key descriptions:

uid: Find the UID for the given user

gid: Find the GID for the given group

user: Find the user name for the given UID

group: Find the group name for the given GID

You can choose to handle any of these individually, rather than using the generic upcall program. If you would like to use your own program for a uid lookup then you would edit your request-key.conf so it looks similar to this:

create id_resolver uid:* * /some/other/program %k %d

create id_resolver * * /sbin/nfsidmap %k %d

Notice that the new line was added above the line for the generic program. request-key will find the first matching line and run the corresponding program. In this case, /some/other/program will handle all uid lookups, and /sbin/nfsidmap will handle gid, user, and group lookups.

## FILES
/etc/idmapd.conf

ID mapping configuration file

/etc/request-key.conf

Request key configuration file

## SEE ALSO
idmapd.conf(5), request-key(8)

## AUTHOR
Bryan Schumaker, <bjschuma@netapp.com>


sm-notify

title: sm-notify(8)

summary: send reboot notifications to NFS peers

text:
# sm-notify(8)

## NAME
sm-notify - send reboot notifications to NFS peers

## SYNOPSIS
/usr/sbin/sm-notify [-dfn] [-m minutes] [-v name] [-p notify-port] [-P path]

## DESCRIPTION
File locks are not part of persistent file system state. Lock state is thus lost when a host reboots.

Network file systems must also detect when lock state is lost because a remote host has rebooted. After an NFS client reboots, an NFS server must release all file locks held by applications that were running on that client. After a server reboots, a client must remind the server of file locks held by applications running on that client.

For NFS version 2 and version 3, the Network Status Monitor protocol (or NSM for short) is used to notify NFS peers of reboots. On Linux, two separate user-space components constitute the NSM service:

sm-notify

A helper program that notifies NFS peers after the local system reboots

rpc.statd

A daemon that listens for reboot notifications from other hosts, and manages the list of hosts to be notified when the local system reboots

The local NFS lock manager alerts its local rpc.statd of each remote peer that should be monitored. When the local system reboots, the sm-notify command notifies the NSM service on monitored peers of the reboot. When a remote reboots, that peer notifies the local rpc.statd, which in turn passes the reboot notification back to the local NFS lock manager.

## NSM OPERATION IN DETAIL
The first file locking interaction between an NFS client and server causes the NFS lock managers on both peers to contact their local NSM service to store information about the opposite peer. On Linux, the local lock manager contacts rpc.statd.

rpc.statd records information about each monitored NFS peer on persistent storage. This information describes how to contact a remote peer in case the local system reboots, how to recognize which monitored peer is reporting a reboot, and how to notify the local lock manager when a monitored peer indicates it has rebooted.

An NFS client sends a hostname, known as the client's caller_name, in each file lock request. An NFS server can use this hostname to send asynchronous GRANT calls to a client, or to notify the client it has rebooted.

The Linux NFS server can provide the client's caller_name or the client's network address to rpc.statd. For the purposes of the NSM protocol, this name or address is known as the monitored peer's mon_name. In addition, the local lock manager tells rpc.statd what it thinks its own hostname is. For the purposes of the NSM protocol, this hostname is known as my_name.

There is no equivalent interaction between an NFS server and a client to inform the client of the server's caller_name. Therefore NFS clients do not actually know what mon_name an NFS server might use in an SM_NOTIFY request. The Linux NFS client records the server's hostname used on the mount command to identify rebooting NFS servers.

### Reboot notification
When the local system reboots, the sm-notify command reads the list of monitored peers from persistent storage and sends an SM_NOTIFY request to the NSM service on each listed remote peer. It uses the mon_name string as the destination. To identify which host has rebooted, the sm-notify command normally sends my_name string recorded when that remote was monitored. The remote rpc.statd matches incoming SM_NOTIFY requests using this string, or the caller's network address, to one or more peers on its own monitor list.

If rpc.statd does not find a peer on its monitor list that matches an incoming SM_NOTIFY request, the notification is not forwarded to the local lock manager. In addition, each peer has its own NSM state number, a 32-bit integer that is bumped after each reboot by the sm-notify command. rpc.statd uses this number to distinguish between actual reboots and replayed notifications.

Part of NFS lock recovery is rediscovering which peers need to be monitored again. The sm-notify command clears the monitor list on persistent storage after each reboot.

## OPTIONS
-d

Keeps sm-notify attached to its controlling terminal and running in the foreground so that notification progress may be monitored directly.

-f

Send notifications even if sm-notify has already run since the last system reboot.

-m retry-time

Specifies the length of time, in minutes, to continue retrying notifications to unresponsive hosts. If this option is not specified, sm-notify attempts to send notifications for 15 minutes. Specifying a value of 0 causes sm-notify to continue sending notifications to unresponsive peers until it is manually killed.

Notifications are retried if sending fails, the remote does not respond, the remote's NSM service is not registered, or if there is a DNS failure which prevents the remote's mon_name from being resolved to an address.

Hosts are not removed from the notification list until a valid reply has been received. However, the SM_NOTIFY procedure has a void result. There is no way for sm-notify to tell if the remote recognized the sender and has started appropriate lock recovery.

-n

Prevents sm-notify from updating the local system's NSM state number.

-p port

Specifies the source port number sm-notify should use when sending reboot notifications. If this option is not specified, a randomly chosen ephemeral port is used.

This option can be used to traverse a firewall between client and server.

-P, --state-directory-path pathname

Specifies the pathname of the parent directory where NSM state information resides. If this option is not specified, sm-notify uses /var/lib/nfs by default.

After starting, sm-notify attempts to set its effective UID and GID to the owner and group of the subdirectory sm of this directory. After changing the effective ids, sm-notify only needs to access files in sm and sm.bak within the state-directory-path.

-v ipaddr | hostname

Specifies the network address from which to send reboot notifications, and the mon_name argument to use when sending SM_NOTIFY requests. If this option is not specified, sm-notify uses a wildcard address as the transport bind address, and uses the my_name recorded when the remote was monitored as the mon_name argument when sending SM_NOTIFY requests.

The ipaddr form can be expressed as either an IPv4 or an IPv6 presentation address. If the ipaddr form is used, the sm-notify command converts this address to a hostname for use as the mon_name argument when sending SM_NOTIFY requests.

This option can be useful in multi-homed configurations where the remote requires notification from a specific network address.

## CONFIGURATION FILE
Many of the options that can be set on the command line can also be controlled through values set in the [sm-notify] or, in one case, the [statd] section of the /etc/nfs.conf configuration file.

Values recognized in the [sm-notify] section include: retry-time, outgoing-port, and outgoing-addr. These have the same effect as the command line options m, p, and v respectively.

An additional value recognized in the [sm-notify] section is lift-grace. By default, sm-notify will lift lockd's grace period early if it has no hosts to notify. Some high availability configurations will run one sm-notify per floating IP address. In these configurations, lifting the grace period early may prevent clients from reclaiming locks. Setting lift-grace to n will prevent sm-notify from ending the grace period early. lift-grace has no corresponding command line option.

The value recognized in the [statd] section is state-directory-path.

## SECURITY
The sm-notify command must be started as root to acquire privileges needed to access the state information database. It drops root privileges as soon as it starts up to reduce the risk of a privilege escalation attack.

During normal operation, the effective user ID it chooses is the owner of the state directory. This allows it to continue to access files in that directory after it has dropped its root privileges. To control which user ID rpc.statd chooses, simply use chown(1) to set the owner of the state directory.

## ADDITIONAL NOTES
Lock recovery after a reboot is critical to maintaining data integrity and preventing unnecessary application hangs.

To help rpc.statd match SM_NOTIFY requests to NLM requests, a number of best practices should be observed, including:

The UTS nodename of your systems should match the DNS names that NFS peers use to contact them

The UTS nodenames of your systems should always be fully qualified domain names

The forward and reverse DNS mapping of the UTS nodenames should be consistent

The hostname the client uses to mount the server should match the server's mon_name in SM_NOTIFY requests it sends

Unmounting an NFS file system does not necessarily stop either the NFS client or server from monitoring each other. Both may continue monitoring each other for a time in case subsequent NFS traffic between the two results in fresh mounts and additional file locking.

On Linux, if the lockd kernel module is unloaded during normal operation, all remote NFS peers are unmonitored. This can happen on an NFS client, for example, if an automounter removes all NFS mount points due to inactivity.

### IPv6 and TI-RPC support
TI-RPC is a pre-requisite for supporting NFS on IPv6. If TI-RPC support is built into the sm-notify command ,it will choose an appropriate IPv4 or IPv6 transport based on the network address returned by DNS for each remote peer. It should be fully compatible with remote systems that do not support TI-RPC or IPv6.

Currently, the sm-notify command supports sending notification only via datagram transport protocols.

## FILES
/var/lib/nfs/sm

directory containing monitor list

/var/lib/nfs/sm.bak

directory containing notify list

/var/lib/nfs/state

NSM state number for this host

/proc/sys/fs/nfs/nsm_local_state

kernel's copy of the NSM state number

## SEE ALSO
rpc.statd(8), nfs(5), uname(2), hostname(7)

RFC 1094 - "NFS: Network File System Protocol Specification"

RFC 1813 - "NFS Version 3 Protocol Specification"

OpenGroup Protocols for Interworking: XNFS, Version 3W - Chapter 11

## AUTHORS
Olaf Kirch <okir@suse.de>

Chuck Lever <chuck.lever@oracle.com>


statd

title: statd(8)

summary: NSM service daemon

text:
# statd(8)

## NAME
rpc.statd - NSM service daemon

## SYNOPSIS
rpc.statd [-dh?FLNvV] [-H prog] [-n my-name] [-o outgoing-port] [-p listener-port] [-P path] [--nlm-port port] [--nlm-udp-port port]

## DESCRIPTION
File locks are not part of persistent file system state. Lock state is thus lost when a host reboots.

Network file systems must also detect when lock state is lost because a remote host has rebooted. After an NFS client reboots, an NFS server must release all file locks held by applications that were running on that client. After a server reboots, a client must remind the server of file locks held by applications running on that client.

For NFS version 2 [RFC1094] and NFS version 3 [RFC1813], the Network Status Monitor protocol (or NSM for short) is used to notify NFS peers of reboots. On Linux, two separate user-space components constitute the NSM service:

rpc.statd

A daemon that listens for reboot notifications from other hosts, and manages the list of hosts to be notified when the local system reboots

sm-notify

A helper program that notifies NFS peers after the local system reboots

The local NFS lock manager alerts its local rpc.statd of each remote peer that should be monitored. When the local system reboots, the sm-notify command notifies the NSM service on monitored peers of the reboot. When a remote reboots, that peer notifies the local rpc.statd, which in turn passes the reboot notification back to the local NFS lock manager.

## NSM OPERATION IN DETAIL
The first file locking interaction between an NFS client and server causes the NFS lock managers on both peers to contact their local NSM service to store information about the opposite peer. On Linux, the local lock manager contacts rpc.statd.

rpc.statd records information about each monitored NFS peer on persistent storage. This information describes how to contact a remote peer in case the local system reboots, how to recognize which monitored peer is reporting a reboot, and how to notify the local lock manager when a monitored peer indicates it has rebooted.

An NFS client sends a hostname, known as the client's caller_name, in each file lock request. An NFS server can use this hostname to send asynchronous GRANT calls to a client, or to notify the client it has rebooted.

The Linux NFS server can provide the client's caller_name or the client's network address to rpc.statd. For the purposes of the NSM protocol, this name or address is known as the monitored peer's mon_name. In addition, the local lock manager tells rpc.statd what it thinks its own hostname is. For the purposes of the NSM protocol, this hostname is known as my_name.

There is no equivalent interaction between an NFS server and a client to inform the client of the server's caller_name. Therefore NFS clients do not actually know what mon_name an NFS server might use in an SM_NOTIFY request. The Linux NFS client uses the server hostname from the mount command to identify rebooting NFS servers.

### Reboot notification
When the local system reboots, the sm-notify command reads the list of monitored peers from persistent storage and sends an SM_NOTIFY request to the NSM service on each listed remote peer. It uses the mon_name string as the destination. To identify which host has rebooted, the sm-notify command sends the my_name string recorded when that remote was monitored. The remote rpc.statd matches incoming SM_NOTIFY requests using this string, or the caller's network address, to one or more peers on its own monitor list.

If rpc.statd does not find a peer on its monitor list that matches an incoming SM_NOTIFY request, the notification is not forwarded to the local lock manager. In addition, each peer has its own NSM state number, a 32-bit integer that is bumped after each reboot by the sm-notify command. rpc.statd uses this number to distinguish between actual reboots and replayed notifications.

Part of NFS lock recovery is rediscovering which peers need to be monitored again. The sm-notify command clears the monitor list on persistent storage after each reboot.

## OPTIONS
-d, --no-syslog

Causes rpc.statd to write log messages on stderr instead of to the system log, if the -F option was also specified.

-F, --foreground

Keeps rpc.statd attached to its controlling terminal so that NSM operation can be monitored directly or run under a debugger. If this option is not specified, rpc.statd backgrounds itself soon after it starts.

-h, -?, --help

Causes rpc.statd to display usage information on stderr and then exit.

-H, --ha-callout prog

Specifies a high availability callout program. If this option is not specified, no callouts are performed. See the High-availability callouts section below for details.

-L, --no-notify

Prevents rpc.statd from running the sm-notify command when it starts up, preserving the existing NSM state number and monitor list.

Note: the sm-notify command contains a check to ensure it runs only once after each system reboot. This prevents spurious reboot notification if rpc.statd restarts without the -L option.

-n, --name ipaddr | hostname

This string is only used by the sm-notify command as the source address from which to send reboot notification requests.

The ipaddr form can be expressed as either an IPv4 or an IPv6 presentation address. If this option is not specified, rpc.statd uses a wildcard address as the transport bind address. See sm-notify(8) for details.

-N

Causes rpc.statd to run the sm-notify command, and then exit. Since the sm-notify command can also be run directly, this option is deprecated.

-o, --outgoing-port port

Specifies the source port number the sm-notify command should use when sending reboot notifications. See sm-notify(8) for details.

-p, --port port

Specifies the port number used for RPC listener sockets. If this option is not specified, rpc.statd will try to consult /etc/services, if gets port succeed, set the same port for all listener socket, otherwise chooses a random ephemeral port for each listener socket.

This option can be used to fix the port value of its listeners when SM_NOTIFY requests must traverse a firewall between clients and servers.

-T, --nlm-port port

Specifies the port number that lockd should listen on for NLM requests. This sets both the TCP and UDP ports unless the UDP port is set separately.

-U, --nlm-udp-port port

Specifies the UDP port number that lockd should listen on for NLM requests.

-P, --state-directory-path pathname

Specifies the pathname of the parent directory where NSM state information resides. If this option is not specified, rpc.statd uses /var/lib/nfs/statd by default.

After starting, rpc.statd attempts to set its effective UID and GID to the owner and group of the subdirectory sm of this directory. After changing the effective ids, rpc.statd only needs to access files in sm and sm.bak within the state-directory-path.

-v, -V, --version

Causes rpc.statd to display version information on stderr and then exit.

## CONFIGURATION FILE
Many of the options that can be set on the command line can also be controlled through values set in the [statd] or, in some cases, the [lockd] sections of the /etc/nfs.conf configuration file. Values recognized in the [statd] section include port, outgoing-port, name, state-directory-path, and ha-callout which each have the same effect as the option with the same name.

The values recognized in the [lockd] section include port and udp-port which have the same effect as the --nlm-port and --nlm-udp-port options, respectively.

## SECURITY
The rpc.statd daemon must be started as root to acquire privileges needed to create sockets with privileged source ports, and to access the state information database. Because rpc.statd maintains a long-running network service, however, it drops root privileges as soon as it starts up to reduce the risk of a privilege escalation attack.

During normal operation, the effective user ID it chooses is the owner of the state directory. This allows it to continue to access files in that directory after it has dropped its root privileges. To control which user ID rpc.statd chooses, simply use chown(1) to set the owner of the state directory.

You can also protect your rpc.statd listeners using the tcp_wrapper library or iptables(8). To use the tcp_wrapper library, add the hostnames of peers that should be allowed access to /etc/hosts.allow. Use the daemon name statd even if the rpc.statd binary has a different filename.

For further information see the tcpd(8) and hosts_access(5) man pages.

## ADDITIONAL NOTES
Lock recovery after a reboot is critical to maintaining data integrity and preventing unnecessary application hangs. To help rpc.statd match SM_NOTIFY requests to NLM requests, a number of best practices should be observed, including:

The UTS nodename of your systems should match the DNS names that NFS peers use to contact them

The UTS nodenames of your systems should always be fully qualified domain names

The forward and reverse DNS mapping of the UTS nodenames should be consistent

The hostname the client uses to mount the server should match the server's mon_name in SM_NOTIFY requests it sends

Unmounting an NFS file system does not necessarily stop either the NFS client or server from monitoring each other. Both may continue monitoring each other for a time in case subsequent NFS traffic between the two results in fresh mounts and additional file locking.

On Linux, if the lockd kernel module is unloaded during normal operation, all remote NFS peers are unmonitored. This can happen on an NFS client, for example, if an automounter removes all NFS mount points due to inactivity.

### High-availability callouts
rpc.statd can exec a special callout program during processing of successful SM_MON, SM_UNMON, and SM_UNMON_ALL requests, or when it receives SM_NOTIFY. Such a program may be used in High Availability NFS (HA-NFS) environments to track lock state that may need to be migrated after a system reboot.

The name of the callout program is specified with the -H option. The program is run with 3 arguments: The first is either add-client del-client or sm-notify depending on the reason for the callout. The second is the mon_name of the monitored peer. The third is the caller_name of the requesting lock manager for add-client or del-client , otherwise it is IP_address of the caller sending SM_NOTIFY. The forth is the state_value in the SM_NOTIFY request.

### IPv6 and TI-RPC support
TI-RPC is a pre-requisite for supporting NFS on IPv6. If TI-RPC support is built into rpc.statd, it attempts to start listeners on network transports marked 'visible' in /etc/netconfig. As long as at least one network transport listener starts successfully, rpc.statd will operate.

## ENVIRONMENT
RPC_STATD_NO_NOTIFY=

If set to a positive integer, has the same effect as --no-notify.

## FILES
/var/lib/nfs/statd/sm

directory containing monitor list

/var/lib/nfs/statd/sm.bak

directory containing notify list

/var/lib/nfs/statd/state

NSM state number for this host

/run/run.statd.pid

pid file

/etc/netconfig

network transport capability database

## SEE ALSO
sm-notify(8), nfs(5), rpc.nfsd(8), rpcbind(8), tcpd(8), hosts_access(5), iptables(8), netconfig(5)

RFC 1094 - "NFS: Network File System Protocol Specification"

RFC 1813 - "NFS Version 3 Protocol Specification"

OpenGroup Protocols for Interworking: XNFS, Version 3W - Chapter 11

## AUTHORS
Jeff Uphoff <juphoff@users.sourceforge.net>

Olaf Kirch <okir@monad.swb.de>

H.J. Lu <hjl@gnu.org>

Lon Hohberger <hohberger@missioncriticallinux.com>

Paul Clements <paul.clements@steeleye.com>

Chuck Lever <chuck.lever@oracle.com>


exportfs

package: nfs-server

title: exportfs(8)

text:
# exportfs(8)

## NAME
exportfs - maintain table of exported NFS file systems

## SYNOPSIS
/usr/sbin/exportfs [-avi] [-o options,..] [client:/path ..]

/usr/sbin/exportfs -r [-v]

/usr/sbin/exportfs [-av] -u [client:/path ..]

/usr/sbin/exportfs [-v]

/usr/sbin/exportfs -f

/usr/sbin/exportfs -s

## DESCRIPTION
An NFS server maintains a table of local physical file systems that are accessible to NFS clients. Each file system in this table is referred to as an exported file system, or export, for short.

The exportfs command maintains the current table of exports for the NFS server. The master export table is kept in a file named /var/lib/nfs/etab. This file is read by rpc.mountd when a client sends an NFS MOUNT request.

Normally the master export table is initialized with the contents of /etc/exports and files under /etc/exports.d by invoking exportfs -a. However, a system administrator can choose to add or delete exports without modifying /etc/exports or files under /etc/exports.d by using the exportfs command.

exportfs and its partner program rpc.mountd work in one of two modes: a legacy mode which applies to 2.4 and earlier versions of the Linux kernel, and a new mode which applies to 2.6 and later versions, providing the nfsd virtual filesystem has been mounted at /proc/fs/nfsd or /proc/fs/nfs. On 2.6 kernels, if this filesystem is not mounted, the legacy mode is used.

In the new mode, exportfs does not give any information to the kernel, but provides it only to rpc.mountd through the /var/lib/nfs/etab file. rpc.mountd then manages kernel requests for information about exports, as needed.

In the legacy mode, exports which identify a specific host, rather than a subnet or netgroup, are entered directly into the kernel's export table, as well as being written to /var/lib/nfs/etab. Further, exports listed in /var/lib/nfs/rmtab which match a non host-specific export request will cause an appropriate export entry for the host given in rmtab to be added to the kernel's export table.

## OPTIONS
-d kind or --debug kind

Turn on debugging. Valid kinds are: all, auth, call, general and parse. Debugging can also be turned on by setting debug= in the [exportfs] section of /etc/nfs.conf.

-a

Export or unexport all directories.

-o options,...

Specify a list of export options in the same manner as in exports(5).

-i

Ignore the /etc/exports file and files under /etc/exports.d directory. Only default options and options given on the command line are used.

-r

Reexport all directories, synchronizing /var/lib/nfs/etab with /etc/exports and files under /etc/exports.d. This option removes entries in /var/lib/nfs/etab which have been deleted from /etc/exports or files under /etc/exports.d, and removes any entries from the kernel export table which are no longer valid.

-u

Unexport one or more directories.

-f

If /proc/fs/nfsd or /proc/fs/nfs is mounted, flush everything out of the kernel's export table. Fresh entries for active clients are added to the kernel's export table by rpc.mountd when they make their next NFS mount request.

-v

Be verbose. When exporting or unexporting, show what's going on. When displaying the current export list, also display the list of export options.

-s

Display the current export list suitable for /etc/exports.

## CONFIGURATION FILE
The [exportfs] section of the /etc/nfs.conf configuration file can contain a debug value, which can be one or more from the list general, call, auth, parse, all. When a list is given, the members should be comma-separated.

exportfs will also recognize the state-directory-path value from both the [mountd] section and the [exportd] section

## DISCUSSION

### Exporting Directories
The first synopsis shows how to invoke exportfs when adding new entries to the export table. When using exportfs -a, all exports listed in /etc/exports and files under /etc/exports.d are added to /var/lib/nfs/etab. The kernel's export table is also updated as needed.

The host:/path argument specifies a local directory to export, along with the client or clients who are permitted to access it. See exports(5) for a description of supported options and access list formats.

IPv6 presentation addresses contain colons, which are already used to separate the "host" and "path" command line arguments. When specifying a client using a raw IPv6 address, enclose the address in square brackets. For IPv6 network addresses, place the prefix just after the closing bracket.

To export a directory to the world, simply specify :/path.

The export options for a particular host/directory pair derive from several sources. The default export options are sync,ro,root_squash,wdelay. These can be overridden by entries in /etc/exports or files under /etc/exports.d.

A system administrator may override options from these sources using the -o command-line option on exportfs. This option takes a comma-separated list of options in the same fashion as one would specify them in /etc/exports. In this way exportfs can be used to modify the export options of an already exported directory.

### Unexporting Directories
The third synopsis shows how to unexport a currently exported directory. When using exportfs -ua, all entries listed in /var/lib/nfs/etab are removed from the kernel export tables, and the file is cleared. This effectively shuts down all NFS activity.

To remove an export, specify a host:/path pair. This deletes the specified entry from /var/lib/nfs/etab and removes the corresponding kernel entry (if any).

### Dumping the Export Table
Invoking exportfs without options shows the current list of exported file systems. Adding the -v option causes exportfs to display the export options for each export.

## EXAMPLES
The following adds all directories listed in /etc/exports and files under /etc/exports.d to /var/lib/nfs/etab and pushes the resulting export entries into the kernel:

```
# exportfs -a
```

To export the /usr/tmp directory to host django, allowing insecure file locking requests from clients:

```
# exportfs -o insecure_locks django:/usr/tmp
```

To unexport the /usr/tmp directory:

```
# exportfs -u django:/usr/tmp
```

To unexport all exports listed in /etc/exports and files under /etc/exports.d:

```
# exportfs -au
```

To export the /usr/tmp directory to IPv6 link-local clients:

```
# exportfs [fe80::]/64:/usr/tmp
```

## USAGE NOTES
Exporting to IP networks or DNS and NIS domains does not enable clients from these groups to access NFS immediately. Rather, these sorts of exports are hints to rpc.mountd(8) to grant any mount requests from these clients. This is usually not a problem, because any existing mounts are preserved in rmtab across reboots.

When unexporting a network or domain entry, any current exports to members of this group will be checked against the remaining valid exports and if they themselves are no longer valid they will be removed.

## FILES
/etc/exports

input file listing exports, export options, and access control lists

/etc/exports.d

directory where extra input files are stored. Note: only files that end with .exports are used.

/var/lib/nfs/etab

master table of exports

/var/lib/nfs/rmtab

table of clients accessing server's exports

## SEE ALSO
exports(5), nfs.conf(5), rpc.mountd(8), exportd(8), netgroup(5)

## AUTHORS
Olaf Kirch <okir@monad.swb.de>

Neil Brown <neilb@cse.unsw.edu.au>


idmapd

title: idmapd(8)

summary: NFSv4 ID <-> Name Mapper

text:
# idmapd(8)

## NAME
rpc.idmapd — NFSv4 ID <-> Name Mapper

## SYNOPSIS
rpc.idmapd

[-h] [-f] [-v] [-C] [-S] [-p path] [-c path]

## DESCRIPTION
rpc.idmapd is the NFSv4 ID <-> name mapping daemon. It provides functionality to the NFSv4 kernel client and server, to which it communicates via upcalls, by translating user and group IDs to names, and vice versa.

The system derives the part of the string by performing a password or group lookup. The lookup mechanism is configured in /etc/idmapd.conf

By default, the part of the string is the system's DNS domain name. It can also be specified in /etc/idmapd.conf if the system is multi-homed, or if the system's DNS domain name does not match the name of the system's Kerberos realm.

When the domain is not specified in /etc/idmapd.conf the local DNS server will be queried for the _nfsv4idmapdomain text record. If the record exists that will be used as the domain. When the record does not exist, the domain part of the DNS domain will used.

Note that on more recent kernels only the NFSv4 server uses rpc.idmapd. The NFSv4 client instead uses nfsidmap(8), and only falls back to rpc.idmapd if there was a problem running the nfsidmap(8) program.

The options are as follows:

-h

Display usage message.

-v

Increases the verbosity level (can be specified multiple times).

-f

Runs rpc.idmapd in the foreground and prints all output to the terminal.

-p path

Specifies the location of the RPC pipefs to be path. The default value is "/var/lib/nfs/rpc_pipefs".

-c path

Use configuration file path. This option is deprecated.

-C

Client-only: perform no idmapping for any NFS server, even if one is detected.

-S

Server-only: perform no idmapping for any NFS client, even if one is detected.

## CONFIGURATION FILES
rpc.idmapd recognizes the following value from the [general] section of the /etc/nfs.conf configuration file:

pipefs-directory

Equivalent to -p.

All other settings related to id mapping are found in the /etc/idmapd.conf configuration file.

## EXAMPLES
rpc.idmapd -f -vvv

Runs rpc.idmapd printing all messages to console, and with a verbosity level of 3.

## FILES
/etc/idmapd.conf, /etc/nfs.conf

## SEE ALSO
idmapd.conf(5), nfs.conf(5), nfsidmap(8)

## AUTHORS
The rpc.idmapd software has been developed by Marius Aamodt Eriksen ⟨marius@citi.umich.edu⟩.