mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-05-02 06:46:11 -04:00
Merge branch 'master' into patch-15
This commit is contained in:
awokd
GitHub
commit
1a19e8d84b
118 changed files with 1081 additions and 522 deletions
|
|
@ -88,14 +88,14 @@ Some USB devices are not compatible with the USB pass-through method Qubes emplo
|
|||
In situations like this, you can still often get the USB device to work by passing through the entire USB controller to a qube.
|
||||
However, with this approach one cannot assign single USB devices, only the whole USB controller with whatever USB devices are connected to it.
|
||||
More information on using and managing USB devices with qubes is available on the [USB] page.
|
||||
If you want assign a certain USB device to a VM (by attaching the whole USB controller), you need to figure out which PCI device is the right controller.
|
||||
If you want assign a certain USB device to a VM by attaching the whole USB controller, you need to figure out which PCI device is the right controller.
|
||||
First, check to which USB bus the device is connected (note that these steps need to be run from a terminal inside `dom0`):
|
||||
|
||||
~~~
|
||||
lsusb
|
||||
~~~
|
||||
|
||||
For example, I want assign a broadband modem to the netvm.
|
||||
For example, I want assign a broadband modem to the NetVM.
|
||||
In the output of `lsusb` it can be listed as something like this.
|
||||
(In this case, the device isn't fully identified):
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ Bus 003 Device 003: ID 413c:818d Dell Computer Corp.
|
|||
|
||||
The device is connected to USB bus \#3.
|
||||
Then check which other devices are connected to the same bus, since *all* of them will be assigned to the same VM.
|
||||
Now is the time to find right USB controller:
|
||||
Now is the time to find the right USB controller:
|
||||
|
||||
~~~
|
||||
readlink /sys/bus/usb/devices/usb3
|
||||
|
|
|
|||
|
|
@ -40,8 +40,8 @@ problematic device drivers.
|
|||
|
||||
Note that scripts need to be executable (chmod +x) to be used.
|
||||
|
||||
Also take a look at [bind-dirs][/doc/bind-dirs] for instruction how to easily
|
||||
modify arbitrary system file in AppVM and have those changes persistent.
|
||||
Also take a look at [bind-dirs](/doc/bind-dirs) for instructions on
|
||||
how to easily modify arbitrary system files in AppVM and have those changes persist.
|
||||
|
||||
GUI and audio configuration in dom0
|
||||
===================================
|
||||
|
|
|
|||
|
|
@ -8,31 +8,82 @@ redirect_from:
|
|||
- /wiki/DiskTRIM/
|
||||
---
|
||||
|
||||
VMs have already TRIM enabled by default, but dom0 doesn't. There are some security implications (read for example [this article](https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html)), but IMO not very serious.
|
||||
Disk Trim
|
||||
----------
|
||||
|
||||
To enable TRIM in dom0 you need:
|
||||
Disk trimming is the procedure by which the operating system informs the underlying storage device of which storage blocks are no longer in use.
|
||||
It does this by issuing an `ATA_TRIM` command for the block. This is also known as a `discard`.
|
||||
In this way, the storage device can perform garbage collection of the unused blocks and internally prepare them for reuse. SSDs in general benefit from this, while HDDs do not.
|
||||
|
||||
1. Get your LUKS device UUID:
|
||||
In a Linux system running on bare metal, this is relatively straight-forward.
|
||||
When instructed by the operating system, discards are issued by the file-system driver directly to the storage driver and then to the SSD.
|
||||
|
||||
In Qubes, this gets more complex due to virtualization, LUKS, and LVM (and thin pools on R4.0 and up).
|
||||
If you run `fstrim --all` inside a TemplateVM, in a worst case the `discard` can follow a path like:
|
||||
|
||||
OS -> File-system Driver -> Virtual Storage Driver -> Backend Storage Driver -> LVM Storage Driver -> LUKS Driver -> Physical Storage Driver -> Physical Storage Device
|
||||
|
||||
If discards are not supported at any one of those layers, it will not make it to the underlying physical device.
|
||||
|
||||
There are some security implications to permitting TRIM (read for example [this article](https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html)), but in most cases not exploitable.
|
||||
|
||||
|
||||
Configuration
|
||||
----------
|
||||
|
||||
In all versions of Qubes, you may want to set up a periodic job in `dom0` to trim the disk.
|
||||
|
||||
This can be done from a terminal as root, by creating a `trim` file in `/etc/cron.daily` (or `/etc/cron.weekly`).
|
||||
Add the following contents:
|
||||
|
||||
```
|
||||
#!/bin/bash
|
||||
/sbin/fstrim --all
|
||||
```
|
||||
|
||||
And mark it as executable with `chmod 755 /etc/cron.daily/trim`.
|
||||
|
||||
**Note** Although discards can be issued on every delete inside `dom0` by adding the `discard` mount option to `/etc/fstab`, this option can hurt performance so the above procedure is recommended instead.
|
||||
However, inside App and Template qubes, the `discard` mount option is on by default to notify the LVM thin pool driver (R4.0) or sparse file driver (R3.2) that the space is no longer needed and can be zeroed and re-used.
|
||||
|
||||
If you are using Qubes with LVM, you may also want to set `issue_discards = 1` in `/etc/lvm/lvm.conf`.
|
||||
Setting this option will permit LVM to issue discards to the SSD when logical volumes are shrunk or deleted.
|
||||
In R4.x, LVM Logical volumes are frequently deleted (every time a disposable VM is shut down, for example) so setting `issue_discards = 1` is recommended if using an SSD.
|
||||
However, this is relatively rare in R3.x.
|
||||
|
||||
|
||||
LUKS
|
||||
----------
|
||||
|
||||
If you have enabled LUKS in dom0, discards will not get passed down to the storage device.
|
||||
|
||||
To enable TRIM support in dom0 with LUKS you need to:
|
||||
|
||||
1. Get your LUKS device UUID:
|
||||
|
||||
~~~
|
||||
ls /dev/mapper/luks-*
|
||||
~~~
|
||||
|
||||
2. Add entry to `/etc/crypttab` (replace luks-\<UUID\> with the device name and the \<UUID\> with UUID alone):
|
||||
2. Add entry to `/etc/crypttab` (replace luks-\<UUID\> with the device name and the \<UUID\> with UUID alone):
|
||||
|
||||
~~~
|
||||
luks-<UUID> UUID=<UUID> none allow-discards
|
||||
luks-<UUID> UUID=<UUID> none discard
|
||||
~~~
|
||||
|
||||
3. Add `rd.luks.allow-discards=1` to kernel cmdline (`/etc/default/grub`, GRUB\_CMDLINE\_LINUX line)
|
||||
4. Rebuild grub config (`grub2-mkconfig -o /boot/grub2/grub.cfg`)
|
||||
5. Rebuild initrd **in hostonly mode**:
|
||||
3. Add `rd.luks.options=discard` to kernel cmdline (follow either GRUB2 or EFI, not both):
|
||||
* GRUB2: `/etc/default/grub`, `GRUB_CMDLINE_LINUX` line and
|
||||
Rebuild grub config (`grub2-mkconfig -o /boot/grub2/grub.cfg`)
|
||||
* EFI: `/boot/efi/EFI/qubes/xen.cfg`, `kernel=` line(s)
|
||||
|
||||
4. Rebuild initrd **in hostonly mode**:
|
||||
|
||||
~~~
|
||||
dracut -H -f
|
||||
~~~
|
||||
|
||||
6. Add "discard" option to `/etc/fstab` for root device
|
||||
7. Reboot the system, verify that allow-discards is really enabled (`dmsetup table`)
|
||||
5. Reboot the system.
|
||||
|
||||
6. To verify if discards are enabled you may use `dmsetup table` (confirm the line for your device mentions "discards") or just run `fstrim -av` (you should see a `/` followed by the number of bytes trimmed).
|
||||
|
||||
|
||||
There is a [bug affecting allow-discards option](https://bugzilla.redhat.com/show_bug.cgi?id=890533), once it will be fixed, first two steps will be no longer needed.
|
||||
|
|
|
|||
|
|
@ -14,19 +14,24 @@ Using External Audio Devices
|
|||
Why you want to use external audio devices
|
||||
------------------------------------------
|
||||
|
||||
Qubes audio virtualization protocol does not implement latency reporting for security reasons, keeping the protocol as simple as possible. Also, in a compromise between low latency and low CPU usage, latency may be around 200 ms. So applications demanding higher audio quality (even Skype) need a better environment. But Qubes flexibility fully allows that using external audio devices. These are mostly USB audio cards, but firewire devices also might be used.
|
||||
Qubes audio virtualization protocol does not implement latency reporting for security reasons, keeping the protocol as simple as possible.
|
||||
Also, in a compromise between low latency and low CPU usage, latency may be around 200 ms.
|
||||
So applications demanding higher audio quality (even Skype) need a better environment.
|
||||
But Qubes flexibility fully allows that using external audio devices.
|
||||
These are mostly USB audio cards, but firewire devices also might be used.
|
||||
|
||||
Implementing external audio devices
|
||||
-----------------------------------
|
||||
|
||||
First you need to identify an user VM dedicated to audio and [assign a device](/doc/AssigningDevices) to it. In the most common case the assigned device is the USB controller to which your USB audio card will be connected.
|
||||
First you need to identify an user VM dedicated to audio and [assign a device](/doc/AssigningDevices) to it.
|
||||
In the most common case the assigned device is the USB controller to which your USB audio card will be connected.
|
||||
|
||||
### Fedora VMs
|
||||
|
||||
In a terminal of the template from which you user VM depends, install pavucontrol with:
|
||||
|
||||
~~~
|
||||
sudo yum install pavucontrol
|
||||
sudo dnf install pavucontrol
|
||||
~~~
|
||||
|
||||
Close the template and start or restart your user VM, insert your external audio device, open a terminal and prepare pulseaudio to use it with:
|
||||
|
|
@ -38,9 +43,10 @@ pactl load-module module-udev-detect
|
|||
|
||||
Start the audio application that is going to use the external audio device.
|
||||
|
||||
Launch pavucontrol, for example using "run command in VM" of Qubes Manager and select you external audio card in pavucontrol. You need to do that only the first time you use a new external audio device, then pulse audio will remember you selection.
|
||||
Launch pavucontrol, for example using "run command in VM" of Qubes Manager and select your external audio card in pavucontrol.
|
||||
You need to do that only the first time you use a new external audio device, then pulse audio will remember your selection.
|
||||
|
||||
If you detach your external audio device, then want to insert it again, or change it with another one, you need to repeat the previous commands in terminal, adding an other line at the beginning:
|
||||
If you detach your external audio device, then want to insert it again (or want to change it with another one), you need to repeat the previous commands in terminal adding another line at the beginning:
|
||||
|
||||
~~~
|
||||
pactl unload-module module-udev-detect
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Fetchmail is standalone MRA (Mail Retrieval Agent) aka "IMAP/POP3 client". Its s
|
|||
Installation
|
||||
------------
|
||||
|
||||
`yum install fetchmail`
|
||||
`dnf install fetchmail`
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
|
|
|||
|
|
@ -31,10 +31,10 @@ prevents websites that use DNS-based load balancers from working
|
|||
unless the user reloads the firewall rules (which re-resolve the DNS
|
||||
names) whenever the balancer transfer her session to another IP. Third
|
||||
the initial setup of the rules is complicated as the firewall drops
|
||||
the connection silently. As a workaround on can use browser's network
|
||||
the connection silently. As a workaround one can use browser's network
|
||||
console to see what is blocked, but this is time-consuming and one can
|
||||
trivially miss some important cases like including in the firewall
|
||||
white list sites for OCSP SSL certificate verification.
|
||||
white-list sites for OCSP SSL certificate verification.
|
||||
|
||||
These drawbacks can be mitigated if one replaces iptable-based rules
|
||||
with a filtering HTTP proxy. The following describes how to setup
|
||||
|
|
@ -94,7 +94,7 @@ Setup
|
|||
name.ip-address-of-app-vm
|
||||
|
||||
The name part before the dot can be arbitrary. For convenience one can
|
||||
use AppVm name here, but this is not required. It is important to get
|
||||
use AppVM name here, but this is not required. It is important to get
|
||||
ip address part right as this is what the control script uses to
|
||||
determine for which AppVM to apply the proxy rules. One can check the
|
||||
IP address of AppVM in Qubes VM manager in the VM settings dialog, see
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ updatevm : sys-firewall
|
|||
Installing different kernel using Qubes kernel package
|
||||
----------------------------------
|
||||
|
||||
VM kernels are packages by Qubes team in `kernel-qubes-vm` packages. Generally system will keep the 3 newest available versions. You can list them with the `rpm` command:
|
||||
VM kernels are packages by Qubes team in `kernel-qubes-vm` packages. Generally the system will keep the 3 newest available versions. You can list them with the `rpm` command:
|
||||
|
||||
~~~
|
||||
[user@dom0 ~]$ rpm -qa 'kernel-qubes-vm*'
|
||||
|
|
@ -58,7 +58,7 @@ kernel-qubes-vm-3.18.16-3.pvops.qubes.x86_64
|
|||
kernel-qubes-vm-3.18.17-4.pvops.qubes.x86_64
|
||||
~~~
|
||||
|
||||
If you want more recent version, you can check `qubes-dom0-unstable` repository. As the name suggest, keep in
|
||||
If you want a more recent version, you can check `qubes-dom0-unstable` repository. As the name suggests, keep in
|
||||
mind that those packages may be less stable than the default ones.
|
||||
|
||||
Checking available versions in `qubes-dom0-unstable` repository:
|
||||
|
|
@ -144,7 +144,7 @@ possible to use VM kernel, which is not packaged by Qubes team. This includes:
|
|||
|
||||
To prepare such VM kernel, you need to install `qubes-kernel-vm-support`
|
||||
package in dom0 and also have matching kernel headers installed (`kernel-devel`
|
||||
package in case of Fedora kernel package). You can install required stuff using `qubes-dom0-update`:
|
||||
package in the case of Fedora kernel package). You can install required stuff using `qubes-dom0-update`:
|
||||
|
||||
~~~
|
||||
[user@dom0 ~]$ sudo qubes-dom0-update qubes-kernel-vm-support kernel-devel
|
||||
|
|
@ -212,7 +212,7 @@ This is possible thanks to PV GRUB2 - GRUB2 running in the VM. To make it happen
|
|||
|
||||
1. Install PV GRUB2 in dom0 - package is named `grub2-xen`.
|
||||
2. Install kernel in the VM. As with all VM software installation - this needs to be done in TemplateVM (of StandaloneVM if you are using one).
|
||||
3. Set VM kernel to `pvgrub2` value. You can use `pvgrub2` in selected VMs, not necessary all of them, even when it's template has kernel installed. You can still use dom0-provided kernel for selected VMs.
|
||||
3. Set VM kernel to `pvgrub2` value. You can use `pvgrub2` in selected VMs, not necessary all of them, even when its template has kernel installed. You can still use dom0-provided kernel for selected VMs.
|
||||
|
||||
**WARNING: When using kernel from within VM, `kernelopts` parameter is ignored.**
|
||||
|
||||
|
|
@ -227,10 +227,10 @@ sudo qubes-dom0-update grub2-xen
|
|||
### Installing kernel in Fedora VM
|
||||
|
||||
In Fedora based VM, you need to install `qubes-kernel-vm-support` package. This
|
||||
package include required additional kernel module and initramfs addition
|
||||
package includes required additional kernel module and initramfs addition
|
||||
required to start Qubes VM (for details see
|
||||
[template implementation](/doc/template-implementation/)). Additionally you
|
||||
need some GRUB tools to create it's configuration. Note: you don't need actual
|
||||
need some GRUB tools to create its configuration. Note: you don't need actual
|
||||
grub bootloader as it is provided by dom0. But having one also shouldn't harm.
|
||||
|
||||
~~~
|
||||
|
|
@ -240,7 +240,7 @@ sudo yum install qubes-kernel-vm-support grub2-tools
|
|||
Then install whatever kernel you want. If you are using distribution kernel
|
||||
package (`kernel` package), initramfs and kernel module should be handled
|
||||
automatically, but you need to ensure you have `kernel-devel` package for the
|
||||
same kernel version installed. If you are using manually build kernel, you need
|
||||
same kernel version installed. If you are using a manually built kernel, you need
|
||||
to handle this on your own. Take a look at `dkms` and `dracut` documentation.
|
||||
Especially `dkms autoinstall` command may be useful.
|
||||
|
||||
|
|
@ -265,10 +265,10 @@ start kernel configured within VM.
|
|||
### Installing kernel in Debian VM
|
||||
|
||||
In Debian based VM, you need to install `qubes-kernel-vm-support` package. This
|
||||
package include required additional kernel module and initramfs addition
|
||||
package includes required additional kernel module and initramfs addition
|
||||
required to start Qubes VM (for details see
|
||||
[template implementation](/doc/template-implementation/)). Additionally you
|
||||
need some GRUB tools to create it's configuration. Note: you don't need actual
|
||||
need some GRUB tools to create its configuration. Note: you don't need actual
|
||||
grub bootloader as it is provided by dom0. But having one also shouldn't harm.
|
||||
|
||||
~~~
|
||||
|
|
@ -326,9 +326,9 @@ When starting the VM you can safely ignore any warnings about a missing module '
|
|||
|
||||
### Troubleshooting
|
||||
|
||||
In case of problems, you can access VM console (using `sudo xl console VMNAME` in dom0) to access
|
||||
GRUB menu. You need to call it just after starting VM (until `GRUB_TIMEOUT`
|
||||
expires) - for example in separate dom0 terminal window.
|
||||
In the event of a problem, you can access the VM console (using `sudo xl console VMNAME` in dom0) to access
|
||||
the GRUB menu. You need to call it just after starting VM (until `GRUB_TIMEOUT`
|
||||
expires) - for example in a separate dom0 terminal window.
|
||||
|
||||
In any case you can later access VM logs (especially VM console log (`guest-VMNAME.log`).
|
||||
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ If you install Qubes without making any backups beforehand, don't worry.
|
|||
If you didn't overwrite the original partitions, then it is usually
|
||||
possible to recover your old systems relatively easily, as described above.
|
||||
|
||||
If you decided to use a shared /boot and *dont* have backups of your previous
|
||||
If you decided to use a shared /boot and *don't* have backups of your previous
|
||||
grub config, it is quite easy to fix this.
|
||||
This example may help.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,12 +42,12 @@ First, retrieve the attachment of this Wifi article in dom0. Then apply the thre
|
|||
|
||||
Finally restart the qubes manager GUI.
|
||||
|
||||
A new option is now available in the AppVM Settings to enable set the NetVM in bridge mode. For a bridged AppVM, you should the select a netvm instead of a firewall vm, enabled the Bridge option and restart your AppVM.
|
||||
An option is available in the AppVM Settings to enable setting the NetVM in bridge mode. For a bridged AppVM, you should then select a NetVM instead of a FirewallVM/ ProxyVM, enable the Bridge option, and restart your AppVM.
|
||||
|
||||
NetVM patch (Qubes R2B2)
|
||||
------------------------
|
||||
|
||||
You need to modify manually the NetVM iptable script inside the NetVM. The reason is that by default the NetVM only accept traffic coming from network interfaces called vif\* (in our case, we will use an additional interface called bridge0. The second reason is that all trafic is NATed by default. In our case, we want to forward traffic from the bridge interface without modifying it, while NATing traffic coming from vif\* interfaces.
|
||||
You need to modify manually the NetVM iptable script inside the NetVM. The reason is that by default the NetVM only accepts traffic coming from network interfaces called vif\* (in our case, we will use an additional interface called bridge0. The second reason is that all trafic is NATed by default. In our case, we want to forward traffic from the bridge interface without modifying it, while NATing traffic coming from vif\* interfaces.
|
||||
|
||||
Modify manually the Template you use for your NetVM (not the NetVM itself). This is by default fedora-x86\_64. Edit the file /etc/sysconfig/iptables. You need to modify two parts of the file.
|
||||
|
||||
|
|
@ -95,7 +95,7 @@ This requires:
|
|||
|
||||
Note: A wireless interface cannot be bridged.
|
||||
|
||||
The bridge edition GUI is somehow buggy as it does not remember all the parameter you setup. You can fix it by editing manually the files in /etc/NetworkManager/system-connections/. Here is one example for these files:
|
||||
The bridge edition GUI is somewhat buggy as it does not remember all the parameters you set up. You can fix it by editing manually the files in /etc/NetworkManager/system-connections/. Here is one example for these files:
|
||||
|
||||
- Bridge-DHCP
|
||||
|
||||
|
|
@ -137,7 +137,7 @@ Note: Do not forget to put stp=false if you bridge only eth0 because sending BPD
|
|||
slave-type=bridge
|
||||
~~~
|
||||
|
||||
If you do not manager to start your bridge, you can start it manually from a NetVM terminal:
|
||||
If you do not manage to start your bridge, you can start it manually from a NetVM terminal:
|
||||
|
||||
~~~
|
||||
$ nmcli con up id bridge0-eth0
|
||||
|
|
|
|||
|
|
@ -14,27 +14,42 @@ Configuring a network printer for Qubes AppVMs
|
|||
Where to configure printers and install drivers?
|
||||
------------------------------------------------
|
||||
|
||||
One would normally want to configure a printer in a template VM, rather than in particular AppVMs. This is because all the global settings made to AppVMs (those stored in its /etc, as well as binaries installed in /usr) would be discarded upon AppVM shutdown. When printer is added and configured in a template VM, then all the AppVMs based on this template should automatically be able to use it (without the need for the template VM to be running, of course).
|
||||
One would normally want to configure a printer in a template VM, rather than in particular AppVMs.
|
||||
This is because all the global settings made to AppVMs (those stored in its /etc, as well as binaries installed in /usr) would be discarded upon AppVM shutdown.
|
||||
When printer is added and configured in a template VM, then all the AppVMs based on this template should automatically be able to use it (without the need for the template VM to be running, of course).
|
||||
|
||||
Alternatively one can add a printer in a standalone VM, but this would limit the printer usage to this particular VM.
|
||||
|
||||
Security considerations for network printers and drivers
|
||||
--------------------------------------------------------
|
||||
|
||||
Some printers require third-party drivers, typically downloadable from the vendor's website. Such drivers are typically distributed in a form of ready to install RPM packages. However, they are often unsigned, and additionally the downloads are available via HTTP connections only. As a result, installation of such third-party RPMs in a default template VM exposes a risk of compromise of this template VM, which, in turn, leads automatically to compromise of all the AppVMs based on the template. (Again, it's not buggy or malicious drivers that we fear here, but rather malicious installation scripts for those drivers).
|
||||
Some printers require third-party drivers, typically downloadable from the vendor's website.
|
||||
Such drivers are typically distributed in a form of ready to install RPM packages.
|
||||
However, they are often unsigned, and additionally the downloads are available via HTTP connections only.
|
||||
As a result, installation of such third-party RPMs in a default template VM exposes a risk of compromise of this template VM, which, in turn, leads automatically to compromise of all the AppVMs based on the template.
|
||||
(Again, it's not buggy or malicious drivers that we fear here, but rather malicious installation scripts for those drivers).
|
||||
|
||||
In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the third-party, unverified drivers there. Such template might then be made the default template for [Disposable VM creation](/doc/dispvm/), which should allow one to print any document by right-clicking on it, choosing "Open in Disposable VM" and print from there. This would allow to print documents from more trusted AppVMs (based on a trusted default template, that is not poisoned by third-party printer drivers).
|
||||
In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the third-party, unverified drivers there.
|
||||
Such template might then be made a DVM template for [Disposable VM creation](/doc/dispvm/), which should allow one to print any document by right-clicking on it, choosing "Open in Disposable VM" and print from there.
|
||||
This would allow to print documents from more trusted AppVMs (based on a trusted default template that is not poisoned by third-party printer drivers).
|
||||
|
||||
However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols. This means, that an attacker who is able to sniff the local network, or who is controlling the (normally untrusted) Qubes NetVM, will likely to be able to see the documents being printed. This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.
|
||||
However, one should be aware that most (all?) network printing protocols are insecure, unencrypted protocols.
|
||||
This means, that an attacker who is able to sniff the local network, or who is controlling the (normally untrusted) Qubes NetVM, will likely to be able to see the documents being printed.
|
||||
This is a limitation of today's printers and printing protocols, something that cannot be solved by Qubes or any other OS.
|
||||
|
||||
Additionally, the printer drivers as well as CUPS application itself, might be buggy and might got exploited when talking to a compromised printer (or by an attacker who controls the local network, or the default NetVM). Consider not using printing from your more trusted AppVMs for this reason.
|
||||
Additionally, the printer drivers as well as CUPS application itself, might be buggy and might get exploited when talking to a compromised printer (or by an attacker who controls the local network, or the default NetVM).
|
||||
Consider not using printing from your more trusted AppVMs for this reason.
|
||||
|
||||
Steps to configure a network printer in a template VM
|
||||
----------------------------------------------------------
|
||||
|
||||
1. Start the "Printer Settings" App in a template VM (either via Qubes "Start Menu", or by launching the `system-config-printer` in the template).
|
||||
2. Add/Configure the printer in the same way as one would do on any normal Linux. Be sure to allow network access from the template VM to your printer, as normally the template VM is not allowed any network access, except to the Qubes proxy for software installation. One can use Qubes Manager to modify firewall rules for particular VMs.
|
||||
2. Add/Configure the printer in the same way as one would do on any normal Linux.
|
||||
You may need to allow network access from the template VM to your printer to complete configuration, as normally the template VM is not allowed any network access except to the Qubes proxy for software installation.
|
||||
One can use Qubes Manager to modify firewall rules for particular VMs.
|
||||
3. Optional: Test the printer by printing a test page. If it works, shut down the template VM.
|
||||
4. Open an AppVM (make sure it's based on the template where you just installed the printer, normally all AppVMs are based on the default template), and test if printing works. If it doesn't then probably the AppVM doesn't have networking access to the printer -- in that case adjust the firewall settings for that AppVM in Qubes Manager. Also, make sure that the AppVM gets restarted after the template was shutdown.
|
||||
4. Open an AppVM (make sure it's based on the template where you just installed the printer, normally all AppVMs are based on the default template), and test if printing works.
|
||||
If it doesn't then probably the AppVM doesn't have networking access to the printer -- in that case adjust the firewall settings for that AppVM in Qubes Manager.
|
||||
Also, make sure that the AppVM gets restarted after the template was shutdown.
|
||||
5. Alternatively if you do not want to modify the firewall rules of the template VM (that have security scope) you can simply shut down the template VM without trying to print the test page (which will not work), start or restart an AppVM based on the template and test printing there.
|
||||
|
||||
|
|
|
|||
|
|
@ -16,11 +16,11 @@ Postfix is full featured MTA (Message Transfer Agent). Here we will configure it
|
|||
Installation
|
||||
------------
|
||||
|
||||
`yum install postfix procmail make cyrus-sasl cyrus-sasl-plain`
|
||||
`dnf install postfix procmail make cyrus-sasl cyrus-sasl-plain`
|
||||
|
||||
Cyrus-sasl is installed to authenticate to remote servers. Procmail is not strictly necessary, but is useful to sort your incoming mail, for example to put each mailing list in its own directory. Make is also not necessary, but is used to keep Postfix lookup tables.
|
||||
|
||||
You should also check `alternatives` command, to see if it is the default `mta`. It probably is not. You may need to `yum remove ssmtp` or something
|
||||
You should also check `alternatives` command, to see if it is the default `mta`. It probably is not. You may need to `dnf remove ssmtp` or something
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
|
@ -99,14 +99,14 @@ alias_maps = hash:/etc/aliases
|
|||
@localhost your.mail@example.com
|
||||
~~~
|
||||
|
||||
`/usr/local/etc/postfix/sender_relay`. This is important file. Put there all your SMTP servers. Pay attention to port (smtp/submission). Square brackets have their special meaning, they are almost certainly needed. For more info consult Postfix manual.
|
||||
`/usr/local/etc/postfix/sender_relay`. This is an important file. Put all your SMTP servers there. Pay attention to port (smtp/submission). Square brackets have their special meaning, they are almost certainly needed. For more info consult Postfix manual.
|
||||
|
||||
~~~
|
||||
your.mail@exmaple.com [mail.example.com]:submission
|
||||
your.other@mail.com [smtp.mail.com]:smtp
|
||||
~~~
|
||||
|
||||
`/usr/local/etc/postfix/saslpass`. Here you put passwords to above mentioned servers. It depends on provider if you need to put whole email as username or just the part before `@`.
|
||||
`/usr/local/etc/postfix/saslpass`. Here you put passwords to above mentioned servers. It depends on your provider if you need to put whole email as username or just the part before `@`.
|
||||
|
||||
~~~
|
||||
[mail.example.com]:submission your.mail:y0urP4ssw0rd
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
layout: doc
|
||||
title: Resize Disk Image
|
||||
title: Resize Private Disk Image
|
||||
permalink: /doc/resize-disk-image/
|
||||
redirect_from:
|
||||
- /en/doc/resize-disk-image/
|
||||
|
|
@ -8,40 +8,65 @@ redirect_from:
|
|||
- /wiki/ResizeDiskImage/
|
||||
---
|
||||
|
||||
Resize Disk Image
|
||||
Resize Private Disk Image
|
||||
-----------------
|
||||
|
||||
There are several disk images which can be easily extended. But pay attention to the overall consumed space of your sparse disk images.
|
||||
There are several disk images which can be easily extended, but pay attention to the overall consumed space of your sparse disk images.
|
||||
See also additional information and caveats about [resizing the root disk image](/doc/resize-root-disk-image/).
|
||||
|
||||
### Private disk image
|
||||
|
||||
1048576 MB is the maximum size which can be assigned to a private storage through qubes-manager.
|
||||
### Private disk image (R4.0)
|
||||
|
||||
To grow the private disk image of a AppVM beyond this limit [qubes-grow-private](/doc/dom0-tools/qvm-grow-private/) can be used:
|
||||
1048576 MiB is the maximum size which can be assigned to private storage through Qube Manager.
|
||||
|
||||
To grow the private disk image of an AppVM beyond this limit, `qvm-volume` can be used:
|
||||
|
||||
~~~
|
||||
qvm-volume extend <vm_name>:private <size>
|
||||
~~~
|
||||
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
|
||||
### Private disk image (R3.2)
|
||||
|
||||
1048576 MB is the maximum size which can be assigned to private storage through Qubes Manager.
|
||||
|
||||
To grow the private disk image of an AppVM beyond this limit, [qvm-grow-private](/doc/dom0-tools/qvm-grow-private/) can be used:
|
||||
|
||||
~~~
|
||||
qvm-grow-private <vm-name> <size>
|
||||
~~~
|
||||
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
|
||||
### Shrinking private disk image (Linux VM)
|
||||
### Shrinking private disk image (Linux VM, R4.0)
|
||||
|
||||
**This operation is dangerous and this is why it isn't available in standard Qubes tools. If you have enough disk space, it is safer to create new VM with smaller disk and move the data.**
|
||||
1. Create a new qube with smaller disk using Qube Manager or `qvm-create`
|
||||
2. Move data to the new qube using `qvm-copy` or OS utilities
|
||||
3. Delete old qube using Qube Manager or `qvm-remove`
|
||||
|
||||
### Shrinking private disk image (Linux VM, R3.2)
|
||||
|
||||
**This operation is dangerous and this is why it isn't available in standard Qubes tools.
|
||||
If you have enough disk space, it is safer to create a new VM with a smaller disk and move the data.**
|
||||
|
||||
The basic idea is to:
|
||||
|
||||
1. Shrink filesystem on the private disk image.
|
||||
2. Then shrink the image.
|
||||
|
||||
Ext4 does not support online shrinking, so can't be done as convenient as image grown. Note that we don't want to touch the VM filesystem directly in dom0 for security reasons. First you need to start VM without `/rw` mounted. One of the possibility is to interrupt its normal startup by adding `rd.break` kernel option:
|
||||
Ext4 does not support online shrinking, so it can't be done as conveniently as growing the image.
|
||||
Note that we don't want to touch the VM filesystem directly in dom0 for security reasons.
|
||||
First you need to start VM without `/rw` mounted.
|
||||
One possibility is to interrupt its normal startup by adding the `rd.break` kernel option:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s <vm-name> kernelopts rd.break
|
||||
qvm-start --no-guid <vm-name>
|
||||
~~~
|
||||
|
||||
And wait for qrexec connect timeout (or simply press Ctrl-C). Then you can connect to VM console and shrink the filesystem:
|
||||
And wait for qrexec connect timeout (or simply press Ctrl-C).
|
||||
Then you can connect to VM console and shrink the filesystem:
|
||||
|
||||
~~~
|
||||
sudo xl console <vm-name>
|
||||
|
|
@ -63,7 +88,9 @@ Now you can resize the image:
|
|||
truncate -s <new-desired-size> /var/lib/qubes/appvms/<vm-name>/private.img
|
||||
~~~
|
||||
|
||||
**It is critical to use the same (or bigger for some safety margin) size in truncate call compared to resize2fs call. Otherwise you will loose your data!** Then reset kernel options back to default:
|
||||
**It is critical to use the same (or bigger for some safety margin) size in truncate call compared to resize2fs call.
|
||||
Otherwise you will lose your data!**
|
||||
Then reset kernel options back to default:
|
||||
|
||||
~~~
|
||||
qvm-prefs -s <vm-name> kernelopts default
|
||||
|
|
@ -71,43 +98,18 @@ qvm-prefs -s <vm-name> kernelopts default
|
|||
|
||||
Done.
|
||||
|
||||
>In order to avoid error, you might want to first reduce the filesystem to a smaller size than desired (say 3G), then truncate the image to the target size (for example 4G), and lastly grow the filesystem to the target size. In order to do this, after the `truncate` step, start the vm again in maintenance mode and use the following command to extend the filesystem to the correct size : `resize2fs /dev/xvdb`.
|
||||
>In order to avoid error, you might want to first reduce the filesystem to a smaller size than desired (say 3G), then truncate the image to the target size (for example 4G), and lastly grow the filesystem to the target size.
|
||||
>In order to do this, after the `truncate` step, start the vm again in maintenance mode and use the following command to extend the filesystem to the correct size : `resize2fs /dev/xvdb`.
|
||||
>
|
||||
>With no argument, resize2fs grows the filesystem to match the underlying block device (the .img file you just shrunk)
|
||||
>With no argument, resize2fs grows the filesystem to match the underlying block device (the .img file you just shrunk).
|
||||
|
||||
|
||||
### Template disk image
|
||||
OS Specific Follow-up Instructions
|
||||
-----------------
|
||||
|
||||
If you want install a lot of software in your TemplateVM, you may need to increase the amount of disk space your TemplateVM can use. See also additional information and caveats about [resizing the root disk image].
|
||||
|
||||
1. Make sure that all the VMs based on this template are shut off (including netvms etc).
|
||||
2. Sanity check: verify that none of loop device are pointing at this template root.img. Run this in dom0: `sudo losetup -a`
|
||||
3. Resize root.img file. Run this in dom0: `truncate -s <desired size> <path to root.img>` (the root.img path can be obtained from qvm-prefs).
|
||||
4. If any netvm/proxyvm used by this template is based on it, set template netvm to none.
|
||||
5. Start the template.
|
||||
6. Execute `sudo resize2fs /dev/mapper/dmroot` in the template.
|
||||
7. Verify available space in the template using `df -h`
|
||||
8. Shutdown the template.
|
||||
9. Restore original netvm setting (if changed), check firewall settings (setting netvm to none causes firewall reset to "block all")
|
||||
|
||||
### HVM disk image
|
||||
|
||||
In this example we will grow the disk image of an HVM to 30GB.
|
||||
|
||||
First, stop/shutdown the HVM.
|
||||
|
||||
Then, from a Dom0 terminal (in KDE: System Tools -\> Terminal Emulator) do the following:
|
||||
|
||||
~~~
|
||||
cd /var/lib/qubes/appvms/<yourHVM>/
|
||||
ls -lh root.img (<--verify current size of disk image)
|
||||
truncate -s 30GB root.img
|
||||
ls -lh root.img (<--verify new size of disk image)
|
||||
~~~
|
||||
|
||||
The partition table and file-system must be adjusted after this change.
|
||||
Use tools appropriate to the OS in your HVM. Brief instructions for Windows 7,
|
||||
FreeBSD, and Linux are provided below.
|
||||
After resizing volumes, the partition table and file-system may need to be adjusted.
|
||||
Use tools appropriate to the OS in your qube.
|
||||
Brief instructions for Windows 7, FreeBSD, and Linux are provided below.
|
||||
|
||||
#### Windows 7
|
||||
|
||||
|
|
@ -129,8 +131,6 @@ zpool online -e poolname ada0
|
|||
|
||||
#### Linux
|
||||
|
||||
Qubes will automatically grow the filesystem for you on AppVMs but not HVMs.
|
||||
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 mkfs to make this space available.
|
||||
|
||||
|
||||
[resizing the root disk image]: /doc/resize-root-disk-image/
|
||||
|
|
|
|||
|
|
@ -11,11 +11,53 @@ redirect_from:
|
|||
Resize Root Disk Image
|
||||
----------------------
|
||||
|
||||
The safest way to increase the size of `root.img` is to turn your TemplateVM into a StandaloneVM. Doing this means it will have it's own root filesystem *(StandaloneVMs use a copy of template, instead of smart sharing)*. To do this run `qvm-create --standalone` from `dom0` Konsole.
|
||||
See additional information and caveats about [resizing private disk images](/doc/resize-disk-image/), paying particular attention to "OS Specific Follow-up Instructions" at the end.
|
||||
|
||||
### Resize a StandaloneVM Root Image
|
||||
### Template disk image
|
||||
|
||||
In `dom0` Konsole run the following command (replace the size and path):
|
||||
If you want install a lot of software in your TemplateVM, you may need to increase the amount of disk space your TemplateVM can use.
|
||||
*Make sure changes in the TemplateVM between reboots don't exceed 10G.*
|
||||
|
||||
1. Make sure that all the VMs based on this template are shut down (including netvms etc).
|
||||
2. Resize root image using Qubes version specific procedure below.
|
||||
3. If any netvm/proxyvm used by this template is based on it, set template's netvm to none.
|
||||
4. Start the template.
|
||||
5. Resize the filesystem using OS appropriate tools (Qubes will handle this automatically with Linux templates).
|
||||
6. Verify available space in the template using `df -h` or OS specific tools.
|
||||
7. Shutdown the template.
|
||||
8. Restore original netvm setting (if changed), check firewall settings (setting netvm to none causes the firewall to reset to "block all")
|
||||
|
||||
### Root disk image (R4.0)
|
||||
|
||||
1048576 MiB is the maximum size which can be assigned to root storage through Qube Manager.
|
||||
|
||||
To grow the root disk image of an AppVM beyond this limit, `qvm-volume` can be used:
|
||||
|
||||
~~~
|
||||
qvm-volume extend <vm_name>:root <size>
|
||||
~~~
|
||||
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
|
||||
### Root disk image (R3.2)
|
||||
|
||||
1048576 MB is the maximum size which can be assigned to root storage through Qubes Manager.
|
||||
|
||||
To grow the root disk image of an AppVM beyond this limit, `qvm-grow-root` can be used:
|
||||
|
||||
~~~
|
||||
qvm-grow-root <vm-name> <size>
|
||||
~~~
|
||||
|
||||
Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk.
|
||||
|
||||
### Resize a StandaloneVM Root Image (R3.2)
|
||||
|
||||
Another way to increase the size of `root.img` is to turn your TemplateVM into a StandaloneVM.
|
||||
Doing this means it will have it's own root filesystem *(StandaloneVMs use a copy of template, instead of smart sharing)*.
|
||||
To do this run `qvm-create --standalone` from `dom0` console.
|
||||
|
||||
In `dom0` console run the following command (replace the size and path):
|
||||
|
||||
~~~
|
||||
truncate -s 20G /var/lib/qubes/appvms/standalonevm/root.img
|
||||
|
|
@ -27,28 +69,4 @@ Then start Terminal for this StandaloneVM and run:
|
|||
sudo resize2fs /dev/mapper/dmroot
|
||||
~~~
|
||||
|
||||
Shutdown the StandaloneVM and you will have extended the size of it's `root.img`
|
||||
|
||||
|
||||
### Resize a TemplateVM Root Image
|
||||
|
||||
Shut down the TemplateVM, as well as all VMs based on that template (since they
|
||||
share `root.img`).
|
||||
In `dom0` Konsole run the following command (replace the size and path):
|
||||
*Make sure changes in the TemplateVM between reboots didn't exceed 10G.*
|
||||
|
||||
~~~
|
||||
truncate -s 20G /var/lib/qubes/vm-templates/fedora-21/root.img
|
||||
~~~
|
||||
|
||||
Then start only the TemplateVM and run the following. Note that if you are
|
||||
resizing the TemplateVM used by, e.g., your NetVM, you may need to disable
|
||||
networking so when the TemplateVM is started, it does not autostart other VMs
|
||||
based on the same `root.img`. Otherwise you will get an error message `Nothing
|
||||
to do!`.
|
||||
|
||||
~~~
|
||||
sudo resize2fs /dev/mapper/dmroot
|
||||
~~~
|
||||
|
||||
Shutdown the TemplateVM and you will have extended the size of it's `root.img`.
|
||||
Shutdown the StandaloneVM and you will have extended the size of its `root.img`.
|
||||
|
|
|
|||
|
|
@ -16,12 +16,16 @@ Rxvt
|
|||
Installation
|
||||
------------
|
||||
|
||||
`yum install rxvt-unicode-256color-ml` will bring both base `rxvt-unicode` and extension. Let me also recommend excellent Terminus font: `yum install terminus-fonts`.
|
||||
`dnf install rxvt-unicode-256color-ml` will bring both base `rxvt-unicode` and extension.
|
||||
Let me also recommend excellent Terminus font: `dnf install terminus-fonts`.
|
||||
|
||||
Xresources
|
||||
----------
|
||||
|
||||
In TemplateVM create file `/etc/X11/Xresources.urxvt` and paste config below. `!`-lines are comments and may be left out. `#`-lines are directives to CPP (C preprocessor) and are necessary. This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default.
|
||||
In TemplateVM create file `/etc/X11/Xresources.urxvt` and paste config below.
|
||||
`!`-lines are comments and may be left out.
|
||||
`#`-lines are directives to CPP (C preprocessor) and are necessary.
|
||||
This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default.
|
||||
|
||||
~~~
|
||||
! CGA colour palette
|
||||
|
|
@ -132,7 +136,8 @@ URxvt.insecure: False
|
|||
!URxvt.termName: rxvt-256color
|
||||
~~~
|
||||
|
||||
Then create script to automatically merge those to xrdb. File `/etc/X11/xinit/xinitrc.d/urxvt.sh`:
|
||||
Then create script to automatically merge those to xrdb.
|
||||
File `/etc/X11/xinit/xinitrc.d/urxvt.sh`:
|
||||
|
||||
~~~
|
||||
#!/bin/sh
|
||||
|
|
@ -143,4 +148,5 @@ Then create script to automatically merge those to xrdb. File `/etc/X11/xinit/xi
|
|||
Shortcuts
|
||||
---------
|
||||
|
||||
For each AppVM, go to *Qubes Manager \> VM Settings \> Applications*. Find `rxvt-unicode` (or `rxvt-unicode (256-color) multi-language`) and add.
|
||||
For each AppVM, go to *Qubes Manager \> VM Settings \> Applications*.
|
||||
Find `rxvt-unicode` (or `rxvt-unicode (256-color) multi-language`) and add.
|
||||
|
|
|
|||
|
|
@ -242,7 +242,7 @@ compromise cannot spread from one VM to another.
|
|||
|
||||
## Writing Your Own Configurations
|
||||
|
||||
Let's start with quick a example:
|
||||
Let's start with a quick example:
|
||||
|
||||
my new and shiny VM:
|
||||
qvm.present:
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue