Alpine Wall User's Guide: Difference between revisions

From Alpine Linux
(Service objects explained)
m (Remove cat and add request for deletion.)
 
(63 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== Configuration File Processing ==
{{Delete|All wikilinks on the entire wiki have already been changed to point to the awall guide on git. Nothing points to this article, nor should it}}


[[Alpine Wall]] (awall) reads its configuration from multiple
The current Alpine Wall User's Guide is available [https://git.alpinelinux.org/awall/about/ here].
JSON-formatted files, called ''policy files''. The processing starts
from directory <tt>/usr/share/awall/mandatory</tt>, which contains
mandatory policy files shipped with APK packages. After that,
installation-specific policy files in <tt>/etc/awall</tt> are
processed.
 
The latter directory may also contain symbolic links to policy files
located in <tt>/usr/share/awall/optional</tt>. These are optional
policies, which can be enabled on need basis. Such symbolic links are
easily created and destroyed using the <tt>awall --enable</tt> and
<tt>awall --disable</tt> commands. <tt>awall --list</tt> shows which
optional policies are enabled and disabled.
 
Sometimes a policy file depends on other policy files. In this case,
the policy file must have a top-level attribute <tt>import</tt>, the
value of which is a list of policy names, which correspond to the file
names without the <tt>.json</tt> suffix. The policies listed there are
always processed before the importing policy. The order of the
generated iptables rules generally reflects the processing order of
their corresponding awall policies.
 
As the import directive does not require the path name to be
specified, awall expects policies to have unique names, even if
located in different directories. It is allowed to import optional
policies that are not explicitly enabled by the user. Such policies
show up with the <tt>required</tt> status in the output of <tt>awall
--list</tt>.
 
== List Parameters ==
 
Several awall parameters are defined as lists of values. In order to
facilitate manual editing of policy files, awall also accepts single
values in place of lists. Such values are semantically equivalent to
lists containing one element.
 
== Variable Expansion ==
 
Awall allows variable definitions in policy files. The top-level
attribute <tt>variable</tt> is a dictionary containing the
definitions. The value of a variable can be of any type (string,
integer, list, or dictionary).
 
A variable is referenced in policy files by a string which equals the
variable name prepended with the <tt>$</tt> character. If the value of
the variable is a string, the reference can be embedded into a longer
string in order to substitute some part of that string (in shell
style). Variable references can be used when defining other variables,
as long as the definitions are not circular.
 
Policy files can reference variables defined in other policy
files. Policy files can also override variables defined elsewhere by
redefining them. In this case, the new definition affects all policy
files, also those processed before the overriding policy. Awall
variables are in fact simple macros, since each variable remains
constant thoughout a single processing round. If multiple files define
the same variable, the definition in the file processed last takes
effect.
 
If defined as an empty string, all non-embedded references to a
variable evaluate as if the attribute in question was not present in
the configuration. This is also the case when a string containing
embedded variable references finally evaluates to an empty string.
 
== Configuration Objects ==
 
Configuration objects can be divided into two main types.
''Auxiliary objects'' model high-level concepts such as services and
zones. ''Rule objects'' translate into one or more iptables rules, and
are often defined with the help of some auxiliary objects.
 
=== Services ===
 
A ''service'' represents a set of network protocols. A top-level
attribute <tt>service</tt> is a dictionary that maps service names to
lists of service definition objects. A service definition object
contains an attribute named <tt>proto</tt>, which corresponds to the
<tt>--protocol</tt> option of iptables. The protocol can be defined as
a numerical value or string as defined in <tt>/etc/protocols</tt>.
 
If the protocol is <tt>tcp</tt> or <tt>udp</tt>, the scope of the
service definition may be constrained by defining an attribute named
<tt>port</tt>, which is a list of TCP or UDP port numbers.
 
If the protocol is <tt>icmp</tt> or <tt>icmpv6</tt>, an analogous
<tt>icmp-type</tt> attribute may be used. In addition, the scope of
the rule is also automatically limited to IPv4 or IPv6, respectively.
 
=== Zones ===
 
=== Rules ===
 
==== Filters ====
 
==== NAT Rules ====
 
=== IP Sets ===
 
== Command Line Syntax ==
 
=== Generating iptables and ipset Files ===
 
=== Activating New Configuration ===
 
=== Optional Policies ===

Latest revision as of 17:59, 21 January 2024

This material is proposed for deletion ...

All wikilinks on the entire wiki have already been changed to point to the awall guide on git. Nothing points to this article, nor should it (Discuss)
Make sure no other pages link here and check the page's history before deleting.

The current Alpine Wall User's Guide is available here.