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
...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
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
* Check whether sysctl is accessible
* Check whether a key which exists when CONFIG_MODULES=y is not accessible
If true, CONFIG_MODULES=n, so ignore modprobe failure.
If false, fail.
- /var/run/qubes/this-is-appvm
- /var/run/qubes/this-is-netvm
- /var/run/qubes/this-is-proxyvm
- /var/run/qubes/this-is-templatevm
This is useful for checking ConditionPathExists from within systemd units.
(Came up in https://phabricator.whonix.org/T432#7206.)
Among other things this also fixes build failure - those scripts were
installed but not listed in spec file.
Actual check doesn't perform 'apt-get update', so do that when running
"standalone" (not as a hook from 'apt-get').
QubesOS/qubes-issues#1066
Initial size of those tmpfs-mounted directories is calculated as 50% of
RAM at VM startup time. Which happen to be quite small number, like
150M. Having such small /tmp and/or /dev/shm apparently isn't enough for
some applications like Google chrome. So set the size statically at 1GB,
which would be the case for baremetal system with 2GB of RAM.
FixesQubesOS/qubes-issues#1003
