mirror of
https://github.com/valitydev/salt.git
synced 2024-11-08 09:23:56 +00:00
Merge pull request #36519 from terminalmage/docs
Rewrite minionfs walkthrough
This commit is contained in:
Mike Place
GitHub
commit
364f74dfc9
@ -2198,9 +2198,9 @@ exposed.
|
||||
.. code-block:: yaml
|
||||
|
||||
minionfs_whitelist:
|
||||
- base
|
||||
- v1.*
|
||||
- 'mybranch\d+'
|
||||
- server01
|
||||
- dev*
|
||||
- 'mail\d+.mydomain.tld'
|
||||
|
||||
.. conf_master:: minionfs_blacklist
|
||||
|
||||
@ -2224,9 +2224,9 @@ exposed.
|
||||
.. code-block:: yaml
|
||||
|
||||
minionfs_blacklist:
|
||||
- base
|
||||
- v1.*
|
||||
- 'mybranch\d+'
|
||||
- server01
|
||||
- dev*
|
||||
- 'mail\d+.mydomain.tld'
|
||||
|
||||
|
||||
.. _pillar-configuration:
|
||||
|
||||
@ -4,155 +4,149 @@
|
||||
MinionFS Backend Walkthrough
|
||||
============================
|
||||
|
||||
Propagating Files
|
||||
=================
|
||||
|
||||
.. 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::
|
||||
|
||||
This walkthrough assumes basic knowledge of Salt and :mod:`cp.push
|
||||
<salt.modules.cp.push>`. To get up to speed, check out the
|
||||
: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
|
||||
should be used to send these files to other minions.
|
||||
#. Minion support for pushing files to the master (using :py:func:`cp.push
|
||||
<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
|
||||
``minion`` and :conf_master:`file_recv` needs to be set to true:
|
||||
|
||||
This walkthrough will show how to use both of these features.
|
||||
|
||||
|
||||
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
|
||||
|
||||
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:
|
||||
- roots
|
||||
- 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
|
||||
|
||||
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.
|
||||
fileserver_backend:
|
||||
- roots
|
||||
- minion
|
||||
|
||||
.. note::
|
||||
minionfs_mountpoint: salt://minionfs
|
||||
|
||||
All of the files that are pushed to the master are going to be available to
|
||||
all of the minions. If this is not what you want, please remove ``minion``
|
||||
from :conf_master:`fileserver_backend` in the master config file.
|
||||
minionfs_whitelist:
|
||||
- host04
|
||||
- web*
|
||||
- 'mail\d+\.domain\.tld'
|
||||
|
||||
.. note::
|
||||
minionfs_whitelist:
|
||||
- web21
|
||||
|
||||
Having directories with the same name as your minions in the root
|
||||
that can be accessed like ``salt://minion-id/`` might cause confusion.
|
||||
Potential Concerns
|
||||
------------------
|
||||
|
||||
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
|
||||
``minion-source`` and put the public part in ``~/.ssh/authorized_keys`` of root
|
||||
user of a minion called ``minion-destination``.
|
||||
|
||||
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.
|
||||
* Unless the :conf_master:`minionfs_whitelist` and/or
|
||||
:conf_master:`minionfs_blacklist` config options are used, all minions which
|
||||
push files to the master will have their files made available via
|
||||
:mod:`minionfs <salt.fileserver.minionfs>`.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user