My goal is to be able temporarily to install packages into disposable sys-firewall.
Its template and dvm-template are set to be updated via cacher (the latter over qrexec too, but irrelevant), so consequently sys-firewall is. This won’t work for sys-firewall, since its provides_network pref is, logically, set to True.
So, for template and dvm-teplate, repos contain http:HTTPS///, and I want sys-firewall repos to contain default, regular http(s):// in order to achieve my goal.
Where and how can I set regular repo files, so sys-firewall could be updated via sys-net, while at the same time its templates to be updated via cacher?
Part of the issue is you have to change the line in 30.user-something in etc/qubes/policy.d as well. And if you’re trying to do things simultaneously (you didn’t indicate so, but just in case) that file needs two values at the same time.
Were it not for that, it’d be easy: Just change the files on that one VM…done, and the right thing would happen to that VM. But alas, the 30.user-something entry is what actually mandates what will be used for updates…it’s just that the template had better have matching code in repos (or the deb11 equivalent).
My salt scripts (adapted from Unman’s work) have the sys-cacher AppVM change the entry in 30-user-something when it is created, and then each template when it gets configured starts with, essentially: does sys-cacher exist? If so change the repos files one way, otherwise, change them the other way. After that all packages will be installed the correct way. (The hitch is that since those recipies work in the target machine environment, not dom0, I had to use a salt grain to denote whether sys-cacher is present. Whether or not there is a better way to do that was going to be my next question to unman once the menu mess is addressed.)
Thanks for the tips, but I’m not sure it’s about the policies, which means most probably I wasn’t clear enough. Let me try to rephrase:
In fedora-36-template and fedora-36-dvm-template I have repos 1, 2 and 3.
I have disposable sys-firewall based on fedora-36-dvm-template.
What I have to do in order to persistently have only repos 2 and 3 for example in sys-firewall? I know I can manually delete repo 1 in sys-firewall upon each start, but as I said, I’d like to have permanent configuration for sys-firewall repos which differ from templates.
This is an interesting question.
There was a long debate (primarily between Insurgo and me) about the
correct treatment here,which remained unresolved because of my enforced
absence.
The simplest answer is to rewrite the repository definitions:
if a Debian qube,it’s simple:
sudo sed -i s^http://HTTPS///^https://^ /etc/apt/sources.list
sudo sed -i s^http://HTTPS///^https://^ /etc/apt/sources.list.d/*
sudo apt update
If it’s a Fedora qube, a little more complicated:
sudo sed -i s^http://HTTPS///^https://^ /etc/yum.repos.d/*
sudo sed -i -E 's/metalink(.*)basearch.*/metalink\1basearch' /etc/yum.repos.d/*
sudo dnf update
That’s all you need to do.
If you want to make this change permanent you can put the relevant
lines in to /rw/config/rc.local
Insurgo thinks you should be able to use the proxy by default in
ordinary qubes,and this should be configured automatically.
I think this is a mistake, because I don’t want to make it easy for users
to install software into qubes, when in most cases they want to install
that software in to the relevant template. (Also the tedious cacher install
would be more so if it included rewriting every qube as well as every
template.)
Well, as I see it he’s talking about apples, and you about oranges.
There is a case where this simply is needed sys-firewall/net to be able to update over cacher: in case it’s template and dvm-template are never started again! So even there is a running qube based on them, template will never get a notification of an update if not started itself. Or such a sys-firewall/net will get notifications regardless of repo links containing HTTPS/// or not?
So, these were apples
And these are oranges. If you don’t want to let them to install, don’t prevent them to get notifications in case described above. Instead, enable only dnf/apt/... update in AppVM/dispVM.
Thanks for the tip. I was afraid it would be rc.local. I will try it and will be back with the results.
I meant here probably something like dnf check-update to be enabled, but not updating actually, if that is enough for dom0 to get a notification for the template.
Well, when applying this in dvm-template’s rc.local, it turned out that I was checking your tip only in sys-firewall. While it works as I’d like it in sys-firewall, it doesn’t work as I’d like it in its dvm-template, because if I start dvm-template, the change is (logically?) applied there too but as I said, in a dvm-template I’d like to be able to update only via cacher.
Eventually, my workaround was deciding to use systemd rc-local.service because later it is easy to add more (startup) commands when needed, without creating more systemd services.
For what additional reason I took this method? Because it allows settings to be applied independently to a dvm-template or dispVms, or both and a bit more quickly then the method described above while leaving room for further customizing. Also, there are known issues with executing rc.local at boot and this method doesn’t involve running it on boot, but in systemd.
Here’s how I did it (for noobs like me):
Created rc.local in a dvm-template that overrides default settings (repo links in this case in a way described above for example) and put it in /home/user/documents folder (or wherever it can survive reboot, except default location).
In a dvm-template’s /rw/config/rc.local I configured rc.local under 1. to be copied to /etc and /etc/rc.d/. Just that.
So when started, both dvm-template and dispvm based on it will have those files copied but neither will have effect until systemd service is started
sudo systemctl start rc-local.service
Run the service in disposable and you’ll get customized repos, while at the same time repos will be in the default state in a dvm-template.
Remember not to enable service on startup, or this won’t work. Only manual starting provides the goal from the OP.
I still hope there’s an automated solution to this.
I have to admit I still can’t figure out how the reference to sys-cacher in the policy.d files hasn’t been messing with this. From what I’ve seen over on my system, that (and that alone) governs what will be used for updates, and if your specific VM doesn’t have the right stuff in the repos files to match that, you’re basically not going to get anywhere. (The unman cacher setup makes sure both are set appropriately and can also undo both if desired.)
Yes but that governs templates only. Not dvm-templates (AppVM) nor dispVM. You can use either http://, or http://HTTPS/// via cacher.
In addition, qubes that have provides_network True enabled, cannot be updated via cacher. There you can use only http(s)://
Ah, OK then, learn (realize) something new every day. Thanks.
I actually do just about nothing to dvm templates once they are created. (In my schema there’s a -create.sls but no -configure.sls; the latter would install software or make other changes–if it existed.) The few things I was doing to them a month or two ago I realized could ALL be handled by adjusting things in /etc/skel in the template (i.e., it was user preference stuff or setting up a directory or something like that).
AppVMs on the other hand are a bit of a different story…I’ve got nine of those left now and one of those is on the chopping block to get converted to a dvm-template. The other eight are qubes that just need persistent user data (e.g., and most notoriously, my email client) in the qube. Sometimes it’s not much, but it’s critical. Of course sys-cacher is one of these.
In fact the more I think about it the more I wonder why you’re trying to update either a dvm-template or an appvm in the first place. My old “updates” to them are invariably user configuration (and the original file is on dom0) not software.
This is not true.
When provides_network is enabled, tinyproxy is automatically configured
to listen on port 8082 and started.
So you cannot use qrexec through port 8082 to cacher.
If you want to update via cacher stop and disable the tinyproxy service,
and enable update via qrexec.