Unexicon Release Notes

The sections that follow detail aspects of the release.

Note that throughout this document where you see i686 listed, read x86_64 for the 64-bit release.

System Requirements

Following are the minimum system requirements for running the unexicon distribution:

CPU Arch:  i686 or x86_64
CPU Speed:  >1GHz
Memory:  ≥1G
Disk Drive:  ≥32G

Preparation

The sections that follow details the steps necessary for preparing boot media of various types.

Unexicon distribution ISOs are multi-purpose and can be used directly to prepare a USB flash drive, SSD, HDD, CD or DVD. Because the distribution is compact, and runs unconstrained in 32G of disk, we highly recommend the use of medium sized, high-speed USB 2.0 flash drives or SATA 3.0 SSDs. See the unexicon hardware page for a reference hardware design.

Unexicon runs compact on a notebook (used for management or development) from an 8G USB flash drive. For a full blown workstation, a 16G to 32G USB flash drive is preferred.

Preparing a CD/DVD

  1. Download the ISO image from the unexicon downloads page
  2. Insert a blank CD or DVD into the CD/DVD burner.
  3. Use a CD burning tool to burn the raw ISO image to the CD or DVD.
  4. On Linux, execute:
    sudo wodim dev=/dev/sr0 image.so
    where image.iso is the name of the downloaded ISO image, and /dev/sr0 is the device name assigned to your CD/DVD burner: try lsblk(1) to discover it.
  5. Remove the CD or DVD after burning, place in a target machine and boot from it.

Preparing a USB flash drive

  1. Download the ISO image from the unexicon downloads page.
  2. Insert a USB flash drive (4G or larger). Ensure that there is no important data on the USB flash drive as it is overwritten during the install process.
  3. Use a USB authoring tool to write the raw ISO image to the USB flash drive.
  4. On Linux, execute:
    sudo dd if=image.iso of=/dev/sdx
    sudo sync
    sudo eject /dev/sdx
    where image.iso is the name of the downloaded ISO image, and /dev/sdx is the device name assigned to the USB flash drive: try lsblk(1) to discover it. Take care with the device name or you will overwrite the wrong drive: maybe your hard drive! All existing data on the drive is lost.
  5. Remove the USB flash drive and insert it into the boot machine.
  6. You may have to change the machine BIOS settings or use a special key sequence to select the boot medium.

Preparing an SSD

  1. Reboot the target system using a USB flash drive or CD/DVD prepared as described above. Press ESC when prompted to get a boot menu and select "Unexicon i686 rescue". The system boots and copy the live image to RAM. At the login prompt, the live medium should be removed. Login as unexicon. (Any live distro can be used for this purpose. I usually keep a current copy of RIPLinuX handy.)
  2. Download the ISO image from the unexicon downloads page (or transfer it) to the live system.
  3. Disk copy the raw ISO image directly to the SSD/HDD drive by executing:
    sudo dd if=image.iso of=/dev/sdx
    sudo sync
    where image.iso is the downloaded ISO image, and /dev/sdx is the device name assigned to the SSD/HDD: try lsblk(1) to discover it. Take care with the device name or you will overwrite the wrong drive. All existing data on the drive is lost.
  4. Reboot the machine. Press the ESC key when prompted to enter the boot menu. Select "Unexicon i686 install" from the boot menu and the system is installed and booted.

Installation

Unlike many Linux distributions, installation menus and selections are not required: the live medium installs itself automatically (upon boot selection) to the drive on which it booted. This means that you must dedicate the drive to unexicon. Selecting "Unexicon i686 install" from the boot menu when the live image is booted installs the system. See Boot Menu Selections later in this document for a description of boot menu selections.

Booting

Unexicon currently uses a GRUB 2.00 boot loader with a custom unexicon boot script. The sections that follow detail the booting process and options.

To boot the system, insert the prepared medium into the computer. This may be the USB/SSD/HDD or CD/DVD as described above. Select the boot order from the computer's BIOS setup and select the installation medium as the boot medium. If your machine is too old to boot a USB, there are some tricks for using a special purpose CD that chain boots the USB. Once BIOS setup is complete, boot the system.

Serial Boot

To control the boot process of servers without display or keyboard, the boot script for unexicon detects the presence of USB0 and COM1 serial ports.

