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
fsck may require significant amount of RAM, enable swap earlier to avoid
out of memory condition. Implement this as a separate service unit, not
a swap unit, because the latter requires udev running (implicit
dependency on dev-xvdc1.device) which is not the case before remounting
root filesystem read-write.
QubesOS/qubes-issues#6174
It doesn't make sense in Qubes to rebuild modules at every VM startup.
Especially when modules dir is either read-only, or on non-persistent
root volume (TemplateBasedVM).
This is especially uneeded for dom0-provided kernels, which already have
u2mfn module built, but DKMS try to rebuild it anyway (and fails,
because of missing/broken kernel-devel package).
DKMS already have appropriate (rpm/dpkg) hooks for new kernel
installation, so actually needed modules should be build in template on
kernel update/install anyway.
This saves about 2s from VM startup time.
clock synchronization mechanism rewritten to use systemd-timesync instead of NtpDate; at the moment, requires:
- modifying /etc/qubes-rpc/policy/qubes.GetDate to redirect GetDate to designated clockvm
- enabling clocksync service in clockvm ( qvm-features clockvm-name service/clocksync true )
Works as specified in issue listed below, except for:
- each VM synces with clockvm after boot and every 6h
- clockvm synces time with the Internet using systemd-timesync
- dom0 synces itself with clockvm every 1h (using cron)
fixesQubesOS/qubes-issues#1230
Configure package manager to use 127.0.0.1:8082 as proxy instead of
"magic" IP intercepted later. The listen on this port and whenever
new connection arrives, spawn qubes.UpdatesProxy service call (to
default target domain - subject to configuration in dom0) and connect
its stdin/out to the local TCP connection. This part use systemd.socket
unit in case of systemd, and ncat --exec otherwise.
On the other end - in target domain - simply pass stdin/out to updates
proxy (tinyproxy) running locally.
It's important to _not_ configure the same VM to both be updates proxy and
use it. In practice such configuration makes little sense - if VM can
access network (which is required to run updates proxy), package manager
can use it directly. Even if this network access is through some
VPN/Tor. If a single VM would be configured as both proxy provider and
proxy user, connection would loop back to itself. Because of this, proxy
connection redirection (to qrexec service) is disabled when the same VM
also run updates proxy.
FixesQubesOS/qubes-issues#1854
Up until today, Qubes OS would insist on either masking or disabling
or activating units that should get their state properly changed
but only on first package install (when the template is built).
This commit adds the possibility of having two types of unit presets:
* Initial presets: these are only changed state during first package
installs.
* Upgrade presets: these get their state changed during first
package installs as well as during upgrades.
All the maintainer has to do is abide by the instructions in the
preset file. Nothing else is necessary.
Namely, this allows users to enable SSHD on their templates or
standalone VMs and still keep it enabled even after the
qubes-core-vm-systemd package is upgraded.
Matt really wanted that, and so did I, so now we can do it!
:-)
There were multiple problems with reusing existing one:
- need to sync with upstream changes (configuration path etc)
- conflicts resolution on updates
- lack of iptables --wait, which causes firewall fail to load sometimes
QubesOS/qubes-issues#1067
