On 18-04-20 13:51:50, Marek Marczykowski-Górecki wrote: > On Thu, Apr 19, 2018 at 10:20:08PM +0200, viq wrote: > > Salt tools give a nice way to configure system (make sure templates exist > > with certain packages, prepare AppVMs based on them, etc). But I'd prefer > > to edit them in a customized editor, with syntax highlighting, etc, which > > is strongly discouraged from being put into dom0. I also feel that having > > version control over those files is the way to go, preferably synced > > somewhere so I can for example easily replicate this when setting up > > another computer or reinstalling. > > > > My understanding is that this is a perfect use case for new Admin API - > > have a machine with editor and git set up to adjust salt files, and either > > give admin permissions to that one, or use something like split-git that > > was mentioned to pull the repo into another VM and execute there. > > Yes, exactly. In theory it should be easily possible to setup management > VM with appropriate policy (see [1]) and use salt from that VM. The > thing you need to change is to make qvm salt module [2] working in vm, > right now it explicitly checks if its running in dom0. Hopefully this is > the only change you need. > > But there is one thing you can't that easily do over Admin API - various > dom0 settings. This include installing packages in dom0, editing various > configuration files (pam? bootloader? qrexec policy?). We're working on > the last one, but others are not solved right now. For multiple dom0 > changes you still need to run salt in dom0. > > For some cases, we use rpm packages to distribute salt formulas - this > include default setup (virtual-machines formula[3]) and our > infrastructure[4]. > For my personal machine, I use salt in dom0 and synchronize this > configuration using signed tarballs, manually...
Hm, salt has SPM[6], which I need to read a bit more about. On one hand, it's a native salt tool, so possibly it could work better for distributing, and more importantly updating states/formulas, but on the other hand, as far as I'm aware, it doesn't currently have concept of signing. > > Am I on the right track here? If so: > > 1) What packages do I need on admin VM to be able to do this? > > Most likely qubes-mgmt-salt-dom0-qvm[2] with its dependencies and > probably minor changes will be enough. The dependencies include at least > python2-qubesadmin. Oh, and qubesctl itself is in > qubes-mgmt-salt-admin-tools[5]. > > > 2) Where and how should I be executing this? A quick test of running > > qubesctl inside a VM didn't even produce logs in dom0 journal, the command > > just complained it can't reach a daemon. > > Client side of Admin API use /etc/qubes-release file to find if its > running in dom0 (and can take a shortcut to talk directly to qubesd), or > not. So I guess you installed package containing /etc/qubes-release, > which normally isn't present in VM. Simply remove the file and retry. > You should see some messages about denied admin.* qrexec calls. > > > 3) What would be a good way to track and distribute necessary changes to > > /etc/qubes-rpc/policy/ on dom0? > > See linked post[1] what changes are required. Normally I'd say, lets > package it in rpm, but since qrexec policy doesn't support .d > directories, it may not work that well. In many places we use salt's > file.prepend to adjust policy files, so maybe use it here too? This > start being quite complex: > 1. Salt formula installed (via rpm?) in dom0, to configure management VM > 2. Management VM running rest of salt formulas to configure other VMs Yeah, this kinda follows what I was thinking. With some work (1) could be available from Qubes repos ;) I guess with defaults allowing to set up mgmt-global, mgmt-personal and mgmt-work, with permissions set up as the names imply? But, being salt-head that I am, what about templating the settings from pillars? No, I'm not convinced whether one long yaml is better than multitude of tiny files... But this could be another way to manage the whole thing. Some examples of what it could look like are pillar examples from rspamd-formula[7], salt-formula[8] and shorewall-formula[9] And of course there are different ways to manage pillars than one long yaml, but this is the most common way. [10] [11] [12] > [1] https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/ > [2] https://github.com/QubesOS/qubes-mgmt-salt-dom0-qvm/ > [3] https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/ > [4] https://github.com/QubesOS/qubes-infrastructure/ > [5] https://github.com/QubesOS/qubes-mgmt-salt [6] https://docs.saltstack.com/en/latest/topics/spm/index.html [7] https://github.com/saltstack-formulas/rspamd-formula/blob/master/pillar.example [8] https://github.com/saltstack-formulas/salt-formula/blob/master/pillar.example [9] https://github.com/saltstack-formulas/shorewall-formula/blob/master/pillar.example [10] https://docs.saltstack.com/en/latest/ref/pillar/all/ [11] https://docs.saltstack.com/en/latest/ref/sdb/all/index.html [12] https://docs.saltstack.com/en/latest/ref/renderers/all/index.html -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20180420205138.o7fkf5wlmngl3ycx%40hirauchi. For more options, visit https://groups.google.com/d/optout.