A USB0 serial port is present when a USB serial cable is plugged into the computer. See the unexicon hardware page for a suitable USB to USB null modem cable. When detected, the boot script outputs boot messages and menus to the port, as well as accepting input from the port. Serial port connections must be set for 38400 baud, 8 data bits, 1 stop bit and no parity (38400 N 8). When detecting the USB0 serial port, you will see the message:

     Testing for USB0 serial port... ...yes.

displayed on the local or IPMI console. An ignorable error is displayed instead of "...yes." when detection fails.

A COM1 serial port usually present as server motherboards still ship with 16550A RS-232c DB-9 COM1 ports. When detected, the boot script outputs boot messages and menus to the port, as well as accepting input from the port. Serial port connections must be set for 38400 baud, 8 data bits, 1 stop bit and no parity (38400 N 8). When detecting the COM1 serial port, you will see the message:

     Testing for COM1 serial port... ...yes.

displayed on the local or IPMI console (and USB0 serial port, if active). An ignorable error is displayed instead of "...yes." when detection fails.

Boot messages and menus are output to all active serial ports as well as the local or IPMI console. Input is accepted from all serial ports as well as the local or IPMI console.

When active serial ports are detected and "Set auto console" is in effect (see Advanced Boot Settings), the boot script instructs the kernel to use the serial port as console. The USB0 port is used in preference to the COM1 port when both are present.

Boot Keys

SHIFT key

When the system boots you will see a GRUB boot message and then the following message will appear while the boot program is initializing:

    Hold SHIFT key for non-graphical menu.

Holding down the SHIFT key at or before this point and any time before the boot loader initializes will result in the display of a non-graphical menu (on the local or IPMI console). When the SHIFT key is held through the boot process, or when the previous boot failed, the boot menu will be presented. (Note, the SHIFT key being held down can only be detected reliably from a locally attached keyboard. IPMI and serial consoles will not necessarily signal the SHIFT key being held down at all.)

The reason for the SHIFT key procedure is that the GRUB boot loader does not support all known graphical terminals and can generate errors and fail to load when it attempts to configure graphical terminals that it does not support. Holding the SHIFT key on the local console allows the operator to bypass graphical terminal configuration and boot an otherwise unbootable system.

ESC Key

The boot script will next detect serial ports as described in the previous section. After detecting serial ports, if the SHIFT key was not held down on the local console and the previous boot succeeded you will see the prompt (on the local or IPMI console, and any configured serial ports):

     Press ESC for Unexicon Boot Menu...

and a 659 Hz tone (low beep) will be generated once on the PC speaker for 120 milliseconds, and the boot program will wait for 3 seconds for an ESC key. If the ESC key is not pressed before the 3 seconds expires, the boot program will display the message:

     Press ESC for Unexicon Boot Menu... 3 2 1...booting.

and a 880 Hz tone (high beep) will be generated once on the PC speaker for 120 milliseconds, and the system will boot into the last default selection from the boot menu. When the ESC key is pressed before the 3 second timer expires, the boot program will display the message:

     Press ESC for Unexicon Boot Menu... 3 2 1...menu.

and the boot menu will be presented.

Boot Menu Selections

When a menu is presented, you will be given a set of selections. The exact set will depend upon whether the boot medium has been prepared or whether an installation has been performed on the boot medium. The following options may be presented:

The following selection is only presented when the system has not yet been installed (or restored from being overwritten with a new ISO image):

Unexicon i686 install
This selection installs the system on a capable boot medium (USB/SSD/HDD), checkpoints the installation, and boots it; on a CD/DVD, boots the live system instead. This selection is the initial default for all boot media and will be selected automatically unless ESC is pressed when prompted.

Once the system has been fully installed, the following selections are presented instead:

Unexicon i686 installed
This selection boots the current installed system. This boot selection is saved and used as the default boot selection for future reboots. This selection is also the initial default after installation. This boot selection is saved as a future default.
Unexicon recovery...
Provides a submenu of checkpoint, rollback and commit recovery boot selections. See Recovery Boot Menu, below, for more information.

If the system is only partially installed (e.g. installed to a small 4G USB flash drive), the following selection is presented instead:

Unexicon i686 persistent
This selection boots the persistent system: a live system with a limited amount of persistence. The system is capable of storing 512MB of root filesystem block changes from the original live image. However, a larger than 1GB unexicon data volume is mounted at /var/local.
This selection is the only persistent system boot option presented (and the initial default) when the boot medium was of insufficient size to install a full system. This normally occurs when the medium was smaller than 6BG in size (a 2G or 4G USB flash drive).

The following selections are always presented:

Unexicon i686 rescue
This selection boots the live system from the boot medium; copies the live image to RAM, and boots from the RAM disk; unmounts and ejects removable boot medium. The selection has the same effect as booting a rescue CD. This selection should be used for any alterations made (upgrade or installation) to a live image for an installed or target system. The booted system offers no persistence. The operator must manually mount any volumes or drives.
Unexicon live...
Provides a submenu of live boot selections. See Live Boot Menu, below, for more information.
Unexicon advanced settings...
Provides a submenu of advanced settings. See Advanced Boot Settings, below, for more information.
Boot from drive...
This option submenu allows you to chain boot existing drives. The first 4 partitions on the first 4 drives can be selected as a target to chain boot.

Live Boot Menu

This submenu provides selections for booting the live system from the live image in the first partitions of the drive or CD. Except where noted, the selections in this menu for a writable boot medium are saved and applied as the default for subsequent boots.

The following selections are always presented:

Unexicon i686 copytoram
This selection boots the live system from the boot medium; copies the live image to RAM, and boots from the RAM disk; unmounts and ejects removable boot medium. The selection has the same effect as booting a rescue CD. This selection should be used for any alterations made to the live image of an installed system.
This system offers no persistence. A data volume, if present, is not mounted at /var/local. The operator may, however, mount /var/local after login. The objective is to not touch a drive that may require recovery. On reboot, all changes made to the system are lost unless the operator mounts /var/local.
Unexicon i686 non-persistent
This selection boots the live system from the boot medium directly; the boot medium may not be removed after boot until the system is shut down. This is the default when booting from a CD/DVD. When not booting from a CD/DVD, this selection has the side effect of installing the system on the boot medium if it is not already installed.
This system offers little to no persistence. When there is a data volume present on the system, it will be mounted at /var/local. Because cached download packages are stored there, packages may be installed rapidly. On reboot, all changes made to the system are lost (with the exception of cached packages and unexicon applications that store their data in the data volume.)

The following selections are only present when the system is installed:

Unexicon i686 persistent
This selection boots the live system with a limited amount of persistence. The persistent system is capable storing 512MB of root filesystem block changes from the original live image. However, a larger than 1GB unexicon data volume is mounted at /var/local.
Only a severely limited number of packages and system updates can be applied to this system. It is, however, useful for 4G live USB sticks for management stations and access terminals. It is also useful for keeping specialized recovery tools on a rescue image.
Memory test (memtest86+)
This selection boots a native memory test binary for checking the memory on the machine. This selection is not saved.

Recovery Boot Menu

Unexicon provides advanced carrier software upgrade with checkpoint and rollback of the system image. The boot options in the recovery boot selection submenu provides fine-grained control over the process. None of the selections made in this submenu are saved: whatever default was present prior to the selection will be used as a default on the next reboot. The selections are as follows:

The following three selections are always presented:

Unexicon i686 current
This selection boots the current installed system, regardless of whether a checkpoint is set or not. It has the same effect as selecting the installed option from the main boot menu, except this boot selection is not saved.
Unexicon i686 checkpoint
This selection creates a new checkpoint of the current system, discarding any previous checkpoint, and boots into the current system. This has the effect of committing the changes to the system since the last checkpoint reflected in the current system, or establishing a new checkpoint after a rollback.

The following two selections are only be presented when a previous checkpoint is in effect:

Unexicon i686 previous
This selection boots into the system at its last checkpoint. The current system is not affected, but any changes made to the booted system are included in a future rollback.
Unexicon i686 rollback
This selection will rollback all of the changes to the installed system that were made since the last checkpoint and boot the rolled back system. It has the effect of overwriting current with previous and then booting current.

The following selection is a shortcut for booting into the "fallback" initial RAM disk of an upgraded system when the "default" initial RAM disk proves unbootable:

Unexicon i686 fallback
This selection boots the current installed system, using the "fallback" initial RAM disk, regardless of whether a checkpoint is set or not. Its sole purpose is to boot the system to repair the "default" initial RAM disk.

See Online Upgrades in this document for information on using the recovery boot options.

Advanced Boot Settings

When the operator selects any of the entries in this submenu, the settings resulting from the action is displayed for 3 seconds and the operator is returned to the main menu. The settings in this submenu affect the boot parameters for any boot of the system and, in some cases, are saved for subsequent boots. The possible selections are as follows:

The following three selections affect the target into which the system will boot:

Set default target
When selected, the system will be set to boot into the default environment (usually the same as graphical boot: default runlevel).
This is the default and recommended target for all systems.
Set graphical target
When selected, the system will be set to boot with a local graphical login (i.e. xdm graphical login: runlevel 5).
Set multi-user target
When selected, the system will be set to boot with only a local non-graphical login (i.e. console and virtual terminals: runlevel 3).
This selection should only be made if the system will not boot into a graphical environment. It is not recommended as the system will no longer support graphical login. Remote access will be restricted to ssh login only.
Set rescue target
When selected, the system will be set to boot into a rescue environment with only a single shell (i.e. console only: runlevel 1).
This target is for emergencies only and is used to boot the box without networking, users, nor virtual terminals. The system will only be accessible from local, IPMI or serial console. It is almost always better to boot the embedded live system instead. For those reasons, this selection is not saved (will not be applied to subsequent boots by default).

The following three selections affect the use of a serial console by the booted kernel:

Set auto console
When selected, the serial boot setting for the kernel will be set according to the detected serial ports. When an active USB0 port is detected, the kernel will be set to boot with ttyUSB0 as a serial console; otherwise, if an active COM1 port is detected, the kernel will be set to boot with COM1 as a serial console; otherwise, the kernel will be set to boot with the local or IPMI console.
This setting is the default and should only be set differently when the automatic console selection fails to set the correct console.
Set local console
When selected, the serial boot setting will be cleared and the system will be set to boot the kernel using the local console, regardless of whether an active serial port is detected or not. The setting is stored and used for all subsequent boots.
This selection should be used only when the automatic console selection fails to properly choose the local or IPMI console.
Set ttyS0 serial console
When selected, the system will be set to boot the kernel using ttyS0 as a serial console, regardless of whether an active COM1 port is detected or not. The setting is stored and used for all subsequent boots.
This selection should be used only when the automatic console selection fails to properly choose the COM1 console.
Set ttyUSB0 serial console
When selected, the system will be set to boot the kernel using ttyUSB0 as a serial console, regardless of whether an active USB0 port is detected or not. The setting is stored and used for all subsequent boots.
This selection should be used only when the automatic console selection fails to properly choose the USB0 console.

Drive Layout

The sections that follow detail the partitioning of drives, logical volume management, and custom partitioning.

The USB/SSD is automatically partitioned by the bootstrap loader when the USB/SSD is prepared by selecting the Unexicon i686 install boot selection in the main boot menu. The boot medium is partitioned in such way that a new live ISO image can be overwritten to the medium without destroying an installed system or persistent data.

Drive Partitioning

The bootstrap loader detects when the boot medium is a CD, DVD or other read-only media and will not offer to partition the drive in the boot menu. Otherwise, when Unexicon i686 install is selected from the boot menu, the makeusb cheat code is added to the boot to signal the bootstrap loader to prepare the USB/SSD by creating any necessary partitions. If the drive contains any partitions other than the 1st primary partition, the bootstrap program will not touch the drive at all. This means that a drive in the system can be custom partitioned makeusb will not alter its configuration.

To prepare a USB/SSD boot medium, the bootstrap loader establishes 3 primary partitions as follows:

1st primary partition:
This partition is defined by the raw ISO image and is not expected to extend beyond cylinder 511 (a 512M from the start of the disk including the boot sector and partition table). This partition is, of course, an iso9660 partition.
2nd primary partition:
A 512M partition is created starting at cylinder 512, leaving 512M for the 1st partition (including boot sector and partition table). This partition is used for a persistent disk mapper snapshot (dm snapshot) volume for use when live booting in persistent mode. This partition is configured as an ext4 partition with a filesystem label of unxcowspace. If a ext4 filesystem already exists at cylinder 512, the bootstrap program will not touch it. If the drive has less than 1024 cylinders, the remaining cylinders from cylinder 512 are allocated to the second partition.
3rd primary partition
The remaining disk in a single partition that contains all of the remaining cylinders on the disk minus the 1024 cylinders reserved for the first two partitions. When the disk is smaller than 1536 cylinders (e.g. a 1G USB flash drive), this partition is not created. This partition is configured as a LVM2 partition.

The 4th primary partition or 5th, 6th, 7th extended partitions are available for use for custom installations.

Logical Volume Manager

The 3rd primary partition on the USB/SSD extends from cylinder 1024 through to the end of the disk and is configured as an LVM2 partition. If a volume group named Unexicon already exists (likely at cylinder 1024), then the bootstrap program will not touch it. Otherwise, the bootstrap program creates a physical volume using the 3rd primary partition and creates a volume group named Unexicon.

Unexicon/boot (LABEL=unxboot)
When the Unexicon volume group is of sufficient size, a boot volume is established. If the boot volume already exists, the bootstrap program will not touch it; otherwise, the volume's contents are created from the live image. The live image is block copied into the volume. The contained ext4 filesystem is expanded to the size of the volume, and then some configuration is performed on the root filesystem contained to change it from a live image to an installed image. The filesystem is relabelled as unxboot.
Unexicon/swap (LABEL=unxswap)
When the Unexicon volume group is of sufficient size, a swap volume is established. If the swap volume already exists, the bootstrap program will not touch it; otherwise, a swap filesystem is established and labelled unxswap. When the volume group is of insufficient size to allocate a swap volume, the system will be unable to suspend to RAM.
Unexicon/snap (LABEL=unxboot)
When the Unexicon volume group is of sufficient size, a snap volume is established. If the snap volume already exists, the bootstrap program will not touch it; otherwise, a volume is established. When the volume group is not of sufficient size to establish a snap volume, the unexicon checkpoint and rollback features will be unavailable.
This volume contains a snapshot of the boot volume and is initially established as a checkpoint of the installed system image. As a snapshot, it appears to have a disk label the same as the boot volume and appears to contain an ext4 filesystem.
Unexicon/data (LABEL=unxdata)
When the Unexicon volume group is of sufficient size, a data volume is established. If the data volume already exists, the bootstrap program will not touch it; otherwise, one is established. An ext4 filesystem is created on the volume and the filesystem is labelled unxdata. This volume will be mounted on /var/local by a live, persistent or installed boot.
This volume is intially empty and may be manipultated (resized, different filesystem) immediately after installation. Additional logical volumes can be established in the room resulting from resizing this logical volume. On need for this is to establish a snapshot volume for independent backup and recovery of the data volume.
USB/SSD size to volume size mapping
units: Gbytes—(1024x1024x1024) bytes
* size boot swap snap data
CD/DVD
§ ~2.0 G ~1.0 G
§ ~4.0 G ~3.0 G
~8.0 G  2.0 G  2.0 G ~3.0 G
~16.0 G  4.0 G  4.0 G  2.0 G ~5.0 G
  ~32.0 G  8.0 G  8.0 G  4.0 G ~12.0 G
  ~64.0 G  12.0 G  12.0 G  6.0 G ~34.0 G
  ~128.0 G  16.0 G  16.0 G  8.0 G ~88.0 G
 ¶  Useful for rescue boot only.
 §  Useful for CD/DVD replacement.
 †  Not recommended for production.
 ‡  Checkpoint constrained.

How the volume group is set up depends on the size of the physical volume (USB/SSD/HDD). The table, at the right, summarizes the allocations.

1G USB ( ≤ 1500 cylinders)
Unusable.
2G USB ( ≤ 3000 cylinders)
The bootstrap program will only allocate the data volume. The volume can grow to the entire volume group size (from 0.5 to 2G, nominal 1G). The system will only be able to run live and with minimal persistence and will be unable to suspend to RAM. Not usable for a deployment platform.
4G USB ( ≤ 6000 cylinders)
The bootstrap program will only allocate the data volume. The volume can grow to the entire volume group size (from 2 to 5G, nominal 3G). The system will only be able to run live and with minimal persistence and will be unable to suspend to RAM. Not usable for a deployment platform.
8G USB ( ≤ 12000 cylinders)
The bootstrap program will allocate 2G to swap, 2G to boot and the remaining space (1 to 7G, nominal 3G) to data. The system will be able to run live or installed and suspend to RAM, but will be unable to perform checkpoint and rollback. Space will be constrained for a full blown workstation: not usable for a deployment platform.
16G USB/SSD ( ≤ 24000 cylinders)
The bootstrap program will allocate 4G to boot, 4G to swap, 2G to snap and the remaining space (1 to 13G, nonminal 5G) to data. The system will be able to run live or installed, suspend to RAM and perform checkpoint and rollback. Checkpoints are limited to 2G in block changes between the current and checkpointed system image. Checkpoints will be lost for updates greater than this size. Space is adequate for a full blown development workstation. Not recommended for a deployment platform due to checkpoint constraints.
32G USB/SSD/HDD ( ≤ 48000 cylinders)
The bootstrap program will allocate 8G to boot, 8G to swap, 4G to snap and the remainder of the disk (4 to 18G, nominal 12G) to data. The data volume can be resized to make room for a data snapshot volume. The system will be able to run with all features without size constraints. This is the minimum size recommended for a deployment platform.
64G USB/SSD/HDD ( ≤ 96000 cylinders)
The bootstrap program will allocate 12G to boot, 12G to swap, 6G to snap and the remainder of the disk (17 to 65G, nominal 34G) to data. The data volume can be resized to make room for a data snapshot volume. The system will be able to run wtih all features without size constraints.
128G and over USB/SSD/HDD ( > 96000 cylinders)
The bootstrap program will allocate 16G to boot, 16G to swap, 8G to snap and the remainder of the disk (55G or larger, nominal 88G) to data. The data volume can be resized to make room for a data snapshot volume or other needed volumes. Primary partition 4 or extended partitions 5, 6 and 7 are available for additional physical volumes. The system will be able to run wtih all features without size constraints.

Custom Partitioning

Unlike some distributions that provide custom partitioning as part of their install process, unexicon establishes the necessary partitioning itself. However, because the install option to the bootstrap program will be ignored if the disk is already partitioned or the volume group exists, it is possible to custom partition a USB/SSD/HDD using the rescue image before booting it for the first time or installing it.

Networking

The sections that follow detail the networking setup.

Unexicon networking is set up to be as automatic as possible. In many network configurations it is possible to not do any network configuration on the unexicon platform whatsoever.

DHCP

In general, no network interface IP address configuration is necessary for a unexicon platform.

Each unexicon platform attempts to obtain network addresses for all of its interfaces on VLAN ID 0 (i.e. the base ethernet) using DHCP. When DHCP fails to obtain an address, IPv4 link-local (zero-net) addresses in the 169.254.0.0/16 network will be assigned using proper IPv4 zero-net link-local procedures. mDNS and DNS-SD procedures will be established to advertise services from all platform regardless of IP address assignment.

Static IP addresses can be assigned using the dhcpcd-ui(1) tool from the system-tray of a graphical login; however, it is recommended that you establish a proper primary DHCP server for static assignments instead, when necessary, and in all but the most trivial of network configurations.

IP addresses on VLAN ID 0 are only necessary for contacting the outside world, as most inter-nodal communications (even with management stations) is performed over the VLAN ID 557 bridge VLAN. See VLANs and Bridging in this document for more information on VLAN ID 557.

Unexicon platforms are already configured to observe and support many DHCP server fields, including default routes, NIS servers, NTP servers, routers, and others. See /etc/dhcpcd.conf for the entire list. The list is much longer than normally supported by a default Linux installation.

It is not necessary to define IP addresses on the local ethernet to unexicon platforms at all, provided that some platform (even a unexicon box with a non-link-local interface) can NAT and provide a default route out of the link local network. Any unexicon platform with an established public address will automatically perform this role.

Also see Routing in this document. Using a number of routing protocols, a unexicon platform can also find its way out of a link-local network without additional IP address assignments.

VLANs and Bridging

To automate unexicon platform networking to as high a degree as possible, the platform establishes an STP bridged VLAN that traverses all non-public interfaces. This bridged VLAN is used for inter-platform communications, self-organizing fault-tolerant clustering, and management discovery. To accomplish this, each unexicon platform performs the following on boot (after establishing VLAN ID 0 IP addresses and configuration):

Your network should be configured to:

Firewalling

Firewall configuration is automatic. A unexicon platform uses a ferm(1) script to establish iptables(8) based firewalls automatically.

The firewall treats all interfaces with public network addresses with suspicion, and trusts all interfaces without public network addresses.

Routing

To facilitate automatic routing and full connectivity, each unexicon platform acts as an IP router and participates in a number of routing protocols. Each platform participates in RIP, OSPF an BABEL protocols. Each platform redistributes its routes and actively participates on all private-network interfaces. Passive RIP, OSPF and BABEL operation is performed on all public interfaces.

NTP

To facility tightly synchronized timing between unexicon platforms, each platform participates as both a NTP server and NTP client. It utilizes unicast connections to all NTP servers advertised by DHCP servers. It also participates in broadcast on the local LAN and multicast on trusted interfaces. Configuration is automatic and need not be adjusted. If a number of low-stratum NTP servers are already configured on your network, each platform will converge on them. In the absence of local NTP servers, any unexicon platform with a route to the public network will home off of NTP pool servers.

mDNS and DNS-SD

To facilitate zero-configuration networking, each unexicon platform participates in multicast-DNS and DNS service discovery protocols on all trusted interfaces. Each platform advertises a list of services including HOST, SSH, XDMCP, VNC and SNMP.

XDMCP

Each graphical-booted unexicon platform runs an XDM (X Display Manager) and advertises willingness to manage remote X11 clients by responding to broadcast queries. Each platform can establish X client sessions and provide XDM login services. In addition, XDCMP services are advertise using mDNS and DNS-SD. XDMCP discovery tools are included in the live image that provide network discovery of unexicon platforms in a local network. By also participating in the bridged VLAN, unexicon platforms running on management stations are able to obtain a graphical login to any unexicon platform in a local network. Using the facilities described under PPTP in this document, all platforms can also participate in management from a centralized NOC.

NIS

Each unexicon platform will configure itself for remote logins from NIS users when provided with an nis-servers option from a DHCP server on network boot. NIS servers may also be established manually (by editing /etc/nisdomain and enabling the domainname, ypbind and autofs systemd services). As with other situations, centralized administration with a properly configured primary DCHP server is recommended for all but trivial networks.

PPTP

Each unexicon platform is capable as acting as a VNC server or client using PPTP.

When acting as a PPTP client and a a PPTP server is identified by a DHCP server, the platform will establish a VNC connection to the PPTP server and offer routes to the NOC to other platforms on the network. Static PPTP server definitions can be established using the nm-applet(1) tool that appears in the system tray of a graphical login to the platform; however, we recommend that DHCP servers be configured to centralize administration in all but the most trivial of networks

When acting as a PPTP server, each unexicon platform will accept incoming connections and proxy the remote client in a local LAN in the address range 10.55.4.0/21. When internet facing, the unexicon platform will perform this function automatically. When acting behind a firewall, you can DNAT PPTP traffic to the server and it will automatically serve a unexicon NOC on the local LAN to the PPTP client.

Direct Connections

The suite of automatic networking provided by a unexicon platform supports local direct network connections using active USB cables. Active USB cables can be directly connected between a mobile management station (e.g. a notebook running unexicon as a management station) and any unexicon platform. Simply connecting the cable between the management station and a front USB port on the platform will establish a zero-configuration network between the two boxes and advertise to the management station all available services.

See the unexicon hardware page for more information on availability and supported cables.

Logins

Administrative Login

Unexicon, unlike some server-only distributions, is tuned for graphical login accounts. Both platforms acting as management stations and deployment platforms provide graphical boot and login services using lightweight window managers and an integrated unexicon XDE desktop environment.

Management an analysis applications, however, should of course be run from dedicated management stations rather than being run on a deployment platform directly.

User Accounts

The live, persistent and installed systems have two user accounts defined: root and unexicon. Both accounts are assigned default passwords that must obviously be changed.

Normal Linux user account tools and commands can be used to manage these user accounts.

root
Graphical and remote logins to the root account are not blocked by default. You should make changes to the appropriate configuration files if you want to change this behaviour. One easy and secure way to block all root logins is to remove the root password.
The default root password must be changed, preferably before the system is network connected.
As with any Linux system, root logins should be avoided unless absolutely necessary. Most (if not all) administrative activities should be taken from the unexicon administrative account.
unexicon
This is the administrative account for the system.
The unexicon user account is assigned user id 1000 and group 1000.
The account is a member of the wheel group and almost all other administrative groups.
The unexicon user account has sudoers privilege to execute commands as root without being prompted for a password. Remote logins to this user are permitted.
The user's home directory is /home2/unexicon: /home2 is used instead of /home to avoid conflict with NIS autofs mounted home directories.
remote accounts
Unexicon is set up to permit remote access to the system using NIS, provided that a DHCP server is configured to instruct the system to bind to a NIS domain on the local network and the NIS maps define access from remote users.
local accounts
Additional local accounts can be created using the normal Linux account management tools that are included on the base distribution or are available from Arch Linux repositories.

Upgrade

Live Release Upgrade

