mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2024-10-01 01:25:40 -04:00
Updated docs, fixed spelling and use Markdown code syntax for commands.
* Add FIXMEs.
This commit is contained in:
Robin Schneider
parent
b7a052ea02
commit
1d80a57af3
@ -11,7 +11,7 @@ Starting with Qubes R3 we use [python unittest](TODO) to perform automatic
|
||||
tests of Qubes OS. Regardless of the name, we use it for both [unit
|
||||
tests](https://en.wikipedia.org/wiki/Unit_tests) and [integration
|
||||
tests](https://en.wikipedia.org/wiki/Integration_tests). The main purpose is of
|
||||
course deliver much more stable releases.
|
||||
course to deliver much more stable releases.
|
||||
|
||||
Integration tests are written with assumption to be called on dedicated
|
||||
hardware. **Do not run those test on machine where you have important data, you
|
||||
|
||||
@ -26,7 +26,7 @@ with the same question.
|
||||
Submitting a Bug Report (or "Issue")
|
||||
------------------------------------
|
||||
|
||||
In GitHub, "Bug Reports" are called "Issues."
|
||||
On GitHub, "Bug Reports" are called "Issues."
|
||||
|
||||
Issues can be submitted to the Qubes project located at
|
||||
[https://github.com/QubesOS/qubes-issues](https://github.com/QubesOS/qubes-issues).
|
||||
@ -53,10 +53,10 @@ filing a new one.
|
||||
You should be sure to include the version the project, as well as versions
|
||||
of related software. For example, be sure to include the Qubes release
|
||||
version (R2, R3) and specific version numbers of package causing problems
|
||||
(if known)
|
||||
(if known).
|
||||
If your issue is related to hardware, provide as many details as possible
|
||||
about the hardware, which could include using commandline tools such as
|
||||
lspci.
|
||||
`lspci`.
|
||||
|
||||
Project maintainers really appreciate thorough explanations. It usually
|
||||
helps them address the problem more quickly, so everyone wins!
|
||||
|
||||
@ -20,7 +20,7 @@ Maintaining proper coding style is very important for any larger software projec
|
||||
- It allows others to easily review the code and catch various bugs,
|
||||
- It provides for an aesthetically pleasing experience when one reads the code...
|
||||
|
||||
Often, developers, usually smart developers, neglect the value of proper coding style, thinking that it's most important how their code works, and expecting that if it solves some problem using a nice and neat trick, then it's all that is really required. Such thinking shows, however, immaturity and is a signal that the developer, however bright and smart, might not be a good fit for any larger project. Writing a clever exploit, that is to be used at one Black Hat show is one thing, while writing a useful software that is to be used and maintained for years, is quite a different story. If you want to show off how smart programmer you are, then you should become a researcher and write exploits. If, on the other hand, you want to be part of a team that makes real, useful software, you should ensure your coding style is impeccable. We often, at Qubes project, often took shortcuts, and often wrote nasty code, and this always back fired at us, sometime months, sometime years later, the net result being we had to spend time fixing code, rather than implementing new functionality.
|
||||
Often, developers, usually smart developers, neglect the value of proper coding style, thinking that it's most important how their code works, and expecting that if it solves some problem using a nice and neat trick, then it's all that is really required. Such thinking shows, however, immaturity and is a signal that the developer, however bright and smart, might not be a good fit for any larger project. Writing a clever exploit, that is to be used at one Black Hat show is one thing, while writing a useful software that is to be used and maintained for years, is quite a different story. If you want to show off what a smart programmer you are, then you should become a researcher and write exploits. If, on the other hand, you want to be part of a team that makes real, useful software, you should ensure your coding style is impeccable. We often, at Qubes project, often took shortcuts, and often wrote nasty code, and this always back fired at us, sometime months, sometime years later, the net result being we had to spend time fixing code, rather than implementing new functionality.
|
||||
|
||||
And here's a [link to the real case](https://groups.google.com/forum/#!msg/qubes-devel/XgTo6L8-5XA/JLOadvBqnqMJ) (one Qubes Security Bulletin) demonstrating how the above described problem lead to a real security bug. Never assume you're smart enough that you can disregard clean and rigorous coding!
|
||||
|
||||
@ -65,12 +65,12 @@ File naming conventions
|
||||
|
||||
- User commands that operate on particular VMs (also those accessible in VMs): `/usr/bin/qvm-*`
|
||||
- User commands that apply to the whole system (Dom0 only): `/usr/bin/qubes-*`
|
||||
- Auxilary executables and scripts in `/usr/libexec/qubes/` (Note: previously we used `/usr/lib/qubes` but decided to change that)
|
||||
- Helper, non-exeutable files in `/usr/share/qubes/`
|
||||
- Auxiliary executables and scripts in `/usr/libexec/qubes/` (Note: previously we used `/usr/lib/qubes` but decided to change that)
|
||||
- Helper, non-executable files in `/usr/share/qubes/`
|
||||
- Various config files in `/etc/qubes`
|
||||
- Qubes RPC services in `/etc/qubes-rpc`. Qubes RPC Policy definitions (only in Dom0) in `/etc/qubes-rpc/policy/`
|
||||
- All VM-related configs, images, and other files in `/var/lib/qubes/`
|
||||
- System-wide temporary files the reflect the current state of system in `/var/run/qubes`
|
||||
- System-wide temporary files which reflect the current state of system in `/var/run/qubes`
|
||||
- Logs: either log to the system-wide messages, or to `/var/log/qubes/`
|
||||
|
||||
**File naming in Windows systems:**
|
||||
@ -81,9 +81,9 @@ File naming conventions
|
||||
General programming style guidelines
|
||||
------------------------------------
|
||||
|
||||
- Do not try to impress wit your coding kung-fu, do not use tricks to save 2 lines of code, always prefer readability over trickiness!
|
||||
- Do not try to impress with your coding kung-fu, do not use tricks to save 2 lines of code, always prefer readability over trickiness!
|
||||
- Make sure your code compiles and builds without warnings.
|
||||
- Always first first about interfaces (e.g. function arguments, or class methods) and data structures before you start writing the actual code.
|
||||
- Always think first about interfaces (e.g. function arguments, or class methods) and data structures before you start writing the actual code.
|
||||
- Use comments to explain non-trivial code fragments, or expected behavior of more complex functions, if it is not clear from their name.
|
||||
- Do **not** use comments for code fragments where it is immediately clear what the code does. E.g. avoid constructs like this:
|
||||
|
||||
@ -148,12 +148,12 @@ Security coding guidelines
|
||||
height = untrusted_conf.height;
|
||||
{% endhighlight %}
|
||||
|
||||
- Use another variables, without the `untrusted_` prefix to hold the sanitized values, as seen above.
|
||||
- Use another variables, without the `untrusted_` prefix to hold the sanitized values, as shown above.
|
||||
|
||||
Python-specific guidelines
|
||||
--------------------------
|
||||
|
||||
- Please follow the guidlines [here](http://www.python.org/dev/peps/pep-0008/), unless they were in conflict with what is written on this page.
|
||||
- Please follow the guidelines [here](http://www.python.org/dev/peps/pep-0008/), unless they were in conflict with what is written on this page.
|
||||
|
||||
C and C++ specific guidelines
|
||||
-----------------------------
|
||||
|
||||
@ -40,13 +40,13 @@ See [the instruction](/doc/QubesBuilder/)
|
||||
|
||||
### Q: How do I submit a patch?
|
||||
|
||||
1. Make all the changes in your working directory, i.e. edit files, move them around (you can use 'git mv' for this), etc.
|
||||
1. Make all the changes in your working directory, i.e. edit files, move them around (you can use `git mv` for this), etc.
|
||||
|
||||
1. Add the changes and commit them (git add, git commit). Never mix different changes into one commit! Write a good description of the commit. The first line should contain a short summary, and then, if you feel like more explanations are needed, enter an empty new line, and then start the long, detailed description (optional).
|
||||
|
||||
1. Test your changes NOW: check if RPMs build fine, etc.
|
||||
|
||||
1. Create the patch using 'git format-patch'. This has an advantage over 'git diff', because the former will also include your commit message, your name and email, so that \*your\* name will be used as a commit's author.
|
||||
1. Create the patch using `git format-patch`. This has an advantage over `git diff`, because the former will also include your commit message, your name and email, so that \*your\* name will be used as a commit's author.
|
||||
|
||||
1. Send your patch to qubes-devel. Start the message subject with the '[PATCH]' string.
|
||||
|
||||
|
||||
@ -12,10 +12,11 @@ A workflow for developing Qubes OS+
|
||||
|
||||
First things first, setup [QubesBuilder](/doc/QubesBuilder/). This guide assumes you're using qubes-builder to build Qubes.
|
||||
|
||||
Repositories and Committing Code
|
||||
Repositories and committing Code
|
||||
--------------------------------
|
||||
|
||||
Qubes is split into a bunch of git repos. This are all contained in the `qubes-src` directory under qubes-builder.
|
||||
FIXME(ypid): Not on github?
|
||||
|
||||
The best way to write and contribute code is to create a git repo somewhere (e.g., github) for the repo you are interested in editing (e.g., `qubes-manager`, `core`, etc). To integrate your repo with the rest of Qubes, cd to the repo directory and add your repository as a remote in git
|
||||
|
||||
@ -168,7 +169,8 @@ sudo cp qmemman/qmemman*.py $QUBES_PY_DIR/
|
||||
sudo cp misc/vm-template-hvm.conf /usr/share/qubes/
|
||||
sudo cp misc/qubes-start.desktop /usr/share/qubes/
|
||||
sudo cp misc/block-snapshot /etc/xen/scripts/
|
||||
sudo cp aux-tools/qubes-dom0-updates.cron /etc/cron.daily/I hope to
|
||||
sudo cp aux-tools/qubes-dom0-updates.cron /etc/cron.daily/
|
||||
# FIXME(Abel Luck): I hope to
|
||||
{% endhighlight %}
|
||||
|
||||
### Apply qvm-tools
|
||||
|
||||
@ -23,13 +23,13 @@ FAQ
|
||||
|
||||
### How are you going to spend the donated Bitcoins?
|
||||
|
||||
Our primary intention is to fund development of additional Qubes features, such as Split GPG (\#474), Qubes MIME handlers, USB PV backend, IPv6 routing between VMs, etc. Those additional features, although often very cool and appealing, are often being postponed because we need to focus on the more mainstream features, including the commercial branches for our paying customers.
|
||||
Our primary intention is to fund development of additional Qubes features, such as [Split GPG](https://github.com/QubesOS/qubes-issues/issues/474), Qubes MIME handlers, USB PV backend, IPv6 routing between VMs, etc. Those additional features, although often very cool and appealing, are often being postponed because we need to focus on the more mainstream features, including the commercial branches for our paying customers.
|
||||
|
||||
But we cannot promise we won't spend your donated Bitcoins in some other way. Frankly, I (JR) don't believe that the income from public donations could sustain ITL in operation for even a month. If, however, ITL were in financial trouble, we would use those donations in an attempt to extend our agony ;) Generally, our goal is to make Qubes/ITL survive -- even if that means we must spend your donated Bitcoins on things other than cool open-source features. Hopefully though, this will not be necessary.
|
||||
|
||||
### I have donated X number of Bitcoins. Can I request that a special feature be implemented?
|
||||
|
||||
The simple answer is: No. If everybody were to decide, then nothing would get implemented. However, if you make a substantial donation (e.g., an amount which you believe could be used to pay for several months of a developer's work), then please contact us in person or via the mailing list. You can attach a digitally signed message using the Bitcoin address you used to donate in order to prove that who made a particular donation. In that case, we will listen carefully and, in the worst case, explain to you why we can't or don't want to implement your requested feature.
|
||||
The simple answer is: No. If everybody were to decide, then nothing would get implemented. However, if you make a substantial donation (e.g., an amount which you believe could be used to pay for several months of a developer's work), then please contact us in person or via the mailing list. You can attach a digitally signed message using the Bitcoin address you used to donate in order to prove that you made a particular donation. In that case, we will listen carefully and, in the worst case, explain to you why we can't or don't want to implement your requested feature.
|
||||
|
||||
### Who actually owns the above Bitcoin address?
|
||||
|
||||
@ -41,7 +41,7 @@ All Qubes developers are paid good salaries, and presently ITL is doing pretty w
|
||||
|
||||
1. Nobody forces or specifically asks you to donate. Qubes will (probably) survive without any donations.
|
||||
2. The main reason to donate is to encourage the creation of additional features, i.e., to make Qubes OS more secure and/or easier to use. This should benefit most Qubes users.
|
||||
3. Another reason to donate is to say "Thank you," as we're releasing Qubes under GPL (excluding the Windows support) and generally trying to make the world a better place. (Oh, right, I had to made this plug somewhere here;)
|
||||
3. Another reason to donate is to say "Thank you," as we're releasing Qubes under GPL (excluding the Windows support) and generally trying to make the world a better place. (Oh, right, I had to make this plug somewhere here;)
|
||||
|
||||
### Are you going to provide a financial report on how you spend our donated Bitcoins?
|
||||
|
||||
|
||||
@ -8,7 +8,7 @@ redirect_from: /wiki/Fetchmail/
|
||||
Fetchmail
|
||||
=========
|
||||
|
||||
Fetchmail is standalone MRA (Mail Retrieval Agent) aka "IMAP/POP3 client". Its sole purpose is to fetch your messages and store it locally or feed to local MTA (Message Transfer Agent). It cannot "read" messages — for that use MUA like Thunderbird or [Mutt](/doc/Mutt/).
|
||||
Fetchmail is standalone MRA (Mail Retrieval Agent) aka "IMAP/POP3 client". Its sole purpose is to fetch your messages and store it locally or feed to local MTA (Message Transfer Agent). It cannot "read" messages — for that, use a MUA like Thunderbird or [Mutt](/doc/Mutt/).
|
||||
|
||||
Installation
|
||||
------------
|
||||
|
||||
@ -13,7 +13,7 @@ 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).
|
||||
|
||||
Alternatively one can add a printer in a standalone VM, but this would limit the printer usage for this particular VM.
|
||||
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
|
||||
--------------------------------------------------------
|
||||
@ -22,16 +22,16 @@ Some printers require 3rd party drivers, typically downloadable from the vendor'
|
||||
|
||||
In order to mitigate this risk, one might consider creating a custom template (i.e. clone the original template) and then install the 3rd party, unverified drivers there. Such template might then be made the default template for [Disposable VM creation](/doc/DisposableVms/), 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 3rd 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 lock network, or who is controlling the (normally untrusted) Qubes NetVM, will likely 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.
|
||||
|
||||
Steps to configure a network printer in a default template
|
||||
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 special Qubes proxy for updates installation. One can use Qubes Manager to modify firewall rules for particular VMs.
|
||||
3. Test the printer by printing a test page. If it works, shut down the template VM.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
@ -10,39 +10,39 @@ Overview of VM block devices
|
||||
|
||||
Every VM has 4 block devices connected:
|
||||
|
||||
- **xvda** - base root device (/) - details described below
|
||||
- **xvdb** - private.img - place where VM always can write.
|
||||
- **xvdc** - volatile.img, discarded at each VM restart - here is placed swap and temporal "/" modifications (see below)
|
||||
- **xvdd** - modules.img - kernel modules and firmware
|
||||
- **xvda** – base root device (/) – details described below
|
||||
- **xvdb** – private.img – place where VM always can write.
|
||||
- **xvdc** – volatile.img, discarded at each VM restart – here is placed swap and temporal "/" modifications (see below)
|
||||
- **xvdd** – modules.img – kernel modules and firmware
|
||||
|
||||
private.img (xvdb)
|
||||
------------------
|
||||
|
||||
This is mounted as /rw and here is placed all VM private data. This includes:
|
||||
|
||||
- */home* - which is symlink to /rw/home
|
||||
- */usr/local* - which is symlink to /rw/usrlocal
|
||||
- */home* – which is bind mounted to /rw/home
|
||||
- */usr/local* – which is symlink to /rw/usrlocal
|
||||
- some config files (/rw/config) called by qubes core scripts (ex /rw/config/rc.local)
|
||||
|
||||
modules.img (xvdd)
|
||||
------------------
|
||||
|
||||
As kernel is chosen in dom0, not VM there must be some way to provide matching kernel modules to VM OS. Qubes kernel dir consists of 3 files:
|
||||
As the kernel is chosen in dom0, there must be some way to provide matching kernel modules to VM. Qubes kernel directory consists of 3 files:
|
||||
|
||||
- *vmlinuz* - actual kernel
|
||||
- *initramfs* - initial ramdisk containing script to setup snapshot devices (see below) and mount /lib/modules
|
||||
- *modules.img* - filesystem image of /lib/modules with matching kernel modules and firmware (/lib/firmware/updates is symlinked to /lib/modules/firmware)
|
||||
- *vmlinuz* – actual kernel
|
||||
- *initramfs* – initial ramdisk containing script to setup snapshot devices (see below) and mount /lib/modules
|
||||
- *modules.img* – filesystem image of /lib/modules with matching kernel modules and firmware (/lib/firmware/updates is symlinked to /lib/modules/firmware)
|
||||
|
||||
Normally kernel "package" is common for many VMs (can be set using qvm-prefs). One of them can be set as default (qvm-set-default-kernel) to simplify kernel updates (by default all VMs uses default kernel). All installed kernels are placed in /var/lib/qubes/vm-kernels as separate subdirs. In this case, modules.img is attached to VM as R/O device.
|
||||
Normally kernel "package" is common for many VMs (can be set using qvm-prefs). One of them can be set as default (qvm-set-default-kernel) to simplify kernel updates (by default all VMs use the default kernel). All installed kernels are placed in /var/lib/qubes/vm-kernels as separate subdirs. In this case, modules.img is attached to the VM as R/O device.
|
||||
|
||||
There is special case when VM can have custom kernel - when it is updateable (StandaloneVM or TemplateVM) and kernel is set to "none" (by qvm-prefs). In this case VM uses kernel from "kernels" VM subdir and modules.img is attached as R/W device. FIXME: "none" should be renamed to "custom".
|
||||
There is a special case when the VM can have a custom kernel – when it is updateable (StandaloneVM or TemplateVM) and the kernel is set to "none" (by qvm-prefs). In this case the VM uses the kernel from the "kernels" VM subdir and modules.img is attached as R/W device. FIXME: "none" should be renamed to "custom".
|
||||
|
||||
Qubes TemplateVM implementation
|
||||
===============================
|
||||
|
||||
TemplateVM has a shared root.img across all AppVMs that are based on it. This mechanism has some advantages over a simple common device connected to multiple VMs:
|
||||
|
||||
- root.img can be modified while there are AppVMs running - without corrupting the filesystem
|
||||
- root.img can be modified while there are AppVMs running – without corrupting the filesystem
|
||||
- multiple AppVMs that are using different versions of root.img (from various points in time) can be running concurrently
|
||||
|
||||
There are two layers of the device-mapper snapshot device; the first one enables modifying root.img without stopping the AppVMs and the second one, which is contained in the AppVM, enables temporal modifications to its filesystem. These modifications will be discarded after a restart of the AppVM.
|
||||
@ -54,20 +54,20 @@ Snapshot device in Dom0
|
||||
|
||||
This device consists of:
|
||||
|
||||
- root.img - real template filesystem
|
||||
- root-cow.img - differences between the device as seen by AppVM and the current root.img
|
||||
- root.img – real template filesystem
|
||||
- root-cow.img – differences between the device as seen by AppVM and the current root.img
|
||||
|
||||
The above is achieved through creating device-mapper snapshots for each version of root.img. When an AppVM is started, a xen hotplug script (/etc/xen/scripts/block-snapshot) reads the inode numbers of root.img and root-cow.img; these numbers are used as the snapshot device's name. When a device with the same name exists the new AppVM will use it - therefore, AppVMs based on the same version of root.img will use the same device. Of course, the device-mapper cannot use the files directly - it must be connected through /dev/loop\*. The same mechanism detects if there is a loop device associated with a file determined by the device and inode numbers - or if creating a new loop device is necessary.
|
||||
The above is achieved through creating device-mapper snapshots for each version of root.img. When an AppVM is started, a xen hotplug script (/etc/xen/scripts/block-snapshot) reads the inode numbers of root.img and root-cow.img; these numbers are used as the snapshot device's name. When a device with the same name exists the new AppVM will use it – therefore, AppVMs based on the same version of root.img will use the same device. Of course, the device-mapper cannot use the files directly – it must be connected through /dev/loop\*. The same mechanism detects if there is a loop device associated with a file determined by the device and inode numbers – or if creating a new loop device is necessary.
|
||||
|
||||
When an AppVM is stopped the xen hotplug script checks whether the device is still in use - if it is not, the script removes the snapshot and frees the loop device.
|
||||
When an AppVM is stopped the xen hotplug script checks whether the device is still in use – if it is not, the script removes the snapshot and frees the loop device.
|
||||
|
||||
### Changes to template filesystem
|
||||
|
||||
In order for the full potential of the snapshot device to be realized, every change in root.img must save the original version of the modified block in root-cow.img. This is achieved by a snapshot-origin device.
|
||||
|
||||
When TemplateVM is started, it receives the snapshot-origin device connected as a root device (in read-write mode). Therefore, every change to this device is immediately saved in root.img - but remains invisible to the AppVM, which uses the snapshot.
|
||||
When TemplateVM is started, it receives the snapshot-origin device connected as a root device (in read-write mode). Therefore, every change to this device is immediately saved in root.img – but remains invisible to the AppVM, which uses the snapshot.
|
||||
|
||||
When TemplateVM is stopped, the xen script moves root-cow.img to root-cow.img.old and creates a new one (using the qvm-template-commit tool). The snapshot device will remain untouched due to the loop device, which uses an actual file on the disk (by inode, not by name). Linux kernel frees the old root-cow.img files as soon as they are unused by all snapshot devices (to be exact, loop devices). The new root-cow.img file will get a new inode number, and so new AppVMs will get new snapshot devices (with different names).
|
||||
When TemplateVM is stopped, the xen script moves root-cow.img to root-cow.img.old and creates a new one (using the `qvm-template-commit` tool). The snapshot device will remain untouched due to the loop device, which uses an actual file on the disk (by inode, not by name). Linux kernel frees the old root-cow.img files as soon as they are unused by all snapshot devices (to be exact, loop devices). The new root-cow.img file will get a new inode number, and so new AppVMs will get new snapshot devices (with different names).
|
||||
|
||||
### Rollback template changes
|
||||
|
||||
@ -80,7 +80,7 @@ Steps performed by **qvm-revert-template-changes**:
|
||||
1. Ensure that no other VMs uses this template.
|
||||
2. Prepare snapshot device with ***root-cow.img.old*** instead of *root-cow.img* (*/etc/xen/scripts/block-snapshot prepare*).
|
||||
3. Replace *snapshot* device-mapper target with *snapshot-merge*, other parameters (chunk size etc) remains untouched. Now kernel starts merging changes stored in *root-cow.img.old* into *root.img*. d-m device can be used normally (if needed).
|
||||
4. Waits for merge completed: *dmsetup status* shows used snapshot blocks - it should be equal to metadata size when completed.
|
||||
4. Waits for merge completed: *dmsetup status* shows used snapshot blocks – it should be equal to metadata size when completed.
|
||||
5. Replace *snapshot-merge* d-m target back to *snapshot*.
|
||||
6. Cleanup snapshot device (if nobody uses it it the moment).
|
||||
7. Move *root-cow.img.old* to *root-cow.img* (overriding existing file).
|
||||
@ -90,15 +90,15 @@ Snapshot device in AppVM
|
||||
|
||||
Root device is exposed to AppVM in read-only mode. AppVM can write only in:
|
||||
|
||||
- private.img - persistent storage (mounted in /rw) used for /home, /usr/local - in future versions, its use may be extended
|
||||
- volatile.img - temporary storage, which is discarded after an AppVM restart
|
||||
- private.img – persistent storage (mounted in /rw) used for /home, /usr/local – in future versions, its use may be extended
|
||||
- volatile.img – temporary storage, which is discarded after an AppVM restart
|
||||
|
||||
volatile.img is divided into two partitions:
|
||||
|
||||
1. changes to root device
|
||||
2. swap partition
|
||||
|
||||
Inside of an AppVM, the root device is wrapped by the snapshot in the first partition of volatile.img. Therefore, the AppVM can write anything to its filesystem - however, such changes will be discarded after a restart.
|
||||
Inside of an AppVM, the root device is wrapped by the snapshot in the first partition of volatile.img. Therefore, the AppVM can write anything to its filesystem – however, such changes will be discarded after a restart.
|
||||
|
||||
StandaloneVM
|
||||
------------
|
||||
|
||||
16
VPN.md
16
VPN.md
@ -8,20 +8,20 @@ redirect_from: /wiki/VPN/
|
||||
How To make a VPN Gateway in Qubes
|
||||
----------------------------------
|
||||
|
||||
The simplest case if you set up a VPN connection using the Network Manager inside one of your VMs. Setting up such a connection is really not Qubes specific and it is documented in Your Operating system documentation. If you using the Qubes default Guest OS (Fedora): [Establishing a VPN Connection](http://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/sec-Establishing_a_VPN_Connection.html)
|
||||
The simplest case if you set up a VPN connection using the Network Manager inside one of your VMs. Setting up such a connection is really not Qubes specific and it is documented in Your operating system documentation. If you using the Qubes default Guest OS (Fedora): [Establishing a VPN Connection](http://docs.fedoraproject.org/en-US/Fedora/18/html/System_Administrators_Guide/sec-Establishing_a_VPN_Connection.html)
|
||||
|
||||
The Qubes specific part is choose the right VM for the VPN client:
|
||||
The Qubes specific part is to choose the right VM for the VPN client:
|
||||
|
||||
### NetVM
|
||||
|
||||
The simplest case if you set up a VPN connection using the Network Manager inside your NetVM. Because the NetworkManager already started you are ready to set up your VPN connection. However this has some disadvantages:
|
||||
The simplest case is to set up a VPN connection using the Network Manager inside your NetVM. Because the NetworkManager already started you are ready to set up your VPN connection. However this has some disadvantages:
|
||||
|
||||
- You have to place (and probably save) Your VPN credentials inside the NetVM wich is directly connected to the outside world
|
||||
- All your AppVMs wich are connected to the NetVM will be connected to the VPN (by default)
|
||||
- You have to place (and probably save) Your VPN credentials inside the NetVM which is directly connected to the outside world
|
||||
- All your AppVMs which are connected to the NetVM will be connected to the VPN (by default)
|
||||
|
||||
### AppVM
|
||||
|
||||
While the Network Manager is not started here (for a good reason) You can configure any kind of VPN client in your AppVM as well, however it is only suggested if you have to use a special VPN client.
|
||||
While the Network Manager is not started here (for a good reason), you can configure any kind of VPN client in your AppVM as well, however it is only suggested if you have to use a special VPN client.
|
||||
|
||||
### ProxyVM
|
||||
|
||||
@ -29,10 +29,10 @@ While the Network Manager is not started here (for a good reason) You can config
|
||||
|
||||
One of the best thing in Qubes that you can use a special type of VMs called ProxyVM (or FirewallVM). The special thing is that your AppVMs see this as a NetVM, and the NetVMs see it as an AppVM. Because of that You can place a ProxyVM between your AppVMs and Your NetVM. This is how the default firewall VM is working.
|
||||
|
||||
Using a ProxyVM to set up a VPN client will gives you the ability to:
|
||||
Using a ProxyVM to set up a VPN client gives you the ability to:
|
||||
|
||||
- Separate your VPN credentials from Your AppVM data.
|
||||
- You can easily control which of your AppVMs are connected to your VPN by simply set it as a NetVM of the desired AppVM.
|
||||
- Easily control which of your AppVMs are connected to your VPN by simply setting it as a NetVM of the desired AppVM.
|
||||
|
||||
**To setup a ProxyVM as a VPN gateway you should:**
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user