Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-02-25 09:11:16 -05:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'master' of https://github.com/QubesOS/qubes-doc

Browse Source
This commit is contained in:
Lemlay 2020-06-05 02:16:39 -04:00
commit b56245a3a8
5 changed files with 45 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
developer/debugging/automated-tests.md
View File

@ -22,10 +22,13 @@ Integration tests are written with the assumption that they will be called on de
Since these tests were written with this expectation, all the VMs with a name starting with `test-` on the installation are removed during the process, and all the tests are recklessly started from dom0, even when testing VM components.
Most of the tests are stored in the [core-admin repository](https://github.com/QubesOS/qubes-core-admin/tree/master/qubes/tests) in the `qubes/tests` directory.
To start them you can use standard python unittest runner:
python3 -m unittest -v qubes.tests
To start them you can use the standard python unittest runner:
`python3 -m unittest -v qubes.tests`
Or our custom one:
python3 -m qubes.tests.run -v
`python3 -m qubes.tests.run -v`
Our test runner runs mostly the same as the standard one, but it has some nice additional features like color output and not needing the "qubes.test" prefix.
It also has the ability to run lone selected template tests.
@ -101,7 +104,7 @@ Example test run:
### Qubes 4.0
Tests on Qubes 4.0 require stopping `qubesd` service first, because special instance of it is started as part of the test run.
Tests on Qubes 4.0 require stopping the `qubesd` service first, because a special instance of it is started as part of the test run.
Additionally, tests needs to be started as root. The full command to run the tests is:
sudo systemctl stop qubesd; sudo -E python3 -m qubes.tests.run -v ; sudo systemctl start qubesd
@ -144,10 +147,10 @@ Again, given the hypothetical `example.py` test:
### Testing PyQt applications
When testing (Py)QT application, it's useful to create separate QApplication object for each test.
But QT framework does not allow to have multiple QApplication objects in the same process at the same time.
This means it's critical to reliably cleanup previous instance before creating the new one.
This turns out to be non-trivial task, especially if _any_ test uses event loop.
When testing (Py)QT applications, it's useful to create a separate QApplication object for each test.
But QT framework does not allow multiple QApplication objects in the same process at the same time.
This means it's critical to reliably cleanup the previous instance before creating a new one.
This turns out to be a non-trivial task, especially if _any_ test uses the event loop.
Failure to perform proper cleanup in many cases results in SEGV.
Below you can find steps for the proper cleanup:
@ -205,7 +208,7 @@ Installation Tests with openQA
Manually testing the installation of Qubes OS is a time-consuming process.
We use [openQA] to automate this process.
It works by installing Qubes in KVM and interacting with it as a user would, including simulating mouse clicks and keyboard presses.
Then, it checks the output to see whether various tests were passed, e.g., by comparing the virtual screen output to screenshots of a successful installation.
Then, it checks the output to see whether various tests were passed, e.g. by comparing the virtual screen output to screenshots of a successful installation.
Using openQA to automatically test the Qubes installation process works as of Qubes 4.0-rc4 on 2018-01-26, provided that the versions of KVM and QEMU are new enough and the hardware has VT-x and EPT.
KVM also supports nested virtualization, so HVM should theoretically work.

14
developer/debugging/profiling.md
View File

@ -11,7 +11,7 @@ redirect_from:
Profiling
=========
This is python profiling primer.
This is a python profiling primer.
For the purpose of this document, `qubes-dev` is name of the domain used for postprocessing profiling stats.
@ -23,7 +23,7 @@ yum install gprof2dot graphviz
git clone http://git.woju.eu/qubes/profiling.git
~~~
If you profile something on dom0, move `Upload.sh` from repository to dom0:
If you profile something in dom0, move `Upload.sh` from the repository to dom0:
~~~
mkdir -p ~/profiling
@ -37,7 +37,7 @@ Workflow
### Identify function responsible for some slow action
You have to select area in which you suspect less than optimal performance. If you do not narrow the area, graphs may be unreadable.
You have to select the area in which you suspect less than optimal performance. If you do not narrow the area, graphs may be unreadable.
### Replace suspect function with probe
@ -59,7 +59,7 @@ with
Beware that some functions may be called often. For example `qubesmanager/main.py:update_table` gets run once per second. This will produce one pstat file per second.
Remember to revert your changes to application afterwards.
Remember to revert your changes to the application afterwards.
### Upload statistics
@ -76,13 +76,13 @@ cd ~/profiling
make
~~~
For every `${basename}.pstats` this will produce `${basename}.txt` and `${basename}.svg`. SVG contains call graph. Text file contains list of all functions sorted by cumulative execution time. You may also try `make all-png`.
For every `${basename}.pstats` this will produce `${basename}.txt` and `${basename}.svg`. SVG files contain call graphs. Text files contain lists of all functions, sorted by cumulative execution time. You may also try `make all-png`.
~~~
make index.html
~~~
This creates `index.html` with all SVG graphics linked to TXT files. Ready for upload.
This creates `index.html` with all SVG graphics linked to TXT files, ready for upload.
~~~
make REMOTE=example.com:public_html/qubes/profiling/ upload
@ -95,4 +95,4 @@ This example is from `qubes-manager` (`qubesmanager/main.py`).
!["update\_table-20140424-170010.svg"](//attachment/wiki/Profiling/update_table-20140424-170010.svg)
It is apparent than problem is around `get_disk_usage` which calls something via `subprocess.call`. It does it 15 times, probably once per VM.
It is apparent that the problem is around `get_disk_usage`, which calls something via `subprocess.call`. It does this 15 times, probably once per VM.

33
external/troubleshooting/out-of-memory.md vendored
View File

@ -19,29 +19,28 @@ qvm-console-dispvm <VMname>
If this does not work, check the size of /var/lib/qubes/qubes.xml. If it is zero, you'll need to use one of the file backup (stored in /var/lib/qubes/backup), hopefully you have the current data there. Find the most recent one and place in /var/lib/qubes/qubes.xml instead of the empty file.
In any case you'll need some disk space to start the VM. Check `df -h` output if you have some. If not, some hints how to free some disk space:
In any case you'll need some disk space to start the VM. Check `df -h` output if you have some. If not, here are some hints how to free some disk space:
1. Clean yum cache:
1. Clean yum cache.
~~~
sudo yum clean all
~~~
~~~
sudo yum clean all
~~~
1. Delete .img files of a less important VM, that can be found in
2. Delete `.img` files of a less important VM, which can be found in `/var/lib/qubes/appvms/`.
Then, when the system is working again, clean up the rest.
/var/lib/qubes/appvms/. Then, when the system is working again, cleanup the rest with:
~~~
qvm-remove <VMname>
~~~
~~~
qvm-remove <VMname>
~~~
With this method, you lose the data of one VM, but it'll work more reliably.
With this method you lose the data of one VM, but it'll work more reliably.
3. Decrease the filesystem safety margin (5% by default).
1. Decrease filesystem safety margin (5% by default):
~~~
sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root
~~~
~~~
sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root
~~~
1. Remove some unneeded files in dom0 home (if you have any, most likely not).
4. Remove some unneeded files in dom0 home (if you have any, most likely not).

2
introduction/intro.md
View File

@ -17,7 +17,7 @@ What is Qubes OS?
<div class="col-lg-3 col-md-3 text-left">
<p>Qubes OS is a free and open-source security-oriented operating system meant for single-user desktop computing.</p>
<p>Qubes OS leverages <a href="https://wiki.xen.org/wiki/Xen_Project_Software_Overview">xen-based virtualization</a> to allow for the creation and management of isolated virtual machines called <a href="/doc/glossary#qube">qubes</a>.
Qubes, which are also referred to as <a href="/doc/glossary#domain">domains</a> or compartments, have specific :</p>
Qubes, which are implemented as <a href="/doc/glossary#vm">virtual machines (VMs)</a>, have specific :</p>
<ul>
<li><b>Purposes</b> : with a predefined set of one or many isolated applications, for personal or professional projects, to manage the <a href="/doc/networking/">network stack</a>, <a href="/doc/firewall/">the firewall</a>, or to fulfill other user-defined purposes.</li>
<li><b>Natures</b> : <a href="/doc/standalone-and-hvm/">full-fledged</a> or <a href="/getting-started/#appvms-qubes-and-templatevms">stripped-down</a> virtual machines which are based on popular operating systems such as <a href="/doc/templates/fedora">Fedora</a>, <a href="/doc/templates/debian">Debian</a> or <a href="/doc/windows/">Windows</a>.</li>

9
introduction/support.md
View File

@ -339,6 +339,15 @@ To unsubscribe, send a blank email to `qubes-translation+unsubscribe@googlegroup
This list also has an optional [Google Groups web interface][qubes-translation-web].
## Unofficial chat channels ##
The following unofficial chat channels are maintained by the community:
* Matrix, Qubes-related: <https://matrix.to/#/#cybersec-qubes_os:matrix.org>
* Matrix, strictly Qubes: <https://matrix.to/#/#Qubes-OS:matrix.org>
* `#qubes` channel on freenode.net via traditional IRC clients or: <https://webchat.freenode.net/>
[mailing lists]: https://en.wikipedia.org/wiki/Electronic_mailing_list
[Qubes team]: /team/
[contributions]: /doc/contributing/