qubesctl fails with "No module named salt.client" unless I: pip install salt
But pip doesn't sign code. How do I securely install the python pip module in a VM which is going to be performing administrative tasks? On Sunday, April 22, 2018 at 12:36:06 AM UTC-7, viq wrote: > > On 18-04-22 03:12:00, Marek Marczykowski-Górecki wrote: > > On Fri, Apr 20, 2018 at 11:40:36PM +0200, viq wrote: > > > On 18-04-20 23:21:10, Marek Marczykowski-Górecki wrote: > > > > On Fri, Apr 20, 2018 at 10:51:38PM +0200, viq wrote: > > > > > On 18-04-20 13:51:50, Marek Marczykowski-Górecki wrote: > > > > > > > > > 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. > > > > > > > > This is exactly the reason we use RPM for distribution-provided > > > > formulas. > > > > I've tried to play with SPM + some wrapper to actually download > files > > > > (dom0 has no network), but AFAIR it was a bit crazy to do it this > way - > > > > the only part of SPM that left could be shortened to "tar x"... > > > > > > Ah, so you looked at it more than I did. Would it make sense to have > > > pretty much just SPM file inside the RPM, and post-install talk with > SPM > > > to install that, or does it really bring nothing to the table? > > > > > On the other hand, RPMs don't play nice with local modifications... > > > > Does SPM do? > > Oh, good point, I'll need to play with it some and check. > > > > > BTW each of our formula packages have FORMULA file, so it should be > > > > compatible with SPM out of the box, at least in theory. > > > > > > > > > > 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? > > > > > > > > I think it is a good idea, but needs some better handling of > pillars. We > > > > already have topd[13] module to maintain top.sls. If we could have > > > > something allowing the user to simply set pillar entry X to value Y > > > > (without learning yaml syntax), that would be great. Pillar modules > you > > > > link below may be the way to go. > > > > > > Hm, where are things like labels and other VM settings stored? > > > > All VM properties are stored in qubes.xml. We do expose some of them as > > pillars already (for example qubes:type), but I don't think it's a good > > place for something not directly related to VMs. > > > > I'm thinking of pillars like the name of mgmt-global VM. This isn't > > something that belongs to some particular VM (in qubes.xml), especially > > when said mgmt-global VM doesn't exist yet. > > Well, "by extension" everything global belongs to dom0, doesn't it? And > for defining ACLs, it doesn't necessarily need to exist yet - though > you're potentially opening yourself up to something else taking it's > place, but I don't think you're going to accidentaly create a > "mgmt-global" VM. > > > I was hoping that some of existing pillar modules would support > > something with user friendly key-value interface, including: > > - listing available keys (maybe even with some description?) > > - getting and setting values > > - a GUI, or interface to integrate with some > > > > While a script that would handle yaml file wouldn't be horribly long, > > I'd guess someone have done that already. > > Looking through [10], there's a couple options that draw my eye: > - not quite the intended use case, but there's consul with it's web UI > [14] (similar should be available for etcd) > - "run this command to get JSON/YAML", which allows to store data in > arbitrary format, with a custom frontend, and just respond with > structured data that salt can understand > - various database options, and while I understand that running most of > them would not be desirable, that includes also sqlite[16], for which > there are some graphical browsers like [15] > > Your comment about listing available keys with descriptions makes me > think that closest matches would be either sqlite or a custom backend, > since for that to be available you would need to provide some kind of > schema. Though it also reminds me about existence of swagger[17], but > I'm not sure yet how it could be relevant, if at all. > > > > Maybe it > > > would be possible to piggy-back on that? Even if code would be needed, > > > pillars just like top system are "just another python file" that IIRC > > > can even be distributed inside SPMs. > > > > > > > > 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 > > > > > > > > [13] https://github.com/QubesOS/qubes-mgmt-salt-base-topd/ > > [14] https://www.consul.io/intro/getting-started/ui.html > [15] http://sqlitebrowser.org/ > [16] > https://docs.saltstack.com/en/latest/ref/pillar/all/salt.pillar.sqlite3.html > [17] https://swagger.io/tools/ > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c2af2070-9636-403d-91b8-0ef21dc350e3%40googlegroups.com.
