Then added this next part to /srv/user_salt/top.sls
user:
dom0:
- salty
And I get these errors after running the command sudo qubesctl state.highstate
[CRITICAL] Specified ext_pillar interface qvm_prefs is unavailable
[CRITICAL] Specified ext_pillar interface qvm_prefs is unavailable
[ERROR ] State 'qvm.vm' was not found in SLS 'salty'
Reason: 'qvm.vm' is not available.
local:
----------
ID: salty--create-qube
Function: qvm.vm
Name: salty
Result: False
Comment: State 'qvm.vm' was not found in SLS 'salty'
Reason: 'qvm.vm' is not available.
Changes:
Summary for local
------------
Succeeded: 0
Failed: 1
------------
Total states run: 1
Total run time: 0.000 ms
DOM0 configuration failed, not continuing
[root@dom0 user_salt]#
These problems arise because most users dont understand that this is
set-up as a different environment in salt terms.
That is why many of the states and pillars are not available out of the
box in that environment.
What most people seem to want is just a directory where they
can put their own states which will be part of the base environment. The
salt way to do this is to add an entry under the base environment in /etc/salt/minion.d/f_defaults.conf
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
This file says # This file is managed by Salt, do not edit by hand!!
at the top. I’m just starting out with salt so I don’t know much about this stuff, but it seems like that isn’t the intended use of that file?
Will salt by any chance ever overwrite my changes if I add them here?
And yes, I’m interested in making my own states that will be part of the base enviorment
[root@dom0 salt]# sudo qubesctl state.highstate
[WARNING ] top_file_merging_strategy is set to 'merge' and multiple top files were found. Merging order is not deterministic, it may be desirable to either set top_file_merging_strategy to 'same' or use the 'env_order' configuration parameter to specify the merging order.
Passed invalid arguments: 'NoneType' object is not iterable.
Usage:
Retrieve the state data from the salt master for this minion and execute it
test
Run states in test-only (dry-run) mode
pillar
Custom Pillar values, passed as a dictionary of key-value pairs
.. code-block:: bash
salt '*' state.highstate stuff pillar='{"foo": "bar"}'
.. note::
Values passed this way will override Pillar values set via
``pillar_roots`` or an external Pillar source.
.. versionchanged:: 2016.3.0
GPG-encrypted CLI Pillar data is now supported via the GPG
renderer. See :ref:`here <encrypted-cli-pillar-data>` for details.
pillar_enc
Specify which renderer to use to decrypt encrypted data located within
the ``pillar`` value. Currently, only ``gpg`` is supported.
.. versionadded:: 2016.3.0
exclude
Exclude specific states from execution. Accepts a list of sls names, a
comma-separated string of sls names, or a list of dictionaries
containing ``sls`` or ``id`` keys. Glob-patterns may be used to match
multiple states.
.. code-block:: bash
salt '*' state.highstate exclude=bar,baz
salt '*' state.highstate exclude=foo*
salt '*' state.highstate exclude="[{'id': 'id_to_exclude'}, {'sls': 'sls_to_exclude'}]"
saltenv
Specify a salt fileserver environment to be used when applying states
.. versionchanged:: 0.17.0
Argument name changed from ``env`` to ``saltenv``.
.. versionchanged:: 2014.7.0
If no saltenv is specified, the minion config will be checked for a
``saltenv`` parameter and if found, it will be used. If none is
found, ``base`` will be used. In prior releases, the minion config
was not checked and ``base`` would always be assumed when the
saltenv was not explicitly set.
pillarenv
Specify a Pillar environment to be used when applying states. This
can also be set in the minion config file using the
:conf_minion:`pillarenv` option. When neither the
:conf_minion:`pillarenv` minion config option nor this CLI argument is
used, all Pillar environments will be merged together.
queue : False
Instead of failing immediately when another state run is in progress,
a value of ``True`` will queue the new state run to begin running once
the other has finished.
This option starts a new thread for each queued state run, so use this
option sparingly.
.. versionchanged:: 3006.0
This parameter can also be set via the ``state_queue`` configuration
option. Additionally, it can now be set to an integer representing
the maximum queue size which can be attained before the state runs
will fail to be queued. This can prevent runaway conditions where
new threads are started until system performance is hampered.
concurrent : False
Execute state runs concurrently instead of serially
.. warning::
This flag is potentially dangerous. It is designed for use when
multiple state runs can safely be run at the same time. Do *not*
use this flag for performance optimization.
localconfig
Optionally, instead of using the minion config, load minion opts from
the file specified by this argument, and then merge them with the
options from the minion config. This functionality allows for specific
states to be run with their own custom minion configuration, including
different pillars, file_roots, etc.
mock
The mock option allows for the state run to execute without actually
calling any states. This then returns a mocked return which will show
the requisite ordering as well as fully validate the state run.
.. versionadded:: 2015.8.4
state_events
The state_events option sends progress events as each function in
a state run completes execution.
.. versionadded:: 3006.0
CLI Examples:
.. code-block:: bash
salt '*' state.highstate
salt '*' state.highstate whitelist=sls1_to_run,sls2_to_run
salt '*' state.highstate exclude=sls_to_exclude
salt '*' state.highstate exclude="[{'id': 'id_to_exclude'}, {'sls': 'sls_to_exclude'}]"
salt '*' state.highstate pillar="{foo: 'Foo!', bar: 'Bar!'}"
DOM0 configuration failed, not continuing
[root@dom0 salt]#
It seems as if I screwed something up (no custom salt config files added with this and it looks like something is broken.) In the event that this happens, is there a way that I could reset my salt files back to the defaults?
Without knowing what it is you have done, and what your highstate
purports to be, it’s extremely difficult to help.
Did you actually edit any salt configuration files? Which Ones? Why
What changes did you make?
If you want, I assume you could reinstall the packages with sudo qubes-dom0-update --action=reinstall
At least you would want salt and salt-minion, and the various
qubes-mgmt… packages. (Check dnf list|grep salt for complete list.
I wouldnt do that unless I was clear that I had broken the
configuration, and to do that you would need to recite the changes that
you made.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
That would reset all dom0 configuration and nothing else? I haven’t configured dom0 besides broken salt, so that would be what I would want in that case.
As I said -
Without knowing what it is you have done, and what your highstate
purports to be, it’s extremely difficult to help.
Did you actually edit any salt configuration files? Which Ones? Why?
What changes did you make?
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.