It tries to connect to cups every second and doesn't do anything else
when cups is disabled. So disable (or enable) both of them at the same
time.
(cherry picked from commit 414f944cf9)
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
(cherry picked from commit 3fb258db47)
Since the qubes-download-dom0-updates script executes dnf with fakeroot, some dnf plugins like etckeeper break the update with "Permission denied" errors.
(cherry picked from commit 5438e43ff6)
Fix removing the file - do not free its filename just before unlink call
(scheduled with atexit function).
At the same time, place the temporary file in a unique directory,
making it possible to edit multiple files with the same name at once.
Remove that directory at exit too.
FixesQubesOS/qubes-issues#3112
(cherry picked from commit e2789ca2d7)
New udev have `DRIVERS` matcher, instead of `ENV{ID_NET_DRIVER}`. Add
appropriate rule to the file. Without it, network was working
incidentally, because there is a fallback in qubes-misc-post.service,
but dynamic network change was broken.
This applies at least to Debian stretch.
FixesQubesOS/qubes-issues#3192
(cherry picked from commit 2068299126)
Debian stretch in default configuration calls apt-get update every 24h.
And additionally, have automatic unattended security updates enabled.
Generally it would be good thing on standalone system, but in AppVM
which loose its rootfs changes after restart it is a waste of resources.
Especially when it kicks in on multiple VMs simultaneously, while on
battery (apt-daily.service have ConditionACPower=true, but VM don't have
that information...).
It would make some sense on TemplateVM/StandaloneVM, but then it kicks
in just at VM startup. Which conflicts with starting the update manually
then (by clicking "update VM" button in manager for example, or using
salt).
So, disable this feature completely.
The actual solution is based on pkg-manager-no-autoupdate by @adrelanos.
FixesQubesOS/qubes-issues#2621
(cherry picked from commit 128af0d191)
(cherry picked from commit 475421b2e2)
Apparently some of this commit got reverted during cleanup before
Qubes 3.0 release.
(cherry picked from commit f49042211b)
When qrexec-client-vm is started with socket on its stdout and no local
process requested, it will try to shutdown(SHUT_WR) this socket when
remote process exists. This is wrong, because this socket may be still
needed by other processes (for example shell from where qrexec-client-vm
was called).
In such a case, simple close() should be used.
(cherry picked from commit 6bddcfcb52)
1. If local process is started, report its exit code, instaed of remote
one. To get remote exit code, simply start qrexec-client-vm without
third argument (and connect its stdin/stdout with the other process some
other way).
2. Report process terminated by signal.
Don't pretend that process terminated by signal finished successfuly.
Copy shell behaviour of reporting it as 128+signum.
3. Do not wait() for any child process, just the one we expect. In case
of qrexec-client-vm the child process is started differently and
wait()ing on it inside main loop would break its exit code reporting.
FixesQubesOS/qubes-issues#2861
(cherry picked from commit ea0cd0fdc3)
Exit code 1 is very common in all kind of programs, including qrexec
services, so it is hard to distinguish remote failure from service call
refusal. Use something from top of the range here (but not 127, as it is
commonly used to report "Command not found")
QubesOS/qubes-issues#2861
(cherry picked from commit d2aa21625c)
This clarifies and also defines some corner cases like exit code
reporting.
QubesOS/qubes-issues#2861
(cherry picked from commit ff26dcfe53)
Man page stripped from Qubes 4.0 features.
It is expected to be killed by a signal. Exit with returncode 0 anyway.
While at it, adjust it for current service format (executable, with
proper shebang).
(cherry picked from commit 22002a34f3)
When /etc/yum.conf is not present (yum-deprecated not installed), don't
try to append to it. It would result in invalid configuration file -
without any section header, and break yum when installed later.
This looks like an overkill. And more importantly - required modules are
not installed by default, making it impossible to use in default minimal
template.
FixesQubesOS/qubes-issues#1610
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
Qubes-specific options must be added in NetworkManager.conf, even if
those lines are commented out by default. The problem is solved by using
extended regular expressions.
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
When trying offline resize2fs, it require running fsck first, which
takes time, especially on large volumes. And in most cases, resize2fs
will notice that no action is needed - after wasting some time on fsck.
To remedy this, use resize2fs in online mode (on mounted filesystem).
And drop fsck call if it fails (filesystem is already mounted
read-write, running fsck isn't good idea).
But do not remove fsck call completely - still call it, but without '-f'
flag, so it run actual check only when really needed (unclean shutdown,
last check far in the past etc).
FixesQubesOS/qubes-issues#979FixesQubesOS/qubes-issues#2583
