replaced all github flavored code blocks with fenced kramdown code blocks

This commit is contained in:
Jeepler 2015-09-27 01:00:33 +02:00
parent df467baf1c
commit 39ef7373fd
58 changed files with 609 additions and 609 deletions

View file

@ -17,32 +17,32 @@ Upgrading Fedora 18 to Fedora 20
Commands to run in dom0 console (you can do the same from Qubes Manager):
```
~~~
qvm-clone fedora-18-x64 fedora-20-x64
qvm-run -a fedora-20-x64 gnome-terminal
```
~~~
Commands to run in new fedora-20-x64 template:
```
~~~
sudo yum --releasever=20 distro-sync
poweroff
```
~~~
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:
```
~~~
truncate -s 5GB /var/tmp/template-upgrade-cache.img
qvm-block -A fedora-20-x64 dom0:/var/tmp/template-upgrade-cache.img
```
~~~
Then use it in template:
```
~~~
sudo mkfs.ext4 /dev/xvdi
sudo mount /dev/xvdi /mnt/removable
sudo yum --releasever=20 --setopt=cachedir=/mnt/removable distro-sync
```
~~~
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:
```
~~~
dd if=/dev/zero of=/var/tmp/zero
(wait for "No space left on device" error)
rm -f /var/tmp/zero
```
~~~
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:
```
~~~
cp --sparse=always root.img root.img.new
mv root.img.new root.img
```
~~~
Done.

View file

