Applies to: KNA, KMA, KVPNA, KOA, KWA, KBA
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 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 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 configuration utilities; these, however, need to be referenced in
the Kernun configuration. For example, an instance of openvpn
creates the tun0 interface when started. To be able to
use it in the Kernun configuration, include the virtual parameter
in its dev item (as illustrated in the interface
VPN-PRAHA section in Figure 6.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 6.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.
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 and
should therefore not be configured directly, but in
rc-conf section of the Kernun 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.