"How can I properly manage my system?" or "how do I use Admin API, salt and git or other versioning/distribution mechanisms together"

[viq]

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.

Am I on the right track here? If so:

1) What packages do I need on admin VM to be able to do this?

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.

3) What would be a good way to track and distribute necessary changes to /etc/qubes-rpc/policy/ on dom0?

And if I'm not on the right track, then what would be the proper way to approach this?

--

viq

[awokd]

On Thu, April 19, 2018 8:20 pm, viq wrote:

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

You might try this question over on qubes-devel, not sure these
technologies are quite at user-friendly stage yet.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

> 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

[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

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlrZ1FcACgkQ24/THMrX
1yzccAf/bInV6KALR82K9mt0yHYrE4N1IlHLyoaBmBi1QyNX/rqY+6/NInKl7Sit
VWpp4HBXcZBcqH9u0j9G1cJBQX3XrN84BLWLFJcRYUNRJkcqWH/DnOusDGuhCdvs
XC8sbwHtkRIueUFgMNpBSyWgyy8GjjSIoQItE7JxGkHMin5AGiNxlNZVY+TuFxV+
B59goJIjzuuUXZTXgkzasXeSLBUKVLUPKMOrgt6Jw1REV6WGwrl6ZDG3T4h7kGBY
zldTYhnxFbiBVX0GWVwGqSfEWjYJxX1/Yh5yNv7TTcZGQFFfBLex8MvMVwE/DEYq
kJ4qiQsj2iGVgFnNchQVB/KFz8eCbg==
=uBDd
-----END PGP SIGNATURE-----

[viq]

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

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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"...

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.

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

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlraWccACgkQ24/THMrX
1ywUUggAjKPrD700d9QLYD49VovSV7WSKp6d3O9YAOYtVfvpoDC4sKtGTkcF4izn
ctQLwjsJhilfeUgS/Jej7jV6MxkJCxyGjXvJQvc1zsjpdGvioSPJ89a04ChcY4S7
sg78gksUW0/yDwgV9KruYp0MVWzS4GoN8siECxZ1xJYtlYEcziJ4Bm+J+G7HNpbd
H5G37MH9R+CbLdLckdjEuBOUV4BWKB1z0X2B71PBdEIF/dguj/rvDfXmZx9GQj36
GOQVwrHsB7b3B6Rp93vc10TX1rVj8WVwwY6k0To7W3IRWFhzPyIR50tTMIzPTGYB
BAFMf9mmGl0Sc36pjk+hQBIq0YBaeg==
=XR7K
-----END PGP SIGNATURE-----

[viq]

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.

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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?

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

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

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlrb4WEACgkQ24/THMrX
1yx2pQgAjo7QYeNxcoMLA/S5L8pt7pnTrHkkm4iOpft7RktoD5HyVw9Harzgpf3z
vGKuzc5dMuEzGxxeE8mGJkHNM48MnEPHZ8oA1xuc3Nyhq/Lz8HDZhUmDZ++M2rJ8
29/i3h4BRB2Tb+c1hT1/7UAFj7I5bM+X3ITkh2irLaO6iVUa3YzFSOv44lLWceWo
WM3S850MsKMxxnB7pXoTIpjECsrchtOzCmHH8y6lOHCjHtWu8Wio4veMJSZTi1+Q
NFCcjvXuw5pMnm3pK5Nr8LwdTDtkuhU5xIA+i24e1GBDSXEURDnqhUBGh6CQ5Osi
phz2LHPawI7teILw+LDXGosZNQQJsA==
=dkdW
-----END PGP SIGNATURE-----

[viq]

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.

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/

[emma.bo...@gmail.com]

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?