Prepend "-" to shell name, to instruct it being a login shell. This way
shell will initialize environment, load /etc/profile etc.
FixesQubesOS/qubes-issues#2903
Since some systemd services are moved to other packages, appropriate
%post/%preun should contain the code to enable/disable them.
FixesQubesOS/qubes-issues#2894
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
When there is only console=hvc0 (i.e. no output to emulated VGA) and
GRUB_TIMEOUT is set to 0, VM startup hangs. This may be very well some
race condition broken by either of console=tty0 or GRUB_TIMEOUT > 0, but
even in such a case, apply this as a workaround for now.
Instead of calling 'su' to switch the user, use own implementation of
this. Thanks to PAM it's pretty simple. The main reason is to have
control over process waiting for session termination (to call
pam_close_sesion/pam_end). Especially we don't want it to keep std* fds
open, which would prevent qrexec-agent from receiving EOF when one of
them will be closed.
Also, this will preserve QREXEC_AGENT_PID environment variable.
FixesQubesOS/qubes-issues#2851
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.
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.
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
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
This configuration isn't included twice - it's Debian post-installation
script of grub that copy settings to /etc/default/grub, which results in
parameters being duplicated. Leave it as is for now.
Add GRUB_TIMEOUT=0 for faster VM startup.
QubesOS/qubes-issues#2577
Qubes VM require few config options in grub. Ship appropriate
configuration. Debian have grub.d support, so it can be done cleanly.
On Fedora, /etc/default/grub needs to be modified. Still keep the
options in separate file, but include it manually from
/etc/default/grub.
QubesOS/qubes-issues#2577
- there are many netcat versions (openbsd, nmap, ...), which behave
differently - especially while handling EOF
- Debian jessie doesn't have nmap-ncat (which handle EOFs sufficiently
good)
QubesOS/qubes-issues#1854
While it doesn't make sense to install qubes-core-agent without qrexec,
it may make sense to do the otherway around - install just
qrexec-agent without all the qrexec services and configuration. For
example on some pre-installed system.
QubesOS/qubes-issues#2771
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).
When a file is moved to other package, the new package needs Replaces:
and Breaks: dependecies on old package. Otherwise dpkg will refuse to
change file ownership.
QubesOS/qubes-issues#2771
This will save a lot of dependencies if networking is not needed in VMs
based on given template. Thanks to updates proxy over qrexec, template
itself do not need to have network configured too.
QubesOS/qubes-issues#2771
In Fedora it makes little sense, but in Debian it allows to avoid a lot
of dependencies. So split in both, to keep it simple.
QubesOS/qubes-issues#2771
This is meant to notify dom0 about features supported by just-installed
template. This service is called by dom0 just after template
installation.
FixesQubesOS/qubes-issues#1637
Documentation pending: QubesOS/qubes-issues#2829
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
