2. System Configuration

2.1. User Accounts

Figure 5.11. User account configuration

User account configuration

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.

2.2. Network Interfaces

Figure 5.12. Network Interfaces

Network Interfaces

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.

2.3. Static Routes

Figure 5.13. Static Routes

Static Routes

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.

2.4. Dynamic IP routing with BIRD

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.

Figure 5.14. BIRD dynamic routing

BIRD dynamic routing

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 systemroutesstatic.

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

2.5. File /etc/rc.conf

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.

Figure 5.15. rc.conf configuration

rc.conf configuration

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 ...".

2.6. Kernel Parameters in /etc/sysctl.conf

Figure 5.16. sysctl.conf configuration

sysctl.conf configuration

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.

2.7. Configuration of the cron Daemon

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.

Figure 5.17. crontab configuration

crontab configuration

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.