valitydev/salt
14
0
Fork 0
mirror of https://github.com/valitydev/salt.git synced 2024-11-08 09:23:56 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge pull request #7207 from terminalmage/docs

Browse Source 
A few docs commits
This commit is contained in:
Erik Johnson 2013-09-12 15:13:05 -07:00
commit 54ec917208
3 changed files with 42 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/conf.py
View File

@ -103,7 +103,7 @@ copyright = '2013 SaltStack, Inc.'
version = salt.version.__version__
#release = '.'.join(map(str, salt.version.__version_info__))
release = '0.16.3'
release = '0.16.4'
language = 'en'
locale_dirs = [

55
doc/topics/troubleshooting/index.rst
View File

@ -13,10 +13,10 @@ A great deal of information is available via the debug logging system, if you
are having issues with minions connecting or not starting run the minion and/or
master in the foreground:
.. code-block:: sh
.. code-block:: bash
# salt-master -l debug
# salt-minion -l debug
salt-master -l debug
salt-minion -l debug
Anyone wanting to run Salt daemons via a process supervisor such as `monit`_,
`runit`_, or `supervisord`_, should omit the ``-d`` argument to the daemons and
@ -36,10 +36,10 @@ it could very well be a firewall.
You can check port connectivity from the minion with the nc command:
.. code-block:: sh
.. code-block:: bash
# nc -v -z salt.master.ip 4505
# nc -v -z salt.master.ip 4506
nc -v -z salt.master.ip 4505
nc -v -z salt.master.ip 4506
There is also a :doc:`firewall configuration</topics/tutorials/firewall>`
document that might help as well.
@ -53,6 +53,8 @@ Salt.
.. _`AppArmor`: http://wiki.apparmor.net/index.php/Main_Page
.. _using-salt-call:
Using salt-call
===============
@ -60,17 +62,23 @@ The ``salt-call`` command was originally developed for aiding in the development
of new Salt modules. Since then, many applications have been developed for
running any Salt module locally on a minion. These range from the original
intent of salt-call, development assistance, to gathering more verbose output
from calls like :doc:`state.highstate</ref/modules/all/salt.modules.state>`.
from calls like :mod:`state.highstate <salt.modules.state.highstate>`.
When developing the State Tree it is generally recommended to invoke
state.highstate with salt-call. This displays far more information
about the highstate execution than calling it remotely. For even more
verbosity, increase the loglevel with the same argument as ``salt-minion``:
When creating your state tree, it is generally recommended to invoke
:mod:`state.highstate <salt.modules.state.highstate>` with ``salt-call``. This
displays far more information about the highstate execution than calling it
remotely. For even more verbosity, increase the loglevel with the same argument
as ``salt-minion``:
.. code-block:: sh
.. code-block:: bash
salt-call -l debug state.highstate
The main difference between using ``salt`` and using ``salt-call`` is that
``salt-call`` is run from the minion, and it only runs the selected function on
that minion. By contrast, ``salt`` is run from the master, and requires you to
specify the minions on which to run the command using salt's :doc:`targeting
system </topics/targeting/index>`.
Too many open files
===================
@ -79,7 +87,7 @@ The salt-master needs at least 2 sockets per host that connects to it, one for
the Publisher and one for response port. Thus, large installations may, upon
scaling up the number of minions accessing a given master, encounter:
.. code-block:: sh
.. code-block:: bash
12:45:29,289 [salt.master ][INFO ] Starting Salt worker process 38
Too many open files
@ -88,7 +96,7 @@ scaling up the number of minions accessing a given master, encounter:
The solution to this would be to check the number of files allowed to be
opened by the user running salt-master (root by default):
.. code-block:: sh
.. code-block:: bash
[root@salt-master ~]# ulimit -n
1024
@ -111,7 +119,7 @@ field in ``net.ipv4.tcp_rmem`` and ``net.ipv4.tcp_wmem`` to at least 16777216.
You can do it manually with something like:
.. code-block:: sh
.. code-block:: bash
# echo 16777216 > /proc/sys/net/core/rmem_max
# echo 16777216 > /proc/sys/net/core/wmem_max
@ -160,12 +168,12 @@ to this issue is to set the execution context of ``salt-call`` and
.. code-block:: bash
# CentOS 5 and RHEL 5:
# chcon -t system_u:system_r:rpm_exec_t:s0 /usr/bin/salt-minion
# chcon -t system_u:system_r:rpm_exec_t:s0 /usr/bin/salt-call
chcon -t system_u:system_r:rpm_exec_t:s0 /usr/bin/salt-minion
chcon -t system_u:system_r:rpm_exec_t:s0 /usr/bin/salt-call
# CentOS 6 and RHEL 6:
# chcon system_u:object_r:rpm_exec_t:s0 /usr/bin/salt-minion
# chcon system_u:object_r:rpm_exec_t:s0 /usr/bin/salt-call
chcon system_u:object_r:rpm_exec_t:s0 /usr/bin/salt-minion
chcon system_u:object_r:rpm_exec_t:s0 /usr/bin/salt-call
This works well, because the ``rpm_exec_t`` context has very broad control over
other types.
@ -184,9 +192,8 @@ needs to be run with the ``python26`` executable.
Common YAML Gotchas
===================
An extensive list of
:doc:`YAML idiosyncrasies</topics/troubleshooting/yaml_idiosyncrasies>`
has been compiled.
An extensive list of :doc:`YAML idiosyncrasies
</topics/troubleshooting/yaml_idiosyncrasies>` has been compiled.
Live Python Debug Output
========================
@ -198,8 +205,8 @@ sure the master of minion are running in the foreground:
.. code-block:: bash
# salt-master -l debug
# salt-minion -l debug
salt-master -l debug
salt-minion -l debug
The pass the signal to the master or minion when it seems to be unresponsive:

10
doc/topics/tutorials/walkthrough.rst
View File

@ -346,6 +346,16 @@ addresses, etc:
salt '*' network.interfaces
``salt-call``
~~~~~~~~~~~~~
The examples so far have described running commands from the Master using the
``salt`` command, but when troubleshooting it can be more beneficial to login
to the minion directly and use ``salt-call``. Doing so allows you to see the
minion log messages specific to the command you are running (which are *not*
part of the return data you see when running the command from the Master using
``salt``), making it unnecessary to tail the minion log. More information on
``salt-call`` and how to use it can be found :ref:`here <using-salt-call>`.
Grains
~~~~~~