No more ugly symlink creation at VM startup, nautilus-actions have system-wide
dir (in opposite to nautilus-scripts).
Currently old symlinks are not cleaned up. Maybe it should, but leaving them
have one advantage: will not break existing users behavior.
Upgrade of kernel is suppressed by qubes-vm-kernel-placeholder package.
Excluding xorg packages makes more problems than goods (e.g. unable to
install dummy driver, block fedora bugfixes).
%setup macro must be present in %prep to set variables required by
find-debuginfo script. Symlink is to place sources in nice
/usr/src/debug/%{name}-%{version} subdir instead of plain /usr/src/debug/core
(which can be ambiguous).
Additionally all packages need to have _builddir pointing at top src dir (in
core-dom0 it was dom0 subdir). And to cheat make about current dir (to have
%{name}-%{version} included in path) chdir must be done by shell, not make - so
can't use make -C.
This libs are required by both dom0 and VM so it's better to have it
separately. Previously in VM it was separate package, but dom0 have them
embedded in qubes-core-dom0, but qubes-core-vm-libs package was used to build
qubes-gui-dom0. Now we do not build all packages for all distros (especially do
not build core-vm package for dom0 distro, so gui-dom0 build fails), so make it
explicit which package is needed by which system.
Some packages depends on kernel (ex fuse, pulseaudio), but kernel in VM is
managed by dom0. Any hack like exlude or so on will break some things, so
install empty placeholder package to fulfill dependencies.
1. Try to use NetworkManager sleep command instead of shutting it down
2. Move sleep action details (which is VM-specific) to VM
3. Export it as qrexec service(s)
Actually all /etc/pam.d/ files containing pam_systemd.so are autogenerated by
authconfig, so "removing" pam_systemd.so file as not elegant solution, seems to
be much more realiable.
The simplest way is just add proxy=... entry to /etc/yum.conf, but sometimes it
is reasonable to bypass the proxy. Some examples:
- usage of non-standard repos with some exotic file layout, which will be
blocked by the proxy
- usage of repos not-accessible via proxy (eg only via VPN stared in VpnVM)
This commit introduces 'yum-proxy-setup' pseudo-service, which can be
controlled via standard qvm-service or qubes-manager. When enabled - yum will
be configured at VM startup to use qubes proxy, otherwise - to connect directly
(proxy setting will be cleared).
Introduce proxy service, which allow only http(s) traffic to yum repos. The
filter rules are based on URL regexp, so it isn't full-featured content
inspection and can be easy bypassed, but should be enough to prevent some
erroneus user actions (like clicking on invalid link).
It is set up to intercept connections to 10.137.255.254:8082, so VM can connect
to this IP regardless of VM in which proxy is running. By default it is
started in every NetVM, but this can be changed using qvm-service or
qubes-manager (as always).
In FC15, NetworkManager by default uses global connections ("Available to all users"). Save them in /rw instead of /etc, to preserve them across reboots.
This will work when device is unmounted. On mounted device backend will be
removed (after 3s timeout), but frontend will left in "closing" state - manual
'xl block-detach' will be needed.
It is build upon qrexec2, qubes.VMShell command. So, in order to e.g.
start firefox in a fresh dispVM, do
qvm-run '$dispvm' firefox http://www.qubes-os.org
Get kernel from global kernels dir (/var/lib/qubes/vm-kernels), not per-VM. Can
be configured by qvm-prefs (kernel parameter).
New tool: qvm-set-default-kernel
For backward compatibility kernel=None means kernel in VM dir (kernels subdir).
(possibly empty) modules.img should be created in it.
Mainly 4 parts:
- scripts for providing rpmdb and yum repos to VM (choosen by qvm-set-updatevm)
- VM script for downloading updates (qubes_download_dom0_updates.sh)
- qfile-dom0-unpacker which receive updates, check signatures and place its in dom0 local yum repo
- qvm-dom0-upgrade which calls all of above and after all yum gpk-update-viewer
Besides qvm-dom0-upgrade, updates are checked every 6h and user is prompted if
want to download it. At dom0 side gpk-update-icon (disabled yet) should notice
new updates in "local" repo.
After yum transaction (install/upgrade/remove),
yum-plugin-post-transaction-actions will execute script which trigger
qvm-sync-appmenus in dom0 (through qrexec).
THIS INTRODUCE NEW PREDEFINED COMMAND IN QREXEC
Ex. gpk-application needs this to work properly while running from user. When
root password is set - polkit-daemon asks for it (according to polkit setting).
