On Mon, Jul 2, 2018 at 12:13 PM Marek Marczykowski-Górecki
<marma...@invisiblethingslab.com> wrote:
> Hash: SHA256
> On Mon, Jul 02, 2018 at 05:17:31PM +0200, Johannes Graumann wrote:
> > Would there be possibilities to bring a in my experience much more
> > approachable ansible option closer to the core and integrate it into
> > the code base overseen by Invisible Things? Maybe by contracting Rudd-
> > O?
> I think yes. But someone would need to implement it. Having Ansible as
> first-class citizen in Qubes requires:
> 1. Direct integration with Admin API / qvm-* commands / qubesadmin python
> module, instead of converting ansible -> salt -> qvm-* commands.
> Generally make managing VMs with Ansible independent of Salt. Admin API
> allows to do all that from selected VM, instead of dom0 (as it was
> before Qubes 4.0).
> 2. Make VM management more isolated - namely do not parse complex data
> returned from managed VM. Displaying success/fail info and a text
> message should be ok, but an interactive protocol is not.
> Salt (namely: salt-ssh) provides a method to package all the
> required configuration into a single tarball, which then can be send
> and executed - this was AFAIR one of main reasons why we've chosen Salt.
> But later it turned out making that tarball needs some input from "remote"
> system ("grains" - things like what OS is there, various tools versions etc), 
> so
> we've added an intermediate DispVM which gets all salt configuration,
> ask target VMs for "grains", then create a tarball and sends it there.
> Each target VM have own DispVM for that created on demand.
> This way if anything compromise the code parsing "grains" (or any
> related structure), it will not gets an access to neither dom0, nor
> other VMs. See relevant ticket[1] for design discussion about this.
> We need something with similar properties for Ansible. If there is a
> mode with uni-directional communication with target VM, it should be
> enough, otherwise a similar scheme as for Salt needs to be done.
> Manuel, would you be interested in working on this?
Over the weekend I actually thought over the problem, and wanted to have
something as close as possible to the upstream Ansible for the same.

The result is is availble at [1]. This has three major things.

1. One *qubes* connection plugin for Ansible
   This allows dom0 and any domU (with proper policy) to do things
 inside of a VM. Means installing packages, copy/fetch files etc.

I have also opened a PR to the upstream Ansible to add this in the

2. To make 1 happen, I added a small qrexec service *qubes.Ansible*.
To do things from dom0, we only need that service in the target AppVMs
or templates. There is also a command line tool (basically service
name changed from
qvm-run-vm command) *qvm-ansible* which will be used by domU VMs to connect
and do things inside of other VMs.

3. A pure Python Ansible module (named: qubesos) to
create/destroy/manage state of the

Now, for now I have tested point 3 only from dom0. Point was tested
from both dom0 and domU VMs.

The Python module will require a lot of other things to make it 100%
compatible with
standard qvm*/qubes-* tools.

I have added examples in the repo. I managed to ran random playbooks
(which I use
in other places) using this. I would love to have feedback on this.

Note: This does not use Salt anywhere.

[1] https://github.com/kushaldas/qubes_ansible

Staff, Freedom of the Press Foundation
CPython Core Developer
Director, Python Software Foundation

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 
For more options, visit https://groups.google.com/d/optout.

Reply via email to