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 [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/20180422073559.cjp36zrwp2arxwbo%40hirauchi. For more options, visit https://groups.google.com/d/optout.
