Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2025-12-10 21:49:07 -05:00
Code Issues Projects Releases Packages Wiki Activity

Mass replace "TemplateVM" with "template"

Browse source 
QubesOS/qubes-issues#1015
This commit is contained in:
Andrew David Wong 2021-06-18 02:16:40 -07:00
parent c07ee61ed8
commit 63498a6c17
No known key found for this signature in database
GPG key ID: 8CE137352A019A17
41 changed files with 187 additions and 187 deletions
Download patch file Download diff file Expand all files Collapse all files

2
user/how-to-guides/how-to-back-up-restore-and-migrate.md
View file

@ -103,7 +103,7 @@ This brings up the **Qubes Restore VMs** window.
Once you've located the backup file, double-click it or select it and hit **OK**.
3. There are three options you may select when restoring from a backup:
1. **ignore missing templates and net VMs**: If any of the VMs in your backup depended upon a NetVM or TemplateVM that is not present in (i.e., "missing from") the current system, checking this box will ignore the fact that they are missing and restore the VMs anyway and set them to use the default NetVM and system default template.
1. **ignore missing templates and net VMs**: If any of the VMs in your backup depended upon a NetVM or template that is not present in (i.e., "missing from") the current system, checking this box will ignore the fact that they are missing and restore the VMs anyway and set them to use the default NetVM and system default template.
2. **ignore username mismatch**: This option applies only to the restoration of dom0's home directory.
If your backup was created on a Qubes system which had a different dom0 username than the dom0 username of the current system, then checking this box will ignore the mismatch between the two usernames and proceed to restore the home directory anyway.
3. **Verify backup integrity, do not restore the data**: This will scan the backup file for corrupted data.

8
user/how-to-guides/how-to-install-software.md
View file

