mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-10-14 11:31:02 -04:00
Merge branch 'rst' into toki_fix_findings
This commit is contained in:
Tobias Killer
GitHub
commit
cad541c3af
115 changed files with 1960 additions and 1862 deletions
|
|
@ -39,18 +39,18 @@ Our test runner runs mostly the same as the standard one, but it has some nice a
|
|||
|
||||
You can use ``python3 -m qubes.tests.run -h`` to get usage information:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
[user@dom0 ~]$ python3 -m qubes.tests.run -h
|
||||
usage: run.py [-h] [--verbose] [--quiet] [--list] [--failfast] [--no-failfast]
|
||||
[--do-not-clean] [--do-clean] [--loglevel LEVEL]
|
||||
[--logfile FILE] [--syslog] [--no-syslog] [--kmsg] [--no-kmsg]
|
||||
[TESTNAME [TESTNAME ...]]
|
||||
|
||||
|
||||
positional arguments:
|
||||
TESTNAME list of tests to run named like in description
|
||||
(default: run all tests)
|
||||
|
||||
|
||||
optional arguments:
|
||||
-h, --help show this help message and exit
|
||||
--verbose, -v increase console verbosity level
|
||||
|
|
@ -74,7 +74,7 @@ You can use ``python3 -m qubes.tests.run -h`` to get usage information:
|
|||
allow running in parallel with qubesd; this is
|
||||
DANGEROUS and WILL RESULT IN INCONSISTENT SYSTEM STATE
|
||||
--break-to-repl break to REPL after tests
|
||||
|
||||
|
||||
When running only specific tests, write their names like in log, in format:
|
||||
MODULE+"/"+CLASS+"/"+FUNCTION. MODULE should omit initial "qubes.tests.".
|
||||
Example: basic/TC_00_Basic/test_000_create
|
||||
|
|
@ -82,7 +82,7 @@ You can use ``python3 -m qubes.tests.run -h`` to get usage information:
|
|||
|
||||
For instance, to run only the tests for the fedora-21 template, you can use the ``-l`` option, then filter the list:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
[user@dom0 ~]$ python3 -m qubes.tests.run -l | grep fedora-21
|
||||
network/VmNetworking_fedora-21/test_000_simple_networking
|
||||
|
|
@ -117,9 +117,9 @@ Example test run:
|
|||
|
||||
Tests are also compatible with nose2 test runner, so you can use this instead:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo systemctl stop qubesd; sudo -E nose2 -v --plugin nose2.plugins.loader.loadtests qubes.tests; sudo systemctl start qubesd
|
||||
$ sudo systemctl stop qubesd; sudo -E nose2 -v --plugin nose2.plugins.loader.loadtests qubes.tests; sudo systemctl start qubesd
|
||||
|
||||
|
||||
This may be especially useful together with various nose2 plugins to store tests results (for example ``nose2.plugins.junitxml``), to ease presenting results. This is what we use on `OpenQA <https://open.qa/>`__.
|
||||
|
|
@ -138,17 +138,17 @@ The below example however will assume that you set up a build environment as des
|
|||
|
||||
Assuming you cloned the ``qubes-builder`` repository to your home directory inside a fedora VM, you can use the following commands to run the unit tests:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
cd ~
|
||||
sudo dnf install python3-pip lvm2 python35 python3-virtualenv
|
||||
virtualenv -p /usr/bin/python35 python35
|
||||
source python35/bin/activate
|
||||
python3 -V
|
||||
cd ~/qubes-builder/qubes-src/core-admin
|
||||
pip3 install -r ci/requirements.txt
|
||||
export PYTHONPATH=../core-qrexec:test-packages
|
||||
./run-tests
|
||||
$ cd ~
|
||||
$ sudo dnf install python3-pip lvm2 python35 python3-virtualenv
|
||||
$ virtualenv -p /usr/bin/python35 python35
|
||||
$ source python35/bin/activate
|
||||
$ python3 -V
|
||||
$ cd ~/qubes-builder/qubes-src/core-admin
|
||||
$ pip3 install -r ci/requirements.txt
|
||||
$ export PYTHONPATH=../core-qrexec:test-packages
|
||||
$ ./run-tests
|
||||
|
||||
|
||||
To run only the tests related to e.g. ``lvm``, you may use:
|
||||
|
|
@ -213,37 +213,37 @@ When testing (Py)QT applications, it’s useful to create a separate QApplicatio
|
|||
import quamash
|
||||
import unittest
|
||||
import gc
|
||||
|
||||
|
||||
class SomeTestCase(unittest.TestCase):
|
||||
def setUp(self):
|
||||
[...]
|
||||
|
||||
|
||||
# force "cleanlooks" style, the default one on Xfce (GtkStyle) use
|
||||
# static variable internally and caches pointers to later destroyed
|
||||
# objects (result: SEGV)
|
||||
self.qtapp = QtGui.QApplication(["test", "-style", "cleanlooks"])
|
||||
|
||||
|
||||
# construct event loop even if this particular test doesn't use it,
|
||||
# otherwise events with qtapp references will be queued there anyway and the
|
||||
# first test that actually use event loop will try to dereference (already
|
||||
# destroyed) objects, resulting in SEGV
|
||||
self.loop = quamash.QEventLoop(self.qtapp)
|
||||
|
||||
|
||||
def tearDown(self):
|
||||
[...]
|
||||
# process any pending events before destroying the object
|
||||
self.qtapp.processEvents()
|
||||
|
||||
|
||||
# queue destroying the QApplication object, do that for any other QT
|
||||
# related objects here too
|
||||
self.qtapp.deleteLater()
|
||||
|
||||
|
||||
# process any pending events (other than just queued destroy), just in case
|
||||
self.qtapp.processEvents()
|
||||
|
||||
|
||||
# execute main loop, which will process all events, _including just queued destroy_
|
||||
self.loop.run_until_complete(asyncio.sleep(0))
|
||||
|
||||
|
||||
# at this point it QT objects are destroyed, cleanup all remaining references;
|
||||
# del other QT object here too
|
||||
self.loop.close()
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ You want to read your LVM image (e.g., there is a problem where you can’t star
|
|||
|
||||
1: make the image available for qubesdb. From dom0 terminal:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
# Example: /dev/qubes_dom0/vm-debian-9-tmp-root
|
||||
[user@dom0]$ dev=$(basename $(readlink /dev/YOUR_LVM_VG/YOUR_LVM_IMAGE))
|
||||
|
|
@ -16,7 +16,7 @@ You want to read your LVM image (e.g., there is a problem where you can’t star
|
|||
|
||||
2: Create a new disposable VM
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
[user@dom0]$ qvm-run -v --dispvm=YOUR_DVM_TEMPLATE --service qubes.StartApp+xterm &
|
||||
|
||||
|
|
@ -25,28 +25,28 @@ You want to read your LVM image (e.g., there is a problem where you can’t star
|
|||
|
||||
From the GUI, or from the command line:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
[user@dom0]$ qvm-block attach NEWLY_CREATED_DISPVM dom0:$dev
|
||||
|
||||
|
||||
4: Mount the partition you want to, and do what you want with it
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
[user@dispXXXX]$ mount /dev/xvdiX /mnt/
|
||||
|
||||
|
||||
5: Umount and kill the VM
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
[user@dispXXXX]$ umount /mnt/
|
||||
|
||||
|
||||
6: Remove the image from qubesdb
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
[user@dom0]$ qubesdb-rm /qubes-block-devices/$dev/
|
||||
|
||||
|
|
|
|||
|
|
@ -17,7 +17,7 @@ To a different VM
|
|||
|
||||
As an example of forwarding terminal output to another VM on the same machine:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
$ mkfifo /tmp/foo
|
||||
$ qvm-run -p some-vm 'xterm -e "cat 0<&5" 5<&0' </tmp/foo >/dev/null 2>&1 &
|
||||
|
|
@ -31,7 +31,7 @@ To a different machine
|
|||
|
||||
In this case over SSH (from a network-connected VM):
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
$ mkfifo /tmp/foo
|
||||
$ qvm-run -p some-vm \
|
||||
|
|
@ -55,7 +55,7 @@ Terminal size
|
|||
|
||||
It is up to you to ensure the sizes of the local and remote terminal are the same, otherwise things may display incorrectly (especially in interactive programs). Depending on your shell, the size of your local (blind) terminal is likely stored in the ``$LINES`` and ``$COLUMNS`` variables.
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
$ echo $COLUMNS $LINES
|
||||
80 24
|
||||
|
|
@ -68,9 +68,9 @@ A note on serial consoles
|
|||
|
||||
If your machine has a serial console, you may with to use that, but note that a similar split-I/O model should be used to ensure Dom0 integrity. If you use the serial console as normal (via e.g. getty on ttyX, and logging in as normal), then the machine at the end of the serial cable could compromise your machine! Ideally, you would take input from your trusted keyboard, and only send the output over the serial cable via e.g. disabling getty and using:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
script -f /dev/ttyS0
|
||||
$ script -f /dev/ttyS0
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -38,15 +38,15 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
# adjust this for your NIC (run lspci)
|
||||
BDF=0000:02:00.0
|
||||
|
||||
|
||||
# adjust this for your network driver
|
||||
DRIVER=e1000e
|
||||
|
||||
|
||||
prog=$(basename $0)
|
||||
|
||||
|
||||
pciunbind() {
|
||||
local path
|
||||
path=/sys/bus/pci/devices/${1}/driver/unbind
|
||||
|
|
@ -56,7 +56,7 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
|
|||
fi
|
||||
echo -n ${1} >${path}
|
||||
}
|
||||
|
||||
|
||||
pcibind() {
|
||||
local path
|
||||
path=/sys/bus/pci/drivers/${2}/bind
|
||||
|
|
@ -66,10 +66,10 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
|
|||
fi
|
||||
echo ${1} >${path}
|
||||
}
|
||||
|
||||
|
||||
pciunbind ${BDF}
|
||||
pcibind ${BDF} ${DRIVER}
|
||||
|
||||
|
||||
sleep 1
|
||||
dhclient
|
||||
|
||||
|
|
@ -78,15 +78,15 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
|
|||
|
||||
6. You’ll need to run the above script on every startup. To automate this save the following systemd service ``/etc/systemd/system/dom0-network-direct.service``
|
||||
|
||||
.. code:: bash
|
||||
.. code:: systemd
|
||||
|
||||
[Unit]
|
||||
Description=Connect network to dom0
|
||||
|
||||
|
||||
[Service]
|
||||
Type=oneshot
|
||||
ExecStart=/home/user/bin/dom0_network.sh
|
||||
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
|
||||
|
|
@ -94,13 +94,13 @@ Internet access is intentionally disabled by default in dom0. But to ease the de
|
|||
|
||||
7. Then, enable and start the SSH Server and the script on boot:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo systemctl enable sshd
|
||||
sudo systemctl start sshd
|
||||
|
||||
sudo systemctl enable dom0-network-direct
|
||||
sudo systemctl start dom0-network-direct
|
||||
$ sudo systemctl enable sshd
|
||||
$ sudo systemctl start sshd
|
||||
|
||||
$ sudo systemctl enable dom0-network-direct
|
||||
$ sudo systemctl start dom0-network-direct
|
||||
|
||||
|
||||
|
||||
|
|
@ -117,32 +117,32 @@ Because of the above reason, some additional configurations need to be done to y
|
|||
|
||||
The following commands should work for you, but do keep in mind that the provisioning scripts are designed for the `openQA environment <https://openqa.qubes-os.org/>`__ and not your specific local testing system. Run the following in ``dom0``:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
# For future reference the following commands are an adaptation of
|
||||
# https://github.com/marmarek/openqa-tests-qubesos/blob/master/tests/update.pm
|
||||
|
||||
|
||||
# Install git
|
||||
sudo qubes-dom0-update git || sudo dnf --setopt=reposdir=/etc/yum.repos.d install git
|
||||
|
||||
$ sudo qubes-dom0-update git || sudo dnf --setopt=reposdir=/etc/yum.repos.d install git
|
||||
|
||||
# Download the openQA automated testing environment Salt configuration
|
||||
git clone https://github.com/marmarek/openqa-tests-qubesos/
|
||||
cd openqa-tests-qubesos/extra-files
|
||||
sudo cp -a system-tests/ /srv/salt/
|
||||
sudo qubesctl top.enable system-tests
|
||||
|
||||
$ git clone https://github.com/marmarek/openqa-tests-qubesos/
|
||||
$ cd openqa-tests-qubesos/extra-files
|
||||
$ sudo cp -a system-tests/ /srv/salt/
|
||||
$ sudo qubesctl top.enable system-tests
|
||||
|
||||
# Install the same configuration as the one in openQA
|
||||
QUBES_VERSION=4.1
|
||||
PILLAR_DIR=/srv/pillar/base/update
|
||||
sudo mkdir -p $PILLAR_DIR
|
||||
printf 'update:\n qubes_ver: '$QUBES_VERSION'\n' | sudo tee $PILLAR_DIR/init.sls
|
||||
printf "base:\n '*':\n - update\n" | sudo tee $PILLAR_DIR/init.top
|
||||
sudo qubesctl top.enable update pillar=True
|
||||
|
||||
$ QUBES_VERSION=4.1
|
||||
$ PILLAR_DIR=/srv/pillar/base/update
|
||||
$ sudo mkdir -p $PILLAR_DIR
|
||||
$ printf 'update:\n qubes_ver: '$QUBES_VERSION'\n' | sudo tee $PILLAR_DIR/init.sls
|
||||
$ printf "base:\n '*':\n - update\n" | sudo tee $PILLAR_DIR/init.top
|
||||
$ sudo qubesctl top.enable update pillar=True
|
||||
|
||||
# Apply states to dom0 and VMs
|
||||
# NOTE: These commands can take several minutes (if not more) without showing output
|
||||
sudo qubesctl --show-output state.highstate
|
||||
sudo qubesctl --max-concurrency=2 --skip-dom0 --templates --show-output state.highstate
|
||||
$ sudo qubesctl --show-output state.highstate
|
||||
$ sudo qubesctl --max-concurrency=2 --skip-dom0 --templates --show-output state.highstate
|
||||
|
||||
|
||||
Development VM
|
||||
|
|
@ -155,7 +155,7 @@ SSH
|
|||
|
||||
Arrange firewall so you can reach the testbench from your ``qubes-dev`` VM. Generate SSH key in ``qubes-dev``:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
ssh-keygen -t ecdsa -b 521
|
||||
|
||||
|
|
@ -163,7 +163,7 @@ Arrange firewall so you can reach the testbench from your ``qubes-dev`` VM. Gene
|
|||
|
||||
Add the following section in ``.ssh/config`` in ``qubes-dev``:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
Host testbench
|
||||
# substitute username in testbench
|
||||
|
|
@ -190,7 +190,7 @@ This step is optional, but very helpful. Put these scripts somewhere in your ``$
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
ssh testbench python -m qubes.tests.run
|
||||
|
||||
|
||||
|
|
@ -199,19 +199,19 @@ This step is optional, but very helpful. Put these scripts somewhere in your ``$
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
TMPDIR=/tmp/qtb-rpms
|
||||
|
||||
|
||||
if [ $# -eq 0 ]; then
|
||||
echo "usage: $(basename $0) <rpmfile> ..."
|
||||
exit 2
|
||||
fi
|
||||
|
||||
|
||||
set -e
|
||||
|
||||
|
||||
ssh testbench mkdir -p "${TMPDIR}"
|
||||
scp "${@}" testbench:"${TMPDIR}" || echo "check if you have 'scp' installed on your testbench"
|
||||
|
||||
|
||||
while [ $# -gt 0 ]; do
|
||||
ssh testbench sudo rpm -i --replacepkgs --replacefiles "${TMPDIR}/$(basename ${1})"
|
||||
shift
|
||||
|
|
@ -223,16 +223,16 @@ This step is optional, but very helpful. Put these scripts somewhere in your ``$
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
set -e
|
||||
|
||||
|
||||
# substitute path to your builder installation
|
||||
pushd ${HOME}/builder >/dev/null
|
||||
|
||||
|
||||
# the following are needed only if you have sources outside builder
|
||||
#rm -rf qubes-src/core-admin
|
||||
#qb -c core-admin package fetch
|
||||
|
||||
|
||||
qb -c core-admin -d host-fc41 prep build
|
||||
# update your dom0 fedora distribution as appropriate
|
||||
qtb-install qubes-src/core-admin/rpm/x86_64/qubes-core-dom0-*.rpm
|
||||
|
|
@ -250,9 +250,9 @@ I (woju) have those two git hooks. They ensure tests are passing (or are marked
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
set -e
|
||||
|
||||
|
||||
python -c "import sys, qubes.tests.run; sys.exit(not qubes.tests.run.main())"
|
||||
|
||||
|
||||
|
|
@ -261,6 +261,6 @@ I (woju) have those two git hooks. They ensure tests are passing (or are marked
|
|||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
||||
exec qtb-iterate
|
||||
|
||||
|
|
|
|||
|
|
@ -45,9 +45,9 @@ You will need to create a custom libvirt config for the target VM. See `the docu
|
|||
|
||||
|
||||
|
||||
.. code:: bash
|
||||
.. code:: xml+jinja
|
||||
|
||||
|
||||
|
||||
{% extends 'libvirt/xen.xml' %}
|
||||
{% block network %}
|
||||
<interface type='ethernet'>
|
||||
|
|
@ -58,7 +58,7 @@ You will need to create a custom libvirt config for the target VM. See `the docu
|
|||
<model type='e1000' />
|
||||
</interface>
|
||||
{% endblock %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ Host and target preparation
|
|||
|
||||
- ``kdnet`` should show that the NIC is supported, note the busparams:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
Network debugging is supported on the following NICs:
|
||||
busparams=0.6.0, Intel(R) PRO/1000 MT Network Connection, KDNET is running on this NIC.
|
||||
|
|
@ -117,7 +117,7 @@ Host and target preparation
|
|||
|
||||
- Reboot ``target-vm``, debugging should start:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: text
|
||||
|
||||
Waiting to reconnect...
|
||||
Connected to target 10.137.0.19 on port 50000 on local IP 10.137.0.20.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue