Table of Contents
isds.cmlList of Figures
system-level definitionsHTTPS and SSHSMTP Proxy System Sections and Forward AgentSMTP Proxy ACLsSMTP Proxy Mail FilterSMTP Proxy Mail Sever in the Internal
NetworkIMAP4 ProxyPOP3 Proxyreturnblock-policy instead of return in rulerc.conf configurationsysctl.conf configurationcrontab configurationhttp-proxy log
(the log was filtered, in order to save space).
source-address client)
sip-proxy configured to listen transparently on a port range 5060-5062
SIP ProxySQL*Net Proxysystemhttp-proxyapply-host is used to distinguish
the local system from the remote oneCLUSTER definitionCLUSTER to define two nodesmonitor binds cluster interfaces togetherThe documentation of Kernun consists of several parts; all of them are
available in the electronic form. The complete documentation is installed
with the software in the directories
/usr/local/kernun/doc and
/usr/local/kernun/man, so it is always available on
any Kernun system. The documentation is also contained in the
doc directory on the installation CD and is therefore
accessible also before the installation. The Kernun documentation is available in
the following formats:
Only several short documents that should be read before the installation of Kernun are available as plain text files:
KERNUN-CHANGES.txtList of changes between individual versions of Kernun.
KERNUN-INSTALL.txtShort installation instructions. This file basically refers to Chapter 3, Kernun System Management in the Kernun Handbook.
KERNUN-RELNOTES.txtRelease notes; various notices concerning the installation, configuration, and use of Kernun.
The Kernun Handbook, that is, this document. The PDF version of the handbook contains also the reference pages except for section 6. This format is suitable for printing and reading as a book, basically from the beginning to the end.
The Kernun Handbook. The HTML version of the handbook contains also all the reference pages. It is available either as a single very long HTML file, or broken into many smaller HTML files. This format is suitable as a reference, with the possibility of hypertext navigation between its parts.
The reference part of the documentation is available also in the form of the standard manual pages that can be viewed using the man(1) command. The manual pages are categorized into sections, similarly as the system manual pages. Kernun uses the following manual page sections:
User commands, mainly various tools for runtime monitoring and generation of statistics.
Configuration. Individual sections of the
/usr/local/kernun/conf/kernun.cml
configuration file are documented in this
section.
For each log message, except for the debugging ones, there is a manual page that describes the conditions, under which the message is logged, and the possible consequences of its appearance in the Kernun log. The manual pages' names are the IDs of the corresponding messages.
The manual pages in this section explain general concepts. They cover features that are common to many parts of Kernun, such as proxies.
Administrative commands, including application proxies and configuration management tools.
If you are looking for the description of a Kernun feature, you can find its explanation in Section 8 (if it is a separate program), or in Section 7 (if it is a part of a program). If the feature is configurable, its configuration is defined in detail in Section 5. The corresponding manual pages in Section 5 and Section 7 or 8 often have the same name; they are distinguished only by the section number.
This Handbook will help you learn how to administer Kernun. An overview of individual products from the Kernun family is given in Chapter 1, Kernun Product Overview, whereas Chapter 2, Kernun Hardware describes the hardware that Kernun comes installed on. The first steps and the installation instructions are provided in Chapter 3, Kernun System Management. For the first time, it suffices to read only the sections needed for the initial installation (Section 3, “Licensing”, Section 5.1, “Standalone Installer”, and Section 5.2, “Initial Configuration”). Reading of the remaining parts of the chapter can be postponed until you need to know more about alternative installation methods, upgrades, backups, or disk layout. If you already have a preinstalled and licensed instance of Kernun, you can skip Chapter 3, Kernun System Management altogether. Chapter 4, User Interface contains an introduction to the graphical and command line administrative interface. Beginners will probably find the GUI (Section 1, “Graphical User Interface”) to be the easiest way of controlling Kernun. If, for any reason, you cannot (or do not want to) use the graphical interface, you find the information about the command line tools in Section 2, “Command Line Interface” and Section 3, “Administrative Utilities”. If you know how to connect to a running Kernun system, monitor and control its operation, view logs, and edit the configuration, you may learn principles of the Kernun configuration and find an explanation of the initial configuration generated during the installation in Chapter 5, Configuration Basics. Chapter 6, Advanced features deals with configuration of advanced features . At any time, details about features, commands, configuration syntax and semantics, as well as the meaning of log messages can be found in the reference pages, which are contained in the Appendix of this Handbook and available also in the form of manual pages.
Table of Contents
The Kernun family consists of several products that are each useful for a specific set of network security tasks. We will provide a brief introduction to each of them now. As individual Kernun products contain different subsets of features, not all parts of the configuration are applicable to each of them. The configuration of Kernun is explained in Chapter 5, Configuration Basics and Chapter 6, Advanced features of this handbook. Individual subsections of those chapters specify the Kernun products they are related to.
Kernun Net Access is a new type of a UTM secure device that contains multiple features, such as firewall, antivirus, antispam, antispyware, content filtering, intrusion detection (IDS or IPS), routing, QoS or VPN, in a single package. It has been designed to protect private data networks and DMZ segments (demilitarized zones, including servers with public services, for example WWW, FTP, mail servers, secure remote VPN connection, etc.). It provides antivirus and antispam protection, as well as an ability to block unsuitable protocols (Skype, ICQ, etc.) and unsuitable Web pages.
Kernun Net Access is highly flexible during the process of secure policy implementation. This includes simple rules of status inspection, as well as sophisticated management on the level of application protocols. Thanks to its ability to inspect the contents of each application protocol, this technology is the ideal solution for environments with high security demands.
A typical implementation of the Kernun Net Access technology is located on the perimeter of the protected network as a gateway between the Internet and the internal network. All connections to and from the Internet are authorized or prohibited at a central location. Kernun Net Access also serves as an antivirus and antispam gateway, and as a server, where VPN connections for clients who work from home or while travelling and of VPN tunnels between branches are terminated. Public service network servers (DMZ) are usually located on another network interface.
Kernun Mail Access is an appliance that provides security for e-mail correspondence. It contains antivirus and antispam filters and a secure system for protocols, such as SMTP, POP3 and IMAP4. An optional extension contains a fully functional e-mail server with mailboxes and shared electronic calendars.
The technology offers a complex e-mail correspondence and electronic calendar solution for the entire company. It contains tools that ensure inspection and protection of the application protocols SMTP, POP3 and IMAP4, antispam and antimalware inspection, access via a Web interface and synchronization support for mobile devices (ActiveSync). Kernun Mail Access can handle all electronic communication needs of the entire company.
A typical implementation of the Kernun Mail Access technology is maintained inside the internal company network or within the DMZ network. All e-mail correspondence is directed to this server. Clients have Kernun Mail Access set as their SMTP/POP3/IMAP4/MAPI server. All incoming and outgoing mail is subject to thorough inspections in the corresponding proxy applications.
Kernun VPN Access is an appliance, in which you can create secure and encoded tunnels between branches. It may also be used by travelling clients to access their private network remotely. It contains a firewall and it is compatible with all devices compliant with the IPSec and OpenVPN standards.
The Kernun VPN Access technology provides secure interconnection of geographically distant computer networks. This interconnection creates a robust Virtual Private Network, within which each user may share all documents, databases, disk space and other resources, regardless of where the data is physically stored. This solution is absolutely transparent and offers many advantages to all end users.
Kernun VPN Access also enables users to access the internal network securely from a given computer; this is appreciated especially by managers and travelling employees. Electronic mail, databases, files, printers, and other sources included in the internal network will be available to you from anywhere. All you need is a portable computer and connection to the Internet; Kernun VPN Access takes care of everything else.
Kernun VPN Access supports many popular protocols used when creating private networks, such as IPSec, OpenVPN (SSL-based VPN) and PPTP, making it possible to get connected under any operating system.
In a typical scenario, Kernun VPN Access is deployed either on the perimeter of the internal network, or in the DMZ. All VPN tunnels and end-user connections are terminated in it.
Kernun Office Access is a high-performance appliance designed for protection of inner segments of private networks, typically in cases when high data throughput is required. This is realized using special hardware and a specific system configuration. This technology is suitable for management of communication between networks that requires extremely high data throughput, usually up to 1 Gb or more.
For example, this technology may protect the segments of a database farm that serves huge amounts of data for a front-end WWW system. Due to security reasons, this system is separated and placed on another network segment. Kernun Office Access ensures high availability between the front-end system and the database farm and, at the same time, manages the operations and protection of the database farm.
Kernun Web Access is a security-oriented application designed to protect Web servers. It is placed in front of the server and detects hacker attacks before they can reach the server itself. It also provides visualisation of Web visit frequencies and includes an optional module for load balancing (distribution of load among several real Web servers).
In addition to the communication comparison process with a set of samples of known data flows and its normalization, the system offers basic protection tools against Denial-of-Service (DoS) attacks. In this case, the attacker attempts to overload the server with a huge amount of requests that seem to be legitimate. Kernun Web Access uses sophisticated algorithms to control the increase in the number of connections coming from each client and thus eliminate many DoS attacks.
Kernun Web Access protects Web servers from attacks performed by means of the HTTP protocol, which is used for Web page and application transfers. The technology detects known attack attempts, including i.a. SQL injection and PHP injection attacks. It also normalizes communication between the Web browser and server and filters out non-standard or otherwise incorrect requests.
Web servers that do not support encryption using the TLS protocol can also be protected by Kernun Web Access. The Web server may still answer without encryption, but Kernun Web Access adds a secure encrypted envelope to the communication. Using Kernun Web Access, you can design and deploy authenticated access to certain Web pages on the protected server to a limited group of users (supported authentication methods include X.509 certificates, authentication tokens and plain passwords).
Kernun Web Access is placed in the hosting centre. The protected Web server is not directly connected to the Internet, but instead, it communicates with the outside world through the Kernun Web Access technology. This security device controls the Web server's entire communication, normalizes it, and enables standard anonymous access to the Web server, as well as content management and administration to privileged users.
The Kernun software features are internally grouped into so-called components, which must be individually licensed in order to work properly. The following table provides a summary of the Kernun components that are included (i.e., licensed) with individual Kernun products.
| KNA | KMA | KVPNA | KOA | KWA | ||
| dns-proxy | Yes | No | No | Yes | Yes | No |
| ftp-proxy | Yes | No | No | Yes | Yes | No |
| gk-proxy | Yes | No | No | Yes | No | No |
| h323-proxy | Yes | No | No | Yes | No | No |
| http-proxy | Yes | No | No | Yes | Yes | No |
| imap4-proxy | Yes | Yes | No | Yes | No | No |
| pop3-proxy | Yes | Yes | No | Yes | No | No |
| sip-proxy | Yes | No | No | Yes | No | No |
| smtp-proxy | Yes | Yes | No | Yes | Yes | No |
| sqlnet-proxy | Yes | No | No | Yes | Yes | No |
| tcp-proxy | Yes | No | No | Yes | Yes | No |
| udp-proxy | Yes | No | No | Yes | Yes | No |
| mod-antivirus | Optional | Yes | No | No | Optional | No |
| mod-antispam | Optional | Yes | No | No | No | No |
| mod-pwf | Optional | No | No | No | No | No |
| mod-ids-ips | Optional | No | No | Yes | Yes | No |
| mod-vpn | Yes | No | Yes | No | Yes | Yes |
| packet-filter | Yes | Yes | Yes | Yes | Yes | Yes |
| mod-reporter | Optional | Optional | Optional | No | Optional | No |
| mod-cluster | Optional | Optional | Optional | Optional | Optional | No |
The Kernun products are shipped as hardware appliances. For description of the Kernun hardware, see Chapter 2, Kernun Hardware.
The Kernun products are shipped as hardware appliances. The Kernun hardware comes in the following variants: SOHO, Pro, Enterprise and Enterprise Plus.
Not all combinations of Kernun products and hardware are eligible. For instance, Kernun Mail Access is available in the SOHO and Enterprise variants. For more information, see the following table, which lists the valid combinations.
| SOHO | Pro | Enterprise | Enterprise Plus | ||
| Kernun Net Access | No | Yes | Yes | Yes | Yes |
| Kernun Mail Access | No | Yes | No | Yes | No |
| Kernun VPN Access | No | Yes | No | Yes | No |
| Kernun Office Access | No | Yes | No | Yes | No |
| Kernun Web Access | No | Yes | No | Yes | No |
The individual hardware variants are briefly characterized as follows:
The basic 1U rack server hardware with low profile (low depth), low performance, no management and no redundancy options. Recommended for networks with up to 50 users and a 10-Mbps or slower upstream line.
An advanced 1U rack server with full depth, advanced performance, a management option and no redundancy options. It is suitable for networks with up to 150 users, connected with a 50-Mbps line at the most.
A high-performance 2U rack server, featuring all the available management and redundancy options. This variant is designed for networks with up to 500 users and a 500-Mbps upstream line.
An even better-performing 2U rack server hardware, again with all the available management and redundancy options. Designed for very demanding users, it fits into environments with hundreds or thousands of users and a 1-Gbps connection to the outside world.
The following table gives a summary of the parameters of individual hardware variants:
| SOHO | Pro | Enterprise | Enterprise Plus | ||
| Rack chassis | N/A | 1U | 1U | 2U | 2U |
| Height (cm) | 3.00 | 4.26 | 4.24 | 8.64 | 8.64 |
| Width (cm) | 29.00 | 44.70 | 42.63 | 44.43 | 44.43 |
| Depth (cm) | 17.00 | 38.70 | 66.04 | 74.40 | 74.40 |
| Weight (kg) | 0.9 | 10.5 | 13.45 | 23.00 | 23.00 |
| Processor freq. | 500 MHz | 2.0 GHz | 1.86 GHz | 2.0 GHz | 3.0 GHz |
| Processor model | single/32bit | single/64bit | dual/64bit | quad/64bit | quad/64bit |
| Memory | 512 MB | 1 GB | 2 GB | 4 GB | 8 GB |
| Disk size | 2 GB | 160 GB | 250 GB | 300 GB | 600 GB |
| Disk model | CF card | SATA | SATA | SAS | SAS |
| Hot-plug disks | No | No | No | Yes | Yes |
| RAID | N/A | N/A | N/A | RAID 1 | RAID 10 |
| Power supply | 24 W | 400 W | 400 W | 750 W | 750 W |
| Hot-plug power | No | No | No | Yes | Yes |
| Power redundancy | No | No | No | Yes | Yes |
| Max eth. ports | 8 | 4 | 6 | 14 | 14 |
| HW encr. accelerator | Optional | No | No | Optional | Optional |
| Remote mgmt | No | No | Yes | Yes | Yes |
Table of Contents
In this chapter, we explain how to create and manage a Kernun installation. The system management tasks include installation, upgrade, system backup and restore. An auditing tool can be used to receive notification of discovered bugs and available new software updates. We also provide information about the use of license files and installation of up to three independent Kernun versions on a single computer.
Kernun uses (slightly modified) FreeBSD as its underlying operating system. Although experience with FreeBSD or another operating system based on Unix would certainly be beneficial when performing advanced administrative tasks, it is not required. Kernun provides its own set of powerful tools for installation, configuration, and monitoring of operation.
Each Kernun release is distributed using the following types of distribution media:
A bootable CD that contains the installation tools and the full installation image.
An ISO image with the same content as the above-mentioned CD.
An installable image of the Kernun system partition. It can be installed either using the installer booted from the installation CD, or from a running Kernun system using the Kernun GUI or the sysmgr(8) command line tool. Each full image is uniquely identified by its build number.
A patch image contains only the differences between two versions of Kernun, and is therefore much smaller than the full image. Patch images are usually created for maintenance updates. Their sole purpose is to optimize the amount of data that needs to be downloaded in order to update a Kernun installation to the current version. The result of installation is the same, no matter whether the full image or a patch image is used; the only difference is in the size of the image. A patch image is identified by its build number and by the build number of its base image.
Kernun releases are identified by version and build numbers.
The version number denotes the source code version of the
Kernun software (the operating system, application proxies, administrative
tools, preinstalled third-party software packages, etc.). The format of
the version number is either 3.0 for releases
(containing new features), or 3.0.1 for patch
releases (containing bug corrections and minor improvements).
Some bug fixes are implemented using the fast development cycle and are
distributed as hotfix releases, numbered e.g.
3.0.1-h3.
The build number identifies the particular build,
i.e., a binary image that comprises the core Kernun software, the operating
system, and third-party software, such as antivirus scanners, system
monitoring tools, or administrative utilities. A build number contains the
version number (formatted without the dots and with a fixed number of digits),
the date and time when the image was created, and the hardware architecture.
Examples: 030000h00.200809241501.i386 or
030001h00.200810170823.amd64.
Kernun is able to use one or two disk devices. Each disk device is either a physical disk, or a logical disk provided by a hardware RAID. The disk space is divided into three system partitions, one data partition, and swap space. In single disk configurations, all four partitions and the swap space are located on the single disk. In configuration with two disks, the system partitions are on one disk, whereas the data partition and the swap space on the other.
Each system partition may contain a complete Kernun installation including the operating system, application proxies, administrative tools, and additional software. The data partition contains logs, statistics, installation images, and backups. The contents of the data partition are shared by all Kernun installations in the system partitions.
The use of three system partitions minimizes downtimes during reinstallations and upgrades. While the system started from one system partition is fully operational, it is possible to install another version in the second partition. Then the new version can be started by a simple reboot. It is always possible to revert to the old version if anything goes wrong with the new one. The next upgrade will be installed in the first partition while running the system from the second one. In this way, two system partitions can be alternated for subsequent upgrades. The third system partition can be used in a similar fashion, so that two previous versions are always available, or for an alternative installation, e.g. when testing a completely new configuration.
When a system partition is booted, it becomes the root file system.
The other system partitions can be mounted to the directories
/1, /2, and
/3. There are lines in /etc/fstab
prepared for this, but the partitions are not mounted automatically.
The data partition is always mounted as /data
automatically. It contains the following directories:
/data/backupSystem backups are stored here. They can be used for restoration or copied to another medium.
/data/distThis is where Kernun installation images are kept. During each installation, the installed image is stored here for future reuse.
/data/logThis directory contains log files. The log directory
/var/log from all system partitions is symlinked
here.
/data/rrdThis directory contains database files used to store system data for system performance monitoring, as well as graphs generated from this data.
/data/statisticsReports with detailed statistics of proxy operation are stored in this directory.
The standard disk space layout is created during the first installation of Kernun on a new computer. It can be re-created or modified using the installer booted from the installation CD, but such action deletes all data on the system and data disks.
It is strongly recommended not to modify the standard disk layout, as many parts of Kernun depend on it. You may add additional file systems and directories, but do not delete or move any file system or directory created by the Kernun installer.
Kernun requires a valid license file to operate properly. Without a license file, the software can be installed, the operating system runs allowing both local and remote administrator access, but no licensed component may be started. The licensed components include all application-level network proxies and some additional modules (for example, antivirus, antispam, and Web filter).
The license file is a cryptographically signed text file. It contains the following information:
The customer identification
An optional identifier used to distinguish different licenses of the same customer
A unique serial number
The license size (the permitted number of protected network devices)
A computer identifier, if the license is valid exclusively with particular hardware.
The expiration date, if the license is valid for a limited time.
(Only Kernun 3.3 and newer) The expiration date of upgrade subscription. Before this date, new features (components) added to Kernun will be automatically licensed if covered by the subscription. After this date, existing features will continue to work (until the optional license expiration date), but new features will not be licensed.
(Only Kernun 3.2 and older) The release version number, if the license is valid for a single Kernun release (e.g., 3.1) only. The license can be used on all patch releases and hotfixes of the licensed release (e.g, 3.1.2 or 3.1.1-h5), but not on other releases (e.g., 3.2).
The list of licensed components.
(Only Kernun 3.3 and newer) The list of licensed groups of components. Licenses are usually issued for groups of components. For example, there are groups corresponding to various Kernun products, such as Kernun Net Access or Kernun Kernun Mail Access. The use of component groups makes it possible to add new licensed components to users with active subscription without the need for a new license file.
(Only Kernun 3.3 and newer) Various parameters of the licensed components.
A cryptographic signature used to verify the integrity of the license.
License files from Kernun 3.0 are not valid for 3.1 and newer releases.
Licenses from Kernun 3.1 and 3.2 are recognized by Kernun 3.3 and newer.
The license file must be installed as
/usr/local/kernun/license.dat. The license file is
stored in the system partition and must therefore be reinstalled after
each installation or upgrade. The license file can be copied to
Kernun either from the command line using SCP, or at the
License tab of the GUI System
Manager.
The set of configurable components changes depending on the type
of the Kernun product and the set of licensed components. For example,
if the HTTP proxy is not licensed, it should not be configured. A
single configuration file may comprise configurations of many Kernun
systems with different products. In each configuration section related
to a single system (section system), the product can
and should be specified using the product item. The
product specification consists of the Kernun software type, the list of
licensed components, the list of licensed component groups, and the
upgrade subscription expiration value. The product specification should be
filled according to the contents of the license file present in the
configured system. When the configuration is verified,
a check is made that only components usable in the selected products
are configured. When the configuration is applied, it is checked that
the product specified in the configuration complies with the product
installed in the target Kernun system. At the time of writing of this
text, there are two product types available:
kernun — all Kernun products;
unspecified — the product type is not
specified and will not be checked when applying the
configuration.
The recognized names of licensed components and component groups are the same as in the license files. Components:
product-kernun, product-kernun-net-access,
product-kernun-mail-access, product-kernun-vpn-access,
product-kernun-office-access, product-kernun-web-access,
product-kernun-secure-box,
product-kernun-secure-box-retail — Kernun product
names;
dns-proxy, ftp-proxy, gk-proxy, h323-proxy, http-proxy,
imap4-proxy, pop3-proxy, sip-proxy, smtp-proxy, sqlnet-proxy,
tcp-proxy, udp-proxy — individual proxies;
icap-server — server for the ICAP
protocol;
mod-antivirus — module for communication
with an antivirus in proxies;
mod-antispam — module for spam checking
in mail proxies;
mod-pwf — module for communication with
an external Web filter in the HTTP proxy;
http-cookie — support for special handling
of security-related HTTP cookies, for example, various session ID
cookies;
mod-match, mod-match-replace — module for
matching and replacement of HTML form data.
Component groups:
kernun-net-access, kernun-mail-access, kernun-vpn-access,
kernun-office-access, kernun-web-access, kernun-secure-box,
kernun-secure-box-retail — individual Kernun products;
modules-data-scanning — modules for
security scanning of data, such as the antivirus module;
modules-secure-box — special modules for
the Kernun Secure Box products;
modules-web-filter — modules providing
URL-based categorization and filtration of WWW servers.
When the initial configuration file is created (see Section 5.2, “Initial Configuration”),
the product type is detected, the currently installed license file is
examined, and the system.product item is set
appropriately. Therefore, it is recommended to install the license
file during the installation of the system,
before the initial configuration script is executed. The license file
can be installed by the standalone installer, as described in Section 5.1, “Standalone Installer”. If the license file is not installed during
the generation of the initial configuration or if a new system is being
added to an already existing configuration, the product
item must be set manually.
If you set the product item manually, select the
correct product type and enter the list of licensed components, the list
of licensed component groups, and the upgrade subscription expiration date
according to your license file[1]. It is
also possible to include the samples/include/products.cml
file in the main
configuration file. This file contains definitions of variables
that can be used instead of the system.product item.
Some products may have optional components. Their respective
variables in samples/include/products.cml have
a parameter containing the list of licensed optional components. For
example, Kernun Net Access with the optional antivirus and antispam modules will be
specified as:
$PRODUCT-KERNUN-NET-ACCESS { mod-antivirus, mod-antispam };
Even if no optional components are licensed, the empty list must be written explicitly as the variable's parameter:
$PRODUCT-KERNUN-NET-ACCESS { };Variables for products without optional components do not have a parameter and are therefore written without the braces:
$PRODUCT-KERNUN-MAIL-ACCESS;
The Kernun boot manager is located on the system disk. It is installed
during the initialization of the system performed by the standalone
installer. The boot manager displays labels of up to three system
partitions and allows selection of the partition to boot from by pressing
F1, F2, or
F3.
F1 Kernun 3.0 2008/10/01 07:36 (030000h00.200809241501.i386) F2 Kernun 3.0 2008/10/18 05:21 (030000h00.200810170852.i386) F3 Kernun 3.0.1 2008/11/15 07:22 (030001h00.200811142135.i386) Default: F2
If no option is selected, the default one is chosen automatically after a timeout. The Kernun GUI or the command line bootmgr(8) utility can be used to change partition labels, enable and disable booting from individual partitions, and set whether the default boot partition is fixed, or is always changed to the last booted partition.
Anybody with physical access to the Kernun console may select a system partition to boot from, boot a different kernel or kernel modules, or boot to the single user mode and access the system without a password. If the system console is not physically secure, the following actions can be done to protect the system against unauthorized access:
Disable boot device selection in the BIOS (for example, by setting a BIOS password).
Enable only the desired system partition in the boot manager (using bootmgr(8)).
Add line “-n” to
/boot.config. This prevents interrupting the
boot process in the stages one and two.
#printf -- '-n\n' > /boot.config
Protect the loader with a password by adding a password line to
/boot/loader.conf. Make the file readable only
by root.
#echo 'password="SECRET"' >> /boot/loader.conf#chmod go-rw /boot/loader.conf
Force verification of the root password as a condition for
entering the single user mode. Locate the line beginning with
“console” in
/etc/ttys and change its last word to
“insecure”.
Kernun can be installed using either the standalone installer booted from the installation CD, or command line or GUI system management tools. The first installation on a new computer must be done using the standalone installer, which does not require an already installed Kernun with initialized system and data disks and is able to initialize the standard disk layout, as described in Section 2, “Disk Space Layout”. Once there is at least one working Kernun instance on the computer, further installations can by done from it using either the GUI, or the sysmgr command line tool. The standalone installer is able to install in any system partition. The GUI and command line installations cannot be performed in the system partition that contains the currently running Kernun instance.
Regardless of the installation method, the newly installed system partition is, by default, enabled in the boot manager and made the default selection for the next boot. The boot manager can be reconfigured using the GUI or the command line utility bootmgr(8).
The standalone installer is normally used only for the first installation on a new computer, after replacing a disk, or if disk repartitioning is needed. In other situations, installation using the GUI (Section 5.3, “Installation from the GUI”) or the command line (Section 5.4, “Installation from the Command Line”) is more comfortable.
To start the standalone installer, you need the Kernun installation CD. You may either obtain the physical CD, or burn the ISO image to an empty CD-R or CD-RW medium. Boot from the CD and following the boot loader and kernel messages, you will see the installer menu.
*** KERNUN INSTALLATION ***
Build 030000h00.200809241501.i386
1. Install Kernun
2. Check for existing Kernun installations
3. Restore backup
4. Start rescue shell
5. Mount Kernun file systems
6. Resize installer's in-memory temporary file system (current size 32m)
7. Halt
8. Power down
9. Reboot
0. Install license
Select action:
Press 1<Enter>. If the disk partitioning for
Kernun has already been done, the device names of the system and data disks are
displayed and the installer asks whether you want repartitioning.
Detected Kernun system disk ad0 Detected Kernun data disk ad0 Repartition disks (y/n)?
Reply n to skip disk
partitioning. If you reply y or if the disk
partitioning has not been done yet, the system and data disks are selected
and partitioned first:
Use file system journaling (y/n)? [y]<Enter>Detected disk devices: ad0 20480 MB ad1 40960 MB Kernun system disk (ad0 ad1) [ad0]:<Enter>System disk size is 20480 MB Kernun data disk (ad0 ad1) [ad0]:ad1Data disk size is 40960 MB
Always select a disk that the BIOS will be able to boot from as the system disk[2]. If there is only one disk device, the selection of devices will be skipped and the single device will be used as both the system disk and the data disk.
When the installer asks a question, it offers a default value
in brackets. Press <Enter> to
select the default value.
The installer then sets the partition sizes. Reasonable default
values are provided, so it usually suffices to accept them by pressing
<Enter>.
Memory size is 4096 MB System partition size in MB, min. 489 MB [5120]: Swap partition size in MB [8192]: Disk ad0 will contain 3 system partitions of size 5120 MB each Partition ad1s1 will contain 8192 MB of swap and 32768 MB for data Use these values (y/n)?yDisk partitioning will delete contents of selected disks, continue (y/n)?y
If you want to cancel the installation process, answer
n to the last question. It will return to the
main menu without changing the disk contents.
Answering y to the ``continue'' question will
initialize the selected system and data disks with the standard disk
layout for Kernun. Any existing contents of the disks will be lost.
Messages concerning creation of disk partitions and file systems will then be displayed, followed by:
Current Kernun installations:
Boot manager on /dev/ad0
F1: Unused
F2: Unused
F3: Unused
type=Kernun 1024 B boot manager (74 character labels)
current_booted=
bootable=
update=yes
default_selection=F1
Select partition for installation (1 2 3) [1]:
These lines show the configuration of the Kernun boot manager, see
bootmgr(8). The first installation will be
usually performed in the first system partition, so just press
<Enter>. After another
confirmation whether you want to overwrite the selected system
partition, the boot manager label for the newly installed Kernun instance
is set. The default label consists of the installed Kernun version,
the date and time of installation, and the build number.
Overwrite partition /dev/ad0s1 by new Kernun installation (y/n)? y
Enter the label that will be used to identify this installation in the
boot manager. The label can be at most 44 characters long. The Kernun
build number will be appended after the entered label automatically.
Label [Kernun 3.0 2008/09/25 14:07]: After setting the label, the installer creates any missing
standard directories in the data partition, creates a new empty file
system in the selected system partition, and displays a list of the
installation images (identified by build numbers) available on the CD
and in the /data/dist directory. If there is more
than one image, one can be selected, with the
newest image as the default. If the image from the CD is selected, it
is first copied to /data/dist. The selected image
is then unpacked to the system partition. The
/etc/fstab file in the newly installed partition
is adjusted according to the system partition number. The build number
of the installed Kernun is stored in the
/kernun-version file in the system partition. The
content of the newly installed Kernun instance is stored in
/kernun-installed.fsdb.bz2. This file is used by
the backup tools in order to decide which files have changed since the
installation and therefore need to be backed up. After the installation
is finished, the installer waits for
<Enter> and then returns to the
main menu.
...
Available installation images:
1 030000h00.200809241501.i386
Copying installation image to /data/dist
Clearing system partition 1
...
Installing kernun-030000h00.200809241501.i386.tbz to system partition 1
Unpacking image
Removing file system content databases for installed images
Creating /etc/fstab
Writing build number into /kernun-version
Creating file system content database
Installation successfully finished
Press Enter for return to menu...Optionally, if you have a license file for your newly installed
system available, you can install it now. This ensures that the initial
configuration script will set the system.product
configuration item correctly after reboot. It will also ask whether the
licensed proxies should be enabled in the initial configuration. The
license installation is done in several steps:
Prepare a USB disk with a UFS or FAT file system.
Copy the license file license.dat to the
root directory of the USB disk. Alternatively, if you have some other
license files (for example, for the antivirus engine), you can pack
them all[3] in
the license.tar file in the
tar format with all paths relative to the Kernun
system root directory.
Do not connect the USB disk yet and select
0 from the installer main menu.
When prompted, connect the USB disk. The license files present will be installed.
Select 9 from the main menu to have the
newly installed Kernun booted. You can then perform its initial
configuration, as described in the following section.
The /data/dist directory may contain full and
patch installation images. A full image can be always installed. A patch
image contains only the differences from a base image. Hence the base image
must be available in order to install the patch image. The base image may
itself be a patch image, and its base image is then required as well. Generally,
each patch image requires a continuous sequence of base images starting
with a full image followed by zero or more patch images.
When a newly installed Kernun system is booted for the first time, an
interactive initial configuration script
(/etc/rc/kernun-config) is executed early in
the boot process[4].
It prompts the administrator for various basic system
parameters, creates and applies the Kernun configuration file, and
finishes the boot procedure with the new configuration. The initial
configuration can be modified later using the standard Kernun GUI or
command line configuration tools.
First, the time zone needs to be set. We recommend to use UTC for
the CMOS clock—select Yes by pressing
<Tab><Enter> in
the first dialog.
Even if the CMOS clock is currently set to the local time, it is
better to select UTC here and adjust the time later using the
date(1) command or by configuring NTP,
see section ntp in
system(5). After selecting the CMOS clock
mode, the time zone menu is displayed. Choose the time zone suitable for
your location. Then set the administrator password
(user root).
After that, a new SSH host key is generated. It is used to authenticate the system to a remote access client[5] (GUI or command line SSH). You should write down the reported key fingerprint and compare it with the fingerprint reported by SSH or the GUI when making the first remote connection to the system. The SSH host keys should be the same for all Kernun installations on the same computer. Therefore, if an SSH host key exists during the installation, it is copied to the newly installed system partition and the generation of a new key is skipped during the initial configuration. The GUI and command line installers look for an SSH host key in the current system partition. The standalone installer takes an SSH host key from the first system partition that contains one and is different from the partition, in which the installation is taking place.
Answer n to the following question (or
just press <Enter>) if you
want to input the basic configuration parameters and generate the
initial Kernun configuration file.
**********************************************************************
Fingerprint of the SSH host DSA key. Compare this value with the value
reported by SSH client or Kernun GUI when connecting in order to check
that you are connecting to this system.
1024 71:0a:ec:8d:dd:9e:e7:2d:2b:91:79:0e:1a:ca:89:2b
/etc/ssh/ssh_host_dsa_key.pub
**********************************************************************
*** KERNUN INITIAL SYSTEM CONFIGURATION ***
Skip Kernun configuration (y/n)? [n] <Enter>Two network interfaces are configured in the default configuration: internal, intended to be connected to the protected network, and external, which is typically connected to the Internet. The configuration script asks for the names, IP addresses, and network masks of these interfaces. Then, the DNS server and default router addresses need to be specified. The initial configuration will allow the administrator SSH access from the internal network (using the GUI or a command line SSH client). If you want to allow some application protocols to pass from clients in the internal network to servers in the external network, you can enable the respective proxies. The configuration of the proxies will contain the default values of various parameters, which will be sufficient for the simplest use. More complicated configuration requirements can be implemented later by editing the generated initial configuration file using the GUI or command line configuration tools (modifying proxy configuration, adding new proxies, etc.). An example of the initial configuration setup is given and explained below.
In many environments, an initial configuration with enabled proxies may violate a security policy. Therefore, it is recommended not to enable any proxy in the initial configuration unless you are sure that you really need it.
Hostname without domain []:fwDomain []:![]()
example.comShow only Ethernet interfaces (y/n)? [y]By repeating the following test with connected and disconnected network cables, you can determine interface names of physical network cards. *** Media state of network interfaces *** ed0: media: Ethernet autoselect (100baseTX <full-duplex>) ed1: media: Ethernet autoselect (100baseTX <full-duplex>) Show again (y/n)? [y] *** Media state of network interfaces *** ed0: media: Ethernet autoselect (none)
ed1: media: Ethernet autoselect (100baseTX <full-duplex>) Show again (y/n)? [y] *** Media state of network interfaces *** ed0: media: Ethernet autoselect (100baseTX <full-duplex>) ed1: media: Ethernet autoselect (100baseTX <full-duplex>) Show again (y/n)? [y]
nInternal interface name (ed0 ed1) []:ed0Internal IP address []:![]()
192.168.10.1Internal interface netmask [24]: External interface name (ed0 ed1) []:ed1External IP address []:![]()
192.168.11.2External interface netmask [24]: DNS server IP address []:10.1.1.1Default router IP address []:![]()
192.168.1.1Postmaster e-mail [postmaster@example.com]:![]()
Enable some proxies (y/n)?
yEnable DNS proxy (y/n)? [n]![]()
yEnable FTP proxy (y/n)? [n] Enable HTTP proxy (y/n)? [n] Enable HTTPS proxy (y/n)? [n] Enable POP3 proxy (y/n)? [n] Enable IMAP4 proxy (y/n)? [n] Enable SMTP proxy (y/n)? [n] Enable SSH proxy (y/n)? [n]yHostname: fwDomain: example.com Internal interface: ed0 Internal IP: 192.168.10.1 Internal netmask: 24 External interface: ed1 External IP: 192.168.11.2 External netmask: 24 Name server: 10.1.1.1 Default router: 192.168.11.1 Postmaster e-mail: postmaster@example.com Enabled proxies: DNS SSH Use these values (y/n)?
y![]()
The configuration begins
with
setting the host name and the domain name. Then, the internal and external
interfaces are selected. First, the available network interfaces are listed.
You can choose
whether you want to show all
interfaces, or just Ethernet interfaces. The interfaces are repeatedly
listed with their media states. This can be useful if you are not
sure about the names of physical interfaces. You can unplug network cables
one by one and observe, which interface changes its state. In the example
, the cable was unplugged from the network
interface ed0. The internal
and external
interface
names, IP addresses, and network masks are defined. The DNS server IP
address
is used by Kernun for domain name
resolution. The default router
is typically
a router in the external network. The postmaster e-mail address
is used by the SMTP proxy to forward mail sent
to the postmaster.
You can also enable some proxies
for
access from the internal to the external network. Questions about
individual proxies are asked only if you reply y to
the initial “enable some proxies” query. Otherwise, all proxies
are disabled without further questions. The generated initial
configuration file will contain configuration of the disabled
proxies as well, with their configuration sections marked as hidden. A proxy
can be easily enabled later by unhiding its configuration using the
GUI or the command line configuration interface. Only licensed proxies are
offered for enabling.
Finally, all values defined during the configuration setup are listed
. If you are satisfied, reply
y
and the initial
configuration file will be generated and applied. If you reply
n, the whole configuration setup will be repeated
with the previously specified values as defaults.
After defining values for the initial configuration, the SSH key for remote administrator access is generated. You must enter a passphrase used to encrypt the key. The same passphrase is also used for the initial download of the key from Kernun.
The configuration script will now generate the root's SSH key. The passphrase for the key will be also used as the password for initial key download from Kernun GUI. Enter SSH key passphrase: Repeat SSH key passphrase: Generating public/private dsa key pair. Your identification has been saved in /home/keygen/id_dsa. Your public key has been saved in /home/keygen/id_dsa.pub. The key fingerprint is: 33:27:5a:63:53:b1:ba:47:bf:e8:58:4a:d0:f6:d4:d4 root@fw.example.com
The SSH key generation is the last step in the initial configuration process. After that, the normal operation of the newly installed Kernun begins.
The SSH (private) key needs to be downloaded to the administrator's
local computer and subsequently copied to any system used by the
administrator to access Kernun. The administrator's computer must be
in a network routed via the Kernun internal interface, e.g.,
192.168.10.0/24 in our
configuration example. There is a special user account keygen dedicated to SSH key download. The
GUI is able to download the key automatically, you only need to select
Initialize new firewall in the Connect to
Server dialog. See also Section 1.1, “Kernun GUI Launcher” for
details. For command line SSH access, you can either use the key
downloaded by the GUI, or download the key manually:
Use SCP to copy the private OpenSSH key
(id_dsa), the public OpenSSH key
(id_dsa.pub), and the Putty key
(key.ppk).
$scp keygen@192.168.10.1:* .keygen@192.168.10.1's password: id_dsa 100% 736 0.7KB/s 00:00 id_dsa.pub 100% 609 0.6KB/s 00:00 key.ppk 100% 807 0.8KB/s 00:00$
Log in to Kernun as user
root using the newly
obtained key.
$ssh -i id_dsa root@192.168.10.1Enter passphrase for key 'id_dsa': ...[root@fw ~]#
Delete the key files in the home directory of user keygen.
[root@fw ~]#rm ~keygen/*
Disable the keygen
account.
[root@fw ~]#pw lock keygen
Log out from Kernun.
[root@fw ~]#logoutConnection to 192.168.10.1 closed.$
The steps after the first one are not strictly necessary, but they are
recommended for security reasons. Although the secret SSH keys are
protected by a passphrase, they should be kept in a secure store that
can be accessed only by authorized administrators. If the key is downloaded by
the GUI, the key files on Kernun as well as the
keygen account are automatically
removed when the GUI connects to Kernun with the downloaded key for
the first time.
In this section, we assume that the reader has at least the
basic knowledge of the Kernun GUI. An introduction to the Kernun GUI can be
found in Section 1, “Graphical User Interface” of this manual. The installation and
its related tasks are controlled by the Kernun GUI System
Manager, which is accessible using the
button in
the main window toolbar, as shown in Figure 3.1, “The System Manager icon in the toolbar”.
The installation is done from the Installation
images tab in the System Manager window, see Figure 3.2, “Installation images in the System Manager”. It displays a list of available
installation images (stored on Kernun in
/kernun/dist). An image is marked as
installable if it is either a full image, or a patch image with an
available base image. The version number, build date, and build
number are listed for each image. Installation images can be copied
from the administrator's local machine, where the GUI runs, to
Kernun by clicking the button.
The button can be used to copy
in the opposite direction. It is also possible to
delete a selected image () or all
images older than the selected one[6] ().
Each installed image is is copied to
/data/dist. As the images may consume a lot of
disk space on a regularly updated Kernun, it is recommended to
delete old images regularly or when you need more space on the data
disk. An easy way to do this is to select one of the newest images
and click .
It is usually sufficient to retain only the one or two most recent
images.
To initiate the installation of the selected image, click the button. In the example, we will install the newest (last) installation image from the list. The installation of Kernun can be alternatively initiated using the button on the Quick Wizards page. A wizard window (see Figure 3.3, “Selection of the installation target”) appears and prompts you to select the target system partition. It displays the number and label of the system partition that contains the currently running system. This partition cannot be overwritten by the installation. One of the other two system partitions, which are also listed with their labels, needs to be chosen. If you started the wizard from the Quick Wizards page, you are then supposed to choose the desired installation image. Finally, the recapitulation of the selected values is displayed. Click the button to launch the installation process (it deletes all the existing content of the selected partition).
When performing an installation, make sure that you have selected the correct system partition, in order to avoid inadvertently overwriting a system partition that you want to retain.
The installation process takes several minutes; it can be aborted using a button in the progress dialog displayed in the meanwhile. The newly installed system partition is made bootable, but the default boot partition is not changed. The reason is that the new Kernun instance is not configured and until its initial configuration is performed from the console, it will be inaccessible via the network. The boot manager configuration after the finished installation can be viewed in the System Manager's Kernun systems tab, as shown in Figure 3.4, “The system partitions after the installation”. It is possible to change the partition label (using the button) or make the new system partition the default boot partition (the button).
If the installation process terminates because of an error, the output of the failed command is displayed. The example in Figure 3.5, “An error during the installation” shows an error message caused by a corrupted installation image file.
The command line installation functionality is provided by
the
sysmgr(8) and
bootmgr(8) utilities. An installation
image that is to be installed must be stored in the
/data/dist directory, along with the
corresponding base image(s), if it is a patch image. The existing
images can be listed using the following command:
[root@fw ~]#sysmgr images* 030000h00.200809241501.i386 030000h00.200810170852.i386* 030001h00.200811142135.i386
The installable images are marked with an asterisk. The image
is a patch image that cannot be installed,
because its base image is missing. Information about the currently installed
instances of Kernun can be obtained using the
bootmgr command or from the
/kernun-version file. In order to get access to this
file in other system partitions, the file systems in those partitions
need to be mounted first.
[root@fw ~]#bootmgrBoot manager on /dev/ad0 F1: Kernun 3.0 2008/10/01 07:36 (030000h00.200809241501.i386)F2: Unused F3: Unused type=Kernun 1024 B boot manager (74 character labels) current_booted=1
bootable=1 update=yes default_selection=F1
[root@fw ~]#cat /kernun-version030000h00.200809241501.i386[root@fw ~]#mount /2[root@fw ~]#cat /2/kernun-version030000h00.200810170852.i386![]()
[root@fw ~]#mount /3mount: /dev/ad0s3a on /3: incorrect super block
The bootmgr command displays labels of the
system partitions
and the number
of the system partition that contains the currently running system
. The second system partition in
the example contains another Kernun version
, even though it was manually relabeled as
“Unused”. The third system partition is really unused;
it does not even contain a file system
.
We will install a new Kernun version in the second system partition. We choose the newest version available according to the sysmgr images report. Unlike the standalone installer described in Section 5.1, “Standalone Installer”, the command line installer asks no questions. The image build number and the target system partition number are given on the command line and the installation starts immediately. The standard partition label, containing the Kernun version, date of installation, and build number, is set for the newly installed partition. The initial configuration process (see Section 5.2, “Initial Configuration”) is started after booting from the newly installed system partition.
[root@fw ~]#sysmgr install 2 030001h00.200811142135.i386Clearing system partition 2 ... Installing kernun-030001h00.200811142135.i386.tbz to system partition 2 Unpacking image Installing SSH host keys Removing file system content databases for installed images Creating /etc/fstab Writing build number into /kernun-version Creating file system content database Installation successfully finished[root@fw ~]#bootmgrBoot manager on /dev/ad0 F1: Kernun 3.0 2008/10/01 07:36 (030000h00.200809241501.i386) F2: Kernun 3.0.1 2008/11/17 16:39 (030001h00.200811142135.i386) F3: Unused type=Kernun 1024 B boot manager (74 character labels) current_booted=1 bootable=1 2 update=yes default_selection=F2
Be careful when running sysmgr install. Especially, make sure that you specify the correct system partition number. Otherwise, you might inadvertently overwrite a system partition that you would like to retain.
The newly installed system partition is made the
default choice for the next boot. As it is not configured, it will
be inaccessible via the network after the reboot and its initial
configuration will need to be performed from the console. If you want to
keep the current default boot partition, so that you retain a fully
working system after the reboot, use the -n
parameter of the sysmgr command:
[root@fw ~]#sysmgr install -n 2 030001h00.200811142135.i386
Kernun provides both GUI and command line tools used to back up
system partitions and restore data from backups created in this way.
They can be used to back up not only the current system partition, but
any of the three system partitions. A backup file does not contain
the complete contents of a system partition, but only the changes made
since its installation. The size of the backup file therefore depends
on the amount of changes that have been made in the system partition
since its last installation. After an installation, the content of a
system partition is stored in the
/kernun-installed.fsdb.bz2 file. When doing
backup, this file is compared with the current content of the system
partition. Added and modified files are stored in the backup file,
along with information about deleted files and files with changed
metadata attributes[7].
The backup and restore operations process only a subset of files
contained in a system partition, mainly Kernun configuration files.
The list of files included in a backup can be viewed and modified
in the /etc/kernun-fsdb-include file. During
backup and restore operations, this file is passed to
diskdb(1)
using the -I parameter.
Backup files are stored in the /data/backup
directory, from which they should be copied to a safe place.
They should not be renamed, because their names contain
important information for backup processing: the build number of
the Kernun instance, the number of the backed up system partitions,
and the date and time when the backup was created.
A backup created on a particular Kernun version (build number) should
be restored to a system partition containing a newly installed image with
the same build number. On the other hand, a system partition with any
partition number can be used for restoring, not only the one where the backup
was created. The restore program adjusts the contents of the file system table
/etc/fstab accordingly.
Kernun provides tools for manual backup and
restoring of system partitions using local backup files in
/data/backup. The administrator should create a backup
at least after every major configuration change and copy it to a storage
medium other than a local disk. Solutions for automated backup, remote backup,
or backup of the data partition are not provided out of the box, because
backup policies required for different deployments vary significantly.
More sophisticated backup scenarios can be implemented using
operating system tools
(tar(1),
cron(8), etc.) or various third-party
backup software. The Kernun tools support only complete restoring of
a backup to a newly installed system partition. Nevertheless, a backup file is a
tar(1) archive compressed by
bzip2(1) and can therefore be freely
manipulated using these tools.
In some situations, especially when a backup is restored to a different version of Kernun or to a system partition that has been modified since the installation, conflicts may be reported during restoring. It is also possible that unresolved conflicts from an earlier restore operation interfere with the current one. In such a case, the old conflicts need to be resolved or discarded first. See Section 7, “Upgrade” for explanation of conflicts and instructions on how to resolve them.
A backup can be created in the GUI in the Kernun
systems tab of the System Manager (Figure 3.4, “The system partitions after the installation”). All you need to do is select a system partition
and click on the button. A backup file will be
created and stored in /data/backup. The new
backup will appear in the Backups tab, see Figure 3.6, “Existing backup files in the GUI”. Using buttons under the list of backup files,
a file can be downloaded to the administrator's computer, uploaded
back to Kernun, or removed.
Click on the button if you want to start the restore operation. Alternatively, restoring can be initiated using on the Quick Wizards page. A wizard window appears. It prompts for the target system partition (must not be the currently booted one), for selection of a backup file and for a corresponding installation image. There are also buttons for uploading a locally stored backup or image to Kernun. As the last step, the recapitulation of the selected values is displayed, as shown in Figure 3.7, “Parameters of a restore operation”. When you click , the selected image is installed in the chosen system partition and the selected backup is unpacked. Then it is possible to do any combination of the following operations: set the newly restored partition as the default boot partition; change the partition label; reboot Kernun immediately (see Figure 3.8, “Final settings after restoring a backup”).
The
sysmgr(8) utility is used to create
and restore backups from the command line. A new backup file in
/data/backup is created by the following command:
[root@fw ~]#sysmgr backup 2Creating backup content database /kernun-backup.fsdb.bz2 Creating file system content database Creating backup file /data/backup/backup-030000h00.200809241501.i386-2-200807281400.tbz[root@fw ~]#
If a backup of the current system partition is to be created, the
partition number (2 in our example) may be
omitted. A list of existing backup files is displayed by
[root@fw ~]#sysmgr backupsbackup-030000h00.200809241501.i386-1-200810031714.tbz backup-030000h00.200809241501.i386-2-200809261822.tbz backup-030000h00.200809241501.i386-2-200809301350.tbz
A backup can be restored to a selected system partition; it must not be the currently used system partition. A clean installation of an image with the correct build number should be done first.
[root@fw ~]#sysmgr install 2 030000h00.200809241501.i386... Installation successfully finished[root@fw ~]#sysmgr restore 2 \>backup-030000h00.200809241501.i386-1-200810031714.tbzProcessing changes of file system contents Unpacking files from backup Resolving conflicts All conflicts resolved[root@fw ~]#
An attempt to restore a backup in a system partition that contains a Kernun instance with a different build number is detected and a warning is displayed:
[root@fw ~]#sysmgr restore 2 \>backup-030000h00.200809241501.i386-1-200810031714.tbzBackup is from different build than currently installed in /2. Installed: 030001h00.200811142135.i386 Backup: 030000h00.200809241501.i386 It is strongly recommended to restore a backup to the Kernun build that was used for creating the backup. Continue anyway (y/n)?n[root@fw ~]#
A backup can be restored also from the standalone
installer booted from the Kernun installation CD. This can be helpful
after installing a new system disk or when moving a Kernun installation
to a new computer. First, select a system partition and install Kernun
from an image corresponding to the backup that is to be restored,
following the procedure described in Section 5.1, “Standalone Installer”.
If the backup file is not already located in /data/dist,
you can copy it there using the emergency repair environment
tools, as described in Section 9, “Emergency Repair Environment”.
*** KERNUN INSTALLATION *** Build 030001h00.200811142135.i386 1. Install Kernun 2. Check for existing Kernun installations 3. Restore backup 4. Start rescue shell 5. Mount Kernun file systems 6. Resize installer's in-memory temporary file system (current size 32m) 7. Halt 8. Power down 9. Reboot 0. Install license Select action:1Detected Kernun system disk ad0 Detected Kernun data disk ad0 Repartition disks (y/n)? n Current Kernun installations: Boot manager on /dev/ad0 F1: Kernun 3.0 2008/10/01 07:36 (030000h00.200809241501.i386) F2: Kernun 3.0.1 2008/11/17 16:39 (030001h00.200811142135.i386) F3: Unused type=Kernun 1024 B boot manager (74 character labels) current_booted= bootable=1 2 update=yes default_selection=F2 Select partition for installation (1 2 3) [1]:![]()
3Overwrite partition /dev/ad0s3 by new Kernun installation (y/n)?![]()
yAvailable installation images: 1 030000h00.200809241501.i386 2 030001h00.200811142135.i386 Select image to install (1-2) [2]:1Enter the label that will be used to identify this installation in the boot manager. The label can be at most 44 characters long. The Kernun build number will be appended after the entered label automatically. Label [Kernun 3.0 2008/11/20 10:26]: Clearing system partition 3 ... Installing kernun-030000h00.200809241501.i386.tbz to system partition 3 ... Installation successfully finished Press Enter for return to menu... *** KERNUN INSTALLATION *** Build 030001h00.200811142135.i386 1. Install Kernun 2. Check for existing Kernun installations 3. Restore backup 4. Start rescue shell 5. Mount Kernun file systems 6. Resize installer's in-memory temporary file system (current size 32m) 7. Halt 8. Power down 9. Reboot 0. Install license Select action:![]()
3Select partition to be restored (1 2 3) [1]:![]()
3Available backups for build installed in partition 3: 1 backup-030000h00.200809241501.i386-1-200810010405.tbz 2 backup-030000h00.200809241501.i386-1-200810040604.tbz Select backup to restore (1-2) [2]:![]()
1Restoring backup-030000h00.200809241501.i386-1-200810010405.tbz to partition 3 Are you sure (y/n)?![]()
yConflicts resolution data in /data/restore already existRemove old /data/restore (y/n)?
yProcessing changes of file system contents Unpacking files from backup![]()
Resolving conflicts All conflicts resolved Press Enter for return to menu...
In the example above, we assume that the backup file is already
stored in the /data/backup directory and the corresponding
installation image in the /data/dist directory. We
start the backup restoring procedure by carrying out a fresh Kernun
installation
in an unused system
partition
. The installation image
is chosen so that it corresponds to the
backup file that will be restored. After returning to the installer
main menu, we select
. The partition
installed in the previous step should be
selected. A list of backups compatible with the content of the target
system partition is displayed. We choose one of the offered backup
files
and the restoring begins. The
message
indicates that there are
unresolved conflicts from previous restore or upgrade operations.
Usually, you should reply n to the question
. This will interrupt the
restore operation. You can restart it after you resolve the conflicts
according to instructions given in Section 7, “Upgrade”. If you are
sure that you do not need to resolve the old
conflicts[8], you may reply
y and the conflict resolution data will be
deleted. The message and question concerning the old conflicts 
will not be displayed if there are no pending conflicts. Finally
, the backed up files are unpacked from the backup
file and checked for conflicts. No conflicts should occur if the
backup is restored to the same Kernun build that was installed at the time
the backup was created. The restored files are installed in their
proper places and the restore operation successfully finishes.
The upgrade procedure described in this section is applicable if you want to retain as much as possible from the configuration of the old Kernun instance in the new instance. If you want to configure a new Kernun version from scratch, follow the installation and configuration procedures described in Section 5, “Installation”.
Upgrading to a new version or build of Kernun is basically done by restoring a backup of the old version in a system partition that contains a fresh installation of the new version. The upgrade procedure comprises the following steps:
The syntax and semantics of the configuration files are sometimes slightly changed between versions. In order to be usable in the new Kernun version, the old configuration file must be converted in step 1. This is done automatically during the upgrade process. The configuration conversion script expects the configuration in a normalized format. Using just some formatting accepted by normal Kernun configuration tools (GUI or CML) is not sufficient. The normalization during the upgrade process is done either automatically (by GUI), or using a command in the command line upgrade.
If you are upgrading from a Kernun version that does not implement automatic configuration normalization during the upgrade process, that is, from a version older than 3.3.2, you should perform the normalization manually. It can be done simply by opening and saving the configuration by either GUI, or CML. The normalization step may be skipped if the configuration has been saved recently and has not been modified outside the Kernun configuration tools, for example, by a text editor.
The upgrade operation results in a newly installed system partition
that contains the new version of Kernun. If we want to keep the configuration
across upgrades, we need to copy the main Kernun configuration file
/usr/local/kernun/conf/kernun.cml and any other
changes done in the old installation to the new one. The configuration files
that have been changed, created, or deleted since the installation are
found and saved when the old system partition is backed up in
step 2.
Step 3 requires a full or patch installation image. Although it is possible to replace the contents of the currently used system partition with the new version, it is not recommended. You should always install an upgrade to a currently unused system partition, for two reasons. First, the old Kernun instance can continue running until the upgrade is finished. Second, you can quickly return Kernun to an operational state if something goes wrong with the upgrade.
The recommended practice is to use two system partitions for regular upgrades. One partition is occupied by the currently running version, while the other contains the old version and will be used for installation of the next upgrade. After each upgrade, the roles of the two partitions are switched. The third system partition can be reserved for special tasks, such as preparation of a completely new configuration.
Set the boot manager (as described in Section 4, “Boot Manager”) default boot partition so that it always boots the currently used Kernun instance. Consider disabling the automatic updating of the default boot partition or disabling the unused partitions altogether.
Restoring of the backup from step 2 in the system partition installed in
step 3 effectively copies the
complete configuration from the old system partition. Restoring of a backup
to a build different from the one used for its creation may cause
conflicts. These are files that cannot be restored
automatically and a manual intervention of the administrator is necessary.
A conflict occurs if there are two incompatible changes of the same file.
The original version of the file comes from the installation image of
the Kernun instance that is being upgraded; we will call it “old”. The
second version (called “backed-up”) is contained in the backup file,
if the file was changed[9] at some time between the installation of the old
version and the start of the upgrade process. The third version
of the file (called “new”) is obtained from the installation image of
the new Kernun instance installed in step 3. There are two potential changes of the
file. One between the old and the backed-up version, the second between
the old and the new version. If only one change exists, no conflict occurs
and the changed (backed-up or new) version of the file will be used. For
example, /etc/ttys may have been
changed by the administrator in the installed Kernun, but remains the same in
the build we are upgrading to. Another example is a proxy executable,
which is modified in the new Kernun version, but left unchanged by the
administrator. If all three versions exist, i.e. when the backed-up
and the new version differ, a conflict occurs. The automated upgrade tools
are unable to handle the file and the administrator must decide whether
the new file, the backed-up file, or some combination of the two should be
used. For example, a third party software added in the new build
creates a new user account in /etc/master.passwd, and the
administrator has created another user account. During the upgrade, a conflict
is reported for /etc/master.passwd. The administrator
can resolve this particular conflict by merging the two versions of the file,
adding both new user accounts to the resulting file.
The detected conflicts are recorded in the
/data/restore/resolve file during step 4. The conflicting files from the backup
file (the “backed-up” version) are not unpacked to the
root directory tree. Instead, they are stored in corresponding locations
under the /data/restore/conflicts directory. The root
directory tree contains the files as installed (the “new”
version). In step 5, the
administrator specifies for each file how the conflict should be resolved,
choosing from the following possibilities:
The new version is retained and the backed-up version is deleted
from /data/restore/conflicts.
The backed-up version replaces the new version.
The new or the backed-up version is used, but is modified first, for example by merging the contents of the two versions in a text editor.
The conflict is postponed until a later iteration of conflict resolution.
The /data/restore directory is deleted when all conflicts
are resolved. Only one upgrade procedure can be in the conflict resolution
stage at a time. If a conflict resolution session is started and there is
already the /data/restore directory with unresolved
conflicts, the administrator can either cancel the second resolution, or
delete the old /data/restore directory, thus effectively
using the “new” versions of the files for all conflicts in the earlier
conflict resolution session.
In step 6, a script is executed
that edits the contents of the main configuration file
/usr/local/kernun/conf/kernun.cml to make
it compatible with the upgraded Kernun. Sometimes, if there
are complex changes in the configuration syntax and semantics between
the two Kernun versions, or if the configuration file contains certain
advanced constructs, the script may be unable to perform a perfect
conversion. It is therefore recommended to always check the result of the
automatic conversion in step 7.
The new configuration file needs to be applied before the upgraded system can be put into normal operation. The low-level configuration files are generated and the configuration is applied in the context of the newly installed system using the applycfg command of sysmgr(8). If the generation or application of the configuration fails, the configuration should be corrected and applied again.
Finally, the upgraded Kernun can be put into the normal production mode by rebooting to the newly installed system partition.
No modifications of the configuration (steps 6 and 7) are often required during the upgrade procedure. This is usually true when upgrading between two builds of the same version or between patch releases of the same version, for example, from 3.0 to 3.0.1 or from 3.0.1 to 3.0.2.
An upgrade is initiated from the Quick Wizards page of the System Manager. There are two alternatives. Click if you want to start the complete upgrade procedure. If you already have a recent backup of the system partition that you want to upgrade, you can skip the first step — creation of a backup. In this case, use the button. We will describe only the former alternative; the latter is almost identical, only the backup step is missing.
The GUI assumes that we want to upgrade the currently running Kernun instance. Therefore, the current system partition will be backed up. After clicking on the button, we select the target system partition in which the upgraded Kernun will be installed. Then we select the installation image of the new version. Our selections are displayed in the settings recapitulation window (Figure 3.9, “Parameters of an upgrade operation”). Click on the button to start the upgrade.
The GUI displays the progress of the upgrade procedure. First, the current system partition is backed up. Then, the new system partition is installed and the backup is restored in it. If there are any conflicts, the conflict resolution window is displayed, as shown in Figure 3.10, “The conflict resolution window during an upgrade”. The window shows a list of conflicting files. You can determine how to resolve the conflict of a file by clicking in the Action column. The following actions are possible:
+ — uses the
“backed-up“ version of the file;
. — uses the “new”
version of the file, as installed from the new installation
image;
- — deletes the file;
! — postpones the conflict to the
next iteration of conflict resolution.
It is also possible to select a file and then click a button on the right-hand side of the window to display the differences between the two versions of the file, or to open one of them in an editor.
After you give instructions for conflict resolution and optionally edit some conflicting files, click to have the conflicts resolved. Finally, a window is displayed (see Figure 3.11, “Final settings after an upgrade”) that makes it possible to realise any combination of the following actions: set the newly upgraded system partition as the default boot partition; run the configuration conversion script; change the partition label; reboot Kernun immediately.
Command line upgrades are realized using the sysmgr(8) utility. Unlike when using the GUI, which performs all the required steps automatically, a command line upgrade must be done step by step. An example of the upgrade procedure follows:
[root@fw ~]#cml -l -f /usr/local/kernun/conf/kernun.cmlRCSL-730-N File '/usr/local/kernun/conf/kernun.cml' locked for current user CMLM-790-N RCS command completed[root@fw ~]#sysmgr checkcfg... Configuration is correct[root@fw ~]#sysmgr backupCreating backup content database /kernun-backup.fsdb.bz2 Creating file system content database Creating backup file /data/backup/backup-030000h00.200809241501.i386-1-200811300006.tbz![]()
[root@fw ~]#sysmgr install 2 030002h00.200811291341.i386Clearing system partition 2 ... Installation successfully finished![]()
[root@fw ~]#sysmgr upgrade 2 \>backup-030000h00.200809241501.i386-1-200811300006.tbzProcessing changes of file system contents Unpacking files from backup Resolving conflicts There are pending conflicts, see /data/restore/resolve *** CONFLICT RESOLUTION ***![]()
1. Resolve with easy editor (ee) 2. Resolve with editor vi 3. Do not resolve now Select action:
2# Conflict resolution file for system partition /2# Each line of this file contains an instruction for one file. You # can edit the file and then apply the instructions by running # "sysmgr resolve". Every line contains three fields: # - one character that defines an action to be done with the file # - one character for file type ('d' for a directory, '-' for any # other type) # - path to the file, interpreted either relative to /2 for the # existing file and relative to //data/restore/conflicts # for the file from the backup # Procedure of conflict resolution: # 1. Locate all lines beginning with '!'. These denote conflicting # files. # 2. Optionally edit the conflicting files. # 3. Change the character '!' to # + ... to use the file from backup, temporarily stored in # /data/restore/conflicts # . ... to keep the current file # - ... to delete the current file # ! ... keep the conflict for future resolution # 4. Run "sysmgr resolve". # 5. Repeat steps 1-4 until all conflicts are resolved. # Merging file from the backup with the current file can be done # either by editing the current file and specifying action '.' # (keep) or editing the file from the backup and specifying # action '+' (use backup). ! - ./etc/motd ! - ./etc/login.conf ... Resolving conflicts There are pending conflicts, see /data/restore/resolve
![]()
[root@fw ~]#vi /data/restore/resolve...![]()
[root@fw ~]#sysmgr resolveResolving conflicts All conflicts resolved![]()
[root@fw ~]#sysmgr upgradecfg 2Upgrading Kernun configuration /2/usr/local/kernun/conf/kernun.cml /2/usr/local/kernun/conf/kernun.cml,v <-- /2/usr/local/kernun/conf/kernun.cml new revision: 1.2; previous revision: 1.1 done Automatic configuration upgrade done. It is recommended to review the configuration before returning Kernun to production use.![]()
[root@fw ~]#sysmgr applycfg 2... System kernun applied in system partition 2![]()
[root@fw ~]#cml -u -f /usr/local/kernun/conf/kernun.cmlCMLM-790-N RCS command completed[root@fw ~]#
Before upgrade, the configuration should be locked
[10], checked and
normalized
. This step ensures that
the configuration upgrade step
will
understand the configuration file. The upgrade procedure starts by
backing up the current system partition
.
Specify a system partition number to upgrade a currently
inactive partition. If a recent backup already exists, this step can
be skipped. A new Kernun version is installed to an unused system
partition
. This command also sets
the default boot manager label for the newly installed partition, and
makes it bootable and the default boot selection for the next booting.
The backup is then restored to the newly installed system partition
. This command writes the list of
conflicts to /data/restore/resolve. The
conflicting files from the backup are stored in the
/data/restore/conflicts directory. If there are
conflicts, the conflict resolution menu is displayed
. You can either resolve the conflicts,
or postpone the conflict resolution to do it later. If you choose
to resolve the conflicts, the conflict resolution file
/data/restore/resolve is opened in a text editor.
Edit the file according to the displayed instructions
to determine the way of resolution
of individual conflicts. After the file is saved and the editor is
terminated, the conflict resolution is executed in accordance with
the file. If some conflicts remain unresolved, a message
is printed. It is then possible to
edit /data/restore/resolve manually
and restart the conflict resolution
. Commands
and
can be repeated until all
conflicts are resolved. The main configuration file is
upgraded
and applied
. Finally, the lock is released
. You can then reboot to
the new system partition and start using the upgraded Kernun.
The Kernun auditing tool kernun-audit(1) provides a convenient source of information about bugs discovered in the Kernun software. The auditing tool also reports when a new software version becomes available. A Kernun audit is usually executed daily by the cron daemon via the periodic command. It downloads the up-to-date auditing database, and then examines the product type, version, and architecture of the installed system. Based on these values, the relevant records are extracted from the database and reported. There are two classes of records: bugs and software updates.
Each bug that is discovered in the currently installed version of the Kernun product is reported. A bug has a unique identification number, a description, a list of versions, in which it occurs, a solution, and a workaround. The recommended solution is always a software update to a version in which the bug has been fixed (if such version is available). The workaround (if available) describes how to minimize the impact of the bug without updating the software. It should be applied if the software has not been fixed yet or if an immediate update is infeasible. Nevertheless, the workaround should always be regarded as a temporary solution and the Kernun installation should be updated as soon as possible.
Software updates are reported only for the same product and architecture as in the installed system. The latest patch release from each release branch is shown. Only versions newer than the currently installed version are displayed. For example, if 3.1 is the version installed and 3.0–3.0.6, 3.1–3.1.3, and 3.2–3.2.1 are available, 3.1.3 and 3.2.1 will be the versions reported.
The initial configuration of a Kernun system runs the auditing tool
daily using the DEFAULT-CRONTAB and
DEFAULT-PERIODIC variables from the
included crontab and the periodic configuration file
crontab.cml. Auditing can be disabled by setting
daily_status_security_kernun_audit_enable to
"NO" in that file. The auditing tool
kernun-audit can be also executed manually from the
command line. The product name, version number, and architecture name are
obtained from the current system, or can be specified using the command line
arguments of kernun-audit. The identification of the
current system is stored in the files /kernun-product
(product name) and /kernun-version (build number,
which contains the version number before the first dot and the
architecture name after the second dot). If the location (local or remote)
of the audit database is not specified, the database is downloaded from
download.kernun.com by
default.
The www.kernun.com Web
site provides an online version of the Kernun auditing tool. After filling
the Kernun product, version, and architecture in a form, the auditing report
is generated in the same format as the one kernun-audit
produces.
The instructions in this section are intended for experienced administrators with profound knowledge of Kernun and FreeBSD.
The Kernun installer booted from the installation CD can be used to repair the system if all system partitions are unable to boot. The available functions are accessible from the installer main menu:
1. Install Kernun 2. Check for existing Kernun installations 3. Restore backup 4. Start rescue shell 5. Mount Kernun file systems 6. Resize installer's in-memory temporary file system (current size 32m) 7. Halt 8. Power down 9. Reboot 0. Install license
Option 1 is described in
Section 5.1, “Standalone Installer”. Options 7,
8, and 9 are
self-descriptive. Option 2 displays the boot manager
configuration and the disk device names.
System disk is /dev/ad0 Boot manager on /dev/ad0 F1: Kernun 3.0 2008/10/01 07:36 (030000h00.200809241501.i386) F2: Unused F3: Unused type=Kernun 1024 B boot manager (74 character labels) current_booted= bootable=1 update=yes default_selection=F1 Data disk is /dev/ad0s4d Swap is /dev/ad0s4b
Option 3 restores a backup selected from a list
of backup files found in /data/backup. If the backup
is stored on another medium, it must be first copied to the
/data/backup directory, using for example the rescue shell
(option 4). For details about backup and restoring, see
Section 6, “Backup and Restoring”.
Option 4 starts a rescue shell
(bash). It provides the environment for emergency
maintenance of a computer with non-bootable Kernun installations. The
rescue shell (as well as the whole standalone installer) runs in a custom
FreeBSD environment. The standard Kernun kernel is used. The root file
system is mounted from the installation CD and is therefore read-only.
A read-write RAM disk for temporary data is mounted under
/tmp, symlinked also from
/var/tmp. The standard size of the RAM disk is
32 MB. It can be resized using option 6 of the
installer main menu.
The content of the RAM disk is lost when the installer is terminated or when the RAM disk is resized.
Do not make the RAM disk too large, because its content is stored in the kernel memory. If the free kernel memory gets too low, the kernel may panic.
Option 5 of the menu mounts any existing Kernun
partitions under the directories /1,
/2, /3 (the system partitions),
and /data (the data partition). The rescue shell
provides many standard FreeBSD command line programs. Programs from a mounted
Kernun system partition can be run as well.
It is often useful to perform a chroot(8) to a mounted Kernun system partition and to run commands in the chrooted environment.
[1] Collect values from lines
starting with component:, group:, and
upgrade: in the license file.
[2] It is usually the first disk: da0
(SCSI), ad0 (PATA), ad10
(SATA).
[3] including
usr/local/kernun/license.dat
[4] More precisely speaking, the initial
configuration script is executed during any system boot if there is no
Kernun configuration file
/usr/local/kernun/conf/kernun.cml and none of
the files /etc/rc.conf and
/etc/rc.conf.local contains the line
kernun_config_enable=NO.
[5] The host key is used by the SSH client (or GUI) to ensure that it is communicating with the intended server. It is different from the client's key, which is used to authenticate the client to the server.
[6] An image is considered older if it has a lower version number or an earlier build date.
[7] for example, access rights, owner, or modification time
[8] for example because they are in a system partition that is not used any more
[9] By a change, we mean modification of the contents of the file, deletion of the file, a change of the file attributes (e.g., the owner or access rights), or creation of a previously nonexistent file.
[10] Steps
and
are supported by Kernun since
release 3.6. In the prior versions, these steps should be
skipped.
Kernun can be administered locally, or remotely via the network. Local administrator access is usually limited to the initial installation, when the network is not yet configured, and emergency situations after a failure or misconfiguration if the network is not accessible. The administrator can access the system locally via a text system console. It provides the same set of command line tools as the remote text login via SSH. In normal operation, Kernun is usually administered remotely. There are two options for remote access: a text command line interface and a graphical user interface.
An administrator can log in to Kernun remotely via SSH and get shell access to the system. Administrative tools accessible from the shell include the primary Kernun command line control and configuration tools kat(8) and cml(8), see also Section 2, “Command Line Interface”. Besides these two, many additional command line utilities are available, including specific Kernun commands introduced in Section 3, “Administrative Utilities” and all the standard FreeBSD commands.
Kernun's graphical user interface (GUI for short, described in Section 1, “Graphical User Interface”) provides a similar functionality as the command line utilities, but in a more intuitive and comprehensive way. It shows the current state of all system components and can display details for each component. The GUI contains also a powerful log analyzer, a configuration editor, and a system manager, which administers installations, backups, and upgrades. There is some functionality that is unique to the GUI and cannot be accessed from the command line, such as displaying of performance graphs. The GUI runs on the administrator's local computer and communicates with Kernun via the network, using SSH internally. Hence, the same prerequisites are needed for both the command line and GUI access to Kernun (especially, SSH keys and the SSH protocol enabled on the way between Kernun and the administrator's computer).
In this section, we will introduce the Kernun GUI. In later chapters dealing with configuration (Chapter 5, Configuration Basics, and Chapter 6, Advanced features) we will assume that the administrator knows how to use the GUI.
The GUI is distributed on a separate installation CD. Unlike
other parts of Kernun, the GUI is distributed under the
terms of the GNU General Public License (GPL). The license text is
available in the LICENSE.GPL file in the directory
containing the GUI source code.
The Kernun GUI is available in two functionally equivalent versions: for Microsoft Windows and for UNIX. The binary executables of the Kernun GUI are distributed for MS Windows and for FreeBSD [11]. The Kernun GUI can be easily compiled also for other UNIX platforms. See the README file for instructions on how to compile the Kernun GUI.
On UNIX machines, the Kernun GUI expects OpenSSH to be installed
(namely, the ssh, ssh-agent,
ssh-keygen and ssh-add programs are
expected to be located in a directory listed in the PATH
environment variable).
There are no prerequisites to be installed on MS Windows. All the necessary executables are included in the Kernun GUI distribution.
The Kernun GUI provides the following functionalities:
monitoring of the state of Kernun;
management (starting, stopping, restarting, …) of Kernun (or its particular components);
work with logs (both current online logs and downloaded offline logs) and statistics;
modification and application of the configuration of Kernun;
administration of Kernun installations, backups, and installation images.
When the GUI is started, the launcher window is displayed, see Figure 4.1, “GUI Launcher”. The launcher provides buttons to open (and change) a local copy of the Kernun configuration file (for more information on work with the configuration in the GUI see Section 1.4, “GCML — Configuration”) or examine a local log file (see Section 1.3, “Logs”). However, the main purpose of the GUI launcher is to establish a new connection to Kernun and launch the main GUI management window.
The GUI communicates with Kernun via
SSH connections. You therefore need to have the
sshd service running and correctly
configured (see Section 2.3, “SSH Server”).
The parameters of the SSH connection to Kernun are specified in the
Connection Parameters dialog, as depicted in Figure 4.2, “Connecting to Server”. You need to fill in the
Host name or IP address of the Kernun machine,
Username, Port and select the
SSH key file.
If you are connecting to Kernun via SSH for the first time, you need to initialize Kernun (i.e., download your private SSH key from Kernun). To do this, use the dialog that appears after the button is pressed. Fill in the Hostname and the Password you entered during the installation. See also Section 5.2, “Initial Configuration”.
If you intend to apply the configuration to other Kernun than the one you are logged in (for example, the second Kernun in a cluster), you must check the Forward SSH agent check box. See ssh(1) for information about security risks of SSH agent forwarding.
It is unsafe to leave the SSH keys loaded in the ssh-agent after finishing your work with Kernun.
The key is deleted automatically on
UNIX, if there was no
ssh-agent running before the Kernun GUI was started.
Otherwise, you need to unload it yourself (e.g. using
ssh-add -d private_key_file).
On MS Windows, the Kernun GUI instances are managed by the GUI launcher, which is set to unload the keys automatically (after a timeout) if there are no main Kernun GUI applications running. You can change this behavior or unload the key manually using the context menu of the Kernun GUI taskbar icon.
The functionality of the Kernun GUI main window, depicted in Figure 4.3, “GKAT — Kernun management console”, is basically equivalent to the command line administrative tool kat(8). It displays the states of individual Kernun components and allows them to be started, stopped, and monitored.
When connected to Kernun, the state of the proxies and other
system components is indicated
by their state icons. The states of the components are also
propagated to the state icon of their parent component groups and of
the whole Kernun. There are the following component groups:
Proxies, System Components
(such as SSH servers, mail forwarders, or DNS servers),
Network (interfaces, packet filtering, routing),
and Open VPN servers.
A running component is denoted by green icon background
, whereas the background of a stopped component
is red
. There are several icon overlays that
indicate further information concerning the component's state:
Not up-to-date configuration — the
configuration of the component has changed; reload it, so that the changes
can take effect.
Parent exiting flag — the proxy is in a special state: it
does not accept new connections, but only waits for the already active sessions to finish.
For example, this state may appear when a proxy is reloaded, some sessions
remain open in the old proxy instance, and only the new instance accepts
new connections. Total restart of the proxy stops the old proxy instance and
starts another, so no sessions remain open.
Not in configuration — the system component
is not in the configuration. Kill the component to solve the problem.
Component's state changing — this overlay
is displayed while the component's state (started/stopped/restarted/reloaded) is being changed.
It disappears immediately after the action is finished.
In the situation depicted in Figure 4.3, “GKAT — Kernun management console” we know that all proxies are running, even though the Proxies subtree is collapsed. The IPS component is stopped, which is why the System Components and Kernun icons are partially green and red. Kernun has four network interfaces, the packet filter and the routing table running. No Open VPN server is configured. You can click on a component, group, or the whole Kernun icon in the proxy tree to select it and display its details in the right-hand part of the window. The information about the RTT (Round Trip Time) in milliseconds between the GUI and Kernun is displayed next to the Kernun name.
On the Manage page of the whole Kernun (that is, with the top-level Kernun node selected from the component list in the left-hand part of the window), the administrator can easily manage (start/stop/reload/restart) the whole Kernun, as depicted in Figure 4.4, “Kernun Manage Page”.
The selected action can be applied either to all components, or to the components marked with a tag in the configuration. The tag or the All components option can be selected from a combo box. A change in the configuration takes effect only after the system state is synchronized with the updated configuration. This can be always done by rebooting, restarting, or reloading the whole Kernun, but it often suffices to restart only a subset of components, while the remaining parts of Kernun may be left running. The Synchronize system button automates this process. It displays a window (depicted in Figure 4.5, “System state synchronization dialog”) that lists the actions required to bring all the components into sync with the configuration. You can manually alter the proposed actions by clicking on a component in the Action column. When you are satisfied, click and all the selected actions will be executed.
The Process List page (Figure 4.6, “Process List page”) contains the list of the running parent proxy processes[12].
The context menu in the process list
(Figure 4.7, “Process List context menu”) can be used to send the TERM
(Kill parent process) or KILL
(Kill -9 parent process)
signals to the particular process, to copy the contents of
the process list to the clipboard or to save them to a file.
The Graphs page contains graphs of various system parameters, see Figure 4.8, “Graphs page”. There are many monitored parameters of the operating system (CPU load, used memory and disk space, etc.), hardware (temperature measurement, if supported by the hardware), and cluster behavior (switches between the cluster master and backup). Kernun collects parameter values and creates graphs depicting how they evolve in time, with several time scales available. The most detailed graphs show only the recent history, while coarse-grained graphs extend further into the past. Right-click on a graph to open a context menu that makes it possible i.a. to save the graph to a file or to add it to Favorite graphs.
The Top page (Figure 4.9, “Top page”) shows the output of the popular top(1) command. The Misc page (Figure 4.10, “Misc page”) displays the output of several commands, showing i.a. the disk space (the df -hi command), the network state (netstat) or the uptime and current load of Kernun (w | head -n 1). The Version page (Figure 4.11, “Version”) shows the version of Kernun and of the FreeBSD system used by Kernun.