@ -156,15 +156,15 @@ This is like the simple revert, except:
### Temporarily allowing networking for software installation
Some third-party applications cannot be installed using the standard repositories and need to be manually downloaded and installed.
When the installation requires internet connection to access third-party repositories, it will naturally fail when run in a Template VM because the default firewall rules for templates only allow connections from package managers.
When the installation requires internet connection to access third-party repositories, it will naturally fail when run in a template because the default firewall rules for templates only allow connections from package managers.
So it is necessary to modify firewall rules to allow less restrictive internet access for the time of the installation, if one really wants to install those applications into a template.
As soon as software installation is completed, firewall rules should be returned back to the default state.
The user should decide by themselves whether such third-party applications should be equally trusted as the ones that come from the standard Fedora signed repositories and whether their installation will not compromise the default Template VM, and potentially consider installing them into a separate template or a standalone VM (in which case the problem of limited networking access doesn't apply by default), as described above.
The user should decide by themselves whether such third-party applications should be equally trusted as the ones that come from the standard Fedora signed repositories and whether their installation will not compromise the default template, and potentially consider installing them into a separate template or a standalone VM (in which case the problem of limited networking access doesn't apply by default), as described above.
### Updates proxy
Updates proxy is a service which allows access only from package managers.
This is meant to mitigate user errors (like using browser in the template VM), rather than some real isolation.
This is meant to mitigate user errors (like using browser in the template), rather than some real isolation.
It is done with http proxy (tinyproxy) instead of simple firewall rules because it is hard to list all the repository mirrors (and keep that list up to date).
The proxy is used only to filter the traffic, not to cache anything.
@ -196,7 +196,7 @@ Example policy file in R4.0 (with Whonix installed, but not set as default Updat
@tag:whonix-updatevm @anyvm deny
# other templates use sys-net
@type:TemplateVM @default allow,target=sys-net
@type:template @default allow,target=sys-net
@anyvm @anyvm deny
```

10
user/how-to-guides/how-to-update.md
View file

@ -33,7 +33,7 @@ It is important to keep your Qubes OS system up-to-date to ensure you have the l
Fully updating your Qubes OS system means updating:
- [Dom0](/doc/how-to-install-software-in-dom0/)
- [TemplateVMs](/doc/how-to-install-software/#updating-software-in-templatevms)
- [templates](/doc/how-to-install-software/#updating-software-in-templates)
- [StandaloneVMs](/doc/how-to-install-software/#standalonevms) (if you have any)
You can accomplish this using the **Qubes Update** tool.
@ -56,18 +56,18 @@ Even if no updates have been detected, you can use this tool to check for update
The above covers updating *within* a given operating system release.
Eventually, however, most operating system releases will reach [end-of-life (EOL)](https://fedoraproject.org/wiki/End_of_life), after which point they will no longer be supported.
This applies to [Qubes OS itself](/doc/supported-versions/#qubes-os) as well as operating systems used for TemplateVMs and StandaloneVMs, such as [Fedora](/doc/templates/fedora/) and [Debian](/doc/templates/debian/).
This applies to [Qubes OS itself](/doc/supported-versions/#qubes-os) as well as operating systems used for templates and StandaloneVMs, such as [Fedora](/doc/templates/fedora/) and [Debian](/doc/templates/debian/).
It is very important to use only supported releases, since generally only supported releases receive security updates.
This means that you must periodically upgrade to a newer release before your current release reaches EOL.
In the case of Qubes OS itself, we will always [announce](/news/categories/#releases) when a given Qubes OS release is approaching and has reached EOL, and we will provide [instructions for upgrading to the next stable supported Qubes OS release](/doc/upgrade/).
Again, you can always see the current support status for all Qubes OS releases [here](/doc/supported-versions/#qubes-os).
Periodic upgrades are also important for TemplateVMs and StandaloneVMs.
For example, you might be using a [Fedora TemplateVM](/doc/templates/fedora/).
Periodic upgrades are also important for templates and StandaloneVMs.
For example, you might be using a [Fedora Template](/doc/templates/fedora/).
The [Fedora Project](https://getfedora.org/) is independent of the Qubes OS Project.
They set their own [schedule](https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule) for when each Fedora release reaches EOL.
You can always find out when an operating system reaches EOL from the upstream project that maintains it, but we also make EOL [announcements](/news/categories/#announcements) and publish guides for official TemplateVM operating systems as a convenience to Qubes users.
You can always find out when an operating system reaches EOL from the upstream project that maintains it, but we also make EOL [announcements](/news/categories/#announcements) and publish guides for official template operating systems as a convenience to Qubes users.
When this happens, you should make sure to follow the guide to upgrade to a supported version of that operating system (see the [Fedora upgrade guides](/doc/templates/fedora/#upgrading) and the [Debian upgrade guides](/doc/templates/debian/#upgrading)).
The one exception to all this is the specific release used for dom0 (not to be confused with Qubes OS as a whole), which [doesn't have to be upgraded](/doc/supported-versions/#note-on-dom0-and-eol).

6
user/how-to-guides/how-to-use-disposables.md
View file

@ -31,7 +31,7 @@ This diagram provides a general example of how disposables can be used to safely
If a [disposable template](/doc/glossary/#disposable-template) becomes compromised, then any disposable based on that disposable template could be compromised.
In particular, the *default* disposable template is important because it is used by the "Open in disposable" feature.
This means that it will have access to everything that you open with this feature.
For this reason, it is strongly recommended that you base the default disposable template on a trusted TemplateVM.
For this reason, it is strongly recommended that you base the default disposable template on a trusted template.
### Disposables and Local Forensics
@ -42,10 +42,10 @@ When it is essential to avoid leaving any trace, consider using [Tails](https://
## Disposables and Networking
Similarly to how app qubes are based on their underlying [TemplateVM](/doc/glossary/#templatevm), disposables are based on their underlying [disposable template](/doc/glossary/#disposable-template).
Similarly to how app qubes are based on their underlying [template](/doc/glossary/#template), disposables are based on their underlying [disposable template](/doc/glossary/#disposable-template).
R4.0 introduces the concept of multiple disposable templates, whereas R3.2 was limited to only one.
On a fresh installation of Qubes, the default disposable template is called `fedora-XX-dvm` (where `XX` is the Fedora version of the default TemplateVM).
On a fresh installation of Qubes, the default disposable template is called `fedora-XX-dvm` (where `XX` is the Fedora version of the default template).
If you have included the Whonix option in your install, there will also be a `whonix-ws-dvm` disposable template available for your use.
You can set any app qube to have the ability to act as a disposable template with: