Use features macros (QREXEC_RING_V2 and ASYNC_INIT) instead of directly
depending on building environment. The macros are turned on (when required) in
libvchan.h based on target system.
When device is ejected by some VM (state=6, effectively inactive), it should be
removed from xenstore to free slot for some another device. This should be done
by libxl toolstack, but not implemented in xen 4.1 - AFAIR done in xen 4.2.
To simplify configuration, automatically enable 'yum-proxy-setup'
pseudo-service when allowing access to the proxy. Also disable this service,
when access is revoked. Thanks to this the user can enable this feature by one
click in firewall settings.
New setting for access to qubes-yum-proxy. The difference from other firewall
setting (and reason for new top-level setting): 'deny' is enforced even if
policy is set to 'allow'. This proxy service is mainly used to filter network
traffic, so do not expose it to VMs which can connect to any host directly (eg
'untrusted' VM).
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).
On FC>=15 /var/run is on tmpfs, so /var/run/tinyproxy from rpm don't survive
reboot. This is bug in Fedora package (should include config file for tmpfiles
service). For now create dir just before starting service.
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).
To simplify configuration, automatically enable 'yum-proxy-setup'
pseudo-service when allowing access to the proxy. Also disable this service,
when access is revoked. Thanks to this the user can enable this feature by one
click in firewall settings.
New setting for access to qubes-yum-proxy. The difference from other firewall
setting (and reason for new top-level setting): 'deny' is enforced even if
policy is set to 'allow'. This proxy service is mainly used to filter network
traffic, so do not expose it to VMs which can connect to any host directly (eg
'untrusted' VM).
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).
On FC>=15 /var/run is on tmpfs, so /var/run/tinyproxy from rpm don't survive
reboot. This is bug in Fedora package (should include config file for tmpfiles
service). For now create dir just before starting service.
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).
