Additional user accounts can be allowed access to the system in the
configuration. Each user is represented by a user section
within the users section. The user section must
contain a role item with a value admin or
audit. The admin class has full access
to the system and permissions to configure and operate all Kernun UTM components.
The audit class can only view the system configuration and
logs. The user section can also contain a
ssh-key item, which generates a corresponding line in the
.ssh/authorized_keys file for the user's ssh key.
The Kernun UTM configuration can hold any number of
interface sections that correspond to a physical
device. Virtual network interfaces can be created from other tools
than Kernun UTM configuration utilities; these, however, need to be referenced in
the Kernun UTM configuration. For example, an instance of openvpn
creates the tun0 interface when started. To be able to
use it in the Kernun UTM configuration, include the virtual parameter
in its dev item (as illustrated in the interface
VPN-PRAHA section in Figure 5.12, “Network Interfaces”).
Such an interface is not generated in the rc.conf
file.
An interface can be assigned multiple IP addresses.
To do so, add an arbitrary number of alias sections
to the interface section. Each of them
must contain an ipv4 item that defines its IPv4 address,
as depicted in Figure 5.12, “Network Interfaces” in
interface EXT.
See interface(5) for details.
Static routes provide the capability to explicitly route packets
for a given network to a static machine, which works as a gateway for
this network when this cannot be done automatically by
the system routing table management daemon (such as
routed). See
route(8) for further info.
A static route is set by a static section in
the routes section. The static section
must contain one dest item — the routed network
address — and a gw item — the address of
the gateway machine for the routed network.
Kernun UTM supports dynamic IP routing via BIRD's (The BIRD Internet Routing Daemon) implementation of OSPF (Open Shortest Path First) protocol. It allows routers to automatically change routes, so that the path remain functional in case of failure of an router in the path.
BIRD uses separate configuration for IPv4 and IPv6. In the
example below, bird4 defines rules for IPv4 routing of
one Kernun UTM in the role of router. This router would be one of multiple
routers in network, either Kernun UTM or any other device that supports
OSPF. For example, two clusters of Kernun UTM with all nodes connected with
each other via VPN.
BIRD, or more precisely OSPF, requires each router to be
identified by an unique ID. use-id in the example
above, uses IPv4 address of interface INT as this ID. The sections
device, kernel,
static and ospf defines different
protocols (or pseudo-protocols) which BIRD should use for import or
export of routes. The device protocol is not a real
routing protocol. It doesn't generate any routes and it only serves as
a module for getting information about network interfaces from the
kernel. Except for very unusual circumstances, you probably should
include this protocol in the configuration since almost all other
protocols require network interfaces to be defined for them to work
with. The kernel is also a pseudo-protocol. Instead of
communicating with other routers in the network, it performs
synchronization of BIRD's routing tables with the OS kernel.
Basically, it sends all routing table updates to the kernel and from
time to time (item scan) it scans the kernel tables to
see whether some routes have disappeared or whether a new route has
been added by someone else. The section static
analogically sets rules for static routes defined in
system → routes →
static.
The ospf section defines, besides import/export
rules, one or more areas (area). In OSPF, the network
is divided into areas that are logical groupings of hosts and networks.
Each area maintains a separate link state database whose information
may be summarized towards the rest of the network by the connecting
router. Thus, the topology of an area is unknown outside of the area.
This reduces the routing traffic between parts of an autonomous system.
An area is identified by it's id. "O" in this example,
identifies backbone area (or area 0.0.0.0) which forms the core of an
OSPF network. In interface sections we assign
different properties for selected network interfaces. Especially, the
cost item. The OSPF routing policies for constructing
a route table are governed by link cost factors associated with each
routing interface. Cost factors may be the distance of a router
(round-trip time), data throughput of a link, or link availability and
reliability, expressed as simple unitless numbers. Other items defines
different rules for communication with other routers via given network
interface.
For more information on BIRD configuration see http://bird.network.cz/?get_doc&f=bird-3.html
The /etc/rc.conf configuration file is
used to automatically perform various actions at the system startup. It
contains information about the configuration of network interfaces, the
services that should be started after a boot and optionally their parameters,
the configuration of the machine's host name, console settings, etc.
See rc.conf(5) for details.
The rc.conf file is generated by Kernun UTM and
should therefore not be configured directly, but in
rc-conf section of the Kernun UTM configuration. An entry in
rc.conf is set through the set-env
item. Examples of useful items include set-env fsck_y_enable yes
(which will make fsck answer itself "YES" to all
questions and thus make automatic OS booting possible).
It is even possible to extend an already set value by redefinition,
such as set-env variable "$variable ...".
The /etc/sysctl.conf file is read when the OS
enters the multi-user mode and sets default settings for the kernel. Its
contents are generated from the variables items in the
syctl section. Each variable sets
one kernel setting. For example, variable
net.inet.ip.forwarding "1" turns on IP forwarding.
The crontab is the configuration file for
the cron daemon, which runs selected commands
periodically. Each entry in crontab contains
seven fields separated by a white space character:
minute — permitted values: 0-59
hour — permitted values: 0-23
day of month — permitted values: 1-31
month — permitted values: 1-12 (or names)
week — permitted values: 0-7 (0 or 7 is Sun, or use names)
user — user under whom the program should be run
command — the command to be run and its parameters
A field may be set to "*", which stands for its entire range. Numerical ranges, lists and their combinations are also allowed. For example, "3-7", "1,2,7,8", "1-3,8-14,20". Step values and more complex expressions can be used as well, see crontab(5) for details.
There is a sample crontab configuration in
samples/include/crontab.cml. It can be included
in crontab by the application of the
$default-crontab variable, which is set in
include samples/include/crontab.cml.
Additional entries can be set by plan items
in the crontab section. For example plan
"1 2 * * * root
/usr/local/kernun/bin/upgradeFBSD.sh" will schedule
the script upgradeFBSD.sh (which automatically
synchronizes and compiles the OS source) to be run every day at 02:01 under
the user root.