mirror of
https://github.com/QubesOS/qubes-doc.git
synced 2025-05-02 06:46:11 -04:00
Various minor spelling and grammar fixes
This commit is contained in:
Miguel Jacq
parent
c1cc28b3c4
commit
db13ef5a33
49 changed files with 131 additions and 131 deletions
|
|
@ -48,7 +48,7 @@ The above command assumes the installation ISO was transferred to Dom0 (copied u
|
|||
qvm-start win7 --cdrom=/dev/cdrom
|
||||
~~~
|
||||
|
||||
Next the VM will start booting from the attached CDROM device (which in the example above just happens to be a 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 with Windows 7 installations), because whenever the installer wants to "reboot the system" it actually shutdowns the VM and Qubes won't automatically start it. Several invocations of qvm-start command (as shown above) might be needed.
|
||||
Next the VM will start booting from the attached CDROM device (which in the example above just happens to be a 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 with Windows 7 installations), because whenever the installer wants to "reboot the system" it actually shuts down the VM and Qubes won't automatically start it. Several invocations of qvm-start command (as shown above) might be needed.
|
||||
|
||||
[](/attachment/wiki/HvmCreate/r2b1-win7-installing.png)
|
||||
|
||||
|
|
@ -170,7 +170,7 @@ Cloning HVM domains
|
|||
|
||||
Just like normal AppVMs, the HVM domains can also be cloned either using a command-line `qvm-clone` command or via manager's 'Clone VM' option in the right-click menu.
|
||||
|
||||
The cloned VM will get identical root and private image and will essentially be an identical of the original VM except that it will get a different MAC address for the networking interface:
|
||||
The cloned VM will get identical root and private images and will essentially be identical to the original VM except that it will get a different MAC address for the networking interface:
|
||||
|
||||
~~~
|
||||
[joanna@dom0 ~]$ qvm-prefs win7
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ How to Create a NetBSD VM
|
|||
|
||||
1. Create a StandaloneVM with the default template.
|
||||
2. Replace `vmlinuz` with the `netbsd-INSTALL_XEN3_DOMU` kernel.
|
||||
3. During setup, chose to install on the `xbd1` hard disk.
|
||||
3. During setup, choose to install on the `xbd1` hard disk.
|
||||
4. Attach the CD to the VM.
|
||||
5. Configure the networking.
|
||||
6. Optionally enable SSHD during the post-install configuration.
|
||||
|
|
|
|||
|
|
@ -10,9 +10,9 @@ redirect_from:
|
|||
|
||||
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
|
||||
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool provider.
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool providers.
|
||||
|
||||
Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.
|
||||
Please keep in mind that using such a VM or VMs based on the template for security and privacy critical tasks is not recommended.
|
||||
|
||||
How to Create a BlackArch VM
|
||||
============================
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ redirect_from:
|
|||
|
||||
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
|
||||
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool provider.
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool providers.
|
||||
|
||||
Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ redirect_from:
|
|||
|
||||
- The installation scripts and provided tools may have bugs, be vulnerable to Man in the Middle (MitM) attacks or other vulnerabilities.
|
||||
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool provider.
|
||||
- Adding additional repositories or tools for installing software extends your trust to those tool providers.
|
||||
|
||||
Please keep in mind that using such a VM or VM's based on the template for security and privacy critical tasks is not recommended.
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ How to create Penetration Testers Framework (PTF) VM
|
|||
|
||||
PTF attempts to install all of your penetration testing tools (latest and greatest), compile them, build them, and make it so that you can install/update your distribution on any machine." (source [PTF Readme](https://github.com/trustedsec/ptf/blob/master/README.md))
|
||||
|
||||
**Note** PTF works on Debian testing as well as on Debian 8. PTF itself works with Debian 8, but the software tools will have missing dependencies. Metasploit for examples requires a newer Ruby version than Debian 8 has in the repositories. Therefor the best way to install PTF is by upgrading a Debian 8 into Debian testing with additional Kali repositories. Instead of installing the tools from Kali, PTF will install and update the newest tools.
|
||||
**Note** PTF works on Debian testing as well as on Debian 8. PTF itself works with Debian 8, but the software tools will have missing dependencies. Metasploit for example requires a newer Ruby version than Debian 8 has in the repositories. Therefore the best way to install PTF is by upgrading a Debian 8 into Debian testing with additional Kali repositories. Instead of installing the tools from Kali, PTF will install and update the newest tools.
|
||||
|
||||
Create Debian Based Penetration Testers Framework (PTF) Template
|
||||
----------------------------------------------------------------
|
||||
|
|
@ -108,7 +108,7 @@ possible to do sudo ptf/ptf
|
|||
[*] Exiting PTF - the easy pentest platform creation framework.
|
||||
sudo msfconsole
|
||||
|
||||
5. Create a AppVMs based on the `ptf` template
|
||||
5. Create an AppVM based on the `ptf` template
|
||||
|
||||
- (Optional) Attach necessary devices
|
||||
|
||||
|
|
|
|||
|
|
@ -53,18 +53,18 @@ In order to keep the template as small and simple as possible, default installed
|
|||
* Some font packages to keep good user experience
|
||||
* leafpad: a note pad
|
||||
* xfce4-terminal: a terminal
|
||||
* thunar: a file browser that support mounting usb keys
|
||||
* thunar: a file browser that supports mounting usb keys
|
||||
* firefox: web browser
|
||||
* thunderbird: a mail browser
|
||||
* evince: a document viewer
|
||||
|
||||
Note that Archlinux does not install GUI packages by default as this decision is left to users. This packages have only been selected to have a usable template.
|
||||
Note that Archlinux does not install GUI packages by default as this decision is left to users. These packages have only been selected to have a usable template.
|
||||
|
||||
## Updating a Qubes-3.1 Archlinux Template
|
||||
|
||||
If you decide to use binary packages but that you where using a Qubes-3.1 Template, your can follow these instructions to enable Qubes 3.2 agents.
|
||||
If you decide to use binary packages but that you were using a Qubes-3.1 Template, you can follow these instructions to enable Qubes 3.2 agents.
|
||||
|
||||
You can use a template that you built for Qubes 3.1 in Qubes 3.2. The qrexec and gui agent functionnalities should still be working so that you can at least open a terminal.
|
||||
You can use a template that you built for Qubes 3.1 in Qubes 3.2. The qrexec and gui agent functionalities should still be working so that you can at least open a terminal.
|
||||
|
||||
In order to enable binary packages for Qubes 3.2, add the following lines to the end of /etc/pacman.conf
|
||||
|
||||
|
|
@ -76,22 +76,22 @@ Server = http://olivier.medoc.free.fr/archlinux/current/
|
|||
You should then follow the instruction related to pacman-key in order to sign the binary packages PGP key. With the key enabled, a pacman update will update qubes agents:
|
||||
` # pacman -Suy `
|
||||
|
||||
The two line that have just been added to /etc/pacman.conf should then be removed as they have been included in the qubes-vm-core update in the file `/etc/pacmand.d/99-qubes-repository-3.2.conf`
|
||||
The two lines that have just been added to /etc/pacman.conf should then be removed as they have been included in the qubes-vm-core update in the file `/etc/pacmand.d/99-qubes-repository-3.2.conf`
|
||||
|
||||
## Known Issues
|
||||
|
||||
### Package cannot be updated because of errors related to xorg-server or pulseaudio versions
|
||||
|
||||
In case archlinux upgrade pulseaudio major version or xorg-server version, updating these packages will break the qubes GUI agent. To avoid breaking things, the update is blocked until a new version of the GUI agent is available.
|
||||
In the case of archlinux upgrade pulseaudio major version or xorg-server version, updating these packages will break the qubes GUI agent. To avoid breaking things, the update is blocked until a new version of the GUI agent is available.
|
||||
|
||||
In this case, the gui-agent-linux component of Qubes-OS needs to be rebuild using these last xorg-server or pulseaudio libraries. You can try to rebuilt it yourself or wait for a new qubes-vm-gui package to be available.
|
||||
In this case, the gui-agent-linux component of Qubes-OS needs to be rebuilt using these last xorg-server or pulseaudio libraries. You can try to rebuild it yourself or wait for a new qubes-vm-gui package to be available.
|
||||
|
||||
### qubes-vm is apparently starting properly (green dot) however graphical applications do not appears to work
|
||||
### qubes-vm is apparently starting properly (green dot) however graphical applications do not appear to work
|
||||
|
||||
They are multiple potential reasons. Some of them are described in the following issues:
|
||||
They are multiple potential reasons. Some of them are described in the following issue:
|
||||
* https://github.com/QubesOS/qubes-issues/issues/2612
|
||||
|
||||
In issue 2612, check that the option `noauto` is present for all lines in /etc/fstab related to /rw or /home. This bug can appears if you come from an old Archlinux Template (pre February 2017).
|
||||
In issue 2612, check that the option `noauto` is present for all lines in /etc/fstab related to /rw or /home. This bug can appear if you come from an old Archlinux Template (pre February 2017).
|
||||
|
||||
## Debugging a broken VM
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ In order to identify the issue, you should start by getting a console access to
|
|||
|
||||
* Or by running in dom0 `sudo xl console yourbrokenvm`
|
||||
|
||||
Starts by trying to run a GUI application such as xfce4-terminal in order to identify any error message.
|
||||
Start by trying to run a GUI application such as xfce4-terminal in order to identify any error message.
|
||||
|
||||
Then you can check potential broken systemd service by running the following command inside the broken vm: `systemctl | grep fail`.
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ Finally, errors related to the GUI agent can be found inside the VM in `/home/us
|
|||
## Packages manager wrapper
|
||||
|
||||
|
||||
Powerpill is a full Pacman wrapper that not only give easy proxy configuration but further offers numerous other advantages.
|
||||
Powerpill is a full Pacman wrapper that not only gives easy proxy configuration but further offers numerous other advantages.
|
||||
|
||||
Please check out:
|
||||
|
||||
|
|
@ -121,7 +121,7 @@ Please check out:
|
|||
[XYNE's (dev) Powerpill](http://xyne.archlinux.ca/projects/powerpill/)
|
||||
|
||||
|
||||
**Important Note:** As you are working in a template vm, by default, you will have to open network access to the template to download files manually, except for package managed which should be handled by the Qubes proxy. You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services through the same window. Remember to change it back if you choose the later route. Actions needing network access will be noted with (needs network access)
|
||||
**Important Note:** As you are working in a template vm, by default, you will have to open network access to the template to download files manually, except for managed packages which should be handled by the Qubes proxy. You can use the "allow full access for" a given time period in the FW settings of the template in the VMM or open up the various services through the same window. Remember to change it back if you choose the later route. Actions needing network access will be noted with (needs network access)
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
|
@ -134,7 +134,7 @@ Please check out:
|
|||
|
||||
* **$ sudo nano -w /etc/pacman.conf**
|
||||
|
||||
* Below is the output of a correct pacman.conf file Make the changes so your file matches this one or rename the original and create a new one and copy and paste this text into it. Text should be justified left in the file. The changes from your default are to make gpg sig signing mandatory for packages but not required for DBs for the archlinux repos. Also to add the repo (at the end) for the Powerpill package.
|
||||
* Below is the output of a correct pacman.conf file Make the changes so your file matches this one or rename the original and create a new one and copy and paste this text into it. Text should be justified left in the file. The changes from your default are to make gpg signing mandatory for packages but not required for DBs for the archlinux repos. Also to add the repo (at the end) for the Powerpill package.
|
||||
|
||||
|
||||
<br>
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ Additional Information
|
|||
----------------------
|
||||
|
||||
It should be noted that Debian 9 (Stretch) is currently marked testing and
|
||||
should be treat as such. For projects that need absolute stability, upgrading
|
||||
should be treated as such. For projects that need absolute stability, upgrading
|
||||
may not be the best option.
|
||||
|
||||
Debian Stretch packages were first made available in the Qubes R3.1 repositories.
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ The download may take a while depending on your connection speed.
|
|||
Duplication and first steps
|
||||
---------------------------
|
||||
|
||||
It is higly recommended to clone the original template, and make any changes in the clone instead of the original template. The following command clones the template. Replace `your-new-clone` with your desired name.
|
||||
It is highly recommended to clone the original template, and make any changes in the clone instead of the original template. The following command clones the template. Replace `your-new-clone` with your desired name.
|
||||
|
||||
~~~
|
||||
[user@dom0 ~]$ qvm-clone fedora-24-minimal your-new-clone
|
||||
|
|
|
|||
|
|
@ -202,7 +202,7 @@ In this case, you have several options:
|
|||
1. [Increase the TemplateVM's disk image size](/doc/resize-disk-image/).
|
||||
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
|
||||
uninstalling packages. You may then reinstall 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
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ In this case, you have several options:
|
|||
1. [Increase the TemplateVM's disk image size](/doc/resize-disk-image/).
|
||||
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
|
||||
uninstalling packages. You may then reinstall 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
|
||||
|
|
|
|||
|
|
@ -215,7 +215,7 @@ In this case, you have several options:
|
|||
1. [Increase the TemplateVM's disk image size][resize-disk-image].
|
||||
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
|
||||
uninstalling packages. You may then reinstall 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`.
|
||||
|
|
|
|||
|
|
@ -124,14 +124,14 @@ Qubes allows HVM VMs to share a common root filesystem from a select Template VM
|
|||
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/hvm-create/) 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:
|
||||
... and install Windows OS (or other OS) into this template the same way as you would install it into a normal HVM -- please see instructions on [this page](/doc/hvm-create/). 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:
|
||||
|
||||
- The private disk is initialized and formatted on the first reboot after tools installation. It can't be done **during** the installation because Xen mass storage drivers are not yet active.
|
||||
- User profiles are moved to the private disk on the next reboot after the private disk is initialized. Reboot is required because the "mover utility" runs very early in the boot process so OS can't yet lock any files in there. This can take some time depending on the profiles' size and because the GUI agent is not yet active dom0/Qubes Manager may complain that the AppVM failed to boot. That's a false alarm (you can increase AppVM's default boot timeout using `qvm-prefs`), the VM should appear "green" in Qubes Manager shortly after.
|
||||
|
||||
It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide setting are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
|
||||
It also makes sense to disable Automatic Updates for all the template-based AppVMs -- of course this should be done in the Template VM, not in individual AppVMs, because the system-wide settings are stored in the root filesystem (which holds the system-wide registry hives). Then, periodically check for updates in the Template VM and the changes will be carried over to any child AppVMs.
|
||||
|
||||
Once the template has been created and installed it is easy to create AppVMs based on:
|
||||
Once the template has been created and installed it is easy to create AppVMs based on it:
|
||||
|
||||
~~~
|
||||
qvm-create --hvm <new windows appvm name> --template <name of template vm> --label <label color>
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue