Documentation

The fastest approach is to download the XenServer® .xva Image from the download section and import it into your running XenServer® via XenCenter®. With this you have all things setup including the Virtual HardDrive for the systemVM.

Create the systemVM (see section "Create systemVM on XenServer®") and continue with section "Configuration Files Overview". Afterwards you are ready for system building.

Create XenServer® Virtual Machines

a) Build VM (where your linux system will be compiled and linked) we call it "buildVM" as referenced later.

b) System VM (where your compiled system will be run after building) we call it "systemVM" as referenced later.

Import buildVM via Command Line

> import buildVM

# xe vm-import filename=download.xva

Create buildVM via Command Line

If you did not already imported the provided .xva image, you can feel free to set up your own build Virtual Machine on your XenServer®.

> create networks

# xe network-create MTU=9216 name-description="build-net1" name-label="build-net1"

> create vm from base template (here with 4GB memory and 4CPU)

# xe vm-install new-name-label="build01.xen01-int" template="Other install media"
# xe vm-memory-limits-set uuid=$VM_UUID static-min=4096MiB dynamic-min=4096MiB dynamic-max=4096MiB static-max=4096MiB
# xe vm-param-set VCPUs-max=4 VCPUs-at-startup=4 uuid=$VM_UUID

> create virtual disc image/block device

# xe vdi-create sr-uuid=$SR_UUID type=user name-label=build01.xen01-int.media.root virtual-size=20GiB
# xe vbd-create vdi-uuid=$VDI_UUID vm-uuid=$VM_UUID bootable=true type=Disk device=hda

> attach nics to VM (customize to your network needs)

# xe vif-create device=0 network-uuid=$NW_UUID vm-uuid=$VM_UUID

Create systemVM on XenServer®

To see the Installation Result you need to create the systemVM on the XenServer® where the buildVM resides. Be careful, you have to assign the VDI temporarily to the buildVM. After building you clone the VDI to the systemVM, now you can customize, create VM snapshots/templates for later reuse.

Partitioning: Re-Check the Parition Setup in Monolith-Linux config file with XenServer® Setup, else you get Install Errors.
Be clear: the VDI Image for the systemVM will be attached to the buildVM, because the build process will use for installation. After the install process you clone this partition and attach it to the final systemVM.
> create vm from base template (here with 1GB memory and 2CPU)

# xe vm-install new-name-label="dummy01.xen01-int" template="Other install media" # xe vm-memory-limits-set uuid=$VM_UUID static-min=1024MiB dynamic-min=1024MiB dynamic-max=1024MiB static-max=1024MiB
# xe vm-param-set VCPUs-max=2 VCPUs-at-startup=2 uuid=$VM_UUID

> create virtual disc image/block device

# xe vdi-create sr-uuid=$SR_UUID type=user name-label=fs01.xen01-int.media virtual-size=30GiB

> attach to "buildVM" as hdb

# xe vbd-create vdi-uuid=$VDI_UUID vm-uuid=$VM_BUILD_UUID bootable=false type=Disk device=hdb

> attach nics to VM (customize to your network needs)

# xe vif-create device=0 network-uuid=$NW_UUID vm-uuid=$VM_UUID

SSH Default User Settings

After importing or installing the buildVM or after compiling and starting the systemVM you want to login to the machines via SSH. Both buildVM and systemVM have following default usernames and passwords set. The systemVM ssh base user and root PWD can be customized via configuration files (described later).

Be careful: The buildVM is a default Ubuntu with a configured sudo, so if you want to get root, you have to "sudo su -". The systemVM with Monolith-Linux on, does not provide a proper sudo config on the first install, you have to do a simple "su -" to get root.

> buildVM

ip: 192.168.0.1/24
xen if: physical network 0

user: admin
pass: adminadmin

user: root
pass: rootroot

> systemVM

user: root
pass: rootroot

Depacking/Cloning

a) depacking

> start buildVM

# xe vm-start uuid=$VM_UUID

> depack monolith linux

# tar -xf monolith-linux-0.2.tar.bz2

> depack monolith-linux templates

# tar -xf monolith-linux-0.2-demo-templates.tar.bz2

b) cloning

> see: Download

Symlinking the (Demo) Templates