Due to the unique layout of the unexicon drive partitioning, it is possible to upgrade the live image on an installation by simply overwritting the USB/SSD/HDD with the new ISO image. Upon booting the "Unexicon i686 install" boot menu selection, the previous partition table will be restored and only the live image in the first primary partition and outdated persistent snapshots in the second primary partition will be altered. The logical volumes in the third primary partition will remain untouched. A subsequent boot into the "Unexicon i686 installed" boot menu selection will reboot into the untouched installed system. In this way the live image and boot scripts can be upgraded on an installed distribution. Follow the same steps outlined above under "Preparing an SSD."

Software Modules

Software modules provided on the unexicon modules page attempt to automate the software installation and management as much as possible. Modules can be installed from a unexicon system by merely clicking on the provided link.

Nevertheless, those that are responsible for maintaining unexicon platforms should familiarize themselves with the Arch Linux pacman(8) and yaourt(8) package management tools starting with the Arch Linux pacman wiki page and the manual pages for these commands provided on the unexicon live image and installed systems.

Repositories

Unexicon provides software repositories compatible with the Arch Linux package management tools and core repositories available at the Arch Linux website and mirrors. The unexicon repository definition and software signing keys are incorporated into the release and live image. The Arch Linux repositories provide thousands of binary packages supported in its core repositories.

The unexicon repositories served from the unexicon website currently provide 232 binary software packages that are maintained by unexicon and not provided elsewhere as binaries, only provided in the AUR as source, or not provided elsewhere at all. 138 of these packages are included in the live image's 771 installed packages. See the unexicon software page for a full listing of software included in the live image.

Online Upgrades

The unexicon distribution is designed to permit full checkpoint and rollback of online upgrades for installed systems. The Unexicon/snap volume is used to perform the checkpoint. After upgrade and stress testing, the upgrade checkpoint can be discarded and the upgrade committed, or the system can be rolled back by booting into the checkpoint device-mapper snapshot image and later discarding the upgrade. The operational database in the 3rd partition is excluded from the rollback to allow database updates to persist across the rollback.

The checkpoint, rollback and commit capability for software upgrade is performed as follows:

  1. When the system upgrade is scheduled, the system is first rebooted.
  2. Upon reboot, ESC key is used to bring up the boot menu.
  3. The submenu "Unexicon recovery..." is selected from the main boot menu.
  4. The selection "Unexicon i686 checkpoint" is selected from the submenu, and the system boots into a checkpointed system.
  5. The system software is upgraded using any means: selecting modules from the unexicon modules page, selecting upgrade from the pk-applet(1) in the system tray on the unexicon login, or executing yaourt -Syu.
  6. The system is placed online and tested. Differences between the system and the checkpointed system can be examined by mounting the /dev/mapper/Unexicon-snap device and comparing the changes with the root directory.
  7. If the system proves to be adequate, it can be left running. The previous checkpoint will remain until another checkpoint operation is performed.
  8. Should the system prove inadequate, there are two steps that can be taken:
    1. Reboot into the previous system at the checkpoint by selecting "Unexicon i686 previous" from the boot recovery submenu. This will boot into the system as it was before the upgrade. The system can be compared online with the upgraded system by mounting /dev/mapper/Unexicon-boot and comparing the changes with the root directory.
    2. Perform a rollback to the previous checkpoint by selecting "Unexicon i686 rollback" from the boot recovery submenu. This will boot into the system as it was before the upgrade, and the upgraded system is abandoned and discarded.

Incremental checkpoints of the system can be performed at any time by selecting "Unexicon i686 checkpoint" from the boot recovery submenu. Bear in mind, however, that the previous checkpoint is discarded when this item is selected. Only stable and trusted system configurations should be checkpointed. Stable and trusted deployed systems should be checkpointed on a regular backup schedule to avoid loosing stable changes since the last checkpoint.

Offline Backup and Restore

A checkpointed system can have its system image backed-up to offline storage by mounting the /dev/mapper/Unexicon-snap device and dumping the filesystem from the device to the off-line storage.

A checkpointed system can have its system image restored from offline storage by mounting the /dev/mapper/Unexicon-snap device and restoring the filesystem to the device from off-line storage. The checkpointed system can then be run or rolled back by rebooting using the "Unexicon i686 previous" or "Unexicon i686 rollback" options (resp.) from the boot recovery submenu.

Note, however, that the /dev/mapper/Unexicon-snap device should not be backed-up or restored when the system is booted with "Unexicon i686 previous," because in that case the "/dev/mapper/Unexicon-snap" device is mounted as the root filesystem.