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
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
It isn't really needed. It was used to workaround libusb bug (causing
crash when the system does not have any USB controller), but since we
use HVM now which do have some USB controllers it isn't needed anymore.
Also, it is not available in stock Fedora kernels.
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
