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

Mass replace "AppVM" and "TemplateBasedVM" with "app qube"

Browse source 
QubesOS/qubes-issues#1015
This commit is contained in:
Andrew David Wong 2021-06-18 01:55:53 -07:00
parent 719836c9f3
commit aea595397f
No known key found for this signature in database
GPG key ID: 8CE137352A019A17
28 changed files with 111 additions and 111 deletions
Download patch file Download diff file Expand all files Collapse all files

18
user/advanced-topics/bind-dirs.md
View file

@ -12,12 +12,12 @@ title: How to Make Any File Persistent (bind-dirs)
## What are bind-dirs? ##
With [bind-dirs](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/bind-dirs.sh)
any arbitrary files or folders can be made persistent in TemplateBasedVMs.
any arbitrary files or folders can be made persistent in app qubes.
## What is it useful for? ##
In a TemplateBasedVM all of the file system comes from the template except `/home`, `/usr/local`, and `/rw`.
This means that changes in the rest of the filesystem are lost when the TemplateBasedVM is shutdown.
In an app qube all of the file system comes from the template except `/home`, `/usr/local`, and `/rw`.
This means that changes in the rest of the filesystem are lost when the app qube is shutdown.
bind-dirs provides a mechanism whereby files usually taken from the template can be persisted across reboots.
For example, in Whonix, [Tor's data dir `/var/lib/tor` has been made persistent in the TemplateBased ProxyVM sys-whonix](https://github.com/Whonix/qubes-whonix/blob/8438d13d75822e9ea800b9eb6024063f476636ff/usr/lib/qubes-bind-dirs.d/40_qubes-whonix.conf#L5)
@ -27,7 +27,7 @@ In this way sys-whonix can benefit from the Tor anonymity feature 'persistent To
In this example, we want to make `/var/lib/tor` persistent.
Inside the TemplateBasedVM.
Inside the app qube.
1. Make sure folder `/rw/config/qubes-bind-dirs.d` exists.
@ -45,7 +45,7 @@ Inside the TemplateBasedVM.
4. Save.
5. Reboot the TemplateBasedVM.
5. Reboot the app qube.
6. Done.
@ -67,17 +67,17 @@ binds+=( '/etc/tor/torrc' )
## How does it work? ##
bind-dirs.sh is called at startup of a TemplateBasedVM, and configuration files in the above configuration folders are parsed to build a bash array.
bind-dirs.sh is called at startup of an app qube, and configuration files in the above configuration folders are parsed to build a bash array.
Files or folders identified in the array are copied to `/rw/bind-dirs` if they do not already exist there, and are then bind mounted over the original files/folders.
Creation of the files and folders in `/rw/bind-dirs` should be automatic the first time the TemplateBasedVM is restarted after configuration.
Creation of the files and folders in `/rw/bind-dirs` should be automatic the first time the app qube is restarted after configuration.
If you want to circumvent this process, you can create the relevant file structure under `/rw/bind-dirs` and make any changes at the same time that you perform the configuration, before reboot.
Note that you must create the full folder structure under `/rw/bind-dirs` - e.g you would have to create `/rw/bind-dirs/var/lib/tor`
## Limitations ##
* Files that exist in the TemplateVM root image cannot be deleted in the TemplateBasedVMs root image using bind-dirs.sh.
* Files that exist in the TemplateVM root image cannot be deleted in the app qubes root image using bind-dirs.sh.
* Re-running `sudo /usr/lib/qubes/init/bind-dirs.sh` without a previous `sudo /usr/lib/qubes/init/bind-dirs.sh umount` does not work.
* Running `sudo /usr/lib/qubes/init/bind-dirs.sh umount` after boot (before shutdown) is probably not sane and nothing can be done about that.
* Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount.
@ -102,5 +102,5 @@ binds=( "${binds[@]/'/var/lib/tor'}" )
## Discussion ##
[TemplateBasedVMs: make selected files and folders located in the root image persistent- review bind-dirs.sh](https://groups.google.com/forum/#!topic/qubes-devel/tcYQ4eV-XX4/discussion)
[app qubes: make selected files and folders located in the root image persistent- review bind-dirs.sh](https://groups.google.com/forum/#!topic/qubes-devel/tcYQ4eV-XX4/discussion)

6
user/advanced-topics/config-files.md
View file

@ -36,7 +36,7 @@ The scripts here all run as root.
- `/rw/config/qubes-ip-change-hook` - script runs in NetVM after every external IP change and on "hardware" link status change.
- In ProxyVMs (or AppVMs with `qubes-firewall` service enabled), scripts placed in the following directories will be executed in the listed order followed by `qubes-firewall-user-script` at start up.
- In ProxyVMs (or app qubes with `qubes-firewall` service enabled), scripts placed in the following directories will be executed in the listed order followed by `qubes-firewall-user-script` at start up.
Good place to write custom firewall rules.
~~~
@ -49,7 +49,7 @@ The scripts here all run as root.
The file is used only in a VM with PCI devices attached.
Intended for use with problematic device drivers.
- In NetVMs/ProxyVMs, scripts placed in `/rw/config/network-hooks.d` will be ran when configuring Qubes interfaces. For each script, the `command`, `vif`, `vif_type` and `ip` is passed as arguments (see `/etc/xen/scripts/vif-route-qubes`). For example, consider a PV AppVM `work` with IP `10.137.0.100` and `sys-firewall` as NetVM. Assuming it's Xen domain id is arbitrary `12` then, the following script located at `/rw/config/network-hooks.d/hook-100.sh` in `sys-firewall`:
- In NetVMs/ProxyVMs, scripts placed in `/rw/config/network-hooks.d` will be ran when configuring Qubes interfaces. For each script, the `command`, `vif`, `vif_type` and `ip` is passed as arguments (see `/etc/xen/scripts/vif-route-qubes`). For example, consider a PV app qube `work` with IP `10.137.0.100` and `sys-firewall` as NetVM. Assuming it's Xen domain id is arbitrary `12` then, the following script located at `/rw/config/network-hooks.d/hook-100.sh` in `sys-firewall`:
~~~
#!/bin/bash
@ -75,7 +75,7 @@ The scripts here all run as root.
Note that scripts need to be executable (`chmod +x`) to be used.
Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easily modify arbitrary system files in an AppVM and have those changes persist.
Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easily modify arbitrary system files in an app qube and have those changes persist.
GUI and audio configuration in dom0
-----------------------------------

14
user/advanced-topics/disposablevm-customization.md
View file

@ -15,15 +15,15 @@ title: DisposableVM Customization
## Introduction
A [DisposableVM](/doc/disposablevm) can be based on any [TemplateBasedVM](/doc/glossary/#templatebasedvm).
A [DisposableVM](/doc/disposablevm) can be based on any [app qube](/doc/glossary/#app-qube).
You can also choose to use different [DisposableVM Templates](/doc/glossary/#disposablevm-template) for different DisposableVMs.
To prepare an AppVM to be a DisposableVM Template, you need to set `template_for_dispvms` property, for example:
To prepare an app qube to be a DisposableVM Template, you need to set `template_for_dispvms` property, for example:
```shell_session
[user@dom0 ~]$ qvm-prefs fedora-26-dvm template_for_dispvms True
```
Additionally, if you want to have menu entries for starting applications in DisposableVM based on this AppVM (instead of in the AppVM itself), you can achieve it with `appmenus-dispvm` feature:
Additionally, if you want to have menu entries for starting applications in DisposableVM based on this app qube (instead of in the app qube itself), you can achieve it with `appmenus-dispvm` feature:
```shell_session
[user@dom0 ~]$ qvm-features fedora-26-dvm appmenus-dispvm 1
@ -84,8 +84,8 @@ This can be done by customizing the DisposableVM Template on which it is based:
You can use a static DisposableVM for `sys-*` as long as it is stateless.
For example, a `sys-net` using DHCP or `sys-usb` will work.
In most cases `sys-firewall` will also work, even if you have configured AppVM firewall rules.
The only exception is if you require something like VM to VM communication and have manually edited `iptables` or other items directly inside the firewall AppVM.
In most cases `sys-firewall` will also work, even if you have configured app qube firewall rules.
The only exception is if you require something like VM to VM communication and have manually edited `iptables` or other items directly inside the firewall app qube.
To create one that has no PCI devices attached, such as for `sys-firewall`:
@ -141,7 +141,7 @@ qubes-prefs clockvm sys-net2
For added convenience, arbitrary programs can be added to the Application Menu of the DisposableVM.
In order to do that, select "Qube settings" entry in selected base AppVM, go to "Applications" tab and select desired applications as for any other qube.
In order to do that, select "Qube settings" entry in selected base app qube, go to "Applications" tab and select desired applications as for any other qube.
Note that currently only applications whose main process keeps running until you close the application (i.e. do not start a background process instead) will work. One of known examples of incompatible applications is GNOME Terminal (shown on the list as "Terminal"). Choose different terminal emulator (like XTerm) instead.
@ -255,7 +255,7 @@ Using DisposableVMs in this manner is ideal for untrusted qubes which require pe
[user@dom0 ~]$ qvm-prefs disp-sys-firewall netvm disp-sys-net
```
4. Set `disp-sys-firewall` as NetVM for other AppVMs:
4. Set `disp-sys-firewall` as NetVM for other app qubes:
```shell_session
[user@dom0 ~]$ qvm-prefs <vm_name> netvm disp-sys-firewall

8
user/advanced-topics/mount-from-other-os.md
View file

@ -17,14 +17,14 @@ These functions are manual and do not require any Qubes specific tools. All step
- LUKS encrypted disk
- LVM based VM storage
Before beginning, if attempting to access one Qubes system from another, it is recommended to pass the entire encrypted Qubes disk to an isolated AppVM.
Before beginning, if attempting to access one Qubes system from another, it is recommended to pass the entire encrypted Qubes disk to an isolated app qube.
This can be done with the command `qvm-block attach <isolated vm> dom0:<disk>` in dom0.
Decrypting the Disk
-----------------
1. Find the disk to be accessed:
1. Open a Linux terminal in either dom0 or the AppVM the disk was passed through to and enter `lsblk`, which will result in an output similar to the following.
1. Open a Linux terminal in either dom0 or the app qube the disk was passed through to and enter `lsblk`, which will result in an output similar to the following.
In this example, the currently booted Qubes system is installed on `sda` and the qubes system to be accessed is on `nvme0n1p2`.
```
@ -58,7 +58,7 @@ Decrypting the Disk
Accessing LVM Logical Volumes
-----------------------------
3. If using an AppVM or standard Linux, LVM should automatically discover the Qubes LVM configuration. In this case, continue to step 4.
3. If using an app qube or standard Linux, LVM should automatically discover the Qubes LVM configuration. In this case, continue to step 4.
1. Qubes uses the default name `qubes_dom0` for it's LVM VG.
This will conflict with the name of the VG of the currently installed system.
To read both, you will have to rename the VG.
@ -91,7 +91,7 @@ Reverting Changes
Any changes which were made to the system in the above steps will need to be reverted before the disk will properly boot.
However, LVM will not allow an VG to be renamed to a name already in use.
Thes steps must occur either in an AppVM or using recovery media.
Thes steps must occur either in an app qube or using recovery media.
1. Unmount any disks that were accessed.
2. Rename the VG back to qubes\_dom0 using the command `vgrename other_install qubes_dom0`.

2
user/advanced-topics/resize-disk-image.md
View file

@ -85,7 +85,7 @@ zpool online -e poolname ada0
#### Linux
Qubes will automatically grow the filesystem for you on all AppVMs with Qubes packages installed (which are all AppVMs installed from templates, cloned from templates etc. - if you have not created an empty HVM and installed a Linux distribution in it, without using Qubes repositories, you are almost certainly safe).
Qubes will automatically grow the filesystem for you on all app qubes with Qubes packages installed (which are all app qubes installed from templates, cloned from templates etc. - if you have not created an empty HVM and installed a Linux distribution in it, without using Qubes repositories, you are almost certainly safe).
Otherwise, you will see that there is unallocated free space at the end of your primary disk.
You can use standard linux tools like `fdisk` and `resize2fs` to make this space available.

22
user/advanced-topics/salt.md
View file

@ -243,8 +243,8 @@ optional arguments:
--skip-dom0 Skip dom0 configuration (VM creation etc)
--targets TARGETS Coma separated list of VMs to target
--templates Target all templates
--app Target all AppVMs
--all Target all non-disposable VMs (TemplateVMs and AppVMs)
--app Target all app qubes
--all Target all non-disposable VMs (TemplateVMs and app qubes)
```
To apply a state to all templates, call `qubesctl --templates state.highstate`.
@ -262,7 +262,7 @@ Beginning with Qubes 4.0 and after [QSB #45](/news/2018/12/03/qsb-45/), we imple
1. Added the `management_dispvm` VM property, which specifies the DVM
Template that should be used for management, such as Salt
configuration. TemplateBasedVMs inherit this property from their
configuration. App qubes inherit this property from their
parent TemplateVMs. If the value is not set explicitly, the default
is taken from the global `management_dispvm` property. The
VM-specific property is set with the `qvm-prefs` command, while the
@ -451,31 +451,31 @@ Whonix gateway ProxyVM
#### `qvm.personal`
Personal AppVM
Personal app qube
#### `qvm.work`
Work AppVM
Work app qube
#### `qvm.untrusted`
Untrusted AppVM
Untrusted app qube
#### `qvm.vault`
Vault AppVM with no NetVM enabled.
Vault app qube with no NetVM enabled.
#### `qvm.default-dispvm`
Default DisposableVM template - fedora-26-dvm AppVM
Default DisposableVM template - fedora-26-dvm app qube
#### `qvm.anon-whonix`
Whonix workstation AppVM.
Whonix workstation app qube.
#### `qvm.whonix-ws-dvm`
Whonix workstation AppVM for Whonix DisposableVMs.
Whonix workstation app qube for Whonix DisposableVMs.
#### `qvm.updates-via-whonix`
@ -545,7 +545,7 @@ VM type. Possible values:
- `admin` - Administration domain (`dom0`)
- `template` - Template VM
- `standalone` - Standalone VM
- `app` - Template based AppVM
- `app` - Template based app qube
### `qubes:template`

4
user/advanced-topics/secondary-storage.md
View file

@ -12,12 +12,12 @@ title: Secondary Storage
Suppose you have a fast but small primary SSD and a large but slow secondary HDD.
You want to store a subset of your AppVMs on the HDD.
You want to store a subset of your app qubes on the HDD.
## Instructions
Qubes 4.0 is more flexible than earlier versions about placing different VMs on different disks.
For example, you can keep templates on one disk and AppVMs on another, without messy symlinks.
For example, you can keep templates on one disk and app qubes on another, without messy symlinks.
These steps assume you have already created a separate [volume group](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_admin#VG_create) and [thin pool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/thinly_provisioned_volume_creation) (not thin volume) for your HDD.
See also [this example](https://www.linux.com/blog/how-full-encrypt-your-linux-system-lvm-luks) if you would like to create an encrypted LVM pool (but note you can use a single logical volume if preferred, and to use the `-T` option on `lvcreate` to specify it is thin). You can find the commands for this example applied to Qubes at the bottom of this R4.0 section.

10
user/advanced-topics/standalone-and-hvm.md
View file

@ -109,8 +109,8 @@ Several invocations of `qvm-start` command (as shown above) might be needed.
## Setting up networking for HVMs
Just like standard paravirtualized AppVMs, the HVM qubes get fixed IP addresses centrally assigned by Qubes.
Normally Qubes agent scripts (or services on Windows) running within each AppVM are responsible for setting up networking within the VM according to the configuration created by Qubes (through [keys](/doc/vm-interface/#qubesdb) exposed by dom0 to the VM).
Just like standard paravirtualized app qubes, the HVM qubes get fixed IP addresses centrally assigned by Qubes.
Normally Qubes agent scripts (or services on Windows) running within each app qube are responsible for setting up networking within the VM according to the configuration created by Qubes (through [keys](/doc/vm-interface/#qubesdb) exposed by dom0 to the VM).
Such centrally managed networking infrastructure allows for [advanced networking configuration](https://blog.invisiblethings.org/2011/09/28/playing-with-qubes-networking-for-fun.html).
A generic HVM domain such as a standard Windows or Ubuntu installation, however, has no Qubes agent scripts running inside it initially and thus requires manual configuration of networking so that it matches the values assigned by Qubes for this qube.
@ -149,7 +149,7 @@ Please see [this page](/doc/windows-appvms/) for specific advice on installing a
## Cloning HVMs
Just like normal AppVMs, the HVM domains can also be cloned either using the command-line `qvm-clone` or via the Qube Manager's 'Clone VM' option in the right-click menu.
Just like normal app qubes, the HVM domains can also be cloned either using the command-line `qvm-clone` or via the Qube Manager's 'Clone VM' option in the right-click menu.
The cloned VM will get identical root and private images and will essentially be identical to the original VM except that it will get a different MAC address for the networking interface:
@ -249,7 +249,7 @@ timezone : localtime
## Assigning PCI devices to HVMs
HVM domains (including Windows VMs) can be [assigned PCI devices](/doc/assigning-devices/) just like normal AppVMs.
HVM domains (including Windows VMs) can be [assigned PCI devices](/doc/assigning-devices/) just like normal app qubes.
E.g. one can assign one of the USB controllers to the Windows VM and should be able to use various devices that require Windows software, such as phones, electronic devices that are configured via FTDI, etc.
One problem at the moment however, is that after the whole system gets suspended into S3 sleep and subsequently resumed, some attached devices may stop working and should be restarted within the VM.
@ -268,7 +268,7 @@ About 60 GB of disk space is required for conversion.
Use an external harddrive if needed.
The final root.img size is 40 GB.
In Debian AppVM, install `qemu-utils` and `unzip`:
In Debian app qube, install `qemu-utils` and `unzip`:
~~~
sudo apt install qemu-utils unzip

2
user/advanced-topics/volume-backup-revert.md
View file

@ -19,7 +19,7 @@ shutdown. (Note that this is a different, lower level activity than the
In Qubes, when you create a new VM, it's volumes are stored in one of the
system's [Storage Pools](/doc/storage-pools/). On pool creation, a
revisions_to_keep default value is set for the entire pool. (For a pool creation
example, see [Storing AppVMs on Secondary Drives](/doc/secondary-storage/).)
example, see [Storing app qubes on Secondary Drives](/doc/secondary-storage/).)
Thereafter, each volume associated with a VM that is stored in this pool
inherits the pool default revisions_to_keep.