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
Stop IP forwarding when stopping qubes-network service (which initially
enables it). This makes ordering against qubes-firewall safe - firewall
is applied before allowing IP forward and then is removed when IP
forward is already disabled.
FixesQubesOS/qubes-issues#5599
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
systemd-gpt-auto-generator creates boot.automount for existing ESP
partition. But Qubes templates have only placeholder ESP there, with no
even filesystem created. Disable it with drop-in file, until it will
become used.
FixesQubesOS/qubes-issues#5261
* origin/pr/163:
init/functions: better not use ipcalc which is not present on minimal distro
Handle errors for non-present ip gateways
Better use '-z' and '-n' for readibility
init/functions: handle non-present /qubes-mac qubesdb and check if iface exists
configure_network: use classical function parsing
Handle legacy non-present /qubes-mac qubesdb entry
Refactor and handle new network qubesdb configuration
* qubesos/pr/157:
qubes-updates-proxy: make ShellCheck happy
Use exec to ease systemd handling the tinyproxy process
Handle tinyproxy path changed in upstream
Avoid race conditions with services ordered shortly after qrexec start.
Make systemd know when qrexec-agent is really ready to serve.
FixesQubesOS/qubes-issues#3985
Previously, bind-dirs.sh had a bunch of `true comment goes here` style debug messages (no-ops). Presumably this was done because these messages are intended as debug messages and would only be displayed when calling bind-dirs.sh with xtrace enabled. However, this includes some fatal errors, which are necessary to debug why bind-dirs.sh is ostensibly not working. For example, I tried to mount /var/lib/docker, didn't realize it did not exist (as an empty directory) in my base template, and there was no journalctl output at all. After this change, journalctl will contain the (very helpful) error message.
qubes-firewall.service have Before=qubes-network.service. The latter
enable ip_forwarding. Make sure the ordering cover not only service
fork, but all its startup sequence, including initial rules and user
scripts.
Reported-by: @tasket
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.
nullglob must be active before a glob is used on a potentially empty
directory. Call shopt immediately after the shebang line.
FixesQubesOS/qubes-issues#3552
If IPv6 is configured in the VM, and it is providing network to others,
apply IPv6 firewall similar to the IPv4 one (including NAT for outgoing
traffix), instead of blocking everything. Also, enable IP forwarding for
IPv6 in such a case.
FixesQubesOS/qubes-issues#718
Start qubes-firewall (which will add "DROP by default" rule) before
enabling IP forwarding, to not leave a time slot where some connection
could go around configured firewall.
QubesOS/qubes-issues#3269
In some cases it may make sense to enfoce outgoing firewall also on
sys-net. If the service is disabled, firewall settings will be
(silently) ignored, so better be on the safe side and enable.
QubesOS/qubes-issues#3290
systemd-timesyncd.service isn't enough, for various reasons:
- it is started too early in the boot process - files in
/var/run/qubes-services are not yet there
- by default it does only one shot synchronization, and there is no
network at that early boot time yet
- by default use-ntp is set to "no"
So, in addition, enable actual ntp client.
FixesQubesOS/qubes-issues#3210
