mirror of
https://github.com/valitydev/salt.git
synced 2024-11-07 17:09:03 +00:00
f9ffcb697a
* json encode arguments passed to an execution module function call
this fixes problems where you could pass a string to a module function,
which thanks to the yaml decoder which is used when parsing command line
arguments could change its type entirely. for example:
__salt__['test.echo')('{foo: bar}')
the test.echo function just returns the argument it's given. however,
because it's being called through a salt-call process like this:
salt-call --local test.echo {foo: bar}
salt thinks it's yaml and therefore yaml decodes it. the return value
from the test.echo call above is therefore a dict, not a string.
* Prevent crash if pygit2 package is requesting re-compilation of the e… (#32652)
* Prevent crash if pygit2 package is requesting re-compilation of the entire library on production systems (no *devel packages)
* Fix PEP8: move imports to the top of the file
* Move logger up
* Add log error message in case if exception is not an ImportError
* align OS grains from older SLES with current one (#32649)
* Fixing critical bug to remove only the specified Host instead of the entire Host cluster (#32640)
* yumpkg: Ignore epoch in version comparison for explict versions without an epoch (#32563)
* yumpkg: Ignore epoch in version comparison for explict versions without an epoch
Also properly handle comparisions for packages with multiple versions.
Resolves #32229
* Don't attempt downgrade for kernel and its subpackages
Multiple versions are supported since their paths do not conflict.
* Lower log level for pillar cache (#32655)
This shouldn't show up on salt-call runs
* Don't access deprecated Exception.message attribute. (#32556)
* Don't access deprecated Exception.message attribute.
To avoid a deprecation warning message in logs.
There is a new function salt.exceptions.get_error_message(e) instead.
* Fixed module docs test.
* Fix for issue 32523 (#32672)
* Fix routes for redhat < 6
* Handle a couple of arguments better (Azure) (#32683)
* backporting a fix from develop where the use of splay would result in seconds=0 in the schedule.list when there was no seconds specified in the origina schedule
* Handle when beacon not configured and we try to enable/disable them (#32692)
* Handle the situation when the beacon is not configured and we try to disable it
* a couple more missing returns in the enable & disable
* Check dependencies type before appling str operations (#32693)
* Update external auth documentation to list supported matcher. (#32733)
Thanks to #31598, all matchers are supported for eauth configuration.
But we still have no way to use compound matchers in eauth configuration.
Update the documentation to explicitly express this limitation.
* modules.win_dacl: consistent case of dacl constants (#32720)
* Document pillar cache options (#32643)
* Add note about Pillar data cache requirement for Pillar targeting method
* Add `saltutil.refresh_pillar` function to the scheduled Minion jobs
* Minor fixes in docs
* Add note about relations between `pillar_cache` option and Pillar Targeting
to Master config comments with small reformatting
* Document Pillar Cache Options for Salt Master
* Document Minions Targeting with Mine
* Remove `saltutil.refresh_pillar` scheduled persistent job
* Properly handle minion failback failure. (#32749)
* Properly handle minion failback failure.
Initiate minion restart if all masters down on __master_disconnect like
minion does on the initial master connect on start.
* Fixed unit test
* Improve documentation on pygit2 versions (#32779)
This adds an explanation of the python-cffi dep added in pygit2 0.21.0,
and recommends 0.20.3 for LTS distros. It also links to the salt-pack
issue which tracks the progress of adding pygit2 to our Debian and
Ubuntu repositories.
* Pylint fix
140 lines
4.6 KiB
ReStructuredText
140 lines
4.6 KiB
ReStructuredText
==========================
|
|
Salt Masterless Quickstart
|
|
==========================
|
|
|
|
.. _`Vagrant`: http://www.vagrantup.com/
|
|
.. _`Vagrant salt provisioner`: http://docs.vagrantup.com/v2/provisioning/salt.html
|
|
.. _`salt-bootstrap`: https://github.com/saltstack/salt-bootstrap
|
|
|
|
Running a masterless salt-minion lets you use Salt's configuration management
|
|
for a single machine without calling out to a Salt master on another machine.
|
|
|
|
Since the Salt minion contains such extensive functionality it can be useful
|
|
to run it standalone. A standalone minion can be used to do a number of
|
|
things:
|
|
|
|
- Stand up a master server via States (Salting a Salt Master)
|
|
- Use salt-call commands on a system without connectivity to a master
|
|
- Masterless States, run states entirely from files local to the minion
|
|
|
|
|
|
It is also useful for testing out state trees before deploying to a production setup.
|
|
|
|
|
|
Bootstrap Salt Minion
|
|
=====================
|
|
|
|
The `salt-bootstrap`_ script makes bootstrapping a server with Salt simple
|
|
for any OS with a Bourne shell:
|
|
|
|
.. code-block:: bash
|
|
|
|
curl -L https://bootstrap.saltstack.com -o bootstrap_salt.sh
|
|
sudo sh bootstrap_salt.sh
|
|
|
|
|
|
See the `salt-bootstrap`_ documentation for other one liners. When using `Vagrant`_
|
|
to test out salt, the `Vagrant salt provisioner`_ will provision the VM for you.
|
|
|
|
Telling Salt to Run Masterless
|
|
==============================
|
|
|
|
To instruct the minion to not look for a master, the :conf_minion:`file_client`
|
|
configuration option needs to be set in the minion configuration file.
|
|
By default the :conf_minion:`file_client` is set to ``remote`` so that the
|
|
minion gathers file server and pillar data from the salt master.
|
|
When setting the :conf_minion:`file_client` option to ``local`` the
|
|
minion is configured to not gather this data from the master.
|
|
|
|
.. code-block:: yaml
|
|
|
|
file_client: local
|
|
|
|
Now the salt minion will not look for a master and will assume that the local
|
|
system has all of the file and pillar resources.
|
|
|
|
Configuration which resided in the
|
|
:doc:`master configuration </ref/configuration/master>` (e.g. ``/etc/salt/master``)
|
|
should be moved to the :doc:`minion configuration </ref/configuration/minion>`
|
|
since the minion does not read the master configuration.
|
|
|
|
.. note::
|
|
|
|
When running Salt in masterless mode, do not run the salt-minion daemon.
|
|
Otherwise, it will attempt to connect to a master and fail. The salt-call
|
|
command stands on its own and does not need the salt-minion daemon.
|
|
|
|
Create State Tree
|
|
=================
|
|
|
|
Following the successful installation of a salt-minion, the next step is to create
|
|
a state tree, which is where the SLS files that comprise the possible states of the
|
|
minion are stored.
|
|
|
|
The following example walks through the steps necessary to create a state tree that
|
|
ensures that the server has the Apache webserver installed.
|
|
|
|
.. note::
|
|
For a complete explanation on Salt States, see the `tutorial
|
|
<http://docs.saltstack.com/en/latest/topics/tutorials/states_pt1.html>`_.
|
|
|
|
1. Create the ``top.sls`` file:
|
|
|
|
``/srv/salt/top.sls:``
|
|
|
|
.. code-block:: yaml
|
|
|
|
base:
|
|
'*':
|
|
- webserver
|
|
|
|
2. Create the webserver state tree:
|
|
|
|
``/srv/salt/webserver.sls:``
|
|
|
|
.. code-block:: yaml
|
|
|
|
apache: # ID declaration
|
|
pkg: # state declaration
|
|
- installed # function declaration
|
|
|
|
.. note::
|
|
|
|
The apache package has different names on different platforms, for
|
|
instance on Debian/Ubuntu it is apache2, on Fedora/RHEL it is httpd
|
|
and on Arch it is apache
|
|
|
|
The only thing left is to provision our minion using ``salt-call``.
|
|
|
|
Salt-call
|
|
---------
|
|
|
|
The salt-call command is used to run remote execution functions locally on a
|
|
minion instead of executing them from the master. Normally the salt-call
|
|
command checks into the master to retrieve file server and pillar data, but
|
|
when running standalone salt-call needs to be instructed to not check the
|
|
master for this data:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt-call --local state.apply
|
|
|
|
The ``--local`` flag tells the salt-minion to look for the state tree in the
|
|
local file system and not to contact a Salt Master for instructions.
|
|
|
|
To provide verbose output, use ``-l debug``:
|
|
|
|
.. code-block:: bash
|
|
|
|
salt-call --local state.apply -l debug
|
|
|
|
The minion first examines the ``top.sls`` file and determines that it is a part
|
|
of the group matched by ``*`` glob and that the ``webserver`` SLS should be applied.
|
|
|
|
It then examines the ``webserver.sls`` file and finds the ``apache`` state, which
|
|
installs the Apache package.
|
|
|
|
The minion should now have Apache installed, and the next step is to begin
|
|
learning how to write
|
|
:doc:`more complex states</topics/tutorials/states_pt1>`.
|