Tool: Simple Set-up of New Qubes and Software

I agree, absolutely. But my way is: when I don’t have enough knowledge to feel enough confident on the matter, I do it manually step by step and in a more restrictive way, trying to compensate the lack of knowledge until reaching the level needed to feel confident.

@unman, first of all thanks for the amazing salt stack and qubes-task-manager. They are truly a blessing.

I am using sys-agent-ssh. How do I have it to automatically perform ssh-add on boot?

I’ve tried putting ssh-add in everything but to no avail:

  • ~/.xinitrc
  • ~/.profile
  • ~/.bashrc
  • /rw/config/rc.local

It only works if I spin a terminal on the sys-ssh-agent then I get the toggle: Identity added: ...

@unman – a suggestion for the cacher vm installation:
add an option to remove qubes-update-check in each vm as a part of the process, or as part of a separate available process.
since it is now a useless service, i have gone through each VM (except those that don’t use cacher like whonix) and deactivated the service manually with:
qvm-service -d VMNAME qubes-update-check
but a clever way to automate this for all cacher updated vm’s would be welcome.

i also have to say, as an aside, that the cacher has improved my workflow-- by necessity. since i don’t get update notifications i now just run a bash script fixed to a hotkey, typically at startup once a day, that updates my net-vm’s, shuts them down, then updates my daily driver app-vms, and starts all my common use applications up. and with kde putting them each in their own workspace by default it is making my startup each day that much smoother, too.

thankyou for all your contributions here!

Can you share the bash script? I am also looking for some automation

Thanks @weyoun.six
I’m glad you find cacher useful. KDE is,of course, excellent in Qubes.

Rather than go through each individually, I could ship a batch file to
disable the service.
I do this myself,but the topic is still being hashed over here in the
Forum, how best to deal with updates in qubes with the cacher installed.

1 Like

I’ve added some new packages to provide:
a central sys-git to hold repositories - policy file controls access by
qube and repository;
a template with software useful for text to speech use;
split-gpg;
a split monero wallet;
syncthing - this includes a syncthing qube with net access, and a qrexec
service to run syncthing from other qubes,including those with no netvm.

More details are available in the Qubes Task Manager.
Sources is available on github

It would be more useful if this topic were kept for installation
problems of the Task Manager, and suggestions for packages to be
included, or contributions.
Issues with individual packages are best dealt with in a topic under a
clear title in User Support.

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

That’s fantastic!
I’ve been (unsuccessfully) trying to create a sys-git for quite a while. Have you gotten around to publishing the process in your notes?

Generally you create a simple systemd service like this, to start the
agent,and load the key

[Unit]
Description=SSH agent

[Service]
Type=oneshot
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK
ExecStart=/usr/bin/ssh-add [key]

[Install]
WantedBy=default.target

You’ll need to adapt this to the socket value you use for the agent - you
can see this in (e.g) work.agent.sh - and I haven’t tested it in any
way.
It wont do where you have passwords on the keys.

I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.

1 Like

No. It’s a little niche for the notes, and it’s basically documented here
All the work is done by qubes.Git and git-qrexec, which I’ve
generalised, and slightly adapted to allow for granular policy control.
My contribution is minimal.

1 Like

I had to change this slightly to (note the ExecStart => ExecStartPost):

[Unit]
Description=SSH agent

[Service]
Type=oneshot
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK
ExecStartPost=/usr/bin/ssh-add [key]

[Install]
WantedBy=default.target

Works like a charm. Thanks!

2 Likes

For anyone who was as confused as me, certain of these setups assume that you have already set up the cacher. Once I did that they worked fine, but before that they failed. So try that if you’re having problems with them!

Can you tell me for which you found this?
All of the template repo salting is conditional on there being a
“cacher” qube - otherwise the repo definitions should be left as they are.

If you found this not to be the case, then it’s a bug that needs to be
fixed. (Although I advocate for using a caching proxy, I don’t intend
to enforce it.)

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.

i forget which repo, but yes it happen to me too.

1 Like

Thanks - it looks as if it is the Pihole and Share packages that are
affected - this is wrong.
I’ll fix it.

1 Like

4 posts were split to a new topic: Salting I2P

so happy you did this

delete

perpare for r4.2 repo? so we dont need to change releasever.

6 posts were merged into an existing topic: Salting I2P

Not sure if it’s just me, but I’m getting 404 when trying to download the RPM from https://qubes.3isec.org/3isec-qubes-task-manager-0.1-1.x86_64.rpm. Is that still the way to install the tool? (I’ve already installed the keys) Or can it just be installed via dnf in dom0 now? (shiver up my spine) :slight_smile:

Thanks!

1 Like