Previously, network uplink (eth0) was configured in two places:
- udev (asynchronously)
- qubes-misc-post.service - at the very end of the boot process
This caused multiple issues:
1. Depending on udev event processing (non-deterministic), network
uplink could be enabled too early, for example before setting up
firewall.
2. Again depending on udev processing, it can be enabled quite late in
the boot process, after network.target is up and services assume
network already configured. This for example causes qubes-firewall to
fail DNS queries.
3. If udev happen try to enable enable networking even earlier, it may
happend before qubesdb-daemon is started, in which case network setup
fill fail. For this case, there was network re-setup in
qubes-misc-post service - much later in the boot.
Fix the above by placing network uplink setup in a dedicated
qubes-network-uplink@${INTERFACE}.service unit ordered after
network-pre.target and pulled in by udev based on vif device existence,
to handle also dynamic network attach/detach.
Then, create qubes-network-uplink.service unit waiting for appropriate
interface-specific unit (if one is expected!) and order it before
network.target.
QubesOS/qubes-issues#5576
qubes-desktop-file-install is called by qubes-triggers-desktop-file-install. It's
arguments are based on the Gnome desktop-install-file utility to allow it to be replaced
by same. Currently the Gnome utility can not be used since it automatically validates
the .desktop entry files with no option to skip validation and will fail on some third
party .desktop files that are not formed properly.
A single trigger script is shared between Fedora, Debian. This script is used by the
package managers triggers and will copy original .desktop files from `/etc/xdg/autostart`
to `/usr/share/qubes/xdg/autostart` and modify the OnlyShownIn / NotShownIn, etc. The
original .desktop files are left untouched and left in place.
Qubes modifies the XDG_CONFIG_DIRS to first include the `/usr/share/qubes/xdg`
directory (XDG_CONFIG_DIRS=/usr/share/qubes/xdg:/etc/xdg).
If a package gets removed, it's desktop entry is also removed from the /usr/share/qubes/xdg
directory.
'qubes-desktop-file-install' options:
--dir DIR Install desktop files to the DIR directory (default: <FILE>)
--force Force overwrite of existing desktop files (default: False)
--remove-show-in Remove the "OnlyShowIn" and "NotShowIn" entries from the desktop file (default: False)
--remove-key KEY Remove the KEY key from the desktop files, if present
--set-key (KEY VALUE) Set the KEY key to VALUE
--remove-only-show-in ENVIRONMENT Remove ENVIRONMENT from the list of desktop environment where the desktop files should be displayed
--add-only-show-in ENVIRONMENT Add ENVIRONMENT to the list of desktop environment where the desktop files should be displayed
--remove-not-show-in ENVIRONMENT Remove ENVIRONMENT from the list of desktop environment where the desktop files should not be displayed
--add-not-show-in ENVIRONMENT Add ENVIRONMENT to the list of desktop environment where the desktop files should not be displayed
The ext4 reserved space is necessary for root partitions, but in the
private.img data partition, it is wasted space (accessible only to root
processes), which means losing 100 MB of the default 2GB.
From mkfs.ext4 man page: "-m reserved-blocks-percentage Specify the
percentage of the filesystem blocks reserved for the super-user." ...
"The default percentage is 5%."
Get rid of underscores in filenames, use dashes instead.
This is first part of cleanup in filenames.
"qubes_rpc" still untouched - will be in separate commit.
No more ugly symlink creation at VM startup, nautilus-actions have system-wide
dir (in opposite to nautilus-scripts).
Currently old symlinks are not cleaned up. Maybe it should, but leaving them
have one advantage: will not break existing users behavior.
When /rw/home/user/.qubes-dispvm-customized is present use /rw/home/user
instead of default /etc/dispvm-dotfiles.tbz. Also make sure that /rw will not
remain mounted during DispVM creation.
The simplest way is just add proxy=... entry to /etc/yum.conf, but sometimes it
is reasonable to bypass the proxy. Some examples:
- usage of non-standard repos with some exotic file layout, which will be
blocked by the proxy
- usage of repos not-accessible via proxy (eg only via VPN stared in VpnVM)
This commit introduces 'yum-proxy-setup' pseudo-service, which can be
controlled via standard qvm-service or qubes-manager. When enabled - yum will
be configured at VM startup to use qubes proxy, otherwise - to connect directly
(proxy setting will be cleared).
