Meefik's Blog

Freedom and Open Source

Using Linux Deploy CLI on desktops

26 Jan 2016 | linuxdeploy

Despite the fact that initially Linux Deploy (abbreviated LD) was conceived as an application for Android, over time there are other options for its application. With the Linux Deploy CLI, a number of new features have become available that open up new uses for the tool.

Linux Deploy CLI is a command-line application designed to automate the process of installing, configuring, and running GNU/Linux distributions inside a chroot container. The application can work both in ordinary desktop Linux-distributions and on mobile platforms based on the Linux kernel, provided that the necessary dependencies are observed (all dependencies can be collected statically). Applications from the Linux distribution run in a chroot environment, operate in parallel with the main system, and are comparable with it in terms of speed. Since the work of Linux Deploy is based on a system call to the Linux kernel, only Linux distributions can act as guest systems.

The application can work in two modes: with superuser rights (chroot) and without them (proot). In normal mode, all supported installation types are available: installation in a file, on a disk partition (logical disk), in a POSIX compatible directory and in RAM (tmpfs). In proot mode, installation is only available in the directory, and a number of restrictions appear:

The application supports automatic installation (base system) and initial configuration of distributions of Debian, Ubuntu, Kali Linux, Arch Linux, Fedora, CentOS, Gentoo, openSUSE and Slackware. Installation of Linux-distribution is carried out over the network from the official mirrors on the Internet. It also supports importing any other system from a pre-prepared rootfs archive in the format tar.gz, tar.bz2 or tar.xz. The application allows you to connect to the console of the installed system (container), as well as start and stop applications inside the container (there is support for various initialization systems and own autoplay scenarios). Each installation option is saved in a separate configuration file, which is responsible for setting up each container. If necessary, containers can be started in parallel. You can export the configuration and the container itself as a rootfs archive for later deployment of this container without re-installing and configuring it.

In general, the idea of Linux Deploy arose from the desire to get an easy and convenient tool for quickly deploying a Linux distribution that could be used for development, testing or training purposes, and then quickly remove it without making changes to the main (host) Linux system and without risking its integrity. The proot program made it possible to create containers for running Linux applications without root privileges, and to use the QEMU software emulation to run applications with a different architecture from the host without the need to support the binfmt_misc module at the kernel level.

It so happens that my main job since 2011 is using computers with Debian. Local developers periodically need a system to run and test their web applications (mainly Java, PHP, Python). For this purpose, virtual systems were usually used either on the basis of VirtualBox, or in the local Proxmox cloud, or Docker. The main disadvantage of VirtualBox is its demanding computer resources, large VDI disk image size, relatively low speed and the likelihood of VM image failure if the system is incorrectly turned off. The disadvantage when using the “cloud” can be called the need for the administrator himself to service user requests for the creation of such systems, as well as spending the resources of the “cloud” on minor tasks. Superuser rights are required to use Docker.

This month, an experiment was conducted, PHP developers their virtual server was replaced by an LD container. Two Debian-based containers were prepared: Apache + PHP + OCI8 and Apache + PHP + MySQL + PhpMyAdmin. Containers were placed on a shared network drive on a local network, the size of each container was about 150 MB.

What the administrator got from this:

What the developer got:

Now for more details on how to do this. Following are instructions for preparing and deploying the LD container.

To run containers without superuser rights, you must install proot:

mkdir ~/bin
wget -O ~/bin/proot
chmod 755 ~/bin/proot

To download and install the Linux Deploy CLI:

wget -O
ln -sf ~/linuxdeploy-cli/ ~/bin/linuxdeploy

Create a configuration named “linux” to deploy the Debian Wheezy base system (64 bits):

linuxdeploy -p linux conf --method='proot' --source-path='' \
    --distrib='debian' --arch='amd64' --suite='wheezy' --target-path='$ENV_DIR/rootfs/linux' \
    --chroot-dir='$TARGET_PATH' --target-type='directory' --username='webmaster' --include='bootstrap'

View saved configuration:

linuxdeploy -p linux conf -x

Starting a new system deployment:

linuxdeploy -p linux deploy

Connecting to the container console as root (the exit command to stop):

linuxdeploy -p linux shell -u root

Next, you can install and configure the necessary software in the container, but you should take into account the features described above. For example, to run Apache, you need to change its port (file /etc/apache2/ports.conf) to 8000, set the empty parameter APACHE_ULIMIT_MAX_FILES=" " (file /etc/apache2/envvvars), and run apachectl itself from under an ordinary user (not root).

Configuring autostart based on the SysV initialization system:

linuxdeploy -p linux conf --include='$INCLUDE init' --init='sysv' --init-level='3' --init-user='$USER_NAME' --init-async

Parameters: INIT_LEVEL - SysV initialization level, INIT_USER - from under which user to run services (by default this is root), INIT_ASYNC - to run services in parallel.

Preparing the configuration, exporting it and exporting the container to the rootfs archive (tar.gz, tar.bz2 and tar.xz archives are supported):

linuxdeploy -p linux conf --source-path='linux.tgz' --target-path='\$ENV_DIR/rootfs/linux' --chroot-dir='\$TARGET_PATH'
linuxdeploy -p linux conf -x > /path/to/linux.conf
linuxdeploy -p linux export /path/to/linux.tgz

Escaping “$” allows you to save the names of variables to config, rather than their values. Thus, when importing a config, these variables will be automatically replaced with the corresponding values, which may differ from the current values.

Now, there are two files (linux.conf and linux.tgz) that you can use when importing a container on another computer:

cd /path/to
linuxdeploy -p linux conf -i ./linux.conf
linuxdeploy -p linux deploy

Connect the main system directory to the container (directory ~/www connect to /var/www container):

linuxdeploy -p linux conf --mounts='$HOME/www:/var/www'

Starting the container (/etc/rcN.d/SXXname start commands are executed for SysV):

linuxdeploy -p linux start

Stop container and release resources (/etc/rc6.d/KXXname stop commands are executed for SysV):

linuxdeploy -p linux stop -u

The result is a solution that meets the needs of both developers and administrators.