Many users protect their ssh keys with passwords, and ssh-agents
therefore require manual intervention.
I suppose you could modify SshAgent service to parse the input, check if
the relevant agent is running and start it if it is not, but that is
different from the current use case.
thanks for your reply.
agent is running automatically anyhow, just still didn’t got a plan how im able to run the correct agent script and delete the keys after i used them (from the keys-add).
maybe i will solve that by just cloning the vm.
so i’ll add the scripts to my service, so they would run if the vm is starting.
but thats not my first priority at the moment.
I dont understand youo
sorry, got night shifts since 2 weeks now and i got the feeling i burned out or something similiar, working on the easiest issues for over an hour atm.
my native language is pretty similiar to my english atm.
anyhow, i meant i have to figure out, how i’m able to trigger the coding-agent.sh if my coding vm is requesting the ssh keys.
how they get “deleted” i found this already out, i meant this command:
ssh-add -t <secs> ...
i also messed up my qubes policy now, i was wanted to change ask to allow because i have to rebase a git repo and i dont want to press ok 300 times.
if im changing to allow, the vm isn’t able to get the private key and it seems like as my qrexec would stop working because im also not anymore able to copy and paste from or to the public clipboard.
if im changing back everything to ask, everything will work again.
There is no facility to automatically add keys on demand.
You can simply add keys on start up of the service by editing the
relevant NAME-agent.sh script to include the keys you want.
If you want this you cant use keys with passwords or time limited keys,
both of which are good practice, but wont work with automation,
obviously.
This shows you have introduced a syntax error in the file.
I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.Did the sys-vpn issue get put in a different thread? I was following that conversation while troubleshooting my issue, which is exactly what others were describing. I came to the conclusion it’s something with my cacher but I didn’t see a clear resolution. I’m doing a full set of updates by unchecking the box and telling it to look for updates because I think unman mentioned that at one point. If that doesn’t work I’m guessing I need to find out what failed in the install? The VM is kind of difficult to work on since it’s PW protected now and I can’t even get the gpk-update trick I found in a different thread.
I was looking through the page for sys-vpn on the github and am guessing going through each of those individually may work too? I’m still learning the whole salting concept but have worked with various scripting languages and can follow along enough to not be totally confused, but I definitely don’t have anywhere near an understanding as many in this thread.
I’d prefer to keep this thread for discussion of the tool, and to
separate out support issues.
Can you move this to a new thread in user Support with some details of your
problem? I understand you have a cacher, but you dont say what your
problem is.
No worries. It was more of me asking if a solution had been found for something identified earlier in this thread. I realized it might be partially self inflicted because of my misunderstanding on cacher role. Either way I’ll create new thread as requested. Thank you.
You still haven’t said what the problem is.
No need for a new thread - if you cant split this off to a new thread,
one of the @mods can.
My bad, I didn’t want to muddy the conversation here. The TLDR was that I started having apps that I was installing from your tool not work from the start with the easiest example of like for like issues was with the openvpn qube. It basically wasn’t working, was missing some of the services mentioned it should have, and was prompting for a password to do anything on it.
During my troubleshooting though I realized that I also wasn’t doing things when I was adding templates like updating sources for devices / templates for the cacher. I was just doing things as I was before installing that and read that wasn’t the correct process. I’m still relatively new to the Qubes ecosystem, but am fascinated with the potentials of the platform. I’ve actually scrapped that build and am working through trying to get a detached /boot version going now, so this isn’t an issue, but I didn’t really fix it either. I just keep realizing there is more to wrap my head around regarding the bigger picture of how it works and trying to learn but trying to avoid bad habits or cutting corners. I do appreciate the follow up but I didn’t open any other threads and just moved onto a different set of problems unrelated but also probbaly the me needing to find right document one.
The monero wallet set of qubes does not work.
I tried installing it via this tool on a fresh Qubes 4.1.2 install. Once monerod fully synced with the network, I opened monero-wallet-ws and attempted to open a wallet. It fails to connect to the daemon.
Thank you for that feedback.
I will see what the issue might be.
1 Like
Can anybody point me to the solution, if there’s one…
Issue still is, that since I installed cacher on my system (4.1.2) the fedora (35, 36, 37) qubes didn’t update anymore (or at least updating with errors).
I understand, that this issue still wasn’t fixed yet (or whatever the problem is, clouldn’t be fixed yet).
Question now is:
Will I be able to update the Fedora qubes again, by uninstalling the complete qubes-task.manager ?
@unman ? @anyone ?
You never have to use the cacher for your Fedora templates (for any templates really, using the cacher is always optional).
Assuming they’re currently set up to use the cacher, there are two aspects to ensure they don’t anymore:
- Set the source of updates to some other qube than the qube that provides caching in your setup, e.g.
sys-whonix. This way, updates will be downloaded from that qube instead of the cache. - Edit the repository configuration in each of your templates to use
https://instead ofhttp://HTTPS///(quoting from memory). Doing it manually can be tedious, but @unman’s repository contains a script to do that.
Does this informatiom make sense to you @TheGardner ?
1 Like
Thats a plan! Will try this out!
Looks like there’s a config on every qube, where you can setup the source of updates separately. Always was thinking, you do that globally (with the update qube in qubes settings [which is sys-whonix on my setup])
Two cents advice: start with one, and repeat one you’ve got the process right 
There are few things more annoying in my experience than troubleshooting a process that didn’t go right n times in a row instead of only once!
Yes - I’ve been tweaking the Fedora config to get those updates working.
Almost invariably the issue arises with the “updates” repository, and I
think that it relates to incorrect mirroring of the updates repo across
the mirrors. If I clear the cache (dnf clean all), and retry later,
updates usually work.
Whether you use cacher is determined by an entry in
/etc/qubes/policy.d/30-user.policy
The entry is this:
qubes.Updates.Proxy * @type:TemplateVM @default allow target=cacher
You can override this by inserting a line ABOVE this one, because policy
is applied to the first match.
qubes.Updates.Proxy * fedora-37 @default allow target=sys-net
This will mean that fedora-37 uses sys-net for updates, while all other
Templates use cacher.
Make any other changes you want.
(If you want to stop using cacher all together you can just delete the
cacher line, and then policy will revert to the default in 90-default.policy
using sys-net.)
When you set up cacher, repository definitions were rewritten to allow
for use of HTTPS repositories.
If you want to use something other than cacher you need to revert these
changes. There is a salt file in /srv/salt/cacher to help you do this.
You apply it like this:
sudo qubesctl --skip-dom0 --targets=TARGET1,TARGET2,TARGET3 state.apply cacher.restore_templates
This file will revert the changes in Debian based, Fedora and Arch templates.
If you inspect the restore_templates.sls you should see that it
replaces patterns in the repository definitions.
The process is (should be) relatively straightforward.
I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
4 Likes
I have installed the @unman software successfully and proceeded to install the MullvadVPN package. It created two Qubes (template-mullvad and MullvadVPN). I received no errors during installation. It says in the instructions I should look for a menu entry called “Setup Mullvad VPN” in the Qubes Menu. I checked both those Qubes in the menu and none had an entry for “Setup Mullvad VPN” (and yes I refreshed to make sure).
What has gone wrong?