@ -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):
```
~~~
qvm-create win7 --hvm --label green
```
~~~
(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):
```
~~~
qvm-start win7 --cdrom=/usr/local/iso/win7_en.iso
```
~~~
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`:
```
~~~
qvm-start win7 --cdrom=/dev/cdrom
```
~~~
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:
```
~~~
--cdrom=[appvm]:[/path/to/iso/within/appvm]
```
~~~
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):
```
~~~
qvm-create --hvm ubuntu --label red
qvm-start ubuntu --cdrom=work-web:/home/user/Downloads/ubuntu-12.10-desktop-i386.iso
```
~~~
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:
```
~~~
[joanna@dom0 ~]$ qvm-prefs win7
name : win7
label : green
@ -145,21 +145,21 @@ qrexec_installed : False
qrexec timeout : 60
drive : None
timezone : localtime
```
~~~
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:
```
~~~
[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 |
/.../
```
~~~
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:
```
~~~
[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
```
~~~
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:
```
~~~
sudo qubes-dom0-update qubes-windows-tools
```
~~~
This should install `qubes-windows-tools-*.rpm` in your system, a package that brings an ISO with Windows Support Tools:
```
~~~
[joanna@dom0 ~]$ rpm -ql qubes-windows-tools-1-201211301354.noarch
/usr/lib/qubes/qubes-windows-tools-201211301354.iso
```
~~~
Now, in order to install the tools in a Windows VM one should start the VM with the ISO attached:
```
~~~
qvm-start lab-win7 --cdrom=/usr/lib/qubes/qubes-windows-tools-201211301354.iso
```
~~~
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.:
```
~~~
qvm-prefs lab-win7 -s qrexec_installed true
```
~~~
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.:
```
~~~
qvm-prefs lab-win7 -s default_user joanna
```
~~~
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.:
```
~~~
qvm-run lab-win7 calc
```
~~~
... or something more fancy (a "networkless" telnet to Windows ;):
```
~~~
[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
```
~~~
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!).

View file

@ -20,24 +20,24 @@ To achieve it (all commands run as root):
1. Generate XOrg configuratio (if you don't have it):
```
~~~
X -configure :1 && mv ~/xorg.conf.new /etc/X11/xorg.conf
```
~~~
2. Add HorizSync line to Monitor section, it should look something like:
```
~~~
Section "Monitor"
Identifier "Monitor0"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 30.0 - 60.0
EndSection
```
~~~
3. Change driver to "vesa" in Device section:
```
~~~
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
```
~~~
Now you should get at least 1280x1024 and be able to choose other modes.

View file

@ -17,25 +17,25 @@ Install
It can be installed via the following command:
```
~~~
[user@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-21-minimal
```
~~~
Usage
-----
It is a good idea to clone the original template, and make any changes in the new clone instead:
```
~~~
[user@dom0 ~]$ qvm-clone fedora-21-minimal <your new template name>
```
~~~
The sudo package is not installed by default, so let's install it:
```
~~~
[user@F21-Minimal ~]$ su -
[user@F21-Minimal ~]$ yum install sudo
```
~~~
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.
@ -45,15 +45,15 @@ To access the journald log, use the `journalctl` command.
If you want to use this template to for standard NetVMs you should install some more packeges:
```
~~~
[user@F21-Minimal ~]$ sudo yum install NetworkManager NetworkManager-wifi network-manager-applet wireless-tools dbus-x11 dejavu-sans-fonts tar tinyproxy
```
~~~
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
```
~~~
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 :)

View file

@ -61,7 +61,7 @@ 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
@ -120,4 +120,4 @@ FOR /F "delims=. tokens=1" %%I IN ('DIR /B "%SYSTEMROOT%\INF\OEM*.INF"') DO (
echo.
echo Cleanup finished. Please manually uninstall Qubes Video and Xen devices from the Device Manager.
```
~~~

View file

@ -32,17 +32,17 @@ Installing Qubes support tools in Windows 7 VMs
First, make sure that `qubes-windows-tools` is installed in your system:
```
~~~
sudo qubes-dom0-update qubes-windows-tools
```
~~~
This package brings the ISO with Qubes Windows Tools that is passed to the VM when `--install-windows-tools` is specified for the `qvm-start` command. Please note that even though the Qubes Windows Tools are proprietary, none of this software ever runs in Dom0 or any other part of the system except for the Windows AppVM in which it is to be installed.
To install the Qubes Windows support tools in a Windows VM one should start the VM passing the additional option `--install-windows-tools`:
```
~~~
qvm-start lab-win7 --install-windows-tools
```
~~~
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.
@ -54,30 +54,30 @@ After successful installation, the Windows VM must be shut down and started agai
Qubes (R2 Beta 3 and later releases) will automatically detect the tools has been installed in the VM and will set appropriate properties for the VM, such as `qrexec_installed`, `guiagent_installed`, and `default_user`. This can be verified (but is not required) using qvm-prefs command:
```
~~~
qvm-prefs <your-appvm-name>
```
~~~
Using Windows AppVMs in seamless mode (Qubes R2 Beta 3 and later)
-----------------------------------------------------------------
Once you start a Windows-based AppVM with Qubes Tools installed, you can easily start individual applications from the VM (note the `-a` switch used here, which will auto-start the VM if it is not running):
```
~~~
qvm-run -a my-win7-appvm explorer.exe
```
~~~
![windows-seamless-4.png](/attachment/wiki/WindowsAppVms/windows-seamless-4.png) ![windows-seamless-1.png](/attachment/wiki/WindowsAppVms/windows-seamless-1.png)
Also, the inter-VM services work as usual -- e.g. to request opening a document or URL in the Windows AppVM from another VM:
```
~~~
[user@work ~]$ qvm-open-in-vm work-win7 roadmap.pptx
```
~~~
```
~~~
[user@work ~]$ qvm-open-in-vm work-win7 http://www.invisiblethingslab.com
```
~~~
... just like in case of Linux AppVMs. Of course all those operations are governed by central policy engine running in Dom0 -- if the policy
@ -97,9 +97,9 @@ Using template-based Windows AppVMs (Qubes R2 Beta 3 and later)
Qubes allows HVM VMs to share a common root filesystem from a select Template VM, just like it is done for Linux AppVMs. This mode is not limited to Windows AppVMs, and can be used for any HVM (e.g. FreeBSD running in a HVM). In order to create a HVM TemplateVM one can use the following command:
```
~~~
qvm-create --hvm-template win7-x64-template -l green
```
~~~
... and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see [this page](/doc/HvmCreate/) instructions. However, it would make lots of sense to store the `C:\Users` directory on the 2nd disk which is automatically exposed by Qubes to all HVMs. This 2nd disk is backed by the `private.img` file in the AppVMs' and is not reset upon AppVMs reboot, so the user's directories and profiles would survive the AppVMs reboot, unlike the "root" filesystem which will be reverted to the "golden image" from the Template VM automatically. To facilitate such separation of user profiles, Qubes Windows Tools provide an option to automatically move `C:\Users` directory to the 2nd disk backed by `private.img`. It's a selectable feature of the installer, enabled by default. If that feature is selected during installation, completion of the process requires two reboots:
@ -110,6 +110,6 @@ It also makes sense to disable Automatic Updates for all the Windows-based AppVM
Once the template has been created and installed it is easy to create AppVMs based on:
```
~~~
qvm-create --hvm <new windows appvm name> --template <name of template vm> --label <label color>
```
~~~