Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-10-01 01:25:40 -04:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'config-files-patch' of https://github.com/deathgrippin/qubes-doc into deathgrippin-config-files-patch

Browse Source
This commit is contained in:
Andrew David Wong 2020-05-18 09:30:32 -05:00
commit 07667d6565
No known key found for this signature in database
GPG Key ID: 8CE137352A019A17
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
user/advanced-configuration/config-files.md
View File

@ -15,12 +15,12 @@ Configuration Files
Qubes-specific VM config files Qubes-specific VM config files
------------------------------ ------------------------------
These files are placed in /rw, which survives a VM restart. These files are placed in `/rw`, which survives a VM restart.
That way, they can be used to customize a single VM instead of all VMs based on the same template. That way, they can be used to customize a single VM instead of all VMs based on the same template.
The scripts here all run as root. The scripts here all run as root.
- `/rw/config/rc.local` - script runs at VM startup. - `/rw/config/rc.local` - script runs at VM startup.
Good place to change some service settings, replace config files with its copy stored in /rw/config, etc. Good place to change some service settings, replace config files with its copy stored in `/rw/config`, etc.
Example usage: Example usage:
~~~ ~~~
@ -37,7 +37,7 @@ The scripts here all run as root.
- `/rw/config/qubes-ip-change-hook` - script runs in NetVM after every external IP change and on "hardware" link status change. - `/rw/config/qubes-ip-change-hook` - script runs in NetVM after every external IP change and on "hardware" link status change.
- In ProxyVMs (or AppVMs with `qubes-firewall` service enabled), scripts placed in the following directories will be executed in the listed order followed by `qubes-firewall-user-script` after each firewall update. - In ProxyVMs (or AppVMs with `qubes-firewall` service enabled), scripts placed in the following directories will be executed in the listed order followed by `qubes-firewall-user-script` after each firewall update.
Good place to write own custom firewall rules. Good place to write custom firewall rules.
~~~ ~~~
/etc/qubes/qubes-firewall.d /etc/qubes/qubes-firewall.d
@ -49,7 +49,7 @@ The scripts here all run as root.
The file is used only in a VM with PCI devices attached. The file is used only in a VM with PCI devices attached.
Intended for use with problematic device drivers. Intended for use with problematic device drivers.
- In NetVMs/ProxyVMs, scripts placed in `/rw/config/network-hooks.d` will be ran when configuring Qubes interfaces. For each script, the `command`, `vif`, `vif_type` and `ip` is passed as arguments (see `/etc/xen/scripts/vif-route-qubes`). For example, consider an PV AppVM `work` with IP `10.137.0.100` and `sys-firewall` as NetVM. Assuming it's Xen domain id is arbitrary `12` then, the following script located at `/rw/config/network-hooks.d/hook-100.sh` in `sys-firewall`: - In NetVMs/ProxyVMs, scripts placed in `/rw/config/network-hooks.d` will be ran when configuring Qubes interfaces. For each script, the `command`, `vif`, `vif_type` and `ip` is passed as arguments (see `/etc/xen/scripts/vif-route-qubes`). For example, consider a PV AppVM `work` with IP `10.137.0.100` and `sys-firewall` as NetVM. Assuming it's Xen domain id is arbitrary `12` then, the following script located at `/rw/config/network-hooks.d/hook-100.sh` in `sys-firewall`:
~~~ ~~~
#!/bin/bash #!/bin/bash
@ -70,9 +70,9 @@ The scripts here all run as root.
fi fi
~~~ ~~~
will be executed with arguments `online vif12.0 vif 10.137.0.100` when starting `work`. Please note that in case of HVM, the script will be called twice - once with vif_type `vif`, then with vif_type `vif_ioemu` (and different interface names). As long as the ioemu interface exists, it should be preferred (up to the hook script). When VM decide to use PV interface (vif_type `vif`), the ioemu one will be unplugged. will be executed with arguments `online vif12.0 vif 10.137.0.100` when starting `work`. Please note that in case of an HVM, the script will be called twice - once with vif_type `vif`, then with vif_type `vif_ioemu` (and different interface names). As long as the ioemu interface exists, it should be preferred (up to the hook script). When the VM decides to use a PV interface (vif_type `vif`), the ioemu one will be unplugged.
Note that scripts need to be executable (chmod +x) to be used. Note that scripts need to be executable (`chmod +x`) to be used.
Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easily modify arbitrary system files in an AppVM and have those changes persist. Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easily modify arbitrary system files in an AppVM and have those changes persist.
@ -80,7 +80,7 @@ Also, take a look at [bind-dirs](/doc/bind-dirs) for instructions on how to easi
GUI and audio configuration in dom0 GUI and audio configuration in dom0
----------------------------------- -----------------------------------
The GUI configuration file `/etc/qubes/guid.conf` in one of a few not managed by qubes-prefs or the Qubes Manager tool. The GUI configuration file `/etc/qubes/guid.conf` in one of a few not managed by `qubes-prefs` or the Qubes Manager tool.
Sample config (included in default installation): Sample config (included in default installation):
~~~ ~~~
@ -140,7 +140,7 @@ Currently supported settings:
- `tint+whitehack` - same as tint, but change white pixels (0xffffff) to - `tint+whitehack` - same as tint, but change white pixels (0xffffff) to
almost-white (0xfefefe) almost-white (0xfefefe)
- `log level` - log level defines the log options log can take. log level can - `log level` - defines the log options logs can take. It can
have a value of 0(only errors), 1(some basic messages), 2(debug). have a value of 0 (only errors), 1 (some basic messages), and 2 (debug).
- `startup_timeout` - The timeout for startup. - `startup_timeout` - The timeout for startup.