2017-05-29 06:28:37 +02:00
|
|
|
etc/dhclient.d/qubes-setup-dnat-to-ns.sh
|
|
|
|
etc/qubes-rpc/qubes.UpdatesProxy
|
|
|
|
etc/qubes/ip6tables.rules
|
2017-12-03 03:30:53 +01:00
|
|
|
etc/qubes/ip6tables-enabled.rules
|
2017-05-29 06:28:37 +02:00
|
|
|
etc/qubes/iptables.rules
|
|
|
|
etc/tinyproxy/tinyproxy-updates.conf
|
|
|
|
etc/tinyproxy/updates-blacklist
|
|
|
|
etc/udev/rules.d/99-qubes-network.rules
|
|
|
|
etc/xen/scripts/vif-qubes-nat.sh
|
|
|
|
etc/xen/scripts/vif-route-qubes
|
|
|
|
lib/systemd/system/qubes-firewall.service
|
|
|
|
lib/systemd/system/qubes-iptables.service
|
|
|
|
lib/systemd/system/qubes-network.service
|
Move network uplink setup to a separate service
Previously, network uplink (eth0) was configured in two places:
- udev (asynchronously)
- qubes-misc-post.service - at the very end of the boot process
This caused multiple issues:
1. Depending on udev event processing (non-deterministic), network
uplink could be enabled too early, for example before setting up
firewall.
2. Again depending on udev processing, it can be enabled quite late in
the boot process, after network.target is up and services assume
network already configured. This for example causes qubes-firewall to
fail DNS queries.
3. If udev happen try to enable enable networking even earlier, it may
happend before qubesdb-daemon is started, in which case network setup
fill fail. For this case, there was network re-setup in
qubes-misc-post service - much later in the boot.
Fix the above by placing network uplink setup in a dedicated
qubes-network-uplink@${INTERFACE}.service unit ordered after
network-pre.target and pulled in by udev based on vif device existence,
to handle also dynamic network attach/detach.
Then, create qubes-network-uplink.service unit waiting for appropriate
interface-specific unit (if one is expected!) and order it before
network.target.
QubesOS/qubes-issues#5576
2020-11-12 01:37:12 +01:00
|
|
|
lib/systemd/system/qubes-network-uplink.service
|
|
|
|
lib/systemd/system/qubes-network-uplink@.service
|
2017-05-29 06:28:37 +02:00
|
|
|
lib/systemd/system/qubes-updates-proxy.service
|
|
|
|
usr/lib/qubes/init/network-proxy-setup.sh
|
2020-11-12 00:53:48 +01:00
|
|
|
usr/lib/qubes/init/network-proxy-stop.sh
|
Move network uplink setup to a separate service
Previously, network uplink (eth0) was configured in two places:
- udev (asynchronously)
- qubes-misc-post.service - at the very end of the boot process
This caused multiple issues:
1. Depending on udev event processing (non-deterministic), network
uplink could be enabled too early, for example before setting up
firewall.
2. Again depending on udev processing, it can be enabled quite late in
the boot process, after network.target is up and services assume
network already configured. This for example causes qubes-firewall to
fail DNS queries.
3. If udev happen try to enable enable networking even earlier, it may
happend before qubesdb-daemon is started, in which case network setup
fill fail. For this case, there was network re-setup in
qubes-misc-post service - much later in the boot.
Fix the above by placing network uplink setup in a dedicated
qubes-network-uplink@${INTERFACE}.service unit ordered after
network-pre.target and pulled in by udev based on vif device existence,
to handle also dynamic network attach/detach.
Then, create qubes-network-uplink.service unit waiting for appropriate
interface-specific unit (if one is expected!) and order it before
network.target.
QubesOS/qubes-issues#5576
2020-11-12 01:37:12 +01:00
|
|
|
usr/lib/qubes/init/network-uplink-wait.sh
|
2017-05-29 06:28:37 +02:00
|
|
|
usr/lib/qubes/init/qubes-iptables
|
|
|
|
usr/lib/qubes/iptables-updates-proxy
|
|
|
|
usr/lib/qubes/qubes-setup-dnat-to-ns
|
|
|
|
usr/lib/qubes/setup-ip
|
|
|
|
usr/lib/tmpfiles.d/qubes-core-agent-linux.conf
|
2019-11-26 00:47:08 +01:00
|
|
|
usr/bin/qubes-firewall
|