From aef3ad9dcf2fe2bbf47429690d248006106a55a7 Mon Sep 17 00:00:00 2001 From: mfc Date: Sun, 31 May 2015 14:40:13 -0400 Subject: [PATCH 001/174] updated TorVM docs to R3.0rc1, fixed typo in Whonix templates doc --- Templates/Whonix.md | 2 +- UserDoc/TorVM.md | 31 +++++++++++++++---------------- 2 files changed, 16 insertions(+), 17 deletions(-) diff --git a/Templates/Whonix.md b/Templates/Whonix.md index 30fadcb6..7accc453 100644 --- a/Templates/Whonix.md +++ b/Templates/Whonix.md @@ -13,6 +13,6 @@ based on the Tor anonymity network, Debian GNU/Linux and security by isolation. Its primary isolation mechanism is VirtualBox, but now it is also possible to run it on top of Qubes OS! -Whonix template(s) are another Qubes community contribution. Currently Whonix activelly maintains those templates. +Whonix template(s) are another Qubes community contribution. Currently Whonix actively maintains those templates. More details, including installation instructions on [Whonix Qubes web page](https://www.whonix.org/wiki/Qubes). diff --git a/UserDoc/TorVM.md b/UserDoc/TorVM.md index 3e585360..096c0a27 100644 --- a/UserDoc/TorVM.md +++ b/UserDoc/TorVM.md @@ -28,6 +28,8 @@ All non-DNS UDP and IPv6 traffic is silently dropped. See [this article](http://theinvisiblethings.blogspot.com/2011/09/playing-with-qubes-networking-for-fun.html) for a description of the concept, architecture, and the original implementation. +If you are interested TorVM, you may find the [Whonix](https://www.qubes-os.org/doc/Templates/Whonix/) templates in Qubes a more usable and robust solution for torifying traffic. + ## Warning + Disclaimer 1. Qubes TorVM is produced independently from the Tor(R) anonymity software and @@ -48,7 +50,7 @@ Installation 0. *(Optional)* If you want to use a separate vm template for your TorVM - qvm-clone fedora-20-x64 fedora-20-x64-net + qvm-clone fedora-21 fedora-21-tor 1. In dom0, create a proxy vm and disable unnecessary services and enable qubes-tor @@ -59,9 +61,9 @@ Installation qvm-service torvm -e qubes-tor # if you created a new template in the previous step - qvm-prefs torvm -s template fedora-20-x64-net + qvm-prefs torvm -s template fedora-21-tor -2. From your template vm, install the torproject Fedora repo +2. From your TemplateVM, install the torproject Fedora repo sudo yum install qubes-tor-repo @@ -69,21 +71,18 @@ Installation sudo yum install qubes-tor -5. Configure an AppVM to use TorVM as its netvm (example a vm named anon-web) +5. Configure an AppVM to use TorVM as its NetVM (for example a vm named anon-web) - qvm-prefs -s anon-web netvm torvm - ... repeat for other appvms ... + qvm-prefs -s anon-web sys-net torvm + ... repeat for any other AppVMs you want torified... -6. Shutdown templateVM. -7. Set prefs of torvm to use your default netvm or firewallvm as its NetVM -8. Start the TorVM and any AppVM you have configured -9. Execute in TorVM (will be not necessary in R2 Beta3): +6. Shutdown the TemplateVM. +7. Set the prefs of your TorVM to use the default sys-net or sys-firewall as its NetVM - sudo mkdir /rw/usrlocal/etc/qubes-tor - sudo touch /rw/usrlocal/etc/qubes-tor/torrc - sudo service qubes-tor restart + qvm-prefs -s torvm netvm sys-net -10. From the AppVM, verify torified connectivity +8. Start the TorVM and any AppVM you have configured to be route through the TorVM +9. From the AppVMs, verify torified connectivity curl https://check.torproject.org @@ -258,14 +257,14 @@ Acknowledgements Qubes TorVM is inspired by much of the previous work done in this area of transparent torified solutions. Notably the following: -* [adrelanos](mailto:adrelanos@riseup.net) for his work on [aos/Whonix](https://sourceforge.net/p/whonix/wiki/Security/) +* [adrelanos](mailto:adrelanos@riseup.net) for his work on [aos/Whonix](https://www.whonix.org) * The [Tor Project wiki](https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO) * And the many people who contributed to discussions on [tor-talk](https://lists.torproject.org/pipermail/tor-talk/) [stream-isolation]: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/171-separate-streams.txt [stream-isolation-explained]: https://lists.torproject.org/pipermail/tor-talk/2012-May/024403.html [tor-threats]: https://www.torproject.org/projects/torbrowser/design/#adversary -[qubes-net]: http://wiki.qubes-os.org/trac/wiki/QubesNet +[qubes-net]: https://www.qubes-os.org/doc/QubesNet/ [dns]: https://tails.boum.org/todo/support_arbitrary_dns_queries/ [tor-browser]: https://www.torproject.org/download/download-easy.html [tor-verify-sig]: https://www.torproject.org/docs/verifying-signatures.html From 7b31877f17920c353908b7e544f75ab22e236243 Mon Sep 17 00:00:00 2001 From: Axon Date: Fri, 5 Jun 2015 03:19:01 +0000 Subject: [PATCH 002/174] Rewrote SecurityPack in Markdown. --- SecurityPack.md | 239 ++++++++++++++++++++++++------------------------ 1 file changed, 119 insertions(+), 120 deletions(-) diff --git a/SecurityPack.md b/SecurityPack.md index 0b58085f..b759949f 100644 --- a/SecurityPack.md +++ b/SecurityPack.md @@ -8,126 +8,122 @@ redirect_from: /wiki/SecurityPack/ Qubes Security Pack =================== -1. [Qubes Security Pack](#QubesSecurityPack) - 1. [Introduction](#Introduction) - 2. [History and Rationale](#HistoryandRationale) - 3. [How to Obtain, Verify, and Read](#HowtoObtainVerifyandRead) - -Introduction ------------- - The **Qubes Security Pack (QSP)** is a Git repository which contains: -- [All Qubes Security Bulletins (QSBs)](/doc/SecurityBulletins/) -- [All PGP keys](https://keys.qubes-os.org/keys/) -- [Warrant canaries](https://en.wikipedia.org/wiki/Warrant_canary) -- Other security-related information and announcements (such as key revocations) + * [Qubes Security Bulletins (QSBs)](/doc/SecurityBulletins/) + * [Qubes PGP keys](https://keys.qubes-os.org/keys/) + * [Qubes warrant canaries](https://canarywatch.org/qubesOS/) + * Security-related information and announcements (e.g., key revocations) -The QSP is located here: +The official location of the QSP is: + +`https://github.com/QubesOS/qubes-secpack` +[(link)](https://github.com/QubesOS/qubes-secpack) -> [https://github.com/QubesOS/qubes-secpack](https://github.com/QubesOS/qubes-secpack) History and Rationale --------------------- -On 2013-01-05, Joanna Rutkowska announced the QSP and explained its rationale in an [email](https://groups.google.com/d/msg/qubes-devel/twkOEaMLtNI/lZyGx6_jFCEJ) to the Qubes mailing lists: +On 2013-01-05, Joanna Rutkowska announced the QSP and explained its rationale in +an [email](https://groups.google.com/d/msg/qubes-devel/twkOEaMLtNI/lZyGx6_jFCEJ) +to the Qubes mailing lists: -{% highlight trac-wiki %} -Hello, + Hello, + + A new Qubes Security Bulletin has been just released and is available here: + + https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt + + As per the previous discussions about recent problems with verifying + digital signatures on messages sent to Google Groups (thanks to + automatic footer addition by Google), we have decided to change the way + we publish Qubes Security Bulletins, as well as other security-related + info pertinent to the Qubes Project. + + Starting today, we will be maintain a Git repository -- "Qubes Security + Pack" -- which will contain all the QSBs released so far, all the keys, + warrant canaries [1], and potentially some additional info or + announcements (e.g. key revocations). The whole repo can be found here: + + https://github.com/QubesOS/qubes-secpack + + Note that all the keys distributed there should be signed by Qubes + Master Key. The Master Key is also attached in the repo, but should + really be obtained/verified using a different channel. + + Additionally, most of the files are signed by core Qubes + developers (currently by Marek and myself) via detached signatures as + well as git tag signatures. + + The are several advantages of using Git to distribute all these information: + + 1) Git repo is a collection of files, some of which can be detached GPG + signatures for other files and we can ensure all these files are + distributed together. + + 2) Git makes it easy for people to clone and redistribute these + collection of files, as well as to easily host them and view on the Web. + + 3) Git provides for signed tags mechanisms which is another mean we + utilize to ensure integrity of the distributed files. + + A few words about the Warrant Canary which we've just introduced today, + and which can be seen here: + + https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-001-2015.txt + + Even though we're not providing any kind of services (such as e.g. email + hosting), that could be searched or tapped by authorities, there are + other possibilities that worry us [2], in the light of various recent + law "developments", such as those that might be coercing people to hand + over their private keys to authorities. + + Until we fully decentralize the root of trust for Qubes, something that + requires the move to deterministic builds [3], and so won't happen + very soon, the possibility of having to disclose any of the Qubes + signing keys to anybody might have pretty serious consequences for those + who decided to entrust Qubes with anything serious. And we would like to + somehow minimize these consequences with this canary thing. + + Additionally the canary is a nice way of ensuring "freshness" of our + messaging to the community. + + Of course the canary doesn't solve all the problems. E.g. if my signing + keys were somehow stolen without our knowledge, it wouldn't help. + Neither it could help in case me being or becoming a miscreant. And + probably it doesn't address many other potential problems, which could + only be solved one day with a multi-signature scheme. But anyway, until + that time, this is the best we can do, I think. + + And congrats to Jann for the very interesting clipboard attack (even + though mostly theoretical, still very cool)! + + Thanks, + joanna. + + -- + The Qubes Security Team + https://www.qubes-os.org/doc/SecurityPage + + + [1] http://en.wikipedia.org/wiki/Warrant_canary + + [2] Especially myself, because I'm currently the Root Of Trust for all + Qubes binaries :/ + + [3] Deterministic builds are required because it's the only way we can + implement multiple signature scheme for distributed binaries. -A new Qubes Security Bulletin has been just released and is available here: - -https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-013-2015.txt - -As per the previous discussions about recent problems with verifying -digital signatures on messages sent to Google Groups (thanks to -automatic footer addition by Google), we have decided to change the way -we publish Qubes Security Bulletins, as well as other security-related -info pertinent to the Qubes Project. - -Starting today, we will be maintain a Git repository -- "Qubes Security -Pack" -- which will contain all the QSBs released so far, all the keys, -warrant canaries [1], and potentially some additional info or -announcements (e.g. key revocations). The whole repo can be found here: - -https://github.com/QubesOS/qubes-secpack - -Note that all the keys distributed there should be signed by Qubes -Master Key. The Master Key is also attached in the repo, but should -really be obtained/verified using a different channel. - -Additionally, most of the files are signed by core Qubes -developers (currently by Marek and myself) via detached signatures as -well as git tag signatures. - -The are several advantages of using Git to distribute all these information: - -1) Git repo is a collection of files, some of which can be detached GPG -signatures for other files and we can ensure all these files are -distributed together. - -2) Git makes it easy for people to clone and redistribute these -collection of files, as well as to easily host them and view on the Web. - -3) Git provides for signed tags mechanisms which is another mean we -utilize to ensure integrity of the distributed files. - -A few words about the Warrant Canary which we've just introduced today, -and which can be seen here: - -https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-001-2015.txt - -Even though we're not providing any kind of services (such as e.g. email -hosting), that could be searched or tapped by authorities, there are -other possibilities that worry us [2], in the light of various recent -law "developments", such as those that might be coercing people to hand -over their private keys to authorities. - -Until we fully decentralize the root of trust for Qubes, something that -requires the move to deterministic builds [3], and so won't happen -very soon, the possibility of having to disclose any of the Qubes -signing keys to anybody might have pretty serious consequences for those -who decided to entrust Qubes with anything serious. And we would like to -somehow minimize these consequences with this canary thing. - -Additionally the canary is a nice way of ensuring "freshness" of our -messaging to the community. - -Of course the canary doesn't solve all the problems. E.g. if my signing -keys were somehow stolen without our knowledge, it wouldn't help. -Neither it could help in case me being or becoming a miscreant. And -probably it doesn't address many other potential problems, which could -only be solved one day with a multi-signature scheme. But anyway, until -that time, this is the best we can do, I think. - -And congrats to Jann for the very interesting clipboard attack (even -though mostly theoretical, still very cool)! - -Thanks, -joanna. - --- -The Qubes Security Team -https://www.qubes-os.org/doc/SecurityPage - - -[1] http://en.wikipedia.org/wiki/Warrant_canary - -[2] Especially myself, because I'm currently the Root Of Trust for all -Qubes binaries :/ - -[3] Deterministic builds are required because it's the only way we can -implement multiple signature scheme for distributed binaries. -{% endhighlight %} How to Obtain, Verify, and Read ------------------------------- -The following example demonstrates one method of obtaining the QSP, verifying its contents, and reading them. +The following example demonstrates one method of obtaining the QSP, verifying +its contents, and reading them. -1. Clone the QSP repo. + 1. Clone the QSP repo. - {% highlight trac-wiki %} + ``` [user@qubes ~]$ git clone https://github.com/QubesOS/qubes-secpack.git Cloning into 'qubes-secpack'... remote: Counting objects: 195, done. @@ -135,11 +131,11 @@ The following example demonstrates one method of obtaining the QSP, verifying it Receiving objects: 100% (195/195), 130.94 KiB | 207.00 KiB/s, done. Resolving deltas: 100% (47/47), done. Checking connectivity... done. - {% endhighlight %} + ``` -2. Import the included PGP keys. + 2. Import the included PGP keys. - {% highlight trac-wiki %} + ``` [user@qubes ~]$ gpg --import qubes-secpack/keys/*/* gpg: directory `/home/user/.gnupg' created gpg: new configuration file `/home/user/.gnupg/gpg.conf' created @@ -167,11 +163,11 @@ The following example demonstrates one method of obtaining the QSP, verifying it gpg: Total number processed: 17 gpg: imported: 17 (RSA: 17) gpg: no ultimately trusted keys found - {% endhighlight %} + ``` 3. Verify and trust the Qubes Master Signing Key. - {% highlight trac-wiki %} + ``` [user@qubes ~]$ gpg --edit-key 36879494 gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. @@ -211,15 +207,20 @@ The following example demonstrates one method of obtaining the QSP, verifying it unless you restart the program. gpg> q - {% endhighlight %} + ``` -> **Important!** + **Important!** -> In order to verify the authenticity of the Qubes Master Signing Key prior to trusting it, you should obtain the Qubes Master Signing Key fingerprint from a trustworthy source (ideally, multiple sources) *other than* this website and visually compare it (them) to the fingerprint displayed in the preceding step, ensuring they match. You can read more about digital signatures and key verification [here](/doc/VerifyingSignatures/). + In order to verify the authenticity of the Qubes Master Signing Key prior to + trusting it, you should obtain the Qubes Master Signing Key fingerprint from + a trustworthy source (ideally, multiple sources) *other than* this website + and visually compare it (them) to the fingerprint displayed in the preceding + step, ensuring they match. You can read more about digital signatures and + key verification [here](/doc/VerifyingSignatures/). -1. Verify and read the canaries. + 4. Verify and read the canaries. - {% highlight trac-wiki %} + ``` [user@qubes ~]$ cd qubes-secpack/canaries/ [user@qubes canaries]$ gpg --verify canary-001-2015.txt.sig.joanna canary-001-2015.txt gpg: Signature made Mon Jan 5 20:21:40 2015 UTC using RSA key ID 92C7B3DC @@ -233,11 +234,11 @@ The following example demonstrates one method of obtaining the QSP, verifying it ---===[ Qubes Canary #1 ]===--- [...] - {% endhighlight %} + ``` -2. Verify and read the QSBs. + 5. Verify and read the QSBs. - {% highlight trac-wiki %} + ``` [user@qubes canaries]$ cd ../QSBs/ [user@qubes QSBs]$ gpg --verify qsb-013-2015.txt.sig.joanna qsb-013-2015.txt gpg: Signature made Mon Jan 5 21:22:14 2015 UTC using RSA key ID 92C7B3DC @@ -251,6 +252,4 @@ The following example demonstrates one method of obtaining the QSP, verifying it ---===[ Qubes Security Bulletin #13 ]===--- [...] - {% endhighlight %} - - + ``` From 9e2f5fda8b62dee9cc8beb1dfa3514d4e99b679e Mon Sep 17 00:00:00 2001 From: Axon Date: Fri, 5 Jun 2015 03:19:32 +0000 Subject: [PATCH 003/174] Added link to VersionScheme. --- QubesDownloads.md | 1 + 1 file changed, 1 insertion(+) diff --git a/QubesDownloads.md b/QubesDownloads.md index 59b10726..0fd2bf58 100644 --- a/QubesDownloads.md +++ b/QubesDownloads.md @@ -9,6 +9,7 @@ Qubes Downloads =============== - [System Requirements](/doc/SystemRequirements/) +- [Version Scheme](/doc/VersionScheme/) - [Hardware Compatibility List](/hcl/) - [On Digital Signatures and How to Verify Qubes Downloads](/doc/VerifyingSignatures/) - [Installation Security Considerations](/doc/InstallSecurity/) From fb821292e467b946f3a861a73f1374781a1c5e9e Mon Sep 17 00:00:00 2001 From: Axon Date: Fri, 5 Jun 2015 23:30:36 +0000 Subject: [PATCH 004/174] Fixed code block indenting. --- SecurityPack.md | 210 +++++++++++++++++++++++------------------------- 1 file changed, 100 insertions(+), 110 deletions(-) diff --git a/SecurityPack.md b/SecurityPack.md index b759949f..a64e9447 100644 --- a/SecurityPack.md +++ b/SecurityPack.md @@ -123,91 +123,85 @@ its contents, and reading them. 1. Clone the QSP repo. - ``` - [user@qubes ~]$ git clone https://github.com/QubesOS/qubes-secpack.git - Cloning into 'qubes-secpack'... - remote: Counting objects: 195, done. - remote: Total 195 (delta 0), reused 0 (delta 0) - Receiving objects: 100% (195/195), 130.94 KiB | 207.00 KiB/s, done. - Resolving deltas: 100% (47/47), done. - Checking connectivity... done. - ``` + [user@qubes ~]$ git clone https://github.com/QubesOS/qubes-secpack.git + Cloning into 'qubes-secpack'... + remote: Counting objects: 195, done. + remote: Total 195 (delta 0), reused 0 (delta 0) + Receiving objects: 100% (195/195), 130.94 KiB | 207.00 KiB/s, done. + Resolving deltas: 100% (47/47), done. + Checking connectivity... done. 2. Import the included PGP keys. - ``` - [user@qubes ~]$ gpg --import qubes-secpack/keys/*/* - gpg: directory `/home/user/.gnupg' created - gpg: new configuration file `/home/user/.gnupg/gpg.conf' created - gpg: WARNING: options in `/home/user/.gnupg/gpg.conf' are not yet active during this run - gpg: keyring `/home/user/.gnupg/secring.gpg' created - gpg: keyring `/home/user/.gnupg/pubring.gpg' created - gpg: /home/user/.gnupg/trustdb.gpg: trustdb created - gpg: key C37BB66B: public key "Joanna Rutkowska (Qubes OS signing key) " imported - gpg: key 1E30A75D: public key "Joanna Rutkowska (Qubes OS signing key) " imported - gpg: key 74EADABC: public key "Joanna Rutkowska (Qubes OS signing key) " imported - gpg: key 65EF29CA: public key "Joanna Rutkowska (Qubes OS Signing Key) " imported - gpg: key 34898310: public key "Joanna Rutkowska (Qubes OS Signing Key) " imported - gpg: key B298547C: public key "Marek Marczykowski (Qubes OS signing key) " imported - gpg: key AB5EEF90: public key "Marek Marczykowski (Qubes OS signing key) " imported - gpg: key A603BCB6: public key "Marek Marczykowski (Qubes OS signing key) " imported - gpg: key 42CFA724: public key "Marek Marczykowski-G�recki (Qubes OS signing key) " imported - gpg: key 15CE40BF: public key "Wojciech Zygmunt Porczyk (Qubes OS signing key) " imported - gpg: key 36879494: public key "Qubes Master Signing Key" imported - gpg: key 211093A7: public key "Qubes OS Release 1 Signing Key" imported - gpg: key 0A40E458: public key "Qubes OS Release 2 Signing Key" imported - gpg: key 03FA5082: public key "Qubes OS Release 3 Signing Key" imported - gpg: key 92C7B3DC: public key "Joanna Rutkowska (Qubes Security Pack Signing Key) " imported - gpg: key 1830E06A: public key "Marek Marczykowski-G�recki (Qubes security pack) " imported - gpg: key 3F48CB21: public key "Qubes OS Security Team " imported - gpg: Total number processed: 17 - gpg: imported: 17 (RSA: 17) - gpg: no ultimately trusted keys found - ``` + [user@qubes ~]$ gpg --import qubes-secpack/keys/*/* + gpg: directory `/home/user/.gnupg' created + gpg: new configuration file `/home/user/.gnupg/gpg.conf' created + gpg: WARNING: options in `/home/user/.gnupg/gpg.conf' are not yet active during this run + gpg: keyring `/home/user/.gnupg/secring.gpg' created + gpg: keyring `/home/user/.gnupg/pubring.gpg' created + gpg: /home/user/.gnupg/trustdb.gpg: trustdb created + gpg: key C37BB66B: public key "Joanna Rutkowska (Qubes OS signing key) " imported + gpg: key 1E30A75D: public key "Joanna Rutkowska (Qubes OS signing key) " imported + gpg: key 74EADABC: public key "Joanna Rutkowska (Qubes OS signing key) " imported + gpg: key 65EF29CA: public key "Joanna Rutkowska (Qubes OS Signing Key) " imported + gpg: key 34898310: public key "Joanna Rutkowska (Qubes OS Signing Key) " imported + gpg: key B298547C: public key "Marek Marczykowski (Qubes OS signing key) " imported + gpg: key AB5EEF90: public key "Marek Marczykowski (Qubes OS signing key) " imported + gpg: key A603BCB6: public key "Marek Marczykowski (Qubes OS signing key) " imported + gpg: key 42CFA724: public key "Marek Marczykowski-G�recki (Qubes OS signing key) " imported + gpg: key 15CE40BF: public key "Wojciech Zygmunt Porczyk (Qubes OS signing key) " imported + gpg: key 36879494: public key "Qubes Master Signing Key" imported + gpg: key 211093A7: public key "Qubes OS Release 1 Signing Key" imported + gpg: key 0A40E458: public key "Qubes OS Release 2 Signing Key" imported + gpg: key 03FA5082: public key "Qubes OS Release 3 Signing Key" imported + gpg: key 92C7B3DC: public key "Joanna Rutkowska (Qubes Security Pack Signing Key) " imported + gpg: key 1830E06A: public key "Marek Marczykowski-G�recki (Qubes security pack) " imported + gpg: key 3F48CB21: public key "Qubes OS Security Team " imported + gpg: Total number processed: 17 + gpg: imported: 17 (RSA: 17) + gpg: no ultimately trusted keys found -3. Verify and trust the Qubes Master Signing Key. + 3. Verify and trust the Qubes Master Signing Key. - ``` - [user@qubes ~]$ gpg --edit-key 36879494 - gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc. - This is free software: you are free to change and redistribute it. - There is NO WARRANTY, to the extent permitted by law. - - - pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC - trust: unknown validity: unknown - [ unknown] (1). Qubes Master Signing Key - - gpg> fpr - pub 4096R/36879494 2010-04-01 Qubes Master Signing Key - Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494 - - gpg> trust - pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC - trust: unknown validity: unknown - [ unknown] (1). Qubes Master Signing Key - - Please decide how far you trust this user to correctly verify other users' keys - (by looking at passports, checking fingerprints from different sources, etc.) - - 1 = I don't know or won't say - 2 = I do NOT trust - 3 = I trust marginally - 4 = I trust fully - 5 = I trust ultimately - m = back to the main menu - - Your decision? 5 - Do you really want to set this key to ultimate trust? (y/N) y - - pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC - trust: ultimate validity: unknown - [ unknown] (1). Qubes Master Signing Key - Please note that the shown key validity is not necessarily correct - unless you restart the program. - - gpg> q - ``` + [user@qubes ~]$ gpg --edit-key 36879494 + gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc. + This is free software: you are free to change and redistribute it. + There is NO WARRANTY, to the extent permitted by law. + + + pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC + trust: unknown validity: unknown + [ unknown] (1). Qubes Master Signing Key + + gpg> fpr + pub 4096R/36879494 2010-04-01 Qubes Master Signing Key + Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494 + + gpg> trust + pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC + trust: unknown validity: unknown + [ unknown] (1). Qubes Master Signing Key + + Please decide how far you trust this user to correctly verify other users' keys + (by looking at passports, checking fingerprints from different sources, etc.) + + 1 = I don't know or won't say + 2 = I do NOT trust + 3 = I trust marginally + 4 = I trust fully + 5 = I trust ultimately + m = back to the main menu + + Your decision? 5 + Do you really want to set this key to ultimate trust? (y/N) y + + pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC + trust: ultimate validity: unknown + [ unknown] (1). Qubes Master Signing Key + Please note that the shown key validity is not necessarily correct + unless you restart the program. + + gpg> q **Important!** @@ -220,36 +214,32 @@ its contents, and reading them. 4. Verify and read the canaries. - ``` - [user@qubes ~]$ cd qubes-secpack/canaries/ - [user@qubes canaries]$ gpg --verify canary-001-2015.txt.sig.joanna canary-001-2015.txt - gpg: Signature made Mon Jan 5 20:21:40 2015 UTC using RSA key ID 92C7B3DC - gpg: Good signature from "Joanna Rutkowska (Qubes Security Pack Signing Key) " - [user@qubes canaries]$ gpg --verify canary-001-2015.txt.sig.marmarek canary-001-2015.txt - gpg: Signature made Mon Jan 5 20:13:37 2015 UTC using RSA key ID 1830E06A - gpg: Good signature from "Marek Marczykowski-G�recki (Qubes security pack) " - [user@qubes canaries]$ cat canary-001-2015.txt - - - ---===[ Qubes Canary #1 ]===--- - - [...] - ``` + [user@qubes ~]$ cd qubes-secpack/canaries/ + [user@qubes canaries]$ gpg --verify canary-001-2015.txt.sig.joanna canary-001-2015.txt + gpg: Signature made Mon Jan 5 20:21:40 2015 UTC using RSA key ID 92C7B3DC + gpg: Good signature from "Joanna Rutkowska (Qubes Security Pack Signing Key) " + [user@qubes canaries]$ gpg --verify canary-001-2015.txt.sig.marmarek canary-001-2015.txt + gpg: Signature made Mon Jan 5 20:13:37 2015 UTC using RSA key ID 1830E06A + gpg: Good signature from "Marek Marczykowski-G�recki (Qubes security pack) " + [user@qubes canaries]$ cat canary-001-2015.txt + + + ---===[ Qubes Canary #1 ]===--- + + [...] 5. Verify and read the QSBs. - ``` - [user@qubes canaries]$ cd ../QSBs/ - [user@qubes QSBs]$ gpg --verify qsb-013-2015.txt.sig.joanna qsb-013-2015.txt - gpg: Signature made Mon Jan 5 21:22:14 2015 UTC using RSA key ID 92C7B3DC - gpg: Good signature from "Joanna Rutkowska (Qubes Security Pack Signing Key) " - [user@qubes QSBs]$ gpg --verify qsb-013-2015.txt.sig.marmarek qsb-013-2015.txt - gpg: Signature made Mon Jan 5 21:38:11 2015 UTC using RSA key ID 1830E06A - gpg: Good signature from "Marek Marczykowski-G�recki (Qubes security pack) " - [user@qubes QSBs]$ cat qsb-013-2015.txt - - - ---===[ Qubes Security Bulletin #13 ]===--- - - [...] - ``` + [user@qubes canaries]$ cd ../QSBs/ + [user@qubes QSBs]$ gpg --verify qsb-013-2015.txt.sig.joanna qsb-013-2015.txt + gpg: Signature made Mon Jan 5 21:22:14 2015 UTC using RSA key ID 92C7B3DC + gpg: Good signature from "Joanna Rutkowska (Qubes Security Pack Signing Key) " + [user@qubes QSBs]$ gpg --verify qsb-013-2015.txt.sig.marmarek qsb-013-2015.txt + gpg: Signature made Mon Jan 5 21:38:11 2015 UTC using RSA key ID 1830E06A + gpg: Good signature from "Marek Marczykowski-G�recki (Qubes security pack) " + [user@qubes QSBs]$ cat qsb-013-2015.txt + + + ---===[ Qubes Security Bulletin #13 ]===--- + + [...] From 1d1e69b8ae2cbe501811261e331a5e7657b70226 Mon Sep 17 00:00:00 2001 From: Axon Date: Fri, 5 Jun 2015 23:35:29 +0000 Subject: [PATCH 005/174] Fixed more code block indenting. --- SecurityPack.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/SecurityPack.md b/SecurityPack.md index a64e9447..121f7f4c 100644 --- a/SecurityPack.md +++ b/SecurityPack.md @@ -167,40 +167,40 @@ its contents, and reading them. gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. - - + + pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). Qubes Master Signing Key - + gpg> fpr pub 4096R/36879494 2010-04-01 Qubes Master Signing Key Primary key fingerprint: 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494 - + gpg> trust pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC trust: unknown validity: unknown [ unknown] (1). Qubes Master Signing Key - + Please decide how far you trust this user to correctly verify other users' keys (by looking at passports, checking fingerprints from different sources, etc.) - + 1 = I don't know or won't say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu - + Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y - + pub 4096R/36879494 created: 2010-04-01 expires: never usage: SC trust: ultimate validity: unknown [ unknown] (1). Qubes Master Signing Key Please note that the shown key validity is not necessarily correct unless you restart the program. - + gpg> q **Important!** From 09fcb536c150af0208cfdf7b8b62607666bbe37e Mon Sep 17 00:00:00 2001 From: Axon Date: Fri, 5 Jun 2015 23:46:31 +0000 Subject: [PATCH 006/174] Fixed even more code block indenting. --- SecurityPack.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/SecurityPack.md b/SecurityPack.md index 121f7f4c..f11fd08a 100644 --- a/SecurityPack.md +++ b/SecurityPack.md @@ -202,9 +202,9 @@ its contents, and reading them. unless you restart the program. gpg> q - + **Important!** - + In order to verify the authenticity of the Qubes Master Signing Key prior to trusting it, you should obtain the Qubes Master Signing Key fingerprint from a trustworthy source (ideally, multiple sources) *other than* this website From 78ec3cf30ff9b7f2ba203b5839d467204796a734 Mon Sep 17 00:00:00 2001 From: Axon Date: Fri, 5 Jun 2015 23:50:35 +0000 Subject: [PATCH 007/174] Still trying to fix code block indenting! --- SecurityPack.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/SecurityPack.md b/SecurityPack.md index f11fd08a..ca55af57 100644 --- a/SecurityPack.md +++ b/SecurityPack.md @@ -161,7 +161,7 @@ its contents, and reading them. gpg: imported: 17 (RSA: 17) gpg: no ultimately trusted keys found - 3. Verify and trust the Qubes Master Signing Key. + 3. Verify and trust the Qubes Master Signing Key. [user@qubes ~]$ gpg --edit-key 36879494 gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc. @@ -202,7 +202,7 @@ its contents, and reading them. unless you restart the program. gpg> q - + **Important!** In order to verify the authenticity of the Qubes Master Signing Key prior to From 697d65d62316cf1cb6ad4478dad186085e424a90 Mon Sep 17 00:00:00 2001 From: Axon Date: Sat, 6 Jun 2015 00:42:30 +0000 Subject: [PATCH 008/174] Minor instruction fixes and style edits; major formatting cleanup. --- BackupEmergencyRestoreV3.md | 118 +++++++++++++++++++----------------- 1 file changed, 61 insertions(+), 57 deletions(-) diff --git a/BackupEmergencyRestoreV3.md b/BackupEmergencyRestoreV3.md index 52b3dd60..3618a36b 100644 --- a/BackupEmergencyRestoreV3.md +++ b/BackupEmergencyRestoreV3.md @@ -7,88 +7,92 @@ permalink: /doc/BackupEmergencyRestoreV3/ Emergency Backup Recovery without Qubes - format version 3 ========================================================== -This page describes how to perform emergency restore of backup created on Qubes R2 or later (which uses backup format 3). +This page describes how to perform an emergency restore of a backup created on Qubes R2 or later (which uses backup format version 3). The Qubes backup system has been designed with emergency disaster recovery in mind. No special Qubes-specific tools are required to access data backed up by Qubes. In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure. **Note:** In the following example, the backup file is assumed to be both encrypted and compressed. -1. Untar the main backup file. + 1. Untar the main backup file. - [user@restore ~]$ tar -i -xvf qubes-backup-2013-12-26-123456 - backup-header - backup-header.hmac - qubes.xml.000 - qubes.xml.000.hmac - vm1/private.img.000 - vm1/private.img.000.hmac - vm1/icon.png.000 - vm1/icon.png.000.hmac - vm1/firewall.xml.000 - vm1/firewall.xml.000.hmac - vm1/whitelisted-appmenus.list.000 - vm1/whitelisted-appmenus.list.000.hmac - dom0-home/dom0user.000 - dom0-home/dom0user.000.hmac + [user@restore ~]$ tar -i -xvf qubes-backup-2015-06-05T123456 + backup-header + backup-header.hmac + qubes.xml.000 + qubes.xml.000.hmac + vm1/private.img.000 + vm1/private.img.000.hmac + vm1/icon.png.000 + vm1/icon.png.000.hmac + vm1/firewall.xml.000 + vm1/firewall.xml.000.hmac + vm1/whitelisted-appmenus.list.000 + vm1/whitelisted-appmenus.list.000.hmac + dom0-home/dom0user.000 + dom0-home/dom0user.000.hmac -1. Verify the integrity of the `backup-header` file contains basic information about your backup. - [user@restore ~]$ cd vm1/ - [user@restore ~]$ openssl dgst -sha512 -hmac "your_passphrase" backup-header - HMAC-SHA512(backup-header)= 5b266783e116fe3b2601a54c249ca5f5f96d421dfe6828eeaeb2dcd014e9e945c27b3d7b0f952f5d55c927318906d9c360f387b0e1f069bb8195e96543e2969c - [user@restore ~]$ cat backup-header.hmac - (stdin)= 5b266783e116fe3b2601a54c249ca5f5f96d421dfe6828eeaeb2dcd014e9e945c27b3d7b0f952f5d55c927318906d9c360f387b0e1f069bb8195e96543e2969c + 2. Verify the integrity of the `backup-header` file, which contains basic information about your backup. - **Note:** The hash values should match. If they do not match, then the backup file may have been tampered with, or there may have been a storage error. + [user@restore ~]$ openssl dgst -sha512 -hmac "your_passphrase" backup-header + HMAC-SHA512(backup-header)= 5b266783e116fe3b2601a54c249ca5f5f96d421dfe6828eeaeb2dcd014e9e945c27b3d7b0f952f5d55c927318906d9c360f387b0e1f069bb8195e96543e2969c + [user@restore ~]$ cat backup-header.hmac + (stdin)= 5b266783e116fe3b2601a54c249ca5f5f96d421dfe6828eeaeb2dcd014e9e945c27b3d7b0f952f5d55c927318906d9c360f387b0e1f069bb8195e96543e2969c - **Note:** If your backup was hashed with a message digest algorithm other than `sha512`, you must substitute the correct message digest command. A complete list of supported message digest algorithms can be found with `openssl list-message-digest-algorithms`. + **Note:** The hash values should match. If they do not match, then the backup file may have been tampered with, or there may have been a storage error. -1. Read the `backup-header`. You'll need some of this information later. The file will look similar to this: - version=3 - hmac-algorithm=SHA512 - crypto-algorithm=aes-256-cbc - encrypted=True - compressed=True + **Note:** If your backup was hashed with a message digest algorithm other than `sha512`, you must substitute the correct message digest command. This information is contained in the `backup-header` file (see step 3), however it is not recommended to open this file until its integrity and authenticity has been verified (the current step). A complete list of supported message digest algorithms can be found with `openssl list-message-digest-algorithms`. + + 3. Read the `backup-header`. You'll need some of this information later. The file will look similar to this: + + [user@restore ~]$ cat backup-header + version=3 + hmac-algorithm=SHA512 + crypto-algorithm=aes-256-cbc + encrypted=True + compressed=True + compression-filter=gzip - If you see `version=2` here, go to [Emergency Backup Recovery - format version 2](/doc/BackupEmergencyRestoreV2/) page instead. + **Note:** If you see `version=2` here, go to [Emergency Backup Recovery - format version 2](/doc/BackupEmergencyRestoreV2/) instead. -1. Verify the integrity of the `private.img` file which houses your data. + 4. Verify the integrity of the `private.img` file which houses your data. - [user@restore ~]$ cd vm1/ - [user@restore vm1]$ openssl dgst -sha512 -hmac "your_passphrase" private.img.000 - HMAC-SHA512(private.img.000)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e - [user@restore vm1]$ cat private.img.000.hmac - (stdin)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e + [user@restore ~]$ cd vm1/ + [user@restore vm1]$ openssl dgst -sha512 -hmac "your_passphrase" private.img.000 + HMAC-SHA512(private.img.000)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e + [user@restore vm1]$ cat private.img.000.hmac + (stdin)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e - **Note:** The hash values should match. If they do not match, then the backup file may have been tampered with, or there may have been a storage error. + **Note:** The hash values should match. If they do not match, then the backup file may have been tampered with, or there may have been a storage error. - **Note:** If your backup was hashed with a message digest algorithm other than `sha512`, you must substitute the correct message digest command. A complete list of supported message digest algorithms can be found with `openssl list-message-digest-algorithms`. You can check `backup-header` file for the hash used to create the backup. + **Note:** If your backup was hashed with a message digest algorithm other than `sha512`, you must substitute the correct message digest command. This information is contained in the `backup-header` file (see step 3). A complete list of supported message digest algorithms can be found with `openssl list-message-digest-algorithms`. -1. Decrypt the `private.img` file. + 5. Decrypt the `private.img` file. - cat private.img.??? | openssl enc -d -pass pass:your_passphrase -aes-256-cbc -out private.img.dec + cat private.img.??? | openssl enc -d -pass pass:your_passphrase -aes-256-cbc -out private.img.dec - **Note:** If your backup was encrypted with a cipher algorithm other than `aes-256-cbc`, you must substitute the correct cipher command. A complete list of supported cipher algorithms can be found with `openssl list-cipher-algorithms`. You can check `backup-header` file to get that information. + **Note:** If your backup was encrypted with a cipher algorithm other than `aes-256-cbc`, you must substitute the correct cipher command. This information is contained in the `backup-header` file (see step 3). A complete list of supported cipher algorithms can be found with `openssl list-cipher-algorithms`. -1. Decompress the decrypted `private.img` file. + 6. Decompress the decrypted `private.img` file. - [user@restore vm1]$ zforce private.img.dec - [user@restore vm1]$ gunzip private.img.dec.gz + [user@restore vm1]$ zforce private.img.dec + private.img.dec -- replaced with private.img.dec.gz + [user@restore vm1]$ gunzip private.img.dec.gz - **Note:** If your backup was compressed with a program other than `gzip`, you must substitute the correct compression program. `backup-header` file contains name of program used to compress the data. + **Note:** If your backup was compressed with a program other than `gzip`, you must substitute the correct compression program. This information is contained in the `backup-header` file (see step 3). -1. Untar the decrypted and decompressed `private.img` file. + 7. Untar the decrypted and decompressed `private.img` file. - [user@restore vm1]$ tar -xvf private.img.dec - vm1/private.img + [user@restore vm1]$ tar -xvf private.img.dec + vm1/private.img -1. Mount the private.img file and access your data. + 8. Mount the private.img file and access your data. - [user@restore vm1]$ sudo mkdir /mnt/img - [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/ - [user@restore vm1]$ cat /mnt/img/home/user/your_data.txt - This data has been successfully recovered! + [user@restore vm1]$ sudo mkdir /mnt/img + [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/ + [user@restore vm1]$ cat /mnt/img/home/user/your_data.txt + This data has been successfully recovered! - **Note:** You may wish to store a plain text copy of these instructions with your Qubes backups in the event that you fail to recall the above procedure while this web page is inaccessible. You may obtain a plaintext version of this file in Git repository housing all the documentation at: + **Note:** You may wish to store a copy of these instructions with your Qubes backups in the event that you fail to recall the above procedure while this web page is inaccessible. All Qubes documentation, including this page, is available in plain text format in the following Git repository: - https://github.com/QubesOS/qubes-doc.git + https://github.com/QubesOS/qubes-doc.git From 0150ac08ccfa1c1ba818d0956be13ae7c5cc2a4f Mon Sep 17 00:00:00 2001 From: Axon Date: Sat, 6 Jun 2015 01:02:11 +0000 Subject: [PATCH 009/174] Minor cleanup. --- BackupEmergencyRestoreV3.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/BackupEmergencyRestoreV3.md b/BackupEmergencyRestoreV3.md index 3618a36b..9cd60345 100644 --- a/BackupEmergencyRestoreV3.md +++ b/BackupEmergencyRestoreV3.md @@ -11,7 +11,7 @@ This page describes how to perform an emergency restore of a backup created on Q The Qubes backup system has been designed with emergency disaster recovery in mind. No special Qubes-specific tools are required to access data backed up by Qubes. In the event a Qubes system is unavailable, you can access your data on any GNU/Linux system with the following procedure. -**Note:** In the following example, the backup file is assumed to be both encrypted and compressed. +**Note:** In the following example, the backup file is both *encrypted* and *compressed*. 1. Untar the main backup file. @@ -68,7 +68,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi 5. Decrypt the `private.img` file. - cat private.img.??? | openssl enc -d -pass pass:your_passphrase -aes-256-cbc -out private.img.dec + [user@restore vm1]$ cat private.img.??? | openssl enc -d -pass pass:your_passphrase -aes-256-cbc -out private.img.dec **Note:** If your backup was encrypted with a cipher algorithm other than `aes-256-cbc`, you must substitute the correct cipher command. This information is contained in the `backup-header` file (see step 3). A complete list of supported cipher algorithms can be found with `openssl list-cipher-algorithms`. @@ -92,6 +92,8 @@ The Qubes backup system has been designed with emergency disaster recovery in mi [user@restore vm1]$ cat /mnt/img/home/user/your_data.txt This data has been successfully recovered! + 9. Success! If you wish to recover data from more than one VM in your backup, simply repeat steps 4--8 for each additional VM. + **Note:** You may wish to store a copy of these instructions with your Qubes backups in the event that you fail to recall the above procedure while this web page is inaccessible. All Qubes documentation, including this page, is available in plain text format in the following Git repository: https://github.com/QubesOS/qubes-doc.git From 8afb9073b2ba16a5586ceb2766f2f91178775b25 Mon Sep 17 00:00:00 2001 From: Axon Date: Fri, 12 Jun 2015 16:30:08 +0000 Subject: [PATCH 010/174] Add FedoraTemplateUpgrade link to main index --- UserDoc.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/UserDoc.md b/UserDoc.md index 3e5417ab..c4e96cef 100644 --- a/UserDoc.md +++ b/UserDoc.md @@ -53,9 +53,10 @@ Qubes User Documentation 5. **[TemplateVMs](/doc/Templates/)** 1. [Updating and Installing Software in VMs](/doc/SoftwareUpdateVM/) - 2. [Templates: Fedora - minimal](/doc/Templates/FedoraMinimal/) - 3. [Templates: Debian](/doc/Templates/Debian/) - 4. External Links + 2. [Upgrading the Fedora Template](/doc/FedoraTemplateUpgrade/) + 3. [Templates: Fedora - minimal](/doc/Templates/FedoraMinimal/) + 4. [Templates: Debian](/doc/Templates/Debian/) + 5. External Links 1. [Extending \`root.img\` Size](https://groups.google.com/group/qubes-devel/msg/9d1ac581236ca9b4) 6. **DispVMs** From a60aafc111108fb2904715763abaf4fab8723174 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Thu, 18 Jun 2015 16:08:42 +0200 Subject: [PATCH 011/174] YubiKey: add qvm-run --nogui option to make it usable for lightdm login --- YubiKey.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/YubiKey.md b/YubiKey.md index 8b11cef2..611b6f18 100644 --- a/YubiKey.md +++ b/YubiKey.md @@ -63,7 +63,7 @@ To use this mode you need: challenge=`head -c64 /dev/urandom | xxd -c 64 -ps` # You may need to adjust slot number and USB VM name here - response=`qvm-run -p sys-usb "ykchalresp -2 -x $challenge"` + response=`qvm-run --nogui -p sys-usb "ykchalresp -2 -x $challenge"` correct_response=`echo $challenge | xxd -r -ps | openssl dgst -sha1 -macopt hexkey:$key -mac HMAC -r | cut -f1 -d ' '` From ee09e47249228073d653ec3e31a0183fe6c9bf78 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Fri, 19 Jun 2015 09:07:09 +0200 Subject: [PATCH 012/174] YubiKey: one more fix for lightdm Use root because user is not given access to the device before local X session is started (which is done in VM after dom0 user logs in). --- YubiKey.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/YubiKey.md b/YubiKey.md index 611b6f18..62ac3e0f 100644 --- a/YubiKey.md +++ b/YubiKey.md @@ -63,7 +63,7 @@ To use this mode you need: challenge=`head -c64 /dev/urandom | xxd -c 64 -ps` # You may need to adjust slot number and USB VM name here - response=`qvm-run --nogui -p sys-usb "ykchalresp -2 -x $challenge"` + response=`qvm-run -u root --nogui -p sys-usb "ykchalresp -2 -x $challenge"` correct_response=`echo $challenge | xxd -r -ps | openssl dgst -sha1 -macopt hexkey:$key -mac HMAC -r | cut -f1 -d ' '` From e676bae91c68735594533e8e57e165d611026ba7 Mon Sep 17 00:00:00 2001 From: Axon Date: Sat, 20 Jun 2015 14:20:28 +0000 Subject: [PATCH 013/174] Index: split Fedora TemplateVM upgrade pages Split the previous Fedora TemplateVM upgrade page into multiple pages by distro: one for Fedora 18->20 and one for Fedora 20->21. --- FedoraTemplateUpgrade.md => FedoraTemplateUpgrade18.md | 2 +- FedoraTemplateUpgrade20.md | 0 2 files changed, 1 insertion(+), 1 deletion(-) rename FedoraTemplateUpgrade.md => FedoraTemplateUpgrade18.md (98%) create mode 100644 FedoraTemplateUpgrade20.md diff --git a/FedoraTemplateUpgrade.md b/FedoraTemplateUpgrade18.md similarity index 98% rename from FedoraTemplateUpgrade.md rename to FedoraTemplateUpgrade18.md index 527d12e9..b97c9a41 100644 --- a/FedoraTemplateUpgrade.md +++ b/FedoraTemplateUpgrade18.md @@ -1,7 +1,7 @@ --- layout: doc title: FedoraTemplateUpgrade -permalink: /doc/FedoraTemplateUpgrade/ +permalink: /doc/FedoraTemplateUpgrade18/ redirect_from: /wiki/FedoraTemplateUpgrade/ --- diff --git a/FedoraTemplateUpgrade20.md b/FedoraTemplateUpgrade20.md new file mode 100644 index 00000000..e69de29b From 9da6088617ced14ed8314659b14320228fa23c46 Mon Sep 17 00:00:00 2001 From: Axon Date: Sat, 20 Jun 2015 14:22:23 +0000 Subject: [PATCH 014/174] Index: create entries for new pages --- UserDoc.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/UserDoc.md b/UserDoc.md index c4e96cef..3b754dad 100644 --- a/UserDoc.md +++ b/UserDoc.md @@ -53,10 +53,11 @@ Qubes User Documentation 5. **[TemplateVMs](/doc/Templates/)** 1. [Updating and Installing Software in VMs](/doc/SoftwareUpdateVM/) - 2. [Upgrading the Fedora Template](/doc/FedoraTemplateUpgrade/) - 3. [Templates: Fedora - minimal](/doc/Templates/FedoraMinimal/) - 4. [Templates: Debian](/doc/Templates/Debian/) - 5. External Links + 2. [Upgrading the Fedora 18 Template](/doc/FedoraTemplateUpgrade18/) + 3. [Upgrading the Fedora 20 Template](/doc/FedoraTemplateUpgrade20/) + 4. [Templates: Fedora - minimal](/doc/Templates/FedoraMinimal/) + 5. [Templates: Debian](/doc/Templates/Debian/) + 6. External Links 1. [Extending \`root.img\` Size](https://groups.google.com/group/qubes-devel/msg/9d1ac581236ca9b4) 6. **DispVMs** From 2da094cc7367e82257949d6513fe56271b1f065e Mon Sep 17 00:00:00 2001 From: Axon Date: Sat, 20 Jun 2015 14:23:35 +0000 Subject: [PATCH 015/174] FedoraTemplateUpgrade20: add new instructions --- FedoraTemplateUpgrade20.md | 106 +++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) diff --git a/FedoraTemplateUpgrade20.md b/FedoraTemplateUpgrade20.md index e69de29b..1f78a5d7 100644 --- a/FedoraTemplateUpgrade20.md +++ b/FedoraTemplateUpgrade20.md @@ -0,0 +1,106 @@ +--- +layout: doc +title: FedoraTemplateUpgrade +permalink: /doc/FedoraTemplateUpgrade20/ +redirect_from: /wiki/FedoraTemplateUpgrade20/ +--- + +How to Upgrade Fedora Templates +=============================== + +Upgrading the Standard Fedora 20 Template to Fedora 21 +------------------------------------------------------ + +These instructions will show you how to upgrade the standard Fedora 20 +TemplateVM to Fedora 21. The same general procedure may be used to upgrade any +template based on the standard Fedora 20 template. + + 1. Clone the existing template and start a terminal in the new template. + + [user@dom0 ~] qvm-clone fedora-20-x64 fedora-21 + [user@dom0 ~] qvm-run -a fedora-21 gnome-terminal + + 2. Attempt the upgrade process in the new template. + + [user@fedora-21 ~] sudo yum erase nautilus-actions libcacard + [user@fedora-21 ~] sudo yum clean all + [user@fedora-21 ~] sudo yum --releasever=21 distro-sync + [user@fedora-21 ~] sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ + [user@fedora-21 ~] poweroff + + If you encounter no errors, proceed to step 5. + + 3. If `yum` reports that you do not have enough free disk space to proceed with + the upgrade process, create an empty file in dom0 to use as a cache and + attach it to the template as a virtual disk. + + [user@dom0 ~] truncate -s 5GB /var/tmp/template-upgrade-cache.img + [user@dom0 ~] qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img + + Then reattempt the upgrade process, but this time using the virtual disk as + a cache. + + [user@fedora-21 ~] sudo mkfs.ext4 /dev/xvdi + [user@fedora-21 ~] sudo mount /dev/xvdi /mnt/removable + [user@fedora-21 ~] sudo yum erase nautilus-actions libcacard + [user@fedora-21 ~] sudo yum clean all + [user@fedora-21 ~] sudo yum --releasever=21 --setopt=cachedir=/mnt/removable distro-sync + [user@fedora-21 ~] sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ + [user@fedora-21 ~] poweroff + + 4. If `yum` complains that there is not enough free space in `/usr/lib/modules`, + do this before reattempting the upgrade: + + [user@fedora-21 ~] sudo mkdir /mnt/removable/modules + [user@fedora-21 ~] sudo cp -rp /usr/lib/modules /mnt/removable/modules + [user@fedora-21 ~] sudo mount --bind /mnt/removable/modules /usr/lib/modules + + 5. After the upgrade process is finished, remove the cache file you created. + + [user@dom0 ~] rm /var/tmp/template-upgrade-cache.img + + 6. Ensure your new template is fully updated. + + [user@dom0 ~] qvm-run -a fedora-21 gnome-terminal + [user@fedora-21 ~] sudo yum update + +Upgrading the Minimal Fedora 20 Template to Fedora 21 +----------------------------------------------------- + +The procedure for upgrading the minimal template (or any template based on the +minimal template) is the same as the procedure for the standard template above, +**except with the following command ommitted**: + + [user@fedora-21-minimal ~] sudo yum erase nautilus-actions libcacard + +Compacting the Upgraded Template +================================ + +Neither `fstrim` nor the `discard` mount option works on the TemplateVM's root +filesystem, so when a file is removed in the template, space is not freed in +dom0. This means that the template will use about twice as much space as is +really necessary after upgrading. + +If you have at least `qubes-core-dom0-2.1.68` installed and are on Qubes R2, +you can use the `qvm-trim-template` tool: + + [user@dom0 ~] qvm-trim-template fedora-21 + +If you do not have `qubes-core-dom0-2.1.68` or are on Qubes R3-rc1, you can +compact the `root.img` manually. To do this, you will need about 15GB (the +TemplateVM's max size + the actually used space there) free space in dom0. + + 1. Start the template and fill all the free space with zeros, for example + with: + + [user@fedora-21 ~] dd if=/dev/zero of=/var/tmp/zero + + 2. Wait for the "No space left on device" error. Then: + + [user@fedora-21 ~] rm -f /var/tmp/zero + + 3. Shut down the template and all VMs based on it. Then: + + [user@dom0 ~] cd /var/lib/qubes/vm-templates/fedora-21 + [user@dom0 ~] cp --sparse=always root.img root.img.new + [user@dom0 ~] mv root.img.new root.img From 3b8bbb8419227317681a17a6af0b8b56cafe252d Mon Sep 17 00:00:00 2001 From: Axon Date: Sat, 20 Jun 2015 14:45:30 +0000 Subject: [PATCH 016/174] FedoraTemplateUpgrade18: add pointer to newer page --- FedoraTemplateUpgrade18.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/FedoraTemplateUpgrade18.md b/FedoraTemplateUpgrade18.md index b97c9a41..f15d521e 100644 --- a/FedoraTemplateUpgrade18.md +++ b/FedoraTemplateUpgrade18.md @@ -8,6 +8,8 @@ redirect_from: /wiki/FedoraTemplateUpgrade/ Upgrade of Fedora template ========================== +(**Note:** There is a [newer version of this page for upgrading from Fedora 20 to Fedora 21](/doc/FedoraTemplateUpgrade20/).) + This instruction in simplified version of [official Fedora instruction](https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum). Note that only "yum" method will work in Qubes template VM (if you are curious why: mostly because template VM does not have own bootloader). Upgrading Fedora 18 to Fedora 20 From 8b44e134181f832b28a2d93751c2648553740c5b Mon Sep 17 00:00:00 2001 From: Axon Date: Tue, 23 Jun 2015 10:40:25 +0000 Subject: [PATCH 017/174] FedoraTemplateUpgrade20: Improve instructions * Revise imprecise parts of instructions * Add summaries of instructions * Add section on known issues --- FedoraTemplateUpgrade20.md | 130 ++++++++++++++++++++++++++++++------- 1 file changed, 105 insertions(+), 25 deletions(-) diff --git a/FedoraTemplateUpgrade20.md b/FedoraTemplateUpgrade20.md index 1f78a5d7..77b0630e 100644 --- a/FedoraTemplateUpgrade20.md +++ b/FedoraTemplateUpgrade20.md @@ -17,61 +17,114 @@ template based on the standard Fedora 20 template. 1. Clone the existing template and start a terminal in the new template. - [user@dom0 ~] qvm-clone fedora-20-x64 fedora-21 - [user@dom0 ~] qvm-run -a fedora-21 gnome-terminal + [user@dom0 ~]$ qvm-clone fedora-20-x64 fedora-21 + [user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal 2. Attempt the upgrade process in the new template. - [user@fedora-21 ~] sudo yum erase nautilus-actions libcacard - [user@fedora-21 ~] sudo yum clean all - [user@fedora-21 ~] sudo yum --releasever=21 distro-sync - [user@fedora-21 ~] sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ - [user@fedora-21 ~] poweroff + [user@fedora-21 ~]$ sudo yum erase nautilus-actions libcacard + [user@fedora-21 ~]$ sudo yum clean all + [user@fedora-21 ~]$ sudo yum --releasever=21 distro-sync + [user@fedora-21 ~]$ sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ - If you encounter no errors, proceed to step 5. + (Poweroff via Qubes VM Manager. May need to be killed.) + + If you encounter no errors, proceed to step 6. 3. If `yum` reports that you do not have enough free disk space to proceed with the upgrade process, create an empty file in dom0 to use as a cache and attach it to the template as a virtual disk. - [user@dom0 ~] truncate -s 5GB /var/tmp/template-upgrade-cache.img - [user@dom0 ~] qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img + [user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img + [user@dom0 ~]$ qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img Then reattempt the upgrade process, but this time using the virtual disk as a cache. - [user@fedora-21 ~] sudo mkfs.ext4 /dev/xvdi - [user@fedora-21 ~] sudo mount /dev/xvdi /mnt/removable - [user@fedora-21 ~] sudo yum erase nautilus-actions libcacard - [user@fedora-21 ~] sudo yum clean all - [user@fedora-21 ~] sudo yum --releasever=21 --setopt=cachedir=/mnt/removable distro-sync - [user@fedora-21 ~] sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ - [user@fedora-21 ~] poweroff + [user@fedora-21 ~]$ sudo mkfs.ext4 /dev/xvdi + [user@fedora-21 ~]$ sudo mount /dev/xvdi /mnt/removable + [user@fedora-21 ~]$ sudo yum erase nautilus-actions libcacard + [user@fedora-21 ~]$ sudo yum clean all + [user@fedora-21 ~]$ sudo yum --releasever=21 --setopt=cachedir=/mnt/removable distro-sync + [user@fedora-21 ~]$ sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ + + (Poweroff via Qubes VM Manager. May need to be killed.) 4. If `yum` complains that there is not enough free space in `/usr/lib/modules`, do this before reattempting the upgrade: - [user@fedora-21 ~] sudo mkdir /mnt/removable/modules - [user@fedora-21 ~] sudo cp -rp /usr/lib/modules /mnt/removable/modules - [user@fedora-21 ~] sudo mount --bind /mnt/removable/modules /usr/lib/modules + [user@fedora-21 ~]$ sudo mkdir /mnt/removable/modules + [user@fedora-21 ~]$ sudo cp -rp /usr/lib/modules /mnt/removable/modules + [user@fedora-21 ~]$ sudo mount --bind /mnt/removable/modules /usr/lib/modules 5. After the upgrade process is finished, remove the cache file you created. - [user@dom0 ~] rm /var/tmp/template-upgrade-cache.img + [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img 6. Ensure your new template is fully updated. - [user@dom0 ~] qvm-run -a fedora-21 gnome-terminal - [user@fedora-21 ~] sudo yum update + [user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal + [user@fedora-21 ~]$ sudo yum -y update + + +Summary of Full Procedure (Full) +-------------------------------- + + [user@dom0 ~]$ qvm-clone fedora-20-x64 fedora-21 + [user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img + [user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal + [user@dom0 ~]$ qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img + [user@fedora-21 ~]$ sudo mkfs.ext4 /dev/xvdi + [user@fedora-21 ~]$ sudo mount /dev/xvdi /mnt/removable + [user@fedora-21 ~]$ sudo mkdir /mnt/removable/modules + [user@fedora-21 ~]$ sudo cp -rp /usr/lib/modules /mnt/removable/modules + [user@fedora-21 ~]$ sudo mount --bind /mnt/removable/modules /usr/lib/modules + [user@fedora-21 ~]$ sudo yum erase nautilus-actions libcacard + [user@fedora-21 ~]$ sudo yum clean all + [user@fedora-21 ~]$ sudo yum --releasever=21 --setopt=cachedir=/mnt/removable distro-sync + [user@fedora-21 ~]$ sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ + + (Poweroff via Qubes VM Manager. May need to be killed.) + + [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img + [user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal + [user@fedora-21 ~]$ sudo yum -y update + Upgrading the Minimal Fedora 20 Template to Fedora 21 ----------------------------------------------------- The procedure for upgrading the minimal template (or any template based on the minimal template) is the same as the procedure for the standard template above, -**except with the following command ommitted**: +**with the following exceptions**: + + 1. `gnome-terminal` is not installed by default. Unless you installed it (or + another terminal emulator), use `xterm`. + 2. `nautilus-actions` and `libcacard` are not installed by default, so do not + try to erase them (unless you installed them). + 3. `sudo` is not installed by default, so use `su` unless you've installed the + former. + + +Summary of Full Procedure (Minimal) +----------------------------------- + + [user@dom0 ~]$ qvm-clone fedora-20-x64-minimal fedora-21-minimal + [user@dom0 ~]$ qvm-run -a fedora-21-minimal xterm + [user@fedora-21-minimal ~]$ su - + [root@fedora-21-minimal ~]# yum clean all + [user@fedora-21-minimal ~]# yum --releasever=21 distro-sync + [user@fedora-21-minimal ~]# cp /usr/lib/qubes/init/ip* /etc/sysconfig/ + + (Poweroff via Qubes VM Manager. May need to be killed.) + + [user@dom0 ~]$ qvm-run -a fedora-21-minimal xterm + [user@fedora-21-minimal ~]$ su - + [root@fedora-21-minimal ~]# yum -y update + +(If you encounter insufficient space issues, you may need to use the methods +described for the standard template above.) - [user@fedora-21-minimal ~] sudo yum erase nautilus-actions libcacard Compacting the Upgraded Template ================================ @@ -104,3 +157,30 @@ TemplateVM's max size + the actually used space there) free space in dom0. [user@dom0 ~] cd /var/lib/qubes/vm-templates/fedora-21 [user@dom0 ~] cp --sparse=always root.img root.img.new [user@dom0 ~] mv root.img.new root.img + + +Known Issues +============ + +You may encounter the following `yum` error: + + At least X MB more space needed on the / filesystem. + +In this case, you have a few options: + + 1. Delete files in order to free up space. One way to do this is by + uninstalling packages (and then reinstalling them again after you finish + the upgrade process, if desired). + 2. Increase the `root.img` size. It should be easy to extend the + `qvm-grow-root` tool in order to support PV (and not only HVM) VMs. + However, someone would need to do this (patches welcome). + 3. Do the upgrade in parts, e.g., by using package groups. (First upgrade + `@core` packages, then the rest.) + 4. Do not perform an in-place upgrade. Instead, simply download and install a + new template package, then redo all desired template modifications. + +Here are some useful messages from the mailing list in regard to the last +option: + + * [Marek](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/dS1jbLRP9n8J) + * [Jason M](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/5PxDfI-RKAsJ) From ca6b0999709e9c0fdb5c7b3ff5233ae75d4ed625 Mon Sep 17 00:00:00 2001 From: Axon Date: Tue, 23 Jun 2015 13:47:27 +0000 Subject: [PATCH 018/174] FedoraTemplateUpgrade20: Improve instructions * Add option to resize disk image * Make language clearer * Various minor improvements --- FedoraTemplateUpgrade20.md | 160 +++++++++++++++++++++---------------- 1 file changed, 93 insertions(+), 67 deletions(-) diff --git a/FedoraTemplateUpgrade20.md b/FedoraTemplateUpgrade20.md index 77b0630e..e12061bb 100644 --- a/FedoraTemplateUpgrade20.md +++ b/FedoraTemplateUpgrade20.md @@ -8,8 +8,35 @@ redirect_from: /wiki/FedoraTemplateUpgrade20/ How to Upgrade Fedora Templates =============================== -Upgrading the Standard Fedora 20 Template to Fedora 21 ------------------------------------------------------- +Summary: Upgrading the Standard Fedora 20 Template to Fedora 21 +--------------------------------------------------------------- + + [user@dom0 ~]$ qvm-clone fedora-20-x64 fedora-21 + [user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img + [user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal + [user@dom0 ~]$ qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img + [user@fedora-21 ~]$ sudo mkfs.ext4 /dev/xvdi + [user@fedora-21 ~]$ sudo mount /dev/xvdi /mnt/removable + [user@fedora-21 ~]$ sudo mkdir /mnt/removable/modules + [user@fedora-21 ~]$ sudo cp -rp /usr/lib/modules /mnt/removable/modules + [user@fedora-21 ~]$ sudo mount --bind /mnt/removable/modules /usr/lib/modules + [user@fedora-21 ~]$ sudo yum erase nautilus-actions libcacard + [user@fedora-21 ~]$ sudo yum clean all + [user@fedora-21 ~]$ sudo yum --releasever=21 --setopt=cachedir=/mnt/removable distro-sync + [user@fedora-21 ~]$ sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ + + (Shut down TemplateVM via Qubes VM Manager; may need to be killed.) + + [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img + [user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal + [user@fedora-21 ~]$ sudo yum -y update + + (Shut down TemplateVM by any normal means.) + + [user@dom0 ~]$ qvm-trim-template fedora-21 + +Detailed: Upgrading the Standard Fedora 20 Template to Fedora 21 +---------------------------------------------------------------- These instructions will show you how to upgrade the standard Fedora 20 TemplateVM to Fedora 21. The same general procedure may be used to upgrade any @@ -27,9 +54,9 @@ template based on the standard Fedora 20 template. [user@fedora-21 ~]$ sudo yum --releasever=21 distro-sync [user@fedora-21 ~]$ sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ - (Poweroff via Qubes VM Manager. May need to be killed.) + (Shut down TemplateVM via Qubes VM Manager; may need to be killed.) - If you encounter no errors, proceed to step 6. + If you encounter no errors, proceed to step 7. 3. If `yum` reports that you do not have enough free disk space to proceed with the upgrade process, create an empty file in dom0 to use as a cache and @@ -57,57 +84,32 @@ template based on the standard Fedora 20 template. [user@fedora-21 ~]$ sudo cp -rp /usr/lib/modules /mnt/removable/modules [user@fedora-21 ~]$ sudo mount --bind /mnt/removable/modules /usr/lib/modules - 5. After the upgrade process is finished, remove the cache file you created. + 5. `yum` may complain: + + At least X MB more space needed on the / filesystem. + + In this case, one option is to [resize the TemplateVM's disk + image](/doc/ResizeDiskImage/) before reattempting the upgrade process. + (See **Additional Information** below for other options.) + + 6. After the upgrade process is finished, remove the cache file, if you + created one. [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img - 6. Ensure your new template is fully updated. + 7. Ensure your new template is fully updated. [user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal [user@fedora-21 ~]$ sudo yum -y update + 8. Trim the new template (see **Compacting the Upgraded Template** for details + and other options). -Summary of Full Procedure (Full) --------------------------------- - - [user@dom0 ~]$ qvm-clone fedora-20-x64 fedora-21 - [user@dom0 ~]$ truncate -s 5GB /var/tmp/template-upgrade-cache.img - [user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal - [user@dom0 ~]$ qvm-block -A fedora-21 dom0:/var/tmp/template-upgrade-cache.img - [user@fedora-21 ~]$ sudo mkfs.ext4 /dev/xvdi - [user@fedora-21 ~]$ sudo mount /dev/xvdi /mnt/removable - [user@fedora-21 ~]$ sudo mkdir /mnt/removable/modules - [user@fedora-21 ~]$ sudo cp -rp /usr/lib/modules /mnt/removable/modules - [user@fedora-21 ~]$ sudo mount --bind /mnt/removable/modules /usr/lib/modules - [user@fedora-21 ~]$ sudo yum erase nautilus-actions libcacard - [user@fedora-21 ~]$ sudo yum clean all - [user@fedora-21 ~]$ sudo yum --releasever=21 --setopt=cachedir=/mnt/removable distro-sync - [user@fedora-21 ~]$ sudo cp /usr/lib/qubes/init/ip* /etc/sysconfig/ - - (Poweroff via Qubes VM Manager. May need to be killed.) - - [user@dom0 ~]$ rm /var/tmp/template-upgrade-cache.img - [user@dom0 ~]$ qvm-run -a fedora-21 gnome-terminal - [user@fedora-21 ~]$ sudo yum -y update + [user@dom0 ~]$ qvm-trim-template fedora-21 -Upgrading the Minimal Fedora 20 Template to Fedora 21 ------------------------------------------------------ - -The procedure for upgrading the minimal template (or any template based on the -minimal template) is the same as the procedure for the standard template above, -**with the following exceptions**: - - 1. `gnome-terminal` is not installed by default. Unless you installed it (or - another terminal emulator), use `xterm`. - 2. `nautilus-actions` and `libcacard` are not installed by default, so do not - try to erase them (unless you installed them). - 3. `sudo` is not installed by default, so use `su` unless you've installed the - former. - - -Summary of Full Procedure (Minimal) ------------------------------------ +Summary: Upgrading the Minimal Fedora 20 Template to Fedora 21 +-------------------------------------------------------------- [user@dom0 ~]$ qvm-clone fedora-20-x64-minimal fedora-21-minimal [user@dom0 ~]$ qvm-run -a fedora-21-minimal xterm @@ -116,16 +118,37 @@ Summary of Full Procedure (Minimal) [user@fedora-21-minimal ~]# yum --releasever=21 distro-sync [user@fedora-21-minimal ~]# cp /usr/lib/qubes/init/ip* /etc/sysconfig/ - (Poweroff via Qubes VM Manager. May need to be killed.) + (Shut down the TemplateVM via Qubes VM Manager. May need to be killed.) [user@dom0 ~]$ qvm-run -a fedora-21-minimal xterm [user@fedora-21-minimal ~]$ su - - [root@fedora-21-minimal ~]# yum -y update + [root@fedora-21-minimal ~]# yum -y update + + (Shut down TemplateVM by any normal means.) + + [user@dom0 ~]$ qvm-trim-template fedora-21-minimal (If you encounter insufficient space issues, you may need to use the methods described for the standard template above.) +Differences Between the Standard and Minimal Upgrade Procedures +--------------------------------------------------------------- + +The procedure for upgrading the minimal template (or any template based on the +minimal template) is the same as the procedure for the standard template above, +**with the following exceptions**: + + 1. `gnome-terminal` is not installed by default. Unless you've installed it + (or another terminal emulator), use `xterm`. (Of course, you can also use + `xterm` for the standard template, if you prefer.) + 2. `nautilus-actions` and `libcacard` are not installed by default, so do not + try to erase them (unless you've installed them). + 3. `sudo` is not installed by default. Unless you've installed it, use `su` as + demonstrated above. (Of course, you can also use `su` for the standard + template, if you prefer.) + + Compacting the Upgraded Template ================================ @@ -137,7 +160,7 @@ really necessary after upgrading. If you have at least `qubes-core-dom0-2.1.68` installed and are on Qubes R2, you can use the `qvm-trim-template` tool: - [user@dom0 ~] qvm-trim-template fedora-21 + [user@dom0 ~]$ qvm-trim-template fedora-21 If you do not have `qubes-core-dom0-2.1.68` or are on Qubes R3-rc1, you can compact the `root.img` manually. To do this, you will need about 15GB (the @@ -146,41 +169,44 @@ TemplateVM's max size + the actually used space there) free space in dom0. 1. Start the template and fill all the free space with zeros, for example with: - [user@fedora-21 ~] dd if=/dev/zero of=/var/tmp/zero + [user@fedora-21 ~]$ dd if=/dev/zero of=/var/tmp/zero 2. Wait for the "No space left on device" error. Then: - [user@fedora-21 ~] rm -f /var/tmp/zero + [user@fedora-21 ~]$ rm -f /var/tmp/zero 3. Shut down the template and all VMs based on it. Then: - [user@dom0 ~] cd /var/lib/qubes/vm-templates/fedora-21 - [user@dom0 ~] cp --sparse=always root.img root.img.new - [user@dom0 ~] mv root.img.new root.img + [user@dom0 ~]$ cd /var/lib/qubes/vm-templates/fedora-21 + [user@dom0 ~]$ cp --sparse=always root.img root.img.new + [user@dom0 ~]$ mv root.img.new root.img -Known Issues -============ +Additional Information +====================== -You may encounter the following `yum` error: +As mentioned above, you may encounter the following `yum` error: At least X MB more space needed on the / filesystem. -In this case, you have a few options: +In this case, you have several options: - 1. Delete files in order to free up space. One way to do this is by - uninstalling packages (and then reinstalling them again after you finish - the upgrade process, if desired). - 2. Increase the `root.img` size. It should be easy to extend the - `qvm-grow-root` tool in order to support PV (and not only HVM) VMs. - However, someone would need to do this (patches welcome). - 3. Do the upgrade in parts, e.g., by using package groups. (First upgrade + 1. [Increase the TemplateVM's disk image size](/doc/ResizeDiskImage/). + This is the solution mentioned in the main instructions above. + 2. Delete files in order to free up space. One way to do this is by + uninstalling packages. You may then reinstalling them again after you + finish the upgrade process, if desired). However, you may end up having to + increase the disk image size anyway (see previous option). + 3. Increase the `root.img` size with `qvm-grow-root`. It should be easy to + extend the `qvm-grow-root` tool in order to support PV (and not only HVM) + VMs. However, someone would need to do this (patches welcome). + 4. Do the upgrade in parts, e.g., by using package groups. (First upgrade `@core` packages, then the rest.) - 4. Do not perform an in-place upgrade. Instead, simply download and install a + 5. Do not perform an in-place upgrade. Instead, simply download and install a new template package, then redo all desired template modifications. -Here are some useful messages from the mailing list in regard to the last -option: +With regard to the last option, here are some useful messages from the mailing +list which also apply to TemplateVM management and migration in general: * [Marek](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/dS1jbLRP9n8J) * [Jason M](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/5PxDfI-RKAsJ) From 0ea8ffe3314eb86c08ed9dd242f4ee0d74f50783 Mon Sep 17 00:00:00 2001 From: Patrick Schleizer Date: Tue, 23 Jun 2015 22:18:30 +0200 Subject: [PATCH 019/174] typo --- InstallNvidiaDriver.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/InstallNvidiaDriver.md b/InstallNvidiaDriver.md index adede290..484d12a6 100644 --- a/InstallNvidiaDriver.md +++ b/InstallNvidiaDriver.md @@ -13,8 +13,8 @@ RpmFusion packages There are rpm packages with all necessary software on rpmfusion. The only package you have to compile is kernel module (but there is ready src.rpm package). -Download pacakages ------------------- +Download packages +----------------- You will need any Fedora 18 system to download and build packages. You can use Qubes AppVM for it, but it isn't necessary. To download packages from rpmfusion - add this repository to your yum configuration (instructions are on their website). After then download packages using yumdownloader: From 4c91b153a6dfab5c5dcf6c0fa82edd2b1cdd25db Mon Sep 17 00:00:00 2001 From: Axon Date: Sun, 28 Jun 2015 05:11:16 +0000 Subject: [PATCH 020/174] FedoraTemplateUpgrade20: add step to remove old template --- FedoraTemplateUpgrade20.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/FedoraTemplateUpgrade20.md b/FedoraTemplateUpgrade20.md index e12061bb..d509b12e 100644 --- a/FedoraTemplateUpgrade20.md +++ b/FedoraTemplateUpgrade20.md @@ -107,6 +107,10 @@ template based on the standard Fedora 20 template. [user@dom0 ~]$ qvm-trim-template fedora-21 + 9. (Optional) Remove the old default template. + + [user@dom0 ~]$ sudo yum remove qubes-template-fedora-20-x64 + Summary: Upgrading the Minimal Fedora 20 Template to Fedora 21 -------------------------------------------------------------- From 4c8e42069187d9057fed70eb6eda09bdd911697c Mon Sep 17 00:00:00 2001 From: Patrick Schleizer Date: Mon, 29 Jun 2015 15:57:16 +0200 Subject: [PATCH 021/174] kernel upgrade instructions --- SoftwareUpdateDom0.md | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/SoftwareUpdateDom0.md b/SoftwareUpdateDom0.md index 756065b3..f6a2c60b 100644 --- a/SoftwareUpdateDom0.md +++ b/SoftwareUpdateDom0.md @@ -63,4 +63,18 @@ Of course, command line tools are still available for accomplishing various upda sudo yum downgrade package-version {% endhighlight %} +### Kernel Upgrade ### +Install newer kernel. The following example installs kernel 3.19 and was tested on Qubes R3 RC1. + + {% highlight trac-wiki %} + sudo qubes-dom0-update kernel-3.19* + {% endhighlight %} + +Rebuild grub config. + + {% highlight trac-wiki %} + sudo grub2-mkconfig -o /boot/grub2/grub.cfg + {% endhighlight %} + +Reboot required. From 32658914c0be216b0525548d84edf5cfd5fe668e Mon Sep 17 00:00:00 2001 From: Patrick Schleizer Date: Mon, 29 Jun 2015 16:13:08 +0200 Subject: [PATCH 022/174] added Template-BasedVM to Glossary --- Glossary.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Glossary.md b/Glossary.md index 2568c808..1d300f23 100644 --- a/Glossary.md +++ b/Glossary.md @@ -26,6 +26,9 @@ Template Virtual Machine. Any standalone VM which supplies its root filesystem t **Standalone(VM)** Standalone (Virtual Machine). In general terms, a VM is described as **standalone** if and only if it does not depend on any other VM for its root filesystem. (In other words, a VM is standalone if and only if it is not an AppVM.) More specifically, a **StandaloneVM** is a type of VM in Qubes which is created by cloning a TemplateVM. Unlike TemplateVMs, however, StandaloneVMs cannot supply their root filesystems to other VMs. (Therefore, while a TemplateVM is a standalone VM, it is not a StandaloneVM.) +**Template-BasedVM** +Opposite of a Standalone(VM). A VM, that depends on another TemplateVM for its root filesystem. + **NetVM** Network Virtual Machine. A type of VM which connects directly to a network and provides access to that network to other VMs which connect to the NetVM. A NetVM called `netvm` is created by default in most Qubes installations. From c377bcffba00e89316fd22d3c6c8b6ef4a74aee8 Mon Sep 17 00:00:00 2001 From: Patrick Schleizer Date: Mon, 29 Jun 2015 16:35:57 +0200 Subject: [PATCH 023/174] updates proxy now also supports apt This was implemented: https://github.com/QubesOS/qubes-issues/issues/887 --- SoftwareUpdateVM.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SoftwareUpdateVM.md b/SoftwareUpdateVM.md index d0fa367e..013d153a 100644 --- a/SoftwareUpdateVM.md +++ b/SoftwareUpdateVM.md @@ -97,7 +97,7 @@ Some 3rd party applications cannot be installed using the standard yum repositor Updates proxy ------------- -Updates proxy is a service which filter http access to allow access to only something that looks like yum repository (or apt repository in the future - \#887). This is meant to mitigate user errors (like using browser in the template VM), rather than some real isolation. It is done with http proxy 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. +Updates proxy is a service which filter http access to allow access to only something that looks like yum or apt repository. This is meant to mitigate user errors (like using browser in the template VM), rather than some real isolation. It is done with http proxy 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 intercept 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 allows that). If the VM is configured to have access to the updates proxy (2), the startup scripts will automatically configure yum 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). From 687bec2582d8d1d9534e0629069235c0290193da Mon Sep 17 00:00:00 2001 From: Patrick Schleizer Date: Mon, 29 Jun 2015 16:43:40 +0200 Subject: [PATCH 024/174] RPMFusion for a Fedora TemplateVM As per: https://groups.google.com/forum/#!topic/qubes-users/pcXh0bYc5jY --- SoftwareUpdateVM.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/SoftwareUpdateVM.md b/SoftwareUpdateVM.md index d0fa367e..f1d5342c 100644 --- a/SoftwareUpdateVM.md +++ b/SoftwareUpdateVM.md @@ -133,3 +133,12 @@ However, one should be careful with treating this property as a reliable way to One advantage of the non-persistent rootfs though, is that the malware is still inactive before the user's filesystem gets mounted and "processed" by system/applications, which might theoretically allow for some scanning programs (or a skilled user) to reliably scan for signs of infections of the AppVM. But, of course, the problem of finding malware hooks in general is hard, so this would work likely only for some special cases (e.g. an AppVM which doesn't use Firefox, as otherwise it would be hard to scan the Firefox profile directory reliably to find malware hooks there). Also note that the user filesystem's metadata might got maliciously modified by malware in order to exploit a hypothetical bug in the AppVM kernel whenever it mounts the malformed filesystem. However, these exploits will automatically stop working (and so the infection might be cleared automatically) after the hypothetical bug got patched and the update applied (via template update), which is an exceptional feature of Qubes OS. Also note that Disposable VMs do not have persistent user filesystem, and so they start up completely "clean" every time. Note the word "clean" means in this context: the same as their template filesystem, of course. + +RPMFusion for a Fedora TemplateVM +--------------------------------- + +If you would like to enable the [RPM Fusion](http://rpmfusion.org/) repository... + +dom0 Start Menu -> Template:Fedora 21 -> Package Sources -> Enable RPMFusion + +This already covers RPMFusion yum signing keys. From 8c85045b5c07498cb4338e228f69a9053629cf7c Mon Sep 17 00:00:00 2001 From: Hakisho Nukama Date: Tue, 30 Jun 2015 12:25:47 +0000 Subject: [PATCH 025/174] moving community.md to qubes-doc --- community.md | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) create mode 100644 community.md diff --git a/community.md b/community.md new file mode 100644 index 00000000..252817ce --- /dev/null +++ b/community.md @@ -0,0 +1,41 @@ +--- +layout: doc +title: Community +permalink: /community/ +--- + +Need help with Qubes OS? Try these resources. + +## [Search](https://duckduckgo.com/?q=Qubes+OS) + +Add **Qubes OS** to refine your query, you might find just what you need. + +## [QubesOS Mailing Lists]({{ site.url }}{{ site.baseurl }}/doc/QubesLists/) + +- Please send all the questions regarding Qubes OS to one of [these]({{ site.url }}{{ site.baseurl }}/doc/QubesLists/) mailing lists. +- To subscribe to the user list, send a blank mail to `qubes-users+subscribe@googlegroups.com`. +- By sending a message to the appropriate mailing list, you are not only giving others a chance to help you, +but you may also be helping others by starting a public discussion about a shared problem or interest. +- **Please do not send questions to individual Qubes developers.** +- **Please do not [top-post](https://en.wikipedia.org/wiki/Posting_style), use inline replying or bottom-posting instead.** + +## [QubesOS/qubes-doc]({{ site.url }}{{ site.baseurl }}/doc/UserFaq/#qubes-users-faq) + +Search through the issues that the fine folks on the **Qubes Documentation** team +have answered, or ask your own at **qubes-users** mailinglist. + +## [QubesOS/qubes-issues](https://github.com/QubesOS/qubes-issues/issues) + +Search through the issues on the main Qubes OS development. Think you've +found a bug? File a new issue. + +## [QubesOS on StackOverflow](https://stackoverflow.com/questions/tagged/Qubes+OS) + +StackOverflow is a staple of any developer's diet. Check out the QubesOS tag +on StackOverflow for an answer to your question. Not there? Ask a new +question! + +## [QubesOS IRC Channel](irc:irc.freenode.net/qubes) + +Get together at **#qubes** on **irc.freenode.net**, the inofficial +QubesOS IRC channel. From cbe7a8db011e2238b6887ca225718392d91e95fe Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Wed, 1 Jul 2015 11:54:28 +0200 Subject: [PATCH 026/174] update fedora minimal template name --- Templates/FedoraMinimal.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Templates/FedoraMinimal.md b/Templates/FedoraMinimal.md index a0791e37..de2704f5 100644 --- a/Templates/FedoraMinimal.md +++ b/Templates/FedoraMinimal.md @@ -18,7 +18,7 @@ Install It can be installed via the following command: {% highlight trac-wiki %} -[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-20-x64-minimal +[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-21-minimal {% endhighlight %} Usage @@ -27,14 +27,14 @@ Usage It is a good idea to clone the original template, and make any changes in the new clone instead: {% highlight trac-wiki %} -[user@dom0 ~]$ qvm-clone fedora-20-x64-minimal +[user@dom0 ~]$ qvm-clone fedora-21-minimal {% endhighlight %} The sudo package is not installed by default, so lets install it: {% highlight trac-wiki %} -[user@F20-Minimal ~]$ su - -[user@F20-Minimal ~]$ yum install sudo +[user@F21-Minimal ~]$ su - +[user@F21-Minimal ~]$ yum install sudo {% endhighlight %} The rsyslog logging service is not installed by default. All logging is now being handled by the systemd journal. Users requiring the rsyslog service should install it manually. @@ -46,13 +46,13 @@ To access the journald log, use the following command: `journalctl` If You want to use this template to for standard NetVMs You should install some more packeges: {% highlight trac-wiki %} -[user@F20-Minimal ~]$ sudo yum install NetworkManager network-manager-applet wireless-tools dbus-x11 dejavu-sans-fonts tar tinyproxy +[user@F21-Minimal ~]$ sudo yum install NetworkManager network-manager-applet wireless-tools dbus-x11 dejavu-sans-fonts tar tinyproxy {% endhighlight %} And maybe some more optional but useful packages as well: {% highlight trac-wiki %} -[user@F20-Minimal ~]$ sudo yum install pciutils vim-minimal less tcpdump telnet psmisc nmap nmap-ncat gnome-keyring +[user@F21-Minimal ~]$ sudo yum install pciutils vim-minimal less tcpdump telnet psmisc nmap nmap-ncat gnome-keyring {% endhighlight %} If Your network device needs some firmware then you should also install the corresponding packages as well. The `lspci; yum search firmware` command will help to choose the right one :) From baf462c187c76b66d16cd42b575c81d21a35a948 Mon Sep 17 00:00:00 2001 From: Zrubi Date: Wed, 1 Jul 2015 12:07:39 +0200 Subject: [PATCH 027/174] Update FedoraMinimal.md fedora 21 specific updates --- Templates/FedoraMinimal.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Templates/FedoraMinimal.md b/Templates/FedoraMinimal.md index de2704f5..81415536 100644 --- a/Templates/FedoraMinimal.md +++ b/Templates/FedoraMinimal.md @@ -46,7 +46,7 @@ To access the journald log, use the following command: `journalctl` If You want to use this template to for standard NetVMs You should install some more packeges: {% highlight trac-wiki %} -[user@F21-Minimal ~]$ sudo yum install NetworkManager network-manager-applet wireless-tools dbus-x11 dejavu-sans-fonts tar tinyproxy +[user@F21-Minimal ~]$ sudo yum install NetworkManager NetworkManager-wifi network-manager-applet wireless-tools dbus-x11 dejavu-sans-fonts tar tinyproxy {% endhighlight %} And maybe some more optional but useful packages as well: @@ -63,7 +63,7 @@ If You want to use this template as a ProxyVM You may want to install evem more #### Firewall -This template is ready to use for a standard firewall VM. However, using the default minimal template with the default firewall and default update settings will result in an error when attempting to update dom0 (`qubes-dom0-update`), since this process requires `tar`, which is not present by default in the minimal template. +This template is ready to use for a standard firewall VM. #### VPN From 750ce3682f8cfd8afd6f427f77397840542b5876 Mon Sep 17 00:00:00 2001 From: Jeppler Date: Wed, 1 Jul 2015 13:02:28 +0200 Subject: [PATCH 028/174] Update WikiStart.md Changed the order of the "Recent News" section. Now the newest entry is on top and the oldest at the bottom. --- WikiStart.md | 37 +++++++++++++++++++++++-------------- 1 file changed, 23 insertions(+), 14 deletions(-) diff --git a/WikiStart.md b/WikiStart.md index 80956394..d19f7e15 100644 --- a/WikiStart.md +++ b/WikiStart.md @@ -29,19 +29,28 @@ Qubes is an open-source operating system designed to provide strong security for Recent News ----------- - -- `Mar 21, 2013` Introducing Qubes Odyssey Framework [article](http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html) -- `Jun 21, 2013` Qubes OS R3 Alpha preview: Odyssey HAL in action! [announcement](http://theinvisiblethings.blogspot.com/2013/06/qubes-os-r3-alpha-preview-odyssey-hal.html) -- `Nov 26, 2013` Windows 7 seamless GUI integration coming to Qubes OS! [article](http://theinvisiblethings.blogspot.com/2013/11/windows-7-seamless-gui-integration.html) -- `Dec 11, 2013` Qubes OS R2 Beta 3 has been released! [announcement](http://theinvisiblethings.blogspot.com/2013/12/qubes-r2-beta-3-has-been-released.html) -- `Feb 16, 2014` Qubes OS selected as a finalist of Access Innovation Prize 2014 for Endpoint Security Solution [announcement](https://www.accessnow.org/blog/2014/02/13/endpoint-security-prize-finalists-announced?utm_content=buffere803e&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer) -- `Mar 28, 2014` [Article about Qubes OS](http://www.economist.com/blogs/babbage/2014/03/computer-security) in The Economist -- `Apr 12, 2014` [Article about Qubes OS](https://pressfreedomfoundation.org/blog/2014/04/operating-system-can-protect-you-even-if-you-get-hacked) by the [Freedom of the Press Foundation](https://pressfreedomfoundation.org/about/board) -- `Apr 21, 2014` Qubes OS R2 rc1 has been released! [announcement](http://theinvisiblethings.blogspot.com/2014/04/qubes-os-r2-rc1-has-been-released.html) -- `Jul 03, 2014` ITL to present on Qubes OS at LinuxCon Europe: a keynote by Joanna Rutkowska and hands-on training by the core dev team! [conference website](http://events.linuxfoundation.org/events/linuxcon-europe) -- `Jul 16, 2014` Qubes Wiki now uses a CA-signed SSL cert (but you might also want to [read](https://groups.google.com/forum/#!topic/qubes-users/LsDpKnwN6w8) also why this is mostly irrelevant) -- `Aug 06, 2014` Qubes OS R2 rc2 has been released! [announcement](http://theinvisiblethings.blogspot.com/2014/08/qubes-os-r2-rc2-debian-template-ssled.html) -- `Sep 26, 2014` **Qubes OS R2** has been released! [announcement](http://theinvisiblethings.blogspot.com/2014/09/announcing-qubes-os-release-2.html) -- `Oct 19, 2014` LinuxCon EU 2014 slides: [keynote](http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Keynote.pdf) and [tutorial](http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Tutorial.pdf) - `Nov 20, 2014` [Article about Qubes OS](http://www.wired.com/2014/11/protection-from-hackers/) in Wired +- `Oct 19, 2014` LinuxCon EU 2014 slides: [keynote](http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Keynote.pdf) and [tutorial](http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Tutorial.pdf) +- `Sep 26, 2014` **Qubes OS R2** has been released! [announcement](http://theinvisiblethings.blogspot.com/2014/09/announcing-qubes-os-release-2.html) +- `Aug 06, 2014` Qubes OS R2 rc2 has been released! [announcement](http://theinvisiblethings.blogspot.com/2014/08/qubes-os-r2-rc2-debian-template-ssled.html) +- `Jul 16, 2014` Qubes Wiki now uses a CA-signed SSL cert (but you might also want to [read](https://groups.google.com/forum/#!topic/qubes-users/LsDpKnwN6w8) also why this is mostly irrelevant) +- `Jul 03, 2014` ITL to present on Qubes OS at LinuxCon Europe: a keynote by Joanna Rutkowska and hands-on training by the core dev team! [conference website](http://events.linuxfoundation.org/events/linuxcon-europe) +- `Apr 21, 2014` Qubes OS R2 rc1 has been released! [announcement](http://theinvisiblethings.blogspot.com/2014/04/qubes-os-r2-rc1-has-been-released.html) +- `Apr 12, 2014` [Article about Qubes OS](https://pressfreedomfoundation.org/blog/2014/04/operating-system-can-protect-you-even-if-you-get-hacked) by the [Freedom of the Press Foundation](https://pressfreedomfoundation.org/about/board) +- `Mar 28, 2014` [Article about Qubes OS](http://www.economist.com/blogs/babbage/2014/03/computer-security) in The Economist +- `Feb 16, 2014` Qubes OS selected as a finalist of Access Innovation Prize 2014 for Endpoint Security Solution [announcement](https://www.accessnow.org/blog/2014/02/13/endpoint-security-prize-finalists-announced?utm_content=buffere803e&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer) +- `Dec 11, 2013` Qubes OS R2 Beta 3 has been released! [announcement](http://theinvisiblethings.blogspot.com/2013/12/qubes-r2-beta-3-has-been-released.html) +- `Nov 26, 2013` Windows 7 seamless GUI integration coming to Qubes OS! [article](http://theinvisiblethings.blogspot.com/2013/11/windows-7-seamless-gui-integration.html) +- `Jun 21, 2013` Qubes OS R3 Alpha preview: Odyssey HAL in action! [announcement](http://theinvisiblethings.blogspot.com/2013/06/qubes-os-r3-alpha-preview-odyssey-hal.html) +- `Mar 21, 2013` Introducing Qubes Odyssey Framework [article](http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html) + + + + + + + + + + From 3882315d5d3aac3ff7fd6fed0c4209fe54075c64 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Wojdy=C5=82a?= Date: Wed, 1 Jul 2015 14:10:40 +0200 Subject: [PATCH 029/174] update Windows Tools for R3 --- UserDoc.md | 3 +- WindowsTools.md => WindowsTools2.md | 9 +-- WindowsTools3.md | 104 ++++++++++++++++++++++++++++ 3 files changed, 111 insertions(+), 5 deletions(-) rename WindowsTools.md => WindowsTools2.md (96%) create mode 100644 WindowsTools3.md diff --git a/UserDoc.md b/UserDoc.md index 3b754dad..3a39c53a 100644 --- a/UserDoc.md +++ b/UserDoc.md @@ -74,7 +74,8 @@ Qubes User Documentation 8. **Windows VMs** 1. [Installing and Using Windows-based AppVMs (Qubes R2 Beta 3 and later)](/doc/WindowsAppVms/) - 2. [Advanced options and troubleshooting of Qubes Tools for Windows](/doc/WindowsTools/) + 2. [Advanced options and troubleshooting of Qubes Tools for Windows (R3)](/doc/WindowsTools3/) + 3. [Advanced options and troubleshooting of Qubes Tools for Windows (R2)](/doc/WindowsTools2/) 9. Advanced Topics 1. [Configuration files](/doc/UserDoc/ConfigFiles/) diff --git a/WindowsTools.md b/WindowsTools2.md similarity index 96% rename from WindowsTools.md rename to WindowsTools2.md index 4b62bc60..bdc96ab6 100644 --- a/WindowsTools.md +++ b/WindowsTools2.md @@ -1,14 +1,15 @@ --- layout: doc -title: WindowsTools -permalink: /doc/WindowsTools/ -redirect_from: /wiki/WindowsTools/ +title: WindowsTools2 +permalink: /doc/WindowsTools2/ +redirect_from: /wiki/WindowsTools2/ --- Qubes Tools for Windows: advanced settings and troubleshooting ============================================================== -''Only 64-bit Windows 7 (any edition) is supported currently. Windows 8+ support is under development.'' +**This document only applies to Qubes R2 (tools version 2.x)** +*Only 64-bit Windows 7 (any edition) is supported currently. Windows 8+ support is under development.* Installable components ---------------------- diff --git a/WindowsTools3.md b/WindowsTools3.md new file mode 100644 index 00000000..92f21adf --- /dev/null +++ b/WindowsTools3.md @@ -0,0 +1,104 @@ +--- +layout: doc +title: WindowsTools +permalink: /doc/WindowsTools3/ +redirect_from: /wiki/WindowsTools/ +--- + +Qubes Tools for Windows: advanced settings and troubleshooting +============================================================== + +**This document only applies to Qubes R3 (tools version 3.x)** +*Only 64-bit Windows 7 (any edition) is supported currently. Windows 8+ support is under development.* +*HVM templates are not supported yet. Specifically, user profiles are not yet moved to a VM's private image (fix incoming).* + +Installable components +---------------------- + +Qubes Tools for Windows (QTW for short) contain several components than can be enabled or disabled during installation: + +- Shared components (required): common libraries used by QTW components. +- Xen PV drivers: drivers for the virtual hardware exposed by Xen. + - Base Xen PV Drivers (required): paravirtual bus and interface drivers. + - Xen PV Disk Drivers: paravirtual storage drivers. + - Xen PV Network Drivers: paravirtual network drivers. +- Qubes Core Agent: qrexec agent and services. Needed for proper integration with Qubes. +- Qubes GUI Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop. + +It's probably a good idea to install a VNC server in the VM before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS. + +Verbose installation +-------------------- + +If the install process fails you can retry it using the command line below to get a detailed installation log (and send that to us): + +`msiexec /i path-to-qubes-tools.msi /lv path-to-log-file.txt` + +Uninstalling QTW 3.x is **not recommended**. It will most likely make the OS non-bootable because drivers for Xen storage devices will be uninstalled. This will be fixed in the future. + +Configuration +------------- + +Starting from version 2.2.\* various aspects of Qubes Tools for Windows can be configured through registry. Main configuration key is located in `HKEY_LOCAL_MACHINE\SOFTWARE\Invisible Things Lab\Qubes Tools`. Configuration values set on this level are global to all QTW components. It's possible to override global values with component-specific keys, this is useful mainly for setting log verbosity for troubleshooting. Possible configuration values are: + +|**Name**|**Type**|**Description**|**Default value**| +|:-------|:-------|:--------------|:----------------| +|LogDir|String|Directory where logs are created|c:\\Program Files\\Invisible Things Lab\\Qubes Tools\\log| +|LogLevel|DWORD|Log verbosity (see below)|2 (INFO)| +|LogRetention|DWORD|Maximum age of log files (in seconds), older logs are automatically deleted|604800 (7 days)| + +Possible log levels: + +|| +|0|Error|Serious errors that most likely cause irrecoverable failures| +|1|Warning|Unexpected but non-fatal events| +|2|Info|Useful information| +|3|Debug|Internal state dumps for troubleshooting| +|4|Verbose|Trace most function calls| + +Debug and Verbose levels can generate large volume of logs and are intended for development/troubleshooting only. + +To override global settings for a specific component, create a new key under the root key mentioned above and name it as the executable name, without `.exe` extension. For example, to change qrexec-agent's log level to Debug, set it like this: + +![qtw-log-level.png](/attachment/wiki/WindowsTools/qtw-log-level.png) + +Component-specific settings currently available: + +|**Component**|**Setting**|**Type**|**Description**|**Default value**| +|:------------|:----------|:-------|:--------------|:----------------| +|qga|UseDirtyBits|DWORD|Enable experimental feature of the gui agent/qvideo driver: use page table dirty bits to determine changed display regions. This can improve performance but may impact display responsiveness (some changes may not be detected resulting in "stale" image). Needs VM restart to apply change.|0| +|qga|DisableCursor|DWORD|Disable cursor in the VM. Useful for integration with Qubes desktop so you don't see two cursors. Can be disabled if you plan to use the VM through a remote desktop connection of some sort. Needs gui agent restart to apply change (locking OS/logoff should be enough since qga is restarted on desktop change).|1| + +Troubleshooting +--------------- + +If the VM is inaccessible (doesn't respond to qrexec commands, gui is not functioning), try to boot it in safe mode: + +- `qvm-start --debug vmname` +- mash F8 on the boot screen to enable boot options and select Safe Mode (optionally with networking) + +Safe Mode should at least give you access to logs (see above). + +**Please include appropriate logs when reporting bugs/problems.** Starting from version 2.4.2 logs contain QTW version, but if you're using an earlier version be sure to mention which one. If the OS crashes (BSOD) please include the BSOD code and parameters in your bug report. The BSOD screen should be visible if you run the VM in debug mode (`qvm-start --debug vmname`). If it's not visible or the VM reboots automatically, try to start Windows in safe mode (see above) and 1) disable automatic restart on BSOD (Control Panel - System - Advanced system settings - Advanced - Startup and recovery), 2) check the system event log for BSOD events. If you can, send the `memory.dmp` dump file from c:\Windows. +Xen logs (/var/log/xen/console/guest-*) are also useful as they contain pvdrivers diagnostic output. + +If a specific component is malfunctioning, you can increase it's log verbosity as explained above to get more troubleshooting information. Below is a list of components: + +|| +|qrexec-agent|Responsible for most communication with Qubes (dom0 and other domains), secure clipboard, file copying, qrexec services.| +|qrexec-client-vm|Used for communications by the qrexec protocol.| +|qga|Gui agent.| +|QgaWatchdog|Service that monitors session/desktop changes (logon/logoff/locking/UAC...) and simulates SAS sequence (ctrl-alt-del).| +|qubesdb-daemon|Service for accessing Qubes configuration database.| +|network-setup|Service that sets up network parameters according to VM's configuration.| +|prepare-volume|Utility that initializes and formats the disk backed by `private.img` file. It's registered to run on next system boot during QTW setup, if that feature is selected (it can't run *during* the setup because Xen block device drivers are not yet active). It in turn registers move-profiles (see below) to run at early boot.| +|move-profiles|Utility that moves user profiles directory to the private disk. It's registered as an early boot native executable (similar to chkdsk) so it can run before any profile files are opened by some other process. Its log is in a fixed location: `c:\move-profiles.log` (it can't use our common logger library so none of the log settings apply).| + +Updates +------- + +When we publish new QTW version (which is announced on `qubes-users` Google Group) it's usually pushed to the `current-testing` or `unstable` repository first. To use versions from current-testing, run this in dom0: + +`qubes-dom0-update --enablerepo=qubes-dom0-current-testing qubes-windows-tools` + +That command will download a new QTW .iso from the testing repository. It goes without saying that you should **backup your VMs** before installing anything from testing repos. From d5fdb9b746800db0473e9210f24fc3a4578377fb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Wojdy=C5=82a?= Date: Wed, 1 Jul 2015 15:26:22 +0200 Subject: [PATCH 030/174] Windows Tools: add note about VNC server in testing VMs --- WindowsTools2.md | 2 +- WindowsTools3.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/WindowsTools2.md b/WindowsTools2.md index bdc96ab6..fc358e73 100644 --- a/WindowsTools2.md +++ b/WindowsTools2.md @@ -22,7 +22,7 @@ Qubes Tools for Windows (QTW for short) contain several components than can be e - GUI Windows Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop. - Disable UAC: disables User Account Control prompts. *Is this still needed/wanted? Gui agent can handle UAC prompts now.* -It's probably a good idea to install a VNC server in the VM before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS. +**In testing VMs only** it's probably a good idea to install a VNC server before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS. Verbose installation -------------------- diff --git a/WindowsTools3.md b/WindowsTools3.md index 92f21adf..2ec2061b 100644 --- a/WindowsTools3.md +++ b/WindowsTools3.md @@ -25,7 +25,7 @@ Qubes Tools for Windows (QTW for short) contain several components than can be e - Qubes Core Agent: qrexec agent and services. Needed for proper integration with Qubes. - Qubes GUI Agent: video driver and gui agent that enable seamless showing of Windows applications on the secure Qubes desktop. -It's probably a good idea to install a VNC server in the VM before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS. +**In testing VMs only** it's probably a good idea to install a VNC server before installing QTW. If something goes very wrong with the Qubes gui agent, a VNC server should still allow access to the OS. Verbose installation -------------------- From c622b831dbe4aceb3ca0e2e6feb525acd0470c41 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Wojdy=C5=82a?= Date: Wed, 1 Jul 2015 15:35:16 +0200 Subject: [PATCH 031/174] Windows Tools: fix doc link --- WindowsTools3.md | 1 + 1 file changed, 1 insertion(+) diff --git a/WindowsTools3.md b/WindowsTools3.md index 2ec2061b..bc3ff389 100644 --- a/WindowsTools3.md +++ b/WindowsTools3.md @@ -3,6 +3,7 @@ layout: doc title: WindowsTools permalink: /doc/WindowsTools3/ redirect_from: /wiki/WindowsTools/ +redirect_from: /doc/WindowsTools/ --- Qubes Tools for Windows: advanced settings and troubleshooting From 79c54f197b3c1d7727da64698aa36ad80dababeb Mon Sep 17 00:00:00 2001 From: Jeppler Date: Wed, 1 Jul 2015 16:00:27 +0200 Subject: [PATCH 032/174] Update WikiStart.md 1. Added the announcement for Qubes OS 3.0 rc1 2. replaced the old theinvisiblethings.blogspot.com links with the new blog.invisiblethings.org links --- WikiStart.md | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/WikiStart.md b/WikiStart.md index d19f7e15..85794692 100644 --- a/WikiStart.md +++ b/WikiStart.md @@ -24,25 +24,26 @@ Qubes is an open-source operating system designed to provide strong security for - [Security](/doc/QubesSecurity/) - [FAQ](/doc/UserFaq/) - [User Documentation](/doc/UserDoc/) -- [How is Qubes OS different from...?](http://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html) -- Beyond Qubes R2 -- the [Qubes Odyssey Framework](http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html) +- [How is Qubes OS different from...?](http://blog.invisiblethings.org/2012/09/12/how-is-qubes-os-different-from.html) +- Beyond Qubes R2 -- the [Qubes Odyssey Framework](http://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html) Recent News ----------- +- `Apr 23, 2015` Qubes OS 3.0 rc1 has been released! [announcement](http://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html) - `Nov 20, 2014` [Article about Qubes OS](http://www.wired.com/2014/11/protection-from-hackers/) in Wired - `Oct 19, 2014` LinuxCon EU 2014 slides: [keynote](http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Keynote.pdf) and [tutorial](http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Tutorial.pdf) -- `Sep 26, 2014` **Qubes OS R2** has been released! [announcement](http://theinvisiblethings.blogspot.com/2014/09/announcing-qubes-os-release-2.html) -- `Aug 06, 2014` Qubes OS R2 rc2 has been released! [announcement](http://theinvisiblethings.blogspot.com/2014/08/qubes-os-r2-rc2-debian-template-ssled.html) +- `Sep 26, 2014` **Qubes OS R2** has been released! [announcement](http://blog.invisiblethings.org/2014/09/26/announcing-qubes-os-release-2.html) +- `Aug 06, 2014` Qubes OS R2 rc2 has been released! [announcement](http://blog.invisiblethings.org/2014/08/06/qubes-os-r2-rc2-debian-template-ssled.html) - `Jul 16, 2014` Qubes Wiki now uses a CA-signed SSL cert (but you might also want to [read](https://groups.google.com/forum/#!topic/qubes-users/LsDpKnwN6w8) also why this is mostly irrelevant) - `Jul 03, 2014` ITL to present on Qubes OS at LinuxCon Europe: a keynote by Joanna Rutkowska and hands-on training by the core dev team! [conference website](http://events.linuxfoundation.org/events/linuxcon-europe) -- `Apr 21, 2014` Qubes OS R2 rc1 has been released! [announcement](http://theinvisiblethings.blogspot.com/2014/04/qubes-os-r2-rc1-has-been-released.html) +- `Apr 21, 2014` Qubes OS R2 rc1 has been released! [announcement](http://blog.invisiblethings.org/2014/04/20/qubes-os-r2-rc1-has-been-released.html) - `Apr 12, 2014` [Article about Qubes OS](https://pressfreedomfoundation.org/blog/2014/04/operating-system-can-protect-you-even-if-you-get-hacked) by the [Freedom of the Press Foundation](https://pressfreedomfoundation.org/about/board) - `Mar 28, 2014` [Article about Qubes OS](http://www.economist.com/blogs/babbage/2014/03/computer-security) in The Economist - `Feb 16, 2014` Qubes OS selected as a finalist of Access Innovation Prize 2014 for Endpoint Security Solution [announcement](https://www.accessnow.org/blog/2014/02/13/endpoint-security-prize-finalists-announced?utm_content=buffere803e&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer) -- `Dec 11, 2013` Qubes OS R2 Beta 3 has been released! [announcement](http://theinvisiblethings.blogspot.com/2013/12/qubes-r2-beta-3-has-been-released.html) -- `Nov 26, 2013` Windows 7 seamless GUI integration coming to Qubes OS! [article](http://theinvisiblethings.blogspot.com/2013/11/windows-7-seamless-gui-integration.html) -- `Jun 21, 2013` Qubes OS R3 Alpha preview: Odyssey HAL in action! [announcement](http://theinvisiblethings.blogspot.com/2013/06/qubes-os-r3-alpha-preview-odyssey-hal.html) -- `Mar 21, 2013` Introducing Qubes Odyssey Framework [article](http://theinvisiblethings.blogspot.com/2013/03/introducing-qubes-odyssey-framework.html) +- `Dec 11, 2013` Qubes OS R2 Beta 3 has been released! [announcement](http://blog.invisiblethings.org/2013/12/10/qubes-r2-beta-3-has-been-released.html) +- `Nov 26, 2013` Windows 7 seamless GUI integration coming to Qubes OS! [article](http://blog.invisiblethings.org/2013/11/26/windows-7-seamless-gui-integration.html) +- `Jun 21, 2013` Qubes OS R3 Alpha preview: Odyssey HAL in action! [announcement](http://blog.invisiblethings.org/2013/06/21/qubes-os-r3-alpha-preview-odyssey-hal.html) +- `Mar 21, 2013` Introducing Qubes Odyssey Framework [article](http://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html) From c1f2da6420bb5f168b2de628cd45858d864f896e Mon Sep 17 00:00:00 2001 From: Patrick Schleizer Date: Thu, 2 Jul 2015 15:15:17 +0200 Subject: [PATCH 033/174] fixed ticket link --- SystemRequirements.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SystemRequirements.md b/SystemRequirements.md index 45fed73a..cb5ca28a 100644 --- a/SystemRequirements.md +++ b/SystemRequirements.md @@ -14,7 +14,7 @@ Minimum - 64-bit Intel or AMD processor (x86\_64 aka x64 aka AMD64) - 4 GB RAM - 32 GB disk space -- legacy boot mode (UEFI not supported yet - \#794) +- legacy boot mode ([UEFI not supported yet](https://github.com/QubesOS/qubes-issues/issues/794)) Recommended ----------- From aa2934d12c71e11dc2092a63b244f90f9fb3c941 Mon Sep 17 00:00:00 2001 From: Noah Vesely Date: Thu, 2 Jul 2015 13:28:54 -0700 Subject: [PATCH 034/174] Updated rotten links to QubesOS Github R2 branch --- Dom0SecureUpdates.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Dom0SecureUpdates.md b/Dom0SecureUpdates.md index 91bcf609..66be09dc 100644 --- a/Dom0SecureUpdates.md +++ b/Dom0SecureUpdates.md @@ -29,15 +29,15 @@ Secure update mechanism we use in Qubes (starting from Beta 2 Keeping Dom0 not connected to any network makes it hard, however, to provide updates for software in Dom0. For this reason we have come up with the following mechanism for Dom0 updates, which minimizes the amount of untrusted input processed by Dom0 software: -The update process is initiated by [qvm-dom0-update script](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/qvm-tools/qvm-dom0-update;h=d6ac222fdc3850a0f1269df27746c9ed6e84c8a9;hb=HEAD), running in Dom0. +The update process is initiated by [qvm-dom0-update script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-dom0-update), running in Dom0. -Updates (\*.rpm files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes\_download\_dom0\_updates.sh script](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=common/qubes_download_dom0_updates.sh;h=dfc46123e9c0904d019d3f05008bc3adca21921d;hb=HEAD) (this script is executed using qrexec by the previously mentioned qvm-dom0-update). Note that we assume that this script might get compromised and might download a maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ```/var/lib/qubes/dom0-updates``` directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ```--installroot=``` option. +Updates (\*.rpm files) are checked and downloaded by UpdateVM, which by default is the same as the firewall VM, but can be configured to be any other, network-connected VM. This is done by [qubes-download-dom0-updates.sh script](https://github.com/QubesOS/qubes-core-agent-linux/blob/release2/misc/qubes-download-dom0-updates.sh) (this script is executed using qrexec by the previously mentioned qvm-dom0-update). Note that we assume that this script might get compromised and might download a maliciously compromised downloads -- this is not a problem as Dom0 verifies digital signatures on updates later. The downloaded rpm files are placed in a ```/var/lib/qubes/dom0-updates``` directory on UpdateVM filesystem (again, they might get compromised while being kept there, still this isn't a problem). This directory is passed to yum using the ```--installroot=``` option. -Once updates are downloaded, the update script that runs in UpdateVM requests an RPM service [qubes.ReceiveUpdates](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/aux-tools/qubes.ReceiveUpdates;h=7134323902b37a0be41b98ef8dbde61a94b1d189;hb=HEAD) to be executed in Dom0. This service is implemented by [qubes-receive-updates script](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/aux-tools/qubes-receive-updates;h=af386090b4a98de7f00736b60b9a1ca16f337822;hb=HEAD) running in Dom0. The Dom0's qvm-dom0-update script (which originally initiated the whole update process) waits until qubes-receive-updates finished. +Once updates are downloaded, the update script that runs in UpdateVM requests an RPM service [qubes.ReceiveUpdates](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes.ReceiveUpdates) to be executed in Dom0. This service is implemented by [qubes-receive-updates script](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-receive-updates) running in Dom0. The Dom0's qvm-dom0-update script (which originally initiated the whole update process) waits until qubes-receive-updates finished. -The qubes-receive-updates script processes the untrusted input from Update VM: it first extracts the received \*.rpm files (that are sent over qrexec data connection) and then verifies digital signature on each file. The qubes-receive-updates script is a security-critical component of the Dom0 update process (as is the [qfile-dom0-unpacker.c](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/aux-tools/qfile-dom0-unpacker.c;h=757a2c43ba9e6780e8173b0049b2678efa0fda84;hb=HEAD) and the rpm utility, both used by the qubes-receive-updates for processing the untrusted input. +The qubes-receive-updates script processes the untrusted input from Update VM: it first extracts the received \*.rpm files (that are sent over qrexec data connection) and then verifies digital signature on each file. The qubes-receive-updates script is a security-critical component of the Dom0 update process (as is the [qfile-dom0-unpacker.c](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qfile-dom0-unpacker.c) and the rpm utility, both used by the qubes-receive-updates for processing the untrusted input. -Once qubes-receive-updates finished unpacking and verifying the updates, the updates are placed in ``qubes-receive-updates`` directory in Dom0 filesystem. Those updates are now trusted. Dom0 is configured (see /etc/yum.conf in Dom0) to use this directory as a default (and only) [yum repository](http://git.qubes-os.org/?p=joanna/core.git;a=blob;f=dom0/qubes-cached.repo;h=963a7ba524d4d63296718161fe4bcd3cad1ff5e7;hb=HEAD). +Once qubes-receive-updates finished unpacking and verifying the updates, the updates are placed in ``qubes-receive-updates`` directory in Dom0 filesystem. Those updates are now trusted. Dom0 is configured (see /etc/yum.conf in Dom0) to use this directory as a default (and only) [yum repository](https://github.com/QubesOS/qubes-core-admin-linux/blob/release2/dom0-updates/qubes-cached.repo). Finally, qvm-dom0-updates runs ``yum update`` that fetches the rpms from qubes-cached repo and installs them as usual. From e49c58e1f73ade4bae8cdbc1a7339715bf1c3c5b Mon Sep 17 00:00:00 2001 From: Matt McCutchen Date: Mon, 6 Jul 2015 18:14:32 -0700 Subject: [PATCH 035/174] Mention Fedora 21 update proxy problem on upgrade instructions This isn't the ideal place for known issues with Fedora 21 that aren't specific to upgrading from Fedora 20, but it's one place I would have seen the information. --- FedoraTemplateUpgrade20.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/FedoraTemplateUpgrade20.md b/FedoraTemplateUpgrade20.md index d509b12e..d8182e8e 100644 --- a/FedoraTemplateUpgrade20.md +++ b/FedoraTemplateUpgrade20.md @@ -214,3 +214,8 @@ list which also apply to TemplateVM management and migration in general: * [Marek](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/dS1jbLRP9n8J) * [Jason M](https://groups.google.com/d/msg/qubes-users/mCXkxlACILQ/5PxDfI-RKAsJ) + +Known issues with Fedora 21 +=========================== + +* [The "Update VM" command in Qubes Manager does not work](https://github.com/QubesOS/qubes-issues/issues/982). From add78b90a11e5ee4faf11e2a1196ad83b3647fc5 Mon Sep 17 00:00:00 2001 From: Noah Vesely Date: Wed, 8 Jul 2015 19:20:03 -0700 Subject: [PATCH 036/174] spelling, grammar, and minor clarifications --- Qrexec.md | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/Qrexec.md b/Qrexec.md index dabb0773..36da6c19 100644 --- a/Qrexec.md +++ b/Qrexec.md @@ -13,11 +13,11 @@ Qubes **qrexec** is a framework for implementing inter-VM (incl. Dom0-VM) servic Basic Dom0-VM command execution ------------------------------- -During domain creation a process named `qrexec-daemon` is started in dom0, and a process named `qrexec-agent` is started in the VM. They are connected over `vchan` channel. +During each domain creation a process named `qrexec-daemon` is started in dom0, and a process named `qrexec-agent` is started in the VM. They are connected over `vchan` channel. -Typically, the first thing that a `qrexec-client` instance does is to send a request to `qrexec-agent` to start a process in the VM. Since then, the stdin/stdout/stderr from this remote process is passed to the `qrexec-client` process. +Typically, the first thing that a `qrexec-client` instance does is to send a request to `qrexec-agent` to start a process in the VM. From then on, the stdin/stdout/stderr from this remote process will be passed to the `qrexec-client` process. -E.g. to start a primitive shell in a VM type the following in Dom0 console: +E.g., to start a primitive shell in a VM type the following in Dom0 console: {% highlight trac-wiki %} [user@dom0 ~]$ /usr/lib/qubes/qrexec-client -d user:bash @@ -29,22 +29,22 @@ Adding `-e` on the `qrexec-client` command line results in mere command executio There is also the `-l ` flag, which directs `qrexec-client` to pass stdin/stdout of the remote program not to its stdin/stdout, but to the (spawned for this purpose) ``. -The `qvm-run` command is heavily based on `qrexec-client`. It also takes care for additional activities, e.g. starting the domain if it is not up yet, and starting the GUI daemon. Thus, it is usually more convenient to use `qvm-run`. +The `qvm-run` command is heavily based on `qrexec-client`. It also takes care of additional activities (e.g., starting the domain, if it is not up yet, and starting the GUI daemon). Thus, it is usually more convenient to use `qvm-run`. -There can be almost arbitrary number of `qrexec-client` processes for a domain (so, connected to the same `qrexec-daemon`, same domain) - their data is multiplexed independently. +There can be almost arbitrary number of `qrexec-client` processes for a domain (i.e., `qrexec-client` processes connected to the same `qrexec-daemon`); their data is multiplexed independently. There is a similar command line utility avilable inside Linux AppVMs (note the `-vm` suffix): `qrexec-client-vm` that will be described in subsequent sections. Qubes Inter-VM Services (Qubes RPC) ----------------------------------- -Apart from simple Dom0-\>VM command executions, as discussed above, it is also useful to have more advanced infrastructure for controlled inter-VM RPC/services. This might be used for simple things like inter-VM file copy operations, as well as more complex tasks like starting a Disposable VM, and requesting it to do certain operations on a handed file(s). +Apart from simple Dom0-\>VM command executions, as discussed above, it is also useful to have more advanced infrastructure for controlled inter-VM RPC/services. This might be used for simple things like inter-VM file copy operations, as well as more complex tasks like starting a DispVM, and requesting it to do certain operations on a handed file(s). -Instead of implementing complex RPC-like mechanisms for inter-VM communication, Qubes takes a much simpler and pragmatic approach and aims to only provide simple *pipes* between the VMs, plus ability to request *pre-defined* programs (servers) to be started on the other end of such pipes, and a centralized policy (enforced in Dom0) which says which VMs can request what services from what VMs. +Instead of implementing complex RPC-like mechanisms for inter-VM communication, Qubes takes a much simpler and pragmatic approach and aims to only provide simple *pipes* between the VMs, plus ability to request *pre-defined* programs (servers) to be started on the other end of such pipes, and a centralized policy (enforced by the `qrexec-policy` process running in dom0) which says which VMs can request what services from what VMs. -Thanks to the framework and automatic stdin/stdout redirection, RPC programs are very simple - both the client and server just use their stdin/stdout to pass data. The framework does all the inner work to connect these file descriptors to each other via `qrexec-daemon` and `qrexec-agent`. Additionally, disposable VMs are tightly integrated - RPC to a DisposableVM is a simple matter of using a magic `$dispvm` keyword as the target VM name. +Thanks to the framework and automatic stdin/stdout redirection, RPC programs are very simple; both the client and server just use their stdin/stdout to pass data. The framework does all the inner work to connect these file descriptors to each other via `qrexec-daemon` and `qrexec-agent`. Additionally, DispVMs are tightly integrated; RPC to a DispVM is a simple matter of using a magic `$dispvm` keyword as the target VM name. -All services in Qubes are identified by a single string, which by convention takes a form of `qubes.ServiceName`. Each VM can provide handlers for each of the known services by providing a file in `/etc/qubes-rpc/` directory with the same name as the service it is supposed to handle. This file will be then executed by the qrexec service, if the Dom0 policy allowed service to be requested (see below). Typically the files in `/etc/qubes-rpc/` contain just one line, which is a path to the specific binary that acts as a server for the incoming request, however they might also be the actual executable themselves. Qrexec framework takes care about connecting the stdin/stdout of the server provess with the corresponding stdin/stdout of the requesting process in the requesting VM (see example Hello World service described below). +All services in Qubes are identified by a single string, which by convention takes a form of `qubes.ServiceName`. Each VM can provide handlers for each of the known services by providing a file in `/etc/qubes-rpc/` directory with the same name as the service it is supposed to handle. This file will then be executed by the qrexec service, if the dom0 policy allowed the service to be requested (see below). Typically, the files in `/etc/qubes-rpc/` contain just one line, which is a path to the specific binary that acts as a server for the incoming request, however they might also be the actual executable themselves. Qrexec framework is careful about connecting the stdin/stdout of the server process with the corresponding stdin/stdout of the requesting process in the requesting VM (see example Hello World service described below). Qubes Services (RPC) policy --------------------------- @@ -69,7 +69,7 @@ These files contain lines with the following format: srcvm destvm (allow|deny|ask)[,user=user_to_run_as][,target=VM_to_redirect_to] {% endhighlight %} -You can specify `srcvm` and `destvm` by name, or by one of `$anyvm`, `$dispvm`, `dom0` reserved keywords (note string `dom0` does not match the `$anyvm` pattern; all other names do). Only `$anyvm` keyword makes sense in the `srcvm` field (service calls from dom0 are currently always allowed, `$dispvm` means "new VM created for this particular request" - so it is never a source of request). Currently there is no way to specify source VM by type, but this is planned for Qubes R3. +You can specify `srcvm` and `destvm` by name, or by one of `$anyvm`, `$dispvm`, `dom0` reserved keywords (note string `dom0` does not match the `$anyvm` pattern; all other names do). Only `$anyvm` keyword makes sense in the `srcvm` field (service calls from dom0 are currently always allowed, `$dispvm` means "new VM created for this particular request" - so it is never a source of request). Currently, there is no way to specify source VM by type, but this is planned for Qubes R3. Whenever a RPC request for service named "XYZ" is received, the first line in `/etc/qubes-rpc/policy/XYZ` that matches the actual `srcvm`/`destvm` is consulted to determine whether to allow RPC, what user account the program should run in target VM under, and what VM to redirect the execution to. If the policy file does not exits, user is prompted to create one *manually*; if still there is no policy file after prompting, the action is denied. @@ -78,7 +78,7 @@ On the target VM, the `/etc/qubes-rpc/XYZ` must exist, containing the file name Requesting VM-VM (and VM-Dom0) services execution ------------------------------------------------- -On src VM, one should invoke the qrexec client via the follwing command: +In a src VM, one should invoke the qrexec client via the following command: {% highlight trac-wiki %} /usr/lib/qubes/qrexec-client-vm [local program arguments]` @@ -86,7 +86,7 @@ On src VM, one should invoke the qrexec client via the follwing command: Note that only stdin/stdout is passed between RPC server and client - notably, no cmdline argument are passed. -The source VM name can be accessed in the server process via QREXEC\_REMOTE\_DOMAIN environment variable. (Note the source VM has *no* control over the name provided in this variable -- the name of the VM is provided by Dom0, and so is trusted). +The source VM name can be accessed in the server process via QREXEC\_REMOTE\_DOMAIN environment variable. (Note the source VM has *no* control over the name provided in this variable--the name of the VM is provided by dom0, and so is trusted.) By default, stderr of client and server is logged to respective `/var/log/qubes/qrexec.XID` files, in each of the VM. @@ -99,7 +99,7 @@ Connect directly to `/var/run/qubes/qrexec-agent-fdpass` socket as described [he ### Revoking "Yes to All" authorization -Qubes RPC policy supports the "ask" action. This will prompt the user whether a given RPC call should be allowed. That prompt window has an option to click "Yes to All", which allows the action and adds a new entry to the policy file, which will unconditionally allow further calls for given service-srcVM-dstVM tuple. +Qubes RPC policy supports an "ask" action, that will prompt the user whether a given RPC call should be allowed. It is set as default for services such as inter-VM file copy. A prompt window launches in dom0, that gives the user option to click "Yes to All", which allows the action and adds a new entry to the policy file, which will unconditionally allow further calls for given (service, srcVM, dstVM) tuple. In order to remove such authorization, issue this command from a Dom0 terminal (example below for qubes.Filecopy service): @@ -107,7 +107,9 @@ In order to remove such authorization, issue this command from a Dom0 terminal ( sudo nano /etc/qubes-rpc/policy/qubes.Filecopy {% endhighlight %} -and then remove the first line/s (before the first \#\# comment) which are the "Yes to All" results. +and then remove any line(s) ending in "allow" (before the first \#\# comment) which are the "Yes to All" results. + +A user might also want to set their own policies in this section. This may mostly serve to prevent the user from mistakenly copying files or text from a trusted to untrusted domain, or vice-versa. ### Qubes RPC "Hello World" service From 991c20d372f3f1846317eb964bbb4ce71cd8e54c Mon Sep 17 00:00:00 2001 From: Noah Vesely Date: Thu, 9 Jul 2015 00:20:39 -0700 Subject: [PATCH 037/174] tiny grammar pull --- Qrexec2Implementation.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Qrexec2Implementation.md b/Qrexec2Implementation.md index 01a95e23..5a3f0d5a 100644 --- a/Qrexec2Implementation.md +++ b/Qrexec2Implementation.md @@ -19,7 +19,7 @@ Players: - `/usr/lib/qubes/qrexec-policy` \<- internal program used to evaluate the policy file and making the 2nd half of the connection. - `/usr/lib/qubes/qrexec-client` \<- raw command line tool that talks to the daemon via unix socket (`/var/run/qubes/qrexec.XID`) -Note: neither of the above tools are designed to be used by users. +Note: none of the above tools are designed to be used by users. Linux VMs implementation ------------------------ @@ -30,7 +30,7 @@ Players: - `/usr/lib/qubes/qubes-rpc-multiplexer` \<- executes the actual service program, as specified in VM's `/etc/qubes-rpc/qubes.XYZ`. - `/usr/lib/qubes/qrexec-client-vm` \<- raw command line tool that talks to the agent. -Note: neither of the above tools are designed to be used by users. `qrexec-client-vm` is designed to be wrapped up by Qubes apps. +Note: none of the above tools are designed to be used by users. `qrexec-client-vm` is designed to be wrapped up by Qubes apps. Windows VMs implemention ------------------------ @@ -64,7 +64,7 @@ When a user in a source VM executes `qrexec-client-vm` utility, the following st - `qrexec-policy` evaluates the policy file. If successful, creates a pair of `qrexec-client` processes, whose stdin/stdout are cross-connencted. - The first `qrexec-client` connects to the src VM, using the `-c ClientID` parameter, which results in not creating a new process, but connecting to the existing process file descriptors (these are the fds of unix socket created in step 1). - The second `qrexec-client` connects to the target VM, and executes `qubes-rpc-multiplexer` command there with the rpc action as the cmdline argument. Finally, `qubes-rpc-multiplexer` executes the correct rpc server on the target. -- In the above step, if the target VM is `$dispvm`, the dispvm is created via the `qfile-daemon-dvm` program. The latter waits for the `qrexec-client` process to exit, and then destroys the dispvm. +- In the above step, if the target VM is `$dispvm`, the DispVM is created via the `qfile-daemon-dvm` program. The latter waits for the `qrexec-client` process to exit, and then destroys the DispVM. Protocol description ("wire-level" spec) ---------------------------------------- From 4e5817b3c2f77a7f9f370c0e28f17d2183700493 Mon Sep 17 00:00:00 2001 From: Jeppler Date: Tue, 14 Jul 2015 18:41:11 +0200 Subject: [PATCH 038/174] "Virtics" source updated - The source was a dead link pointing to an empty dokuwiki page. I changed it, but please review the source. I guess this notice is not useful any more: (We plan to implement some ideas from Matt's thesis in Qubes very soon -- stay tuned for details) --- QubesResearch.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/QubesResearch.md b/QubesResearch.md index 21741e91..c8a8359b 100644 --- a/QubesResearch.md +++ b/QubesResearch.md @@ -23,8 +23,7 @@ Here are some links to various papers/research projects that somehow relate to Q ### Application-level security -- [Virtics: A System for Privilege Separation of Legacy Desktop Applications](http://radlab.cs.berkeley.edu/wiki/Virtics) by Matt Piotrowski - (We plan to implement some ideas from Matt's thesis in Qubes very soon -- stay tuned for details) +- [Virtics: A System for Privilege Separation of Legacy Desktop Applications](http://www.eecs.berkeley.edu/Pubs/TechRpts/2010/EECS-2010-70.pdf) by Matt Piotrowski ### VMM/Xen disagregation From 15c0146c765afe4a8856ea7e6b9ba19fed3c83fa Mon Sep 17 00:00:00 2001 From: Hakisho Nukama Date: Fri, 17 Jul 2015 22:35:59 +0000 Subject: [PATCH 039/174] Supporting old trac link for backward compatibility in QSB. --- SecurityPage.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/SecurityPage.md b/SecurityPage.md index d02691fd..8f3f4c96 100644 --- a/SecurityPage.md +++ b/SecurityPage.md @@ -2,7 +2,9 @@ layout: doc title: SecurityPage permalink: /doc/SecurityPage/ -redirect_from: /wiki/SecurityPage/ +redirect_from: +- /wiki/SecurityPage/ +- /trac/wiki/SecurityPage/ --- Reporting Security Issues in Qubes OS From 943c36478851416e66c541436df43e16af66a875 Mon Sep 17 00:00:00 2001 From: Hakisho Nukama Date: Fri, 17 Jul 2015 22:46:04 +0000 Subject: [PATCH 040/174] Supporting more old trac links for backward compatibility in QSB. --- CodingStyle.md | 4 +++- SecurityBulletins.md | 4 +++- SecurityCriticalCode.md | 4 +++- 3 files changed, 9 insertions(+), 3 deletions(-) diff --git a/CodingStyle.md b/CodingStyle.md index c1d404a7..6283502e 100644 --- a/CodingStyle.md +++ b/CodingStyle.md @@ -2,7 +2,9 @@ layout: doc title: CodingStyle permalink: /doc/CodingStyle/ -redirect_from: /wiki/CodingStyle/ +redirect_from: +- /wiki/CodingStyle/ +- /trac/wiki/CodingStyle/ --- Coding Guidelines for Qubes Developers diff --git a/SecurityBulletins.md b/SecurityBulletins.md index 8ef12d60..e7183d70 100644 --- a/SecurityBulletins.md +++ b/SecurityBulletins.md @@ -2,7 +2,9 @@ layout: doc title: SecurityBulletins permalink: /doc/SecurityBulletins/ -redirect_from: /wiki/SecurityBulletins/ +redirect_from: +- /wiki/SecurityBulletins/ +- /trac/wiki/SecurityBulletins/ --- Qubes Security Bulletins diff --git a/SecurityCriticalCode.md b/SecurityCriticalCode.md index 236ea2ca..b6adc98c 100644 --- a/SecurityCriticalCode.md +++ b/SecurityCriticalCode.md @@ -2,7 +2,9 @@ layout: doc title: SecurityCriticalCode permalink: /doc/SecurityCriticalCode/ -redirect_from: /wiki/SecurityCriticalCode/ +redirect_from: +- /wiki/SecurityCriticalCode/ +- /trac/wiki/SecurityCriticalCode/ --- Security-Critical Code in Qubes OS From bac54d9d36596f5f5a14a2c5f263f349e52f2aa7 Mon Sep 17 00:00:00 2001 From: Noah Vesely Date: Sat, 18 Jul 2015 19:10:57 -0700 Subject: [PATCH 041/174] Fixed link-rot to Virtcs paper The old link pointed to some home page for the project that is now blank. --- QubesResearch.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/QubesResearch.md b/QubesResearch.md index 21741e91..4a3476f8 100644 --- a/QubesResearch.md +++ b/QubesResearch.md @@ -23,7 +23,7 @@ Here are some links to various papers/research projects that somehow relate to Q ### Application-level security -- [Virtics: A System for Privilege Separation of Legacy Desktop Applications](http://radlab.cs.berkeley.edu/wiki/Virtics) by Matt Piotrowski +- [Virtics: A System for Privilege Separation of Legacy Desktop Applications](http://bnrg.cs.berkeley.edu/~adj/publications/paper-files/EECS-2010-70.pdf) by Matt Piotrowski (We plan to implement some ideas from Matt's thesis in Qubes very soon -- stay tuned for details) ### VMM/Xen disagregation From e1550f6ab698524700e2da5b218836dc79462f9c Mon Sep 17 00:00:00 2001 From: Robin Schneider Date: Sun, 19 Jul 2015 18:41:14 +0200 Subject: [PATCH 042/174] Fixed spelling and moved section how to contribute. * Normal git pull-request workflow and patches are used. --- DevelFaq.md | 15 +++------------ SourceCode.md | 15 +++++++++++++-- 2 files changed, 16 insertions(+), 14 deletions(-) diff --git a/DevelFaq.md b/DevelFaq.md index 64f74fbc..2a7783b1 100644 --- a/DevelFaq.md +++ b/DevelFaq.md @@ -16,11 +16,11 @@ Qubes Developers FAQ ### Q: Why does dom0 need to be 64-bit? -Often it is more difficult to exploit a bug on the x64 Linux than it is on x86 Linux (e.g. ASLR is sometimes harder to get around). While we designed Qubes with the emphasis on limiting any potential attack vectors in the first place, still we realize that some of the code running in Dom0, e.g. our GUI daemon or xen-store daemon, even though it is very simple code, might contain some bugs. Plus currently we haven't implemented a separate storage domain, so also the disk backends are in Dom0 and are "reachable" from the VMs, which adds up to the potential attack surface. So, having faced a choice between 32-bit and 64-bit OS for Dom0, it was almost a no-brainer, as the 64-bit option provides some (little perhaps, but still) more protection against some classes of attacks, and at the same time do not have any disadvantages (except that it requires a 64-bit processor, but all systems on which it makes sense to run Qubes, e.g. that have at least 3-4GB memory, they do have 64-bit CPUs anyway). +Often it is more difficult to exploit a bug on the x64 Linux than it is on x86 Linux (e.g. ASLR is sometimes harder to get around). While we designed Qubes with the emphasis on limiting any potential attack vectors in the first place, still we realize that some of the code running in Dom0, e.g. our GUI daemon or xen-store daemon, even though it is very simple code, might contain some bugs. Plus currently we haven't implemented a separate storage domain, so also the disk backends are in Dom0 and are "reachable" from the VMs, which adds up to the potential attack surface. So, having faced a choice between 32-bit and 64-bit OS for Dom0, it was almost a no-brainer, as the 64-bit option provides some (little perhaps, but still) more protection against some classes of attacks, and at the same time does not have any disadvantages (except that it requires a 64-bit processor, but all systems on which it makes sense to run Qubes, e.g. that have at least 3-4GB memory, they do have 64-bit CPUs anyway). ### Q: Why do you use KDE in Dom0? What is the roadmap for Gnome support? -There a few things that are KDE-specific, but generally it should not be a big problem to also add Gnome support to Qubes (in Dom0 of course). Those KDE-specific things are: +There are a few things that are KDE-specific, but generally it should not be a big problem to also add Gnome support to Qubes (in Dom0 of course). Those KDE-specific things are: - Qubes requires KDM (KDE Login Manager), rather than GDM, for the very simple reason that GDM doesn't obey standards and start `/usr/bin/Xorg` instead of `/usr/bin/X`. This is important for Qubes, because we need to load a special "X wrapper" (to make it possible to use Linux usermode shared memory to access Xen shared memory pages in our App Viewers -- see the sources [here](https://github.com/QubesOS/qubes-gui-daemon/tree/master/shmoverride)). So, Qubes makes the `/usr/bin/X` to be a symlink to the Qubes X Wrapper, which, in turn, executes the `/usr/bin/Xorg`. This works well with KDM (and would probably also work with other X login managers), but not with GDM. If somebody succeeded in makeing GDM to execute `/usr/bin/X` instead of `/usr/bin/Xorg`, we would love to hear about it! @@ -40,13 +40,4 @@ 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. 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. Send your patch to qubes-devel. Start the message subject with the '[PATCH]' string. - +See [Qubes Source Code Repositories](/doc/SourceCode/). diff --git a/SourceCode.md b/SourceCode.md index 40697b19..4afa7631 100644 --- a/SourceCode.md +++ b/SourceCode.md @@ -33,5 +33,16 @@ git clone git://github.com/QubesOS/qubes-core-admin.git core-admin If you want to contribute to the project, there are two preferred ways: -1. Use github [fork & pull requests](https://guides.github.com/activities/forking/) -2. [sending a patch](/doc/DevelFaq/#q-how-do-i-submit-a-patch) via the project's mailing list (`git format-patch`). +1. Use github [fork & pull requests](https://guides.github.com/activities/forking/) +2. [sending a patch](/doc/DevelFaq/#q-how-do-i-submit-a-patch) via the project's mailing list (`git format-patch`). + +## Sending 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. + +2. 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). + +3. Test your changes NOW: check if RPMs build fine, etc. + +4. 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. + +5. Send your patch to qubes-devel. Start the message subject with the '[PATCH]' string. From b856595ba0e413d582bc7838ac95e331a7244191 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Wed, 22 Jul 2015 03:57:31 +0200 Subject: [PATCH 043/174] yubikey: add screen locking instruction --- YubiKey.md | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/YubiKey.md b/YubiKey.md index 62ac3e0f..8f8b5e37 100644 --- a/YubiKey.md +++ b/YubiKey.md @@ -92,3 +92,44 @@ When everything is ok, your screen will be unlocked. In any case you can still use your login password, but do it in secure location where no one can snoop your password. + +Locking the screen when YubiKey is removed +------------------------------------------ + +You can setup your system to automatically lock the screen when you unplug +YubiKey. This will require creating simple qrexec service which will expose +ability to lock the screen to your USB VM, and then adding udev hook to +actually call that service. + +1. First configure the qrexec service. Create `/etc/qubes-rpc/custom.LockScreen` (in dom0) + with simple command to lock the screen. In case of xscreensaver (used in Xfce) + it would be: + + DISPLAY=:0 xscreensaver-command -lock + +2. Allow your USB VM to call that service. Assuming that its named `sys-usb` it +would require creating `/etc/qubes-rpc/policy/custom.LockScreen` with: + + sys-usb dom0 allow + +3. Create udev hook in your USB VM. Store it in `/rw/config` to have it +persistent across VM restarts. For example name the file +`/rw/config/yubikey.rules`. Write there single line: + + ACTION=="remove", SUBSYSTEM=="usb", ENV{ID_SECURITY_TOKEN}=="1", RUN+="/usr/bin/qrexec-client-vm dom0 custom.LockScreen" + +4. Ensure that the udev hook is placed in the right place after VM restart. Append to `/rw/config/rc.local`: + + ln -s /rw/config/yubikey.rules /etc/udev/rules.d/ + udevadm control --reload + + Then make `/rw/config/rc.local` executable. For changes to take effect, you + need to call this script manually for the first time. + +If you use KDE, the command(s) in first step would be different: + + # In case of USB VM being autostarted, it will not have direct access to D-Bus + # session bus, so find its address manually: + kde_pid=`pidof kdeinit4` + export `cat /proc/$kde_pid/environ|grep -ao 'DBUS_SESSION_BUS_ADDRESS=[[:graph:]]*'` + qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock From f4848980b3431abe1c44352d7532b146a3b5bfe3 Mon Sep 17 00:00:00 2001 From: Wojtek Porczyk Date: Wed, 22 Jul 2015 21:29:33 +0200 Subject: [PATCH 044/174] QubesDownloads: New mirror infrastructure --- QubesDownloads.md | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/QubesDownloads.md b/QubesDownloads.md index 0fd2bf58..f40d4c06 100644 --- a/QubesDownloads.md +++ b/QubesDownloads.md @@ -18,8 +18,10 @@ Qubes Downloads Qubes Release 3.0 --------------- -- [Qubes-R3.0-rc1-x86\_64-DVD.iso](http://sourceforge.net/projects/qubesos/files/Qubes-R3.0-rc1-x86_64-DVD.iso/download) (via sourceforge.net) -- [Digital Signature](http://sourceforge.net/projects/qubesos/files/Qubes-R3.0-rc1-x86_64-DVD.iso.asc/download) (via sourceforge.net) +- [Qubes-R3.0-rc1-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc1-x86_64-DVD.iso) (mirror 1) +- [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc1-x86_64-DVD.iso.asc) (mirror 1) +- [Qubes-R3.0-rc1-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc1-x86_64-DVD.iso) (mirror 2) +- [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc1-x86_64-DVD.iso.asc) (mirror 2) - **[Installation Guide for Qubes R3.0 rc1](/doc/InstallationGuideR3.0rc1/)** - [Upgrading to Qubes R3.0 rc1](/doc/InstallationGuideR3.0rc1/#upgrading) @@ -27,16 +29,15 @@ Qubes Release 3.0 Qubes Release 2 --------------- -- [Qubes-R2-x86\_64-DVD.iso](http://sourceforge.net/projects/qubesos/files/Qubes-R2-x86_64-DVD.iso/download) (via sourceforge.net) -- [Digital Signature](http://sourceforge.net/projects/qubesos/files/Qubes-R2-x86_64-DVD.iso.asc/download) (via sourceforge.net) +- [Qubes-R2-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R2-x86_64-DVD.iso) (mirror 1) +- [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R2-x86_64-DVD.iso.asc) (mirror 1) +- [Qubes-R2-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R2-x86_64-DVD.iso) (mirror 2) +- [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R2-x86_64-DVD.iso.asc) (mirror 2) - **[Installation Guide for Qubes R2](/doc/InstallationGuideR2/)** - [Upgrading to Qubes R2](/doc/InstallationGuideR2/#upgrading) -- [Qubes-R2-rc2-x86\_64-DVD.iso](http://sourceforge.net/projects/qubesos/files/Qubes-R2-rc2-x86_64-DVD.iso/download) (via sourceforge.net) -- [Digital Signature](http://sourceforge.net/projects/qubesos/files/Qubes-R2-rc2-x86_64-DVD.iso.asc/download) (via sourceforge.net) - -- **[Installation Guide for Qubes R2 rc2](/doc/InstallationGuideR2rc2/)** +- **[Installation Guide for Qubes R2 rc2](/doc/InstallationGuideR2rc2/)** (deprecated) - [Upgrading to Qubes R2 rc2](/doc/InstallationGuideR2rc2/#upgrading) Qubes Release 1 @@ -44,8 +45,10 @@ Qubes Release 1 (This is mainly for historical reference, we strongly recommend Qubes R2 above) -- [Qubes-R1-x86\_64-DVD.iso](http://sourceforge.net/projects/qubesos/files/Qubes-R1-x86_64-DVD.iso/download) (via sourceforge.net) -- [Digital Signature](http://sourceforge.net/projects/qubesos/files/Qubes-R1-x86_64-DVD.iso.asc/download) (via sourceforge.net) +- [Qubes-R1-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R1-x86_64-DVD.iso) (mirror 1) +- [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R1-x86_64-DVD.iso.asc) (mirror 1) +- [Qubes-R1-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R1-x86_64-DVD.iso) (mirror 2) +- [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R1-x86_64-DVD.iso.asc) (mirror 2) - **[Installation Guide](/doc/InstallationGuide/)** From 1d80a57af38b7aead452b2afef570741b90a6847 Mon Sep 17 00:00:00 2001 From: Robin Schneider Date: Thu, 23 Jul 2015 13:19:16 +0200 Subject: [PATCH 045/174] Updated docs, fixed spelling and use Markdown code syntax for commands. * Add FIXMEs. --- AutomatedTests.md | 2 +- BugReportingGuide.md | 6 ++--- CodingStyle.md | 18 +++++++-------- DevelFaq.md | 4 ++-- DevelopmentWorkflow.md | 6 +++-- DocStyle.md | 4 ++-- Donations.md | 6 ++--- Fetchmail.md | 2 +- InstallSecurity.md | 2 +- NetworkPrinter.md | 10 ++++----- SecurityCriticalCode.md | 2 +- TemplateImplementation.md | 46 +++++++++++++++++++-------------------- VPN.md | 16 +++++++------- community.md | 8 +++---- 14 files changed, 67 insertions(+), 65 deletions(-) diff --git a/AutomatedTests.md b/AutomatedTests.md index 4581d6e6..2f7fab71 100644 --- a/AutomatedTests.md +++ b/AutomatedTests.md @@ -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 diff --git a/BugReportingGuide.md b/BugReportingGuide.md index f76d5175..9ba46aed 100644 --- a/BugReportingGuide.md +++ b/BugReportingGuide.md @@ -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! diff --git a/CodingStyle.md b/CodingStyle.md index 6283502e..a26c6561 100644 --- a/CodingStyle.md +++ b/CodingStyle.md @@ -2,7 +2,7 @@ layout: doc title: CodingStyle permalink: /doc/CodingStyle/ -redirect_from: +redirect_from: - /wiki/CodingStyle/ - /trac/wiki/CodingStyle/ --- @@ -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 ----------------------------- diff --git a/DevelFaq.md b/DevelFaq.md index 64f74fbc..10fd892b 100644 --- a/DevelFaq.md +++ b/DevelFaq.md @@ -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. diff --git a/DevelopmentWorkflow.md b/DevelopmentWorkflow.md index 4f356097..c32016ef 100644 --- a/DevelopmentWorkflow.md +++ b/DevelopmentWorkflow.md @@ -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 diff --git a/DocStyle.md b/DocStyle.md index b2617c44..b24a010c 100644 --- a/DocStyle.md +++ b/DocStyle.md @@ -18,7 +18,7 @@ Guidelines for Documentation Contributors * In the event that a user is required to read the Markdown source directly, this will make it easier to follow, e.g., numbered steps in a set of instructions. - * Use hanging indentations + * Use hanging indentations where appropriate. - * Use `[reference-style][ref]` links. + * Use `[reference-style][ref]` links. `[ref]: http://daringfireball.net/projects/markdown/syntax#link` diff --git a/Donations.md b/Donations.md index 612da95b..386eba81 100644 --- a/Donations.md +++ b/Donations.md @@ -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? diff --git a/Fetchmail.md b/Fetchmail.md index 1505257d..7c35a6b8 100644 --- a/Fetchmail.md +++ b/Fetchmail.md @@ -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 ------------ diff --git a/InstallSecurity.md b/InstallSecurity.md index df83e78f..d9766bd8 100644 --- a/InstallSecurity.md +++ b/InstallSecurity.md @@ -61,7 +61,7 @@ Cons: 1. Use a USB optical drive. 2. Attach a SATA optical drive to a secondary SATA controller, then assign this secondary SATA controller to an AppVM. - 3. Use a SATA optical drive attached to dom0. + 3. Use a SATA optical drive attached to dom0. (Option 3 violates the Qubes security model since it entails transferring an untrusted ISO to dom0 in order to burn it to disc, which leaves only the other two options.) diff --git a/NetworkPrinter.md b/NetworkPrinter.md index 447f759b..43b38c52 100644 --- a/NetworkPrinter.md +++ b/NetworkPrinter.md @@ -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. diff --git a/SecurityCriticalCode.md b/SecurityCriticalCode.md index b6adc98c..18251e5c 100644 --- a/SecurityCriticalCode.md +++ b/SecurityCriticalCode.md @@ -2,7 +2,7 @@ layout: doc title: SecurityCriticalCode permalink: /doc/SecurityCriticalCode/ -redirect_from: +redirect_from: - /wiki/SecurityCriticalCode/ - /trac/wiki/SecurityCriticalCode/ --- diff --git a/TemplateImplementation.md b/TemplateImplementation.md index ee9b068d..e5b55cd1 100644 --- a/TemplateImplementation.md +++ b/TemplateImplementation.md @@ -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 ------------ diff --git a/VPN.md b/VPN.md index 39c2f4f6..774e336f 100644 --- a/VPN.md +++ b/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:** diff --git a/community.md b/community.md index 252817ce..76f21f5f 100644 --- a/community.md +++ b/community.md @@ -12,12 +12,12 @@ Add **Qubes OS** to refine your query, you might find just what you need. ## [QubesOS Mailing Lists]({{ site.url }}{{ site.baseurl }}/doc/QubesLists/) -- Please send all the questions regarding Qubes OS to one of [these]({{ site.url }}{{ site.baseurl }}/doc/QubesLists/) mailing lists. +- Please send all the questions regarding Qubes OS to one of [these]({{ site.url }}{{ site.baseurl }}/doc/QubesLists/) mailing lists. - To subscribe to the user list, send a blank mail to `qubes-users+subscribe@googlegroups.com`. -- By sending a message to the appropriate mailing list, you are not only giving others a chance to help you, +- By sending a message to the appropriate mailing list, you are not only giving others a chance to help you, but you may also be helping others by starting a public discussion about a shared problem or interest. -- **Please do not send questions to individual Qubes developers.** -- **Please do not [top-post](https://en.wikipedia.org/wiki/Posting_style), use inline replying or bottom-posting instead.** +- **Please do not send questions to individual Qubes developers.** +- **Please do not [top-post](https://en.wikipedia.org/wiki/Posting_style), use inline replying or bottom-posting instead.** ## [QubesOS/qubes-doc]({{ site.url }}{{ site.baseurl }}/doc/UserFaq/#qubes-users-faq) From ff0360e5c7fa65d4ebfb059cac423b085ad8dd4c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Sat, 25 Jul 2015 04:30:05 +0200 Subject: [PATCH 046/174] StickMounting: formatting --- StickMounting.md | 24 ++++++++++++++---------- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/StickMounting.md b/StickMounting.md index 83d1a342..976ea84c 100644 --- a/StickMounting.md +++ b/StickMounting.md @@ -24,13 +24,17 @@ A command-line tool, `qvm-block`, is also available. This tool can be used to as qvm-block -l {% endhighlight %} -> This will list all available block devices connected to any USB controller in your system, no matter in which VM hosts the controller. The name of the VM hosting the USB controller is displayed before the colon in the device name. The string after the colon is the name of the device used within the VM. + This will list all available block devices connected to any USB controller + in your system, no matter in which VM hosts the controller. The name of the + VM hosting the USB controller is displayed before the colon in the device + name. The string after the colon is the name of the device used within the + VM. -> **Note:** If your device is not listed here, you may refresh the list by calling (from the VM to which device is connected): -> -> {% highlight trac-wiki %} -> sudo udevadm trigger --action=change -> {% endhighlight %} + **Note:** If your device is not listed here, you may refresh the list by calling (from the VM to which device is connected): + + {% highlight trac-wiki %} + sudo udevadm trigger --action=change + {% endhighlight %} 1. Connect the device to an AppVM: @@ -40,7 +44,7 @@ A command-line tool, `qvm-block`, is also available. This tool can be used to as **Note:** The order of these parameters was changed in Qubes 1.0-rc1. -> This will attach the device as "/dev/xvdi" in the AppVM. + This will attach the device as "/dev/xvdi" in the AppVM. 1. The USB stick is now attached to the AppVM. If using a default AppVM, you may open Nautilus file manager in the AppVM, and your stick should be visible in the **Devices** panel on the left. @@ -48,9 +52,9 @@ A command-line tool, `qvm-block`, is also available. This tool can be used to as 1. In a dom0 console, unmount the stick: -{% highlight trac-wiki %} -qvm-block -d -{% endhighlight %} + {% highlight trac-wiki %} + qvm-block -d + {% endhighlight %} 1. You may now remove the device. From 6254028b0e80b4a4412338afc342fb8f4fd8d3d7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Sat, 25 Jul 2015 04:30:15 +0200 Subject: [PATCH 047/174] StickMounting: warning to not remove the stick before detaching it from a VM --- StickMounting.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/StickMounting.md b/StickMounting.md index 976ea84c..4e3bddc8 100644 --- a/StickMounting.md +++ b/StickMounting.md @@ -50,7 +50,7 @@ A command-line tool, `qvm-block`, is also available. This tool can be used to as 1. When you finish using your USB stick, click the eject button or right-click and select **Unmount**. -1. In a dom0 console, unmount the stick: +1. In a dom0 console, detach the stick: {% highlight trac-wiki %} qvm-block -d @@ -58,3 +58,6 @@ A command-line tool, `qvm-block`, is also available. This tool can be used to as 1. You may now remove the device. +**Warning: Do not remove the device before detatching it from the VM!** Otherwise you +will not be able to attach it anywhere later. See [this +ticket](https://github.com/QubesOS/qubes-issues/issues/1082) for details. From 955e2ec3960e6a214e6ab11f2916112132d9e400 Mon Sep 17 00:00:00 2001 From: Noah Vesely Date: Sun, 26 Jul 2015 05:23:25 -0700 Subject: [PATCH 048/174] A different proposal for explaining USB issues I thought this version provides the reader with a better idea of their options. I would still like to know how to recover from accidentally removing a USB stick before detaching it from the VM w/o rebooting. I think it would be great if we could include instructions here on how to do it. --- StickMounting.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/StickMounting.md b/StickMounting.md index 83d1a342..6242e8e0 100644 --- a/StickMounting.md +++ b/StickMounting.md @@ -10,11 +10,11 @@ How to Mount USB Sticks to AppVMs (**Note:** In the present context, the term "USB stick" denotes any [USB mass storage device](https://en.wikipedia.org/wiki/USB_mass_storage_device_class). In addition to smaller flash memory sticks, this includes things like USB external hard drives.) -Qubes supports the ability to mount a USB stick to any AppVM easily, no matter which VM actually handles the USB controller. (The USB controller may be assigned on the **Devices** tab of an AppVM's settings page in Qubes VM Manager or by using the [qvm-pci command](/doc/AssigningDevices/).) +Qubes supports the ability to attach a USB stick (or just one or more of its partitions) to any AppVM easily, no matter which VM actually handles the USB controller. (The USB controller may be assigned on the **Devices** tab of an AppVM's settings page in Qubes VM Manager or by using the [qvm-pci command](/doc/AssigningDevices/).) -As of Qubes R2 Beta 3, USB stick mounting has been integrated into the Qubes VM Manger GUI. Simply insert your USB stick, right-click the desired AppVM in the Qubes VM Manager list, click **Attach/detach block devices**, and select your desired action and device. +As of Qubes R2 Beta 3, USB stick mounting has been integrated into the Qubes VM Manger GUI. Simply insert your USB stick, right-click the desired AppVM in the Qubes VM Manager list, click **Attach/detach block devices**, and select your desired action and device. This, however, only works for the whole device. If you would like to attach individual partitions you must use the command-line tool (shown below). The reason for this is that when attaching a single partition, it used to be that Nautilus file manager would not see it and automatically mount it (see [this ticket](https://github.com/QubesOS/qubes-issues/issues/623)). This problem, however, seems to be resolved (see [this issue comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124270051)). If for some reason it does not show up in nautilus for you and you still need to attach just a single partition to a device, you will need to mount it manually; the device will show up as /dev/xvdi (or /dev/xvdj if there is already one device attached--/dev/xvdk and so on). -A command-line tool, `qvm-block`, is also available. This tool can be used to assign a USB stick to an AppVM as follows: +The command-line tool you may use to mount whole USB sticks or their partitions is `qvm-block`. This tool can be used to assign a USB stick to an AppVM as follows: 1. Insert your USB stick. @@ -24,23 +24,23 @@ A command-line tool, `qvm-block`, is also available. This tool can be used to as qvm-block -l {% endhighlight %} -> This will list all available block devices connected to any USB controller in your system, no matter in which VM hosts the controller. The name of the VM hosting the USB controller is displayed before the colon in the device name. The string after the colon is the name of the device used within the VM. +This will list all available block devices connected to any USB controller in your system, no matter in which VM hosts the controller. The name of the VM hosting the USB controller is displayed before the colon in the device name. The string after the colon is the name of the device used within the VM. -> **Note:** If your device is not listed here, you may refresh the list by calling (from the VM to which device is connected): -> -> {% highlight trac-wiki %} -> sudo udevadm trigger --action=change -> {% endhighlight %} +**Note:** If your device is not listed here, you may refresh the list by calling (from the VM to which device is connected): -1. Connect the device to an AppVM: +{% highlight trac-wiki %} +sudo udevadm trigger --action=change +{% endhighlight %} + +1. Assuming our USB stick is sdb, we attach the device to an AppVM like so: {% highlight trac-wiki %} - qvm-block -a personal dom0:sda + qvm-block -a personal dom0:sdb {% endhighlight %} - **Note:** The order of these parameters was changed in Qubes 1.0-rc1. +This will attach the device as "/dev/xvdi", if not already taken by another attached device, in the AppVM. You may also mount one partition at a time by using the same command with the partition number after sdb. -> This will attach the device as "/dev/xvdi" in the AppVM. +**Warning: when working with single partitions, it is possible to assign the same partition to multiple VMs.** For example, you could attach sdb1 to VM1 and then sdb to VM2. It is up to the user not to make this mistake. Xen block device framework currently does not provide an easy way around this. Point 2 of [this ticket comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124119309) gives details on this. 1. The USB stick is now attached to the AppVM. If using a default AppVM, you may open Nautilus file manager in the AppVM, and your stick should be visible in the **Devices** panel on the left. @@ -54,3 +54,4 @@ qvm-block -d 1. You may now remove the device. +**Warning: Do not remove the device before detatching it from the VM!** Otherwise you will not be able to attach it anywhere later. See point 3 of [this ticket comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124119309) for details. From 04b94d858abd11fb69c924edea30b4d6bd1e1735 Mon Sep 17 00:00:00 2001 From: Hakisho Nukama Date: Mon, 27 Jul 2015 12:30:00 +0000 Subject: [PATCH 049/174] Fixed merge conflict, finally. --- DevelFaq.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/DevelFaq.md b/DevelFaq.md index 0eec18f9..2a7783b1 100644 --- a/DevelFaq.md +++ b/DevelFaq.md @@ -41,13 +41,3 @@ See [the instruction](/doc/QubesBuilder/) ### Q: How do I submit a patch? See [Qubes Source Code Repositories](/doc/SourceCode/). -======= -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. Send your patch to qubes-devel. Start the message subject with the '[PATCH]' string. From 45cfedf0c454af9eb7d5b52bb11b5c79e9867eca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Wojdy=C5=82a?= Date: Tue, 28 Jul 2015 05:46:55 +0200 Subject: [PATCH 050/174] add instructions for uninstalling Windows Tools 2.x --- UninstallingWindowsTools2.md | 123 +++++++++++++++++++++++++++++++++++ UserDoc.md | 1 + WindowsTools2.md | 5 +- 3 files changed, 128 insertions(+), 1 deletion(-) create mode 100644 UninstallingWindowsTools2.md diff --git a/UninstallingWindowsTools2.md b/UninstallingWindowsTools2.md new file mode 100644 index 00000000..8062519e --- /dev/null +++ b/UninstallingWindowsTools2.md @@ -0,0 +1,123 @@ +--- +layout: doc +title: UninstallingWindowsTools2 +permalink: /doc/UninstallingWindowsTools2/ +redirect_from: /wiki/UninstallingWindowsTools2/ +--- + +Uninstalling Qubes Tools for Windows v2.x +========================================= + +**Do not try to uninstall Qubes Tools for Windows (QTW) 2.x from Windows Control Panel. It will render your HVM unbootable and will require manual fixing.** + +Preface +------- + +Version 2.x of QTW (used for Windows HVMs in Qubes R2) is difficult to uninstall due to issues with the Xen GPL PV drivers package that is used. However, uninstalling QTW version 2.x is required to migrate the HVM to Qubes R3. +HVMs with QTW 2.x *will not boot normally in Qubes R3* due to Xen drivers failing. They will boot in Safe Mode. It's easier to uninstall QTW 2.x from Qubes R2, but if that's not an option it's also possible in Qubes R3 (just a bit more complicated). Details below. + +Uninstalling QTW 2.x in Qubes R2 +-------------------------------- + +1. Copy the uninstall script posted at the end of this document and save it in the HVM as a .BAT file. +2. Reboot the HVM in Safe Mode: type `bcdedit /set safeboot minimal` in a command prompt with admin privileges then restart normally. The OS will now always start in Safe Mode until the setting is reverted. +3. In Safe Mode execute the uninstall script from step 1. +4. Open Device Manager. Manually uninstall Qubes Video device (in 'Display adapters') and Xen PCI driver (in 'System devices'). This will prevent the (already removed) devices from showing up. +5. Type `bcdedit /deletevalue safeboot` in a command prompt to disable Safe Mode boot. +6. Reboot. Open Device Manager and verify that there are no active Xen PV devices: + - There should be one unidentified PCI device in System devices (this is the Xen PV device, not functioning because PV drivers are inactive). + - Disk drives should be QEMU (emulated). + - Network adapter should be Realtek (emulated). + +Now you can backup the HVM, migrate it to Qubes R3 and install QTW 3.x there. + +Uninstalling QTW 2.x in Qubes R3 +-------------------------------- + +HVMs with QTW 2.x will not boot normally in Qubes R3 due to the old Xen drivers failing. If removing QTW from Qubes R2 is not an option (see above) then you will need to boot the HVM in Safe Mode. + +### Preparation in dom0 + +Disable VM tools in VM's preferences: +* `qvm-prefs -s vmname qrexec_installed false` +* `qvm-prefs -s vmname guiagent_installed false` + +### Enabling Safe Mode +* If you're quick you can mash F8 just as the HVM boots to access Windows' advanced boot options. The timing for it is very tight though. If you manage to get the boot menu, select Safe Mode boot. +* Alternatively, allow the HVM to (try to) boot. It will crash with a BSOD. +* After the crash start the HVM again. Now Windows will display the recovery menu which, for some unknown reason, does not include Safe Mode boot option. We need to try harder. +* Select **Launch Startup Repair**. +* If you're prompted to try System Restore, **don't**. Hit cancel. +* Grab a drink or read a book while Windows tries to do something but ultimately the repair process fails. +* *Now* you're presented with a choice of *advanced options* that include a command prompt. Why isn't this available from the start? +* Launch the command prompt, log in and type `bcdedit /set {default} safeboot minimal`. The OS will now always start in Safe Mode until the setting is reverted. +* Reboot and proceed with the uninstallation instructions from the previous paragraph (*Uninstalling QTW 2.x in Qubes R2*). + +If you need network access to copy the uninstall script to the HVM, use *Safe Mode with Networking* instead of pure Safe Mode (replace `minimal` with `network` in the bcdedit commands above). Disable the Xen PV network device first. You may need to manually configure IP settings for the emulated Realtek adapter. + + +The uninstall script +==================== + +Save it as a .BAT file in the HVM and run in Safe Mode. + +``` +@echo off + +:: This batch file uninstalls Qubes Tools for Windows version 2.x +:: Needs to be run in safe mode + +:: Registry cleanup +reg delete "HKLM\Software\Invisible Things Lab" /f + +:: services/drivers +reg delete HKLM\System\CurrentControlSet\Services\ShutdownMon /f +reg delete HKLM\System\CurrentControlSet\Services\QrexecAgent /f +reg delete HKLM\System\CurrentControlSet\Services\QTWHelper /f +reg delete HKLM\System\CurrentControlSet\Services\QubesNetworkSetup /f +reg delete HKLM\System\CurrentControlSet\Services\QVideo /f +reg delete HKLM\System\CurrentControlSet\Services\XenNet /f +reg delete HKLM\System\CurrentControlSet\Services\XenPCI /f +reg delete HKLM\System\CurrentControlSet\Services\XenVbd /f + +:: xenpci filter entries +reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E96A-E325-11CE-BFC1-08002BE10318} /v UpperFilters /f +reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318} /v UpperFilters /f +reg delete HKLM\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318} /v UpperFilters /f + +:: files +rmdir /q /s "%ProgramFiles%\Invisible Things Lab" +rmdir /q /s "%ProgramFiles%\Xen PV Drivers" + +del /q /s "%windir%\system32\move-profiles.exe" +del /q /s "%windir%\system32\windows-utils.dll" +del /q /s "%windir%\system32\qvgdi.dll" +del /q /s "%windir%\system32\drivers\qvmini.sys" +del /q /s "%windir%\system32\drivers\xennet.sys" +del /q /s "%windir%\system32\drivers\xenpci.sys" +del /q /s "%windir%\system32\drivers\xenvbd.sys" + +:: driver store entries +FOR /F "delims=. tokens=1" %%I IN ('DIR /B "%SYSTEMROOT%\INF\OEM*.INF"') DO ( + TYPE "%SYSTEMROOT%\INF\%%I.inf" | FIND /c /i "Xen GPL PV" >%TEMP%\qtwuninstall + FOR /f %%c IN (%TEMP%\qtwuninstall) DO ( + IF /I %%c NEQ 0 ( + DEL "%SYSTEMROOT%\INF\%%I.inf" + DEL "%SYSTEMROOT%\INF\%%I.pnf" + ) + ) +) + +FOR /F "delims=. tokens=1" %%I IN ('DIR /B "%SYSTEMROOT%\INF\OEM*.INF"') DO ( + TYPE "%SYSTEMROOT%\INF\%%I.inf" | FIND /c /i "Qubes" >%TEMP%\qtwuninstall + FOR /f %%c IN (%TEMP%\qtwuninstall) DO ( + IF /I %%c NEQ 0 ( + DEL "%SYSTEMROOT%\INF\%%I.inf" + DEL "%SYSTEMROOT%\INF\%%I.pnf" + ) + ) +) + +echo. +echo Cleanup finished. Please manually uninstall Qubes Video and Xen devices from the Device Manager. +``` diff --git a/UserDoc.md b/UserDoc.md index 3a39c53a..395db673 100644 --- a/UserDoc.md +++ b/UserDoc.md @@ -76,6 +76,7 @@ Qubes User Documentation 1. [Installing and Using Windows-based AppVMs (Qubes R2 Beta 3 and later)](/doc/WindowsAppVms/) 2. [Advanced options and troubleshooting of Qubes Tools for Windows (R3)](/doc/WindowsTools3/) 3. [Advanced options and troubleshooting of Qubes Tools for Windows (R2)](/doc/WindowsTools2/) + 1. [Uninstalling Qubes Tools for Windows 2.x](/doc/UninstallingWindowsTools2/) 9. Advanced Topics 1. [Configuration files](/doc/UserDoc/ConfigFiles/) diff --git a/WindowsTools2.md b/WindowsTools2.md index fc358e73..d94a30c8 100644 --- a/WindowsTools2.md +++ b/WindowsTools2.md @@ -31,7 +31,10 @@ If the install process fails you can retry it using the command line below to ge `msiexec /i path-to-qubes-tools.msi /lv path-to-log-file.txt` -Uninstalling QTW 2.x is **not recommended**. It will most likely make the OS non-bootable because drivers for Xen storage devices will be uninstalled. +Uninstalling +------------ + +See [this page](/doc/UninstallingWindowsTools2/). Configuration ------------- From d84879411d1196b2a3038bd57a88d842e05c7791 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Fri, 31 Jul 2015 17:42:32 +0200 Subject: [PATCH 051/174] Instruction how to recover from prematurely detached device --- StickMounting.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/StickMounting.md b/StickMounting.md index 0f7f3494..78fa1c7a 100644 --- a/StickMounting.md +++ b/StickMounting.md @@ -62,3 +62,36 @@ This will attach the device as "/dev/xvdi", if not already taken by another atta **Warning: Do not remove the device before detatching it from the VM!** Otherwise you will not be able to attach it anywhere later. See [this ticket](https://github.com/QubesOS/qubes-issues/issues/1082) for details. + + +What if I removed the device before detaching it from the VM? +------------------------------------------------------------ + +Currently (until [this +ticket](https://github.com/QubesOS/qubes-issues/issues/1082) got implemented), +if you remove the device before detaching it from the VM, Qubes (more precisely +- libvirtd) will think that the device is still attached to the VM and will not +allow attaching further devices under the same name. The easiest way to recover +from such situation is to reboot the VM to which device was attached. But if +this isn't an option, you can manually recover from the situation by following +this steps: + +1. Physically connect the device back. You can use any device as long as it + will be detected under the same name (for example `sdb`). +2. Attach the device manually to the same VM using `xl block-attach` command. + It is important to use the same "frontend" device name (by default `xvdi`) - + you can get it from `qvm-block` listing: + + [user@dom0 ~]$ qvm-block + sys-usb:sda DataTraveler_2.0 () 246 MiB (attached to 'testvm' as 'xvdi') + [user@dom0 ~]$ xl block-attach testvm phy:/dev/sda backend=sys-usb xvdi + + In above example all `xl block-attach` parameters can be deducted from + `qvm-block` output. In order: + + * `testvm` - name of target VM to which device was attached - listed in brackets by `qvm-block` command + * `phy:/dev/sda` - physical path at which device appears in source VM (just after source VM name in `qvm-block` output) + * `backend=sys-usb` - name of source VM, can be omitted in case of dom0 + * `xvdi` - "frontend" device name (listed at the end of line in `qvm-block` output + +3. Now properly detach the device, either using Qubes Manager, or `qvm-block -d` command. From 0a64f016ed124292f2b5ef738cf1a52306e17a09 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Fri, 31 Jul 2015 18:03:46 +0200 Subject: [PATCH 052/174] StickMounting: formatting --- StickMounting.md | 36 ++++++++++++++---------------------- 1 file changed, 14 insertions(+), 22 deletions(-) diff --git a/StickMounting.md b/StickMounting.md index 78fa1c7a..2e1b65b1 100644 --- a/StickMounting.md +++ b/StickMounting.md @@ -20,9 +20,7 @@ The command-line tool you may use to mount whole USB sticks or their partitions 1. In a dom0 console (running as normal user), list all available block devices: - {% highlight trac-wiki %} - qvm-block -l - {% endhighlight %} + qvm-block -l This will list all available block devices connected to any USB controller in your system, no matter in which VM hosts the controller. The name of the @@ -32,20 +30,16 @@ The command-line tool you may use to mount whole USB sticks or their partitions **Note:** If your device is not listed here, you may refresh the list by calling (from the VM to which device is connected): - {% highlight trac-wiki %} - sudo udevadm trigger --action=change - {% endhighlight %} + sudo udevadm trigger --action=change 1. Assuming our USB stick is sdb, we attach the device to an AppVM like so: - {% highlight trac-wiki %} - qvm-block -a personal dom0:sdb - {% endhighlight %} + qvm-block -a personal dom0:sdb + + This will attach the device as "/dev/xvdi", if not already taken by another attached device, in the AppVM. You may also mount one partition at a time by using the same command with the partition number after sdb. -This will attach the device as "/dev/xvdi", if not already taken by another attached device, in the AppVM. You may also mount one partition at a time by using the same command with the partition number after sdb. - -**Warning: when working with single partitions, it is possible to assign the same partition to multiple VMs.** For example, you could attach sdb1 to VM1 and then sdb to VM2. It is up to the user not to make this mistake. Xen block device framework currently does not provide an easy way around this. Point 2 of [this ticket comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124119309) gives details on this. + **Warning: when working with single partitions, it is possible to assign the same partition to multiple VMs.** For example, you could attach sdb1 to VM1 and then sdb to VM2. It is up to the user not to make this mistake. Xen block device framework currently does not provide an easy way around this. Point 2 of [this ticket comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124119309) gives details on this. 1. The USB stick is now attached to the AppVM. If using a default AppVM, you may open Nautilus file manager in the AppVM, and your stick should be visible in the **Devices** panel on the left. @@ -53,9 +47,7 @@ This will attach the device as "/dev/xvdi", if not already taken by another atta 1. In a dom0 console, detach the stick: - {% highlight trac-wiki %} - qvm-block -d - {% endhighlight %} + qvm-block -d 1. You may now remove the device. @@ -82,16 +74,16 @@ this steps: It is important to use the same "frontend" device name (by default `xvdi`) - you can get it from `qvm-block` listing: - [user@dom0 ~]$ qvm-block - sys-usb:sda DataTraveler_2.0 () 246 MiB (attached to 'testvm' as 'xvdi') - [user@dom0 ~]$ xl block-attach testvm phy:/dev/sda backend=sys-usb xvdi + [user@dom0 ~]$ qvm-block + sys-usb:sda DataTraveler_2.0 () 246 MiB (attached to 'testvm' as 'xvdi') + [user@dom0 ~]$ xl block-attach testvm phy:/dev/sda backend=sys-usb xvdi In above example all `xl block-attach` parameters can be deducted from `qvm-block` output. In order: - * `testvm` - name of target VM to which device was attached - listed in brackets by `qvm-block` command - * `phy:/dev/sda` - physical path at which device appears in source VM (just after source VM name in `qvm-block` output) - * `backend=sys-usb` - name of source VM, can be omitted in case of dom0 - * `xvdi` - "frontend" device name (listed at the end of line in `qvm-block` output + * `testvm` - name of target VM to which device was attached - listed in brackets by `qvm-block` command + * `phy:/dev/sda` - physical path at which device appears in source VM (just after source VM name in `qvm-block` output) + * `backend=sys-usb` - name of source VM, can be omitted in case of dom0 + * `xvdi` - "frontend" device name (listed at the end of line in `qvm-block` output 3. Now properly detach the device, either using Qubes Manager, or `qvm-block -d` command. From 7e8aa4eb50b30117a79d9215414108fbf7ba60c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Fri, 31 Jul 2015 18:47:25 +0200 Subject: [PATCH 053/174] Update list of default qrexec services --- SystemDoc/VMInterface.md | 58 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 54 insertions(+), 4 deletions(-) diff --git a/SystemDoc/VMInterface.md b/SystemDoc/VMInterface.md index a28407cf..01cf1eff 100644 --- a/SystemDoc/VMInterface.md +++ b/SystemDoc/VMInterface.md @@ -51,10 +51,60 @@ Qubes RPC Services called by dom0 to provide some VM configuration: -- qubes.SetMonitorLayout - provide list of monitors, one in a line, each line contains four numbers: width height X Y -- qubes.WaitForSession - called to wait for full VM startup -- qubes.GetAppmenus - receive appmenus from given VM (template); TODO: describe format here -- qubes.GetImageRGBA - receive image/application icon: TODO: describe format and parameters here +- `qubes.SetMonitorLayout` - provide list of monitors, one in a line, each line contains four numbers: `width height X Y` +- `qubes.WaitForSession` - called to wait for full VM startup +- `qubes.GetAppmenus` - receive appmenus from given VM (template); TODO: describe format here +- `qubes.GetImageRGBA` - receive image/application icon: TODO: describe format and parameters here +- `qubes.SetDateTime` - set VM time, called periodically by dom0 (can be + triggered manually from dom0 by calling `qvm-sync-clock`). The service + receives one line at stdin - time in format of `date -u -Iseconds`, for + example `2015-07-31T16:10:43+0000`. +- `qubes.SetGuiMode` - called in HVM to switch between fullscreen and seamless + GUI mode. The service receives a single word on stdin - either `FULLSCREEN` + or `SEAMLESS` + + +Other Qrexec services installed by default: + +- `qubes.Backup` - store Qubes backup. The service receives location chosen by + the user (one line, terminated by '\n'), the backup archive ([description of + backup format](/doc/BackupEmergencyRestoreV2/)) +- `qubes.DetachPciDevice` - service called in reaction to `qvm-pci -d` call on + running VM. The service receives one word - BDF of device to detach. When the + service call ends, the device will be detached +- `qubes.Filecopy` - receive some files from other VM. Files sent in [qfile format](/doc/Qfilecopy/) +- `qubes.OpenInVM` - open a file in called VM. Service receives a single file on stdin (in + [qfile format](/doc/Qfilecopy/). After a file viewer/editor is terminated, if + the file was modified, can be sent back (just raw content, without any + headers); otherwise service should just terminate without sending anything. + This service is used by both `qvm-open-in-vm` and `qvm-open-in-dvm` tools. When + called in DispVM, service termination will trigger DispVM cleanup. +- `qubes.Restore` - retrieve Qubes backup. The service receives backup location + entered by the user (one line, terminated by '\n'), then should output backup + archive in [qfile format](/doc/Qfilecopy/) (core-agent-linux component contains + `tar2qfile` utility to do the conversion +- `qubes.SelectDirectory`, `qubes.SelectFile` - services which should show + file/directory selection dialog and return (to stdout) a single line + containing selected path, or nothing in case of cancellation +- `qubes.SuspendPre` - service called in every VM with PCI device attached just + before system suspend +- `qubes.SuspendPost` - service called in every VM with PCI device attached just + after system resume +- `qubes.SyncNtpClock` - service called to trigger network time synchronization. + Service should synchronize local VM time and terminate when done. +- `qubes.VMShell` - call any command in the VM; the command(s) is passed one per line + +Currently Qubes still calls few tools in VM directly, not using service +abstraction. This will change in the future. Those tools are: + +- `/usr/lib/qubes/qubes-download-dom0-updates.sh` - script to download updates (or new packages to be installed) for dom0 (`qubes-dom0-update` tool) +- `date -u -Iseconds` - called directly to retrieve time after calling `qubes.SyncNtpClock` service (`qvm-sync-clock` tool) +- `nm-online -x` - called before `qubes.SyncNtpClock` service call by `qvm-sync-clock` tool +- `resize2fs` - called to resize filesystem on /rw partition by `qvm-grow-private` tool +- `gpk-update-viewer` - called by Qubes Manager to display available updates in a TemplateVM +- `systemctl start qubes-update-check.timer` (and similarly stop) - called when enabling/disabling updates checking in given VM (`qubes-update-check` [qvm-service](/doc/QubesService/)) + +Additionally automatic tests extensively calls various commands directly in VMs. We do not plan to change that. GUI protocol ------------ From b9f2ce22eda4c0e5b5998d5edd82ba7c611d2c78 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Sat, 1 Aug 2015 01:12:54 +0200 Subject: [PATCH 054/174] R3.0rc2 related changes --- InstallationGuideR3.0rc2.md | 98 +++++++++++++++++++++++++++++++++++++ QubesDownloads.md | 12 ++--- 2 files changed, 104 insertions(+), 6 deletions(-) create mode 100644 InstallationGuideR3.0rc2.md diff --git a/InstallationGuideR3.0rc2.md b/InstallationGuideR3.0rc2.md new file mode 100644 index 00000000..2e45f064 --- /dev/null +++ b/InstallationGuideR3.0rc2.md @@ -0,0 +1,98 @@ +--- +layout: doc +title: Installation Guide for Qubes 3.0 rc2 +permalink: /doc/InstallationGuideR3.0rc2/ +--- + +Installation Guide for Qubes Release 3.0 rc2 +============================================ + +1. [Hardware Requirements](#hardware-requirements) +2. [Download installer ISO](#download-installer-iso) +3. [Burning the ISO onto a DVD or USB stick](#burning-the-iso-onto-a-dvd-or-usb-stick) +4. [Upgrading](#upgrading) +5. [Troubleshooting problems with the installer](#troubleshooting-problems-with-the-installer) +6. [Known Issues](#known-issues) +7. [Getting Help](#getting-help) + +Hardware Requirements +--------------------- + +Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. + +Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). + +Download installer ISO +---------------------- + +See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: + + gpg -v Qubes-R3.0-rc2-x86_64-DVD.iso.asc + +Burning the ISO onto a DVD or USB stick +--------------------------------------- + +Once you verify this is an authentic ISO, you should burn it on a DVD. + +If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: + + dd if=Qubes-R3.0-rc2-x86_64-DVD.iso of=/dev/sdX + +On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator): + + dd if=Qubes-R3.0-rc2-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress + +**Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)** + +Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. + +Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions! + +The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) + +Upgrading from R3.0rc1 +----------------------- + +If you are using Qubes R3.0rc1, just install system updates, there is no special steps required. + +Upgrading +--------- + +If you are using Qubes R2, follow instructions below. + +The easiest and safest way to upgrade to Qubes R3.0rc2 is to install it from scratch and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. + +Users of Qubes R2 can upgrade using [experimental procedure](/doc/UpgradeToR3.0rc1/) (the same as for R3.0rc1). + +Troubleshooting problems with the installer +------------------------------------------- + +If the installer fails for some reason, typically because of the graphics card not being correctly supported, it is possible to try booting the installer with a different kernel -- to do that, choose Troubleshooting menu in the Installer Welcome screen, and later choose an option to proceed with one of the kernels provided. + +The installer ships with 4 different kernels (3.12, 3.11, 3.9 and 3.7) and all those kernel will be installed (regardless of which is selected to run the installer) so it is later always possible to boot the Qubes OS using any of those kernels. + +Known Issues +------------ + +- UEFI is not supported, you need to enable "legacy boot" in BIOS before installing Qubes OS + +- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. + +- If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. + +- For other known issues take a look at [our tickets](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3%22+label%3Abug) + +It is advised to install updates just after system installation to apply bug fixes for (some of) the above problems. + +Getting Help +------------ + +- **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!) + +- Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) + +- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below): + - [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users) + - `qubes-users@googlegroups.com` + +- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. diff --git a/QubesDownloads.md b/QubesDownloads.md index f40d4c06..7ebff55c 100644 --- a/QubesDownloads.md +++ b/QubesDownloads.md @@ -18,13 +18,13 @@ Qubes Downloads Qubes Release 3.0 --------------- -- [Qubes-R3.0-rc1-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc1-x86_64-DVD.iso) (mirror 1) -- [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc1-x86_64-DVD.iso.asc) (mirror 1) -- [Qubes-R3.0-rc1-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc1-x86_64-DVD.iso) (mirror 2) -- [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc1-x86_64-DVD.iso.asc) (mirror 2) +- [Qubes-R3.0-rc2-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc2-x86_64-DVD.iso) (mirror 1) +- [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc2-x86_64-DVD.iso.asc) (mirror 1) +- [Qubes-R3.0-rc2-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc2-x86_64-DVD.iso) (mirror 2) +- [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc2-x86_64-DVD.iso.asc) (mirror 2) -- **[Installation Guide for Qubes R3.0 rc1](/doc/InstallationGuideR3.0rc1/)** -- [Upgrading to Qubes R3.0 rc1](/doc/InstallationGuideR3.0rc1/#upgrading) +- **[Installation Guide for Qubes R3.0 rc2](/doc/InstallationGuideR3.0rc2/)** +- [Upgrading to Qubes R3.0 rc2](/doc/InstallationGuideR3.0rc2/#upgrading) Qubes Release 2 --------------- From 6126f7c0f5b867f8a02f0dbfd3cb11d0ac96e69a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Sat, 1 Aug 2015 14:52:52 +0200 Subject: [PATCH 055/174] Fix link to bug list --- InstallationGuideR3.0rc2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/InstallationGuideR3.0rc2.md b/InstallationGuideR3.0rc2.md index 2e45f064..a966debb 100644 --- a/InstallationGuideR3.0rc2.md +++ b/InstallationGuideR3.0rc2.md @@ -80,7 +80,7 @@ Known Issues - If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. -- For other known issues take a look at [our tickets](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3%22+label%3Abug) +- For other known issues take a look at [our tickets](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3.0%22+label%3Abug) It is advised to install updates just after system installation to apply bug fixes for (some of) the above problems. From c5069f2000710ee397fefec51129ab68a848023a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Sat, 1 Aug 2015 20:55:12 +0200 Subject: [PATCH 056/174] Update contribution guide --- ContributingHowto.md | 2 ++ DocStyle.md | 18 ++++++++++++++++++ SourceCode.md | 19 ++++++++----------- 3 files changed, 28 insertions(+), 11 deletions(-) diff --git a/ContributingHowto.md b/ContributingHowto.md index 11471713..5efb0c21 100644 --- a/ContributingHowto.md +++ b/ContributingHowto.md @@ -21,6 +21,8 @@ Perhaps the best starting point is to have a look at the [issues](https://github Before you engage in some longer activity, e.g. implementing a new feature, it's always good to contact us first (preferably via the [qubes-devel](/doc/QubesLists/) list), to avoid a situation when two or more independent people would work on the same feature at the same time, doubling each others work. When you contact us and devote to a particular task, we will create a ticket for this task with info who is working on this feature and what is the expected date of some early code to be posted. +When you are ready to start some work, read how to [access Qubes sources and send patches](/doc/SourceCode/). + You can also contribute in other areas than coding and testing, e.g. by providing mirrors for Qubes rpm repositories, providing feedback about what features you would like to have in Qubes, or perhaps even preparing some cool You Tube videos that would demonstrate some Qubes' features. You are always encouraged to discuss your ideas on qubes-devel. You should be aware, however, that we will not blindly accept all the contributions! We will accept only the quality ones. Open source doesn't mean lack of quality control! If we reject your patch, please do not get discouraged, try fixing it so that it adheres to the required standards. We will only reject contributions in the good faith, to make Qubes a better OS. diff --git a/DocStyle.md b/DocStyle.md index b24a010c..d9ab99dc 100644 --- a/DocStyle.md +++ b/DocStyle.md @@ -22,3 +22,21 @@ Guidelines for Documentation Contributors where appropriate. * Use `[reference-style][ref]` links. `[ref]: http://daringfireball.net/projects/markdown/syntax#link` + + +Sending documentation updates +----------------------------- + +Main documentation repository is [qubes-doc] on [QubesOS] github account. If +you want to add something there, clone that repository commit the changes and +send us patches using either [github pull requests][github-forking] or [plain +email sent to qubes-devel mailing list][patch]. + +If you have a github account (its free!), you can simply browse [qubes-doc] +repository and edit the files there! Github interface will automatically guide +you through [fork & pull request creation process][github-forking]. + +[qubes-doc]: https://github.com/QubesOS/qubes-doc +[QubesOS]: https://github.com/QubesOS/ +[github-forking]: https://guides.github.com/activities/forking/ +[patch]: /doc/SourceCode/#sending-a-patch diff --git a/SourceCode.md b/SourceCode.md index 4afa7631..5fcf546a 100644 --- a/SourceCode.md +++ b/SourceCode.md @@ -31,18 +31,15 @@ e.g.: git clone git://github.com/QubesOS/qubes-core-admin.git core-admin {% endhighlight %} -If you want to contribute to the project, there are two preferred ways: - -1. Use github [fork & pull requests](https://guides.github.com/activities/forking/) -2. [sending a patch](/doc/DevelFaq/#q-how-do-i-submit-a-patch) via the project's mailing list (`git format-patch`). - ## Sending 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. -2. 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). +If you want to contribute to the project, there are two ways: -3. Test your changes NOW: check if RPMs build fine, etc. +* **Preferred**: Use github [fork & pull requests](https://guides.github.com/activities/forking/) +* Sending a patch via the project's mailing list (`git format-patch`). -4. 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. - -5. Send your patch to qubes-devel. Start the message subject with the '[PATCH]' string. + 1. Make all the changes in your working directory, i.e. edit files, move them around (you can use 'git mv' for this), etc. + 2. 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). + 3. Test your changes NOW: check if RPMs build fine, etc. + 4. 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. + 5. Send your patch to qubes-devel. Start the message subject with the '[PATCH]' string. From 42d1458b7f84ba67e3b1a7562b83e03b3e6b8dc8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Thu, 6 Aug 2015 04:52:04 +0200 Subject: [PATCH 057/174] Change command in DispVM example gnome-terminal isn't the best choice as terminates immediately (after sending a call to gnome-terminal-server), so does DispVM. --- DisposableVms.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/DisposableVms.md b/DisposableVms.md index 003149e8..752249b1 100644 --- a/DisposableVms.md +++ b/DisposableVms.md @@ -44,7 +44,7 @@ Starting an arbitrary application in a disposable VM via command line (from Dom0 **Note:** Normally there should be no need for doing this -- this is just for Qubes hackers ;) {% highlight trac-wiki %} -[joanna@dom0 ~]$ echo gnome-terminal | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red +[joanna@dom0 ~]$ echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red {% endhighlight %} In fact the Disposable VM appmenu used for starting Firefox contains a very similar command to the above. Please note, however, that it generally makes little sense to start any other application other than a Web Browser this way... @@ -55,7 +55,7 @@ Starting an arbitrary program in a Disposable VM from an AppVM Sometimes it might be useful to start an arbitrary program, such as e.g. terminal in an Disposable VM from an AppVM. This could be simply done this way: {% highlight trac-wiki %} -[user@vault ~]$ qvm-run '$dispvm' gnome-terminal +[user@vault ~]$ qvm-run '$dispvm' xterm {% endhighlight %} Note the above command is issued in an AppVM, not in Dom0. The created Disposable VM can be normally accessed via other tools, such as e.g. `qvm-copy-to-vm`, using its 'dispX' name, as shown by the Qubes Manager or `qvm-ls` tools. The created Disposable VM will inherit firewall settings of the ancestor VM, which is useful in some cases (e.g. when the original AppVM had networking cut off). From 547c51d12a7a087086caf1e6e2b0fa6742f4b0b9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Sat, 8 Aug 2015 21:16:52 +0200 Subject: [PATCH 058/174] Update qvm-prefs man page --- Dom0Tools/QvmPrefs.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/Dom0Tools/QvmPrefs.md b/Dom0Tools/QvmPrefs.md index f1c82942..5771e874 100644 --- a/Dom0Tools/QvmPrefs.md +++ b/Dom0Tools/QvmPrefs.md @@ -20,6 +20,7 @@ SYNOPSIS -------- qvm-prefs -l [options] \ +qvm-prefs -g [options] \ \ qvm-prefs -s [options] \ \ [...] OPTIONS @@ -31,6 +32,9 @@ Show this help message and exit -l, --list List properties of a specified VM +-g, --get +Get a single property of a specified VM + -s, --set Set properties of a specified VM @@ -45,6 +49,11 @@ Control whenever this VM will be included in backups by default (for now works o pcidevs PCI devices assigned to the VM. Should be edited using qvm-pci tool. +pci\_strictreset +Accepted values: `True`, `False` + +Control whether prevent assigning to VM a device which does not support any reset method. Generally such devices should not be assigned to any VM, because there will be no way to reset device state after VM shutdown, so the device could attack next VM to which it will be assigned. But in some cases it could make sense - for example when the VM to which it is assigned is trusted one, or is running all the time. + label Accepted values: `red`, `orange`, `yellow`, `green`, `gray`, `blue`, `purple`, `black` @@ -88,7 +97,7 @@ Number of CPU (cores) available to VM. Some VM types (eg DispVM) will not work p kernelopts Accepted values: string, `default` -VM kernel parameters (available only for PV VMs). This can be used to workaround some hardware specific problems (eg for NetVM). Setting to `default` will use some reasonable defaults (currently different for VMs with PCI devices and without). Some helpful options (for debugging purposes): `earlyprintk=xen`, `init=/bin/bash` +VM kernel parameters (available only for PV VMs). This can be used to workaround some hardware specific problems (eg for NetVM). Setting to `default` will use some reasonable defaults (currently different for VMs with PCI devices and without). For VM without PCI devices `default` option means inherit this value from the VM template (if any). Some helpful options (for debugging purposes): `earlyprintk=xen`, `init=/bin/bash` name Accepted values: alphanumerical name From fb6ed54bd0204e61725f9f72c9810f90a6b4ea12 Mon Sep 17 00:00:00 2001 From: Noah Vesely Date: Mon, 10 Aug 2015 16:49:31 -0700 Subject: [PATCH 059/174] Added a couple dependencies to the `yum install` line --- QubesBuilder.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/QubesBuilder.md b/QubesBuilder.md index aa081e71..2a74dd9f 100644 --- a/QubesBuilder.md +++ b/QubesBuilder.md @@ -21,11 +21,13 @@ In order to use it one should use an rpm-based distro, like Fedora :) and should - wget - rpmdevtools - python-sh +- dialog +- rpm-sign Unusually one can install those packages by just issuing: {% highlight trac-wiki %} -sudo yum install git createrepo rpm-build make wget rpmdevtools python-sh +sudo yum install git createrepo rpm-build make wget rpmdevtools python-sh dialog rpm-sign {% endhighlight %} The build system creates build environments in chroots and so no other packages are needed on the host. All files created by the build system are contained within the qubes-builder directory. The full build requires some 25GB of free space, so keep that in mind when deciding where to place this directory. From 910fc8d1840d7f4a67809c032e56dc38a20a14c2 Mon Sep 17 00:00:00 2001 From: Lauri Ojansivu Date: Wed, 12 Aug 2015 23:52:06 +0300 Subject: [PATCH 060/174] Instructions how to get Lenovo 450 working with Qubes --- Lenovo450Tinkering.md | 21 +++++++++++++++++++++ UserDoc.md | 1 + 2 files changed, 22 insertions(+) create mode 100644 Lenovo450Tinkering.md diff --git a/Lenovo450Tinkering.md b/Lenovo450Tinkering.md new file mode 100644 index 00000000..66fb6bab --- /dev/null +++ b/Lenovo450Tinkering.md @@ -0,0 +1,21 @@ +--- +layout: doc +title: Lenovo450Tinkering +permalink: /doc/Lenovo450Tinkering/ +redirect_from: /wiki/Lenovo450Tinkering/ +--- + +Instructions for getting your Lenovo 450 laptop working with Qubes/Linux +========================================================================= + +Lenovo 450 uses UEFI, so some settings are needed to get Qubes (or Fedora) to boot, otherwise Qubes install USB stick will reboot right after boot selector screen and not continue install. + +Setting UEFI options to get Qubes install to boot +------------------------------------------------- + +1. Enable Legacy USB mode +2. Disable all Secure Boot and UEFI options, but leave this enabled: Config / USB / USB UEFI BIOS SUPPORT +3. Save settings and reboot +5. Install Qubes + +... and now enjoy :) These settings may be needed also in other UEFI computers. diff --git a/UserDoc.md b/UserDoc.md index 395db673..297bbe66 100644 --- a/UserDoc.md +++ b/UserDoc.md @@ -96,6 +96,7 @@ Qubes User Documentation 7. Vendor-specific 1. [How to install an Nvidia driver in dom0](/doc/InstallNvidiaDriver/) 2. [Getting Sony Vaio Z laptop to work with Qubes](/doc/SonyVaioTinkering/) + 3. [Getting Lenovo 450 to work with Qubes](/doc/Lenovo450Tinkering/) 8. External Links 1. [Installing on system with new AMD GPU (missing firmware problem)](https://groups.google.com/group/qubes-devel/browse_thread/thread/e27a57b0eda62f76) From 2735f20e1885b08a16dd611ff55a9caafea56364 Mon Sep 17 00:00:00 2001 From: unman Date: Sat, 15 Aug 2015 01:16:49 +0000 Subject: [PATCH 061/174] Edit pages on Disposable VMs to make it clear that files edited in a dispVM will be saved back to the originating VM. Updated some commands to match R3 Moved section on using a custom template to Customization page. --- DisposableVms.md | 39 +++++++++++++--------------------- UserDoc/DispVMCustomization.md | 24 +++++++++++++++++++++ 2 files changed, 39 insertions(+), 24 deletions(-) diff --git a/DisposableVms.md b/DisposableVms.md index 752249b1..ba064dc1 100644 --- a/DisposableVms.md +++ b/DisposableVms.md @@ -1,8 +1,8 @@ --- layout: doc -title: DisposableVms +title: DisposableVMs permalink: /doc/DisposableVms/ -redirect_from: /wiki/DisposableVms/ +redirect_from: /wiki/DisposableVMs/ --- Disposable VMs (DispVMs) @@ -13,17 +13,23 @@ Background See [this article](http://theinvisiblethings.blogspot.com/2010/06/disposable-vms.html) for a background on why would one want to use a Disposable VM and what it is. +A DisposableVM is a lightweight VM that can be created quickly and which will disappear when it is finished with. Usually a Disposable VM is created in order to host a single application, like a viewer or an editor. This means that you can safely work with files without risk of compromising any of your VMs. Changes made to a file opened in a disposable VM are passed back to the originating VM. + +By default a Disposable VM will inherit the netVM and firewall settings of the ancestor VM. You can change this behaviour: in the Qubes Manager go to the advanced tab of VM Settings where you can set the default netVM to be used for DisposableVMs created from that VM. + +Once a dispVM has been created it will appear in the Qubes Manager with the name "dispX", and NetVM and firewall rules can be set as for a normal VM. + Opening a file in a Disposable VM (via GUI) ------------------------------------------- -In some AppVM, right click on the file you wish to open in a Disposable VM (in the Nautilus file manager), then choose Scripts -\> Open in Disposable VM. Wait a few seconds and an default application for this file type should appear displaying the file content. This app is running in a whole new VM -- a disposable VM created for the purpose of view this very file. Once you close the viewing application then whole Disposable VM will get destroyed. +In some AppVM, right click on the file you wish to open in a Disposable VM (in the Nautilus file manager), then choose "Open in Disposable VM". Wait a few seconds and the default application for this file type should appear displaying the file content. This app is running in a whole new VM -- a disposable VM created for the purpose of viewing or editing this very file. Once you close the viewing application the whole Disposable VM will be destroyed. If you have edited the file and saved the changes the changed file will be saved back to the original VM, overwriting the original. ![r1-open-in-dispvm-1.png](/attachment/wiki/DisposableVms/r1-open-in-dispvm-1.png) ![r1-open-in-dispvm-2.png](/attachment/wiki/DisposableVms/r1-open-in-dispvm-2.png) Opening a fresh web browser instance in a new Disposable VM ----------------------------------------------------------- -Sometimes it is convenient to open a fresh instance of Firefox within a new fresh Disposable VM. This can be easily done by using the Start Menu: just go to Start -\> Disposable VM -\> Firefox and wait a few seconds until a web browser starts. Once you close the viewing application then whole Disposable VM will get destroyed. +Sometimes it is convenient to open a fresh instance of Firefox within a new fresh Disposable VM. This can be easily done by using the Start Menu: just go to Start -\> System Tools -\> DispVM:Firefox web browser . Wait a few seconds until a web browser starts. Once you close the viewing application the whole Disposable VM will get destroyed. ![r1-open-in-dispvm-3.png](/attachment/wiki/DisposableVms/r1-open-in-dispvm-3.png) @@ -58,30 +64,15 @@ Sometimes it might be useful to start an arbitrary program, such as e.g. termina [user@vault ~]$ qvm-run '$dispvm' xterm {% endhighlight %} -Note the above command is issued in an AppVM, not in Dom0. The created Disposable VM can be normally accessed via other tools, such as e.g. `qvm-copy-to-vm`, using its 'dispX' name, as shown by the Qubes Manager or `qvm-ls` tools. The created Disposable VM will inherit firewall settings of the ancestor VM, which is useful in some cases (e.g. when the original AppVM had networking cut off). +Note the above command is issued in an AppVM, not in Dom0. The created Disposable VM can be normally accessed via other tools, such as e.g. `qvm-copy-to-vm`, using its 'dispX' name, as shown by the Qubes Manager or `qvm-ls` tools. -Using a non-default template as a basis for Disposable VM + +Customizing Disposable VMs --------------------------------------------------------- -In some situations it might be beneficial to use a non-default template as a basis for Disposable VM. One example is to use a less-trusted template with some less trusted, 3rd party, often unsigned, applications installed, such as e.g. 3rd part printer drivers. +You can change the template used to generate the Disposable VM, and change settings used in the Disposable VM savefile. These changes will be reflected in every new Disposable VM. +Full instructions are [here] (doc/UserDoc/DispVMCustomization/) -In order to regenerate Disposable VM "snapshot" (called 'savefile' on Qubes) one can conveniently use the following command in Dom0: - -{% highlight trac-wiki %} -[joanna@dom0 ~]$ qvm-create-default-dvm -{% endhighlight %} - -This would create a new Disposable VM savefile based on the custom template. Now, whenever one opens a file (from any AppVM) in a Disposable VM, a Disposable VM based on this template will be used. - -One can easily verify if the new Disposable VM template is indeed based on a custom template (in the example below the template called "f17-yellow" was used as a basis for the Disposable VM): - -{% highlight trac-wiki %} -[joanna@dom0 ~]$ ll /var/lib/qubes/dvmdata/ -total 0 -lrwxrwxrwx 1 joanna joanna 45 Mar 11 13:59 default_dvm.conf -> /var/lib/qubes/appvms/f17-yellow-dvm/dvm.conf -lrwxrwxrwx 1 joanna joanna 49 Mar 11 13:59 default_savefile -> /var/lib/qubes/appvms/f17-yellow-dvm/dvm-savefile -lrwxrwxrwx 1 joanna joanna 47 Mar 11 13:59 savefile_root -> /var/lib/qubes/vm-templates/f17-yellow/root.img -{% endhighlight %} Disposable VMs and Local Forensics ---------------------------------- diff --git a/UserDoc/DispVMCustomization.md b/UserDoc/DispVMCustomization.md index bb331fb1..cbe7630f 100644 --- a/UserDoc/DispVMCustomization.md +++ b/UserDoc/DispVMCustomization.md @@ -5,6 +5,30 @@ permalink: /doc/UserDoc/DispVMCustomization/ redirect_from: /wiki/UserDoc/DispVMCustomization/ --- +Chaanging the template used as a basis for Disposable VM +======================================================== + +You may want to use a non-default template as a basis for Disposable VM. One example is to use a less-trusted template with some less trusted, 3rd party, often unsigned, applications installed, such as e.g. 3rd part printer drivers. + +In order to regenerate the Disposable VM "snapshot" (called 'savefile' on Qubes) one can use the following command in Dom0: + +{% highlight trac-wiki %} +[joanna@dom0 ~]$ qvm-create-default-dvm +{% endhighlight %} + +This would create a new Disposable VM savefile based on the custom template. Now, whenever one opens a file (from any AppVM) in a Disposable VM, a Disposable VM based on this template will be used. + +One can easily verify if the new Disposable VM template is indeed based on a custom template (in the example below the template called "f17-yellow" was used as a basis for the Disposable VM): + +{% highlight trac-wiki %} +[joanna@dom0 ~]$ ll /var/lib/qubes/dvmdata/ +total 0 +lrwxrwxrwx 1 joanna joanna 45 Mar 11 13:59 default_dvm.conf -> /var/lib/qubes/appvms/f17-yellow-dvm/dvm.conf +lrwxrwxrwx 1 joanna joanna 49 Mar 11 13:59 default_savefile -> /var/lib/qubes/appvms/f17-yellow-dvm/dvm-savefile +lrwxrwxrwx 1 joanna joanna 47 Mar 11 13:59 savefile_root -> /var/lib/qubes/vm-templates/f17-yellow/root.img +{% endhighlight %} + + Customization of Disposable VM ============================== From a4d584c6454174d1126c498b592b48a56c7f7f10 Mon Sep 17 00:00:00 2001 From: unman Date: Sat, 15 Aug 2015 01:25:33 +0000 Subject: [PATCH 062/174] Correct spelling --- UserDoc/DispVMCustomization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/UserDoc/DispVMCustomization.md b/UserDoc/DispVMCustomization.md index cbe7630f..b9bb2324 100644 --- a/UserDoc/DispVMCustomization.md +++ b/UserDoc/DispVMCustomization.md @@ -5,7 +5,7 @@ permalink: /doc/UserDoc/DispVMCustomization/ redirect_from: /wiki/UserDoc/DispVMCustomization/ --- -Chaanging the template used as a basis for Disposable VM +Changing the template used as a basis for Disposable VM ======================================================== You may want to use a non-default template as a basis for Disposable VM. One example is to use a less-trusted template with some less trusted, 3rd party, often unsigned, applications installed, such as e.g. 3rd part printer drivers. From a8e64c03645dad1da327dadf888288af7d9a9cd0 Mon Sep 17 00:00:00 2001 From: Bahtiar `kalkin-` Gadimov Date: Sun, 16 Aug 2015 17:50:33 +0200 Subject: [PATCH 063/174] Instructions how to add new tests to core-admin --- AutomatedTests.md | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/AutomatedTests.md b/AutomatedTests.md index 2f7fab71..aae12322 100644 --- a/AutomatedTests.md +++ b/AutomatedTests.md @@ -94,3 +94,36 @@ For example to run only tests for fedora-21 template, you can use `-l` option, t vm_qrexec_gui/TC_20_DispVM_fedora-21/test_020_gui_app vm_qrexec_gui/TC_20_DispVM_fedora-21/test_030_edit_file [user@dom0 ~]$ python -m qubes.tests.run -v `python -m qubes.tests.run -l | grep fedora-21` + + +## Adding a new test to core-admin +After you added a new unit test to [core-admin/tests](https://github.com/QubesOS/qubes-core-admin/tree/master/tests) +you have to make sure of two things: + +1. The test will be added to the RPM file created by [QubesBuilder](/doc/QubesBuilder/) +For this you need to edit [core-admin/tests/Makefile](https://github.com/QubesOS/qubes-core-admin/tree/master/tests/Makefile) +2. The test will be loaded by [core-admin/tests/\_\_init\_\_.py](https://github.com/QubesOS/qubes-core-admin/tree/master/tests/__init__.py) + +### Editing the Makefile +Add at the bottom of the file the two lines which will copy your test and its +compiled version to the right directory in the RPM file. I.e. adding `example.py` + + cp example.py $(DESTDIR)$(PYTHON_TESTSPATH) + cp example.py[co] $(DESTDIR)$(PYTHON_TESTSPATH) + + +### Editing \_\_init\_\_.py +Add at the bottom of the file in the method `def load_tests` to the variable +`modname` your test. I.e adding `example.py`. +```python + for modname in ( + 'qubes.tests.basic', + 'qubes.tests.dom0_update', + 'qubes.tests.network', + 'qubes.tests.vm_qrexec_gui', + 'qubes.tests.backup', + 'qubes.tests.backupcompatibility', + 'qubes.tests.regressions', + 'qubes.tests.example', # This is our newly added test + ): +``` From 7a7d65c3f455e08f920a0df0dedac10b285106b7 Mon Sep 17 00:00:00 2001 From: eriklovlie Date: Mon, 17 Aug 2015 11:02:40 +0200 Subject: [PATCH 064/174] Trivial typo fix in SimpleIntro.md --- SimpleIntro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SimpleIntro.md b/SimpleIntro.md index 127318ea..d1121ba5 100644 --- a/SimpleIntro.md +++ b/SimpleIntro.md @@ -23,7 +23,7 @@ Most people use an operating system like Windows or OS X on their desktop and la Aren't antivirus programs and firewalls enough? ----------------------------------------------- -Unfortunately, conventional security approaches like antivirus programs and (softare and/or hardware) firewalls are no longer enough to keep out sophisticated attackers. For example, nowadays it's common for malware creators to check to see if their malware is recognized by any popular antivirus programs. If it's recognized, they scramble their code until it's no longer recognizable by the antivirus programs, then send it out. The best antivirus programs will subsequently get updated once the antivirus programmers discover the new threat, but this usually occurs at least a few days after the new attacks start to appear in the wild. By then, it's typically too late for those who have already been compromised. In addition, bugs are inevitably discovered in the common software we all use (such as our web browsers), and no antivirus program or firewall can prevent all of these bugs from being exploited. +Unfortunately, conventional security approaches like antivirus programs and (software and/or hardware) firewalls are no longer enough to keep out sophisticated attackers. For example, nowadays it's common for malware creators to check to see if their malware is recognized by any popular antivirus programs. If it's recognized, they scramble their code until it's no longer recognizable by the antivirus programs, then send it out. The best antivirus programs will subsequently get updated once the antivirus programmers discover the new threat, but this usually occurs at least a few days after the new attacks start to appear in the wild. By then, it's typically too late for those who have already been compromised. In addition, bugs are inevitably discovered in the common software we all use (such as our web browsers), and no antivirus program or firewall can prevent all of these bugs from being exploited. How does Qubes provide security? -------------------------------- From ad5346bf09c922b6f67c7bbdf892c37c460a1499 Mon Sep 17 00:00:00 2001 From: unman Date: Wed, 26 Aug 2015 01:04:50 +0000 Subject: [PATCH 065/174] Fix link --- DisposableVms.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DisposableVms.md b/DisposableVms.md index ba064dc1..0f1d4e61 100644 --- a/DisposableVms.md +++ b/DisposableVms.md @@ -71,7 +71,7 @@ Customizing Disposable VMs --------------------------------------------------------- You can change the template used to generate the Disposable VM, and change settings used in the Disposable VM savefile. These changes will be reflected in every new Disposable VM. -Full instructions are [here] (doc/UserDoc/DispVMCustomization/) +Full instructions are [here](/doc/UserDoc/DispVMCustomization/) Disposable VMs and Local Forensics From 8339c86bdbb44066a962441d77a7d704e20060d3 Mon Sep 17 00:00:00 2001 From: unman Date: Wed, 26 Aug 2015 02:05:30 +0000 Subject: [PATCH 066/174] Rewrite Nvidia page for clarity --- InstallNvidiaDriver.md | 58 ++++++++++++++++++++++-------------------- 1 file changed, 31 insertions(+), 27 deletions(-) diff --git a/InstallNvidiaDriver.md b/InstallNvidiaDriver.md index 484d12a6..38816b74 100644 --- a/InstallNvidiaDriver.md +++ b/InstallNvidiaDriver.md @@ -5,26 +5,24 @@ permalink: /doc/InstallNvidiaDriver/ redirect_from: /wiki/InstallNvidiaDriver/ --- -Nvidia proprietary driver installation -====================================== +#Nvidia proprietary driver installation -RpmFusion packages -================== +You can use rpm packages from rpmfusion, or you can build the driver yourself. -There are rpm packages with all necessary software on rpmfusion. The only package you have to compile is kernel module (but there is ready src.rpm package). +##RpmFusion packages -Download packages ------------------ +There are rpm packages with all necessary software on rpmfusion. The only package you have to compile is the kernel module (but there is a ready built src.rpm package). -You will need any Fedora 18 system to download and build packages. You can use Qubes AppVM for it, but it isn't necessary. To download packages from rpmfusion - add this repository to your yum configuration (instructions are on their website). After then download packages using yumdownloader: +###Download packages + +You will need any Fedora 18 system to download and build packages. You can use Qubes AppVM for it, but it isn't necessary. To download packages from rpmfusion - add this repository to your yum configuration (instructions are on their website). Then download packages using yumdownloader: {% highlight trac-wiki %} yumdownloader --resolve xorg-x11-drv-nvidia yumdownloader --source nvidia-kmod {% endhighlight %} -Build kernel package --------------------- +###Build kernel package You will need at least kernel-devel (matching your Qubes dom0 kernel), rpmbuild tool and kmodtool, and then you can use it to build package: @@ -33,33 +31,37 @@ yum install kernel-devel rpm-build kmodtool rpmbuild --nodeps -D "kernels `uname -r`" --rebuild nvidia-kmod-260.19.36-1.fc13.3.src.rpm {% endhighlight %} -In above command replace `uname -r` with kernel version from your Qubes dom0. If everything went right, you have now complete packages with nvidia drivers for Qubes system. Transfer them to dom0 (eg using USB stick) and install (using standard "yum install /path/to/file"). Then you need to disable nouveau (normally it is done by install scripts from nvidia package, but unfortunately it isn't compatible with Qubes...): +In above command replace `uname -r` with kernel version from your Qubes dom0. If everything went right, you have now complete packages with nvidia drivers for Qubes system. Transfer them to dom0 (eg using USB stick) and install (using standard "yum install /path/to/file"). -1. Edit /etc/default/grub: +Then you need to disable nouveau (normally it is done by install scripts from nvidia package, but unfortunately it isn't compatible with Qubes...): + +Edit /etc/default/grub: {% highlight trac-wiki %} GRUB_CMDLINE_LINUX="quiet rhgb nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off" {% endhighlight %} -2. Regenerate grub configuration: +Regenerate grub configuration: {% highlight trac-wiki %} grub2-mkconfig -o /boot/grub2/grub.cfg {% endhighlight %} -Then reboot. +Reboot. -Manual installation -=================== -But this is somehow complicated: First - download it from nvidia.com site. Here "NVIDIA-Linux-x86\_64-260.19.44.run" is used. Copy it to dom0. Every next step is done in dom0. -See [this page](/doc/CopyToDomZero/) for instruction on how to transfer files to Dom0 (where there is normally no networking). +##Manual installation -**WARNING**: Nvidia doesn't sign their files. To make it worse, you are forced to download them over a plaintext connection. This means there are virtually dozens of possibilities for somebody to modify this file and provide you with a malicious/backdoored file. You should realize that installing untrusted files into your Dom0 is really a bad idea. Perhaps it might be a better idea to just get a new laptop with integrated Intel GPU? You have been warned, anyway. +This process is quite complicated: First - download the source from nvidia.com site. Here "NVIDIA-Linux-x86\_64-260.19.44.run" is used. Copy it to dom0. Every next step is done in dom0. -Userspace components --------------------- +See [this page](/doc/CopyToDomZero/) for instructions on how to transfer files to Dom0 (where there is normally no networking). + +**WARNING**: Nvidia doesn't sign their files. To make it worse, you are forced to download them over a plaintext connection. This means there are virtually dozens of possibilities for somebody to modify this file and provide you with a malicious/backdoored file. You should realize that installing untrusted files into your Dom0 is a bad idea. Perhaps it might be a better idea to just get a new laptop with integrated Intel GPU? You have been warned. + + + +###Userspace components Install libraries, Xorg driver, configuration utilities. This can by done by nvidia-installer: @@ -67,8 +69,7 @@ Install libraries, Xorg driver, configuration utilities. This can by done by nvi ./NVIDIA-Linux-x86_64-260.19.44.run --ui=none --no-x-check --keep --no-nouveau-check --no-kernel-module {% endhighlight %} -Kernel module -------------- +###Kernel module You will need: @@ -82,7 +83,7 @@ This installation must be done manually, because nvidia-installer refused to ins - */lib/modules/2.6.34.1-12.xenlinux.qubes.x86\_64/build* symlinked to the above directory - */usr/src/kernels/2.6.34.1-12.xenlinux.qubes.x86\_64/arch/x64/include/mach-xen* should be present (if not - take it from kernel sources) -If it is not true - correct it manually. To build kernel module, enter *NVIDIA-Linux-x86\_64-260.19.44/kernel* directory and execute: +If all the files are not there correct the errors manually. To build kernel module, enter *NVIDIA-Linux-x86\_64-260.19.44/kernel* directory and execute: {% highlight trac-wiki %} make @@ -90,7 +91,9 @@ IGNORE_XEN_PRESENCE=1 CC="gcc -DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM" make mv /lib/modules/2.6.34.1-12.xenlinux.qubes.x86_64/kernel/drivers/video/nvidia.ko /lib/modules/2.6.34.1-12.xenlinux.qubes.x86_64/extra/ {% endhighlight %} -Ignore error while inserting nvidia.ko (at the end of make phase). Now you should disable nouveau: +Ignore any errors while inserting nvidia.ko (at the end of make phase). + +###Disable nouveau: {% highlight trac-wiki %} cat /etc/modprobe.d/nouveau-disable.conf @@ -100,8 +103,7 @@ install nouveau /bin/true Add *rdblacklist=nouveau* option to /boot/grub/menu.lst (at the end of line containing *vmlinuz*). -Configure Xorg --------------- +###Configure Xorg After all, you should configure Xorg to use nvidia driver. You can use *nvidia-xconfig* or do it manually: @@ -111,4 +113,6 @@ mv /root/xorg.conf.new /etc/X11/xorg.conf # replace Driver in Device section by "nvidia" {% endhighlight %} + + Now you should reboot the system. From feabcb53cf6e75da80f11e8ed7fdf82ed628a8c7 Mon Sep 17 00:00:00 2001 From: Michael Carbone Date: Wed, 26 Aug 2015 04:16:20 -0400 Subject: [PATCH 067/174] added 3.0rc2 and liveUSB release to Recent News --- WikiStart.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/WikiStart.md b/WikiStart.md index 85794692..24fd6d97 100644 --- a/WikiStart.md +++ b/WikiStart.md @@ -29,6 +29,8 @@ Qubes is an open-source operating system designed to provide strong security for Recent News ----------- +- `Aug 10, 2015` Qubes OS 3.0 rc2 LiveUSB (alpha) has been released! [announcement](https://groups.google.com/d/msg/qubes-users/IQdCEpkooto/iyMh3LuzCAAJ) +- `Jul 31, 2015` Qubes OS 3.0 rc2 has been released! [announcement](https://groups.google.com/d/msg/qubes-users/jw9CdQepMPE/95HQDF6QBwAJ) - `Apr 23, 2015` Qubes OS 3.0 rc1 has been released! [announcement](http://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html) - `Nov 20, 2014` [Article about Qubes OS](http://www.wired.com/2014/11/protection-from-hackers/) in Wired - `Oct 19, 2014` LinuxCon EU 2014 slides: [keynote](http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Keynote.pdf) and [tutorial](http://www.invisiblethingslab.com/resources/2014/LinuxCon_2014_Qubes_Tutorial.pdf) From 2eee93e67f3967eeef8796929977fd0367d0bbd3 Mon Sep 17 00:00:00 2001 From: unman Date: Sun, 30 Aug 2015 18:31:11 +0000 Subject: [PATCH 068/174] Update Debian.md --- Templates/Debian.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/Templates/Debian.md b/Templates/Debian.md index 6ebd245e..41732b53 100644 --- a/Templates/Debian.md +++ b/Templates/Debian.md @@ -26,14 +26,19 @@ Install It can be installed via the following command: -Debian 7 (wheezy) - stable: +Debian 7 (wheezy) - old stable: [user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-7 -Debian 8 (jessie) - testing: +Debian 8 (jessie) - stable: [user@dom0 ~]$ sudo qubes-dom0-update qubes-template-debian-8 + +Debian 9 (stretch) - testing: +A prebuilt template is not yet available, but you can build an experimental stretch template from source. + + Known issues ------------ From a58d81bca0115470ee8403c6eb0ccf3875740424 Mon Sep 17 00:00:00 2001 From: Wojtek Porczyk Date: Tue, 1 Sep 2015 17:54:35 +0200 Subject: [PATCH 069/174] VersionScheme: wrap at 80 characters --- VersionScheme.md | 61 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 50 insertions(+), 11 deletions(-) diff --git a/VersionScheme.md b/VersionScheme.md index 667684dd..740850ef 100644 --- a/VersionScheme.md +++ b/VersionScheme.md @@ -8,36 +8,75 @@ redirect_from: /wiki/VersionScheme/ Version Scheme ============== -Beginning with R3 release, we change (and formalise) the versioning scheme. From now on, it will be as follows. +Beginning with R3 release, we change (and formalise) the versioning scheme. +From now on, it will be as follows. Qubes distributions and products -------------------------------- -We intend to make it easy to make a remix of qubes, targetting another hypervisor or isolation provider. We may also create commercial products intended for specific circumstances. There is one distinguished distribution called **Qubes OS**. All source code for it is available for download under GPL licence and is openly developed on the mailing lists. The rest of this document discusses Qubes OS. Another remix may have its own version series. +We intend to make it easy to make a remix of qubes, targetting another +hypervisor or isolation provider. We may also create commercial products +intended for specific circumstances. There is one distinguished distribution +called **Qubes OS**. All source code for it is available for download under GPL +licence and is openly developed on the mailing lists. The rest of this document +discusses Qubes OS. Another remix may have its own version series. Release version --------------- -Qubes OS as a whole is released from time to time. Version scheme for all releases is modelled after Linux kernel version numbers. When announcing new release, we decide on the major.minor version (like `3.0`) and release `3.0-rc1`. When we feel that enough progress has been made, we put `3.0-rc2` and so on. All these versions are considered unstable and not ready for production. You may ask for support on mailing lists (specifically **qubes-devel**), but it is not guaranteed (you may for example get answer „update to newer `-rc`”). Public ISO image may or may not be available. +Qubes OS as a whole is released from time to time. Version scheme for all +releases is modelled after Linux kernel version numbers. When announcing new +release, we decide on the major.minor version (like `3.0`) and release +`3.0-rc1`. When we feel that enough progress has been made, we put `3.0-rc2` +and so on. All these versions are considered unstable and not ready for +production. You may ask for support on mailing lists (specifically +**qubes-devel**), but it is not guaranteed (you may for example get answer +„update to newer `-rc`”). Public ISO image may or may not be available. -When enough development has been made, we announce the first stable version, like e.g. `3.0.0` (i.e. without `-rc`). This version is considered stable and we support it for some period. Core components are branched at this moment and bugfixes are backported from master branch. Questions about stable release should be directed to the **qubes-users** mailing list. No major features and interface incompatibilities are to be included in this release. We release bugfixes as `3.0.1`, `3.0.2` and so on, while new features come into the next release e.g. `3.1-rcX`. +When enough development has been made, we announce the first stable version, +like e.g. `3.0.0` (i.e. without `-rc`). This version is considered stable and +we support it for some period. Core components are branched at this moment and +bugfixes are backported from master branch. Questions about stable release +should be directed to the **qubes-users** mailing list. No major features and +interface incompatibilities are to be included in this release. We release +bugfixes as `3.0.1`, `3.0.2` and so on, while new features come into the next +release e.g. `3.1-rcX`. -Tickets in the tracker are sorted out by release major.minor, such as `3.0`, `3.1` (trac calls this „milestone”). +Tickets in the tracker are sorted out by release major.minor, such as `3.0`, +`3.1` (trac calls this „milestone”). Component version ----------------- -Qubes release is defined as specific versions of components, which are developed more or less separately. Their versions are composed of major and minor version of target Qubes OS release followed by third component which is just incremented. There is no apparent indication that given version is stable or not. +Qubes release is defined as specific versions of components, which are +developed more or less separately. Their versions are composed of major and +minor version of target Qubes OS release followed by third component which is +just incremented. There is no apparent indication that given version is stable +or not. -There are some non-essential components like `qubes-apps-*` that are shared between releases. Their versions indicate oldest qubes-release that is supported. We try hard to support multiple releases by one branch to ease code maintenance. +There are some non-essential components like `qubes-apps-*` that are shared +between releases. Their versions indicate oldest qubes-release that is +supported. We try hard to support multiple releases by one branch to ease code +maintenance. -Different Qubes releases remixes may comprise of different components and version are not guaranteed to be monotonic between releases. We may decide that for newer release some component should be downgraded. There is no guarantee that arbitrary combination of different versions of random components will yield usable (or even install-able) compilation. +Different Qubes releases remixes may comprise of different components and +version are not guaranteed to be monotonic between releases. We may decide that +for newer release some component should be downgraded. There is no guarantee +that arbitrary combination of different versions of random components will +yield usable (or even install-able) compilation. Git tags and branches --------------------- -We mark each component version in the repository by tag containing `v`. Likewise, each Qubes OS release is marked by `R` tag. +We mark each component version in the repository by tag containing +`v`. Likewise, each Qubes OS release is marked by `R` tag. -At the release of some release we create branches named like `release2`. Only bugfixes and compatible improvements are backported to these branches. These branches should compile. All new development is done in `master` branch. This branch is totally unsupported and may not even compile depending on maintainer of repository. +At the release of some release we create branches named like `release2`. Only +bugfixes and compatible improvements are backported to these branches. These +branches should compile. All new development is done in `master` branch. This +branch is totally unsupported and may not even compile depending on maintainer +of repository. -All version and release tags should be made and signed by someone from ITL staff. Public keys are included in `qubes-builder` and available at [http://keys.qubes-os.org/keys/](http://keys.qubes-os.org/keys/). +All version and release tags should be made and signed by someone from ITL +staff. Public keys are included in `qubes-builder` and available at +[http://keys.qubes-os.org/keys/](http://keys.qubes-os.org/keys/). From 0ddfb2c2fc67734f71941153a2d9b00b1e5cfc1e Mon Sep 17 00:00:00 2001 From: Jeepler Date: Tue, 1 Sep 2015 22:16:40 +0200 Subject: [PATCH 070/174] added description of QvmFirewall rule --- Dom0Tools/QvmFirewall.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Dom0Tools/QvmFirewall.md b/Dom0Tools/QvmFirewall.md index 121e569e..1a0529d6 100644 --- a/Dom0Tools/QvmFirewall.md +++ b/Dom0Tools/QvmFirewall.md @@ -11,7 +11,7 @@ qvm-firewall NAME ---- -qvm-firewall +qvm-firewall - manage VM's firewall rules Date 2012-04-10 From 1019352238702a09d2e0d5725822b9e8f0155bfb Mon Sep 17 00:00:00 2001 From: Wojtek Porczyk Date: Tue, 1 Sep 2015 20:36:30 +0200 Subject: [PATCH 071/174] VersionScheme: add release schedule rules --- VersionScheme.md | 36 ++++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/VersionScheme.md b/VersionScheme.md index 740850ef..793e5c9b 100644 --- a/VersionScheme.md +++ b/VersionScheme.md @@ -45,6 +45,42 @@ release e.g. `3.1-rcX`. Tickets in the tracker are sorted out by release major.minor, such as `3.0`, `3.1` (trac calls this „milestone”). +Release schedule +---------------- + +There is no specific schedule for major and minor other that more general +roadmap. When time comes, Supreme Committee declares feature freeze and tags +`-rc1` and releases ISO image. From this time on, no new features are accepted. +Also a strict time schedule kicks in. + +Each release candidate period is as follows. For the first two weeks we accept +and assign bugreports to be fixed before next release candidate. For the next +two weeks we generally focus on fixing assigned bugreports, so issues discovered +during this time may be postponed until later RC. Finally after that there is +one week of current-testing freeze, during which time no new packages are +released, in hope that they will be installed by wider user base and tested. + +The next RC is released five weeks after the former. All packets are published +in `current` repository and the cycle starts over. There should be no less than +1 and no more than 3 release candidates before final release. + + + + + + + + + + +
stagetime
initial testing2 weeks
bug fixing2 weeks
`current-testing` freeze1 week
+ +Starting with second cycle (that is, after `-rc1`) two weeks into the cycle +(after primary bug-reporting period) the Supreme Committee decides wether there +should be another RC. If, based on remaining issues, the Committee decides to +release final, then the Committee agrees upon the release date, which should be +no later than a week after. + Component version ----------------- From 48139991069a6587e8cf4f2016aede2b4756c877 Mon Sep 17 00:00:00 2001 From: Wojtek Porczyk Date: Wed, 2 Sep 2015 11:35:05 +0200 Subject: [PATCH 072/174] Release 3.0 draft --- releases/3.0/release-notes.md | 30 ++++++++++++++++++++++++++++++ releases/3.0/schedule.md | 22 ++++++++++++++++++++++ 2 files changed, 52 insertions(+) create mode 100644 releases/3.0/release-notes.md create mode 100644 releases/3.0/schedule.md diff --git a/releases/3.0/release-notes.md b/releases/3.0/release-notes.md new file mode 100644 index 00000000..c68ba475 --- /dev/null +++ b/releases/3.0/release-notes.md @@ -0,0 +1,30 @@ +--- +layout: doc +title: Qubes R3.0 release notes +permalink: /doc/releases/3.0/release-notes/ +--- + +Qubes R3.0 release notes +======================== + +*this page is a draft for yet unreleased version* + +New features since 2.0 +---------------------- + +* Xen 4.4 +* Qrexec 3 +* Debian templates +* Whonix templates +* Build system improvements + +Known issues +------------ + +* Windows Tools: `qvm-block` does not work + +Downloads +--------- + +Installation instructions +------------------------- diff --git a/releases/3.0/schedule.md b/releases/3.0/schedule.md new file mode 100644 index 00000000..483f21eb --- /dev/null +++ b/releases/3.0/schedule.md @@ -0,0 +1,22 @@ +--- +layout: doc +title: Qubes R3.0 release schedule +permalink: /doc/releases/3.0/schedule/ +--- + +Qubes R3.0 release schedule +=========================== + + + + + + + + current-testing freeze + + + + + +
datestage
3.0-rc2
5.09.2015
3.0-rc3
15.09.2015ISO
3.0
1.10.2015ISO
From 9048ddd3203d67d6b569fe29ba8402669cb9c66e Mon Sep 17 00:00:00 2001 From: Wojtek Porczyk Date: Wed, 2 Sep 2015 11:43:38 +0200 Subject: [PATCH 073/174] Add checklist for releases --- releases/todo.md | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 releases/todo.md diff --git a/releases/todo.md b/releases/todo.md new file mode 100644 index 00000000..a2af9581 --- /dev/null +++ b/releases/todo.md @@ -0,0 +1,31 @@ +--- +layout: doc +title: Release checklist +permalink: /doc/releases/todo/ +--- + +Release checklist +================= + +*the checklist is probably unfinished* + +On -rc1 +------- +* write schedule +* push all packages to `current-testing` +* draft release notes, one note per feature +* build ISO and push to mirrors + +On subsequent -rc +----------------- +* push packages to `current` +* update release notes +* build ISO and push to mirrors + +On final release +---------------- +* push packages to `current` +* finish release notes +* build ISO and push to mirrors +* write blog post +* announce on Twitter From f74f5038210b3bf9990eeda0d10389f54d7b68bc Mon Sep 17 00:00:00 2001 From: unman Date: Thu, 3 Sep 2015 00:18:20 +0000 Subject: [PATCH 074/174] Clarified docs on USB controllers and devices. Updated page on Stick mounting. Added section to FAQ on usb controller problems. --- StickMounting.md | 22 +++++++++++++++------- UserFaq.md | 24 +++++++++++++++++++++++- 2 files changed, 38 insertions(+), 8 deletions(-) diff --git a/StickMounting.md b/StickMounting.md index 2e1b65b1..b8ad5466 100644 --- a/StickMounting.md +++ b/StickMounting.md @@ -12,7 +12,9 @@ How to Mount USB Sticks to AppVMs Qubes supports the ability to attach a USB stick (or just one or more of its partitions) to any AppVM easily, no matter which VM actually handles the USB controller. (The USB controller may be assigned on the **Devices** tab of an AppVM's settings page in Qubes VM Manager or by using the [qvm-pci command](/doc/AssigningDevices/).) -As of Qubes R2 Beta 3, USB stick mounting has been integrated into the Qubes VM Manger GUI. Simply insert your USB stick, right-click the desired AppVM in the Qubes VM Manager list, click **Attach/detach block devices**, and select your desired action and device. This, however, only works for the whole device. If you would like to attach individual partitions you must use the command-line tool (shown below). The reason for this is that when attaching a single partition, it used to be that Nautilus file manager would not see it and automatically mount it (see [this ticket](https://github.com/QubesOS/qubes-issues/issues/623)). This problem, however, seems to be resolved (see [this issue comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124270051)). If for some reason it does not show up in nautilus for you and you still need to attach just a single partition to a device, you will need to mount it manually; the device will show up as /dev/xvdi (or /dev/xvdj if there is already one device attached--/dev/xvdk and so on). +As of Qubes R2 Beta 3, USB stick mounting has been integrated into the Qubes VM Manager GUI. Simply insert your USB stick, right-click the desired AppVM in the Qubes VM Manager list, click **Attach/detach block devices**, and select your desired action and device. This, however, only works for the whole device. +If you would like to attach individual partitions you must use the command-line tool (shown below). The reason for this is that when attaching a single partition, it used to be that Nautilus file manager would not see it and automatically mount it (see [this ticket](https://github.com/QubesOS/qubes-issues/issues/623)). This problem, however, seems to be resolved (see [this issue comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124270051)). +If for some reason the device does not appear in nautilus and you still need to attach just a single partition to a device, you will need to mount it manually; the device will show up as /dev/xvdi (or /dev/xvdj if there is already one device attached - if two, /dev/xvdk and so on). The command-line tool you may use to mount whole USB sticks or their partitions is `qvm-block`. This tool can be used to assign a USB stick to an AppVM as follows: @@ -23,21 +25,27 @@ The command-line tool you may use to mount whole USB sticks or their partitions qvm-block -l This will list all available block devices connected to any USB controller - in your system, no matter in which VM hosts the controller. The name of the + in your system, no matter which VM hosts the controller. The name of the VM hosting the USB controller is displayed before the colon in the device name. The string after the colon is the name of the device used within the - VM. + VM. Like this: + + dom0:sdb1 Cruzer () 4GiB + + usbVM:sdb1 Disk () 2GiB **Note:** If your device is not listed here, you may refresh the list by calling (from the VM to which device is connected): sudo udevadm trigger --action=change -1. Assuming our USB stick is sdb, we attach the device to an AppVM like so: +1. Assuming our USB stick is attached to dom0 and is sdb, we attach the device to an AppVM like so: - qvm-block -a personal dom0:sdb + `qvm-block -a personal dom0:sdb` - This will attach the device as "/dev/xvdi", if not already taken by another attached device, in the AppVM. You may also mount one partition at a time by using the same command with the partition number after sdb. + This will attach the device to the AppVM as "/dev/xvdi", if not already taken by another attached device, or "/dev/xvdj" etc. + + You may also mount one partition at a time by using the same command with the partition number after sdb. **Warning: when working with single partitions, it is possible to assign the same partition to multiple VMs.** For example, you could attach sdb1 to VM1 and then sdb to VM2. It is up to the user not to make this mistake. Xen block device framework currently does not provide an easy way around this. Point 2 of [this ticket comment](https://github.com/QubesOS/qubes-issues/issues/1072#issuecomment-124119309) gives details on this. @@ -78,7 +86,7 @@ this steps: sys-usb:sda DataTraveler_2.0 () 246 MiB (attached to 'testvm' as 'xvdi') [user@dom0 ~]$ xl block-attach testvm phy:/dev/sda backend=sys-usb xvdi - In above example all `xl block-attach` parameters can be deducted from + In above example all `xl block-attach` parameters can be deduced from `qvm-block` output. In order: * `testvm` - name of target VM to which device was attached - listed in brackets by `qvm-block` command diff --git a/UserFaq.md b/UserFaq.md index e8ac15d7..23ec8e59 100644 --- a/UserFaq.md +++ b/UserFaq.md @@ -39,7 +39,8 @@ Qubes Users' FAQ 2. [My keyboard layout settings are not behaving correctly. What should I do?](#my-keyboard-layout-settings-are-not-behaving-correctly-what-should-i-do) 3. [My dom0 and/or TemplateVM update stalls when attempting to update via …](#my-dom0-andor-templatevm-update-stalls-when-attempting-to-update-via-the-gui-tool-what-should-i-do) 4. [How do I run a Windows HVM in non-seamless mode (i.e., as a single window)?](#how-do-i-run-a-windows-hvm-in-non-seamless-mode-ie-as-a-single-window) - 5. [I assigned a PCI device to an AppVM, then unassigned it/shut down the …](#i-assigned-a-pci-device-to-an-appvm-then-unassigned-itshut-down-the-appvm-why-isnt-the-device-available-in-dom0) + 5. [I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot.](#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot) + 6. [I assigned a PCI device to an AppVM, then unassigned it/shut down the …](#i-assigned-a-pci-device-to-an-appvm-then-unassigned-itshut-down-the-appvm-why-isnt-the-device-available-in-dom0) General Questions ----------------- @@ -187,6 +188,27 @@ In your TemplateVMs, open a terminal and run `sudo yum upgrade`. Enable "debug mode" in the AppVM's settings, either by checking the box labelled "Run in debug mode" in the Qubes VM Manager AppVM settings menu or by running the [qvm-prefs command](/doc/Dom0Tools/QvmPrefs/).) + +### I created a usbVM and assigned usb controllers to it. Now the usbVM wont boot. + + +This is probably because one of the controllers does not support reset. In Qubes R2 any such errors were ignored but in Qubes R3.0 they are not. +A device that does not support reset is not safe and generally should not be assigned to a VM. + +Most likely the offending controller is a USB3.0 device. You can remove this controller from the usbVM, and see if this allows the VM to boot. +Alternatively you may be able to disable USB 3.0 in the BIOS. + +Another solution would be to set the pci_strictreset option using qvm-prefs in dom0: + +`qvm-prefs usbVM -s pci_strictreset false` + +This option allows the VM to ignore the error and the VM will start. +Please review the note on [this page](https://www.qubes-os.org/doc/Dom0Tools/QvmPrefs/) and be aware of the potential risk. + + + + + ### I assigned a PCI device to an AppVM, then unassigned it/shut down the AppVM. Why isn't the device available in dom0? This is an intended feature. A device which was previously assigned to a less trusted AppVM could attack dom0 if it were automatically reassigned there. In order to re-enable the device in dom0, either: From 9d65a688beaeb26777054c94bd29114474ed32e2 Mon Sep 17 00:00:00 2001 From: unman Date: Thu, 3 Sep 2015 13:37:29 +0000 Subject: [PATCH 075/174] Added ref to FAQ in security guidelines on using USBVM. --- SecurityGuidelines.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/SecurityGuidelines.md b/SecurityGuidelines.md index 1993a247..399ca005 100644 --- a/SecurityGuidelines.md +++ b/SecurityGuidelines.md @@ -127,9 +127,9 @@ Creating and Using a USBVM The connection of an **untrusted USB external drive to Dom0** may involve some risk because Dom0 reads **partition tables** automatically, and also because the whole USB stack is put to work **to parse** all the USB device info first, to determine if it is a USB Mass Storage, and to read its config, etc. This happens even if the drive is then assigned and mounted in another VM. -To avoid this risk it is possible to prepare and utilize a **USBVM**. However this is not presently recommended for beginners, as Xen does not yet provide a working PVUSB, and so only USB Mass Storage devices could be passed to individual VMs later (via qvm-block). This involves that a USBVM cannot be preinstalled and the whole thing cannot be automatized. So avoid it if you have doubts. +To avoid this risk it is possible to prepare and utilize a **USBVM**. However this is not presently recommended for beginners, as Xen does not yet provide a working PVUSB, and so only USB Mass Storage devices can be passed to individual VMs later (via qvm-block). This means that a USBVM cannot be preinstalled and the whole thing cannot be automated. So avoid it if you have doubts. -Also avoid it if you do not have a **USB controller free of input devices** or programmable devices. However, as already noted most laptops use PS-2 for keyboards and touchpad devices which do not cause problems. +Also avoid it if you do not have a **USB controller free of input devices** or programmable devices, for the reasons above. However, as already noted most laptops use PS-2 for keyboards and touchpad devices which do not cause problems. An **USBVM** operates like a dedicated temporary parking area, used just to prevent any contact between dom0 and the USB drive. Then, every time you connect an **untrusted USB external drive** to a USB port managed by that USB controller, you need to attach it to the VM that needs it, using qubes manager or [terminal](/doc/StickMounting/). Again, this **works only for disk-like USB devices**. Other devices cannot be currently virtualized. So once you assign their controller to your **USBVM** they'll be no more available. @@ -140,7 +140,7 @@ An **USBVM** operates like a dedicated temporary parking area, used just to prev 3. Give it "red" or "orange" or "yellow" label. 4. In the AppVM's settings, go to the "devices" tab. Find your USB controller in the "Available" list. Move it to the "Selected" list. 5. Click OK. Restart the AppVM. (Restarting may not even be required.) -6. **In dom0 terminal**, run +6. Set the VM to start automatically at Boot using the VM Manager, (under VM Settings), or **In dom0 terminal**, run {% highlight trac-wiki %} qvm-prefs -s usbvm autostart true @@ -148,6 +148,9 @@ An **USBVM** operates like a dedicated temporary parking area, used just to prev This will cause your new **USBVM** to automatically start when the system starts up. So that in case you forgot to start it and then accidentally plugged a USB stick (or your colleague at work did it while you were at lunch), **it won't compromise the Dom0**. +If the USBVM will not start, look at [this faq](../UserFaq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot) + + Dom0 Precautions ---------------- From c7499fa9b8e76b2525e2c645386cca3424202294 Mon Sep 17 00:00:00 2001 From: unman Date: Thu, 3 Sep 2015 14:25:33 +0000 Subject: [PATCH 076/174] Added ref to FAQ to security guidelines on assigning USB controllers. --- SecurityGuidelines.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/SecurityGuidelines.md b/SecurityGuidelines.md index 399ca005..fe66c27d 100644 --- a/SecurityGuidelines.md +++ b/SecurityGuidelines.md @@ -122,6 +122,9 @@ It is preferably to avoid using **Bluetooth** if you travel and if you do not tr Many laptops will also allow one to disable various hardware (Camera, BT, Mic, etc) **in BIOS**. This might or might not be safe, depending on how much you trust your BIOS vendor. +If the VM will not start after you have assigned a USB controller, look at [this faq](../UserFaq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot) + + Creating and Using a USBVM -------------------------- From 233b55363a56f2abbb09c52b48c5c1817e715836 Mon Sep 17 00:00:00 2001 From: Stephan Renatus Date: Sat, 5 Sep 2015 09:55:34 +0200 Subject: [PATCH 077/174] nitpicking some typos, wording --- Templates/FedoraMinimal.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Templates/FedoraMinimal.md b/Templates/FedoraMinimal.md index 81415536..b0bb52b6 100644 --- a/Templates/FedoraMinimal.md +++ b/Templates/FedoraMinimal.md @@ -30,7 +30,7 @@ It is a good idea to clone the original template, and make any changes in the ne [user@dom0 ~]$ qvm-clone fedora-21-minimal {% endhighlight %} -The sudo package is not installed by default, so lets install it: +The sudo package is not installed by default, so let's install it: {% highlight trac-wiki %} [user@F21-Minimal ~]$ su - @@ -39,11 +39,11 @@ The sudo package is not installed by default, so lets install it: The rsyslog logging service is not installed by default. All logging is now being handled by the systemd journal. Users requiring the rsyslog service should install it manually. -To access the journald log, use the following command: `journalctl` +To access the journald log, use the `journalctl` command. ### as a NetVM -If You want to use this template to for standard NetVMs You should install some more packeges: +If you want to use this template to for standard NetVMs you should install some more packeges: {% highlight trac-wiki %} [user@F21-Minimal ~]$ sudo yum install NetworkManager NetworkManager-wifi network-manager-applet wireless-tools dbus-x11 dejavu-sans-fonts tar tinyproxy @@ -55,11 +55,11 @@ And maybe some more optional but useful packages as well: [user@F21-Minimal ~]$ sudo yum install pciutils vim-minimal less tcpdump telnet psmisc nmap nmap-ncat gnome-keyring {% endhighlight %} -If Your network device needs some firmware then you should also install the corresponding packages as well. The `lspci; yum search firmware` command will help to choose the right one :) +If your network device needs some firmware then you should also install the corresponding packages as well. The `lspci; yum search firmware` command will help to choose the right one :) ### as a ProxyVM -If You want to use this template as a ProxyVM You may want to install evem more packages +If you want to use this template as a ProxyVM you may want to install even more packages #### Firewall @@ -67,7 +67,7 @@ This template is ready to use for a standard firewall VM. #### VPN -The needed packages are depend on the VPN technology. `yum search "NetworkManager VPN plugin"` command may help you to choose the right one. +The needed packages depend on the VPN technology. The `yum search "NetworkManager VPN plugin"` command may help you to choose the right one. [More details about setting up a VPN Gateway](/wiki/VPN#ProxyVM) From 8d1237df056c20de6d98da27c761c46f26004f55 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Sun, 6 Sep 2015 00:38:09 +0200 Subject: [PATCH 078/174] Update keys.qubes-os.org to HTTPS --- VersionScheme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/VersionScheme.md b/VersionScheme.md index 793e5c9b..19855c34 100644 --- a/VersionScheme.md +++ b/VersionScheme.md @@ -115,4 +115,4 @@ of repository. All version and release tags should be made and signed by someone from ITL staff. Public keys are included in `qubes-builder` and available at -[http://keys.qubes-os.org/keys/](http://keys.qubes-os.org/keys/). +[https://keys.qubes-os.org/keys/](https://keys.qubes-os.org/keys/). From 35cde9e043eaced69823e9b4d7029e8831097ba0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Sun, 6 Sep 2015 00:57:56 +0200 Subject: [PATCH 079/174] Describe bug priorities meaning --- VersionScheme.md | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/VersionScheme.md b/VersionScheme.md index 19855c34..ca21f8db 100644 --- a/VersionScheme.md +++ b/VersionScheme.md @@ -81,6 +81,34 @@ should be another RC. If, based on remaining issues, the Committee decides to release final, then the Committee agrees upon the release date, which should be no later than a week after. +Bug priorities +-------------- + +When deciding whether the current release candidate is the final one, the Committee +takes bugs priorities into consideration. The meaning of them is as follows: + +* `blocker` - when any such bug is present in the current release candidate, it +can't be considered final release. Bugs with this priority must be fixed before +the next release candidate, even if that means delaying its release (which +should be considered only last resort option). + +* `critical` - when any such bug is present in the current release candidate, it +can't be considered final release. But such bugs are not qualified to delay +next release candidate release. + +* `major` - existence of such bugs do not strictly prevent the current release +candidate be considered final (but of course we should try hard to not have +them there). Fixing bugs of this priority can be delayed and qualified as +updates to the final stable release. + +* `minor` - existence of such bugs do not prevent the current release candidate +be considered final. Fixing such bugs can be delayed to the next Qubes OS +release. Eventually such fixes might be backported as an update to the stable +release(s). + +All above is about bugs, no features should be assigned to the current release +after first `-rc`. Supreme Committee is free to adjust priorities appropriately. + Component version ----------------- From a8f05399f6f29f4a04e6c7e687cff32e53a076af Mon Sep 17 00:00:00 2001 From: Robin Schneider Date: Mon, 7 Sep 2015 17:05:37 +0200 Subject: [PATCH 080/174] Fixed typo and renamed AppVM "red" to "untrusted" as for consistently reasons. * The GettingStarted page lists "untrusted" but not "red". --- GettingStarted.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/GettingStarted.md b/GettingStarted.md index 4b91bb31..bb771d17 100644 --- a/GettingStarted.md +++ b/GettingStarted.md @@ -51,7 +51,7 @@ You can start apps directly from the start menu. Each domain has its own menu di ![r2b1-appsmenu-1.png](/attachment/wiki/GettingStarted/r2b1-appsmenu-1.png) ![r2b1-appsmenu-3.png](/attachment/wiki/GettingStarted/r2b1-appsmenu-3.png) -By default, each domain's menu contains only a few shortcuts. If you'd like to add more, simply click **Add more shortcuts...**, select the desired applictions, and click **OK**. You can also add shortcuts manually. (This is sometimes necessary if the desired application doesn't show up in the Qubes VM Manager window.) To do this in KDE, right-click on the **Start** button and click **Menu Editor**. Click the domain directory in which you'd like the menu to appear, click **New Item**, enter its name as **\: \**, and provide the command for starting the app (see below). Then click **Save** and wait approximately 15 seconds for the changes to propagate to the KDE menu. +By default, each domain's menu contains only a few shortcuts. If you'd like to add more, simply click **Add more shortcuts...**, select the desired applications, and click **OK**. You can also add shortcuts manually. (This is sometimes necessary if the desired application doesn't show up in the Qubes VM Manager window.) To do this in KDE, right-click on the **Start** button and click **Menu Editor**. Click the domain directory in which you'd like the menu to appear, click **New Item**, enter its name as **\: \**, and provide the command for starting the app (see below). Then click **Save** and wait approximately 15 seconds for the changes to propagate to the KDE menu. To start apps from the console in dom0, type: @@ -62,7 +62,7 @@ qvm-run -a " [arguments]" e.g.: {% highlight trac-wiki %} -qvm-run -a red firefox +qvm-run -a untrusted firefox {% endhighlight %} Adding, Removing, and Listing Domains From 4a2c7b764adebc8993dcf1c77311867672c7e6c2 Mon Sep 17 00:00:00 2001 From: Michael Carbone Date: Fri, 11 Sep 2015 13:18:34 -0400 Subject: [PATCH 081/174] fixed typos, one formatting issue please review to make sure re: formatting issue --- Mutt.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Mutt.md b/Mutt.md index 1ee800dd..a86aad17 100644 --- a/Mutt.md +++ b/Mutt.md @@ -14,9 +14,9 @@ Mutt lacks true MTA (Message Transfer Agent aka "SMTP client") and MRA (Mail Retrieval Agent aka "IMAP/POP3 client"), thus there are some provisions built-in. In principle it is only mail reader and composer. You may install true MTA such as [Postfix](/doc/Postfix/) or Exim and MRA such as -[Fetchmail](/doc/Fetchmail/). Alternativelly you can synchronize your mailbox +[Fetchmail](/doc/Fetchmail/). Alternatively you can synchronize your mailbox using [OfflineIMAP](https://github.com/OfflineIMAP/offlineimap) and just stick -to integrated SMTP support. You can even use itegrated IMAP client, but it is +to integrated SMTP support. You can even use integrated IMAP client, but it is not very convenient. Installation @@ -188,6 +188,7 @@ In `.urlview`: In `.mailcap`: + ### TODO: override most/all default mailcap settings to prevent ### opening in muttvm ### is there a way to do this polymorphically? i.e. not From 4c366d2474ca69914f8ff56859ff98464916a8ea Mon Sep 17 00:00:00 2001 From: Michael Carbone Date: Sat, 12 Sep 2015 11:29:32 -0400 Subject: [PATCH 082/174] fixed typo --- SimpleIntro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/SimpleIntro.md b/SimpleIntro.md index d1121ba5..50a73be0 100644 --- a/SimpleIntro.md +++ b/SimpleIntro.md @@ -40,7 +40,7 @@ Booting your computer from a live CD (or DVD) when you need to perform sensitive How does Qubes compare to running VMs in a convential OS? --------------------------------------------------------- -Not all virtual machine software is equal when it comes to security. You may have used or heard of VMs in relation to software like VirtualBox or VMware Workstation. These are known as "Type 2" or "hosted" hypervisors. (The **hypervisor** is the software, firmare, or hardware that creates and runs virtual machines.) These programs are popular because they're designed primarily to be easy to use and run under popular OSes like Windows (which is called the **host** OS, since it "hosts" the VMs). However, the fact that Type 2 hypervisors run under the host OS means that they're really only as secure as the host OS itself. If the host OS is ever compromised, then any VMs it hosts are also effectivley compromised. +Not all virtual machine software is equal when it comes to security. You may have used or heard of VMs in relation to software like VirtualBox or VMware Workstation. These are known as "Type 2" or "hosted" hypervisors. (The **hypervisor** is the software, firmare, or hardware that creates and runs virtual machines.) These programs are popular because they're designed primarily to be easy to use and run under popular OSes like Windows (which is called the **host** OS, since it "hosts" the VMs). However, the fact that Type 2 hypervisors run under the host OS means that they're really only as secure as the host OS itself. If the host OS is ever compromised, then any VMs it hosts are also effectively compromised. By contrast, Qubes uses a "Type 1" or "bare metal" hypervisor called [Xen](http://www.xenproject.org). Instead of running inside an OS, Type 1 hypervisors run directly on the "bare metal" of the hardware. This means that an attacker must be capable of subverting the hypervisor itself in order to compromise the entire system, which is vastly more difficult. From a64b715fbf1571a0e7e140547fe6dedc515ec0a9 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Mon, 14 Sep 2015 21:47:26 +0200 Subject: [PATCH 083/174] downloads: update mirrors list --- QubesDownloads.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/QubesDownloads.md b/QubesDownloads.md index 7ebff55c..f2fb807a 100644 --- a/QubesDownloads.md +++ b/QubesDownloads.md @@ -57,7 +57,5 @@ Mirrors Qubes ISOs are also available from the following mirrors: -- [http://ftp.fsn.hu/pub/linux/distributions/qubes/](http://ftp.fsn.hu/pub/linux/distributions/qubes/) -- [http://linuxtracker.org/index.php?page=torrent-details&id=3bdf893771d63bdbe3d83f31e064360ee10f30ec](http://linuxtracker.org/index.php?page=torrent-details&id=3bdf893771d63bdbe3d83f31e064360ee10f30ec) -- [http://burnbit.com/torrent/303367/Qubes\_R2\_rc2\_x86\_64\_DVD\_iso](http://burnbit.com/torrent/303367/Qubes_R2_rc2_x86_64_DVD_iso) - +- [Burnbit torrent](http://burnbit.com/search?q=qubes) +- [mirrors.kernel.org](http://mirrors.kernel.org/qubes/iso/) From ecd22417a27b766c2eaa85740cb92c9538c32e6f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Tue, 15 Sep 2015 23:39:59 +0200 Subject: [PATCH 084/174] Unified installation guide Move "Upgrading" and "Known Issues" sections to release notes --- InstallationGuide.md | 94 +++++++------------ InstallationGuideR2.md | 107 --------------------- InstallationGuideR2B1.md | 99 ------------------- InstallationGuideR2B2.md | 90 ------------------ InstallationGuideR2B3.md | 120 ------------------------ InstallationGuideR2rc1.md | 105 --------------------- InstallationGuideR2rc2.md | 99 ------------------- InstallationGuideR3.0rc1.md | 93 ------------------ InstallationGuideR3.0rc2.md | 98 ------------------- QubesDownloads.md | 14 +-- UpgradeToR2rc1.md => UpgradeToR2.md | 17 ++-- UpgradeToR3.0rc1.md => UpgradeToR3.0.md | 9 +- releases.md | 24 +++++ releases/1.0/release-notes.md | 54 +++++++++++ releases/2.0/release-notes.md | 89 ++++++++++++++++++ releases/3.0/release-notes.md | 28 ++++++ 16 files changed, 252 insertions(+), 888 deletions(-) delete mode 100644 InstallationGuideR2.md delete mode 100644 InstallationGuideR2B1.md delete mode 100644 InstallationGuideR2B2.md delete mode 100644 InstallationGuideR2B3.md delete mode 100644 InstallationGuideR2rc1.md delete mode 100644 InstallationGuideR2rc2.md delete mode 100644 InstallationGuideR3.0rc1.md delete mode 100644 InstallationGuideR3.0rc2.md rename UpgradeToR2rc1.md => UpgradeToR2.md (82%) rename UpgradeToR3.0rc1.md => UpgradeToR3.0.md (93%) create mode 100644 releases.md create mode 100644 releases/1.0/release-notes.md create mode 100644 releases/2.0/release-notes.md diff --git a/InstallationGuide.md b/InstallationGuide.md index 550a5108..40911a2c 100644 --- a/InstallationGuide.md +++ b/InstallationGuide.md @@ -1,37 +1,43 @@ --- layout: doc -title: InstallationGuide +title: Installation Guide permalink: /doc/InstallationGuide/ redirect_from: /wiki/InstallationGuide/ +redirect_from: /doc/InstallationGuideR1/ +redirect_from: /doc/InstallationGuideR2B1/ +redirect_from: /doc/InstallationGuideR2B2/ +redirect_from: /doc/InstallationGuideR2B3/ +redirect_from: /doc/InstallationGuideR2rc1/ +redirect_from: /doc/InstallationGuideR2rc2/ +redirect_from: /doc/InstallationGuideR3.0rc1/ +redirect_from: /doc/InstallationGuideR3.0rc2/ --- -Installation Guide (for Qubes Release 1) +Installation Guide ======================================== -1. [Hardware Requirements](#HardwareRequirements) -2. [Download installer ISO](#DownloadinstallerISO) -3. [Burning the ISO onto a DVD or USB stick](#BurningtheISOontoaDVDorUSBstick) -4. [Upgrading from Qubes 1.0-rc1](#UpgradingfromQubes1.0-rc1) -5. [Migrating from Qubes Beta 3](#MigratingfromQubesBeta3) -6. [Installing Updates](#InstallingUpdates) -7. [Known Issues](#KnownIssues) -8. [Getting Help](#GettingHelp) +1. [Hardware Requirements](#hardware-requirements) +2. [Download installer ISO](#download-installer-iso) +3. [Burning the ISO onto a DVD or USB stick](#burning-the-iso-onto-a-dvd-or-usb-stick) +4. [Upgrading](#upgrading) +5. [Troubleshooting problems with the installer](#troubleshooting-problems-with-the-installer) +6. [Getting Help](#getting-help) Hardware Requirements --------------------- Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. -Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. +Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). Download installer ISO ---------------------- -See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: +See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: -{% highlight trac-wiki %} -gpg -v .asc -{% endhighlight %} + gpg -v Qubes-R2-x86_64-DVD.iso.asc + +Adjust filename to the version you're installing. Burning the ISO onto a DVD or USB stick --------------------------------------- @@ -40,11 +46,15 @@ Once you verify this is an authentic ISO, you should burn it on a DVD. If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: -{% highlight trac-wiki %} -dd if=Qubes-R1-x86_64-DVD.iso of=/dev/sdX -{% endhighlight %} + dd if=Qubes-R2-x86_64-DVD.iso of=/dev/sdX -**Be sure to use a correct device as the target in the dd command above (instead of sdX)'''** +Adjust filename to the version you're installing. **Be sure to use a correct device as the target in the dd command above (instead of sdX)'''** + +On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator): + + dd if=Qubes-R2-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress + +Adjust filename to the version you're installing. **Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)** Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. @@ -52,45 +62,12 @@ Then, when finally ready, boot your system from the installer DVD and follow the The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) -Upgrading from Qubes 1.0-rc1 ----------------------------- +Upgrading +--------- -If you're already running Qubes 1.0-rc1, you don't need to reinstall, it's just enough to update the packages in your Dom0 and the template VM(s). The easiest way for doing this is to click on the Update Button in the Qubes Manger -- one click when you selected Dom0, and one click for each of your template VM (by default there is just one template). +See [release notes](/doc/releases/) of appropriate version. -Migrating from Qubes Beta 3 ---------------------------- -If you have Qubes Beta 3 currently installed on your system, you must reinstall from scratch, as we offer no direct upgrade option in the installer (sorry). However, we do offer tools for smooth migration of your AppVMs. In order to do that, please backup your AppVMs using the `qvm-backup` tool [as usual](/doc/BackupRestore/). Then, after you install Qubes 1.0 rc1, you can restore them using `qvm-backup-restore` tool. However, because we have changed the default template in RC1, you should tell qvm-back-restore about that by passing `--replace-template` option: - -{% highlight trac-wiki %} -qvm-backup-restore --replace-template=fedora-15-x64:fedora-17-x64 -{% endhighlight %} - -Installing Updates ------------------- - -Installing updates is very easy and can be done using the "Update" button in the Qubes Manager. Alternatively it can also be done from command prompt -- see the following for more details: - -- For installing updates for Dom0 -- see instructions [here](/doc/SoftwareUpdateDom0/). -- For installing updates for you domains (VMs) -- see instructions [here](/doc/SoftwareUpdateVM/). - -Known Issues ------------- - -- Installer might not support some USB keyboards (\#230). This seems to include all the Mac Book keyboards (most PC laptops have PS2 keyboards and are not affected). - -- If you don't enable Composition (System Setting -\> Desktop -\> Enable desktop effects), which you really should do, then the KDE task bar might get somehow ugly (e.g. half of it might be black). This is some KDE bug that we don't plan to fix. - -- Some keyboard layout set by KDE System Settings can cause [keyboard not working at all](https://groups.google.com/group/qubes-devel/browse_thread/thread/77d076b65dda7226). If you hit this issue, you can switch to console (by console login option) and manually edit `/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf` (and `/etc/sysconfig/keyboard`) and place correct keyboard layout settings (details in linked thread). You can check if specific keyboard layout settings are proper using `setxkbmap` tool. - -- On systems with more than 8GB of RAM there is problem with Disposable VM. To fix it, limit maximum memory allocation for DispVM to 3GB - - {% highlight trac-wiki %} - qvm-prefs -s fedora-17-x64-dvm maxmem 3072 - qvm-create-default-dvm --default-template --default-script - {% endhighlight %} - -- On some systems the KDE Window Manager might freeze upon resuming from S3 sleep when compositing is enabled (and the only method to log in to the system if this happens is to switch to a text console, enter your user's password, kill the kwin process, go back to the Xorg console, log in, and start a new instance of kwin using Konsole application :) If you experience such problems, make sure to disable compositing before putting the system into sleep by pressing Alt-Ctrl-F12 (and then enabling it back once you log in after resume) -- this way you should never see this problem again. Getting Help ------------ @@ -99,7 +76,8 @@ Getting Help - Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) -- If you don't find answer in the sources given above, write to the *qubes-devel* mailing list: - - [http://groups.google.com/group/qubes-devel](http://groups.google.com/group/qubes-devel) - - `qubes-devel@googlegroups.com` +- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below): + - [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users) + - `qubes-users@googlegroups.com` +- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. diff --git a/InstallationGuideR2.md b/InstallationGuideR2.md deleted file mode 100644 index fcc1d1b6..00000000 --- a/InstallationGuideR2.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -layout: doc -title: InstallationGuideR2 -permalink: /doc/InstallationGuideR2/ -redirect_from: /wiki/InstallationGuideR2/ ---- - -Installation Guide for Qubes Release 2 -====================================== - -1. [Hardware Requirements](#HardwareRequirements) -2. [Download installer ISO](#DownloadinstallerISO) -3. [Burning the ISO onto a DVD or USB stick](#BurningtheISOontoaDVDorUSBstick) -4. [Upgrading](#Upgrading) -5. [Troubleshooting problems with the installer](#Troubleshootingproblemswiththeinstaller) -6. [Known Issues](#KnownIssues) -7. [Getting Help](#GettingHelp) - -Hardware Requirements ---------------------- - -Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. - -Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). - -Download installer ISO ----------------------- - -See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: - -{% highlight trac-wiki %} -gpg -v Qubes-R2-x86_64-DVD.iso.asc -{% endhighlight %} - -Burning the ISO onto a DVD or USB stick ---------------------------------------- - -Once you verify this is an authentic ISO, you should burn it on a DVD. - -If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: - -{% highlight trac-wiki %} -dd if=Qubes-R2-x86_64-DVD.iso of=/dev/sdX -{% endhighlight %} - -On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator): - -{% highlight trac-wiki %} -dd if=Qubes-R2-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress -{% endhighlight %} - -**Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)** - -Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. - -Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions! - -The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) - -![qubes-r2-installer-welcome.png](/attachment/wiki/InstallationGuideR2/qubes-r2-installer-welcome.png) - -Upgrading ---------- - -Upgrading from Qubes R2 rc1 should be a simple matter of installing updates for [dom0](/doc/SoftwareUpdateDom0/) and [VMs](/doc/SoftwareUpdateVM/). - -Users of R2 beta 3 should follow instructions on how to upgrade to Qubes R2 rc1 [here](/doc/UpgradeToR2rc1/). - -Troubleshooting problems with the installer -------------------------------------------- - -If the installer fails for some reason, typically because of the graphics card not being correctly supported, it is possible to try booting the installer with a different kernel -- to do that, choose Troubleshooting menu in the Installer Welcome screen, and later choose an option to proceed with one of the kernels provided: - -![qubes-r2-installer-troubleshooting.png](/attachment/wiki/InstallationGuideR2/qubes-r2-installer-troubleshooting.png) - -The installer ships with 4 different kernels (3.12, 3.11, 3.9 and 3.7) and all those kernel will be installed (regardless of which is selected to run the installer) so it is later always possible to boot the Qubes OS using any of those kernels. - -Known Issues ------------- - -- On some graphics cards the Xfce4 Window Manager (one of the two supported Dom0 Windows Managers in Qubes R2, the other being KDE) might behave "strangely", e.g. decorations might not be drawn sometimes. Also the accompanying lightdm login manager might incorrectly display the wallpaper. If you're facing those problems, it's advisable to use the KDE Window Manager and kdm instead of Xfce4 and lightdm (this is default if one chooses the KDE only installation option in the installer). - -- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. - -- If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. - -- Under some circumstances, Qubes backup can create broken backup, without any visible message (\#902). It is advisable to verify a backup to spot the problem. If you encounter this problem, backup VM directory manually. - -- System shutdown sometimes is very slow (\#903). To mitigate the problem, shutdown all the VMs first. - -- For other known issues take a look at [our trac tickets](https://wiki.qubes-os.org/query?status=accepted&status=assigned&status=new&status=reopened&type=defect&milestone=Release+2.1+(post+R2)&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority) - -It is advised to install updates just after system installation to apply bug fixes for (some of) the above problems. - -Getting Help ------------- - -- **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!) - -- Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) - -- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below): - - [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users) - - `qubes-users@googlegroups.com` - -- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. - diff --git a/InstallationGuideR2B1.md b/InstallationGuideR2B1.md deleted file mode 100644 index 96c55f7c..00000000 --- a/InstallationGuideR2B1.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -layout: doc -title: InstallationGuideR2B1 -permalink: /doc/InstallationGuideR2B1/ -redirect_from: /wiki/InstallationGuideR2B1/ ---- - -Installation Guide (for Qubes Release 2 Beta 1) -=============================================== - -1. [Hardware Requirements](#HardwareRequirements) -2. [Download installer ISO](#DownloadinstallerISO) -3. [Burning the ISO onto a DVD or USB stick](#BurningtheISOontoaDVDorUSBstick) -4. [Upgrading from Qubes R1](#UpgradingfromQubesR1) -5. [Installing Updates](#InstallingUpdates) -6. [Known Issues](#KnownIssues) -7. [Getting Help](#GettingHelp) - -Hardware Requirements ---------------------- - -Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. - -Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). - -Download installer ISO ----------------------- - -See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: - -{% highlight trac-wiki %} -gpg -v .asc -{% endhighlight %} - -Burning the ISO onto a DVD or USB stick ---------------------------------------- - -Once you verify this is an authentic ISO, you should burn it on a DVD. - -If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: - -{% highlight trac-wiki %} -dd if=Qubes-R2-Beta-1-x86_64-DVD.iso of=/dev/sdX -{% endhighlight %} - -**Be sure to use a correct device as the target in the dd command above (instead of sdX)'''** - -Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. - -Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions! - -The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) - -Upgrading from Qubes R1 ------------------------ - -If you're already running Qubes Release 1, you don't need to reinstall, it's just enough to update the packages in your Dom0 and the template VM(s). This procedure is described [here?](/doc/UpgradeToR2/). - -Installing Updates ------------------- - -Installing updates is very easy and can be done using the "Update" button in the Qubes Manager. Alternatively it can also be done from command prompt -- see the following for more details: - -- For installing updates for Dom0 -- see instructions [here](/doc/SoftwareUpdateDom0/). -- For installing updates for you domains (VMs) -- see instructions [here](/doc/SoftwareUpdateVM/). - -Known Issues ------------- - -- Installer might not support some USB keyboards (\#230). This seems to include all the Mac Book keyboards (most PC laptops have PS2 keyboards and are not affected). - -- If you don't enable Composition (System Setting -\> Desktop -\> Enable desktop effects), which you really should do, then the KDE task bar might get somehow ugly (e.g. half of it might be black). This is some KDE bug that we don't plan to fix. - -- Some keyboard layout set by KDE System Settings can cause [keyboard not working at all](https://groups.google.com/group/qubes-devel/browse_thread/thread/77d076b65dda7226). If you hit this issue, you can switch to console (by console login option) and manually edit `/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf` (and `/etc/sysconfig/keyboard`) and place correct keyboard layout settings (details in linked thread). You can check if specific keyboard layout settings are proper using `setxkbmap` tool. - -- On systems with more than 8GB of RAM there is problem with Disposable VM. To fix it, limit maximum memory allocation for DispVM to 3GB - - {% highlight trac-wiki %} - qvm-prefs -s fedora-17-x64-dvm maxmem 3072 - qvm-create-default-dvm --default-template --default-script - {% endhighlight %} - -- Qubes installer/system won't boot from a USB3-attached disks due to missing modules in initramfs (\#691). Please use USB2 port/device instead for now. - -- Systems with AMD graphics needs additional firmware (missing in default installation), details [here](http://groups.google.com/group/qubes-devel/browse_thread/thread/e27a57b0eda62f76). - -Getting Help ------------- - -- **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!) - -- Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) - -- If you don't find answer in the sources given above, write to the *qubes-devel* mailing list (you don't need to be subscribed to the list, just send email to the address given below): - - [http://groups.google.com/group/qubes-devel](http://groups.google.com/group/qubes-devel) - - `qubes-devel@googlegroups.com` - -- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. - diff --git a/InstallationGuideR2B2.md b/InstallationGuideR2B2.md deleted file mode 100644 index db490820..00000000 --- a/InstallationGuideR2B2.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -layout: doc -title: InstallationGuideR2B2 -permalink: /doc/InstallationGuideR2B2/ -redirect_from: /wiki/InstallationGuideR2B2/ ---- - -Installation Guide for Qubes Release 2 Beta 2 -============================================= - -1. [Hardware Requirements](#HardwareRequirements) -2. [Download installer ISO](#DownloadinstallerISO) -3. [Burning the ISO onto a DVD or USB stick](#BurningtheISOontoaDVDorUSBstick) -4. [Upgrading from Qubes R1 or R2 Beta 1](#UpgradingfromQubesR1orR2Beta1) -5. [Installing Updates](#InstallingUpdates) -6. [Known Issues](#KnownIssues) -7. [Getting Help](#GettingHelp) - -Hardware Requirements ---------------------- - -Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. - -Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). - -Download installer ISO ----------------------- - -See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: - -{% highlight trac-wiki %} -gpg -v .asc -{% endhighlight %} - -Burning the ISO onto a DVD or USB stick ---------------------------------------- - -Once you verify this is an authentic ISO, you should burn it on a DVD. - -If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: - -{% highlight trac-wiki %} -dd if=Qubes-R2-Beta2-x86_64-DVD.iso of=/dev/sdX -{% endhighlight %} - -**Be sure to use a correct device as the target in the dd command above (instead of sdX)** - -Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. - -Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions! - -The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) - -Upgrading from Qubes R1 or R2 Beta 1 ------------------------------------- - -Because of the distribution change in R2B2 (from fc13 to fc18) it's preferred that users reinstall Qubes R2B2 from scratch, and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. - -Advanced users (and advanced users only) can also try a manual upgrade procedure that has been described [here](/doc/UpgradeToR2B2/). It's advisable to backup your VMs before proceeding anyway! - -Installing Updates ------------------- - -Installing updates is very easy and can be done using the "Update" button in the Qubes Manager. Alternatively it can also be done from command prompt -- see the following for more details: - -- For installing updates for Dom0 -- see instructions [here](/doc/SoftwareUpdateDom0/). -- For installing updates for you domains (VMs) -- see instructions [here](/doc/SoftwareUpdateVM/). - -Known Issues ------------- - -- On some graphics cards the Xfce4 Window Manager (one of the two supported Dom0 Windows Managers in Qubes R2 B2, the other being KDE) might behave "strangely", e.g. decorations might not be drawn sometimes. Also the accompanying lightdm login manager might incorrectly display the wallpaper. If you're facing those problems, it's advisable to use the KDE Window Manager and kdm instead of Xfce4 and lightdm (this is default if one chooses the KDE only installation option in the installer). - -- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. - -- When restoring service VMs from a backup (such as custom netvms, firewallvms, etc) their icons might not be preserved in the "Start Menu". - -Getting Help ------------- - -- **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!) - -- Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) - -- If you don't find answer in the sources given above, write to the *qubes-devel* mailing list (you don't need to be subscribed to the list, just send email to the address given below): - - [http://groups.google.com/group/qubes-devel](http://groups.google.com/group/qubes-devel) - - `qubes-devel@googlegroups.com` - -- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. - diff --git a/InstallationGuideR2B3.md b/InstallationGuideR2B3.md deleted file mode 100644 index b9cf3c8d..00000000 --- a/InstallationGuideR2B3.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -layout: doc -title: InstallationGuideR2B3 -permalink: /doc/InstallationGuideR2B3/ -redirect_from: /wiki/InstallationGuideR2B3/ ---- - -Installation Guide for Qubes Release 2 Beta 3 -============================================= - -1. [Hardware Requirements](#HardwareRequirements) -2. [Download installer ISO](#DownloadinstallerISO) -3. [Burning the ISO onto a DVD or USB stick](#BurningtheISOontoaDVDorUSBstick) -4. [Upgrading from Qubes R1 or R2 Beta 2](#UpgradingfromQubesR1orR2Beta2) -5. [Installing Updates](#InstallingUpdates) -6. [Troubleshooting problems with the installer](#Troubleshootingproblemswiththeinstaller) -7. [Known Issues](#KnownIssues) -8. [Getting Help](#GettingHelp) - -Hardware Requirements ---------------------- - -Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. - -Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). - -Download installer ISO ----------------------- - -See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: - -{% highlight trac-wiki %} -gpg -v .asc -{% endhighlight %} - -Burning the ISO onto a DVD or USB stick ---------------------------------------- - -Once you verify this is an authentic ISO, you should burn it on a DVD. - -If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: - -{% highlight trac-wiki %} -dd if=Qubes-R2-Beta3-x86_64-DVD.iso of=/dev/sdX -{% endhighlight %} - -On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator): - -{% highlight trac-wiki %} -dd if=Qubes-R2-Beta3-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress -{% endhighlight %} - -**Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)** - -Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. - -Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions! - -The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) - -![r2b3-installer-welcome.png](/attachment/wiki/InstallationGuideR2B3/r2b3-installer-welcome.png) - -Upgrading from Qubes R1 or R2 Beta 2 ------------------------------------- - -The easiest and safest way to upgrade to Qubes R2B3 is to install it from scratch and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. - -Users can also try a manual upgrade procedure that has been described [here](/doc/UpgradeToR2B3/). - -Note: if the user has custom Template VMs (i.e. other than the default template, e.g. created from it by cloning), or Standalone VMs, then the user should perform manual upgrade from R2B2 to R2B3, as described under the link given above. - -Installing Updates ------------------- - -NOTE: Updates has been released after R2B3 ISO has been built -- it is recommended to install Dom0 updates shortly after installation to resolve some of the issues mentioned in the section below (Known Issues). - -Installing updates is very easy and can be done using the "Update" button in the Qubes Manager. Alternatively it can also be done from command prompt -- see the following for more details: - -- For installing updates for Dom0 -- see instructions [here](/doc/SoftwareUpdateDom0/). -- For installing updates for you domains (VMs) -- see instructions [here](/doc/SoftwareUpdateVM/). - -Troubleshooting problems with the installer -------------------------------------------- - -If the installer fails for some reason, typically because of the graphics card not being correctly supported, it is possible to try booting the installer with a different kernel -- to do that, choose Troubleshooting menu in the Installer Welcome screen, and later choose an option to proceed with one of the kernels provided: - -![r2b3-installer-troubleshooting.png](/attachment/wiki/InstallationGuideR2B3/r2b3-installer-troubleshooting.png) - -The installer ships with 3 different kernels (3.11, 3.9 and 3.7) and all those kernel will be installed (regardless of which is selected to run the installer) so it is later always possible to boot the Qubes OS using any of those kernels. - -Known Issues ------------- - -- On some graphics cards the Xfce4 Window Manager (one of the two supported Dom0 Windows Managers in Qubes R2 B2, the other being KDE) might behave "strangely", e.g. decorations might not be drawn sometimes. Also the accompanying lightdm login manager might incorrectly display the wallpaper. If you're facing those problems, it's advisable to use the KDE Window Manager and kdm instead of Xfce4 and lightdm (this is default if one chooses the KDE only installation option in the installer). - -- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. - -- When restoring service VMs from a backup (such as custom netvms, firewallvms, etc) their icons might not be preserved in the "Start Menu". - -- If you're GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. - -- For HVMs without Qubes Tools installed the GUI window will not be shown unless 'debug' flag is enabled for the VM. This has been fixed in `qubes-core-dom0` package \>= 2.1.35 -- please ensure you install updates after installation to resolve this issue. - -- Clocks might not get syncs in the VMs for up to several minutes after resume from sleep. This has been fixed in `qubes-core-dom0-linux` package \>= 2.0.4 -- please ensure you install updates after installation to resolve this issue. - -- Gnome terminal window sometimes shrinks to minimal size (especially when opening new tab). The workaround is to disable its menubar and scrollbar. - -Getting Help ------------- - -- **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!) - -- Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) - -- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below): - - [http://groups.google.com/group/qubes-users](http://groups.google.com/group/qubes-users) - - `qubes-users@googlegroups.com` - -- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. - diff --git a/InstallationGuideR2rc1.md b/InstallationGuideR2rc1.md deleted file mode 100644 index 7c715c3c..00000000 --- a/InstallationGuideR2rc1.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -layout: doc -title: InstallationGuideR2rc1 -permalink: /doc/InstallationGuideR2rc1/ -redirect_from: /wiki/InstallationGuideR2rc1/ ---- - -Installation Guide for Qubes Release 2 rc1 -========================================== - -1. [Hardware Requirements](#hardware-requirements) -2. [Download installer ISO](#download-installer-iso) -3. [Burning the ISO onto a DVD or USB stick](#burning-the-iso-onto-a-dvd-or-usb-stick) -4. [Upgrading](#upgrading) -5. [Troubleshooting problems with the installer](#troubleshooting-problems-with-the-installer) -6. [Known Issues](#known-issues) -7. [Getting Help](#getting-help) - -Hardware Requirements ---------------------- - -Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. - -Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). - -Download installer ISO ----------------------- - -See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: - -{% highlight trac-wiki %} -gpg -v .asc -{% endhighlight %} - -Burning the ISO onto a DVD or USB stick ---------------------------------------- - -Once you verify this is an authentic ISO, you should burn it on a DVD. - -If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: - -{% highlight trac-wiki %} -dd if=Qubes-R2-rc1-x86_64-DVD.iso of=/dev/sdX -{% endhighlight %} - -On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator): - -{% highlight trac-wiki %} -dd if=Qubes-R2-rc1-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress -{% endhighlight %} - -**Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)** - -Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. - -Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions! - -The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) - -![qubes-r2-rc1-installer-welcome.png](/attachment/wiki/InstallationGuideR2rc1/qubes-r2-rc1-installer-welcome.png) - -Upgrading ---------- - -The easiest and safest way to upgrade to Qubes R2rc1 (especially from older releases) is to install it from scratch and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. - -Users of R2 beta 3 can upgrade using procedure that has been described [here](/doc/UpgradeToR2rc1/). - -Note: if the user has custom Template VMs (i.e. other than the default template, e.g. created from it by cloning), or Standalone VMs, then the user should perform manual upgrade from R2B3 to R2rc1, as described under the link given above. - -Troubleshooting problems with the installer -------------------------------------------- - -If the installer fails for some reason, typically because of the graphics card not being correctly supported, it is possible to try booting the installer with a different kernel -- to do that, choose Troubleshooting menu in the Installer Welcome screen, and later choose an option to proceed with one of the kernels provided: - -![qubes-r2-rc1-installer-troubleshooting.png](/attachment/wiki/InstallationGuideR2rc1/qubes-r2-rc1-installer-troubleshooting.png) - -The installer ships with 4 different kernels (3.12, 3.11, 3.9 and 3.7) and all those kernel will be installed (regardless of which is selected to run the installer) so it is later always possible to boot the Qubes OS using any of those kernels. - -Known Issues ------------- - -- On some graphics cards the Xfce4 Window Manager (one of the two supported Dom0 Windows Managers in Qubes R2, the other being KDE) might behave "strangely", e.g. decorations might not be drawn sometimes. Also the accompanying lightdm login manager might incorrectly display the wallpaper. If you're facing those problems, it's advisable to use the KDE Window Manager and kdm instead of Xfce4 and lightdm (this is default if one chooses the KDE only installation option in the installer). - -- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. - -- If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. - -- HVMs with Qubes Tools installed will not have access to the network if firewallvm uses 3.12 kernel (the default). The workaround is to use older (3.11) kernel for firewallvm. You need to [install kernel-qubes-vm-3.11.10 package](/doc/SoftwareUpdateDom0/#how-to-downgrade-a-specific-package), then ensure that it is used for firewallvm (for example using Qubes Manager - advanced tab of VM settings). - -- Just after installation, applications menu will not contain colorful application icons (new feature), only padlock in VM color. To get colorful icons, you need to start template VM (fedora-20-x64) and call `qvm-sync-appmenus fedora-20-x64` in dom0 terminal. If you have other Template VMs or Standalone VMs, repeat the steps for them too. - -Getting Help ------------- - -- **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!) - -- Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) - -- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below): - - [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users) - - `qubes-users@googlegroups.com` - -- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. - diff --git a/InstallationGuideR2rc2.md b/InstallationGuideR2rc2.md deleted file mode 100644 index 4c2f11a2..00000000 --- a/InstallationGuideR2rc2.md +++ /dev/null @@ -1,99 +0,0 @@ ---- -layout: doc -title: InstallationGuideR2rc2 -permalink: /doc/InstallationGuideR2rc2/ -redirect_from: /wiki/InstallationGuideR2rc2/ ---- - -Installation Guide for Qubes Release 2 rc2 -========================================== - -1. [Hardware Requirements](#HardwareRequirements) -2. [Download installer ISO](#DownloadinstallerISO) -3. [Burning the ISO onto a DVD or USB stick](#BurningtheISOontoaDVDorUSBstick) -4. [Upgrading](#Upgrading) -5. [Troubleshooting problems with the installer](#Troubleshootingproblemswiththeinstaller) -6. [Known Issues](#KnownIssues) -7. [Getting Help](#GettingHelp) - -Hardware Requirements ---------------------- - -Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. - -Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). - -Download installer ISO ----------------------- - -See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: - -{% highlight trac-wiki %} -gpg -v Qubes-R2-rc2-x86_64-DVD.iso.asc -{% endhighlight %} - -Burning the ISO onto a DVD or USB stick ---------------------------------------- - -Once you verify this is an authentic ISO, you should burn it on a DVD. - -If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: - -{% highlight trac-wiki %} -dd if=Qubes-R2-rc2-x86_64-DVD.iso of=/dev/sdX -{% endhighlight %} - -On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator): - -{% highlight trac-wiki %} -dd if=Qubes-R2-rc2-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress -{% endhighlight %} - -**Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)** - -Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. - -Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions! - -The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) - -![qubes-r2-rc2-installer-welcome.png](/attachment/wiki/InstallationGuideR2rc2/qubes-r2-rc2-installer-welcome.png) - -Upgrading ---------- - -Upgrading from Qubes R2 rc1 should be a simple matter of installing updates for [dom0](/doc/SoftwareUpdateDom0/) and [VMs](/doc/SoftwareUpdateVM/). - -Users of R2 beta 3 should follow instructions on how to upgrade to Qubes R2 rc1 [here](/doc/UpgradeToR2rc1/). - -Troubleshooting problems with the installer -------------------------------------------- - -If the installer fails for some reason, typically because of the graphics card not being correctly supported, it is possible to try booting the installer with a different kernel -- to do that, choose Troubleshooting menu in the Installer Welcome screen, and later choose an option to proceed with one of the kernels provided: - -![qubes-r2-rc2-installer-troubleshooting.png](/attachment/wiki/InstallationGuideR2rc2/qubes-r2-rc2-installer-troubleshooting.png) - -The installer ships with 4 different kernels (3.12, 3.11, 3.9 and 3.7) and all those kernel will be installed (regardless of which is selected to run the installer) so it is later always possible to boot the Qubes OS using any of those kernels. - -Known Issues ------------- - -- On some graphics cards the Xfce4 Window Manager (one of the two supported Dom0 Windows Managers in Qubes R2, the other being KDE) might behave "strangely", e.g. decorations might not be drawn sometimes. Also the accompanying lightdm login manager might incorrectly display the wallpaper. If you're facing those problems, it's advisable to use the KDE Window Manager and kdm instead of Xfce4 and lightdm (this is default if one chooses the KDE only installation option in the installer). - -- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. - -- If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. - -Getting Help ------------- - -- **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!) - -- Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) - -- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below): - - [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users) - - `qubes-users@googlegroups.com` - -- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. - diff --git a/InstallationGuideR3.0rc1.md b/InstallationGuideR3.0rc1.md deleted file mode 100644 index 52d46b99..00000000 --- a/InstallationGuideR3.0rc1.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -layout: doc -title: Installation Guide for Qubes 3.0 rc1 -permalink: /doc/InstallationGuideR3.0rc1/ ---- - -Installation Guide for Qubes Release 3.0 rc1 -============================================ - -1. [Hardware Requirements](#hardware-requirements) -2. [Download installer ISO](#download-installer-iso) -3. [Burning the ISO onto a DVD or USB stick](#burning-the-iso-onto-a-dvd-or-usb-stick) -4. [Upgrading](#upgrading) -5. [Troubleshooting problems with the installer](#troubleshooting-problems-with-the-installer) -6. [Known Issues](#known-issues) -7. [Getting Help](#getting-help) - -Hardware Requirements ---------------------- - -Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. - -Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). - -Download installer ISO ----------------------- - -See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: - - gpg -v Qubes-R3.0-rc1-x86_64-DVD.iso.asc - -Burning the ISO onto a DVD or USB stick ---------------------------------------- - -Once you verify this is an authentic ISO, you should burn it on a DVD. - -If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: - - dd if=Qubes-R3.0-rc1-x86_64-DVD.iso of=/dev/sdX - -On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator): - - dd if=Qubes-R3.0-rc1-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress - -**Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)** - -Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. - -Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions! - -The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) - -Upgrading ---------- - -The easiest and safest way to upgrade to Qubes R3.0rc1 is to install it from scratch and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. - -Users or Qubes R2 can upgrade using experimental procedure that has been described [here](/doc/UpgradeToR3.0rc1/). - -Troubleshooting problems with the installer -------------------------------------------- - -If the installer fails for some reason, typically because of the graphics card not being correctly supported, it is possible to try booting the installer with a different kernel -- to do that, choose Troubleshooting menu in the Installer Welcome screen, and later choose an option to proceed with one of the kernels provided. - -The installer ships with 4 different kernels (3.12, 3.11, 3.9 and 3.7) and all those kernel will be installed (regardless of which is selected to run the installer) so it is later always possible to boot the Qubes OS using any of those kernels. - -Known Issues ------------- - -- There is no Qubes Windows Tools for Qubes R3.0 yet. We are working on this - -- UEFI is not supported, you need to enable "legacy boot" in BIOS before installing Qubes OS - -- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. - -- If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. - -- For other known issues take a look at [our tickets](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3%22+label%3Abug) - -It is advised to install updates just after system installation to apply bug fixes for (some of) the above problems. - -Getting Help ------------- - -- **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!) - -- Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) - -- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below): - - [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users) - - `qubes-users@googlegroups.com` - -- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. diff --git a/InstallationGuideR3.0rc2.md b/InstallationGuideR3.0rc2.md deleted file mode 100644 index a966debb..00000000 --- a/InstallationGuideR3.0rc2.md +++ /dev/null @@ -1,98 +0,0 @@ ---- -layout: doc -title: Installation Guide for Qubes 3.0 rc2 -permalink: /doc/InstallationGuideR3.0rc2/ ---- - -Installation Guide for Qubes Release 3.0 rc2 -============================================ - -1. [Hardware Requirements](#hardware-requirements) -2. [Download installer ISO](#download-installer-iso) -3. [Burning the ISO onto a DVD or USB stick](#burning-the-iso-onto-a-dvd-or-usb-stick) -4. [Upgrading](#upgrading) -5. [Troubleshooting problems with the installer](#troubleshooting-problems-with-the-installer) -6. [Known Issues](#known-issues) -7. [Getting Help](#getting-help) - -Hardware Requirements ---------------------- - -Please see the [Hardware Compatibility List](/hcl/) page for more information on required and recommended hardware. - -Note: We don't recommend installing Qubes in a virtual machine! It will likely not work. Don't send emails asking about it. However, you can install it on an external USB hard drive and run from it, at least for testing (normally such disks are *orders* of magnitude slower than even the slowest internal hard drives). - -Download installer ISO ----------------------- - -See [this page](/doc/QubesDownloads/) for ISO downloads. Remember, we have absolutely no control over those servers, and so you should be assuming that they might be compromised, or just be serving a compromised ISOs because their operators decided so, for whatever reason. Always verify the digital signature on the downloaded ISO. See this [page](/doc/VerifyingSignatures/) for more info about how to download and verify our GPG keys, and then verify the downloaded ISO: - - gpg -v Qubes-R3.0-rc2-x86_64-DVD.iso.asc - -Burning the ISO onto a DVD or USB stick ---------------------------------------- - -Once you verify this is an authentic ISO, you should burn it on a DVD. - -If you prefer to use USB as a source for installation, then you just need to copy the ISO onto the USB device, e.g. using dd: - - dd if=Qubes-R3.0-rc2-x86_64-DVD.iso of=/dev/sdX - -On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator): - - dd if=Qubes-R3.0-rc2-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress - -**Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)** - -Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. - -Then, when finally ready, boot your system from the installer DVD and follow the instructions on screen. The installer is very simple and asks very few questions -- it's actually easier to install Qubes right now than most other Linux distributions! - -The installer loads Xen right at the beginning, so chances are high that if you can see the installer's graphical screen, Qubes will work on your system :) - -Upgrading from R3.0rc1 ------------------------ - -If you are using Qubes R3.0rc1, just install system updates, there is no special steps required. - -Upgrading ---------- - -If you are using Qubes R2, follow instructions below. - -The easiest and safest way to upgrade to Qubes R3.0rc2 is to install it from scratch and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. - -Users of Qubes R2 can upgrade using [experimental procedure](/doc/UpgradeToR3.0rc1/) (the same as for R3.0rc1). - -Troubleshooting problems with the installer -------------------------------------------- - -If the installer fails for some reason, typically because of the graphics card not being correctly supported, it is possible to try booting the installer with a different kernel -- to do that, choose Troubleshooting menu in the Installer Welcome screen, and later choose an option to proceed with one of the kernels provided. - -The installer ships with 4 different kernels (3.12, 3.11, 3.9 and 3.7) and all those kernel will be installed (regardless of which is selected to run the installer) so it is later always possible to boot the Qubes OS using any of those kernels. - -Known Issues ------------- - -- UEFI is not supported, you need to enable "legacy boot" in BIOS before installing Qubes OS - -- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. - -- If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. - -- For other known issues take a look at [our tickets](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3.0%22+label%3Abug) - -It is advised to install updates just after system installation to apply bug fixes for (some of) the above problems. - -Getting Help ------------- - -- **User manuals are [here](/doc/UserDoc/).** (Strongly recommended!) - -- Developers documentation (normally not needed by users) is [here](/doc/SystemDoc/) - -- If you don't find answer in the sources given above, write to the *qubes-users* mailing list (you don't need to be subscribed to the list, just send email to the address given below): - - [https://groups.google.com/group/qubes-users](https://groups.google.com/group/qubes-users) - - `qubes-users@googlegroups.com` - -- Please do not write email to individual developers (Marek, Joanna, etc) asking questions about installation or other problems. Please send all such questions to the mailing list. diff --git a/QubesDownloads.md b/QubesDownloads.md index f2fb807a..a6ed441d 100644 --- a/QubesDownloads.md +++ b/QubesDownloads.md @@ -18,33 +18,33 @@ Qubes Downloads Qubes Release 3.0 --------------- +- [Release notes](/doc/releases/3.0/release-notes/) - [Qubes-R3.0-rc2-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc2-x86_64-DVD.iso) (mirror 1) - [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc2-x86_64-DVD.iso.asc) (mirror 1) - [Qubes-R3.0-rc2-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc2-x86_64-DVD.iso) (mirror 2) - [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc2-x86_64-DVD.iso.asc) (mirror 2) -- **[Installation Guide for Qubes R3.0 rc2](/doc/InstallationGuideR3.0rc2/)** -- [Upgrading to Qubes R3.0 rc2](/doc/InstallationGuideR3.0rc2/#upgrading) +- **[Installation Guide](/doc/InstallationGuide/)** +- [Upgrading to Qubes R3.0 rc2](/doc/releases/3.0/release-notes/#upgrading) Qubes Release 2 --------------- +- [Release notes](/doc/releases/2.0/release-notes/) - [Qubes-R2-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R2-x86_64-DVD.iso) (mirror 1) - [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R2-x86_64-DVD.iso.asc) (mirror 1) - [Qubes-R2-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R2-x86_64-DVD.iso) (mirror 2) - [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R2-x86_64-DVD.iso.asc) (mirror 2) -- **[Installation Guide for Qubes R2](/doc/InstallationGuideR2/)** -- [Upgrading to Qubes R2](/doc/InstallationGuideR2/#upgrading) - -- **[Installation Guide for Qubes R2 rc2](/doc/InstallationGuideR2rc2/)** (deprecated) -- [Upgrading to Qubes R2 rc2](/doc/InstallationGuideR2rc2/#upgrading) +- **[Installation Guide](/doc/InstallationGuide/)** +- [Upgrading to Qubes R2](/doc/releases/2.0/release-notes/#upgrading) Qubes Release 1 --------------- (This is mainly for historical reference, we strongly recommend Qubes R2 above) +- [Release notes](/doc/releases/1.0/release-notes/) - [Qubes-R1-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R1-x86_64-DVD.iso) (mirror 1) - [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R1-x86_64-DVD.iso.asc) (mirror 1) - [Qubes-R1-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R1-x86_64-DVD.iso) (mirror 2) diff --git a/UpgradeToR2rc1.md b/UpgradeToR2.md similarity index 82% rename from UpgradeToR2rc1.md rename to UpgradeToR2.md index 150df713..ef70569d 100644 --- a/UpgradeToR2rc1.md +++ b/UpgradeToR2.md @@ -1,32 +1,33 @@ --- layout: doc -title: UpgradeToR2rc1 -permalink: /doc/UpgradeToR2rc1/ +title: UpgradeToR2 +permalink: /doc/UpgradeToR2/ +redirect_from: /doc/UpgradeToR2rc1/ redirect_from: /wiki/UpgradeToR2rc1/ --- -Upgrading Qubes R2 Beta 3 to R2 rc1 +Upgrading Qubes R2 Beta 3 to R2 =================================== -Current Qubes R2 Beta 3 (R2B3) systems can be upgraded in-place to the latest R2 rc1 (R2rc1) release by following the procedure below. +Current Qubes R2 Beta 3 (R2B3) systems can be upgraded in-place to the latest R2 (R2) release by following the procedure below. **Before attempting either an in-place upgrade or a clean installation, we strongly recommend that users back up the system by using the built-in [backup tool](/doc/BackupRestore/).** Upgrade Template and Standalone VM(s) ------------------------------------- -- Qubes R2 rc1 comes with new template based on Fedora 20. You can upgrade existing template according to procedure described [here](/doc/FedoraTemplateUpgrade/). +- Qubes R2 comes with new template based on Fedora 20. You can upgrade existing template according to procedure described [here](/doc/FedoraTemplateUpgrade/). - **It also possible to download a new Fedora 20-based template from our repositories**. To do this please first upgrade the Dom0 distro as described in the section below. -While technically it is possible to use old Fedora 18 template on R2 rc1, it is strongly recommended to upgrade all the Template VMs and Standalone VMs, because Fedora 18 no longer receive security updates. +While technically it is possible to use old Fedora 18 template on R2, it is strongly recommended to upgrade all the Template VMs and Standalone VMs, because Fedora 18 no longer receive security updates. By default, in Qubes R2, there is only one Template VM, however users are free to create more Template VMs for special purposes, as well as Standalone VMs. If more than one template and/or Standalone VMs are used, then it is recommended to upgrade/replace all of them. More information on using multiple Template VMs, as well as Standalone VMs, can be found [here](/doc/SoftwareUpdateVM/). Upgrading dom0 -------------- -Note that dom0 in R2rc1 is based on Fedora 20, in contrast to Fedora 18 in previous release, so this operation will upgrade a lot of packages. +Note that dom0 in R2 is based on Fedora 20, in contrast to Fedora 18 in previous release, so this operation will upgrade a lot of packages. 1. Open terminal in Dom0. E.g. Start-\>System Settings-\>Konsole. @@ -38,7 +39,7 @@ Note that dom0 in R2rc1 is based on Fedora 20, in contrast to Fedora 18 in previ After this step you should have `qubes-release-2-5` in your Dom0. Important: if you happen to have `qubes-release-2-6*` then you should downgrade to `qubes-release-2-5`! The `qubes-release-2-6*` packages have been uploaded to the testing repos and were kept there for a few hours, until we realized they bring incorrect repo definitions and so we removed them and also have changed the update procedure a bit (simplifying it). -1. Upgrade dom0 to R2 rc1: +1. Upgrade dom0 to R2: Note: be sure that the VM used as a update-downloading-vm (by default its the firewallvm based on the default template) has been updated to the latest qubes packages, specifically `qubes-core-vm-2.1.33` or later. This doesn't imply that the VM must already be upgraded to fc20 -- for Dom0 upgrade we could still use an fc18-based VM (updatevm) it is only important to install the latest Qubes packages there. diff --git a/UpgradeToR3.0rc1.md b/UpgradeToR3.0.md similarity index 93% rename from UpgradeToR3.0rc1.md rename to UpgradeToR3.0.md index c37f1dbe..4dbcc5be 100644 --- a/UpgradeToR3.0rc1.md +++ b/UpgradeToR3.0.md @@ -1,15 +1,16 @@ --- layout: doc -title: Upgrade to R3.0 rc1 -permalink: /doc/UpgradeToR3.0rc1/ +title: Upgrade to R3.0 +permalink: /doc/UpgradeToR3.0/ +redirect_from: /doc/UpgradeToR3.0rc1/ --- -Upgrading Qubes R2 to R3.0-rc1 +Upgrading Qubes R2 to R3.0 ====================================== **This instruction is highly experimental, the official way to upgrade from R2 is to backup the data and reinstall the system. Use at your own risk!** -Current Qubes R3.0-rc1 (R3.0rc1) systems can be upgraded in-place to the latest R3.0 release candidate by following the procedure below. However, upgrading in-place is riskier than performing a clean installation, since there are more things which can go wrong. For this reason, **we strongly recommended that users perform a [clean installation](/doc/InstallationGuideR3.0rc1/) of Qubes R3.0 rc1**. +Current Qubes R3.0 (R3.0) systems can be upgraded in-place to the latest R3.0 by following the procedure below. However, upgrading in-place is riskier than performing a clean installation, since there are more things which can go wrong. For this reason, **we strongly recommended that users perform a [clean installation](/doc/InstallationGuide/) of Qubes R3.0**. **Before attempting either an in-place upgrade or a clean installation, we strongly recommend that users back up the system by using the built-in [backup tool](/doc/BackupRestore/).** diff --git a/releases.md b/releases.md new file mode 100644 index 00000000..7504a164 --- /dev/null +++ b/releases.md @@ -0,0 +1,24 @@ +--- +layout: doc +title: Qubes releases +permalink: /doc/releases/ +--- + +Qubes releases +============== + +Qubes R1 +-------- + +* [Release Notes](/doc/releases/1.0/release-notes/) + +Qubes R2 +-------- + +* [Release Notes](/doc/releases/2.0/release-notes/) + +Qubes R3.0 +-------- + +* [Release Notes](/doc/releases/3.0/release-notes/) +* [Release schedule](/doc/releases/3.0/schedule/) diff --git a/releases/1.0/release-notes.md b/releases/1.0/release-notes.md new file mode 100644 index 00000000..819fe047 --- /dev/null +++ b/releases/1.0/release-notes.md @@ -0,0 +1,54 @@ +--- +layout: doc +title: Qubes R1.0 release notes +permalink: /doc/releases/1.0/release-notes/ +--- + +Qubes R1.0 release notes +======================== + +Detailed release notes in [this blog post](http://blog.invisiblethings.org/2012/09/03/introducing-qubes-10.html). + +Known issues +------------ + +- Installer might not support some USB keyboards (\#230). This seems to include all the Mac Book keyboards (most PC laptops have PS2 keyboards and are not affected). + +- If you don't enable Composition (System Setting -\> Desktop -\> Enable desktop effects), which you really should do, then the KDE task bar might get somehow ugly (e.g. half of it might be black). This is some KDE bug that we don't plan to fix. + +- Some keyboard layout set by KDE System Settings can cause [keyboard not working at all](https://groups.google.com/group/qubes-devel/browse_thread/thread/77d076b65dda7226). If you hit this issue, you can switch to console (by console login option) and manually edit `/etc/X11/xorg.conf.d/00-system-setup-keyboard.conf` (and `/etc/sysconfig/keyboard`) and place correct keyboard layout settings (details in linked thread). You can check if specific keyboard layout settings are proper using `setxkbmap` tool. + +- On systems with more than 8GB of RAM there is problem with Disposable VM. To fix it, limit maximum memory allocation for DispVM to 3GB + + {% highlight trac-wiki %} + qvm-prefs -s fedora-17-x64-dvm maxmem 3072 + qvm-create-default-dvm --default-template --default-script + {% endhighlight %} + +- On some systems the KDE Window Manager might freeze upon resuming from S3 sleep when compositing is enabled (and the only method to log in to the system if this happens is to switch to a text console, enter your user's password, kill the kwin process, go back to the Xorg console, log in, and start a new instance of kwin using Konsole application :) If you experience such problems, make sure to disable compositing before putting the system into sleep by pressing Alt-Ctrl-F12 (and then enabling it back once you log in after resume) -- this way you should never see this problem again. + +Downloads +--------- + +See [Qubes Downloads](/doc/QubesDownloads/). + +Installation instructions +------------------------- + +See [Installation Guide](/doc/InstallationGuide/). + +Upgrading +--------- + +### From Qubes 1.0-rc1 + +If you're already running Qubes 1.0-rc1, you don't need to reinstall, it's just enough to update the packages in your Dom0 and the template VM(s). The easiest way for doing this is to click on the Update Button in the Qubes Manger -- one click when you selected Dom0, and one click for each of your template VM (by default there is just one template). + +### From Qubes 1.0 Beta 3 + +If you have Qubes Beta 3 currently installed on your system, you must reinstall from scratch, as we offer no direct upgrade option in the installer (sorry). However, we do offer tools for smooth migration of your AppVMs. In order to do that, please backup your AppVMs using the `qvm-backup` tool [as usual](/doc/BackupRestore/). Then, after you install Qubes 1.0 rc1, you can restore them using `qvm-backup-restore` tool. However, because we have changed the default template in RC1, you should tell qvm-back-restore about that by passing `--replace-template` option: + +{% highlight trac-wiki %} +qvm-backup-restore --replace-template=fedora-15-x64:fedora-17-x64 +{% endhighlight %} + diff --git a/releases/2.0/release-notes.md b/releases/2.0/release-notes.md new file mode 100644 index 00000000..89c463d2 --- /dev/null +++ b/releases/2.0/release-notes.md @@ -0,0 +1,89 @@ +--- +layout: doc +title: Qubes R2.0 release notes +permalink: /doc/releases/2.0/release-notes/ +--- + +Qubes R2.0 release notes +======================== + +Detailed release notes in [this blog post](http://blog.invisiblethings.org/2014/09/26/announcing-qubes-os-release-2.html) + +New features since 1.0 +---------------------- + +* Support for generic fully virtualized VMs (without qemu in the TCB!) +* Support for Windows-based AppVMs integration (clipboard, file exchange, qrexec, pv drivers) +* Secure audio input to select AppVMs (Hello Skype users!) +* Clipboard is now also controlled by central policies, unified with other qrexec policies. +* Out of the box TorVM support +* Experimental support for PVUSB +* Updated Xorg packages in Dom0 to support new GPUs +* DisposableVM customization support +* Introduced Xfce 4.10 environment for Dom0 as an alternative to KDE +* Advanced infrastructure for system backups +* Ability to autostart selected VM at system startup +* Support for dynamic screen resolution change +* Dom0 distribution upgraded to Fedora 20 + +Known issues +------------ + +- On some graphics cards the Xfce4 Window Manager (one of the two supported Dom0 Windows Managers in Qubes R2, the other being KDE) might behave "strangely", e.g. decorations might not be drawn sometimes. Also the accompanying lightdm login manager might incorrectly display the wallpaper. If you're facing those problems, it's advisable to use the KDE Window Manager and kdm instead of Xfce4 and lightdm (this is default if one chooses the KDE only installation option in the installer). + +- Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. + +- If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. + +- Under some circumstances, Qubes backup can create broken backup, without any visible message (\#902). It is advisable to verify a backup to spot the problem. If you encounter this problem, backup VM directory manually. + +- System shutdown sometimes is very slow (\#903). To mitigate the problem, shutdown all the VMs first. + +- For other known issues take a look at [our trac tickets](https://wiki.qubes-os.org/query?status=accepted&status=assigned&status=new&status=reopened&type=defect&milestone=Release+2.1+(post+R2)&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority) + +It is advised to install updates just after system installation to apply bug fixes for (some of) the above problems. + +Downloads +--------- + +See [Qubes Downloads](/doc/QubesDownloads/). + +Installation instructions +------------------------- + +See [Installation Guide](/doc/InstallationGuide/). + +Upgrading +--------- + +### From Qubes R2 rc1 + +Upgrading from Qubes R2 rc1 should be a simple matter of installing updates for [dom0](/doc/SoftwareUpdateDom0/) and [VMs](/doc/SoftwareUpdateVM/). + +### From Qubes R2 beta 3 and older + +The easiest and safest way to upgrade to Qubes R2 (especially from older releases) is to install it from scratch and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. + +Users of R2 beta 3 can upgrade using procedure that has been described [here](/doc/UpgradeToR2/). + +Note: if the user has custom Template VMs (i.e. other than the default template, e.g. created from it by cloning), or Standalone VMs, then the user should perform manual upgrade from R2B3 to R2rc1, as described under the link given above. + +### Migrating between beta releases + +#### From Qubes R1 to R2 beta1 + +If you're already running Qubes Release 1, you don't need to reinstall, it's just enough to update the packages in your Dom0 and the template VM(s). This procedure is described [here?](/doc/UpgradeToR2/). + +#### From Qubes R1 or R2 Beta 1 to R2 beta2 + +Because of the distribution change in R2B2 (from fc13 to fc18) it's preferred that users reinstall Qubes R2B2 from scratch, and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. + +Advanced users (and advanced users only) can also try a manual upgrade procedure that has been described [here](/doc/UpgradeToR2B2/). It's advisable to backup your VMs before proceeding anyway! + +#### Upgrading from Qubes R1 or R2 Beta 2 to R2 beta 3 + +The easiest and safest way to upgrade to Qubes R2B3 is to install it from scratch and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. + +Users can also try a manual upgrade procedure that has been described [here](/doc/UpgradeToR2B3/). + +Note: if the user has custom Template VMs (i.e. other than the default template, e.g. created from it by cloning), or Standalone VMs, then the user should perform manual upgrade from R2B2 to R2B3, as described under the link given above. diff --git a/releases/3.0/release-notes.md b/releases/3.0/release-notes.md index c68ba475..455d8cf8 100644 --- a/releases/3.0/release-notes.md +++ b/releases/3.0/release-notes.md @@ -23,8 +23,36 @@ Known issues * Windows Tools: `qvm-block` does not work +* UEFI is not supported, you need to enable "legacy boot" in BIOS before installing Qubes OS + +* Some icons in the Qubes Manager application might not be drawn correctly when using the Xfce4 environment in Dom0. If this bothers you, please use the KDE environment instead. + +* If your GPU is not correctly supported by the Dom0 kernel (e.g. the 3D desktop effects do not run smoothly) then you might experience "heaviness" with Windows 7-based AppVMs. In that case, please solve the problem with your GPU support in Dom0 in the first place (by using a different kernel), or install Qubes OS on a different system. + +* For other known issues take a look at [our tickets](https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+3%22+label%3Abug) + +It is advised to install updates just after system installation to apply bug fixes for (some of) the above problems. + Downloads --------- +See [Qubes Downloads](/doc/QubesDownloads/). + Installation instructions ------------------------- + +See [Installation Guide](/doc/InstallationGuide/). + +Upgrading +--------- + +### From from R3.0rc1 + +If you are using Qubes R3.0rc1, just install system updates, there is no special steps required. + +### From R2.0 or earlier + +The easiest and safest way to upgrade to Qubes R3.0 is to install it from scratch and use [qubes backup and restore tools](/doc/BackupRestore/) for migrating of all of the user VMs. + +Users of Qubes R2 can upgrade using [experimental procedure](/doc/UpgradeToR3.0/). + From 660994f273bcd49f4bb83523a327a1ad359de5fa Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Wed, 16 Sep 2015 00:13:47 +0200 Subject: [PATCH 085/174] Use Rufus to write ISO image to USB on Windows --- InstallationGuide.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/InstallationGuide.md b/InstallationGuide.md index 40911a2c..0a489e66 100644 --- a/InstallationGuide.md +++ b/InstallationGuide.md @@ -50,11 +50,9 @@ If you prefer to use USB as a source for installation, then you just need to cop Adjust filename to the version you're installing. **Be sure to use a correct device as the target in the dd command above (instead of sdX)'''** -On windows you can use [this](http://www.chrysocome.net/dd) tool. Example command would be (as Administrator): +On windows you can use [Rufus](http://rufus.akeo.ie/) tool. Be sure to select "DD image" mode (you need to do that **after** selecting Qubes iso image): - dd if=Qubes-R2-x86_64-DVD.iso of=\\?\Device\Harddisk1\Partition0 bs=1M --size --progress - -Adjust filename to the version you're installing. **Be sure to use a correct device as the target in the dd command above (instead of sdX or Harddisk1)** + Before proceeding with the installation, you are encouraged to first read all the information on this page, especially the *Known Issues* paragraph. From cf910210d8d4a6877c49350505b292e4d38dfaaf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Wed, 16 Sep 2015 12:14:10 +0200 Subject: [PATCH 086/174] 3.0 release schedule - fix table formatting --- releases/3.0/schedule.md | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/releases/3.0/schedule.md b/releases/3.0/schedule.md index 483f21eb..dc8fe71f 100644 --- a/releases/3.0/schedule.md +++ b/releases/3.0/schedule.md @@ -7,16 +7,8 @@ permalink: /doc/releases/3.0/schedule/ Qubes R3.0 release schedule =========================== - - - - - - - current-testing freeze - - - - - -
datestage
3.0-rc2
5.09.2015
3.0-rc3
15.09.2015ISO
3.0
1.10.2015ISO
+| Date | Stage | +| -----------:| ------------------------------------- | +| 5 Sep 2015 | current-testing freeze before 3.0-rc3 | +| 15 Sep 2015 | 3.0-rc3 release | +| 1 Oct 2015 | 3.0 release | From df386c46e6f4c12ac08aba95498ff84e70d0cef6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Wed, 16 Sep 2015 16:23:14 +0200 Subject: [PATCH 087/174] R3.0-rc3 --- QubesDownloads.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/QubesDownloads.md b/QubesDownloads.md index a6ed441d..dfbc148b 100644 --- a/QubesDownloads.md +++ b/QubesDownloads.md @@ -19,13 +19,13 @@ Qubes Release 3.0 --------------- - [Release notes](/doc/releases/3.0/release-notes/) -- [Qubes-R3.0-rc2-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc2-x86_64-DVD.iso) (mirror 1) -- [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc2-x86_64-DVD.iso.asc) (mirror 1) -- [Qubes-R3.0-rc2-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc2-x86_64-DVD.iso) (mirror 2) -- [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc2-x86_64-DVD.iso.asc) (mirror 2) + + +- [Qubes-R3.0-rc3-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc3-x86_64-DVD.iso) (mirror 2) +- [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc3-x86_64-DVD.iso.asc) (mirror 2) - **[Installation Guide](/doc/InstallationGuide/)** -- [Upgrading to Qubes R3.0 rc2](/doc/releases/3.0/release-notes/#upgrading) +- [Upgrading to Qubes R3.0 rc3](/doc/releases/3.0/release-notes/#upgrading) Qubes Release 2 --------------- From 5db856233b74f738cc74c5fc50698e7c25c0e2c1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Wed, 16 Sep 2015 23:55:13 +0200 Subject: [PATCH 088/174] release checklist - repositories related tasks --- releases/todo.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/releases/todo.md b/releases/todo.md index a2af9581..0301f886 100644 --- a/releases/todo.md +++ b/releases/todo.md @@ -12,8 +12,12 @@ Release checklist On -rc1 ------- * write schedule +* create package repositories (linux-yum, linux-deb) +* update repository definition (core-agent-linux, installer-qubes-os/qubes-release) * push all packages to `current-testing` * draft release notes, one note per feature +* create upgrade package in previous release branch (r2->r3.0, r3.0->r3.1, etc) - core-agent-linux +* make sure that keys for the current release are included in previous release's qubes-release package (for upgrade) * build ISO and push to mirrors On subsequent -rc From a05120cf7534f3d15da268be0a35a3b555487848 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= Date: Thu, 17 Sep 2015 01:01:38 +0200 Subject: [PATCH 089/174] Enable links to kernel.org mirror --- QubesDownloads.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/QubesDownloads.md b/QubesDownloads.md index dfbc148b..cab9e92b 100644 --- a/QubesDownloads.md +++ b/QubesDownloads.md @@ -19,8 +19,8 @@ Qubes Release 3.0 --------------- - [Release notes](/doc/releases/3.0/release-notes/) - - +- [Qubes-R3.0-rc3-x86\_64-DVD.iso](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc3-x86_64-DVD.iso) (mirror 1) +- [Digital Signature](https://mirrors.kernel.org/qubes/iso/Qubes-R3.0-rc3-x86_64-DVD.iso.asc) (mirror 1) - [Qubes-R3.0-rc3-x86\_64-DVD.iso](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc3-x86_64-DVD.iso) (mirror 2) - [Digital Signature](https://ftp.qubes-os.org/iso/Qubes-R3.0-rc3-x86_64-DVD.iso.asc) (mirror 2) From 5f483fa685bfa11a17d0d14d37d9c8d7eef086a9 Mon Sep 17 00:00:00 2001 From: Jeepler Date: Fri, 18 Sep 2015 20:34:06 +0200 Subject: [PATCH 090/174] Qubes OS 3.0 rc3 release added to wikistart --- WikiStart.md | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/WikiStart.md b/WikiStart.md index 24fd6d97..216d3774 100644 --- a/WikiStart.md +++ b/WikiStart.md @@ -2,7 +2,7 @@ layout: doc title: Qubes OS Project permalink: / -redirect_from: +redirect_from: - "/wiki/" - "/wiki/WikiStart/" - "/trac/" @@ -29,6 +29,7 @@ Qubes is an open-source operating system designed to provide strong security for Recent News ----------- +- `Sep 16, 2015` Qubes OS 3.0 rc3 has been released! [announcement](https://groups.google.com/d/msg/qubes-users/v-eTHh3JLo0/AlaBthwhLQAJ) - `Aug 10, 2015` Qubes OS 3.0 rc2 LiveUSB (alpha) has been released! [announcement](https://groups.google.com/d/msg/qubes-users/IQdCEpkooto/iyMh3LuzCAAJ) - `Jul 31, 2015` Qubes OS 3.0 rc2 has been released! [announcement](https://groups.google.com/d/msg/qubes-users/jw9CdQepMPE/95HQDF6QBwAJ) - `Apr 23, 2015` Qubes OS 3.0 rc1 has been released! [announcement](http://blog.invisiblethings.org/2015/04/23/qubes-30rc1-and-roadmap.html) @@ -46,14 +47,3 @@ Recent News - `Nov 26, 2013` Windows 7 seamless GUI integration coming to Qubes OS! [article](http://blog.invisiblethings.org/2013/11/26/windows-7-seamless-gui-integration.html) - `Jun 21, 2013` Qubes OS R3 Alpha preview: Odyssey HAL in action! [announcement](http://blog.invisiblethings.org/2013/06/21/qubes-os-r3-alpha-preview-odyssey-hal.html) - `Mar 21, 2013` Introducing Qubes Odyssey Framework [article](http://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html) - - - - - - - - - - - From e352164673c7c8b0fd62fcb231d66d4611049db3 Mon Sep 17 00:00:00 2001 From: Jeepler Date: Fri, 18 Sep 2015 23:46:58 +0200 Subject: [PATCH 091/174] added a page ResizeRootDiskImage.md and removed the external link --- ResizeRootDiskImage.md | 29 +++++++++++++++++++++++++++++ UserDoc.md | 7 ++----- 2 files changed, 31 insertions(+), 5 deletions(-) create mode 100644 ResizeRootDiskImage.md diff --git a/ResizeRootDiskImage.md b/ResizeRootDiskImage.md new file mode 100644 index 00000000..7f434708 --- /dev/null +++ b/ResizeRootDiskImage.md @@ -0,0 +1,29 @@ +--- +layout: doc +title: ResizeRootDiskImage +permalink: /doc/ResizeRootDiskImage/ +redirect_from: /wiki/ResizeRootDiskImage/ +--- + +### Resizing \`root.img\` Size + +The safest way to increase the size of \`root.img\` is to do it for a standalone +VM (qvm-create --standalone) - which has its own root filesystem +(copy of template, instead of smart sharing). +But it should also work for a normal template (as long as changes in the +template between reboots didn't exceed 10G). + +Replace the size and the path (name) of the template as wished and run your +modified command: +``` +truncate -s 20G /var/lib/qubes/vm-templates/fedora-21/root.img +``` + +Then start your template or standalone VM and run: +``` +sudo resize2fs /dev/mapper/dmroot +``` + +after that shutdown the template. + +Then you should have extended \`root.img\` in your VM/template diff --git a/UserDoc.md b/UserDoc.md index 297bbe66..bed52081 100644 --- a/UserDoc.md +++ b/UserDoc.md @@ -57,9 +57,8 @@ Qubes User Documentation 3. [Upgrading the Fedora 20 Template](/doc/FedoraTemplateUpgrade20/) 4. [Templates: Fedora - minimal](/doc/Templates/FedoraMinimal/) 5. [Templates: Debian](/doc/Templates/Debian/) - 6. External Links - 1. [Extending \`root.img\` Size](https://groups.google.com/group/qubes-devel/msg/9d1ac581236ca9b4) - + 6. [Extending \`root.img\` Size](/doc/ResizeRootDiskImage/) + 6. **DispVMs** 1. [Disposable VMs](/doc/DisposableVms/) 2. [DispVM Customization](/doc/UserDoc/DispVMCustomization/) @@ -102,5 +101,3 @@ Qubes User Documentation 1. [Installing on system with new AMD GPU (missing firmware problem)](https://groups.google.com/group/qubes-devel/browse_thread/thread/e27a57b0eda62f76) 2. [Solving problems with Macbook Air 2012](https://groups.google.com/group/qubes-devel/browse_thread/thread/b8b0d819d2a4fc39/d50a72449107ab21#8a9268c09d105e69) 3. [Booting with GRUB2 and GPT](https://groups.google.com/group/qubes-devel/browse_thread/thread/e4ac093cabd37d2b/d5090c20d92c4128#d5090c20d92c4128) - - From 24b1c1c53b2e846df4a230bd943aab59a00f7ed4 Mon Sep 17 00:00:00 2001 From: Jeppler Date: Fri, 18 Sep 2015 23:54:27 +0200 Subject: [PATCH 092/174] just reverted (deleted) a former change --- Dom0Tools/QvmFirewall.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Dom0Tools/QvmFirewall.md b/Dom0Tools/QvmFirewall.md index 1a0529d6..121e569e 100644 --- a/Dom0Tools/QvmFirewall.md +++ b/Dom0Tools/QvmFirewall.md @@ -11,7 +11,7 @@ qvm-firewall NAME ---- -qvm-firewall - manage VM's firewall rules +qvm-firewall Date 2012-04-10 From 5309bed08c25a9158b837b2c0e30cc54408270b0 Mon Sep 17 00:00:00 2001 From: Jeepler Date: Sat, 19 Sep 2015 00:43:30 +0200 Subject: [PATCH 093/174] DocStyle description added rules for headings --- DocStyle.md | 3 ++- ResizeRootDiskImage.md | 5 +++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/DocStyle.md b/DocStyle.md index d9ab99dc..c222e7d6 100644 --- a/DocStyle.md +++ b/DocStyle.md @@ -22,7 +22,8 @@ Guidelines for Documentation Contributors where appropriate. * Use `[reference-style][ref]` links. `[ref]: http://daringfireball.net/projects/markdown/syntax#link` - + * Use underline headings `=====` and `-----` if possible. If this is not + possible use the Atx-style headings on the left side, e. g. `### H3`. Sending documentation updates ----------------------------- diff --git a/ResizeRootDiskImage.md b/ResizeRootDiskImage.md index 7f434708..238b777a 100644 --- a/ResizeRootDiskImage.md +++ b/ResizeRootDiskImage.md @@ -5,7 +5,8 @@ permalink: /doc/ResizeRootDiskImage/ redirect_from: /wiki/ResizeRootDiskImage/ --- -### Resizing \`root.img\` Size +Resizing \`root.img\` Size +-------------------------- The safest way to increase the size of \`root.img\` is to do it for a standalone VM (qvm-create --standalone) - which has its own root filesystem @@ -14,7 +15,7 @@ But it should also work for a normal template (as long as changes in the template between reboots didn't exceed 10G). Replace the size and the path (name) of the template as wished and run your -modified command: +modified command: ``` truncate -s 20G /var/lib/qubes/vm-templates/fedora-21/root.img ``` From 4ea778ccbc4fde892b97c955dabb1cdaed3c9da4 Mon Sep 17 00:00:00 2001 From: Jeepler Date: Sat, 19 Sep 2015 02:03:05 +0200 Subject: [PATCH 094/174] Added link to R3 template for Archlinux.md and added IPPolicy explanation to Ubuntu.md. Linked both files to UserDoc.md --- Templates/Archlinux.md | 6 +++++- Templates/Ubuntu.md | 8 ++++++-- UserDoc.md | 6 ++++-- 3 files changed, 15 insertions(+), 5 deletions(-) diff --git a/Templates/Archlinux.md b/Templates/Archlinux.md index 5db9db41..03db31b4 100644 --- a/Templates/Archlinux.md +++ b/Templates/Archlinux.md @@ -27,7 +27,11 @@ Install Currently we do not ship ready to use binary package. It can be compiled using [this instructions](/doc/BuildingArchlinuxTemplate/). -Olivier provides binary package build by himself, you can get it [here](https://groups.google.com/d/msgid/qubes-devel/54CE3FB1.3050708%40yahoo.fr). +Olivier provides binary package build by himself, you can get it for: +* Qubes R2 [here](https://groups.google.com/d/msgid/qubes-devel/54CE3FB1.3050708%40yahoo.fr). +* Qubes R3 [here](https://groups.google.com/d/msg/qubes-users/RI3KQVEEc30/h5nsNw_SHTQJ) + + Known issues ------------ diff --git a/Templates/Ubuntu.md b/Templates/Ubuntu.md index 3d7f635b..45de1d69 100644 --- a/Templates/Ubuntu.md +++ b/Templates/Ubuntu.md @@ -10,7 +10,10 @@ Ubuntu template(s) If you like to use Ubuntu Linux distribution in your AppVMs, you can build and install one of available Ubuntu templates. Those template currently are not -available in ready to use binary packages. +available in ready to use binary packages, because Canonical does not allow +to redistribute a modified Ubuntu. The redistribution is not allowed by their +[Intellectual property rights policy](http://www.ubuntu.com/legal/terms-and-policies/intellectual-property-policy). + Install ------- @@ -26,4 +29,5 @@ want to build. Known issues ------------ -If you want to help in improving the template, feel free to [contribute](/wiki/ContributingHowto). +If you want to help in improving the template, feel free to +[contribute](/wiki/ContributingHowto). diff --git a/UserDoc.md b/UserDoc.md index bed52081..edcdeda1 100644 --- a/UserDoc.md +++ b/UserDoc.md @@ -57,8 +57,10 @@ Qubes User Documentation 3. [Upgrading the Fedora 20 Template](/doc/FedoraTemplateUpgrade20/) 4. [Templates: Fedora - minimal](/doc/Templates/FedoraMinimal/) 5. [Templates: Debian](/doc/Templates/Debian/) - 6. [Extending \`root.img\` Size](/doc/ResizeRootDiskImage/) - + 6. [Templates: Archlinux](/doc/Templates/Archlinux/) + 7. [Templates: Ubuntu](/doc/Templates/Ubuntu/) + 8. [Extending \`root.img\` Size](/doc/ResizeRootDiskImage/) + 6. **DispVMs** 1. [Disposable VMs](/doc/DisposableVms/) 2. [DispVM Customization](/doc/UserDoc/DispVMCustomization/) From 00574e390aff56c46e2ac7de317f226474b0f8af Mon Sep 17 00:00:00 2001 From: Axon Date: Sat, 19 Sep 2015 04:17:17 +0000 Subject: [PATCH 095/174] Restore intentional end-of-line spaces Erroneously removed by ypid/qubes-doc@1d80a57 --- DocStyle.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/DocStyle.md b/DocStyle.md index d9ab99dc..7eb1ceb2 100644 --- a/DocStyle.md +++ b/DocStyle.md @@ -18,9 +18,9 @@ Guidelines for Documentation Contributors * In the event that a user is required to read the Markdown source directly, this will make it easier to follow, e.g., numbered steps in a set of instructions. - * Use hanging indentations + * Use hanging indentations where appropriate. - * Use `[reference-style][ref]` links. + * Use `[reference-style][ref]` links. `[ref]: http://daringfireball.net/projects/markdown/syntax#link` From 1c8b80339c54f26c179358554422a3cd67407308 Mon Sep 17 00:00:00 2001 From: Jeepler Date: Sun, 20 Sep 2015 05:08:04 +0200 Subject: [PATCH 096/174] all wiki trac {% highlight trac-wiki %}{% endhighlight %} replaced with the ``` used for markdown code --- AntiEvilMaid.md | 4 +- AssigningDevices.md | 44 +++++++++++----------- BackupEmergencyRestoreV2.md | 32 ++++++++-------- BuildingArchlinuxTemplate.md | 68 +++++++++++++++++----------------- BuildingNonFedoraTemplate.md | 16 ++++---- CodingStyle.md | 20 +++++----- CopyPaste.md | 12 +++--- CopyToDomZero.md | 8 ++-- DevelopmentWorkflow.md | 56 ++++++++++++++-------------- DiskTRIM.md | 12 +++--- DisposableVms.md | 12 +++--- Donations.md | 4 +- ExternalAudio.md | 12 +++--- ExternalDeviceMountPoint.md | 4 +- FedoraTemplateUpgrade18.md | 24 ++++++------ Fetchmail.md | 12 +++--- FullScreenMode.md | 8 ++-- GUIdocs.md | 8 ++-- GettingStarted.md | 16 ++++---- HvmCreate.md | 60 +++++++++++++++--------------- InstallNvidiaDriver.md | 32 ++++++++-------- InstallationIsoBuilding.md | 16 ++++---- KdeDom0.md | 20 +++++----- LinuxHVMTips.md | 12 +++--- Mutt.md | 12 +++--- NetworkBridgeSupport.md | 32 ++++++++-------- NvidiaTroubleshooting.md | 24 ++++++------ OutOfmemory.md | 20 +++++----- Postfix.md | 36 +++++++++--------- Profiling.md | 24 ++++++------ Qrexec.md | 36 +++++++++--------- Qrexec3.md | 20 +++++----- Qrexec3Implementation.md | 20 +++++----- QubesBuilder.md | 24 ++++++------ QubesFirewall.md | 56 ++++++++++++++-------------- QubesR3Building.md | 20 +++++----- QubesService.md | 4 +- ResizeDiskImage.md | 32 ++++++++-------- Rxvt.md | 8 ++-- SecurityGuidelines.md | 24 ++++++------ SecurityPage.md | 4 +- SoftwareUpdateDom0.md | 24 ++++++------ SoftwareUpdateVM.md | 16 ++++---- SonyVaioTinkering.md | 4 +- SourceCode.md | 8 ++-- Templates/FedoraMinimal.md | 20 +++++----- TestBench.md | 12 +++--- UpgradeToR2.md | 12 +++--- UpgradeToR2B1.md | 20 +++++----- UpgradeToR2B2.md | 32 ++++++++-------- UpgradeToR2B3.md | 24 ++++++------ UsbInstallation.md | 4 +- UserDoc/ConfigFiles.md | 8 ++-- UserDoc/DispVMCustomization.md | 20 +++++----- UserDoc/SplitGpg.md | 20 +++++----- UserDoc/XFCE.md | 12 +++--- UserFaq.md | 4 +- VerifyingSignatures.md | 36 +++++++++--------- WindowsAppVms.md | 32 ++++++++-------- WindowsDebugging.md | 8 ++-- ZFS.md | 56 ++++++++++++++-------------- releases/1.0/release-notes.md | 8 ++-- 62 files changed, 644 insertions(+), 644 deletions(-) diff --git a/AntiEvilMaid.md b/AntiEvilMaid.md index 0ffd201c..2b6ec1b0 100644 --- a/AntiEvilMaid.md +++ b/AntiEvilMaid.md @@ -18,9 +18,9 @@ Installing In Dom0 install anti-evil-maid: -{% highlight trac-wiki %} +``` sudo qubes-dom0-update anti-evil-maid -{% endhighlight %} +``` More information regarding configuration in the [README](https://github.com/QubesOS/qubes-antievilmaid/blob/master/README) file. diff --git a/AssigningDevices.md b/AssigningDevices.md index a75fdb84..04cc8338 100644 --- a/AssigningDevices.md +++ b/AssigningDevices.md @@ -10,21 +10,21 @@ Assigning Devices to VMs In order to assign a whole PCI(e) device to a VM, one should use `qvm-pci` tool. E.g. -{% highlight trac-wiki %} +``` lspci -{% endhighlight %} +``` Find the BDF address of the device you want to assign, and then: -{% highlight trac-wiki %} +``` qvm-pci -a -{% endhighlight %} +``` E.g. assuming 00:1a.0 is a BDF of the device I want to assign to the "personal" domain: -{% highlight trac-wiki %} +``` qvm-pci -a personal 00:1a.0 -{% endhighlight %} +``` Note that one can only assign full PCI or PCI Express devices. This means one cannot assign single USB devices -- only the whole USB controller with whatever USB devices connected to it. This limit is imposed by PC and VT-d architecture. @@ -40,33 +40,33 @@ Finding the right USB controller If you want assign certain USB device to a VM (by attaching a 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: -{% highlight trac-wiki %} +``` lsusb -{% endhighlight %} +``` For example I want assign a broadband modem to the netvm. In lsusb output it can be listed as something like this (in this case device isn't fully identified): -{% highlight trac-wiki %} +``` Bus 003 Device 003: ID 413c:818d Dell Computer Corp. -{% endhighlight %} +``` The device is connected to the USB bus \#3. Then check which other devices are connected to the same bus - all of them will be assigned to the same VM. Now is the time to find right USB controller: -{% highlight trac-wiki %} +``` readlink /sys/bus/usb/devices/usb3 -{% endhighlight %} +``` This should output something like: -{% highlight trac-wiki %} +``` ../../../devices/pci-0/pci0000:00/0000:00:1a.0/usb3 -{% endhighlight %} +``` Now you see BDF address in the path (right before final usb3). Strip leading "0000:" and pass the rest to qvm-pci tool: -{% highlight trac-wiki %} +``` qvm-pci -a netvm 00:1a.0 -{% endhighlight %} +``` Possible issues --------------- @@ -75,11 +75,11 @@ Possible issues VMs with assigned PCI devices in Qubes have allocated a small buffer for DMA operations (called swiotlb). By default it is 2MB, but some devices need a larger buffer. To change this allocation, edit VM's kernel parameters (this is expressed in 512B chunks): -{% highlight trac-wiki %} +``` # qvm-prefs netvm |grep kernelopts kernelopts : iommu=soft swiotlb=2048 (default) # qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=4096" -{% endhighlight %} +``` This is [known to be needed](https://groups.google.com/group/qubes-devel/browse_thread/thread/631c4a3a9d1186e3) for Realtek RTL8111DL Gigabit Ethernet Controller. @@ -87,7 +87,7 @@ This is [known to be needed](https://groups.google.com/group/qubes-devel/browse_ Sometimes PCI arbitrator is too strict. There is a way to enable permissive mode for it. Create `/etc/systemd/system/qubes-pre-netvm.service`: -{% highlight trac-wiki %} +``` [Unit] Description=Netvm fixup Before=qubes-netvm.service @@ -99,7 +99,7 @@ RemainAfterExit=yes [Install] WantedBy=multi-user.target -{% endhighlight %} +``` Then enable it with `systemctl enable qubes-pre-netvm.service` @@ -118,11 +118,11 @@ or 1. Go to the sysfs (`/sys/bus/pci`), find the right device, detach it from the pciback driver and attach back to the original driver. Replace `` with your device, for example `00:1c.2`: - {% highlight trac-wiki %} + ``` echo 0000: > /sys/bus/pci/drivers/pciback/unbind MODALIAS=`cat /sys/bus/pci/devices/0000:/modalias` MOD=`modprobe -R $MODALIAS | head -n 1` echo > /sys/bus/pci/drivers/$MOD/bind - {% endhighlight %} + ``` diff --git a/BackupEmergencyRestoreV2.md b/BackupEmergencyRestoreV2.md index f8359783..f9750a24 100644 --- a/BackupEmergencyRestoreV2.md +++ b/BackupEmergencyRestoreV2.md @@ -15,7 +15,7 @@ The Qubes backup system has been designed with emergency disaster recovery in mi 1. Untar the main backup file. - {% highlight trac-wiki %} + ``` [user@restore ~]$ tar -i -xvf qubes-backup-2013-12-26-123456 backup-header backup-header.hmac @@ -31,17 +31,17 @@ The Qubes backup system has been designed with emergency disaster recovery in mi vm1/whitelisted-appmenus.list.000.hmac dom0-home/dom0user.000 dom0-home/dom0user.000.hmac - {% endhighlight %} + ``` 1. Verify the integrity of the `private.img` file which houses your data. - {% highlight trac-wiki %} + ``` [user@restore ~]$ cd vm1/ [user@restore vm1]$ openssl dgst -sha512 -hmac "your_passphrase" private.img.000 HMAC-SHA512(private.img.000)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e [user@restore vm1]$ cat private.img.000.hmac (stdin)= cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e - {% endhighlight %} + ``` **Note:** The hash values should match. If they do not match, then the backup file may have been tampered with, or there may have been a storage error. @@ -49,59 +49,59 @@ The Qubes backup system has been designed with emergency disaster recovery in mi 1. Decrypt the `private.img` file. - {% highlight trac-wiki %} + ``` [user@restore vm1]$ openssl enc -d -pass pass:your_passphrase -aes-256-cbc -in private.img.000 -out private.img.dec.000 - {% endhighlight %} + ``` **Note:** For multi-part files, a loop can be used: - {% highlight trac-wiki %} + ``` for f in private.img.*; do openssl enc -d -pass pass:your_passphrase -aes-256-cbc -in $f -out ${f/.img/.img.dec} done - {% endhighlight %} + ``` **Note:** If your backup was encrypted with a cipher algorithm other than `aes-256-cbc`, you must substitute the correct cipher command. A complete list of supported cipher algorithms can be found with `openssl list-cipher-algorithms`. 1. Decompress the decrypted `private.img` file. - {% highlight trac-wiki %} + ``` [user@restore vm1]$ zforce private.img.dec.* [user@restore vm1]$ gunzip private.img.dec.000.gz - {% endhighlight %} + ``` **Note:** If your backup was compressed with a program other than `gzip`, you must substitute the correct compression program. 1. Untar the decrypted and decompressed `private.img` file. - {% highlight trac-wiki %} + ``` [user@restore vm1]$ tar -M -xvf private.img.dec.000 vm1/private.img - {% endhighlight %} + ``` **Note:** For multi-part files, a script is required: 1. Create a `new-volume-script`: - {% highlight trac-wiki %} + ``` #!/bin/sh name=`expr $TAR_ARCHIVE : '\(.*\)\..*'` suffix=`printf %03d $[ $TAR_VOLUME - 1 ]` echo $name.$suffix >&$TAR_FD - {% endhighlight %} + ``` 2. `chmod +x new-volume-script`. 3. `tar --new-volume-script=./new-volume-script -xvf private.img.dec.000`. (The `--new-volume-script` option enables multi-volume untaring.) 1. Mount the private.img file and access your data. - {% highlight trac-wiki %} + ``` [user@restore vm1]$ sudo mkdir /mnt/img [user@restore vm1]$ sudo mount -o loop vm1/private.img /mnt/img/ [user@restore vm1]$ cat /mnt/img/home/user/your_data.txt This data has been successfully recovered! - {% endhighlight %} + ``` **Note:** You may wish to store a plain text copy of these instructions with your Qubes backups in the event that you fail to recall the above procedure while this web page is inaccessible. You may obtain a plaintext version of this file in Git repository housing all the documentation at: diff --git a/BuildingArchlinuxTemplate.md b/BuildingArchlinuxTemplate.md index 9cd6ab90..e70c2be9 100644 --- a/BuildingArchlinuxTemplate.md +++ b/BuildingArchlinuxTemplate.md @@ -23,17 +23,17 @@ Change the following variables GIT\_SUBDIR=marmarek DISTS\_VM=archlinux Get all required sources ------------------------ -{% highlight trac-wiki %} +``` make get-sources -{% endhighlight %} +``` Note that make get-sources sometimes fails because it didn't download packages that are not used by archlinux such as xfce or kde packages. You can ignore the repositories that are failing by adding the following line to your builder.conf: -{% highlight trac-wiki %} +``` COMPONENTS:=$(filter-out desktop-linux-kde desktop-linux-xfce,$(COMPONENTS)) -{% endhighlight %} +``` Just don't forget that you need to comment this line again if you want to build the whole Qubes-OS install CD. @@ -42,23 +42,23 @@ Make all required qubes components The first use of the builder can take several hours depending on your bandwidth as it will install an archlinux chroot: -{% highlight trac-wiki %} +``` make vmm-xen-vm make core-vchan-xen-vm make linux-utils-vm make core-agent-linux-vm make gui-common-vm make gui-agent-linux-vm -{% endhighlight %} +``` Now build the template itself ----------------------------- This can take again several hours, especially the first time you built and archlinux template: -{% highlight trac-wiki %} +``` make linux-template-builder -{% endhighlight %} +``` Retrieve your template ---------------------- @@ -75,30 +75,30 @@ Can't open file archlinux-2013.02.01-dual.iso Archlinux ISO files are sometimes removed from mirrors. Check the last version available on the archlinux mirror (eg: [http://mir.archlinux.fr/iso/](http://mir.archlinux.fr/iso/)), and update qubes-src/linux-template-builder/scripts\_archlinux/00\_prepare.sh accordingly: -{% highlight trac-wiki %} +``` ISO_VERSION=2013.06.01 -{% endhighlight %} +``` You will also need to download the signature matching this ISO version inside qubes-src/linux-template-builder/scripts\_archlinux/: -{% highlight trac-wiki %} +``` wget http://mir.archlinux.fr/iso/2013.06.01/archlinux-2013.06.01-dual.iso.sig -{% endhighlight %} +``` The nm-applet (network manager icon) fails to start when archlinux is defined as a template-vm: ----------------------------------------------------------------------------------------------- In fact /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf does not allow a standard user to run network manager clients. To allow this, one need to change inside \: -{% highlight trac-wiki %} +``` -{% endhighlight %} +``` to -{% highlight trac-wiki %} +``` -{% endhighlight %} +``` DispVM, Yum proxy and most Qubes addons (thunderbird ...) have not been tested at all. -------------------------------------------------------------------------------------- @@ -111,26 +111,26 @@ This is apparently a bug in Archlinux between glibc and pulseaudio package 4.0-6 Error when building the gui-agent-linux with pulsecore error ------------------------------------------------------------ -{% highlight trac-wiki %} +``` module-vchan-sink.c:62:34: fatal error: pulsecore/core-error.h: No such file or directory #include -{% endhighlight %} +``` This error is because Archlinux update package too quickly. Probably, a new version of pulseaudio has been released, but the qubes team has not imported the new development headers yet. You can create fake new headers just by copying the old headers: -{% highlight trac-wiki %} +``` cd qubes-builder/qubes-src/gui-agent-linux/pulse ls cp -r pulsecore-#lastversion pulsecore-#archlinuxversion -{% endhighlight %} +``` You can check the current archlinux pulseaudio version like this: -{% highlight trac-wiki %} +``` sudo chroot chroot-archlinux/ pacman -Qi pulseaudio -{% endhighlight %} +``` chroot-archlinux/dev/pts has not been unmounted ----------------------------------------------- @@ -154,15 +154,15 @@ The boot process fails without visible errors in the logs, but spawn a recovery The problem is a new conflict between systemd and the old sysvinit style. To fix this, you can change the master xen template in dom0 to remove sysvinit remains: Edit **INSIDE DOM0** /usr/share/qubes/vm-template.conf, and change the variable 'extra' that contains the kernel variables: from: -{% highlight trac-wiki %} +``` extra="ro nomodeset 3 console=hvc0 rd_NO_PLYMOUTH {kernelopts}" -{% endhighlight %} +``` to: -{% highlight trac-wiki %} +``` extra="ro nomodeset console=hvc0 rd_NO_PLYMOUTH {kernelopts}" -{% endhighlight %} +``` Qubes-OS is now using different xenstore variable names, which makes to archlinux VM failing to boot ---------------------------------------------------------------------------------------------------- @@ -171,15 +171,15 @@ Apply the following fix in the template to revert the variable name to the old Q You can edit the template the following way: -{% highlight trac-wiki %} +``` sudo mkdir /mnt/vm sudo mount /var/lib/qubes/vm-templates/archlinux-x64/root.img /mnt/vm sudo chroot /mnt/vm -{% endhighlight %} +``` Then apply the fix: -{% highlight trac-wiki %} +``` sudo sed 's:qubes-keyboard:qubes_keyboard:g' -i /etc/X11/xinit/xinitrc.d/qubes-keymap.sh sudo sed 's:qubes-netvm-domid:qubes_netvm_domid:g' -i /etc/NetworkManager/dispatcher.d/30-qubes-external-ip @@ -212,19 +212,19 @@ sudo sed 's:qubes-vm-updateable:qubes_vm_updateable:g' -i /usr/lib/qubes/qubes_t sudo sed 's:qubes-vm-type:qubes_vm_type:g' -i /usr/bin/qubes-session sudo sed 's:qubes-vm-updateable:qubes_vm_updateable:g' -i /usr/bin/qubes-session -{% endhighlight %} +``` Do not forgot to: -{% highlight trac-wiki %} +``` umount /mnt/vm -{% endhighlight %} +``` Installing the template in dom0 fails because of a missing dependency (qubes-core-dom0-linux) --------------------------------------------------------------------------------------------- Again you built a template based on a recent Qubes API which has not been released yet. So skip the dependency for now: -{% highlight trac-wiki %} +``` sudo rpm -U --nodeps yourpackage.rpm -{% endhighlight %} +``` diff --git a/BuildingNonFedoraTemplate.md b/BuildingNonFedoraTemplate.md index 7f654b46..3fb15c8a 100644 --- a/BuildingNonFedoraTemplate.md +++ b/BuildingNonFedoraTemplate.md @@ -24,11 +24,11 @@ You need to install your OS inside a chroot that will be used to build all the r The scripts you will be interested in will be inside the qubes-src/linux-template-builder project: -{% highlight trac-wiki %} +``` scripts_fedora scripts_archlinux scripts_yourOSname -{% endhighlight %} +``` ### 00\_prepare.sh @@ -42,19 +42,19 @@ The goal of this script is to install a base environment of your target OS insid Edit the builder.conf file to change the variable DISTS\_VM to your OS name (DISTS\_VM=your\_os\_name). The try to make the template to check that at least these to first scripts are working correctly: -{% highlight trac-wiki %} +``` make linux-template-builder -{% endhighlight %} +``` Qubes builder Makefiles ----------------------- Now you need to create Makefiles specific to your OS. You will find the required scripts directly inside qubes-builder: -{% highlight trac-wiki %} +``` prepare-chroot-yourOSname Makefile.yourOSname -{% endhighlight %} +``` ### prepare-chroot-yourOSname @@ -103,11 +103,11 @@ Additional Installation scripts Again you need to work on scripts inside the qubes-src/linux-template-builder project: -{% highlight trac-wiki %} +``` scripts_fedora scripts_archlinux scripts_yourOSname -{% endhighlight %} +``` ### 02\_install\_groups.sh diff --git a/CodingStyle.md b/CodingStyle.md index a26c6561..5e1aa7f5 100644 --- a/CodingStyle.md +++ b/CodingStyle.md @@ -47,14 +47,14 @@ General typographic conventions - Comments should be indent together with the code, e.g. like this: - {% highlight trac-wiki %} + ``` for (...) { // The following code finds PGP private key matching the given public key in O(1) while (key_found) { (...) } } - {% endhighlight %} + ``` File naming conventions ----------------------- @@ -87,29 +87,29 @@ General programming style guidelines - 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: - {% highlight trac-wiki %} + ``` // Return window id int get_window_id (...) { (...) return id; } - {% endhighlight %} + ``` - Do **not** use comments to disable code fragments. In a production code there should really be no commented or disabled code fragments. If you really, really have a good reason to retain some fragment of unused code, use \#if or \#ifdef to disable it, e.g.: - {% highlight trac-wiki %} + ``` #if 0 (...) // Some unused code here #endif - {% endhighlight %} + ``` ... and preferably use some descriptive macro instead of just `0`, e.g.: - {% highlight trac-wiki %} + ``` #if USE_OLD_WINDOW_TRAVERSING (...) // Some unused code here #endif - {% endhighlight %} + ``` Not sure how to do similar thing in Python... Anyone? @@ -137,7 +137,7 @@ Security coding guidelines - Any input that comes from untrusted, or less trusted, or just differently-trusted, entity should always be considered as malicious and should always be sanitized and verified. So, if your software runs in Dom0 and processes some input from any of the VMs, this input should be considered to be malicious. Even if your software runs in a VM, and processes input from some other VM, you should also assume that the input is malicious and verify it. - Use `untrusted_` prefix for all variables that hold values read from untrusted party and which have not yet been verified to be decent, e.g.: - {% highlight trac-wiki %} + ``` read_struct(untrusted_conf); /* sanitize start */ if (untrusted_conf.width > MAX_WINDOW_WIDTH) @@ -146,7 +146,7 @@ Security coding guidelines untrusted_conf.height = MAX_WINDOW_HEIGHT; width = untrusted_conf.width; height = untrusted_conf.height; - {% endhighlight %} + ``` - Use another variables, without the `untrusted_` prefix to hold the sanitized values, as shown above. diff --git a/CopyPaste.md b/CopyPaste.md index 7ac185ce..689c4c78 100644 --- a/CopyPaste.md +++ b/CopyPaste.md @@ -52,22 +52,22 @@ Clipboard automatic policy enforcement The Qubes clipboard policy is configurable in: -{% highlight trac-wiki %} +``` /etc/qubes-rpc/policy/qubes.ClipboardPaste -{% endhighlight %} +``` You may wish to configure this policy in order to prevent user error. For example, if you are certain that you never wish to paste *into* your "vault" AppVM (and it is highly recommended that you do not), then you should edit the policy as follows: -{% highlight trac-wiki %} +``` $anyvm vault deny $anyvm $anyvm ask -{% endhighlight %} +``` Shortcut Configuration ---------------------- The copy/paste shortcuts are configurable in: -{% highlight trac-wiki %} +``` /etc/qubes/guid.conf -{% endhighlight %} +``` diff --git a/CopyToDomZero.md b/CopyToDomZero.md index 93606a17..ed62636f 100644 --- a/CopyToDomZero.md +++ b/CopyToDomZero.md @@ -12,15 +12,15 @@ First, there should normally be few reasons for the user to want to copy files f For this reason we intentionally do not provide a convenient tool for copying files between VMs and Dom0 (while we provide a tool for copying files between VMs). However, if you're determined to copy some files to Dom0 anyway, you can use the following method (run this command from Dom0's console): -{% highlight trac-wiki %} +``` qvm-run --pass-io 'cat /path/to/file_in_src_domain' > /path/to/file_name_in_dom0 -{% endhighlight %} +``` BTW, you can use the same method to copy files from Dom0 to VMs: -{% highlight trac-wiki %} +``` cat /path/to/file_in_dom0 | qvm-run --pass-io 'cat > /path/to/file_name_in_appvm' -{% endhighlight %} +``` ### Copying logs from dom0 diff --git a/DevelopmentWorkflow.md b/DevelopmentWorkflow.md index c32016ef..9def5daa 100644 --- a/DevelopmentWorkflow.md +++ b/DevelopmentWorkflow.md @@ -22,10 +22,10 @@ The best way to write and contribute code is to create a git repo somewhere (e.g **Example:** -{% highlight trac-wiki %} +``` $ cd qubes-builder/qubes-src/qubes-manager $ git remote add abel git@github.com:abeluck/qubes-manager.git -{% endhighlight %} +``` You can then proceed to easily develop in your own branches, pull in new commits from the dev branches, merge them, and eventually push to your own repo on github. @@ -37,55 +37,55 @@ When you are ready to submit your changes to Qubes to be merged, push your chang In qubes-builder/qubes-src/kernel: -{% highlight trac-wiki %} +``` make prep -{% endhighlight %} +``` The resulting tree will be in kernel-\/linux-\: -{% highlight trac-wiki %} +``` ls -ltrd kernel*/linux* -{% endhighlight %} +``` -{% highlight trac-wiki %} +``` drwxr-xr-x 23 user user 4096 Nov 5 09:50 kernel-3.4.18/linux-3.4.18 drwxr-xr-x 6 user user 4096 Nov 21 20:48 kernel-3.4.18/linux-obj -{% endhighlight %} +``` #### Go to the kernel tree and update the version In qubes-builder/qubes-src/kernel: -{% highlight trac-wiki %} +``` cd kernel-3.4.18/linux-3.4.18 -{% endhighlight %} +``` #### Changing the config In kernel-3.4.18/linux-3.4.18: -{% highlight trac-wiki %} +``` cp ../../config-pvops .config make oldconfig -{% endhighlight %} +``` Now change the configuration. For example, in kernel-3.4.18/linux-3.4.18: -{% highlight trac-wiki %} +``` make menuconfig -{% endhighlight %} +``` Copy the modified config back into the kernel tree: -{% highlight trac-wiki %} +``` cp .config ../../../config-pvops -{% endhighlight %} +``` #### Patching the code TODO: describe the workflow for patching the code, below are some random notes, not working well -{% highlight trac-wiki %} +``` ln -s ../../patches.xen export QUILT_PATCHES=patches.xen export QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" @@ -101,7 +101,7 @@ quilt add drivers/usb/host/Kconfig drivers/usb/host/Makefile \ quilt refresh cd ../.. vi series-pvops.conf -{% endhighlight %} +``` #### Building RPMS @@ -113,20 +113,20 @@ You might want to take a moment here to review (git diff, git status), commit yo To actually build RPMS, in qubes-src/kernel: -{% highlight trac-wiki %} +``` make rpms -{% endhighlight %} +``` RPMS will appear in qubes-src/kernel/rpm/x86\_64: -{% highlight trac-wiki %} +``` -rw-rw-r-- 1 user user 42996126 Nov 17 04:08 kernel-3.4.18-1debug20121116c.pvops.qubes.x86_64.rpm -rw-rw-r-- 1 user user 43001450 Nov 17 05:36 kernel-3.4.18-1debug20121117a.pvops.qubes.x86_64.rpm -rw-rw-r-- 1 user user 8940138 Nov 17 04:08 kernel-devel-3.4.18-1debug20121116c.pvops.qubes.x86_64.rpm -rw-rw-r-- 1 user user 8937818 Nov 17 05:36 kernel-devel-3.4.18-1debug20121117a.pvops.qubes.x86_64.rpm -rw-rw-r-- 1 user user 54490741 Nov 17 04:08 kernel-qubes-vm-3.4.18-1debug20121116c.pvops.qubes.x86_64.rpm -rw-rw-r-- 1 user user 54502117 Nov 17 05:37 kernel-qubes-vm-3.4.18-1debug20121117a.pvops.qubes.x86_64.rpm -{% endhighlight %} +``` ### Useful [QubesBuilder](/doc/QubesBuilder/) commands @@ -148,7 +148,7 @@ You may also like to run your [test environment on separate machine](/doc/TestBe TODO: edit this script to be more generic -{% highlight trac-wiki %} +``` #!/bin/sh set -x @@ -171,24 +171,24 @@ 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/ # FIXME(Abel Luck): I hope to -{% endhighlight %} +``` ### Apply qvm-tools TODO: make it more generic -{% highlight trac-wiki %} +``` #!/bin/sh BAK=qvm-tools.bak$$ mkdir -p $BAK cp -a /usr/bin/qvm-* /usr/bin/qubes-* $BAK/ sudo cp qvm-tools/qvm-* qvm-tools/qubes-* /usr/bin/ -{% endhighlight %} +``` ### Copy from dom0 to an appvm -{% highlight trac-wiki %} +``` #/bin/sh # # usage ./cp-domain @@ -199,4 +199,4 @@ fname=`basename $file` qvm-run $domain 'mkdir /home/user/incoming/dom0 -p' cat $file| qvm-run --pass-io $domain "cat > /home/user/incoming/dom0/$fname" -{% endhighlight %} +``` diff --git a/DiskTRIM.md b/DiskTRIM.md index 3d91bddf..8567ac9b 100644 --- a/DiskTRIM.md +++ b/DiskTRIM.md @@ -11,23 +11,23 @@ To enable TRIM in dom0 you need: 1. Get your LUKS device UUID: - {% highlight trac-wiki %} + ``` ls /dev/mapper/luks-* - {% endhighlight %} + ``` 2. Add entry to `/etc/crypttab` (replace luks-\ with the device name and the \ with UUID alone): - {% highlight trac-wiki %} + ``` luks- UUID= none allow-discards - {% endhighlight %} + ``` 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**: - {% highlight trac-wiki %} + ``` dracut -H -f - {% endhighlight %} + ``` 6. Add "discard" option to `/etc/fstab` for root device 7. Reboot the system, verify that allow-discards is really enabled (`dmsetup table`) diff --git a/DisposableVms.md b/DisposableVms.md index 0f1d4e61..461ac310 100644 --- a/DisposableVms.md +++ b/DisposableVms.md @@ -38,9 +38,9 @@ Opening a file in a Disposable VM via command line (from AppVM) Use the `qvm-open-in-dvm` command line (from your AppVM), e.g.: -{% highlight trac-wiki %} +``` [user@work-pub ~]$ qvm-open-in-dvm Downloads/apple-sandbox.pdf -{% endhighlight %} +``` The qvm-open-in-dvm will not exit until you close the application in the Disposable VM. @@ -49,9 +49,9 @@ Starting an arbitrary application in a disposable VM via command line (from Dom0 **Note:** Normally there should be no need for doing this -- this is just for Qubes hackers ;) -{% highlight trac-wiki %} +``` [joanna@dom0 ~]$ echo xterm | /usr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT red -{% endhighlight %} +``` In fact the Disposable VM appmenu used for starting Firefox contains a very similar command to the above. Please note, however, that it generally makes little sense to start any other application other than a Web Browser this way... @@ -60,9 +60,9 @@ Starting an arbitrary program in a Disposable VM from an AppVM Sometimes it might be useful to start an arbitrary program, such as e.g. terminal in an Disposable VM from an AppVM. This could be simply done this way: -{% highlight trac-wiki %} +``` [user@vault ~]$ qvm-run '$dispvm' xterm -{% endhighlight %} +``` Note the above command is issued in an AppVM, not in Dom0. The created Disposable VM can be normally accessed via other tools, such as e.g. `qvm-copy-to-vm`, using its 'dispX' name, as shown by the Qubes Manager or `qvm-ls` tools. diff --git a/Donations.md b/Donations.md index 386eba81..1f5a01c5 100644 --- a/Donations.md +++ b/Donations.md @@ -10,9 +10,9 @@ Donating to the Qubes Project The Qubes project is now accepting donations in Bitcoins. You can use the following address to send Bitcoins to the project (but you might want to read the short FAQ below first): -{% highlight trac-wiki %} +``` 14zockMSKKp5MK6X2cHJ3mQwm9MwYsJ39j -{% endhighlight %} +``` This address can also be found in a message posted to Qubes mailing list, which can be viewed via Google Groups Web interface over SSL [here](https://groups.google.com/d/msg/qubes-devel/u3wAzm1dB5Y/s5CiUGDebL4J), for double verification. For additional verification, you can verify the digital signature on the message, which should come from Joanna Rutkowska. diff --git a/ExternalAudio.md b/ExternalAudio.md index deedc75e..4e1f6fa6 100644 --- a/ExternalAudio.md +++ b/ExternalAudio.md @@ -22,16 +22,16 @@ First you need to identify an user VM dedicated to audio and [assign a device](/ In a terminal of the template from which you user VM depends, install pavucontrol with: -{% highlight trac-wiki %} +``` sudo yum install pavucontrol -{% endhighlight %} +``` 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: -{% highlight trac-wiki %} +``` sudo chmod a+rw /dev/snd/* pactl load-module module-udev-detect -{% endhighlight %} +``` Start the audio application that is going to use the external audio device. @@ -39,8 +39,8 @@ Launch pavucontrol, for example using "run command in VM" of Qubes Manager and s 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: -{% highlight trac-wiki %} +``` pactl unload-module module-udev-detect sudo chmod a+rw /dev/snd/* pactl load-module module-udev-detect -{% endhighlight %} +``` diff --git a/ExternalDeviceMountPoint.md b/ExternalDeviceMountPoint.md index 65220cf2..c5301fe6 100644 --- a/ExternalDeviceMountPoint.md +++ b/ExternalDeviceMountPoint.md @@ -7,8 +7,8 @@ redirect_from: /wiki/ExternalDeviceMountPoint/ All external storage devices connected to an AppVM using the Fedora template can be found under -{% highlight trac-wiki %} +``` /run/media/user/ -{% endhighlight %} +``` ...of that AppVM's filesystem. diff --git a/FedoraTemplateUpgrade18.md b/FedoraTemplateUpgrade18.md index f15d521e..06b929ba 100644 --- a/FedoraTemplateUpgrade18.md +++ b/FedoraTemplateUpgrade18.md @@ -17,32 +17,32 @@ Upgrading Fedora 18 to Fedora 20 Commands to run in dom0 console (you can do the same from Qubes Manager): -{% highlight trac-wiki %} +``` qvm-clone fedora-18-x64 fedora-20-x64 qvm-run -a fedora-20-x64 gnome-terminal -{% endhighlight %} +``` Commands to run in new fedora-20-x64 template: -{% highlight trac-wiki %} +``` sudo yum --releasever=20 distro-sync poweroff -{% endhighlight %} +``` If you have installed a lot of software in your template, it may happen that you don't have enough disk space for upgrade. Yum will tell you this just after confirming the operation (before it change anything to your system). In that case you need to provide some "external" place for yum cache (uses about 2GB during upgrade). For example attach virtual disk stored in some file. Prepare the file in dom0: -{% highlight trac-wiki %} +``` truncate -s 5GB /var/tmp/template-upgrade-cache.img qvm-block -A fedora-20-x64 dom0:/var/tmp/template-upgrade-cache.img -{% endhighlight %} +``` Then use it in template: -{% highlight trac-wiki %} +``` sudo mkfs.ext4 /dev/xvdi sudo mount /dev/xvdi /mnt/removable sudo yum --releasever=20 --setopt=cachedir=/mnt/removable distro-sync -{% endhighlight %} +``` After upgrade is finished, you can remove /var/tmp/template-upgrade-cache.img file. @@ -55,17 +55,17 @@ fstrim, nor "discard" mount option do not work on template root fs, so when some You can compact root.img in the "old way", you'll need about 15GB (template's max size + really used space there) in dom0 for this operation: Start the template, fill all the free space with zeros, for example with: -{% highlight trac-wiki %} +``` dd if=/dev/zero of=/var/tmp/zero (wait for "No space left on device" error) rm -f /var/tmp/zero -{% endhighlight %} +``` Then shutdown template and all VMs based on it. Go into template directory in dom0 (/var/lib/qubes/vm-templates/fedora-20-x64 or so) and issue: -{% highlight trac-wiki %} +``` cp --sparse=always root.img root.img.new mv root.img.new root.img -{% endhighlight %} +``` Done. diff --git a/Fetchmail.md b/Fetchmail.md index 7c35a6b8..a4a06dbf 100644 --- a/Fetchmail.md +++ b/Fetchmail.md @@ -24,7 +24,7 @@ Assuming you have more than one account (safe assumption these days), you need t In TemplateVM create `/etc/systemd/system/fetchmail@.service`: -{% highlight trac-wiki %} +``` [Unit] Description=Mail Retrieval Agent After=network.target @@ -34,11 +34,11 @@ Requires=postfix.service User=user ExecStart=/bin/fetchmail -f /usr/local/etc/fetchmail/%I.rc -d 60 -i /usr/local/etc/fetchmail/.%I.fetchids --pidfile /usr/local/etc/fetchmail/.%I.pid RestartSec=1 -{% endhighlight %} +``` Then shutdown TemplateVM, start AppVM and create directory `/usr/local/etc/fetchmail`. In it, create one `.rc` file for each instance of fetchmail, ie. `personal1.rc` and `personal2.rc`. Sample configuration file: -{% highlight trac-wiki %} +``` set syslog set no bouncemail #set daemon 600 @@ -57,13 +57,13 @@ user woju pass supersecret idle # vim: ft=fetchmail -{% endhighlight %} +``` Then `chown -R user:user /usr/local/etc/fetchmail` and `chmod 600 /usr/local/etc/fetchmail/*.rc`. **This is important**, fetchmail will refuse to run with wrong permissions on its rc-file. Next, add this to `/rw/config/rc.local`: -{% highlight trac-wiki %} +``` #!/bin/sh for rc in /usr/local/etc/fetchmail/*.rc; do @@ -71,6 +71,6 @@ for rc in /usr/local/etc/fetchmail/*.rc; do instance=${instance##*/} echo systemctl --no-block start fetchmail@${instance} done -{% endhighlight %} +``` Now reboot your AppVM and you are done. diff --git a/FullScreenMode.md b/FullScreenMode.md index 11ff817d..7078f4b9 100644 --- a/FullScreenMode.md +++ b/FullScreenMode.md @@ -30,19 +30,19 @@ If you want to enable full screen mode for select VMs, you can do that by creati **Note:** There should be only one `VM: {}` block in the file (or you will [get into problems](https://groups.google.com/d/msg/qubes-users/-Yf9yNvTsVI/xXsEm8y2lrYJ)) -{% highlight trac-wiki %} +``` VM: { personal: { allow_fullscreen = true; }; }; -{% endhighlight %} +``` The string 'personal' above is exemplary and should be replaced by the actual name of the VM for which you want to enable this functionality. One can also enable this functionality for all the VMs globally in the same file, by modifying the 'global' section: -{% highlight trac-wiki %} +``` global: { # default values allow_fullscreen = true; @@ -51,6 +51,6 @@ global: { #secure_paste_sequence = "Ctrl-Shift-v"; #windows_count_limit = 500; }; -{% endhighlight %} +``` Be sure to restart the VM(s) after modifying this file, for the changes to take effect. diff --git a/GUIdocs.md b/GUIdocs.md index 4bc6f56c..32b091d9 100644 --- a/GUIdocs.md +++ b/GUIdocs.md @@ -100,7 +100,7 @@ Window manager hints and flags are described at [http://standards.freedesktop.or Each message starts with the following header -{% highlight trac-wiki %} +``` struct msghdr { uint32_t type; uint32_t window; @@ -111,7 +111,7 @@ struct msghdr { * whatever it wants! */ uint32_t untrusted_len; }; -{% endhighlight %} +``` The header is followed by message-specific data. @@ -183,12 +183,12 @@ Proper handling of the below messages is NOT security-critical. Each message starts with the following header -{% highlight trac-wiki %} +``` struct msghdr { uint32_t type; uint32_t window; }; -{% endhighlight %} +``` The header is followed by message-specific data. ` KEYPRESS, BUTTON, MOTION, FOCUS ` messages pass information extracted from dom0 XEvent; see appropriate event documentation. diff --git a/GettingStarted.md b/GettingStarted.md index bb771d17..aa9691cb 100644 --- a/GettingStarted.md +++ b/GettingStarted.md @@ -55,15 +55,15 @@ By default, each domain's menu contains only a few shortcuts. If you'd like to a To start apps from the console in dom0, type: -{% highlight trac-wiki %} +``` qvm-run -a " [arguments]" -{% endhighlight %} +``` e.g.: -{% highlight trac-wiki %} +``` qvm-run -a untrusted firefox -{% endhighlight %} +``` Adding, Removing, and Listing Domains ------------------------------------- @@ -96,7 +96,7 @@ To allow domains to enter full screen mode, one should edit the `/etc/qubes/guid E.g. to allow all domains to enter full screen mode, set `allow_fullscreen` flag to `true` in the `global` section: -{% highlight trac-wiki %} +``` global: { # default values allow_fullscreen = false; @@ -105,18 +105,18 @@ global: { #secure_paste_sequence = "Ctrl-Shift-v"; #windows_count_limit = 500; }; -{% endhighlight %} +``` To allow only select AppVMs to enter full screen mode, create a per-VM section, and set `allow_fullscreen` flag there to `true`: -{% highlight trac-wiki %} +``` VM: { work: { allow_fullscreen = true; }; }; -{% endhighlight %} +``` In order for the changes to take effect, restart the AppVM(s). diff --git a/HvmCreate.md b/HvmCreate.md index 9f9a9f46..b3cde776 100644 --- a/HvmCreate.md +++ b/HvmCreate.md @@ -20,23 +20,23 @@ Creating an HVM domain First, lets create a new HVM domain (use the --hvm switch to qvm-create, or choose HVM type in the Qubes Manager VM creation dialog box): -{% highlight trac-wiki %} +``` qvm-create win7 --hvm --label green -{% endhighlight %} +``` (Of course, the name of the domain ("win7"), as well as it's label ("green"), are just exemplary). Now, we need to install an OS inside this VM, this can done by attaching an installation ISO upon starting the VM (this currently can be done only from command line, but in the future we surely will added an option to do this also from the manager): -{% highlight trac-wiki %} +``` qvm-start win7 --cdrom=/usr/local/iso/win7_en.iso -{% endhighlight %} +``` The command above assumes the installation ISO was somehow transferred to Dom0, e.g. copied using `dd` command from an installation CDROM. If one wishes to use the actual physical media without copying it first to a file, then one can just pass `/dev/cdrom` as an argument to `--cdrom`: -{% highlight trac-wiki %} +``` qvm-start win7 --cdrom=/dev/cdrom -{% endhighlight %} +``` Now, the VM will start booting from the attached CDROM device, which in the example above just happens to be the Windows 7 installation disk. Depending on the OS that is being installed in the VM, one might be required to start the VM several times (as is the case e.g. with Windows 7 installation), because whenever the installer wants to "reboot the system", it actually shutdowns the VM (and Qubes won't automatically start it), so several invocations of qvm-start command (as shown above) might be needed. @@ -47,16 +47,16 @@ Using Installation ISOs located in other VMs Sometimes one wants to download the installation ISO from the Web and use it for HVM creation. However, for security reasons, networking is disabled for Qubes Dom0, which makes it not possible to download an ISO within Dom0. Also Qubes do not provide any (easy to use) mechanisms for copying files between AppVMs and Dom0, and generally tries to discourage such actions. So, it would be inconvenient to require that the installation ISO for an HVM domain be always located in Dom0. And the good news is that this is indeed not required -- one can use the following syntax when specifying the location of /usr/local/iso/win7\_en.iso the installation ISO: -{% highlight trac-wiki %} +``` --cdrom=[appvm]:[/path/to/iso/within/appvm] -{% endhighlight %} +``` Assuming e.g. the an installation ISO named `ubuntu-12.10-desktop-i386.iso` has been downloaded in `work-web` AppVM, and located within `/home/user/Downloads` directory within this AppVM, one can immediately create a new HVM and use this ISO as an installation media with the following command (issued in Dom0, of course): -{% highlight trac-wiki %} +``` qvm-create --hvm ubuntu --label red qvm-start ubuntu --cdrom=work-web:/home/user/Downloads/ubuntu-12.10-desktop-i386.iso -{% endhighlight %} +``` Of course the AppVM where the ISO is kept must also be running for this to work (this VM is now serving the ISO and acting as a disk backend). @@ -93,7 +93,7 @@ Just like normal AppVMs, the HVM domains can also be cloned, either using a comm The cloned VM will get identical root and private image, and essentially will be identical to the original VM, except that it will get a different MAC address for the networking interface: -{% highlight trac-wiki %} +``` [joanna@dom0 ~]$ qvm-prefs win7 name : win7 label : green @@ -145,21 +145,21 @@ qrexec_installed : False qrexec timeout : 60 drive : None timezone : localtime -{% endhighlight %} +``` Note how the MAC addresses differ between those two, otherwise identical VMs. Of course, the IP addresses, assigned by Qubes, will also be different, to allow networking to function properly: -{% highlight trac-wiki %} +``` [joanna@dom0 ~]$ qvm-ls -n /.../ win7-copy | | Halted | Yes | | *firewallvm | green | 10.137.2.3 | n/a | 10.137.2.1 | win7 | | Halted | Yes | | *firewallvm | green | 10.137.2.7 | n/a | 10.137.2.1 | /.../ -{% endhighlight %} +``` If, for any reason, one would like to make sure that the two VMs have the same MAC address, one can use qvm-prefs to set a fixed MAC address for the VM: -{% highlight trac-wiki %} +``` [joanna@dom0 ~]$ qvm-prefs win7-copy -s mac 00:16:3E:5E:6C:05 [joanna@dom0 ~]$ qvm-prefs win7-copy name : win7-copy @@ -184,7 +184,7 @@ qrexec_installed : False qrexec timeout : 60 drive : None timezone : localtime -{% endhighlight %} +``` Please note that as of now Qubes does not support shared templates for HVM domains. This means that HVM domains cloned this way will have two separate copies of the whole filesystems. This has consequences in taking much more disk space compared to standard AppVMs that share the root fs with the Template VM. Another consequence is that it's probably not legal to clone a proprietary OS, such as Windows this way, unless your license specifically allows for that (even though Windows Activation won't complain when one sets identical MAC address for the cloned VMs, it's doubtful practice at best). @@ -211,22 +211,22 @@ Qubes Windows Support Tools are not open source and are distributed under a comm Because the Windows Support Tools are not licensed under a GPL license they are not distributed with Qubes installation ISO. Instead, one can download them when needed using the standard Qubes command for installing software in Dom0: -{% highlight trac-wiki %} +``` sudo qubes-dom0-update qubes-windows-tools -{% endhighlight %} +``` This should install `qubes-windows-tools-*.rpm` in your system, a package that brings an ISO with Windows Support Tools: -{% highlight trac-wiki %} +``` [joanna@dom0 ~]$ rpm -ql qubes-windows-tools-1-201211301354.noarch /usr/lib/qubes/qubes-windows-tools-201211301354.iso -{% endhighlight %} +``` Now, in order to install the tools in a Windows VM one should start the VM with the ISO attached: -{% highlight trac-wiki %} +``` qvm-start lab-win7 --cdrom=/usr/lib/qubes/qubes-windows-tools-201211301354.iso -{% endhighlight %} +``` Once the Windows VM boots, a CDROM should appear in the 'My Computer' menu (typically as `D:`) with a setup program in its main directory: @@ -242,25 +242,25 @@ After successful installation, the Windows VM must be shut down. Additionally, once should inform Qubes that tools have been installed in this VM by setting the `qrexec_installed` flag in the VM's properties -- this can be done using the `qvm-prefs` command in Dom0, e.g.: -{% highlight trac-wiki %} +``` qvm-prefs lab-win7 -s qrexec_installed true -{% endhighlight %} +``` Also, by default Qubes assumes that the default user in the Windows VM is named `user` -- if one has chosen a different user during Windows installation, Qubes should be informed about this by setting the `default_user` property for the VM, e.g.: -{% highlight trac-wiki %} +``` qvm-prefs lab-win7 -s default_user joanna -{% endhighlight %} +``` If everything went fine (please remember about the need to reboot the Windows VM after installation of the tools), one can run some simple tests to see if qrexec service runs fine with this VM, e.g.: -{% highlight trac-wiki %} +``` qvm-run lab-win7 calc -{% endhighlight %} +``` ... or something more fancy (a "networkless" telnet to Windows ;): -{% highlight trac-wiki %} +``` [joanna@dom0 ~]$ qvm-run lab-win7 -p cmd.exe Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. @@ -283,7 +283,7 @@ dir c:\ C:\Windows\system32>exit exit -{% endhighlight %} +``` Another things to check are if clipboard copy/paste and file copy works fine with this VM. If it doesn't, then perhaps one more VM reboot is necessary (seriously, hey this is Windows!). diff --git a/InstallNvidiaDriver.md b/InstallNvidiaDriver.md index 38816b74..822dffb7 100644 --- a/InstallNvidiaDriver.md +++ b/InstallNvidiaDriver.md @@ -17,19 +17,19 @@ There are rpm packages with all necessary software on rpmfusion. The only packag You will need any Fedora 18 system to download and build packages. You can use Qubes AppVM for it, but it isn't necessary. To download packages from rpmfusion - add this repository to your yum configuration (instructions are on their website). Then download packages using yumdownloader: -{% highlight trac-wiki %} +``` yumdownloader --resolve xorg-x11-drv-nvidia yumdownloader --source nvidia-kmod -{% endhighlight %} +``` ###Build kernel package You will need at least kernel-devel (matching your Qubes dom0 kernel), rpmbuild tool and kmodtool, and then you can use it to build package: -{% highlight trac-wiki %} +``` yum install kernel-devel rpm-build kmodtool rpmbuild --nodeps -D "kernels `uname -r`" --rebuild nvidia-kmod-260.19.36-1.fc13.3.src.rpm -{% endhighlight %} +``` In above command replace `uname -r` with kernel version from your Qubes dom0. If everything went right, you have now complete packages with nvidia drivers for Qubes system. Transfer them to dom0 (eg using USB stick) and install (using standard "yum install /path/to/file"). @@ -37,15 +37,15 @@ Then you need to disable nouveau (normally it is done by install scripts from nv Edit /etc/default/grub: - {% highlight trac-wiki %} + ``` GRUB_CMDLINE_LINUX="quiet rhgb nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off" - {% endhighlight %} + ``` Regenerate grub configuration: - {% highlight trac-wiki %} + ``` grub2-mkconfig -o /boot/grub2/grub.cfg - {% endhighlight %} + ``` Reboot. @@ -65,9 +65,9 @@ See [this page](/doc/CopyToDomZero/) for instructions on how to transfer files t Install libraries, Xorg driver, configuration utilities. This can by done by nvidia-installer: -{% highlight trac-wiki %} +``` ./NVIDIA-Linux-x86_64-260.19.44.run --ui=none --no-x-check --keep --no-nouveau-check --no-kernel-module -{% endhighlight %} +``` ###Kernel module @@ -85,21 +85,21 @@ This installation must be done manually, because nvidia-installer refused to ins If all the files are not there correct the errors manually. To build kernel module, enter *NVIDIA-Linux-x86\_64-260.19.44/kernel* directory and execute: -{% highlight trac-wiki %} +``` make IGNORE_XEN_PRESENCE=1 CC="gcc -DNV_VMAP_4_PRESENT -DNV_SIGNAL_STRUCT_RLIM" make -f Makefile.kbuild mv /lib/modules/2.6.34.1-12.xenlinux.qubes.x86_64/kernel/drivers/video/nvidia.ko /lib/modules/2.6.34.1-12.xenlinux.qubes.x86_64/extra/ -{% endhighlight %} +``` Ignore any errors while inserting nvidia.ko (at the end of make phase). ###Disable nouveau: -{% highlight trac-wiki %} +``` cat /etc/modprobe.d/nouveau-disable.conf # blacklist isn't enough... install nouveau /bin/true -{% endhighlight %} +``` Add *rdblacklist=nouveau* option to /boot/grub/menu.lst (at the end of line containing *vmlinuz*). @@ -107,11 +107,11 @@ Add *rdblacklist=nouveau* option to /boot/grub/menu.lst (at the end of line cont After all, you should configure Xorg to use nvidia driver. You can use *nvidia-xconfig* or do it manually: -{% highlight trac-wiki %} +``` X -configure mv /root/xorg.conf.new /etc/X11/xorg.conf # replace Driver in Device section by "nvidia" -{% endhighlight %} +``` diff --git a/InstallationIsoBuilding.md b/InstallationIsoBuilding.md index f8f0fc9a..2c942a6e 100644 --- a/InstallationIsoBuilding.md +++ b/InstallationIsoBuilding.md @@ -17,10 +17,10 @@ Build installer packages Get [Qubes Installer repository](http://git.qubes-os.org/?p=smoku/installer) and build its packages: -{% highlight trac-wiki %} +``` cd installer make rpms -{% endhighlight %} +``` Packages will be in `rpm/noarch` and `rpm/x86_64`. @@ -29,10 +29,10 @@ Install Revisor Next install the freshly built revisor and anaconda: -{% highlight trac-wiki %} +``` yum install rpm/noarch/revisor*.rpm yum install rpm/x86_64/anaconda*.rpm -{% endhighlight %} +``` Review configuration files -------------------------- @@ -68,18 +68,18 @@ The ```build/yum/dom0-updates``` is to be used for select rpms that should also Update your local repos: -{% highlight trac-wiki %} +``` make update-repo -{% endhighlight %} +``` Build ISO --------- Now you're finally ready to build the ISO image: -{% highlight trac-wiki %} +``` make iso -{% endhighlight %} +``` and wait... diff --git a/KdeDom0.md b/KdeDom0.md index f21b6f48..2446e1fc 100644 --- a/KdeDom0.md +++ b/KdeDom0.md @@ -13,9 +13,9 @@ The Qubes kde-dom0 project (see [Source Code](/doc/SourceCode/)) contains the so Getting the sources ------------------- -{% highlight trac-wiki %} +``` git clone git://qubes-os.org/mainstream/kde-dom0.git kde-dom0 -{% endhighlight %} +``` Building the packages --------------------- @@ -24,27 +24,27 @@ It's best to use Fedora 12 or 13 as a development system. First, you should download and verify the original KDE sources (not part of the kde-dom0 repository): -{% highlight trac-wiki %} +``` make get-sources verify-sources -{% endhighlight %} +``` Now, check if you have all the required build dependencies: -{% highlight trac-wiki %} +``` make prep -{% endhighlight %} +``` Install any required packages that `make` might have complained about. Then you're ready to build the rpms (you might want to adjust the release of each rpm package by editing the `rel` variable at the beginning of each `.spec` file): -{% highlight trac-wiki %} +``` make rpms -{% endhighlight %} +``` **Note:** The `kdebase-*` packages build process requires corresponding `kdelibs-devel` package to be installed first. If your build system is based on Fedora 12/13, and if the `kdelibs-devel` package exist in Fedora repo that is based the same KDE software version (e.g. 4.4.3) as the KDE packages you're building (see the `version` file), than you should be able to use the Fedora package: -{% highlight trac-wiki %} +``` yum install kdelibs-devel-{version} -{% endhighlight %} +``` If not, then you should build your `kdelibs-devel` first (`cd kdelibs-devel && make rpms`), then install it on your build system, and then you can build all the rest (`make rpms`). diff --git a/LinuxHVMTips.md b/LinuxHVMTips.md index 5a3db991..0f2f47cf 100644 --- a/LinuxHVMTips.md +++ b/LinuxHVMTips.md @@ -20,24 +20,24 @@ To achieve it (all commands run as root): 1. Generate XOrg configuratio (if you don't have it): - {% highlight trac-wiki %} + ``` X -configure :1 && mv ~/xorg.conf.new /etc/X11/xorg.conf - {% endhighlight %} + ``` 2. Add HorizSync line to Monitor section, it should look something like: - {% highlight trac-wiki %} + ``` Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "Monitor Model" HorizSync 30.0 - 60.0 EndSection - {% endhighlight %} + ``` 3. Change driver to "vesa" in Device section: - {% highlight trac-wiki %} + ``` Section "Device" # (...) Identifier "Card0" @@ -46,7 +46,7 @@ To achieve it (all commands run as root): BoardName "Unknown Board" BusID "PCI:0:2:0" EndSection - {% endhighlight %} + ``` Now you should get at least 1280x1024 and be able to choose other modes. diff --git a/Mutt.md b/Mutt.md index a86aad17..7b797dc0 100644 --- a/Mutt.md +++ b/Mutt.md @@ -33,7 +33,7 @@ Mutt generally works out of the box. This configuration guide discusses only Qub First, paste this to `/etc/Muttrc.local` in TemplateVM: -{% highlight trac-wiki %} +``` # specify your key or override in ~/.mutt/muttrc in AppVM set pgp_sign_as="0xDEADBEEF" @@ -105,11 +105,11 @@ send-hook "~A" set pgp_autoinline=no crypt_autoencrypt=no send-hook "~t @invisiblethingslab\.com" set crypt_autoencrypt=yes # vim:ft=muttrc -{% endhighlight %} +``` Then shutdown your TemplateVM. Next open your AppVM, create file `/home/user/.mutt/muttrc` and adjust for your needs: -{% highlight trac-wiki %} +``` # # accounts # @@ -134,14 +134,14 @@ subscribe (qubes-(users|devel)|othergroup)@googlegroups\.com fcc-save-hook qubes-users@googlegroups\.com =list/qubes-users/ fcc-save-hook qubes-devel@googlegroups\.com =list/qubes-devel/ fcc-save-hook othergroup@googlegroups\.com =list/othergroup/ -{% endhighlight %} +``` You may also create `/home/user/.signature`: -{% highlight trac-wiki %} +``` regards, Wojciech Porczyk -{% endhighlight %} +``` Some additional useful settings ------------------------------- diff --git a/NetworkBridgeSupport.md b/NetworkBridgeSupport.md index 469c2a15..3035f076 100644 --- a/NetworkBridgeSupport.md +++ b/NetworkBridgeSupport.md @@ -22,20 +22,20 @@ Qubes manager patch (Qubes R2B2) The following patches can be applied to the Qubes Manager GUI in order to add an option to easily bridge a VM. Use it at your own risk. If the patch breaks the Qubes Manager, you can try to restore the qubes packages: -{% highlight trac-wiki %} +``` # qubes-dom-update qubes-core-dom0 qubes-manager # yum reinstall qubes-core-dom0 # yum reinstall qubes-manager -{% endhighlight %} +``` First, retrieve the attachment of this Wifi article in dom0. Then apply the three patches the following way after installing the patch tool : -{% highlight trac-wiki %} +``` # qubes-dom0-update patch # patch /usr/lib64/python2.7/site-package/qubes/qubes.py < qubes.py-bridge.diff # patch /usr/lib64/python2.7/site-package/qubesmanager/settings.py < settings.py-bridge.diff # patch /usr/lib64/python2.7/site-package/qubesmanager/ui_settingsdlg.py < ui_settingsdlg.py-bridge.diff -{% endhighlight %} +``` Finally restart the qubes manager GUI. @@ -50,7 +50,7 @@ Modify manually the Template you use for your NetVM (not the NetVM itself). This - Starting from the line -A POSTROUTING -j MASQUERADE that you need to comment : - {% highlight trac-wiki %} + ``` # Bridge support # Comment the following line #-A POSTROUTING -j MASQUERADE @@ -59,26 +59,26 @@ Modify manually the Template you use for your NetVM (not the NetVM itself). This # Allow redirection of bridge packets (optional as POSTROUTING default is ACCEPT) #-A POSTROUTING -o bridge+ -j ACCEPT # End Bridge support - {% endhighlight %} + ``` - Starting from the line -A FORWARD -i vif+ -j ACCEPT: - {% highlight trac-wiki %} + ``` -A FORWARD -i vif+ -o vif+ -j DROP -A FORWARD -i vif+ -j ACCEPT # Bridge Support -A FORWARD -i bridge+ -j ACCEPT # End Bridge Support -A FORWARD -j DROP - {% endhighlight %} + ``` Ensure that the IP addresses used by default in qubes are in the form 10.137.1.\* or 10.137.2.\* by running ifconfig. Of course, this setup won't work with IPv6. Now you need to restart the NetVM and FirewallVM or only iptables in both VMs if you prefer: -{% highlight trac-wiki %} +``` # systemctl restart iptables -{% endhighlight %} +``` Create a Bridge inside the NetVM -------------------------------- @@ -96,7 +96,7 @@ The bridge edition GUI is somehow buggy as it does not remember all the paramete - Bridge-DHCP - {% highlight trac-wiki %} + ``` [connection] id=Bridge-DHCP uuid=fd68198b-313a-47cb-9155-52e95cdc67f3 @@ -113,13 +113,13 @@ The bridge edition GUI is somehow buggy as it does not remember all the paramete [bridge] interface-name=bridge0 stp=false - {% endhighlight %} + ``` Note: Do not forget to put stp=false if you bridge only eth0 because sending BPDUs could make your admins angry :) - bridge0-eth0 - {% highlight trac-wiki %} + ``` [802-3-ethernet] duplex=full mac-address=88:AE:1D:AE:30:31 @@ -132,12 +132,12 @@ Note: Do not forget to put stp=false if you bridge only eth0 because sending BPD timestamp=1363601650 master=fd68198b-313a-47cb-9155-52e95cdc67f3 slave-type=bridge - {% endhighlight %} + ``` If you do not manager to start your bridge, you can start it manually from a NetVM terminal: -{% highlight trac-wiki %} +``` $ nmcli con up id bridge0-eth0 -{% endhighlight %} +``` Now that the bridge is ready, the bridged AppVM can be started... diff --git a/NvidiaTroubleshooting.md b/NvidiaTroubleshooting.md index 71a560fd..60ddbc1a 100644 --- a/NvidiaTroubleshooting.md +++ b/NvidiaTroubleshooting.md @@ -22,15 +22,15 @@ Assuming your X Window System works fine now when you booted from the "failsafe" 1. Switch to runlevel 3 (this should kill your X server): -{% highlight trac-wiki %} +``` init 3 -{% endhighlight %} +``` 1. Run X-autoconfiguration: -{% highlight trac-wiki %} +``` Xorg -configure -{% endhighlight %} +``` This should generate a file `xorg.conf.new` in the `/root` directory. @@ -40,29 +40,29 @@ In most cases you can ignore any warning or error messages displayed by the X se - Uncomment the ShadowFB option, so that you should now have something like this: - {% highlight trac-wiki %} + ``` Option "ShadowFB" # [] - {% endhighlight %} + ``` - Change the driver name to `nouveau` (you will probably have `nv` written there): - {% highlight trac-wiki %} + ``` Driver "nouveau" - {% endhighlight %} + ``` Save the modification, exit the editor. 1. Move the file to `/etc/X11` and rename it as `xorg.conf`: -{% highlight trac-wiki %} +``` mv /root/xorg.conf.new /etc/X11/xorg.conf -{% endhighlight %} +``` 1. Verify that X will work with those new settings: -{% highlight trac-wiki %} +``` xinit -{% endhighlight %} +``` If you see a terminal window in the top left corner, it means you most likely succeeded, even if your keyboard or mouse do not work now (don't worry about them). diff --git a/OutOfmemory.md b/OutOfmemory.md index b4bc7717..bee0c1b7 100644 --- a/OutOfmemory.md +++ b/OutOfmemory.md @@ -9,18 +9,18 @@ VMs specially templates use disk space. Also default private storage max size is So it is a good practice to regularly check disk space usage with command -{% highlight trac-wiki %} +``` df -{% endhighlight %} +``` in dom0 terminal. A system in out of space condition should be able to boot, but may be unable to load a desktop manager. In this case it is possible to login to dom0 terminal with Alt + Ctrl + F2. To recover disk space it may be possible to delete files in a userVM connecting to the userVM terminal: -{% highlight trac-wiki %} +``` qvm-start sudo xl console -{% endhighlight %} +``` If this does not work, check the size of /var/lib/qubes/qubes.xml. If it is zero, you'll need to use one of the file backup (stored in /var/lib/qubes/backup), hopefully you have the current data there. Find the most recent one and place in /var/lib/qubes/qubes.xml instead of the empty file. @@ -28,25 +28,25 @@ In any case you'll need some disk space to start the VM. Check "df" output if yo 1. Clean yum cache: -{% highlight trac-wiki %} +``` sudo yum clean all -{% endhighlight %} +``` 1. Delete .img files of a less important VM, that can be found in /var/lib/qubes/appvms/. Then, when the system is working again, cleanup the rest with: -{% highlight trac-wiki %} +``` qvm-remove -{% endhighlight %} +``` With this method you lose one VM data, but it'll more securely work. 1. Decrease filesystem safety margin (5% by default): -{% highlight trac-wiki %} +``` sudo tune2fs -m 4 /dev/mapper/vg_dom0-lv_root -{% endhighlight %} +``` 1. Remove some unneeded files in dom0 home (if you have one, most likely no). diff --git a/Postfix.md b/Postfix.md index 77c73c7d..000157f7 100644 --- a/Postfix.md +++ b/Postfix.md @@ -22,9 +22,9 @@ Configuration In TemplateVM open `/etc/aliases` and add line: -{% highlight trac-wiki %} +``` root: user -{% endhighlight %} +``` and run `newaliases`. @@ -36,7 +36,7 @@ Now shutdown TemplateVM, start AppVM. Create directory `/usr/local/etc/postfix` Postfix keeps its lookup tables in bdb hash databases. They need to be compiled from source files. Postfix admins like to keep track of them by means of `/usr/local/etc/postfix/Makefile`: -{% highlight trac-wiki %} +``` all: $(addsuffix .db,$(shell sed -n -e '/^[^#].*hash:\/etc\/postfix/s:.*/::p' main.cf)) newaliases clean: @@ -45,13 +45,13 @@ clean: %.db: % /usr/sbin/postmap hash:$< -{% endhighlight %} +``` ### Postfix main configuration `/usr/local/etc/postfix/main.cf` (`/etc/postfix` is intentional, don't correct it): -{% highlight trac-wiki %} +``` mydestination = $myhostname, $myhostname.$mydomain, $myhostname.localdomain, localhost, localhost.$mydomain, localhost.localdomain, $mydomain, localdomain mynetworks_style = host @@ -84,36 +84,36 @@ sendmail_path = /usr/sbin/sendmail newaliases_path = /usr/bin/newaliases mailq_path = /usr/bin/mailq alias_maps = hash:/etc/aliases -{% endhighlight %} +``` ### Lookup tables `/usr/local/etc/postfix/generic` (put there your primary address): -{% highlight trac-wiki %} +``` @localhost your.mail@example.com -{% endhighlight %} +``` `/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. -{% highlight trac-wiki %} +``` your.mail@exmaple.com [mail.example.com]:submission your.other@mail.com [smtp.mail.com]:smtp -{% endhighlight %} +``` `/usr/local/etc/postfix/saslpass`. Here you put passwords to abovementioned servers. It depends on provider if you need to put whole email as username or just the part before `@`. -{% highlight trac-wiki %} +``` [mail.example.com]:submission your.mail:y0urP4ssw0rd [smtp.mail.com]:smtp your.other@mail.com:supers3cret -{% endhighlight %} +``` `/usr/local/etc/postfix/sender_access`. I use it to nullroute known spam domains. If you do not need it, comment respective line in `main.cf`. -{% highlight trac-wiki %} +``` spamdomain1.com DISCARD spamdomain2.com DISCARD -{% endhighlight %} +``` Now run `make` in `/usr/local/etc/postfix`. It will hopefully compile four abovementioned lookup tables (`generic.db`, `sender_relay.db`, `saslpass.db` and `sender_access`). @@ -121,7 +121,7 @@ Now run `make` in `/usr/local/etc/postfix`. It will hopefully compile four above Don't start postfix or fetchmail yet, first create `/home/user/.procmailrc`: -{% highlight trac-wiki %} +``` MAILDIR = "${HOME}/.maildir" ORGMAIL = "${MAILDIR}/" DEFAULT = "${MAILDIR}/" @@ -133,18 +133,18 @@ list/qubes-users/ :0 * ^List-Id:.*qubes-devel\.googlegroups\.com list/qubes-devel/ -{% endhighlight %} +``` Run --- Open `/rw/config/rc.local` and add those two lines (before fetchmail lines, if you have them): -{% highlight trac-wiki %} +``` #!/bin/sh mount --bind /usr/local/etc/postfix /etc/postfix systemctl --no-block start postfix -{% endhighlight %} +``` Reboot your AppVM and you are done. diff --git a/Profiling.md b/Profiling.md index df0df114..4cd9b144 100644 --- a/Profiling.md +++ b/Profiling.md @@ -15,17 +15,17 @@ For the purpose of this document, `qubes-dev` is name of the domain used for pos Requirements ------------ -{% highlight trac-wiki %} +``` yum install gprof2dot graphviz git clone http://git.woju.eu/qubes/profiling.git -{% endhighlight %} +``` If you profile something on dom0, move `Upload.sh` from repository to dom0: -{% highlight trac-wiki %} +``` mkdir -p ~/profiling qvm-run -p qubes-dev 'cat ~/profiling/Upload.sh' > ~/profiling/Upload.sh -{% endhighlight %} +``` - WARNING: this will obviously be running third party code which is not signed by ITL nor Fedora. You have been warned. @@ -62,28 +62,28 @@ Remember to revert your changes to application afterwards. If you are in dom0: -{% highlight trac-wiki %} +``` cd ~/profiling ./Upload.sh -{% endhighlight %} +``` ### Analyse -{% highlight trac-wiki %} +``` make -{% endhighlight %} +``` For every `${basename}.pstats` this will produce `${basename}.txt` and `${basename}.svg`. SVG contains call graph. Text file contains list of all functions sorted by cumulative execution time. You may also try `make all-png`. -{% highlight trac-wiki %} +``` make index.html -{% endhighlight %} +``` This creates `index.html` with all SVG graphics linked to TXT files. Ready for upload. -{% highlight trac-wiki %} +``` make REMOTE=example.com:public_html/qubes/profiling/ upload -{% endhighlight %} +``` Example ------- diff --git a/Qrexec.md b/Qrexec.md index 36da6c19..e7345214 100644 --- a/Qrexec.md +++ b/Qrexec.md @@ -19,9 +19,9 @@ Typically, the first thing that a `qrexec-client` instance does is to send a req E.g., to start a primitive shell in a VM type the following in Dom0 console: -{% highlight trac-wiki %} +``` [user@dom0 ~]$ /usr/lib/qubes/qrexec-client -d user:bash -{% endhighlight %} +``` The string before first semicolon specifies what user to run the command as. @@ -65,9 +65,9 @@ In dom0, there is a bunch of files in `/etc/qubes-rpc/policy/` directory, whose These files contain lines with the following format: -{% highlight trac-wiki %} +``` srcvm destvm (allow|deny|ask)[,user=user_to_run_as][,target=VM_to_redirect_to] -{% endhighlight %} +``` You can specify `srcvm` and `destvm` by name, or by one of `$anyvm`, `$dispvm`, `dom0` reserved keywords (note string `dom0` does not match the `$anyvm` pattern; all other names do). Only `$anyvm` keyword makes sense in the `srcvm` field (service calls from dom0 are currently always allowed, `$dispvm` means "new VM created for this particular request" - so it is never a source of request). Currently, there is no way to specify source VM by type, but this is planned for Qubes R3. @@ -80,9 +80,9 @@ Requesting VM-VM (and VM-Dom0) services execution In a src VM, one should invoke the qrexec client via the following command: -{% highlight trac-wiki %} +``` /usr/lib/qubes/qrexec-client-vm [local program arguments]` -{% endhighlight %} +``` Note that only stdin/stdout is passed between RPC server and client - notably, no cmdline argument are passed. @@ -103,9 +103,9 @@ Qubes RPC policy supports an "ask" action, that will prompt the user whether a g In order to remove such authorization, issue this command from a Dom0 terminal (example below for qubes.Filecopy service): -{% highlight trac-wiki %} +``` sudo nano /etc/qubes-rpc/policy/qubes.Filecopy -{% endhighlight %} +``` and then remove any line(s) ending in "allow" (before the first \#\# comment) which are the "Yes to All" results. @@ -117,37 +117,37 @@ We will show the necessary files to create a simple RPC call that adds two integ - Client code on source VM (`/usr/bin/our_test_add_client`) -{% highlight trac-wiki %} +``` #!/bin/sh echo $1 $2 # pass data to rpc server exec cat >&$SAVED_FD_1 # print result to the original stdout, not to the other rpc endpoint -{% endhighlight %} +``` - Server code on target VM (`/usr/bin/our_test_add_server`) -{% highlight trac-wiki %} +``` #!/bin/sh read arg1 arg2 # read from stdin, which is received from the rpc client echo $(($arg1+$arg2)) # print to stdout - so, pass to the rpc client -{% endhighlight %} +``` - Policy file in dom0 (`/etc/qubes-rpc/policy/test.Add`) -{% highlight trac-wiki %} +``` $anyvm $anyvm ask -{% endhighlight %} +``` - Server path definition on target VM (`/etc/qubes-rpc/test.Add`) -{% highlight trac-wiki %} +``` /usr/bin/our_test_add_server -{% endhighlight %} +``` - To test this service, run the following in the source VM: -{% highlight trac-wiki %} +``` /usr/lib/qubes/qrexec-client-vm test.Add /usr/bin/our_test_add_client 1 2 -{% endhighlight %} +``` and we should get "3" as answer, provided dom0 policy allows the call to pass through, which would happen after we click "Yes" in the popup that should appear after the invocation of this command. If we changed the policy from "ask" to "allow", then no popup should be presented, and the call will always be allowed. diff --git a/Qrexec3.md b/Qrexec3.md index 0600946e..0c8abc98 100644 --- a/Qrexec3.md +++ b/Qrexec3.md @@ -87,37 +87,37 @@ We will show the necessary files to create rpc call that adds two integers on th - rpc client code (*/usr/bin/our\_test\_add\_client*) - {% highlight trac-wiki %} + ``` #!/bin/sh echo $1 $2 # pass data to rpc server exec cat >&$SAVED_FD_1 # print result to the original stdout, not to the other rpc endpoint - {% endhighlight %} + ``` - rpc server code (*/usr/bin/our\_test\_add\_server*) - {% highlight trac-wiki %} + ``` #!/bin/sh read arg1 arg2 # read from stdin, which is received from the rpc client echo $(($arg1+$arg2)) # print to stdout - so, pass to the rpc client - {% endhighlight %} + ``` - policy file in dom0 (*/etc/qubes-rpc/policy/test.Add* ) - {% highlight trac-wiki %} + ``` $anyvm $anyvm ask - {% endhighlight %} + ``` - server path definition ( */etc/qubes-rpc/test.Add*) - {% highlight trac-wiki %} + ``` /usr/bin/our_test_add_server - {% endhighlight %} + ``` - invoke rpc via - {% highlight trac-wiki %} + ``` /usr/lib/qubes/qrexec-client-vm target_vm test.Add /usr/bin/our_test_add_client 1 2 - {% endhighlight %} + ``` and we should get "3" as answer, after dom0 allows it. diff --git a/Qrexec3Implementation.md b/Qrexec3Implementation.md index 218cedb0..2bb2fc7c 100644 --- a/Qrexec3Implementation.md +++ b/Qrexec3Implementation.md @@ -66,21 +66,21 @@ Qrexec protocol details Qrexec protocol is message-based. All messages share a common header followed by an optional data packet. -{% highlight trac-wiki %} +``` /* uniform for all peers, data type depends on message type */ struct msg_header { uint32_t type; /* message type */ uint32_t len; /* data length */ }; -{% endhighlight %} +``` When two peers establish connection, the server sends `MSG_HELLO` followed by `peer_info` struct: -{% highlight trac-wiki %} +``` struct peer_info { uint32_t version; /* qrexec protocol version */ }; -{% endhighlight %} +``` The client then should reply with its own `MSG_HELLO` and `peer_info`. If protocol versions don't match, the connection is closed. TODO: fallback for backwards compatibility, don't do handshake in the same domain?. @@ -101,14 +101,14 @@ Details of all possible use cases and the messages involved are described below. - **dom0**: `qrexec-client` replies with `MSG_HELLO` header followed by `peer_info` to `qrexec-daemon`. - **dom0**: `qrexec-client` sends `MSG_EXEC_CMDLINE` header followed by `exec_params` to `qrexec-daemon` - {% highlight trac-wiki %} + ``` /* variable size */ struct exec_params { uint32_t connect_domain; /* target domain id */ uint32_t connect_port; /* target vchan port for i/o exchange */ char cmdline[0]; /* command line to execute, size = msg_header.len - sizeof(struct exec_params) */ }; - {% endhighlight %} + ``` In this case, `connect_domain` and `connect_port` are set to 0. @@ -133,7 +133,7 @@ Details of all possible use cases and the messages involved are described below. - **domY**: `qrexec-client-vm` connects to `qrexec-agent` (via local socket/named pipe). - **domY**: `qrexec-client-vm` sends `trigger_service_params` data to `qrexec-agent` (without filling the `request_id` field): - {% highlight trac-wiki %} + ``` struct trigger_service_params { char service_name[64]; char target_domain[32]; @@ -143,7 +143,7 @@ Details of all possible use cases and the messages involved are described below. struct service_params { char ident[32]; }; - {% endhighlight %} + ``` - **domY**: `qrexec-agent` allocates a locally-unique (for this domain) `request_id` (let's say `13`) and fills it in the `trigger_service_params` struct received from `qrexec-client-vm`. - **domY**: `qrexec-agent` sends `MSG_TRIGGER_SERVICE` header followed by `trigger_service_params` to `qrexec-daemon` in **dom0** via vchan. @@ -159,14 +159,14 @@ Details of all possible use cases and the messages involved are described below. - **dom0**: `qrexec-client` replies with `MSG_HELLO` header followed by `peer_info` to **domX**'s`qrexec-daemon`. - **dom0**: `qrexec-client` sends `MSG_EXEC_CMDLINE` header followed by `exec_params` to **domX**'s`qrexec-daemon` - {% highlight trac-wiki %} + ``` /* variable size */ struct exec_params { uint32_t connect_domain; /* target domain id */ uint32_t connect_port; /* target vchan port for i/o exchange */ char cmdline[0]; /* command line to execute, size = msg_header.len - sizeof(struct exec_params) */ }; - {% endhighlight %} + ``` In this case, `connect_domain` is set to id of **domY** (from the `-c` parameter) and `connect_port` is set to 0. `cmdline` field contains the RPC to execute, in this case `user:QUBESRPC qubes.SomeRpc domY`. diff --git a/QubesBuilder.md b/QubesBuilder.md index 2a74dd9f..3dc36153 100644 --- a/QubesBuilder.md +++ b/QubesBuilder.md @@ -26,15 +26,15 @@ In order to use it one should use an rpm-based distro, like Fedora :) and should Unusually one can install those packages by just issuing: -{% highlight trac-wiki %} +``` sudo yum install git createrepo rpm-build make wget rpmdevtools python-sh dialog rpm-sign -{% endhighlight %} +``` The build system creates build environments in chroots and so no other packages are needed on the host. All files created by the build system are contained within the qubes-builder directory. The full build requires some 25GB of free space, so keep that in mind when deciding where to place this directory. The build system is configured via builder.conf file -- one should copy the attached builder.conf.default, and modify it as needed, e.g.: -{% highlight trac-wiki %} +``` cp builder.conf.default builder.conf # edit the builder.conf file and set the following variables: # (make sure to leave no spaces around '=' sign!) @@ -44,23 +44,23 @@ NO_SIGN=1 # and VMs is fc20 so if you want to build Qubes 2 DIST_DOM0=fc20 DISTS_VM=fc20 -{% endhighlight %} +``` One additional useful requirement is that 'sudo root' work without any prompt, which is default on most distros (e.g. 'sudo bash' brings you the root shell without asking for any password). This is important as the builder needs to switch to root and then back to user several times during the build process. Additionally, if building with signing enabled (so NO\_SIGN is not set), one must adjust \~/.rpmmacro file so that it point to the GPG key used for package signing, e.g.: -{% highlight trac-wiki %} +``` %_signature gpg %_gpg_path /home/user/.gnupg %_gpg_name AC1BF9B3 # <-- Key ID used for signing -{% endhighlight %} +``` It is also recommended to use an empty passphrase for the private key used for signing. Contrary to a popular belief, this doesn't affect your key or sources security -- if somebody compromised your system, then the game is over, whether you use additional passphrase for the key or not. So, to build Qubes one would do: -{% highlight trac-wiki %} +``` # Import the Qubes master key gpg --recv-keys 0x36879494 @@ -90,7 +90,7 @@ make qubes # ... and then to build the ISO make iso -{% endhighlight %} +``` And this should produce a shiny new ISO. @@ -128,9 +128,9 @@ If you want to somehow modify sources, you can also do it, here are some basic s > `get-sources` is already done, so continue with the next one. You can skip `sign-all` if you've disabled signing > -> {% highlight trac-wiki %} +> ``` > make xen core kernel gui addons docs template kde-dom0 installer qubes-manager dom0-updates -> {% endhighlight %} +> ``` 1. build iso installation image @@ -141,11 +141,11 @@ Code verification keys management [QubesBuilder](/doc/QubesBuilder/) by default verifies signed tags on every downloaded code. Public keys used for that are stored in `keyrings/git`. By default Qubes developers' keys are imported automatically, but if you need some additional keys (for example your own), you can add them using: -{% highlight trac-wiki %} +``` GNUPGHOME=$PWD/keyrings/git gpg --import /path/to/key.asc GNUPGHOME=$PWD/keyrings/git gpg --edit-key ID_OF_JUST_IMPORTED_KEY # here use "trust" command to set key fully or ultimately trusted - only those keys are accepted by QubesBuilder -{% endhighlight %} +``` All Qubes developers' keys are signed by the Qubes Master Signing Key (which is set as ultimately trusted key), so are trusted automatically. diff --git a/QubesFirewall.md b/QubesFirewall.md index d9431769..63f9ca09 100644 --- a/QubesFirewall.md +++ b/QubesFirewall.md @@ -34,15 +34,15 @@ Reconnecting AppVMs after a NetVM reboot Normally Qubes doesn't let the user to stop a NetVM if there are other AppVMs running which use it as their own NetVM. But in case the NetVM stops for whatever reason (e.g. it crashes, or the user forces its shutdown via qvm-kill via terminal in the netvm), then there is an easy way to restore the connection to the netvm by issuing: -{% highlight trac-wiki %} +``` qvm-prefs -s netvm -{% endhighlight %} +``` Normally AppVMs do not connect directly to the actual NetVM which has networking devices, but rather to the default FirewallVM first, and in most cases it would be the NetVM that would crash, e.g. in response to S3 sleep/restore or other issues with WiFi drivers. In that case it is necessary to just issue the above command once, for the FirewallVM (this assumes default VM-nameing used by the default Qubes installation): -{% highlight trac-wiki %} +``` qvm-prefs firewallvm -s netvm netvm -{% endhighlight %} +``` Enabling networking between two AppVMs -------------------------------------- @@ -56,18 +56,18 @@ In order to allow networking between AppVM A and B follow those steps: - Start both AppVMs, and also open a terminal in the firewall VM - In the firewall VM's terminal enter the following iptables rule: - {% highlight trac-wiki %} + ``` sudo iptables -I FORWARD 2 -s -d -j ACCEPT - {% endhighlight %} + ``` - Now you should be able to reach the AppVM B from A -- test it using e.g. ping issues from AppVM A. Note however, that this doesn't allow you to reach A from B -- for this you would need another rule, with A and B addresses swapped. - If everything works as expected, then the above iptables rule(s) should be written into firewall VM's `qubes_firewall_user_script` script which is run on every firewall update. This is necessary, because Qubes orders every firewall VM to update all the rules whenever new VM is started in the system. If we didn't enter our rules into this "hook" script, then shortly our custom rules would disappear and inter-VM networking would stop working. Here's an example how to update the script (note that, by default, there is no script file present, so we likely will be creating it, unless we had some other custom rules defines earlier in this firewallvm): - {% highlight trac-wiki %} + ``` [user@firewallvm ~]$ sudo bash [root@firewallvm user]# echo "iptables -I FORWARD 2 -s 10.137.2.25 -d 10.137.2.6 -j ACCEPT" >> /rw/config/qubes_firewall_user_script [root@firewallvm user]# chmod +x /rw/config/qubes_firewall_user_script - {% endhighlight %} + ``` Port forwarding to an AppVM from the outside world -------------------------------------------------- @@ -90,15 +90,15 @@ In NetVM terminal, take note of the interface name and IPAddress on which you wa Still in NetVM terminal, code the appropriate natting firewall rule to intercept traffic on the inbound interface for the service and nat the destination IP address to the one of the firewallVM for the traffic to be routed there: -{% highlight trac-wiki %} +``` iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.0.10 -j DNAT --to-destination 10.137.1.x -{% endhighlight %} +``` Code the appropriate new filtering firewall rule to allow new connections for the service: -{% highlight trac-wiki %} +``` iptables -I FORWARD 2 -i eth0 -d 10.137.1.x -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT -{% endhighlight %} +``` Note: If you want to expose the service on multiple interfaces, repeat the steps described in part 1 for each interface. @@ -114,23 +114,23 @@ In order to ensure your set-up survive a reboot we need in the NetVM to: Store these commands in ` /rw/config/rc.local `: -{% highlight trac-wiki %} +``` sudo nano /rw/config/rc.local -{% endhighlight %} +``` -{% highlight trac-wiki %} +``` #!/bin/sh /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 192.168.0.10 -j DNAT --to-destination 10.137.1.x /sbin/iptables -I FORWARD 2 -s 192.168.0.0/24 -d 10.137.1.x -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT -{% endhighlight %} +``` Make this file executable: -{% highlight trac-wiki %} +``` sudo chmod +x /rw/config/rc.local -{% endhighlight %} +``` **2. Allow packets to be routed from the firewallVM to the appVM** @@ -140,15 +140,15 @@ In FirewallVM Terminal, take note of the IPAddress for interface eth0 using the Still in FirewallVM terminal, code the appropriate natting firewall rule to intercept traffic on the inbound interface for the service and nat the destination IP address to the one of the AppVM for the traffic to be routed there: -{% highlight trac-wiki %} +``` iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.x -j DNAT --to-destination 10.137.2.y -{% endhighlight %} +``` Code the appropriate new filtering firewall rule to allow new connections for the service: -{% highlight trac-wiki %} +``` iptables -I FORWARD 2 -i eth0 -s 192.168.0.0/24 -d 10.137.2.y -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT -{% endhighlight %} +``` > Note: If you do not wish to limit the IP addresses connecting to the service, remove the ` -s 192.168.0.1/24 ` @@ -158,28 +158,28 @@ This time in order to ensure your set-up survive a reboot we need in the firewal Store these commands in ` /rw/config/qubes_firewall_user_script `: -{% highlight trac-wiki %} +``` #!/bin/sh /sbin/iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -d 10.137.1.x -j DNAT --to-destination 10.137.2.y /sbin/iptables -I FORWARD 4 -i eth0 -s 192.168.0.0/24 -d 10.137.2.y -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT -{% endhighlight %} +``` And again make this file executable: -{% highlight trac-wiki %} +``` sudo chmod +x /rw/config/qubes_firewall_user_script -{% endhighlight %} +``` **3. Allow packets into the AppVM to reach the service** Here no routing is required, only filtering. Proceed in the same way as above but store the filtering rule in the `/rw/config/rc.local` script. -{% highlight trac-wiki %} +``` #!/bin/sh /sbin/iptables -I INPUT 5 -p tcp --dport 443 -m conntrack --ctstate NEW -j ACCEPT -{% endhighlight %} +``` This time testing should allow connectivity to the service. diff --git a/QubesR3Building.md b/QubesR3Building.md index 2e6d63ce..7d371c77 100644 --- a/QubesR3Building.md +++ b/QubesR3Building.md @@ -10,47 +10,47 @@ Building Qubes OS 3.0 ISO Ensure your system is rpm-based and that you have necessary dependencies installed (see [QubesBuilder](/doc/QubesBuilder/) for more info): -{% highlight trac-wiki %} +``` sudo yum install git createrepo rpm-build make wget rpmdevtools pandoc -{% endhighlight %} +``` Get the necessary keys to verify the sources: -{% highlight trac-wiki %} +``` $ wget https://keys.qubes-os.org/keys/qubes-master-signing-key.asc $ gpg --import qubes-master-signing-key.asc $ gpg --edit-key 36879494 # Verify fingerprint!, set trust to *ultimate* $ wget https://keys.qubes-os.org/keys/qubes-developers-keys.asc $ gpg --import qubes-developers-keys.asc -{% endhighlight %} +``` Note we do *not* relay above on the security of our server (keys.qubes-os.org) nor the connection (ssl, cert) -- we only rely on you getting the Qubes Master Signing Key fingerprint *somehow* and ensure they match! Now lets bootstrap the builder. Unfortunately the builder cannot verify itself (the classic Chicken and Egg problem), so we need to verify the signature manually: -{% highlight trac-wiki %} +``` $ git clone git://github.com/QubesOS/qubes-builder.git $ cd qubes-builder $ git describe --exact-match HEAD $ git tag -v -{% endhighlight %} +``` Assuming the verification went fine, we're good to go with all the rest without ever thinking more about verifying digital signatures on all the rest of the components, as the builder will do that for us, for each component, every time we, even for all aux files (e.g. Xen or Linux kernel sources). Let's configure the builder first (we can use one of the example configs, either for R2 or "master", which currently means pre-released R3): -{% highlight trac-wiki %} +``` cp example-configs/qubes-os-master.conf builder.conf -{% endhighlight %} +``` You can take a loot at the `builder.conf.default` for a description of all available options. Nevertheless, the default config should be enough for start: -{% highlight trac-wiki %} +``` $ make get-sources qubes $ make sign-all # this requires setting SIGN_KEY in the builder.conf, can be skipped for test builds. $ make iso -{% endhighlight %} +``` Enjoy your new ISO! diff --git a/QubesService.md b/QubesService.md index 6e9044e7..4e826ae5 100644 --- a/QubesService.md +++ b/QubesService.md @@ -12,11 +12,11 @@ Under the hood enabled service in VM is signaled by file in /var/run/qubes-servi 1. Disable old service: `systemctl disable ` 2. Create `/etc/systemd/system/.service` file containing: - {% highlight trac-wiki %} + ``` .include /lib/systemd/system/.service [Unit] ConditionPathExists=/var/run/qubes-service/ - {% endhighlight %} + ``` 3. Enable new service: `systemctl enable `. diff --git a/ResizeDiskImage.md b/ResizeDiskImage.md index 508ef188..82848563 100644 --- a/ResizeDiskImage.md +++ b/ResizeDiskImage.md @@ -17,17 +17,17 @@ There are several disk images which can be easily extended. To grow the private disk image of a AppVM beyond this limit [qubes-grow-private](/doc/Dom0Tools/QvmGrowPrivate/) can be used: -{% highlight trac-wiki %} +``` qvm-grow-private -{% endhighlight %} +``` Note: Size is the target size (i.e. 4096MB or 16GB, ...), not the size to add to the existing disk. Note2: If once the VM is started, the disk is has not been increased, you can issue in the VM's terminal: -{% highlight trac-wiki %} +``` sudo resize2fs /dev/xvdb -{% endhighlight %} +``` ### Shrinking private disk image (Linux VM) @@ -40,14 +40,14 @@ The basic idea is to: 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: -{% highlight trac-wiki %} +``` qvm-prefs -s kernelopts rd.break qvm-start --no-guid -{% endhighlight %} +``` And wait for qrexec connect timeout (or simply press Ctrl-C). Then you can connect to VM console and shrink the filesystem: -{% highlight trac-wiki %} +``` sudo xl console # you should get dracut emergency shell here mount --bind /dev /sysroot/dev @@ -59,19 +59,19 @@ umount /proc exit umount /sysroot/dev poweroff -{% endhighlight %} +``` Now you can resize the image: -{% highlight trac-wiki %} +``` truncate -s /var/lib/qubes/appvms//private.img -{% endhighlight %} +``` **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: -{% highlight trac-wiki %} +``` qvm-prefs -s kernelopts default -{% endhighlight %} +``` Done. @@ -97,12 +97,12 @@ First, stop/shutdown the HVM. Then, from a Dom0 terminal (in KDE: System Tools -\> Terminal Emulator) do the following: -{% highlight trac-wiki %} +``` cd /var/lib/qubes/appvms// 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) -{% endhighlight %} +``` The partition table and file-system must be adjusted after this change: @@ -117,9 +117,9 @@ No reboot required. #### FreeBSD -{% highlight trac-wiki %} +``` gpart recover ada0 sysctl kern.geom.debugflags=0x10 gpart resize -i index ada0 zpool online -e poolname ada0 -{% endhighlight %} +``` diff --git a/Rxvt.md b/Rxvt.md index 237c2dd1..5b6a24f8 100644 --- a/Rxvt.md +++ b/Rxvt.md @@ -20,7 +20,7 @@ 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 neccessary. This shouldn't go to `/etc/X11/Xresources`, because that file is not preprocessed by default. -{% highlight trac-wiki %} +``` ! CGA colour palette !*color0: #000000 @@ -123,15 +123,15 @@ URxvt.insecure: False ! some termcap-aware software sometimes throw '$TERM too long' !URxvt.termName: rxvt-256color -{% endhighlight %} +``` Then create script to automatically merge those to xrdb. File `/etc/X11/xinit/xinitrc.d/urxvt.sh`: -{% highlight trac-wiki %} +``` #!/bin/sh [ -r /etc/X11/Xresources.urxvt ] && xrdb -merge /etc/X11/Xresources.urxvt -{% endhighlight %} +``` Shortcuts --------- diff --git a/SecurityGuidelines.md b/SecurityGuidelines.md index fe66c27d..aaabf8b9 100644 --- a/SecurityGuidelines.md +++ b/SecurityGuidelines.md @@ -29,17 +29,17 @@ Download Verification Standard program installation -{% highlight trac-wiki %} +``` sudo yum install -{% endhighlight %} +``` on template terminal already accomplishes verification, for fedora and qubes repositories. If you install new repositories, they might have gpgcheck disabled. [Check the config files](http://docs.fedoraproject.org/en-US/Fedora/12/html/Deployment_Guide/sec-Configuring_Yum_and_Yum_Repositories.html) and be sure to check that -{% highlight trac-wiki %} +``` gpgcheck=1 -{% endhighlight %} +``` Plus, also make sure you **safely import their signing keys**. This may require you check from multiple sources that the signing key is always the same. @@ -66,9 +66,9 @@ Enabling and Verifying VT-d/IOMMU In **Dom0** terminal, run: -{% highlight trac-wiki %} +``` qubes-hcl-report -{% endhighlight %} +``` where \ is the name of the VM within which the report will be written (but the report will also be displayed in the Dom0 terminal). If it displays that VT-d is active, you should be able to assign **PCIe devices to a HVM** and **enjoy DMA protection** for your driver domains, so you successfully passed this step. @@ -79,15 +79,15 @@ Updating Software To keep your system regularly updated against security related bugs and get new features, run in Dom0: -{% highlight trac-wiki %} +``` sudo qubes-dom0-update -{% endhighlight %} +``` and run in templates and standalone VM -{% highlight trac-wiki %} +``` sudo yum update -{% endhighlight %} +``` or use the equivalent items in Qubes Manager, which displays an icon when an update is available. @@ -145,9 +145,9 @@ An **USBVM** operates like a dedicated temporary parking area, used just to prev 5. Click OK. Restart the AppVM. (Restarting may not even be required.) 6. Set the VM to start automatically at Boot using the VM Manager, (under VM Settings), or **In dom0 terminal**, run - {% highlight trac-wiki %} + ``` qvm-prefs -s usbvm autostart true - {% endhighlight %} + ``` This will cause your new **USBVM** to automatically start when the system starts up. So that in case you forgot to start it and then accidentally plugged a USB stick (or your colleague at work did it while you were at lunch), **it won't compromise the Dom0**. diff --git a/SecurityPage.md b/SecurityPage.md index 8f3f4c96..362cbe42 100644 --- a/SecurityPage.md +++ b/SecurityPage.md @@ -21,9 +21,9 @@ Qubes Security Team The Qubes Security Team can be contacted via email using the following address: -{% highlight trac-wiki %} +``` security at qubes-os dot org -{% endhighlight %} +``` Qubes Security Team GPG Key --------------------------- diff --git a/SoftwareUpdateDom0.md b/SoftwareUpdateDom0.md index f6a2c60b..342a3fba 100644 --- a/SoftwareUpdateDom0.md +++ b/SoftwareUpdateDom0.md @@ -35,15 +35,15 @@ Of course, command line tools are still available for accomplishing various upda 1. To check and install updates for dom0 software: - {% highlight trac-wiki %} + ``` $ sudo qubes-dom0-update - {% endhighlight %} + ``` 1. To install additional packages in dom0 (usually not recommended): - {% highlight trac-wiki %} + ``` $ sudo qubes-dom0-update anti-evil-maid - {% endhighlight %} + ``` You may also pass the `--enablerepo=` option in order to enable optional repositories (see yum configuration in dom0). However, this is only for advanced users who really understand what they are doing. @@ -51,30 +51,30 @@ Of course, command line tools are still available for accomplishing various upda 1. Download an older version of the package: - {% highlight trac-wiki %} + ``` sudo qubes-dom0-update package-version - {% endhighlight %} + ``` Yum will say that there is no update, but the package will nonetheless be downloaded to dom0. 1. Downgrade the packge: - {% highlight trac-wiki %} + ``` sudo yum downgrade package-version - {% endhighlight %} + ``` ### Kernel Upgrade ### Install newer kernel. The following example installs kernel 3.19 and was tested on Qubes R3 RC1. - {% highlight trac-wiki %} + ``` sudo qubes-dom0-update kernel-3.19* - {% endhighlight %} + ``` Rebuild grub config. - {% highlight trac-wiki %} + ``` sudo grub2-mkconfig -o /boot/grub2/grub.cfg - {% endhighlight %} + ``` Reboot required. diff --git a/SoftwareUpdateVM.md b/SoftwareUpdateVM.md index 97b51251..3d0c1b91 100644 --- a/SoftwareUpdateVM.md +++ b/SoftwareUpdateVM.md @@ -72,9 +72,9 @@ Sometime it might be convenient to have a VM that has its own filesystem, where In order to create a standalone VM you can use a command line like this (from console in Dom0): -{% highlight trac-wiki %} +``` qvm-create --standalone --label