Finnix for VPS providers
Finnix, the LiveCD for system administrators
Finnix is perfectly suited for Virtual Private Server (VPS) providers, as a means of offering customers a bootable distro with a wide range of tools to help administer and recover operating systems on their VPS account. Finnix has been around for over 10 years and provides a very stable system administration platform. Releases are made approximately quarterly, but individual releases "age" well, so you do not have to keep up to date every time a new Finnix release is made. Yearly would be a good target for VPS providers, unless customer needs necessitate more frequent updates.
This page provides information for VPS providers on how to integrate Finnix with your platform. If you are a VPS provider and would like assistance with providing Finnix to your customers, please email email@example.com.
Finnix is normally booted as a CD-based distribution. The bootloader (isolinux) loads a kernel and initial ramdisk (initrd). The initrd scans the PCI bus, loads driver modules found on the initrd, scans for block devices and attempts to mount each one. If one of the block devices contains a Finnix CD, the initrd mounts it, then mounts the compressed root filesystem located as a file on the CD. This filesystem is a SquashFS filesystem, and provides transparent compression/decompression. Finnix mounts a tmpfs ramdisk (defaulting to up to 80% of the available memory), and combines the compressed root and the ramdisk via a union filesystem (UnionFS or AUFS, depending on the version of Finnix). It then pivots the root to the union filesystem.
Once the union filesystem becomes the root filesystem and the PID 1 init is in place, the running initrd is destroyed. Finnix then scans the PCI bus, loading more modules (this time with more modules available available on the compressed root). It scans for disks, updates /etc/inittab, scans for LVM/dm-crypt/RAID devices to setup, sets up console services, and starts a DHCP client. The user is then dropped into a root shell. There are no daemons started by default, and the passwords for "root" and "finnix" are disabled, but the user can then quickly set a temporary password and start an SSH daemon if they want, for example. Or the user can continue to work directly from the console.
Full virtualization VPS
If you run a VPS based on full virtualization such as VMware, VirtualBox, KVM, QEMU, etc, there is very little you need to do. Simply set up the guest profile's main OS disks, but tell the virtualization to boot the Finnix ISO. Finnix should run just like any other operating system.
Xen is a powerful paravirtualization technology for maintaining a Linux VPS, though with paravirtualization comes the need for special operating system support. Finnix is fully aware of Xen guests, and will automatically set up the necessary changes need to be run in a Xen session. These include:
- Setup of /dev/xvd* block devices and /dev/hvc* consoles
- Modifying /etc/inittab to use /dev/hvc0 as the console terminal
- Skipping setting of the hardware clock, console font and keyboard table
- Skipping the shutdown/reboot countdown at the end (normally used to allow the user to remove the CD before shutdown)
As of Finnix 102 (Linux 3.0), the Finnix-supplied AMD64 kernel contains DomU functionality, and Finnix is able to fully utilize this functionality without any sort of modification. Simply extract the kernel (/isolinux/linux64) and initrd (/isolinux/initrd.xz) from the ISO and use them to boot Finnix.
The 32-bit kernel does not contain DomU functionality, you must use the AMD64 kernel.
You may also compile your own kernel, based on the needs of your platform. From a kernel defconfig, this is the BARE MINIMUM needed to boot Finnix (as of Finnix 101, Linux 2.6.36):
- CONFIG_AUFS_FS=y or CONFIG_UNION_FS=y
All options are available in a vanilla kernel, with the exception of the last line. Neither UnionFS nor AUFS are included with vanilla kernels, though many distros patch them in (usually AUFS). As of Finnix 101, Finnix supports either UnionFS or AUFS automatically, but you will need to manually patch one of these in. You can pick whichever one is best suited for your target kernel release.
Again, this is the bare minimum needed to boot Finnix from a kernel defconfig; other kernel options, such as CONFIG_TMPFS are required for Finnix operation, but are already selected as part of defconfig on modern Linux kernels. Conversely, a bare minimum defconfig does not provide much in terms of kernel features to your users. It is recommended that you use a similar kernel config to what you normally provide users to boot regular distros, and add UnionFS/AUFS support.
A modular kernel is possible, though it would require remastering the CD to add the module trees to both the compressed root and the initrd. Because of that, it is preferred that you use a monolithic kernel with all functionality built in to avoid trouble. If you do go the modular/remastered route, there is one kernel option that must be compiled into the main kernel: CONFIG_XEN_BLKDEV_FRONTEND=y. (Update: As of Finnix 102, xen_blkfront may be compiled as a module and placed in the initrd.)
Finnix is distributed as a 32-bit userland operating system, but will work with either 32-bit or 64-bit kernels. If you are using Xen, it is recommended you compile as ARCH=x86_64 to provide to customers. Even with a 32-bit userland, a 64-bit kernel is useful to execute static 64-bit binaries, chroot into 64-bit file trees, or effectively utilize over 4GB of memory.
Once your kernel is compiled, boot the guest with the following pseudo config:
- Kernel: Your custom Finnix-specific kernel
- Initrd: Your custom initrd if remastering, otherwise /isolinux/initrd.gz copied from the CD
- Kernel command line: None needed, "quiet" recommended
- /dev/xvda: Normal customer profile hard drive image
- /dev/xvdb: Normal customer profile swap image
- /dev/xvdh: Your custom ISO if remastering, otherwise the Finnix release ISO
The disk ordering is not important to Finnix; Finnix will find itself on any block device. This example layout is recommended so the customer's hard drive image and swap image are in the same locations as where they would normally be.
A sample Xen configuration would be:
kernel = "/path/to/backend/finnix/linux64" ramdisk = "/path/to/backend/finnix/initrd.xz" extra = "quiet" name = "finnix" memory = "128" disk = [ 'file:/path/to/guest/root.img,xvda,w', 'file:/path/to/guest/swap.img,xvdb,w', 'file:/path/to/backend/finnix/finnix.iso,xvdh,r', ] vif = [ 'bridge=br0', ]
User Mode Linux
User Mode Linux (UML) is an older virtualization technology that allows one Linux system to boot another completely in userspace (that is, the guest Linux kernel is simply a program running on the host, but once inside the guest, it is presented as a fully segmented operating system). UML isn't used much by commercial VPS providers anymore, but is nonetheless recognized and handled by Finnix, much like Xen support.
Many of the same topics discussed in Xen above apply to UML as well. You will need a recent UML-compiled Linux kernel with UnionFS/AUFS support. Then simply start the UML kernel with the necessary initrd, customer profile drives, and Finnix ISO.
If you do not provide virtual console access to your customers, Finnix may be configured to automatically start an SSH daemon on bootup. To do so, present the following boot parameters to the kernel:
If you do not use sshd_password, a password will be randomly generated and displayed on the console, so it should be up to your management system to create a necessary temporary password (or let the customer pick one), set it via sshd_password, and present the password to the customer.
As of Finnix 102, it is possible to set IPv4 IP addresses directly as guest kernel arguments.
ip_int=eth0 ip_eth0_v4addr=192.168.2.2 ip_eth0_v4netmask=255.255.255.128 ip_v4gateway=192.168.2.1 ip_dns=192.168.2.10,192.168.2.11 ip_search=domain.lan,otherdomain.lan
If ip_int is set, DHCP will not be attempted on any interfaces. IPv6 configuration is not yet possible.
- ip_int: List of comma-separated interfaces to configure.
- ip_$INT_v4addr: IPv4 address for the interface. Required for each specified interface.
- ip_$INT_v4netmask: IPv4 netmask for the interface. Optional, set to 255.255.255.0 if not specified.
- ip_v4gateway: IPv4 default gateway. Optional.
- ip_dns: List of comma-separated IP address nameservers (for resolv.conf). Optional, Google DNS servers will be used if not specified.
- ip_search: List of comma-separated domains to search (for resolv.conf). Optional.
- ip_domain: Primary domain (for resolv.conf). ip_search overrides this option. Optional.