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...
 
> 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? 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/

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

Reply via email to