FreedomBox/HACKING.md
Sunil Mohan Adapa 2e5a1857f7
container: Add script to manage systemd-nspawn containers for dev.
Inspired by: https://salsa.debian.org/vexch/plinth/snippets/391

This script creates a simple container using systemd-nspawn for developing
FreedomBox. It has many advantages over running a VM using Vagrant. RAM is
allocated to processes in the container as needed without any fixed limit. Also
RAM does not have to be statically allocated so it is typically much lighter
than running an VM. There is no hardware emulation when running a container with
same architecture, so processes run as fast as they would on the host machine.

Environment: The script will run only run on hosts having systemd-nspawn and
network-manager installed, typical GNU/Linux distributions. It has been
primarily developed and tested on Debian Buster but should work on most modern
GNU/Linux distributions.

Disk image: systemd-nspawn accepts not only a directory for starting a container
but also a disk image. This disk image is loop-back mounted and container is
started from that mounted directory. The partition to use is determined by
looking at the boot flag in the partition table. This happens to work well with
all existing FreedomBox images. In future, we may be able to run different
architectures in this manner.

After downloading, the disk image is expanded along with the partition and file
system inside so that development can be done without running into disk space
issues. Expanding the disk does not immediately consume disk space because it
will be a sparse file. As data is written to the disk, it will occupy more and
more space but the upper limit is the size to which disk has been expanded.

Downloading images: Images are downloaded from FreedomBox download server using
fixed URLs for each distribution. Signature is verified for the download images.
The fingerprint of the allowed signing key is hard-coded in this script.
Downloaded images are kept even after destroying the extracted raw image along
with container. This allows for quickly resetting the container without
downloading again.

Booting: systemd-nspawn is run in 'boot' mode. This means that init process
(happens to be systemd) is started inside the container. It then spawns all the
other necessary daemons including openssh-server, firewalld and network-manager.
A login terminal can be opened using 'machinectl login' because container is
running systemd. SSH into the container is possible because network is up,
configured by network-manager, and openssh server is running.

Shared folder: Using systemd-nspawn, the project directory is mounted as
/freedombox inside the container. The project directory is determined as
directory in which this script resides. The project folder from the container
point of view will be read-only. Container should be able to write various files
such as build files, FreedomBox sqlite3 database and session files into the
/freedombox folder. To enable writing, an additional read-write folder is
overlayed onto /freedombox folder in the container. This directory can't be
created under the project folder and is created instead in
$XDG_DATA_HOME/freedombox-container/overlay/$DISTRIBUTION. If XDG_DATA_HOME is
not set, it is assumed to be $HOME/.local/shared/. Whenever data is written into
/freedombox directory inside the container, this directory on the host receives
the changes. See documentation for Overlay filesystem for further details. When
container is destroyed, this overlay folder is destroyed to ensure clean state
after bringing up the container again.

Users: PrivateUsers configuration flag for systemd-nspawn is currently off. This
means that each user's UID on the host is also the same UID in the container as
along as there is an entry in the container's password database. In future, we
may explore using private users inside the container.

'fbx' is the development user and its UID is changed during setup phase to 10000
hoping it would not match anything on the host system. 'fbx' user has full sudo
access inside the container without needing a password. Password for this user
is not set by default, but can be set if needed. If there is no access to the
container in any way, one can run 'sudo machinectl shell' and then run 'passwd
fbx' to set the password for the 'fbx' user.

'plinth' user's UID in the container is also changed and set to the UID of
whichever user owns the project directory. This allows the files to written by
'plinth' container user in the project directory because UID of the owner of the
directory is same as the 'plinth' user's UID in container.

Network: A private network is created inside the container using systemd-nspawn
feature. Network interfaces from the host are not available inside the
container. A new network interface called 'host0' is configured inside the
container which is automatically configured by network-manager. On the host a
new network interface is created. This script creates configuration for a
'shared' network using network-manager. When bringing up the container, this
network connection is also brought up. A DHCP server and a DNS server are
started network-manager on the host side so that DHCP and DNS client functions
work inside the container. Traffic from the container is also masqueraded so
that Internet connectivity inside the container works if the host has one.

If necessary, the network interface on host side can be differently configured.
For example, it can be bridged with another interface to expose the container on
a network that the host machine participates in.

The network IP address inside the container can be queried using machinectl.
This script queries that IP address and presents the address in its console
messages. All ports in the container can be reached from the host using this IP
address as long as the firewall inside the container allows it. There is no need
to perform port forwarding or mapping.

SSH: It is assumed that openssh-server is installed inside the container. SSH
server keys in the container are created if missing. Client side keys are
created in .container/ssh directory and the public key is installed in the
authorized keys file of the 'fbx' user. The 'ssh' sub-command to this script is
simply a convenience mechanism for quick launch of ssh with the right IP
address, user name and identity file.

Role of machinectl: Most of the work is done by systemd-nspawn. machinectl is
useful for running systemd-nspawn in the background and querying its current
state. It also helps with providing the IP address of the container. machinectl
is made to recognize the container by creating a link in /var/lib/machines/ to
the image file. systemd-nspawn options are added by creating a temporary file in
/run/systemd/nspawn. All machinectl commands should work.

