On 11/17/21 18:19, Marek Marczykowski-Górecki wrote:
On Wed, Nov 17, 2021 at 05:05:01PM +0000, Zrubi wrote:
user@dom0 ~]$ sudo grep sys-net /etc/libvirt/libxl/sys-firewall.xml
<backenddomain name='sys-net'/>
This seems like a hidden property, as not show on the GUI, but not even
using qvm-prefs.
It is in qvm-prefs very explicitly: a netvm property of sys-firewall.
Hmm, then it was just not is sync for some reason:
name - sys-firewall
netvm - WiFi
But now the .xml and the output of the qvm-prefs are in sync, so not
sure how it happened - maybe I just missed something. Sorry for the lame
question then :)
user@dom0 ~]$ grep sys-net /etc/qubes/policy.d/90-default.policy
# Default rule for all TemplateVMs - direct the connection to sys-net
qubes.UpdatesProxy * @type:TemplateVM @default allow
target=sys-net
^^ Maybe this is triggering it?
This is what templates will use to download updates from, see
https://www.qubes-os.org/doc/how-to-install-software/#updates-proxy
So, yes, if you want to use something else, you do need to change it
(but I recommend creating a new file with lower number and putting your
rule there - it will take precedence over later rules).
Yeah, I was found it meanwhile...
And thanks for the advice, makes sense to not mess up the default :)
So my 'issue' just shifted to have a qubes-updates-proxy process
somewhere else than sys-net.
Previously I was running it in my sys-firewall.
Now it is a DVM by default, and I can't find the way how to run the
qubes-update-proxy in this case.
Any advise about this please?
Thanks:
--
Zrubi
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/c4b913eb-3a46-f899-4a87-8a3c118f20f6%40zrubi.hu.
