neulab/tldr huggingface dataset:
H_ENTER, const char *str Add str as a new element to the history, and, if necessary, removing the oldest entry to keep the list to the created size. If H_SETUNIQUE was has been called with a non-zero arguments, the element will not be entered into the history if its contents match the ones of the current history element.  If the element is entered history() returns 1, if it is ignored as a duplicate returns 0.  Finally history() returns -1 if an error occurred.
H_PREV_STR, const char *str Return the closest previous event that starts with str.
H_NEXT_STR, const char *str Return the closest next event that starts with str.
H_PREV_EVENT, int e Return the previous event numbered e.
H_NEXT_EVENT, int e Return the next event numbered e.
H_LOAD, const char *file Load the history list stored in file.
H_SAVE, const char *file Save the history list to file.
H_SETUNIQUE, int unique Set flag that adjacent identical event strings should not be entered into the history.
H_GETUNIQUE Retrieve the current setting if adjacent identical elements should be entered into the history.
H_DEL, int e Delete the event numbered e.  This function is only provided for readline(3) compatibility.  The caller is responsible for free'ing the string in the returned HistEvent.
history() returns >= 0 if the operation op succeeds.  Otherwise, -1 is returned and ev is updated to contain more details about the error.
The tokenization functions use a common data structure, Tokenizer, which is created by tok_init() and freed by tok_end().
tok_init() Initialise the tokenizer, and return a data structure to be used by all other tokenizer functions.  IFS contains the Input Field Separators, which defaults to ⟨space⟩, ⟨tab⟩, and ⟨newline⟩ if NULL.
tok_end() Clean up and finish with t, assumed to have been created with tok_init().
tok_reset() Reset the tokenizer state.  Use after a line has been successfully tokenized by tok_line() or tok_str() and before a new line is to be tokenized.
tok_line() Tokenize li, If successful, modify: argv to contain the words, argc to contain the number of words, cursorc (if not NULL) to contain the index of the word containing the cursor, and cursoro (if not NULL) to contain the offset within argv[cursorc] of the cursor.
Returns 0 if successful, -1 for an internal error, 1 for an unmatched single quote, 2 for an unmatched double quote, and 3 for a backslash quoted ⟨newline⟩.  A positive exit code indicates that another line should be read and tokenization attempted again.
tok_str() A simpler form of tok_line(); str is a NUL terminated string to tokenize.
sh(1), signal(3), termcap(3), editrc(5), termcap(5)
The editline library first appeared in 4.4BSD.  CC_REDISPLAY appeared in NetBSD 1.3.  CC_REFRESH_BEEP, EL_EDITMODE and the readline emulation appeared in NetBSD 1.4.  EL_RPROMPT appeared in NetBSD 1.5.
The editline library was written by Christos Zoulas.  Luke Mewburn wrote this manual and implemented CC_REDISPLAY, CC_REFRESH_BEEP, EL_EDITMODE, and EL_RPROMPT.  Jaromir Dolecek implemented the readline emulation.
At this time, it is the responsibility of the caller to check the result of the EL_EDITMODE operation of el_get() (after an el_source() or el_parse()) to determine if editline should be used for further input.  I.e., EL_EDITMODE is purely an indication of the result of the most recent editrc(5) edit command.
CARGO-BUILD(1)               General Commands Manual              CARGO-BUILD(1)
cargo-build - Compile the current package
cargo build [options]
Compile local packages and all of their dependencies.
-p spec..., --package spec... Build only the specified packages. See cargo-pkgid(1) for the SPEC format. This flag may be specified multiple times and supports common Unix glob patterns like *, ? and []. However, to avoid your shell accidentally expanding glob patterns before Cargo handles them, you must use single quotes or double quotes around each pattern.
--workspace Build all members in the workspace.
Target Selection When no target selection options are given, cargo build will build all binary and library targets of the selected packages. Binaries are skipped if they have required-features that are missing.
--profile name Build with the given profile. See the the reference <https://doc.rust-lang.org/cargo/reference/profiles.html> for more details on profiles.
--out-dir directory Copy final artifacts to this directory.
This option is unstable and available only on the nightly channel <https://doc.rust-lang.org/book/appendix-07-nightly-rust.html> and requires the -Z unstable-options flag to enable. See <https://github.com/rust-lang/cargo/issues/6790> for more information.
--build-plan Outputs a series of JSON messages to stdout that indicate the commands to run the build.
This option is unstable and available only on the nightly channel <https://doc.rust-lang.org/book/appendix-07-nightly-rust.html> and requires the -Z unstable-options flag to enable. See <https://github.com/rust-lang/cargo/issues/5579> for more information.
1. Build the local package and all of its dependencies:
2. Build with optimizations:
cargo(1), cargo-rustc(1)
BASENAME(1)                       User Commands                      BASENAME(1)
basename - strip directory and suffix from filenames
basename NAME [SUFFIX] basename OPTION... NAME...
Print NAME with any leading directory components removed.  If specified, also remove a trailing SUFFIX.
basename /usr/bin/sort -> "sort"
basename include/stdio.h .h -> "stdio"
basename -s .h include/stdio.h -> "stdio"
basename -a any/str1 any/str2 -> "str1" followed by "str2"
dirname(1), readlink(1)
Full documentation <https://www.gnu.org/software/coreutils/basename> or available locally via: info '(coreutils) basename invocation'
GIT-BUNDLE(1)                      Git Manual                      GIT-BUNDLE(1)
git-bundle - Move objects and refs by archive
git bundle create [-q | --quiet | --progress | --all-progress] [--all-progress-implied] [--version=<version>] <file> <git-rev-list-args> git bundle verify [-q | --quiet] <file> git bundle list-heads <file> [<refname>...] git bundle unbundle [--progress] <file> [<refname>...]
Create, unpack, and manipulate "bundle" files. Bundles are used for the "offline" transfer of Git objects without an active "server" sitting on the other side of the network connection.
They can be used to create both incremental and full backups of a repository, and to relay the state of the references in one repository to another.
Git commands that fetch or otherwise "read" via protocols such as ssh:// and https:// can also operate on bundle files. It is possible git- clone(1) a new repository from a bundle, to use git-fetch(1) to fetch from one, and to list the references contained within it with git-ls- remote(1). There’s no corresponding "write" support, i.e.a git push into a bundle is not supported.
See the "EXAMPLES" section below for examples of how to use bundles.
Bundles are .pack files (see git-pack-objects(1)) with a header indicating what references are contained within the bundle.
Like the the packed archive format itself bundles can either be self-contained, or be created using exclusions. See the "OBJECT PREREQUISITES" section below.
Bundles created using revision exclusions are "thin packs" created using the --thin option to git-pack-objects(1), and unbundled using the --fix-thin option to git-index-pack(1).
There is no option to create a "thick pack" when using revision exclusions, and users should not be concerned about the difference. By using "thin packs", bundles created using exclusions are smaller in size. That they’re "thin" under the hood is merely noted here as a curiosity, and as a reference to other documentation.
See the bundle-format documentation[1] for more details and the discussion of "thin pack" in the pack format documentation[2] for further details.
create [options] <file> <git-rev-list-args> Used to create a bundle named file. This requires the <git-rev-list-args> arguments to define the bundle contents.  options contains the options specific to the git bundle create subcommand.
verify <file> Used to check that a bundle file is valid and will apply cleanly to the current repository. This includes checks on the bundle format itself as well as checking that the prerequisite commits exist and are fully linked in the current repository.  git bundle prints a list of missing commits, if any, and exits with a non-zero status.
list-heads <file> Lists the references defined in the bundle. If followed by a list of references, only references matching those given are printed out.
unbundle <file> Passes the objects in the bundle to git index-pack for storage in the repository, then prints the names of all defined references. If a list of references is given, only references matching those in the list are printed. This command is really plumbing, intended to be called only by git fetch.
<git-rev-list-args> A list of arguments, acceptable to git rev-parse and git rev-list (and containing a named ref, see SPECIFYING REFERENCES below), that specifies the specific objects and references to transport. For example, master~10..master causes the current master reference to be packaged along with all objects added since its 10th ancestor commit. There is no explicit limit to the number of references and objects that may be packaged.
[<refname>...] A list of references used to limit the references reported as available. This is principally of use to git fetch, which expects to receive only those references asked for and not necessarily everything in the pack (in this case, git bundle acts like git fetch-pack).
--all-progress When --stdout is specified then progress report is displayed during the object count and compression phases but inhibited during the write-out phase. The reason is that in some cases the output stream is directly linked to another command which may wish to display progress status of its own as it processes incoming pack data. This flag is like --progress except that it forces progress report for the write-out phase as well even if --stdout is used.
--all-progress-implied This is used to imply --all-progress whenever progress display is activated. Unlike --all-progress this flag doesn’t actually force any progress display by itself.
--version=<version> Specify the bundle version. Version 2 is the older format and can only be used with SHA-1 repositories; the newer version 3 contains capabilities that permit extensions. The default is the oldest supported format, based on the hash algorithm in use.
-q, --quiet This flag makes the command not to report its progress on the standard error stream.
Revisions must be accompanied by reference names to be packaged in a bundle.
More than one reference may be packaged, and more than one set of prerequisite objects can be specified. The objects packaged are those not contained in the union of the prerequisites.
The git bundle create command resolves the reference names for you using the same rules as git rev-parse --abbrev-ref=loose. Each prerequisite can be specified explicitly (e.g. ^master~10), or implicitly (e.g. master~10..master, --since=10.days.ago master).
All of these simple cases are OK (assuming we have a "master" and "next" branch):
$ git bundle create master.bundle master $ echo master | git bundle create master.bundle --stdin $ git bundle create master-and-next.bundle master next $ (echo master; echo next) | git bundle create master-and-next.bundle --stdin
And so are these (and the same but omitted --stdin examples):
$ git bundle create recent-master.bundle master~10..master $ git bundle create recent-updates.bundle master~10..master next~5..next
A revision name or a range whose right-hand-side cannot be resolved to a reference is not accepted:
$ git bundle create HEAD.bundle $(git rev-parse HEAD) fatal: Refusing to create empty bundle. $ git bundle create master-yesterday.bundle master~10..master~5 fatal: Refusing to create empty bundle.
When creating bundles it is possible to create a self-contained bundle that can be unbundled in a repository with no common history, as well as providing negative revisions to exclude objects needed in the earlier parts of the history.
Feeding a revision such as new to git bundle create will create a bundle file that contains all the objects reachable from the revision new. That bundle can be unbundled in any repository to obtain a full history that leads to the revision new:
$ git bundle create full.bundle new
A revision range such as old..new will produce a bundle file that will require the revision old (and any objects reachable from it) to exist for the bundle to be "unbundle"-able:
$ git bundle create full.bundle old..new
A self-contained bundle without any prerequisites can be extracted into anywhere, even into an empty repository, or be cloned from (i.e., new, but not old..new).
It is okay to err on the side of caution, causing the bundle file to contain objects already in the destination, as these are ignored when unpacking at the destination.
If you want to match git clone --mirror, which would include your refs such as refs/remotes/*, use --all. If you want to provide the same set of refs that a clone directly from the source repository would get, use --branches --tags for the <git-rev-list-args>.
The git bundle verify command can be used to check whether your recipient repository has the required prerequisite commits for a bundle.
Assume you want to transfer the history from a repository R1 on machine A to another repository R2 on machine B. For whatever reason, direct connection between A and B is not allowed, but we can move data from A to B via some mechanism (CD, email, etc.). We want to update R2 with development made on the branch master in R1.
To bootstrap the process, you can first create a bundle that does not have any prerequisites. You can use a tag to remember up to what commit you last processed, in order to make it easy to later update the other repository with an incremental bundle:
machineA$ cd R1 machineA$ git bundle create file.bundle master machineA$ git tag -f lastR2bundle master
Then you transfer file.bundle to the target machine B. Because this bundle does not require any existing object to be extracted, you can create a new repository on machine B by cloning from it:
machineB$ git clone -b master /home/me/tmp/file.bundle R2
This will define a remote called "origin" in the resulting repository that lets you fetch and pull from the bundle. The $GIT_DIR/config file in R2 will have an entry like this:
[remote "origin"] url = /home/me/tmp/file.bundle fetch = refs/heads/*:refs/remotes/origin/*
To update the resulting mine.git repository, you can fetch or pull after replacing the bundle stored at /home/me/tmp/file.bundle with incremental updates.
After working some more in the original repository, you can create an incremental bundle to update the other repository:
machineA$ cd R1 machineA$ git bundle create file.bundle lastR2bundle..master machineA$ git tag -f lastR2bundle master
You then transfer the bundle to the other machine to replace /home/me/tmp/file.bundle, and pull from it.
machineB$ cd R2 machineB$ git pull
If you know up to what commit the intended recipient repository should have the necessary objects, you can use that knowledge to specify the prerequisites, giving a cut-off point to limit the revisions and objects that go in the resulting bundle. The previous example used the lastR2bundle tag for this purpose, but you can use any other options that you would give to the git-log(1) command. Here are more examples:
You can use a tag that is present in both:
$ git bundle create mybundle v1.0.0..master
You can use a prerequisite based on time:
$ git bundle create mybundle --since=10.days master
You can use the number of commits:
$ git bundle create mybundle -10 master
You can run git-bundle verify to see if you can extract from a bundle that was created with a prerequisite:
$ git bundle verify mybundle
This will list what commits you must have in order to extract from the bundle and will error out if you do not have them.
A bundle from a recipient repository’s point of view is just like a regular repository which it fetches or pulls from. You can, for example, map references when fetching:
$ git fetch mybundle master:localRef
You can also see what references it offers:
$ git ls-remote mybundle
1. the bundle-format documentation file:///usr/share/doc/git-doc/technical/bundle-format.html
2. the pack format documentation file:///usr/share/doc/git-doc/technical/pack-format.html
NFT(8)                                                                    NFT(8)
nft - Administration tool of the nftables framework for packet filtering and classification
nft [ -nNscaeSupyjt ] [ -I directory ] [ -f filename | -i | cmd ...] nft -h nft -v
nft is the command line tool used to set up, maintain and inspect packet filtering and classification rules in the Linux kernel, in the nftables framework. The Linux kernel subsystem is known as nf_tables, and ‘nf’ stands for Netfilter.
The command accepts several different options which are documented here in groups for better understanding of their meaning. You can get information about options by running nft --help.
-h, --help Show help message and all options.
-v, --version Show version.
-V Show long version information, including compile-time configuration.
Ruleset input handling options that specify to how to load rulesets:
-f, --file filename Read input from filename. If filename is -, read from stdin.
-D, --define name=value Define a variable. You can only combine this option with -f.
-i, --interactive Read input from an interactive readline CLI. You can use quit to exit, or use the EOF marker, normally this is CTRL-D.
-I, --includepath directory Add the directory directory to the list of directories to be searched for included files. This option may be specified multiple times.
-c, --check Check commands validity without actually applying the changes.
Ruleset list output formatting that modify the output of the list ruleset command:
-a, --handle Show object handles in output.
-s, --stateless Omit stateful information of rules and stateful objects.
-t, --terse Omit contents of sets from output.
-S, --service Translate ports to service names as defined by /etc/services.
-N, --reversedns Translate IP address to names via reverse DNS lookup. This may slow down your listing since it generates network traffic.
-u, --guid Translate numeric UID/GID to names as defined by /etc/passwd and /etc/group.
-n, --numeric Print fully numerical output.
-y, --numeric-priority Display base chain priority numerically.
-p, --numeric-protocol Display layer 4 protocol numerically.
-T, --numeric-time Show time, day and hour values in numeric format.
Command output formatting:
-e, --echo When inserting items into the ruleset using add, insert or replace commands, print notifications just like nft monitor.
-j, --json Format output in JSON. See libnftables-json(5) for a schema description.
-d, --debug level Enable debugging output. The debug level can be any of scanner, parser, eval, netlink, mnl, proto-ctx, segtree, all. You can combine more than one by separating by the , symbol, for example -d eval,mnl.
LEXICAL CONVENTIONS Input is parsed line-wise. When the last character of a line, just before the newline character, is a non-quoted backslash (\), the next line is treated as a continuation. Multiple commands on the same line can be separated using a semicolon (;).
A hash sign (#) begins a comment. All following characters on the same line are ignored.
Identifiers begin with an alphabetic character (a-z,A-Z), followed by zero or more alphanumeric characters (a-z,A-Z,0-9) and the characters slash (/), backslash (\), underscore (_) and dot (.). Identifiers using different characters or clashing with a keyword need to be enclosed in double quotes (").
INCLUDE FILES include filename
Other files can be included by using the include statement. The directories to be searched for include files can be specified using the -I/--includepath option. You can override this behaviour either by prepending ‘./’ to your path to force inclusion of files located in the current working directory (i.e. relative path) or / for file location expressed as an absolute path.
If -I/--includepath is not specified, then nft relies on the default directory that is specified at compile time. You can retrieve this default directory via the -h/--help option.
Include statements support the usual shell wildcard symbols (,?,[]). Having no matches for an include statement is not an error, if wildcard symbols are used in the include statement. This allows having potentially empty include directories for statements like include "/etc/firewall/rules/". The wildcard matches are loaded in alphabetical order. Files beginning with dot (.) are not matched by include statements.
SYMBOLIC VARIABLES define variable = expr $variable
Symbolic variables can be defined using the define statement. Variable references are expressions and can be used to initialize other variables. The scope of a definition is the current block and all blocks contained within.
Using symbolic variables.
define int_if1 = eth0 define int_if2 = eth1 define int_ifs = { $int_if1, $int_if2 }
filter input iif $int_ifs accept
Address families determine the type of packets which are processed. For each address family, the kernel contains so called hooks at specific stages of the packet processing paths, which invoke nftables if rules for these hooks exist.
ip       IPv4 address family.
ip6      IPv6 address family.
inet     Internet (IPv4/IPv6) address family.
arp      ARP address family, handling IPv4 ARP packets.
bridge   Bridge address family, handling packets which traverse a bridge device.
netdev   Netdev address family, handling packets on ingress and egress.
All nftables objects exist in address family specific namespaces, therefore all identifiers include an address family. If an identifier is specified without an address family, the ip family is used by default.
IPV4/IPV6/INET ADDRESS FAMILIES The IPv4/IPv6/Inet address families handle IPv4, IPv6 or both types of packets. They contain five hooks at different packet processing stages in the network stack.
Table 1. IPv4/IPv6/Inet address family hooks ┌────────────┬─────────────────────────────┐ │Hook        │ Description                 │ ├────────────┼─────────────────────────────┤ │            │                             │ │prerouting  │ All packets entering the    │ │            │ system are processed by the │ │            │ prerouting hook. It is      │ │            │ invoked before the routing  │ │            │ process and is used for     │ │            │ early filtering or changing │ │            │ packet attributes that      │ │            │ affect routing.             │ ├────────────┼─────────────────────────────┤ │            │                             │ │input       │ Packets delivered to the    │ │            │ local system are processed  │ │            │ by the input hook.          │ ├────────────┼─────────────────────────────┤ │            │                             │ │forward     │ Packets forwarded to a      │ │            │ different host are          │ │            │ processed by the forward    │ │            │ hook.                       │ ├────────────┼─────────────────────────────┤ │            │                             │ │output      │ Packets sent by local       │ │            │ processes are processed by  │ │            │ the output hook.            │ ├────────────┼─────────────────────────────┤ │            │                             │ │postrouting │ All packets leaving the     │ │            │ system are processed by the │ │            │ postrouting hook.           │ ├────────────┼─────────────────────────────┤ │            │                             │ │ingress     │ All packets entering the    │ │            │ system are processed by     │ │            │ this hook. It is invoked    │ │            │ before layer 3 protocol     │ │            │ handlers, hence before the  │ │            │ prerouting hook, and it can │ │            │ be used for filtering and   │ │            │ policing. Ingress is only   │ │            │ available for Inet family   │ │            │ (since Linux kernel 5.10).  │ └────────────┴─────────────────────────────┘
ARP ADDRESS FAMILY The ARP address family handles ARP packets received and sent by the system. It is commonly used to mangle ARP packets for clustering.
Table 2. ARP address family hooks ┌───────┬─────────────────────────────┐ │Hook   │ Description                 │ ├───────┼─────────────────────────────┤ │       │                             │ │input  │ Packets delivered to the    │ │       │ local system are processed  │ │       │ by the input hook.          │ ├───────┼─────────────────────────────┤ │       │                             │ │output │ Packets send by the local   │ │       │ system are processed by the │ │       │ output hook.                │ └───────┴─────────────────────────────┘
BRIDGE ADDRESS FAMILY The bridge address family handles Ethernet packets traversing bridge devices.
The list of supported hooks is identical to IPv4/IPv6/Inet address families above.
NETDEV ADDRESS FAMILY The Netdev address family handles packets from the device ingress and egress path. This family allows you to filter packets of any ethertype such as ARP, VLAN 802.1q, VLAN 802.1ad (Q-in-Q) as well as IPv4 and IPv6 packets.
Table 3. Netdev address family hooks ┌────────┬─────────────────────────────┐ │Hook    │ Description                 │ ├────────┼─────────────────────────────┤ │        │                             │ │ingress │ All packets entering the    │ │        │ system are processed by     │ │        │ this hook. It is invoked    │ │        │ after the network taps (ie. │ │        │ tcpdump), right after tc    │ │        │ ingress and before layer 3  │ │        │ protocol handlers, it can   │ │        │ be used for early filtering │ │        │ and policing.               │ ├────────┼─────────────────────────────┤ │        │                             │ │egress  │ All packets leaving the     │ │        │ system are processed by     │ │        │ this hook. It is invoked    │ │        │ after layer 3 protocol      │ │        │ handlers and before tc      │ │        │ egress. It can be used for  │ │        │ late filtering and          │ │        │ policing.                   │ └────────┴─────────────────────────────┘
Tunneled packets (such as vxlan) are processed by netdev family hooks both in decapsulated and encapsulated (tunneled) form. So a packet can be filtered on the overlay network as well as on the underlying network.
Note that the order of netfilter and tc is mirrored on ingress versus egress. This ensures symmetry for NAT and other packet mangling.
Ingress packets which are redirected out some other interface are only processed by netfilter on egress if they have passed through netfilter ingress processing before. Thus, ingress packets which are redirected by tc are not subjected to netfilter. But they are if they are redirected by netfilter on ingress. Conceptually, tc and netfilter can be thought of as layers, with netfilter layered above tc: If the packet hasn’t been passed up from the tc layer to the netfilter layer, it’s not subjected to netfilter on egress.
{list | flush} ruleset [family]
The ruleset keyword is used to identify the whole set of tables, chains, etc. currently in place in kernel. The following ruleset commands exist:
list    Print the ruleset in human-readable format.
flush   Clear the whole ruleset. Note that, unlike iptables, this will remove all tables and whatever they contain, effectively leading to an empty ruleset - no packet filtering will happen anymore, so the kernel accepts any valid packet it receives.
It is possible to limit list and flush to a specific address family only. For a list of valid family names, see the section called “ADDRESS FAMILIES” above.
By design, list ruleset command output may be used as input to nft -f. Effectively, this is the nft-equivalent of iptables-save and iptables-restore.
{add | create} table [family] table [ {comment comment ;} { flags 'flags ; }] {delete | list | flush} table [family] table list tables [family] delete table [family] handle handle
Tables are containers for chains, sets and stateful objects. They are identified by their address family and their name. The address family must be one of ip, ip6, inet, arp, bridge, netdev. The inet address family is a dummy family which is used to create hybrid IPv4/IPv6 tables. The meta expression nfproto keyword can be used to test which family (ipv4 or ipv6) context the packet is being processed in. When no address family is specified, ip is used by default. The only difference between add and create is that the former will not return an error if the specified table already exists while create will return an error.
Table 4. Table flags ┌────────┬────────────────────────────┐ │Flag    │ Description                │ ├────────┼────────────────────────────┤ │        │                            │ │dormant │ table is not evaluated any │ │        │ more (base chains are      │ │        │ unregistered).             │ └────────┴────────────────────────────┘
Add, change, delete a table.
# start nft in interactive mode nft --interactive
# create a new table. create table inet mytable
# add a new base chain: get input packets add chain inet mytable myin { type filter hook input priority filter; }
# add a single counter to the chain add rule inet mytable myin counter
# disable the table temporarily -- rules are not evaluated anymore add table inet mytable { flags dormant; }
# make table active again: add table inet mytable
add      Add a new table for the given family with the given name.
delete   Delete the specified table.
list     List all chains and rules of the specified table.
flush    Flush all chains and rules of the specified table.
{add | create} chain [family] table chain [{ type type hook hook [device device] priority priority ; [policy policy ;] [comment comment ;] }] {delete | list | flush} chain ['family] table chain list chains [family] delete chain [family] table handle handle rename chain [family] table chain newname
Chains are containers for rules. They exist in two kinds, base chains and regular chains. A base chain is an entry point for packets from the networking stack, a regular chain may be used as jump target and is used for better rule organization.
add      Add a new chain in the specified table. When a hook and priority value are specified, the chain is created as a base chain and hooked up to the networking stack.
create   Similar to the add command, but returns an error if the chain already exists.
delete   Delete the specified chain. The chain must not contain any rules or be used as jump target.
rename   Rename the specified chain.
list     List all rules of the specified chain.
flush    Flush all rules of the specified chain.
For base chains, type, hook and priority parameters are mandatory.
Table 5. Supported chain types ┌───────┬───────────────┬────────────────┬──────────────────┐ │Type   │ Families      │ Hooks          │ Description      │ ├───────┼───────────────┼────────────────┼──────────────────┤ │       │               │                │                  │ │filter │ all           │ all            │ Standard chain   │ │       │               │                │ type to use in   │ │       │               │                │ doubt.           │ ├───────┼───────────────┼────────────────┼──────────────────┤ │       │               │                │                  │ │nat    │ ip, ip6, inet │ prerouting,    │ Chains of this   │ │       │               │ input, output, │ type perform     │ │       │               │ postrouting    │ Native Address   │ │       │               │                │ Translation      │ │       │               │                │ based on         │ │       │               │                │ conntrack        │ │       │               │                │ entries. Only    │ │       │               │                │ the first packet │ │       │               │                │ of a connection  │ │       │               │                │ actually         │ │       │               │                │ traverses this   │ │       │               │                │ chain - its      │ │       │               │                │ rules usually    │ │       │               │                │ define details   │ │       │               │                │ of the created   │ │       │               │                │ conntrack entry  │ │       │               │                │ (NAT statements  │ │       │               │                │ for instance).   │ ├───────┼───────────────┼────────────────┼──────────────────┤ │       │               │                │                  │ │route  │ ip, ip6       │ output         │ If a packet has  │ │       │               │                │ traversed a      │ │       │               │                │ chain of this    │ │       │               │                │ type and is      │ │       │               │                │ about to be      │ │       │               │                │ accepted, a new  │ │       │               │                │ route lookup is  │ │       │               │                │ performed if     │ │       │               │                │ relevant parts   │ │       │               │                │ of the IP header │ │       │               │                │ have changed.    │ │       │               │                │ This allows to   │ │       │               │                │ e.g. implement   │ │       │               │                │ policy routing   │ │       │               │                │ selectors in     │ │       │               │                │ nftables.        │ └───────┴───────────────┴────────────────┴──────────────────┘
Apart from the special cases illustrated above (e.g. nat type not supporting forward hook or route type only supporting output hook), there are three further quirks worth noticing:
•   The netdev family supports merely two combinations, namely filter type with ingress hook and filter type with egress hook. Base chains in this family also require the device parameter to be present since they exist per interface only.
•   The arp family supports only the input and output hooks, both in chains of type filter.
•   The inet family also supports the ingress hook (since Linux kernel 5.10), to filter IPv4 and IPv6 packet at the same location as the netdev ingress hook. This inet hook allows you to share sets and maps between the usual prerouting, input, forward, output, postrouting and this ingress hook.
The priority parameter accepts a signed integer value or a standard priority name which specifies the order in which chains with the same hook value are traversed. The ordering is ascending, i.e. lower priority values have precedence over higher ones.
Standard priority values can be replaced with easily memorizable names. Not all names make sense in every family with every hook (see the compatibility matrices below) but their numerical value can still be used for prioritizing chains.
These names and values are defined and made available based on what priorities are used by xtables when registering their default chains.
Most of the families use the same values, but bridge uses different ones from the others. See the following tables that describe the values and compatibility.
Table 6. Standard priority names, family and hook compatibility matrix ┌─────────┬───────┬────────────────┬─────────────┐ │Name     │ Value │ Families       │ Hooks       │ ├─────────┼───────┼────────────────┼─────────────┤ │         │       │                │             │ │raw      │ -300  │ ip, ip6, inet  │ all         │ ├─────────┼───────┼────────────────┼─────────────┤ │         │       │                │             │ │mangle   │ -150  │ ip, ip6, inet  │ all         │ ├─────────┼───────┼────────────────┼─────────────┤ │         │       │                │             │ │dstnat   │ -100  │ ip, ip6, inet  │ prerouting  │ ├─────────┼───────┼────────────────┼─────────────┤ │         │       │                │             │ │filter   │ 0     │ ip, ip6, inet, │ all         │ │         │       │ arp, netdev    │             │ ├─────────┼───────┼────────────────┼─────────────┤ │         │       │                │             │ │security │ 50    │ ip, ip6, inet  │ all         │ ├─────────┼───────┼────────────────┼─────────────┤ │         │       │                │             │ │srcnat   │ 100   │ ip, ip6, inet  │ postrouting │ └─────────┴───────┴────────────────┴─────────────┘
Table 7. Standard priority names and hook compatibility for the bridge family ┌───────┬───────┬─────────────┐ │       │       │             │ │Name   │ Value │ Hooks       │ ├───────┼───────┼─────────────┤ │       │       │             │ │dstnat │ -300  │ prerouting  │ ├───────┼───────┼─────────────┤ │       │       │             │ │filter │ -200  │ all         │ ├───────┼───────┼─────────────┤ │       │       │             │ │out    │ 100   │ output      │ ├───────┼───────┼─────────────┤ │       │       │             │ │srcnat │ 300   │ postrouting │ └───────┴───────┴─────────────┘
Basic arithmetic expressions (addition and subtraction) can also be achieved with these standard names to ease relative prioritizing, e.g. mangle - 5 stands for -155. Values will also be printed like this until the value is not further than 10 from the standard value.
Base chains also allow to set the chain’s policy, i.e. what happens to packets not explicitly accepted or refused in contained rules. Supported policy values are accept (which is the default) or drop.
{add | insert} rule [family] table chain [handle handle | index index] statement ... [comment comment] replace rule [family] table chain handle handle statement ... [comment comment] delete rule [family] table chain handle handle
Rules are added to chains in the given table. If the family is not specified, the ip family is used. Rules are constructed from two kinds of components according to a set of grammatical rules: expressions and statements.
The add and insert commands support an optional location specifier, which is either a handle or the index (starting at zero) of an existing rule. Internally, rule locations are always identified by handle and the translation from index happens in userspace. This has two potential implications in case a concurrent ruleset change happens after the translation was done: The effective rule index might change if a rule was inserted or deleted before the referred one. If the referred rule was deleted, the command is rejected by the kernel just as if an invalid handle was given.
A comment is a single word or a double-quoted (") multi-word string which can be used to make notes regarding the actual rule. Note: If you use bash for adding rules, you have to escape the quotation marks, e.g. \"enable ssh for servers\".
add       Add a new rule described by the list of statements. The rule is appended to the given chain unless a location is specified, in which case the rule is inserted after the specified rule.
insert    Same as add except the rule is inserted at the beginning of the chain or before the specified rule.
replace   Similar to add, but the rule replaces the specified rule.
delete    Delete the specified rule.
add a rule to ip table output chain.
nft add rule filter output ip daddr 192.168.0.0/24 accept # 'ip filter' is assumed # same command, slightly more verbose nft add rule ip filter output ip daddr 192.168.0.0/24 accept
delete rule from inet table.
# nft -a list ruleset table inet filter { chain input { type filter hook input priority filter; policy accept; ct state established,related accept # handle 4 ip saddr 10.1.1.1 tcp dport ssh accept # handle 5 ... # delete the rule with handle 5 nft delete rule inet filter input handle 5
nftables offers two kinds of set concepts. Anonymous sets are sets that have no specific name. The set members are enclosed in curly braces, with commas to separate elements when creating the rule the set is used in. Once that rule is removed, the set is removed as well. They cannot be updated, i.e. once an anonymous set is declared it cannot be changed anymore except by removing/altering the rule that uses the anonymous set.
Using anonymous sets to accept particular subnets and ports.
nft add rule filter input ip saddr { 10.0.0.0/8, 192.168.0.0/16 } tcp dport { 22, 443 } accept
Named sets are sets that need to be defined first before they can be referenced in rules. Unlike anonymous sets, elements can be added to or removed from a named set at any time. Sets are referenced from rules using an @ prefixed to the sets name.
Using named sets to accept addresses and ports.
nft add rule filter input ip saddr @allowed_hosts tcp dport @allowed_ports accept
The sets allowed_hosts and allowed_ports need to be created first. The next section describes nft set syntax in more detail.
add set [family] table set { type type | typeof expression ; [flags flags ;] [timeout timeout ;] [gc-interval gc-interval ;] [elements = { element[, ...] } ;] [size size ;] [comment comment ;] [policy 'policy ;] [auto-merge ;] } {delete | list | flush} set [family] table set list sets [family] delete set [family] table handle handle {add | delete} element [family] table set { element[, ...] }
Sets are element containers of a user-defined data type, they are uniquely identified by a user-defined name and attached to tables. Their behaviour can be tuned with the flags that can be specified at set creation time.
add      Add a new set in the specified table. See the Set specification table below for more information about how to specify properties of a set.
delete   Delete the specified set.
list     Display the elements in the specified set.
flush    Remove all elements from the specified set.
add map [family] table map { type type | typeof expression [flags flags ;] [elements = { element[, ...] } ;] [size size ;] [comment comment ;] [policy 'policy ;] } {delete | list | flush} map [family] table map list maps [family]
Maps store data based on some specific key used as input. They are uniquely identified by a user-defined name and attached to tables.
add              Add a new map in the specified table.
delete           Delete the specified map.
list             Display the elements in the specified map.
flush            Remove all elements from the specified map.
add element      Comma-separated list of elements to add into the specified map.
delete element   Comma-separated list of element keys to delete from the specified map.
Table 9. Map specifications ┌─────────┬─────────────────────┬──────────────────────┐ │Keyword  │ Description         │ Type                 │ ├─────────┼─────────────────────┼──────────────────────┤ │         │                     │                      │ │type     │ data type of map    │ string: ipv4_addr,   │ │         │ elements            │ ipv6_addr,           │ │         │                     │ ether_addr,          │ │         │                     │ inet_proto,          │ │         │                     │ inet_service, mark,  │ │         │                     │ counter, quota.      │ │         │                     │ Counter and quota    │ │         │                     │ can’t be used as     │ │         │                     │ keys                 │ ├─────────┼─────────────────────┼──────────────────────┤ │         │                     │                      │ │typeof   │ data type of set    │ expression to derive │ │         │ element             │ the data type from   │ ├─────────┼─────────────────────┼──────────────────────┤ │         │                     │                      │ │flags    │ map flags           │ string: constant,    │ │         │                     │ interval             │ ├─────────┼─────────────────────┼──────────────────────┤ │         │                     │                      │ │elements │ elements contained  │ map data type        │ │         │ by the map          │                      │ ├─────────┼─────────────────────┼──────────────────────┤ │         │                     │                      │ │size     │ maximum number of   │ unsigned integer (64 │ │         │ elements in the map │ bit)                 │ ├─────────┼─────────────────────┼──────────────────────┤ │         │                     │                      │ │policy   │ map policy          │ string: performance  │ │         │                     │ [default], memory    │ └─────────┴─────────────────────┴──────────────────────┘
{add | create | delete | get } element [family] table set { ELEMENT[, ...] }
ELEMENT := key_expression OPTIONS [: value_expression] OPTIONS := [timeout TIMESPEC] [expires TIMESPEC] [comment string] TIMESPEC := [numd][numh][numm][num[s]]
Element-related commands allow to change contents of named sets and maps. key_expression is typically a value matching the set type. value_expression is not allowed in sets but mandatory when adding to maps, where it matches the data part in its type definition. When deleting from maps, it may be specified but is optional as key_expression uniquely identifies the element.
create command is similar to add with the exception that none of the listed elements may already exist.
get command is useful to check if an element is contained in a set which may be non-trivial in very large and/or interval sets. In the latter case, the containing interval is returned instead of just the element itself.
Table 10. Element options ┌────────┬─────────────────────────────┐ │Option  │ Description                 │ ├────────┼─────────────────────────────┤ │        │                             │ │timeout │ timeout value for sets/maps │ │        │ with flag timeout           │ ├────────┼─────────────────────────────┤ │        │                             │ │expires │ the time until given        │ │        │ element expires, useful for │ │        │ ruleset replication only    │ ├────────┼─────────────────────────────┤ │        │                             │ │comment │ per element comment field   │ └────────┴─────────────────────────────┘
{add | create} flowtable [family] table flowtable { hook hook priority priority ; devices = { device[, ...] } ; } list flowtables [family] {delete | list} flowtable [family] table flowtable delete flowtable [family] table handle handle
Flowtables allow you to accelerate packet forwarding in software. Flowtables entries are represented through a tuple that is composed of the input interface, source and destination address, source and destination port; and layer 3/4 protocols. Each entry also caches the destination interface and the gateway address - to update the destination link-layer address - to forward packets. The ttl and hoplimit fields are also decremented. Hence, flowtables provides an alternative path that allow packets to bypass the classic forwarding path. Flowtables reside in the ingress hook that is located before the prerouting hook. You can select which flows you want to offload through the flow expression from the forward chain. Flowtables are identified by their address family and their name. The address family must be one of ip, ip6, or inet. The inet address family is a dummy family which is used to create hybrid IPv4/IPv6 tables. When no address family is specified, ip is used by default.
The priority can be a signed integer or filter which stands for 0. Addition and subtraction can be used to set relative priority, e.g. filter + 5 equals to 5.
add      Add a new flowtable for the given family with the given name.
delete   Delete the specified flowtable.
list     List all flowtables.
list { secmarks | synproxys | flow tables | meters | hooks } [family] list { secmarks | synproxys | flow tables | meters | hooks } table [family] table list ct { timeout | expectation | helper | helpers } table [family] table
Inspect configured objects. list hooks shows the full hook pipeline, including those registered by kernel modules, such as nf_conntrack.
{add | delete | list | reset} type [family] table object delete type [family] table handle handle list counters [family] list quotas [family] list limits [family]
Stateful objects are attached to tables and are identified by a unique name. They group stateful information from rules, to reference them in rules the keywords "type name" are used e.g. "counter name".
add      Add a new stateful object in the specified table.
delete   Delete the specified object.
list     Display stateful information the object holds.
reset    List-and-reset stateful object.
CT HELPER add ct helper [family] table name { type type protocol protocol ; [l3proto family ;] } delete ct helper [family] table name list ct helpers