mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-09-21 13:34:43 -04:00
Fixes to code block pygemnt's highlighting, add __pychache__ to gitignore
add prompts to terminal sessions where needed
This commit is contained in:
parent
9bd5e20bfd
commit
7e76afb1a4
31 changed files with 108 additions and 106 deletions
1
.gitignore
vendored
1
.gitignore
vendored
|
@ -1 +1,2 @@
|
|||
_build
|
||||
**/__pycache__/*
|
||||
|
|
|
@ -48,7 +48,7 @@ To update (git fetch) **all** of these repositories :
|
|||
|
||||
.. code:: console
|
||||
|
||||
find . -mindepth 1 -maxdepth 1 -type d -exec git -C {} fetch --tags --recurse-submodules=on-demand --all \;
|
||||
$ find . -mindepth 1 -maxdepth 1 -type d -exec git -C {} fetch --tags --recurse-submodules=on-demand --all \;
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -157,7 +157,7 @@ Arrange firewall so you can reach the testbench from your ``qubes-dev`` VM. Gene
|
|||
|
||||
.. code:: console
|
||||
|
||||
ssh-keygen -t ecdsa -b 521
|
||||
$ ssh-keygen -t ecdsa -b 521
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -90,7 +90,7 @@ In a src VM, one should invoke the qrexec client via the following command:
|
|||
|
||||
.. code:: console
|
||||
|
||||
/usr/lib/qubes/qrexec-client-vm <target vm name> <service name> <local program path> [local program arguments]
|
||||
$ /usr/lib/qubes/qrexec-client-vm <target vm name> <service name> <local program path> [local program arguments]
|
||||
|
||||
|
||||
|
||||
|
@ -164,7 +164,7 @@ We will show the necessary files to create a simple RPC call that adds two integ
|
|||
|
||||
.. code:: console
|
||||
|
||||
/usr/lib/qubes/qrexec-client-vm <target VM> test.Add /usr/bin/our_test_add_client 1 2
|
||||
$ /usr/lib/qubes/qrexec-client-vm <target VM> test.Add /usr/bin/our_test_add_client 1 2
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ Reporting security issues in Qubes OS
|
|||
|
||||
If you’ve discovered a security issue affecting Qubes OS, either directly or indirectly (e.g., the issue affects Xen in a configuration that is used in Qubes OS), then we would be more than happy to hear from you! We promise to take all reported issues seriously. If our investigation confirms that an issue affects Qubes, we will patch it within a reasonable time and release a public `Qubes security bulletin (QSB) <https://www.qubes-os.org/security/qsb/>`__ that describes the issue, discusses the potential impact of the vulnerability, references applicable patches or workarounds, and credits the discoverer. Please use the `Qubes security team PGP key <https://keys.qubes-os.org/keys/qubes-os-security-team-key.asc>`__ to encrypt your email to this address:
|
||||
|
||||
.. code:: console
|
||||
.. code:: text
|
||||
|
||||
security at qubes-os dot org
|
||||
|
||||
|
|
|
@ -188,7 +188,7 @@ Set ``default_guivm`` as ``dom0``:
|
|||
|
||||
.. code:: console
|
||||
|
||||
qubes-prefs default_guivm dom0
|
||||
$ qubes-prefs default_guivm dom0
|
||||
|
||||
|
||||
and for every selected qubes not using default value for GUI domain property, for example with a qube ``personal``:
|
||||
|
|
|
@ -99,7 +99,7 @@ You can also use ``kstart`` to control virtual desktop placement like this:
|
|||
|
||||
.. code:: console
|
||||
|
||||
kstart --desktop 3 --windowclass <vm_name> -q --tray -a <vm_name> '<run_program_command>'
|
||||
$ kstart --desktop 3 --windowclass <vm_name> -q --tray -a <vm_name> '<run_program_command>'
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -285,7 +285,7 @@ Finally, you need to create a GRUB configuration. You may want to adjust some se
|
|||
|
||||
You can safely ignore this error message:
|
||||
|
||||
.. code:: console
|
||||
.. code:: output
|
||||
|
||||
grub2-probe: error: cannot find a GRUB drive for /dev/mapper/dmroot. Check your device.map
|
||||
|
||||
|
|
|
@ -92,10 +92,10 @@ FreeBSD
|
|||
|
||||
.. code:: console
|
||||
|
||||
gpart recover ada0
|
||||
sysctl kern.geom.debugflags=0x10
|
||||
gpart resize -i index ada0
|
||||
zpool online -e poolname ada0
|
||||
$ gpart recover ada0
|
||||
$ sysctl kern.geom.debugflags=0x10
|
||||
$ gpart resize -i index ada0
|
||||
$ zpool online -e poolname ada0
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -72,8 +72,8 @@ It is possible to use an existing Btrfs storage if it is configured. In dom0, av
|
|||
|
||||
.. code:: console
|
||||
|
||||
mount -t btrfs
|
||||
btrfs show filesystem
|
||||
$ mount -t btrfs
|
||||
$ btrfs show filesystem
|
||||
|
||||
|
||||
To register the storage to qubes use the following command where ``<pool_name>`` is a freely chosen pool name adn ``<dir_path>`` is the mounted path to the second btrfs storage:
|
||||
|
|
|
@ -393,7 +393,7 @@ Unzip VirtualBox zip file:
|
|||
|
||||
.. code:: console
|
||||
|
||||
unzip *.zip
|
||||
$ unzip *.zip
|
||||
|
||||
|
||||
|
||||
|
@ -401,7 +401,7 @@ Extract OVA tar archive:
|
|||
|
||||
.. code:: console
|
||||
|
||||
tar -xvf *.ova
|
||||
$ tar -xvf *.ova
|
||||
|
||||
|
||||
|
||||
|
@ -409,7 +409,7 @@ Convert vmdk to raw:
|
|||
|
||||
.. code:: console
|
||||
|
||||
qemu-img convert -O raw *.vmdk win10.raw
|
||||
$ qemu-img convert -O raw *.vmdk win10.raw
|
||||
|
||||
|
||||
|
||||
|
@ -445,7 +445,7 @@ Filetype of OVA file:
|
|||
|
||||
.. code:: console
|
||||
|
||||
file *.ova
|
||||
$ file *.ova
|
||||
|
||||
|
||||
|
||||
|
@ -453,7 +453,7 @@ List files of OVA tar archive:
|
|||
|
||||
.. code:: console
|
||||
|
||||
tar -tf *.ova
|
||||
$ tar -tf *.ova
|
||||
|
||||
|
||||
|
||||
|
@ -461,7 +461,7 @@ List filetypes supported by qemu-img:
|
|||
|
||||
.. code:: console
|
||||
|
||||
qemu-img -h | tail -n1
|
||||
$ qemu-img -h | tail -n1
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -31,7 +31,7 @@ It is critical to complete this step **before** proceeding to dom0 upgrade. Othe
|
|||
|
||||
.. code:: console
|
||||
|
||||
rpm -q qubes-core-vm
|
||||
$ rpm -q qubes-core-vm
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -78,13 +78,13 @@ Upgrading dom0
|
|||
|
||||
.. code:: console
|
||||
|
||||
rm -f /etc/group.rpmnew
|
||||
rm -f /etc/shadow.rpmnew
|
||||
rm -f /etc/qubes/guid.conf.rpmnew
|
||||
mv -f /etc/nsswitch.conf{.rpmnew,}
|
||||
mv -f /etc/pam.d/postlogin{.rpmnew,}
|
||||
mv -f /etc/salt/minion.d/f_defaults.conf{.rpmnew,}
|
||||
mv -f /etc/dracut.conf{.rpmnew,}
|
||||
$ rm -f /etc/group.rpmnew
|
||||
$ rm -f /etc/shadow.rpmnew
|
||||
$ rm -f /etc/qubes/guid.conf.rpmnew
|
||||
$ mv -f /etc/nsswitch.conf{.rpmnew,}
|
||||
$ mv -f /etc/pam.d/postlogin{.rpmnew,}
|
||||
$ mv -f /etc/salt/minion.d/f_defaults.conf{.rpmnew,}
|
||||
$ mv -f /etc/dracut.conf{.rpmnew,}
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -29,16 +29,16 @@ If you would prefer to perform a clean installation rather than upgrading in-pla
|
|||
|
||||
6. Install the ``qubes-dist-upgrade`` tool. This is the inplace upgrade tool, which is not what we’re doing. However it will be needed in order to upgrade the templates to the 4.3 version. You install it with the following command in the dom0 terminal:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo qubes-dom0-update -y qubes-dist-upgrade
|
||||
$ sudo qubes-dom0-update -y qubes-dist-upgrade
|
||||
|
||||
|
||||
7. Change your templates to use the 4.3 repositories instead of the 4.2 ones. You do this with the following command in the dom0 terminal:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade
|
||||
$ sudo qubes-dist-upgrade --releasever=4.3 --template-standalone-upgrade
|
||||
|
||||
|
||||
**Note**: This step is critical to ensure the templates will receive updates once Qubes 4.2 reaches end-of-life (EOL).
|
||||
|
@ -54,9 +54,9 @@ The upgrade may take several hours, and will download several gigabytes of data.
|
|||
|
||||
In place upgrade is a complex operation. For this reason, we provide a ``qubes-dist-upgrade`` tool to handle all the necessary steps automatically. You can install it with the following command in the dom0 terminal:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo qubes-dom0-update -y qubes-dist-upgrade
|
||||
$ sudo qubes-dom0-update -y qubes-dist-upgrade
|
||||
|
||||
|
||||
|
||||
|
@ -114,9 +114,9 @@ Full list of options can be obtained with ``qubes-dist-upgrade --releasever=4.3
|
|||
|
||||
After installing the tool, before-reboot stages can be performed at once with:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo qubes-dist-upgrade --all-pre-reboot
|
||||
$ sudo qubes-dist-upgrade --all-pre-reboot
|
||||
|
||||
|
||||
|
||||
|
@ -126,9 +126,9 @@ Alternatively, each upgrade stage can be started separately (see the list of opt
|
|||
|
||||
After completing “STAGE 1” through “STAGE 3”, restart the system. Then perform the final steps:
|
||||
|
||||
.. code:: bash
|
||||
.. code:: console
|
||||
|
||||
sudo qubes-dist-upgrade --all-post-reboot
|
||||
$ sudo qubes-dist-upgrade --all-post-reboot
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -71,8 +71,9 @@ The Qubes backup system has been designed with emergency disaster recovery in mi
|
|||
|
||||
**Note:** For multi-part files, a loop can be used:
|
||||
|
||||
.. code:: console
|
||||
.. code:: bash
|
||||
|
||||
#!/bin/sh
|
||||
find -name 'private.img.*' | sort -V | while read f; do
|
||||
openssl enc -d -md MD5 -pass pass:"$backup_pass" -aes-256-cbc -in $f -out
|
||||
${f/.img/.img.dec}
|
||||
|
|
|
@ -81,6 +81,6 @@ Note that you can use the same method to copy files from dom0 to domUs (if, for
|
|||
|
||||
.. code:: console
|
||||
|
||||
cat /path/to/file_in_dom0 | qvm-run --pass-io <dest-vm> 'cat > /path/to/file_name_in_appvm'
|
||||
$ cat /path/to/file_in_dom0 | qvm-run --pass-io <dest-vm> 'cat > /path/to/file_name_in_appvm'
|
||||
|
||||
|
||||
|
|
|
@ -281,7 +281,7 @@ The updates proxy uses RPC/qrexec. The proxy is configured in qrexec policy in d
|
|||
|
||||
Example policy file in R4.1 (with Whonix installed, but not set as default UpdateVM for all templates):
|
||||
|
||||
.. code:: console
|
||||
.. code:: text
|
||||
|
||||
# any VM with tag `whonix-updatevm` should use `sys-whonix`; this tag is added to `whonix-gw` and `whonix-ws` during installation and is preserved during template clone
|
||||
@tag:whonix-updatevm @default allow,target=sys-whonix
|
||||
|
|
|
@ -62,7 +62,7 @@ In case of a USB-drive, make sure it’s attached to your computer. If you don
|
|||
|
||||
This will list all available block devices in your system across all VMs. The name of the qube hosting the block device is displayed before the colon in the device ID. The string after the colon is the ID of the device used within the qube, like so:
|
||||
|
||||
.. code:: console
|
||||
.. code:: output
|
||||
|
||||
sourceVM:sdb Cruzer () 4GiB
|
||||
sourceVM:sdb1 Disk () 2GiB
|
||||
|
@ -127,7 +127,7 @@ To recover from this error state, in dom0 run
|
|||
|
||||
.. code:: console
|
||||
|
||||
virsh detach-disk targetVM xvdi
|
||||
$ virsh detach-disk targetVM xvdi
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -158,7 +158,7 @@ To find the right controller, follow the usb bus:
|
|||
|
||||
.. code:: console
|
||||
|
||||
readlink /sys/bus/usb/devices/usb3
|
||||
$ readlink /sys/bus/usb/devices/usb3
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -355,7 +355,7 @@ In the sys-net VM’s Terminal, the first step is to define an nftables chain th
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
|
||||
$ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
|
||||
|
||||
|
||||
|
||||
|
@ -369,7 +369,7 @@ Second step, code a natting firewall rule to route traffic on the outside interf
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-dnat-qubeDEST iifname ens6 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
|
||||
$ nft add rule qubes custom-dnat-qubeDEST iifname ens6 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.1.z
|
||||
|
||||
|
||||
|
||||
|
@ -377,7 +377,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-forward iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
|
||||
$ nft add rule qubes custom-forward iifname ens6 ip saddr 192.168.x.y/24 ip daddr 10.137.1.z tcp dport 443 ct state new,established,related counter accept
|
||||
|
||||
|
||||
|
||||
|
@ -391,7 +391,7 @@ Verify the rules on the sys-net firewall correctly match the packets you want by
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft list table ip qubes
|
||||
$ nft list table ip qubes
|
||||
|
||||
|
||||
|
||||
|
@ -414,7 +414,7 @@ In this example, we can see 7 packets in the forward rule, and 3 packets in the
|
|||
|
||||
.. code:: console
|
||||
|
||||
telnet 192.168.x.n 443
|
||||
$ telnet 192.168.x.n 443
|
||||
|
||||
|
||||
|
||||
|
@ -453,7 +453,7 @@ In the sys-firewall Terminal, add a DNAT chain that will contain routing rules:
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
|
||||
$ nft add chain qubes custom-dnat-qubeDEST '{ type nat hook prerouting priority filter +1 ; policy accept; }'
|
||||
|
||||
|
||||
|
||||
|
@ -461,7 +461,7 @@ Second step, code a natting firewall rule to route traffic on the outside interf
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-dnat-qubeDEST iifgroup 1 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
|
||||
$ nft add rule qubes custom-dnat-qubeDEST iifgroup 1 ip saddr 192.168.x.y/24 tcp dport 443 ct state new,established,related counter dnat 10.137.0.xx
|
||||
|
||||
|
||||
|
||||
|
@ -469,7 +469,7 @@ Third step, code the appropriate new filtering firewall rule to allow new connec
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
|
||||
$ nft add rule qubes custom-forward iifgroup 1 ip saddr 192.168.x.y/24 ip daddr 10.137.0.xx tcp dport 443 ct state new,established,related counter accept
|
||||
|
||||
|
||||
|
||||
|
@ -516,7 +516,7 @@ The according rule to allow the traffic is:
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx ct state new,established,related counter accept
|
||||
$ nft add rule qubes custom-input tcp dport 443 ip daddr 10.137.0.xx ct state new,established,related counter accept
|
||||
|
||||
|
||||
|
||||
|
@ -549,7 +549,7 @@ For instance, if you want to check if your network interface ``eth0`` is receivi
|
|||
|
||||
.. code:: console
|
||||
|
||||
tcpdump -i eth0 -nn dst port 443 and src net 192.168.x.y/24
|
||||
$ tcpdump -i eth0 -nn dst port 443 and src net 192.168.x.y/24
|
||||
|
||||
|
||||
|
||||
|
@ -567,7 +567,7 @@ You can dump the ruleset in two files using the following command:
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft list ruleset | tee nft_backup | tee nft_new_ruleset
|
||||
$ nft list ruleset | tee nft_backup | tee nft_new_ruleset
|
||||
|
||||
|
||||
|
||||
|
@ -577,6 +577,6 @@ You can revert to the original ruleset with the following commands:
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft flush ruleset && nft -f nft_backup
|
||||
$ nft flush ruleset && nft -f nft_backup
|
||||
|
||||
|
||||
|
|
|
@ -329,7 +329,7 @@ In the sys-net VM’s Terminal, code a natting firewall rule to route traffic on
|
|||
|
||||
.. code:: console
|
||||
|
||||
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j DNAT --to-destination 10.137.1.z
|
||||
$ iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.x.y -j DNAT --to-destination 10.137.1.z
|
||||
|
||||
|
||||
|
||||
|
@ -337,7 +337,7 @@ Code the appropriate new filtering firewall rule to allow new connections for th
|
|||
|
||||
.. code:: console
|
||||
|
||||
iptables -I FORWARD 2 -i eth0 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
|
||||
$ iptables -I FORWARD 2 -i eth0 -d 10.137.1.z -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
|
||||
|
||||
|
||||
|
||||
|
@ -353,8 +353,8 @@ Verify you are cutting through the sys-net VM firewall by looking at its counter
|
|||
|
||||
.. code:: console
|
||||
|
||||
iptables -t nat -L -v -n
|
||||
iptables -L -v -n
|
||||
$ iptables -t nat -L -v -n
|
||||
$ iptables -L -v -n
|
||||
|
||||
|
||||
|
||||
|
@ -364,7 +364,7 @@ Verify you are cutting through the sys-net VM firewall by looking at its counter
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft list table ip qubes-firewall
|
||||
$ nft list table ip qubes-firewall
|
||||
|
||||
|
||||
|
||||
|
@ -372,7 +372,7 @@ Send a test packet by trying to connect to the service from an external device
|
|||
|
||||
.. code:: console
|
||||
|
||||
telnet 192.168.x.y 443
|
||||
$ telnet 192.168.x.y 443
|
||||
|
||||
|
||||
|
||||
|
@ -457,7 +457,7 @@ In the sys-firewall VM’s Terminal, code a natting firewall rule to route traff
|
|||
|
||||
.. code:: console
|
||||
|
||||
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.z -j DNAT --to-destination 10.137.0.xx
|
||||
$ iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.z -j DNAT --to-destination 10.137.0.xx
|
||||
|
||||
|
||||
|
||||
|
@ -465,7 +465,7 @@ Code the appropriate new filtering firewall rule to allow new connections for th
|
|||
|
||||
.. code:: console
|
||||
|
||||
iptables -I FORWARD 2 -i eth0 -s 192.168.x.0/24 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
|
||||
$ iptables -I FORWARD 2 -i eth0 -s 192.168.x.0/24 -d 10.137.0.xx -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT
|
||||
|
||||
|
||||
|
||||
|
@ -477,7 +477,7 @@ Code the appropriate new filtering firewall rule to allow new connections for th
|
|||
|
||||
.. code:: console
|
||||
|
||||
nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
|
||||
$ nft add rule ip qubes-firewall forward meta iifname eth0 ip saddr 192.168.x.0/24 ip daddr 10.137.0.xx tcp dport 443 ct state new counter accept
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -35,7 +35,7 @@ As the name implies, this generates authentication code that is time-dependent.
|
|||
|
||||
.. code:: console
|
||||
|
||||
google-authenticator
|
||||
$ google-authenticator
|
||||
|
||||
|
||||
|
||||
|
@ -238,8 +238,8 @@ All these requirements are described below, step by step, for the YubiKey and Ni
|
|||
|
||||
.. code:: console
|
||||
|
||||
AESKEY=$(echo -n "your-20-digit-secret" | base32)
|
||||
nitropy nk3 secrets register --kind hotp --hash sha256 --digits-str 8 --counter-start 1 --touch-button loginxs $AESKEY
|
||||
$ AESKEY=$(echo -n "your-20-digit-secret" | base32)
|
||||
$ nitropy nk3 secrets register --kind hotp --hash sha256 --digits-str 8 --counter-start 1 --touch-button loginxs $AESKEY
|
||||
|
||||
|
||||
|
||||
|
@ -283,7 +283,7 @@ All these requirements are described below, step by step, for the YubiKey and Ni
|
|||
|
||||
.. code:: console
|
||||
|
||||
read -r password
|
||||
$ read -r password
|
||||
|
||||
|
||||
|
||||
|
@ -420,8 +420,8 @@ If you use KDE, the command(s) in first step would be different:
|
|||
|
||||
# In the case of USB VM being autostarted, it will not have direct access to D-Bus
|
||||
# session bus, so find its address manually:
|
||||
kde_pid=`pidof kdeinit4`
|
||||
export `cat /proc/$kde_pid/environ|grep -ao 'DBUS_SESSION_BUS_ADDRESS=[[:graph:]]*'`
|
||||
qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
|
||||
$ kde_pid=`pidof kdeinit4`
|
||||
$ export `cat /proc/$kde_pid/environ|grep -ao 'DBUS_SESSION_BUS_ADDRESS=[[:graph:]]*'`
|
||||
$ qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
|
||||
|
||||
|
||||
|
|
|
@ -25,7 +25,7 @@ Create/Edit ``/etc/qubes/policy.d/30-user-gpg2.policy`` in dom0, and add a line
|
|||
|
||||
.. code:: console
|
||||
|
||||
qubes.Gpg2 + gpg-client-vm @default allow target=gpg-server-vm
|
||||
$ qubes.Gpg2 + gpg-client-vm @default allow target=gpg-server-vm
|
||||
|
||||
|
||||
|
||||
|
@ -33,8 +33,8 @@ Import/Generate your secret keys in the server domain. For example:
|
|||
|
||||
.. code:: console
|
||||
|
||||
gpg-server-vm$ gpg --import /path/to/my/secret-keys-export
|
||||
gpg-server-vm$ gpg --import-ownertrust /path/to/my/ownertrust-export
|
||||
$ gpg-server-vm$ gpg --import /path/to/my/secret-keys-export
|
||||
$ gpg-server-vm$ gpg --import-ownertrust /path/to/my/ownertrust-export
|
||||
|
||||
|
||||
|
||||
|
@ -42,7 +42,7 @@ or
|
|||
|
||||
.. code:: console
|
||||
|
||||
gpg-server-vm$ gpg --gen-key
|
||||
$ gpg-server-vm$ gpg --gen-key
|
||||
|
||||
|
||||
|
||||
|
@ -64,7 +64,7 @@ Output should be:
|
|||
|
||||
.. code:: console
|
||||
|
||||
split-gpg2-client on
|
||||
$ split-gpg2-client on
|
||||
|
||||
|
||||
Restart the client domain.
|
||||
|
@ -73,12 +73,12 @@ Export the **public** part of your keys and import them in the client domain. Al
|
|||
|
||||
.. code:: console
|
||||
|
||||
gpg-server-vm$ gpg --export > public-keys-export
|
||||
gpg-server-vm$ gpg --export-ownertrust > ownertrust-export
|
||||
gpg-server-vm$ qvm-copy public-keys-export ownertrust-export
|
||||
$ gpg-server-vm$ gpg --export > public-keys-export
|
||||
$ gpg-server-vm$ gpg --export-ownertrust > ownertrust-export
|
||||
$ gpg-server-vm$ qvm-copy public-keys-export ownertrust-export
|
||||
|
||||
gpg-client-vm$ gpg --import ~/QubesIncoming/gpg-server-vm/public-keys-export
|
||||
gpg-client-vm$ gpg --import-ownertrust ~/QubesIncoming/gpg-server-vm/ownertrust-export
|
||||
$ gpg-client-vm$ gpg --import ~/QubesIncoming/gpg-server-vm/public-keys-export
|
||||
$ gpg-client-vm$ gpg --import-ownertrust ~/QubesIncoming/gpg-server-vm/ownertrust-export
|
||||
|
||||
|
||||
|
||||
|
@ -86,7 +86,7 @@ This should be enough to have it running:
|
|||
|
||||
.. code:: console
|
||||
|
||||
gpg-client-vm$ gpg -K
|
||||
$ gpg-client-vm$ gpg -K
|
||||
/home/user/.gnupg/pubring.kbx
|
||||
-----------------------------
|
||||
sec# rsa2048 2019-12-18 [SC] [expires: 2021-12-17]
|
||||
|
|
|
@ -283,7 +283,7 @@ At this point you may open a tab in dom0 for debugging, in case something goes a
|
|||
|
||||
.. code:: console
|
||||
|
||||
tailf /var/log/qubes/vm-win7new.log \
|
||||
$ tailf /var/log/qubes/vm-win7new.log \
|
||||
/var/log/xen/console/hypervisor.log \
|
||||
/var/log/xen/console/guest-win7new-dm.log
|
||||
|
||||
|
|
|
@ -342,7 +342,7 @@ These parameters are set for the following reasons:
|
|||
|
||||
.. code:: console
|
||||
|
||||
tailf /var/log/qubes/vm-WindowsNew.log \
|
||||
$ tailf /var/log/qubes/vm-WindowsNew.log \
|
||||
/var/log/xen/console/hypervisor.log \
|
||||
/var/log/xen/console/guest-WindowsNew-dm.log
|
||||
|
||||
|
|
|
@ -70,7 +70,7 @@ It helps to run the following command:
|
|||
|
||||
.. code:: console
|
||||
|
||||
nslookup security.debian.org
|
||||
$ nslookup security.debian.org
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -127,7 +127,7 @@ To fix this issue:
|
|||
|
||||
.. code:: console
|
||||
|
||||
fuser -m /home
|
||||
$ fuser -m /home
|
||||
|
||||
|
||||
|
||||
|
@ -139,9 +139,9 @@ Kill these process until they are all gone using ``kill <process ID>``.
|
|||
|
||||
.. code:: console
|
||||
|
||||
umount /home
|
||||
fsck /dev/xvdb
|
||||
resize2fs /dev/xvdb
|
||||
$ umount /home
|
||||
$ fsck /dev/xvdb
|
||||
$ resize2fs /dev/xvdb
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -61,7 +61,7 @@ If this solves the problem then you will want to make the change permanent:
|
|||
|
||||
.. code:: console
|
||||
|
||||
grub2-mkconfig --output=/boot/grub2/grub.cfg
|
||||
$ grub2-mkconfig --output=/boot/grub2/grub.cfg
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -13,9 +13,9 @@ To change this allocation, edit VM’s kernel parameters (this is expressed in 5
|
|||
|
||||
.. code:: console
|
||||
|
||||
# qvm-prefs netvm |grep kernelopts
|
||||
$ qvm-prefs netvm |grep kernelopts
|
||||
kernelopts : iommu=soft swiotlb=2048 (default)
|
||||
# qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=8192"
|
||||
$ qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=8192"
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ Successfully installed in legacy mode, but had to change some xen parameters
|
|||
|
||||
.. code:: console
|
||||
|
||||
vi EFI/BOOT/grub.cfg
|
||||
$ vi EFI/BOOT/grub.cfg
|
||||
|
||||
|
||||
|
||||
|
@ -65,7 +65,7 @@ Some Dell systems and probably others have `another bug in UEFI firmware <https:
|
|||
|
||||
.. code:: console
|
||||
|
||||
sed -i -e 's/ucode=scan/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/grub.cfg
|
||||
$ sed -i -e 's/ucode=scan/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/grub.cfg
|
||||
|
||||
|
||||
|
||||
|
@ -85,7 +85,7 @@ Or if you have already rebooted after the first stage install and have encounter
|
|||
|
||||
.. code:: console
|
||||
|
||||
fdisk -l /dev/sda | grep EFI
|
||||
$ fdisk -l /dev/sda | grep EFI
|
||||
|
||||
The output should look like this:
|
||||
|
||||
|
@ -97,14 +97,14 @@ Or if you have already rebooted after the first stage install and have encounter
|
|||
|
||||
.. code:: console
|
||||
|
||||
mkdir -p /mnt/sysimage/boot/efi
|
||||
mount /dev/sda1 /mnt/sysimage/boot/efi
|
||||
$ mkdir -p /mnt/sysimage/boot/efi
|
||||
$ mount /dev/sda1 /mnt/sysimage/boot/efi
|
||||
|
||||
4. Execute:
|
||||
|
||||
.. code:: console
|
||||
|
||||
sed -i -e 's/ucode=scan/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/grub.cfg
|
||||
$ sed -i -e 's/ucode=scan/\0 efi=attr=uc/' /mnt/sysimage/boot/efi/EFI/qubes/grub.cfg
|
||||
|
||||
|
||||
|
||||
|
@ -128,7 +128,7 @@ Some firmware will not recognize the default Qubes EFI configuration. As such, i
|
|||
|
||||
.. code:: console
|
||||
|
||||
fdisk -l /dev/sda | grep EFI
|
||||
$ fdisk -l /dev/sda | grep EFI
|
||||
|
||||
The output should look like this:
|
||||
|
||||
|
@ -140,8 +140,8 @@ Some firmware will not recognize the default Qubes EFI configuration. As such, i
|
|||
|
||||
.. code:: console
|
||||
|
||||
mkdir -p /mnt/sysimage/boot/efi
|
||||
mount /dev/sda1 /mnt/sysimage/boot/efi
|
||||
$ mkdir -p /mnt/sysimage/boot/efi
|
||||
$ mount /dev/sda1 /mnt/sysimage/boot/efi
|
||||
|
||||
4. Copy ``grubx64.efi`` to the fallback path:
|
||||
|
||||
|
@ -167,7 +167,7 @@ Some firmware will not recognize the default Qubes EFI configuration. As such, i
|
|||
|
||||
.. code:: console
|
||||
|
||||
efibootmgr -v -c -u -L Qubes -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1
|
||||
$ efibootmgr -v -c -u -L Qubes -l /EFI/qubes/grubx64.efi -d /dev/sda -p 1
|
||||
|
||||
|
||||
|
||||
|
|
|
@ -75,9 +75,9 @@ One solution is to add a dummy interface to allow the package to install correct
|
|||
|
||||
.. code:: console
|
||||
|
||||
ip link add d0 type dummy
|
||||
ip addr add 192.168.0.1/24 dev d0
|
||||
ip link set d0 up
|
||||
$ ip link add d0 type dummy
|
||||
$ ip addr add 192.168.0.1/24 dev d0
|
||||
$ ip link set d0 up
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue