aa47e05ae4
Conceptually equivalent to networking by means of slirp4netns(1), with a few practical differences: - pasta(1) forks to background once networking is configured in the namespace and quits on its own once the namespace is deleted: file descriptor synchronisation and PID tracking are not needed - port forwarding is configured via command line options at start-up, instead of an API socket: this is taken care of right away as we're about to start pasta - there's no need for further selection of port forwarding modes: pasta behaves similarly to containers-rootlessport for local binds (splice() instead of read()/write() pairs, without L2-L4 translation), and keeps the original source address for non-local connections like slirp4netns does - IPv6 is not an experimental feature, and enabled by default. IPv6 port forwarding is supported - by default, addresses and routes are copied from the host, that is, container users will see the same IP address and routes as if they were in the init namespace context. The interface name is also sourced from the host upstream interface with the first default route in the routing table. This is also configurable as documented - sandboxing and seccomp(2) policies cannot be disabled - only rootless mode is supported. See https://passt.top for more details about pasta. Also add a link to the maintained build of pasta(1) manual as valid in the man page cross-reference checks: that's where the man page for the latest build actually is -- it's not on Github and it doesn't match any existing pattern, so add it explicitly. Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Common Man Page Options
This subdirectory contains option (flag) names and descriptions
common to multiple podman man pages. Each file is one option. The
filename does not necessarily need to be identical to the option
name: for instance, hostname.container.md and hostname.pod.md
exist because the --hostname option is sufficiently different
between podman-{create,run} and podman-pod-{create,run} to
warrant living separately.
How
The files here are included in podman-*.md.in files using the @@option
mechanism:
@@option foo ! will include options/foo.md
The tool that does this is hack/markdown-preprocess. It is a python
script because it needs to run on readthedocs.io. From a given .md.in
file, this script will create a .md file that can then be read by
go-md2man, sphinx, anything that groks markdown. This runs as
part of make docs.
Special Substitutions
Some options are almost identical except for 'pod' vs 'container'
differences. For those, use <<text for pods|text for containers>>.
Order is immaterial: the important thing is the presence of the
string "pod" in one half but not the other. The correct string
will be chosen based on the filename: if the file contains -pod,
such as podman-pod-create, the string with pod (case-insensitive)
in it will be chosen.
The string <<subcommand>> will be replaced with the podman subcommand
as determined from the filename, e.g., create for podman-create.1.md.in.
This allows the shared use of examples in the option file:
Example: podman <<subcommand>> --foo --bar
As a special case, podman-pod-X becomes just X (the "pod" is removed).
This makes the pod-id-file man page more useful. To get the full
subcommand including 'pod', use <<fullsubcommand>>.