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!
:-)
Do not use a symlink there, as it will be left after NetworkManager
shutdown - as a broken link then
FixesQubesOS/qubes-issues#2320
Reported by Achim Patzner <noses@noses.com>
The systemctl in Debian unstable fails when trying to disable a removed
service. The manpage do not mention a switch to change this behaviour.
But it says:
Note that this operation creates only the suggested symlinks for
the units. While this command is the recommended way to manipulate
the unit configuration directory, the administrator is free to make
additional changes manually by placing or removing symlinks in the
directory.
So a simple rm should be fine.
This doesn't help when xen update is installed after this one. So, deal
with it in xen %post itself.
This reverts commit f2257e1e3b.
QubesOS/qubes-issues#2141
systemctl preset output lengthy warning when trying to operate on
non-existing unit. This preset action is meant to disable unit, so it's
even better it doesn't exists.
This have many advantages:
- prevent XSS (QubesOS/qubes-issues#1462)
- use default browser instead of default HTML viewer
- better qrexec policy control
- easier to control where are opened files vs URLs
For now allow only http(s):// and ftp:// addresses (especially prevent
file://). But this list can be easily extended.
QubesOS/qubes-issues#1462FixesQubesOS/qubes-issues#1487
xdg-open is more robust in choosing default application for particular
file type: it supports fallback if the preferred application isn't
working, and most importantly it support system-wide defaults
(/usr/share/applications/defaults.list,
/usr/share/applications/mimeapps.list), so no "random" application is
chosen.
By default xdg-open tries to use environment-specific tool, like
gvfs-open - which isn't good for us, because many such tools do not wait
for editor/viewer termination. That would mean that DisposableVM would
be destroyed just after opening the file.
To avoid such effect, we set DE=generic.
FixesQubesOS/qubes-issues#1621
No functional change.
This will make it easier to switch the tool (without recompiling
vm-file-editor), or even use differrent tools depending on some
conditions.
QubesOS/qubes-issues#1621
Many USB controllers doesn't play nice with suspend when attached to PV
domain, so unload those drivers by default. This is just a configuration
file, so user is free to change this setting if his/shes particular
controller doesn't have such problem.
FixesQubesOS/qubes-issues#1565
DNF in Fedora 22 uses python2, but in Fedora 23 - python3. Package both
of them, in separate packages (according to Fedora packaging guidelines)
and depend on the right one depending on target distribution version.
FixesQubesOS/qubes-issues#1529
Explicitly block something like "curl http://10.137.255.254: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.
FixesQubesOS/qubes-issues#1482
Apparently unmanaged devices are loaded only from main
NetworkManager.conf. Exactly the same line pasted (not typed!) to main
NetworkManager.conf works, but in
/etc/NetworkManager/conf.d/30-qubes.conf it doesn't.
BTW There was a typo in option name ("unmanaged_devices" instead of
"unmanaged-devices", but it wasn't the cause).
This reverts commit 6c4831339c.
QubesOS/qubes-issues#1176
Since this proxy is used only when explicitly configured in application
(package manager), there is no point in worrying about user
_erroneously_ using web browser through this proxy. If the user really
want to access the network from some other application he/she can always
alter firewall rules for that.
FixesQubesOS/qubes-issues#1188
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
Since /lib/modules is not mounted read-only anymore (only a selected
subdirectory there), it is no longer required to prevent kernel package
installation. Even more - since PV Grub being supported, it makes sense
to have kernel installed in the VM.
QubesOS/qubes-issues#1354
Initramfs created in TemplateVM may be used also in AppVMs based on it, so
technically it is different system. Especially it has different devices
mounted (own /rw, own swap etc), so prevent hardcoding UUIDs here.
QubesOS/qubes-issues#1354
Without dconf, gsettings uses "memory" backend which isn't saved
anywhere and isn't shared across applications. This makes gsettings
pretty useless.
FixesQubesOS/qubes-issues#1299
Do not modify main /etc/NetworkManager/NetworkManager.conf as it would
cause conflicts during updates. Use
/etc/NetworkManager/conf.d/30-qubes.conf instead.
Also remove some dead code for dynamically generated parts (no longer
required to "blacklist" eth0 in VMs - we have proper connection
generated for it). It was commented out for some time already
FixesQubesOS/qubes-issues#1176