If you setup an own buildVM via download or GIT, you have to symlink the templates to the main system template dir.

> symlink templates (domain) to monolith template dir

# cd monolith-linux-0.2/template
# ln -s ../../monolith-linux-0.2-templates/sfl04.b.webcodex.de

Template Configuration Files Overview

Config FileShort Description
> local.confmain config file
> make.confmake settings, cflags
> kernel.conflinux kernel configuration file, see http://www.kernel.org
> partitions.txtpartition setup
> sysctl.configsystem control settings
> sysctl_interface.confsystem control network interfcaces settings
> packages_additional.confconfigure additional source code to compile
> ssh/sshd_configsecure shell server configuration file
> ssh/pub.keyssh login user public key which gets autodeployed
> sysconfig/consoleconsole settings
> sysconfig/iptablesfirewall iptables settings
> sysconfig/networkhostname
> sysconfig/network-devices/*single network interface config

Configuration Files explained

> local.conf
Constant NameValues   Description
INSTALL__on_host0|10: Install Virtual (on XenServer® VM)
1: Install on HW Host
NET__hostnamestringHostname. e.g. "dummy01". Will be automatically set in /etc/hostname, /etc/hosts and /etc/sysctl.conf (kernel.hostname).
NET__domainstringDomainname. e.g. "webcodex.de". Will be automatically set in /etc/sysctl.conf (kernel.domainname)
NET__devicestringInterface which will be configured for install (if internet or else is required). e.g. "eth0"
NET__ipstringIPv4 Address. e.g. "10.0.0.1"
NET__netmaskstringIPv4 Netmask. e.g. "255.0.0.0"
NET__default_gw_ipstringIPv4 Default Gateway. e.g. "10.0.0.254"
NET__nameserver1stringIPv4 First Nameserver used for resolving. e.g. "123.123.123.123"
NET__nameserver2stringIPv4 Second Nameserver used for resolving. e.g. "123.123.123.123"
FS__devicesstringDevice List which will be used while installation. e.g. "xvda"
FS__devices_install_hoststringIn Case of Virtual Install (INSTALL__on_host==0), device(s) which will be used instead.e.g. "xvdb"
FS__mk_disklabel0|1Activate Disklabel Writing
FS__mk_disklabel_xvd%msdosMake MSDOS Disklabel on specified xvd% Device
GRUB__install_devicestringInstall GRUB on specified device. Be careful, for a virtual install this is the partition on the VM INSTALLER HOST. e.g. "/dev/xvdb" for /dev/xvda on the later SYSTEM HOST partition.
GRUB__install_partitionstringDefine GRUB install partition. This is the partition on the SYSTEM HOST. e.g. "hd0,msdos2"
GRUB__root_partitionstringDefine GRUB root partition. This is the partition on the SYSTEM HOST. e.g. "xvda2"
GRUB__boot_timeoutintDefine GRUB boot timeout in seconds. e.g. 60
GRUB__boot_default0|1Define GRUB boot default.
GRUB__boot_fallback0|1Define GRUB boot fallback.
ARCH__systemstringDefine system architecture. At the moment, the default value of "X86_64" should not be changed.
GLIBC__minimal_locales0|1If set to 1, just install EN_US and DE_DE locales.
GLIBC__timezonestringGLIBC Timezone. e.g. "Europe/Berlin"
KERNEL__versionstringLinux Kernel Version. e.g. "linux-3.2.56"
KERNEL__namestringComplete Linux Kernel Name. e.g. "vmlinuz-3.2.56-1-hardened"
GLOBAL__debugintDebug Level, for the dummy template set to 100. 0 disables debug output completely.
ROOT__pwdstringEncrypted Root Password. Will be used to set root Password at installation time. SHA512 Format.
SSH__login_userstringAdditional User who will be created at installation time. e.g. "admin"
SSH__login_user_shellstringAdditional User Shell. e.g. "/bin/bash"
SSH__login_user_pwdstringEncrypted Additional User Password. Will be used to set user Password at installation time. SHA512 Format.
SSH__login_user_auth_key0|1Auto Deploy SSH Public Key for additional User.
> partitions.txt
Column  TypeValueDescription
1Partition Typeprima|exten|logic  Partition Type: Primary, Extended, Logical.
2DevicedevicenameDevice Name, e.g. sda1|xvda1|xvdb2.
3InstallDevicedevicenameInstall Device Name, for virtual install where Device Name while Installation differs from later SystemVM Device Name.
4Partition Type82,83Partition Type. 82=Linux Swap, 83=Linux, 85=Linux Extended.
5Filesystem Typeswap,ext3Filesysten Type. swap, ext3, ext4, etc.
6Sizex[M|G]Filesysten Size, e.g. 2000M or 20G.
7Boot0|1Bootable Partition.
8Mount Point/mnt/fooPartition Mountpoint.
9Mount Optionssw,noatimePartition Mount Options.
10LabelstringLabel Name.
11Filesystem Options-Filesystem Options.
12Filesystem Dump0|1Filesystem Dump enables/disabled.
13Filesystem Check Order0-9Filesystem Check Order.

Building

The dummy01 template shipped with the Monolith-Linux Distribution is optimized for Intel X86_64. Following Compiler Flags (make.conf) have been set as default (-march=corei7 -O3) with 6 building threads (make -j6).

> now start building the system with template domain "sfl04.b.webcodex.de" and profile "dummy01".

if you are using the .xva image, then login as user admin (password: "adminadmin") and
# cd /home/admin/monolith-linux-0.2

# sudo ./sys/installer.sh -d sfl04.b.webcodex.de -p dummy01

Clone Build Virtual Disc Image

After building you should clone the install Virtual Disc Image and attach it to the systemVM. You can of course detach and attach the install Virtual Disc Image directly, but then you loose your build "snapshot".

> find the correct VDI_UUID

# xe vm-list
get UUID for vm-name "buildVM"

# xe vbd-list | grep -A 2 -B 2 $VM_UUID

for all relevant buildVM connected VBDs , we have to check if vdi-name-label="systemVM"
# xe vbd-param-list uuid=$VBD_UUID
as well the correct vdi-uuid is listed. use this one to clone in the next step.

> clone build partition. write down the VDI_UUID for later deletion if something fails you have to re-clone the VDI.

# xe vdi-clone uuid=$VDI_UUID new-name-label="systemVM-tmp-clone" new-name-description="systemVM-tmp-clone"

> connect build device to VM

# xe vbd-create vdi-uuid=$VDI_UUID vm-uuid=$VM_SYSTEM_UUID bootable=true type=Disk device=hda

Start systemVM

If you already created the systemVM and did attach the VDI/VBD to it, now start the systemVM and check if everything went fine.

> check console bootup

if something went wrong, you have to fix config and recompile.

> check ssh login

if you can not login, check your network settings. you can use XenServer® Console under XenCenter® to edit the configs directly.

> check base security

use checksec.sh (find under /sys/security) to inspect if the binary/library files have correctly been built with all security enhancements. checksec.sh is from TRAPKIT.de

# checksec.sh --dir /bin/
# checksec.sh --dir /sbin/
# checksec.sh --dir /usr/bin/
# checksec.sh --dir /usr/sbin/
# checksec.sh --dir /lib/
# checksec.sh --dir /usr/lib/

some of the binaries are not built with all security features active, but this does not mean a lack of security. nevertheless it should be analyzed if the specified source code can be fixed to build the binaries with all security features enabled.

Beyond Installation - Monolith Linux Structure

System Structure Main

/build
|-/src - build sources
/config - internal config files
|-/etc - config files used as templates for system installation
| |-/init.d - modified LFS bootscripts (iptables, asterisk added)
/sys - internal code
| |-/compile
| | |-stage1 - stage1 build scripts
| | |-stage2 - stage2 build scripts
| |-/compilescripts - additional source compile scripts
| |-/installscripts - additional source installation scripts (POST install scripts)
| |-/misc - misc scripts, e.g. version-check
| |-/security - security scripts, e.g. checksec.sh
/template (symlinked templates)

System Structure Templates

/$domain - domain name
|-/$profile - profile name, profile base dir
| |-/ssh - ssh based config files
| |-/sysconfig - /etc/sysconfig
| | |-/network-devices - network interface configuration

 

>>> hosted by apache webserver on gentoo hardened os
http://www.apache.org
http://www.gentoo.org