mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-05-02 23:05:19 -04:00
Update attachment paths
This commit is contained in:
Andrew David Wong
parent
60bd80ad25
commit
e451f92cde
31 changed files with 111 additions and 111 deletions
|
|
@ -114,7 +114,7 @@ vm_qrexec_gui/TC_20_DispVM_fedora-21/test_030_edit_file
|
|||
|
||||
Example test run:
|
||||
|
||||
|
||||
|
||||
|
||||
Tests are also compatible with nose2 test runner, so you can use this instead:
|
||||
|
||||
|
|
|
|||
|
|
@ -94,6 +94,6 @@ make REMOTE=example.com:public_html/qubes/profiling/ upload
|
|||
|
||||
This example is from `qubes-manager` (`qubesmanager/main.py`).
|
||||
|
||||
|
||||
|
||||
|
||||
It is apparent that the problem is around `get_disk_usage`, which calls something via `subprocess.call`. It does this 15 times, probably once per VM.
|
||||
|
|
|
|||
|
|
@ -65,43 +65,43 @@ Ok, let's start.
|
|||
Every documentation page has an "Edit this page" button.
|
||||
It may be on the side (in the desktop layout):
|
||||
|
||||
[](/attachment/wiki/doc-edit/03-button2.png)
|
||||
[](/attachment/doc/03-button2.png)
|
||||
|
||||
Or at the bottom (in the mobile layout):
|
||||
|
||||
[](/attachment/wiki/doc-edit/02-button1.png)
|
||||
[](/attachment/doc/02-button1.png)
|
||||
|
||||
When you click on it, you'll be prompted for your GitHub username and password (if you aren't already logged in).
|
||||
You can also create an account from here.
|
||||
|
||||
[](/attachment/wiki/doc-edit/04-sign-in.png)
|
||||
[](/attachment/doc/04-sign-in.png)
|
||||
|
||||
If this is your first contribution to the documentation, you need to "fork" the repository (make your own copy). It's easy --- just click the big green button on the next page.
|
||||
This step is only needed the first time you make a contribution.
|
||||
|
||||
[](/attachment/wiki/doc-edit/05-fork.png)
|
||||
[](/attachment/doc/05-fork.png)
|
||||
|
||||
Now you can make your modifications.
|
||||
You can also preview the changes to see how they'll be formatted by clicking the "Preview changes" tab.
|
||||
If you want to add images, please see [How to add images](#how-to-add-images).
|
||||
If you're making formatting changes, please [render the site locally](https://github.com/QubesOS/qubesos.github.io#instructions) to verify that everything looks correct before submitting any changes.
|
||||
|
||||
[](/attachment/wiki/doc-edit/06-edit.png)
|
||||
[](/attachment/doc/06-edit.png)
|
||||
|
||||
Once you're finished, describe your changes at the bottom and click "Propose file change".
|
||||
|
||||
[](/attachment/wiki/doc-edit/07-commit-msg.png)
|
||||
[](/attachment/doc/07-commit-msg.png)
|
||||
|
||||
After that, you'll see exactly what modifications you've made.
|
||||
At this stage, those changes are still in your own copy of the documentation ("fork").
|
||||
If everything looks good, send those changes to us by pressing the "Create pull request" button.
|
||||
|
||||
[](/attachment/wiki/doc-edit/08-review-changes.png)
|
||||
[](/attachment/doc/08-review-changes.png)
|
||||
|
||||
You will be able to adjust the pull request message and title there.
|
||||
In most cases, the defaults are ok, so you can just confirm by pressing the "Create pull request" button again.
|
||||
|
||||
[](/attachment/wiki/doc-edit/09-create-pull-request.png)
|
||||
[](/attachment/doc/09-create-pull-request.png)
|
||||
|
||||
If any of your changes should be reflected in the [documentation index (a.k.a. table of contents)](/doc/) --- for example, if you're adding a new page, changing the title of an existing page, or removing a page --- please see [How to edit the documentation index](#how-to-edit-the-documentation-index).
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ Otherwise, we may have some questions for you, which we'll post in a comment on
|
|||
(GitHub will automatically notify you if we do.)
|
||||
If, for some reason, we can't accept your pull request, we'll post a comment explaining why we can't.
|
||||
|
||||
[](/attachment/wiki/doc-edit/10-done.png)
|
||||
[](/attachment/doc/10-done.png)
|
||||
|
||||
## How to edit the documentation index
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ To add an image to a page, use the following syntax in the main document.
|
|||
This will make the image a hyperlink to the image file, allowing the reader to click on the image in order to view the image by itself.
|
||||
|
||||
```
|
||||
[](/attachment/wiki/page-title/image-filename.png)
|
||||
[](/attachment/doc/image-filename.png)
|
||||
```
|
||||
|
||||
Then, submit your image(s) in a separate pull request to the [qubes-attachment](https://github.com/QubesOS/qubes-attachment) repository using the same path and filename.
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ TBD
|
|||
|
||||
## Components
|
||||
|
||||
|
||||
|
||||
|
||||
A central entity in the Qubes Admin API system is a `qubesd` daemon, which
|
||||
holds information about all domains in the system and mediates all actions (like
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ Details of all possible use cases and the messages involved are described below.
|
|||
|
||||
### dom0: request execution of `cmd` in domX
|
||||
|
||||
|
||||
|
||||
|
||||
- **dom0**: `qrexec-client` is invoked in **dom0** as follows:
|
||||
|
||||
|
|
@ -145,7 +145,7 @@ Details of all possible use cases and the messages involved are described below.
|
|||
|
||||
### domX: request execution of service `admin.Service` in dom0
|
||||
|
||||
|
||||
|
||||
|
||||
- **domX**: `qrexec-client-vm` is invoked as follows:
|
||||
|
||||
|
|
@ -191,7 +191,7 @@ Details of all possible use cases and the messages involved are described below.
|
|||
|
||||
### domX: invoke execution of qubes service `qubes.Service` in domY
|
||||
|
||||
|
||||
|
||||
|
||||
- **domX**: `qrexec-client-vm` is invoked as follows:
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Typically, the first thing that a `qrexec-client` instance does is to send a req
|
|||
`qrexec-client` starts a vchan server, which `qrexec-agent` then connects to.
|
||||
Once this channel is established, stdin/stdout/stderr from the VMprocess is passed between `qrexec-agent` and the `qrexec-client` process.
|
||||
|
||||
|
||||
|
||||
|
||||
The `qrexec-client` command is used to make connections to VMs from dom0.
|
||||
For example, the following command creates an empty file called `hello-world.txt` in the home folder of `someVM`:
|
||||
|
|
|
|||
|
|
@ -300,7 +300,7 @@ significantly differs from what is described in this section.
|
|||
The VM-VM channels in Qubes R2 are made via "gluing" two VM-Dom0 and Dom0-VM
|
||||
vchan connections:
|
||||
|
||||
|
||||
|
||||
|
||||
Note that Dom0 never examines the actual data flowing in neither of the two
|
||||
vchan connections.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ title: Architecture
|
|||
|
||||
Qubes implements a Security by Isolation approach. To do this, Qubes utilizes virtualization technology in order to isolate various programs from each other and even to sandbox many system-level components, such as networking and storage subsystems, so that the compromise of any of these programs or components does not affect the integrity of the rest of the system.
|
||||
|
||||
[](/attachment/wiki/QubesArchitecture/qubes-schema-v2.png)
|
||||
[](/attachment/doc/qubes-schema-v2.png)
|
||||
|
||||
Qubes lets the user define many security domains, which are implemented as lightweight Virtual Machines (VMs), or “AppVMs.” For example, the user can have “personal,” “work,” “shopping,” “bank,” and “random” AppVMs and can use the applications within those VMs just as if they were executing on the local machine. At the same time, however, these applications are well isolated from each other. Qubes also supports secure copy-and-paste and file sharing between the AppVMs, of course.
|
||||
|
||||
|
|
@ -31,7 +31,7 @@ Key Architecture features
|
|||
- Qubes GUI provides isolation between apps sharing the same desktop
|
||||
- Secure system boot based (optional)
|
||||
|
||||
(For those interested in the history of the project, [Architecture Spec v0.3 [PDF]](/attachment/wiki/QubesArchitecture/arch-spec-0.3.pdf) is the original 2009 document that started this all.
|
||||
(For those interested in the history of the project, [Architecture Spec v0.3 [PDF]](/attachment/doc/arch-spec-0.3.pdf) is the original 2009 document that started this all.
|
||||
Please note that this document is for historical interest only.
|
||||
For the latest information, please see the rest of the [System Documentation](/doc/#system).)
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ the Qubes system include:
|
|||
|
||||
And all these components are "glued together" by the Qubes Core Stack.
|
||||
|
||||
[](/attachment/wiki/QubesArchitecture/qubes-components.png)
|
||||
[](/attachment/doc/qubes-components.png)
|
||||
|
||||
This diagram illustrates the location of all these components in the overall
|
||||
system architecture. Unlike the other Qubes architecture diagram above, this one
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ To sum up, this solution has the following benefits:
|
|||
- no changes to Xorg code
|
||||
- minimal size of the supporting code
|
||||
|
||||
|
||||
|
||||
|
||||
Security markers on dom0 windows
|
||||
--------------------------------
|
||||
|
|
|
|||
|
|
@ -56,12 +56,12 @@ qvm-features ipv4-only-qube ipv6 ''
|
|||
|
||||
This configuration is presented below - green qubes have IPv6 access, red one does not.
|
||||
|
||||
|
||||
|
||||
|
||||
In that case, system uplink connection have native IPv6. But in some cases it may not be true. Then some tunneling solution can be used (for example teredo). The same will apply when the user is connected to VPN service providing IPv6 support, regardless of user's internet connection.
|
||||
Such configuration can be expressed by enabling `ipv6` feature only on some subset of Qubes networking, for example by creating separate qube to encapsulate IPv6 traffic and setting `ipv6` to `1` only there. See diagram below
|
||||
|
||||
|
||||
|
||||
|
||||
Besides enabling IPv6 forwarding, standard Qubes firewall can be used to limit what network resources are available to each qube. Currently only `qvm-firewall` command support adding IPv6 rules, GUI firewall editor will have this ability later.
|
||||
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ TemplateVM has a shared root.img across all AppVMs that are based on it. This me
|
|||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
## Snapshot device in Dom0
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue