3. Install software as normally instructed inside that operating system (e.g. `sudo dnf install <PACKAGE_NAME>` on Fedora, `sudo apt install <PACKAGE_NAME>` on Debian).
In order to protect you from performing risky activites in templates, they do not have normal network access.
Instead, templates use an [updates proxy](#updates-proxy) that allows you to install and update software without giving the template direct network access.
## Advanced
The following sections cover advanced topics pertaining to installing and updating software in domUs.
-`qubes-vm-*-current-testing` -- testing packages that will eventually land in the stable (`current`) repository
-`qubes-vm-*-security-testing` -- a subset of `qubes-vm-*-current-testing` that contains packages that qualify as security fixes
-`qubes-vm-*-unstable` -- packages that are not intended to land in the stable (`qubes-vm-*-current`) repository; mostly experimental debugging packages
When you create a [standalone](/doc/standalone-and-hvm/) from a template, the standalone is a complete clone of the template, including the entire filesystem.
After the moment of creation, the standalone is completely independent from the template.
If you would like to enable the [RPM Fusion](https://rpmfusion.org/) repositories, open a Terminal of the template and type the following commands, depending on which RPM Fusion repositories you wish to enable (see [RPM Fusion](https://rpmfusion.org/) for details):
This will permanently enable the RPM Fusion repos.
If you install software from here, it's important to keep these repos enabled so that you can receiving future updates.
If you only enable these repos temporarily to install a package the Qubes update mechanism may persistently notify you that updates are available, since it cannot download them.
**Important:** This command will roll back any changes made *during the last time the template was run, but **not** before.*
This means that if you have already restarted the template, using this command is unlikely to help, and you'll likely want to reinstall it from the repository instead.
However, if you don't have anything important in the private volume (likely for a template), then you can work around this by just resetting the private volume with `qvm-volume import --no-resize <template>:private /dev/null`.
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, 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.
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.
The proxy is running in selected VMs (by default all the NetVMs (1)) and intercepts traffic directed to 10.137.255.254:8082.
Thanks to such configuration all the VMs can use the same proxy address, and if there is a proxy on network path, it will handle the traffic (of course when firewall rules allow that).
If the VM is configured to have access to the updates proxy (2), the startup scripts will automatically configure dnf to really use the proxy (3).
Also access to updates proxy is independent of any other firewall settings (VM will have access to updates proxy, even if policy is set to block all the traffic).
1.`qubes-updates-proxy` (and its deprecated name: `qubes-yum-proxy`) - a service providing a proxy for templates - by default enabled in NetVMs (especially: sys-net)
2.`updates-proxy-setup` (and its deprecated name: `yum-proxy-setup`) - use a proxy provided by another VM (instead of downloading updates directly), enabled by default in all templates
# 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
Snap packages do not use the normal update channels for Debian and Fedora (apt and dnf) and are often installed as the user rather than as root. To support these in an app qube you need to take the following steps:
The refresh will take a few minutes; after it's complete the Snap app will appear in the app qube's list of available applications. At this point the snap will be persistent within the app qube and will receive updates when the app qube is running.
If you want a desktop app to start automatically every time a qube starts you can create a link to it in the `~/.config/autostart` directory of the **app qube**. This might be useful for Qubes that you set to automatically start on boot or for Qubes that have a set of apps you typically use all day, such as a chat app.
2. List the names of the available desktop shortcuts by running the command `ls /usr/share/applications` and find the exact name of the shortcut to the app you want to autostart:
4. Make a link to the desktop app file you'd like to start in the autostart directory. For example, the command below will link the Thunderbird app into the autostart directory:
Note that the app will autostart only when the app qube starts. If you would like the app qube to autostart, select the "Start qube automatically on boot" checkbox in the app qube's Qube Settings.
