On 1/4/19 3:08 PM, Brian C. Duggan wrote:
> 2. Salt should ensure that service VMs are running before Salt applies
> states to their client VMs. For example, I have a service VM that
> exports gpg-agent's SSH socket through Qrexec. This VM needs to be
> running so that the client VM can clone git repos using keys on the
> serivce VM.
> 

I did some more testing. Of course, Qubes starts halted VMs when another
VM makes a Qrexec RPC call to it. The calling process on the client VM
will block until the service VM starts and the RPC call returns. So this
isn't really a valid use case for orchestration.

At first, I thought the SSH authentication attempts failed because the
service VM wasn't started yet. After more testing, I can see that the
systemd socket service just doesn't work at the stage during initial
boot that Salt runs. The socket file exists at this stage, though. SSH
authentication succeeds during subsequent Salt runs after the VM is booted.

But I've also noticed that sometimes a new app VM's grain ID is still
the template's ID when Salt processes templates. This can be a problem
when both dom0 and app VMs need the same pillar data:

pillar/app/client-vm-1.sls:
app:
  client-vm-1:
    server-name: server-vm-1

pillar/app/client-vm-2.sls:
app:
  client-vm-2:
    server-name: server-vm-1

pillar/top.sls:
base:
  dom0,client-vm-1:
    - match: list
    - app.client-vm-1
  dom0,client-vm-2:
    - match: list
    - app.client-vm-2

dom0 needs the combined app data to set RPC policies between the clients
and their servers. The clients need their own data to configure which
service VM to send their RPC to. It's convenient for clients to find it
through pillar['app'][grains['id']]. Maybe there's a better way of
constructing this pillar data?

Is there a way to delay Salt execution on VMs until they are fully booted?

For the curious, I'm using a Salt formula to set up access to gpg-agent
on a service VM from client VMs through Qrexec:

https://gitlab.com/bcduggan/qrexec-gpg-agent-formula

Thanks,
Brian

-- 
Brian C. Duggan
he/him/his

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d3f8ee12-8498-d0b5-4537-abc2f8e3e8ee%40dugga.net.
For more options, visit https://groups.google.com/d/optout.

Reply via email to