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
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
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
If root filesystem is the last partition (new layout), resize it
in-place. Use 'parted' tool because it can resize just one partition,
without need to specify the whole new partition table. Since the
partition is mounted, parted is unhappy to modify it. Force it by
answering to its interactive prompts, and add (apparently not
documented) ---pretend-input-tty to use those answers even
though stdin is not a tty. Split the operation into multiple parted
calls, for more reliable interactive prompts handling.
Qubes 3.x disk layout (no partition table) is also supported, but the
one that was used in Qubes 4.0 rc1 (root filesystem as the first
partition) is not.
FixesQubesOS/qubes-issues#3173QubesOS/qubes-issues#3143
* fixes-20171002:
qubes.ResizeDisk: handle dmroot being a symlink
qrexec: use user shell instead of hardcoded /bin/sh
qrexec: code style fix - use spaces for indentation
Add convenient wrappers for qvm-copy-to-vm and qvm-move-to-vm
Currently building the package fails with an error 'qubes-r3.2: key "2043E7ACC1833B9C" is unknown'.
This also harmonizes the code with the current documentation: https://www.qubes-os.org/doc/templates/archlinux/#binary-packages-activation
(cherry picked from commit 5662d7e5fe7f5236a2623f725b7e0f908d26631f)
Without this change the package builds successfully but there is a
file conflict error when installing it.
(cherry picked from commit 4f26267796fa856d1e3a2883494b7cc09221b2e9)
Default `ask` policy ignore target domain specified by the caller, so it
doesn't make sense to specify one. Provide convenient wrappers not
needing one. Do not change behaviour of existing tools for compatibility
reasons.
FixesQubesOS/qubes-issues#3141
Explicitly block something like "curl http://127.0.0.1:8082" and
return error page in this case. This error page is used in Whonix to
detect if the proxy is torrified. If not blocked, it may happen that
empty response is returned instead of error. See linked ticket for
details.
This was previously done for 10.137.255.254, but since migration to
qrexec-based connection, 127.0.0.1 is used instead.
FixesQubesOS/qubes-issues#1482
* qubesos/pr/53:
Handle fallthrough with attribute(noreturn) for consistancy and compatiblity with older GCC
Add CENTOS/RHEL support (drop fedora-release dependancy as template builder will install it anyway and here it only make harder to support non-fedora builds)
Few reasons for this:
1. new templates use dnf to download packages, so yum.conf is unused
2. dom0 in Qubes 4.0 don't have this file at all (so sed fails here)
3. $OPTS already contains --setopt=reposdir=...
FixesQubesOS/qubes-issues#2945
Some services require GUI access. Make qrexec-agent handling this, based
on per-service configuration, instead of forcing every caller to call
qubes.WaitForSession service first. This is especially important for
Disposable VMs, because those are destroyed after a single service call.
This needs to be done in qrexec-agent (instead of service script, or
qubes-rpc-multiplexer), because agent will behave differently depending
on GUI session being available or not. Namely, will use
qrexec-fork-server (so the process will be a child of session leader),
or will open new session.
Service configuration lives in /etc/qubes/rpc-config/SERVICE_NAME, can
can contain 'key=value' entries (no space around '=' allowed). Currently
the only settings supported is 'wait-for-session', with value either '0'
or '1'.
QubesOS/qubes-issues#2974
