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
...but installed on all Debian versions. This is mostly required by
vebose file list in debian/qubes-core-agent.install. But also make it
use new options when upstream will set them.
QubesOS/qubes-issues#2161
qubes-early-vm-config.service depend on qubes-db daemon running, to
retrieve various configuration parameters. But the startup ordering
declaration was missing
FixesQubesOS/qubes-issues#2750
Before, the script skipped none existing ro paths even if the path
existed below /rw. This would require someone who wants to use bind-dirs
only in TemplateBasedVM to ensure that the paths exist before the
bind-dirs script gets called.
This patch changes this behavior so that if the path exists below /rw, it
is ensured that an (empty) file/directory is present in ro (where the
corresponding path from /rw is then bind mounted over).
Requires: Docs update. I can open a PR when this PRs looks good.
Fixes limitation: "Does not work if the file / folder in question does
not already exist in the root image. I.e. a file that does not exist in
the root image cannot be bind mounted in the TemplateBasedVM."
Example use case: https://github.com/debops/ansible-persistent_paths
Tested on: Qubes OS 3.2; Debian 8 TemplateBasedVM (and Template)
Related to: https://github.com/QubesOS/qubes-issues/issues/2661
* qubesos/pr/25:
Add systemd override for haveged in xenial and stretch. (#2161) Reenable haveged.service after debian package installation
FixesQubesOS/qubes-issues#2161
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
