Skip to content

Latest commit

 

History

History
285 lines (198 loc) · 9.04 KB

developer_guide.adoc

File metadata and controls

285 lines (198 loc) · 9.04 KB

OSCAP Anaconda Addon Developer Guide

1. How to Test oscap Anaconda Addon

Anaconda has capability to load installer updates using "updates image". This image can be loaded from different storages and use different formats. This page should show one working use case, not all possibilities.

What do you need to test your changes?

  1. Clone addon repository & use required branch & change code.

  2. Build addon update image.

  3. Run a VM using reanaconda.

1.1. Clone repository & use required branch

The rhel7-branch uses Python 2 and supports RHEL7 Anaconda, whereas the rawhide uses Python 3, and targets the Fedora Rawhide.

1.2. Build image

We will create cpio archive ASCII cpio archive (SVR4 with no CRC) packed using gzip (gzip compressed data). On RHEL installation media, the OAA package and its dependencies are included, but this is not the case with Fedora. Therefore, the archive has to contain those dependencies.

You can use the create_update_image.sh script in the oscap-anaconda-addon repository to create the update.img image. If some time has passed since you have created the image, you typically want to re-download fresh RPM dependencies in the process, so the image is up-to-date in all aspects.

For further reading, see the official docs.

./create_update_image.sh download_rpms

Or install podman and create the update image with dependencies in a container using:

make container-update-image

If you want to see what was packed, you can extract the image.

gunzip -c update.img | cpio -id

or use the lsinitrd command, which is part of the dracut package on RHEL and Fedora:

lsinitrd update.img

1.3. Use reanaconda

The reanaconda script prepares and starts a VM with the update image. You can get it from the repository at https://github.com/rhinstaller/devel-tools/tree/master/reanaconda

Prepare the VM:

./reanaconda.py prime --sensible --tree http://ftp.fi.muni.cz/pub/linux/fedora/linux/releases/34/Everything/x86_64/os

After the script terminates, provide the update image:

./reanaconda.py updates path/to/updates.img

The VM should be shown in a QEMU window, which you can play with and you can close it any time.

If you run a Fedora VM, there won’t be scap-security-guide content available, so you will have to serve the content from your host machine using a HTTP server. For example, you can provide your local SSG build. In a new terminal, run:

cd ~/work/git/scap-security-guide/build
python3 -m http.server

And then, in the OSCAP Anaconda Addon user interface, enter the URL. Your host is visible from your guest at 10.0.2.2. For example:

http://10.0.2.2:8000/ssg-fedora-ds.xml

Watch the console, as the VM is supposed to download the update image, and the Python server should output the corresponding HTTP request:

<IP> - - [<date>] "GET /update.img HTTP/1.1" 200 -

200 is the OK request status.

There is a cleanup step, but you don’t have to run it if you only want to restart the VM with a new image:

./reanaconda.py cleanup

1.4. Further introspection of Anaconda

After reaching the Anaconda GUI, you can switch into another VT and check out that the update went OK by examining the files on the disc. You can also debug Anaconda in a sophisticated way - as of 04/2018, switching to tty1 brought you to a TMUX session with windows attached to various processes. There is also an official how-to-debug documentation though.

1.5. Older method without reanaconda

1.5.1. Serve image using HTTP server

You don’t need public HTTP server or setup Apache. You can use simple python HTTP server - it serves all files in you current directory.

python3 -m http.server

Setup your firewall rules correctly to make webserver port accessible from virtual machine.

1.5.2. Load system with update image

If you want to load your changes to anaconda, you have to setup boot options correctly. You have two ways how to setup it:

  • Manually

  • With Network Install/PXE boot

If you want to set it manually, you have to boot your machine into grub. Then you can change options (usually using "tab" key).

If you use Network Install/PXE boot you can pass requires parameters there - look for kernel options. Advantage of this solution is that you will not need to change parameters during every boot.

Required boot parameters:

