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!
:-)
qubes-setup-dnat-to-ns is called multiple times during boot. Of particular interest are the two invocations done by:
1. `/usr/lib/qubes/init/network-proxy.setup.sh` (`qubes-network.service`)
2. `/usr/lib/qubes/init/misc-post.sh` (`qubes-misc-post.service`)
These can, and do often, run in parallel. Often enough that the `PR-QBS` `nat` chain can end up with eight rules instead of four, or (worse) zero rules.
This commit represents the proper boot ordering of these services, where the post startup *must* happen after Qubes has already started its iptables, firewall, network setup and netwatcher.
This eliminates the race.
f4d367a6 dropped the check if the bind target exists and added
"--no-clobber" to the cp call. For directories this does not work as
desired: cp checks per (recursive) file instead of once for the
specified directory.
- qubes-misc-post.service is no longer responsible for mounting /rw
- both qubes-sysinit.service and qubes-mount-dirs.service are part of
basic.target, so no need to mention them explicitly (as long as
DefaultDependencies=yes)
QubesOS/qubes-issues#2198
It is needed for vchan communication. It was loaded implicitly by mount
/proc/xen, but since we're moving away from this legacy interface, load
it explicitly.
QubesOS/qubes-issues#2194
The service is really responsible for mounting /rw and /home, so should
be ordered before local-fs.target - this will allow other services
to use standard ordering targets.
This probably makes Before=qubes-gui-agent.service not needed anymore,
but do not remove it yet without extensive testing to not risk
regression.
FixesQubesOS/qubes-issues#2194
Even if update check fails for some reason (network problem, apt-get lock
being held etc), don't mark the service as failed. The update check
mechanism is designed this way to not worry about such single failures
- other VM(s) may still check and report updates availability.
FixesQubesOS/qubes-issues#1889
* qubesos/pr/18:
Enable xendriverdomain.service in 75-qubes-vm.preset
Remove 'if true' wrapper from 06a0d30d50
*Do* block until good random is available again
dvm, then xendriverdomain, then qrexec-agent
Network management software should order itself after network-pre.target
(man 7 systemd.special) so that other units can order themselves before
the *beginning* of network initialization. (qubes-misc-post too because
it calls setup-ip.)
Relevant for QubesOS/qubes-issues#2108
Files in /var/run/qubes-service are created by qubes-sysinit.service. So
defer that condition check after that service start.
Thanks @adrelanos for the report.
FixesQubesOS/qubes-issues#1985
* origin/pr/58:
refactoring / code simplification
fixed broken file copy for files in multi level directories
also exit from bind-directories if file /var/run/qubes-service/qubes-dvm exists
use symlink_level_max rather than hardcoding 10; comment
run /usr/lib/qubes/bind-dirs.sh from mount-dirs.sh
renamed: bind-dirs -> bind-dirs.sh
renamed: misc/bind-dirs -> vm-systemd/bind-dirs
work on bind-dirs
work on bind-dirs
work on bind-dirs https://phabricator.whonix.org/T414
For a long time the DNS address was the same as default gateway. This is
still the case in R3.x, but using `qubes-gateway` configuration
parameter for it is misleading. It should be up to dom0 to provide DNS
address (whether the value is the same as gateway or not).
FixesQubesOS/qubes-issues#1817
qubes-sysinit.sh waits for xenbus initialization by watching its
interface file presence. In linux before 3.10 there is no
/dev/xen/xenbus, which is the case in Debian 7 (3.2 kernel). The problem
applies only to the VMs with PVGrub enabled, because otherwise VM would
use dom0 privided kernel, which is much newer.
FixesQubesOS/qubes-issues#1609
