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 #36519 from terminalmage/docs

Browse Source 
Rewrite minionfs walkthrough
This commit is contained in:
Mike Place 2016-09-23 14:19:58 +09:00 committed by GitHub
commit 364f74dfc9
2 changed files with 126 additions and 132 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/ref/configuration/master.rst
View File

@ -2198,9 +2198,9 @@ exposed.
.. code-block:: yaml .. code-block:: yaml
minionfs_whitelist: minionfs_whitelist:
- base - server01
- v1.* - dev*
- 'mybranch\d+' - 'mail\d+.mydomain.tld'
.. conf_master:: minionfs_blacklist .. conf_master:: minionfs_blacklist
@ -2224,9 +2224,9 @@ exposed.
.. code-block:: yaml .. code-block:: yaml
minionfs_blacklist: minionfs_blacklist:
- base - server01
- v1.* - dev*
- 'mybranch\d+' - 'mail\d+.mydomain.tld'
.. _pillar-configuration: .. _pillar-configuration:

246
doc/topics/tutorials/minionfs.rst
View File

@ -4,155 +4,149 @@
MinionFS Backend Walkthrough MinionFS Backend Walkthrough
============================ ============================
Propagating Files
=================
.. versionadded:: 2014.1.0 .. versionadded:: 2014.1.0
Sometimes, one might need to propagate files that are generated on a minion.
Salt already has a feature to send files from a minion to the master.
Enabling File Propagation
=========================
To enable propagation, the :conf_master:`file_recv` option needs to be set to ``True``.
.. code-block:: yaml
file_recv: True
These changes require a restart of the master, then new requests for the
``salt://minion-id/`` protocol will send files that are pushed by ``cp.push``
from ``minion-id`` to the master.
.. code-block:: bash
salt 'minion-id' cp.push /path/to/the/file
This command will store the file, including its full path, under
:conf_master:`cachedir` ``/master/minions/minion-id/files``. With the default
:conf_master:`cachedir` the example file above would be stored as
`/var/cache/salt/master/minions/minion-id/files/path/to/the/file`.
.. note:: .. note::
This walkthrough assumes basic knowledge of Salt and :mod:`cp.push This walkthrough assumes basic knowledge of Salt and :mod:`cp.push
<salt.modules.cp.push>`. To get up to speed, check out the <salt.modules.cp.push>`. To get up to speed, check out the
:doc:`walkthrough </topics/tutorials/walkthrough>`. :doc:`walkthrough </topics/tutorials/walkthrough>`.
MinionFS Backend Sometimes it is desirable to deploy a file located on one minion to one or more
================ other minions. This is supported in Salt, and can be accomplished in two parts:
Since it is not a good idea to expose the whole :conf_master:`cachedir`, MinionFS #. Minion support for pushing files to the master (using :py:func:`cp.push
should be used to send these files to other minions. <salt.modules.cp.push>`)
Simple Configuration #. The :mod:`minionfs <salt.fileserver.minionfs>` fileserver backend
====================
To use the minionfs backend only two configuration changes are required on the
master. The :conf_master:`fileserver_backend` option needs to contain a value of This walkthrough will show how to use both of these features.
``minion`` and :conf_master:`file_recv` needs to be set to true:
Enabling File Push
==================
To set the master to accept files pushed from minions, the
:conf_master:`file_recv` option in the master config file must be set to
``True`` (the default is ``False``).
.. code-block:: yaml .. code-block:: yaml
file_recv: True
.. note::
This change requires a restart of the salt-master service.
Pushing Files
=============
Once this has been done, files can be pushed to the master using the
:py:func:`cp.push <salt.modules.cp.push>` function:
.. code-block:: bash
salt 'minion-id' cp.push /path/to/the/file
This command will store the file in a subdirectory named ``minions`` under the
master's :conf_master:`cachedir`. On most masters, this path will be
``/var/cache/salt/master/minions``. Within this directory will be one directory
for each minion which has pushed a file to the master, and underneath that the
full path to the file on the minion. So, for example, if a minion with an ID of
``dev1`` pushed a file ``/var/log/myapp.log`` to the master, it would be saved
to ``/var/cache/salt/master/minions/dev1/var/log/myapp.log``.
Serving Pushed Files Using MinionFS
===================================
While it is certainly possible to add ``/var/cache/salt/master/minions`` to the
master's :conf_master:`file_roots` and serve these files, it may only be
desirable to expose files pushed from certain minions. Adding
``/var/cache/salt/master/minions/<minion-id>`` for each minion that needs to be
exposed can be cumbersome and prone to errors.
Enter :mod:`minionfs <salt.fileserver.minionfs>`. This fileserver backend will
make files pushed using :py:func:`cp.push <salt.modules.cp.push>` available to
the Salt fileserver, and provides an easy mechanism to restrict which minions'
pushed files are made available.
Simple Configuration
--------------------
To use the :mod:`minionfs <salt.fileserver.minionfs>` backend, add ``minion``
to the list of backends in the :conf_master:`fileserver_backend` configuration
option on the master:
.. code-block:: yaml
file_recv: True
fileserver_backend: fileserver_backend:
- roots - roots
- minion - minion
.. note::
As described earlier, ``file_recv: True`` is also needed to enable the
master to receive files pushed from minions. As always, changes to the
master configuration require a restart of the ``salt-master`` service.
Files made available via :mod:`minionfs <salt.fileserver.minionfs>` are by
default located at ``salt://<minion-id>/path/to/file``. Think back to the
earlier example, in which ``dev1`` pushed a file ``/var/log/myapp.log`` to the
master. With :mod:`minionfs <salt.fileserver.minionfs>` enabled, this file
would be addressable in Salt at ``salt://dev1/var/log/myapp.log``.
If many minions have pushed to the master, this will result in many directories
in the root of the Salt fileserver. For this reason, it is recommended to use
the :conf_master:`minionfs_mountpoint` config option to organize these files
underneath a subdirectory:
.. code-block:: yaml
minionfs_mountpoint: salt://minionfs
Using the above mountpoint, the file in the example would be located at
``salt://minionfs/dev1/var/log/myapp.log``.
Restricting Certain Minions' Files from Being Available Via MinionFS
--------------------------------------------------------------------
A whitelist and blacklist can be used to restrict the minions whose pushed
files are available via :mod:`minionfs <salt.fileserver.minionfs>`. These lists
can be managed using the :conf_master:`minionfs_whitelist` and
:conf_master:`minionfs_blacklist` config options. Click the links for both of
them for a detailed explanation of how to use them.
A more complex configuration example, which uses both a whitelist and
blacklist, can be found below:
.. code-block:: yaml
file_recv: True file_recv: True
These changes require a restart of the master, then new requests for the fileserver_backend:
``salt://minion-id/`` protocol will send files that are pushed by ``cp.push`` - roots
from ``minion-id`` to the master. - minion
.. note:: minionfs_mountpoint: salt://minionfs
All of the files that are pushed to the master are going to be available to minionfs_whitelist:
all of the minions. If this is not what you want, please remove ``minion`` - host04
from :conf_master:`fileserver_backend` in the master config file. - web*
- 'mail\d+\.domain\.tld'
.. note:: minionfs_whitelist:
- web21
Having directories with the same name as your minions in the root Potential Concerns
that can be accessed like ``salt://minion-id/`` might cause confusion. ------------------
Commandline Example * There is no access control in place to restrict which minions have access to
=================== files served up by :mod:`minionfs <salt.fileserver.minionfs>`. All minions
will have access to these files.
Lets assume that we are going to generate SSH keys on a minion called * Unless the :conf_master:`minionfs_whitelist` and/or
``minion-source`` and put the public part in ``~/.ssh/authorized_keys`` of root :conf_master:`minionfs_blacklist` config options are used, all minions which
user of a minion called ``minion-destination``. push files to the master will have their files made available via
:mod:`minionfs <salt.fileserver.minionfs>`.
First, lets make sure that ``/root/.ssh`` exists and has the right permissions:
.. code-block:: bash
[root@salt-master file]# salt '*' file.mkdir dir_path=/root/.ssh user=root group=root mode=700
minion-source:
None
minion-destination:
None
We create an RSA key pair without a passphrase [*]_:
.. code-block:: bash
[root@salt-master file]# salt 'minion-source' cmd.run 'ssh-keygen -N "" -f /root/.ssh/id_rsa'
minion-source:
Generating public/private rsa key pair.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
9b:cd:1c:b9:c2:93:8e:ad:a3:52:a0:8b:0a:cc:d4:9b root@minion-source
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| o . |
| o o S o |
|= + . B o |
|o+ E B = |
|+ . .+ o |
|o ...ooo |
+-----------------+
and we send the public part to the master to be available to all minions:
.. code-block:: bash
[root@salt-master file]# salt 'minion-source' cp.push /root/.ssh/id_rsa.pub
minion-source:
True
now it can be seen by everyone:
.. code-block:: bash
[root@salt-master file]# salt 'minion-destination' cp.list_master_dirs
minion-destination:
- .
- etc
- minion-source/root
- minion-source/root/.ssh
Lets copy that as the only authorized key to ``minion-destination``:
.. code-block:: bash
[root@salt-master file]# salt 'minion-destination' cp.get_file salt://minion-source/root/.ssh/id_rsa.pub /root/.ssh/authorized_keys
minion-destination:
/root/.ssh/authorized_keys
Or we can use a more elegant and salty way to add an SSH key:
.. code-block:: bash
[root@salt-master file]# salt 'minion-destination' ssh.set_auth_key_from_file user=root source=salt://minion-source/root/.ssh/id_rsa.pub
minion-destination:
new
.. [*] Yes, that was the actual key on my server, but the server is already destroyed.