inst.updates=http://gateway:8000/update.img

Here, gateway is supposed to refers to your host machine:

  • On Fedora, you have to enter the IP address of the virtual bridge interface.

  • On RHEL, the gateway hostname will be recognized correctly.

Remember that you can also provide your custom-built SSG content to the insaller this way - you may copy your datastream to the directory that is served by the server as it contains the image, and then, enter http://gateway:8000/my-custom-ds.xml as a remote content URL.

Watch the console, as the VM is supposed to download the update image, and the Python server should output the corresponding HTTP request:

<IP> - - [<date>] "GET /update.img HTTP/1.1" 200 -

200 is the OK request status.

1.5.3. Installing a VM using update image and kickstart

You can also use the virt-install command, which is useful when you want to test kickstart installation.

Some kickstarts (.cfg files) can be found in the testing_files directory. You will also need installation URL and the update image described above.

For example:

virt-install \
--connect qemu:///system \
--name oaa_test \
--memory 2048 --vcpus 2 --disk size=8 \
--os-variant fedora35 \
--location INSTALLATION_URL \
-x inst.updates=http://192.168.122.1:8000/update.img  \
-x inst.ks=http://192.168.122.1:8000/ks.cfg \
--network default

Replace INSTALLATION_URL with correct URL and ks.cfg with the real kickstart file name.

1.5.4. Testing with newer OpenSCAP

If you have a new RPM in a repo, eg. in a COPR repository created by Packit, you can add a link to the repo to your kickstart.

For example:

repo --name oscap --baseurl=https://download.copr.fedorainfracloud.org/results/packit/OpenSCAP-openscap-1838/epel-8-x86_64/

1.5.5. Testing code in rawhide branch

Our rawhide branch is compatible with the latest released Fedora. However, testing this code has some caveats, for example, the reanaconda tool can’t be used at this moment. The recommended procedure for testing the rawhide branch is the following:

  1. Download the latest Fedora Server DVD ISO file from https://fedoraproject.org/server/download/, for example Fedora-Server-dvd-x86_64-38-1.6.iso.

  2. Create an OAA update image with the -r parameter set to the version:

    sudo ./create_update_image.sh -r 38 download_rpms
  3. Start a HTTP server in the project directory:

    python3 -m http.server
  4. Create a virtual machine in virt-manager choosing the downloaded ISO file as the installation resource.

  5. When the virtual machine screen appears, navigate using arrow to highlight Install Fedora 38 and press e.

  6. On the line starting with linux, append this command:

    inst.updates=http://192.168.122.1:8000/update.img

    where the IP address may vary - if the update image is not downloaded during the installation media boot (you can tell that something happened from the output of the Python server command), look up the gateway IP address from the respective VM configuration.

  7. Press F10.

The HTTP server should display a GET /update.img message, otherwise fix the firewalld settings.

2. Available make commands

Following commands are available to be used in make command:

dist        - Build the release tarball
install     - Install the plugin into your system
uninstall   - Uninstall the plugin from your system
po-pull     - Pull translations from Zanata
potfile     - Update translation template file
push-pot    - Push translation template to Zanata
test        - Run pylint checks and unit tests
pylint      - Run only pylint checks
unittest    - Run only unit tests

2.1. Translations

Following packages are needed to manage translations:

intltool
git

2.2. Running Unit Tests

Following packages are needed to run unit tests:

anaconda
openscap-python3
python3-cpio
python3-mock
python3-pytest
python3-pycurl

Run the unit tests using:

make unittest

Or install podman and run the tests in a container using:

make container-test

3. Updating translations

Sometimes it is neccessary to create a patch that updates translations present in the release tarball with custom translations, or translations from Zanata. You can use the make-language-patch script in the tools subdirectory for this task. You just supply the release tarball, and a filesystem path to the directory with .po files if you don’t want to use Zanata to update the po directory contents and use that one. The resulting patch can then be applied to the release package without any additional steps needed.