Signed-off-by: Sunil Mohan Adapa <sunil@medhas.org>
Reviewed-by: Veiko Aasa <veiko17@disroot.org>
2020-06-04 18:20:03 +03:00

12 KiB

Hacking

Requirements for Development OS

FreedomBox is built as part of Debian GNU/Linux. However, you don't need to install Debian to do development for FreedomBox. FreedomBox development is typically done on a container or a Virtual Machine. For running a container, you need systemd containers, Git and Python. This approach is recommended. For running a VM, you can work on any operating system that can install latest versions of Git, Vagrant and VirtualBox.

Using Containers

The ./container script shipped with FreedomBox source code can manage the development environment inside a systemd-nspawn container.

  1. Checkout FreedomBox Service (Plinth) source code using Git.

    host$ git clone https://salsa.debian.org/freedombox-team/freedombox.git
    host$ cd freedombox
    
  2. To download, setup, run, and configure a container for FreedomBox development, simply execute in your FreedomBox Service (Plinth) development folder:

    host$ ./container up
    
  3. SSH into the running container with the following command:

    host$ ./container ssh
    

Using after Setup

After logging into the container, the source code is available in /freedombox directory:

guest$ cd /freedombox

Run the development version of FreedomBox Service (Plinth) from your source directory in the container using the following command. This command continuously deploys your code changes into the container providing a quick feedback cycle during development.

guest$ freedombox-develop

If you have changed any system configuration files during your development, you will need to run the following to install those files properly on to the system and their changes to reflect properly.

guest$ sudo ./setup.py install

Note: This development container has automatic upgrades disabled by default.

Using Vagrant

Use VirtualBox and Vagrant if for some reason, the container option is not suitable such as when you are running non-GNU/Linux machine or a non-systemd machine.

For Debian GNU/Linux and Derivatives

  1. Install Git, Vagrant and VirtualBox using apt.

    $ sudo apt install git virtualbox vagrant
    

Installing VirtualBox manually

  1. Add Oracle's key to apt's list of accepted keys.

    $ sudo wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -
    
  2. Create a file under /etc/apt/sources.list.d/ for virtualbox package.

    $ sudo touch /etc/apt/sources.list.d/virtualbox.list
    
  3. Add the relevant source for your Debian/derivative distribution into the above file.

Example for Buster:

deb https://download.virtualbox.org/virtualbox/debian buster contrib
  1. Search and install the latest virtualbox package.

    $ apt search virtualbox
    
        # virtualbox-6.1
        # virtualbox-6.0
    
    $ sudo apt install virtualbox-6.1
    

For Other GNU/Linux Distributions or *BSDs

  1. Install Git, Vagrant and VirtualBox using your favourite package manager.

For macOS

  1. Install Homebrew.

  2. Install Git, VirtualBox and Vagrant using Homebrew.

    $ brew install git
    $ brew cask install virtualbox
    $ brew cask install vagrant
    

For Windows

  1. Install Git, VirtualBox and Vagrant from their respective download pages.

  2. Tell Git to use Unix line endings by running the following in Git Bash.

    host$ git config --global core.autocrlf input
    
  3. Run all the following commands inside Git Bash.

Setting Up Development Environment Using Vagrant

Vagrant is a free software command line utility for managing the life cycle of virtual machines. The FreedomBox project provides ready-made virtual machines (VMs) for use with Vagrant. These images make setting up an environment for FreedomBox development rather simple: You can edit the source code on your host and immediately see the effects in the running VM. The entire setup is automatic and requires about 4.5 GB of disk space.

  1. Checkout FreedomBox Service (Plinth) source code using Git.

    host$ git clone https://salsa.debian.org/freedombox-team/freedombox.git
    host$ cd freedombox
    
  2. To download, setup, run, and configure a VM for FreedomBox development using Vagrant, simply execute in your FreedomBox Service (Plinth) development folder:

    host$ vagrant up
    
  3. SSH into the running vagrant box with the following command:

    host$ vagrant ssh
    

Using the Virtual Machine

After logging into the virtual machine (VM), the source code is available in /vagrant directory:

vm$ cd /vagrant

Run the development version of FreedomBox Service (Plinth) from your source directory in the virtual machine using the following command. This command continuously deploys your code changes into the virtual machine providing a quick feedback cycle during development.

vm$ sudo -u plinth /vagrant/run --develop

If you have changed any system configuration files during your development, you will need to run the following to install those files properly on to the system and their changes to reflect properly.

vm$ sudo ./setup.py install

Note: This development virtual machine has automatic upgrades disabled by default.

Running Tests

To run all the tests in the container/VM:

guest$ py.test-3

Another way to run tests (not recommended):

guest$ ./setup.py test

To run a specific test function, test class or test module, use pytest filtering options. See pytest documentation for further filter options.

Examples:

# Run tests in a directory
guest$ py.test-3 plinth/tests

# Run tests in a module
guest$ py.test-3 plinth/tests/test_actions.py

# Run tests of one class in test module
guest$ py.test-3 plinth/tests/test_actions.py::TestActions

# Run one test in a class or module
guest$ py.test-3 plinth/tests/test_actions.py::TestActions::test_is_package_manager_busy

Running the Test Coverage Analysis

To run the coverage tool in the container/VM:

guest$ py.test-3 --cov=plinth

To collect HTML report:

guest$ py.test-3 --cov=plinth --cov-report=html

Invoking this command generates a HTML report to the htmlcov directory. index.html presents the coverage summary, broken down by module. Data columns can be sorted by clicking on the column header. Clicking on the name of a particular source file opens a page that displays the contents of that file, with color-coding in the left margin to indicate which statements or branches were executed via the tests (green) and which statements or branches were not executed (red).

Running Functional Tests

Install Dependencies

For running tests inside the container

Inside the container run

guest$ cd /freedombox ; sudo functional_tests/install.sh

For running tests inside the VM

From the host, provision the virtual machine with tests:

host$ vagrant provision --provision-with tests

For running tests on host machine

Follow the instructions below to run the tests on host machine. If you wish perform the tests on host machine, the host machine must be based on Debian Buster (or later).

host$ pip3 install splinter
host$ pip3 install pytest-splinter
host$ pip3 install pytest-xdist  # optional, to run tests in parallel
host$ sudo apt install firefox
host$ sudo apt install python3-pytest-bdd
host$ sudo apt install xvfb python3-pytest-xvfb  # optional, to avoid opening browser windows
host$ sudo apt install smbclient  # optional, to test samba
  • Install the latest version of geckodriver. It is usually a single binary which you can place at /usr/local/bin/geckodriver . Geckodriver will use whichever binary is named 'firefox' for launching the browser and interacting with it.

Run FreedomBox Service

Warning: Functional tests will change the configuration of the system under test, including changing the hostname and users. Therefore you should run the tests using FreedomBox running on a throw-away VM.

The VM should have NAT port-forwarding enabled so that 4430 on the host forwards to 443 on the guest. From where the tests are running, the web interface of FreedomBox should be accessible at https://localhost:4430/.

To run samba tests, port 4450 on the host should be forwarded to port 445 on the guest.

Setup FreedomBox Service for tests

Via Plinth, create a new user as follows:

  • Username: tester
  • Password: testingtesting

This step is optional if a fresh install of Plinth is being tested. Functional tests will create the required user using FreedomBox's first boot process.

Run Functional Tests

When inside a container/VM you will need to target the guest

guest$ export FREEDOMBOX_URL=https://localhost FREEDOMBOX_SAMBA_PORT=445

You will be running py.test-3.

guest$ py.test-3 --include-functional

The full test suite can take a long time to run (more than an hour). You can also specify which tests to run, by specifying a mark:

guest$ py.test-3 -m essential --include-functional
guest$ py.test-3 -m mediawiki --include-functional

If xvfb is installed and you still want to see browser windows, use the --no-xvfb command-line argument.

guest$ py.test-3 --no-xvfb -m mediawiki --include-functional

Tests can also be run in parallel, provided you have the pytest-xdist plugin installed.

$ py.test-3 -n 4 --dist=loadfile --include-functional -m essential

Building the Documentation Separately

FreedomBox Service (Plinth) man page is built from DocBook source in the doc/ directory. FreedomBox manual is downloaded from the wiki is also available there. Both these are build during the installation process.

To build the documentation separately, run:

guest$ make -C doc

Repository

FreedomBox Service (Plinth) is available from salsa.debian.org.

Bugs & TODO

You can report bugs on FreedomBox Service's (Plinth's) issue tracker.

See CONTRIBUTING.md for information how to best contribute code.

Internationalization

To mark text for translation, FreedomBox Service (Plinth) uses Django's translation strings. A module should e.g. from django.utils.translation import ugettext as _ and wrap user-facing text with _(). Use it like this:

message = _('Application successfully installed and configured.')

Translations

The easiest way to start translating is with your browser, by using Weblate. Your changes will automatically get pushed to the code repository.

Alternatively, you can directly edit the .po file in your language directory Plinth/plinth/locale/ and create a pull request (see CONTRIBUTING.md). In that case, consider introducing yourself on #freedombox IRC (irc.debian.org), because some work may have been done already on the Debian translators discussion lists or the Weblate localization platform.

For more information on translations: https://wiki.debian.org/FreedomBox/Translate

Application Icons

When adding a new App into FreedomBox, an icon is needed to represent the app in the application view and for shortcuts in the front page. The following the guidelines for creating an app icon:

  • Use SVG format.
  • Keep the size and complexity of the SVG minimal. Simplify the graphic if necessary.
  • Units for the entire document should be in pixels.
  • View area should be 512x512 pixels.
  • Background should be transparent.
  • Leave no margins and prefer a square icon. If the icon is wide, leave top and bottom margins. If the icon is tall, leave left and right margins.