On Mon, Jul 2, 2018 at 12:13 PM Marek Marczykowski-Górecki <marma...@invisiblethingslab.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > 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 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 . 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 core. 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 VMs. 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.  https://github.com/kushaldas/qubes_ansible Kushal -- Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in -- 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 email@example.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAAzeMbzH5Z%2BQY_J%3DVRoxHCCP1yGR9QV_tSVAV66w6JFni%3DE4dQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.