mirror of
https://github.com/saltstack-formulas/openssh-formula.git
synced 2026-09-20 17:34:01 +02:00
feat(semantic-release): implement for this formula
* Close #165 * Move existing `.kitchen.yml` => `kitchen.vagrant.yml` * Semi-automated using https://github.com/myii/ssf-formula/pull/30 * Fix errors shown below: ```bash openssh-formula$ yamllint -s . ./pillar.example 49:3 error duplication of key "AllowUsers" in mapping (key-duplicates) 57:3 error duplication of key "DenyUsers" in mapping (key-duplicates) 63:3 error duplication of key "AllowGroups" in mapping (key-duplicates) 70:3 error duplication of key "DenyGroups" in mapping (key-duplicates) 79:24 warning truthy value should be one of [false, true] (truthy) 80:29 warning truthy value should be one of [false, true] (truthy) 118:4 warning missing starting space in comment (comments) 119:4 warning missing starting space in comment (comments) 119:89 error line too long (122 > 88 characters) (line-length) 120:4 warning missing starting space in comment (comments) 120:89 error line too long (144 > 88 characters) (line-length) 147:30 warning truthy value should be one of [false, true] (truthy) 148:21 warning truthy value should be one of [false, true] (truthy) 149:19 warning truthy value should be one of [false, true] (truthy) 150:32 warning truthy value should be one of [false, true] (truthy) 151:26 warning truthy value should be one of [false, true] (truthy) 152:31 warning truthy value should be one of [false, true] (truthy) 153:32 warning truthy value should be one of [false, true] (truthy) 154:29 warning truthy value should be one of [false, true] (truthy) 155:34 warning truthy value should be one of [false, true] (truthy) 175:8 warning missing starting space in comment (comments) 175:89 error line too long (152 > 88 characters) (line-length) 176:8 warning missing starting space in comment (comments) 176:89 error line too long (126 > 88 characters) (line-length) 177:8 warning missing starting space in comment (comments) 177:89 error line too long (148 > 88 characters) (line-length) 213:18 warning truthy value should be one of [false, true] (truthy) 219:18 warning truthy value should be one of [false, true] (truthy) 225:18 warning truthy value should be one of [false, true] (truthy) 241:22 warning truthy value should be one of [false, true] (truthy) 243:22 warning truthy value should be one of [false, true] (truthy) 244:20 warning truthy value should be one of [false, true] (truthy) 245:21 warning truthy value should be one of [false, true] (truthy) 254:24 warning truthy value should be one of [false, true] (truthy) 255:22 warning truthy value should be one of [false, true] (truthy) 256:23 warning truthy value should be one of [false, true] (truthy) 265:22 warning truthy value should be one of [false, true] (truthy) 268:21 warning truthy value should be one of [false, true] (truthy) 269:20 warning truthy value should be one of [false, true] (truthy) 270:21 warning truthy value should be one of [false, true] (truthy) 279:26 warning truthy value should be one of [false, true] (truthy) 280:24 warning truthy value should be one of [false, true] (truthy) 281:25 warning truthy value should be one of [false, true] (truthy) 307:16 warning truthy value should be one of [false, true] (truthy) 308:6 warning missing starting space in comment (comments) 314:6 warning missing starting space in comment (comments) 316:24 warning truthy value should be one of [false, true] (truthy) 339:89 error line too long (546 > 88 characters) (line-length) 340:89 error line too long (546 > 88 characters) (line-length) 341:89 error line too long (546 > 88 characters) (line-length) 342:89 error line too long (546 > 88 characters) (line-length) 344:4 warning missing starting space in comment (comments) 345:4 warning missing starting space in comment (comments) 357:19 warning truthy value should be one of [false, true] (truthy) ./openssh/osfamilymap.yaml 1:1 warning missing document start "---" (document-start) ./openssh/osfingermap.yaml 1:1 warning missing document start "---" (document-start) ./openssh/osmap.yaml 1:1 warning missing document start "---" (document-start) ./openssh/defaults.yaml 1:1 warning missing document start "---" (document-start) 3:18 warning truthy value should be one of [false, true] (truthy) 6:34 warning too few spaces before comment (comments) 10:25 warning truthy value should be one of [false, true] (truthy) 12:32 warning too few spaces before comment (comments) 16:24 warning truthy value should be one of [false, true] (truthy) 18:24 warning too few spaces before comment (comments) 20:42 warning too few spaces before comment (comments) 27:6 warning missing starting space in comment (comments) ```
This commit is contained in:
Imran Iqbal
@@ -0,0 +1,159 @@
|
||||
.. _contributing:
|
||||
|
||||
How to contribute
|
||||
=================
|
||||
|
||||
This document will eventually outline all aspects of guidance to make your contributing experience a fruitful and enjoyable one.
|
||||
What it already contains is information about *commit message formatting* and how that directly affects the numerous automated processes that are used for this repo.
|
||||
It also covers how to contribute to this *formula's documentation*.
|
||||
|
||||
.. contents:: **Table of Contents**
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
Submitting a pull request is more than just code!
|
||||
To achieve a quality product, the *tests* and *documentation* need to be updated as well.
|
||||
An excellent pull request will include these in the changes, wherever relevant.
|
||||
|
||||
Commit message formatting
|
||||
-------------------------
|
||||
|
||||
Since every type of change requires making Git commits,
|
||||
we will start by covering the importance of ensuring that all of your commit
|
||||
messages are in the correct format.
|
||||
|
||||
Automation of multiple processes
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This formula uses `semantic-release <https://github.com/semantic-release/semantic-release>`_ for automating numerous processes such as bumping the version number appropriately, creating new tags/releases and updating the changelog.
|
||||
The entire process relies on the structure of commit messages to determine the version bump, which is then used for the rest of the automation.
|
||||
|
||||
Full details are available in the upstream docs regarding the `Angular Commit Message Conventions <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines>`_.
|
||||
The key factor is that the first line of the commit message must follow this format:
|
||||
|
||||
.. code-block::
|
||||
|
||||
type(scope): subject
|
||||
|
||||
|
||||
* E.g. ``docs(contributing): add commit message formatting instructions``.
|
||||
|
||||
Besides the version bump, the changelog and release notes are formatted accordingly.
|
||||
So based on the example above:
|
||||
|
||||
..
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<h3>Documentation</h3>
|
||||
|
||||
* **contributing:** add commit message formatting instructions
|
||||
|
||||
|
||||
* The ``type`` translates into a ``Documentation`` sub-heading.
|
||||
* The ``(scope):`` will be shown in bold text without the brackets.
|
||||
* The ``subject`` follows the ``scope`` as standard text.
|
||||
|
||||
Linting commit messages in Travis CI
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This formula uses `commitlint <https://github.com/conventional-changelog/commitlint>`_ for checking commit messages during CI testing.
|
||||
This ensures that they are in accordance with the ``semantic-release`` settings.
|
||||
|
||||
For more details about the default settings, refer back to the ``commitlint`` `reference rules <https://conventional-changelog.github.io/commitlint/#/reference-rules>`_.
|
||||
|
||||
Relationship between commit type and version bump
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This formula applies some customisations to the defaults, as outlined in the table below,
|
||||
based upon the `type <https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#type>`_ of the commit:
|
||||
|
||||
.. list-table::
|
||||
:name: commit-type-vs-version-bump
|
||||
:header-rows: 1
|
||||
:stub-columns: 0
|
||||
:widths: 1,2,3,1,1
|
||||
|
||||
* - Type
|
||||
- Heading
|
||||
- Description
|
||||
- Bump (default)
|
||||
- Bump (custom)
|
||||
* - ``build``
|
||||
- Build System
|
||||
- Changes related to the build system
|
||||
- –
|
||||
-
|
||||
* - ``chore``
|
||||
- –
|
||||
- Changes to the build process or auxiliary tools and libraries such as
|
||||
documentation generation
|
||||
- –
|
||||
-
|
||||
* - ``ci``
|
||||
- Continuous Integration
|
||||
- Changes to the continuous integration configuration
|
||||
- –
|
||||
-
|
||||
* - ``docs``
|
||||
- Documentation
|
||||
- Documentation only changes
|
||||
- –
|
||||
- 0.0.1
|
||||
* - ``feat``
|
||||
- Features
|
||||
- A new feature
|
||||
- 0.1.0
|
||||
-
|
||||
* - ``fix``
|
||||
- Bug Fixes
|
||||
- A bug fix
|
||||
- 0.0.1
|
||||
-
|
||||
* - ``perf``
|
||||
- Performance Improvements
|
||||
- A code change that improves performance
|
||||
- 0.0.1
|
||||
-
|
||||
* - ``refactor``
|
||||
- Code Refactoring
|
||||
- A code change that neither fixes a bug nor adds a feature
|
||||
- –
|
||||
- 0.0.1
|
||||
* - ``revert``
|
||||
- Reverts
|
||||
- A commit used to revert a previous commit
|
||||
- –
|
||||
- 0.0.1
|
||||
* - ``style``
|
||||
- Styles
|
||||
- Changes that do not affect the meaning of the code (white-space,
|
||||
formatting, missing semi-colons, etc.)
|
||||
- –
|
||||
- 0.0.1
|
||||
* - ``test``
|
||||
- Tests
|
||||
- Adding missing or correcting existing tests
|
||||
- –
|
||||
- 0.0.1
|
||||
|
||||
Use ``BREAKING CHANGE`` to trigger a ``major`` version change
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Adding ``BREAKING CHANGE`` to the footer of the extended description of the commit message will **always** trigger a ``major`` version change, no matter which type has been used.
|
||||
This will be appended to the changelog and release notes as well.
|
||||
To preserve good formatting of these notes, the following format is prescribed:
|
||||
|
||||
* ``BREAKING CHANGE: <explanation in paragraph format>.``
|
||||
|
||||
An example of that:
|
||||
|
||||
.. code-block:: git
|
||||
|
||||
...
|
||||
|
||||
BREAKING CHANGE: With the removal of all of the `.sls` files under
|
||||
`template package`, this formula no longer supports the installation of
|
||||
packages.
|
||||
|
||||
+264
@@ -0,0 +1,264 @@
|
||||
.. _readme:
|
||||
|
||||
openssh
|
||||
=======
|
||||
|img_travis| |img_sr|
|
||||
|
||||
.. |img_travis| image:: https://travis-ci.com/saltstack-formulas/openssh-formula.svg?branch=master
|
||||
:alt: Travis CI Build Status
|
||||
:scale: 100%
|
||||
:target: https://travis-ci.com/saltstack-formulas/openssh-formula
|
||||
.. |img_sr| image:: https://img.shields.io/badge/%20%20%F0%9F%93%A6%F0%9F%9A%80-semantic--release-e10079.svg
|
||||
:alt: Semantic Release
|
||||
:scale: 100%
|
||||
:target: https://github.com/semantic-release/semantic-release
|
||||
|
||||
Install and configure an openssh server.
|
||||
|
||||
.. contents:: **Table of Contents**
|
||||
|
||||
General notes
|
||||
-------------
|
||||
|
||||
See the full `SaltStack Formulas installation and usage instructions
|
||||
<https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html>`_.
|
||||
|
||||
If you are interested in writing or contributing to formulas, please pay attention to the `Writing Formula Section
|
||||
<https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html#writing-formulas>`_.
|
||||
|
||||
If you want to use this formula, please pay attention to the ``FORMULA`` file and/or ``git tag``,
|
||||
which contains the currently released version. This formula is versioned according to `Semantic Versioning <http://semver.org/>`_.
|
||||
|
||||
See `Formula Versioning Section <https://docs.saltstack.com/en/latest/topics/development/conventions/formulas.html#versioning>`_ for more details.
|
||||
|
||||
Contributing to this repo
|
||||
-------------------------
|
||||
|
||||
**Commit message formatting is significant!!**
|
||||
|
||||
Please see :ref:`How to contribute <CONTRIBUTING>` for more details.
|
||||
|
||||
Available states
|
||||
----------------
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
|
||||
``openssh``
|
||||
^^^^^^^^^^^
|
||||
|
||||
Installs the ``openssh`` server package and service.
|
||||
|
||||
``openssh.auth``
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Manages SSH certificates for users.
|
||||
|
||||
``openssh.auth_map``
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Same functionality as openssh.auth but with a simplified Pillar syntax.
|
||||
Plays nicely with `Pillarstack
|
||||
<https://docs.saltstack.com/en/latest/ref/pillar/all/salt.pillar.stack.html>`_.
|
||||
|
||||
``openssh.banner``
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Installs a banner that users see when SSH-ing in.
|
||||
|
||||
``openssh.client``
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Installs the openssh client package.
|
||||
|
||||
``openssh.config``
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Installs the ssh daemon configuration file included in this formula
|
||||
(under "openssh/files"). This configuration file is populated
|
||||
by values from pillar. ``pillar.example`` results in the generation
|
||||
of the default ``sshd_config`` file on Debian Wheezy.
|
||||
|
||||
It is highly recommended ``PermitRootLogin`` is added to pillar
|
||||
so root login will be disabled.
|
||||
|
||||
``openssh.config_ini``
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Version of managing ``sshd_config`` that uses the
|
||||
`ini_managed.option_present <https://docs.saltstack.com/en/latest/ref/states/all/salt.states.ini_manage.html>`_
|
||||
state module, so it enables to override only one or
|
||||
multiple values and keeping the defaults shipped by your
|
||||
distribution.
|
||||
|
||||
|
||||
``openssh.known_hosts``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Manages ``/etc/ssh/ssh_known_hosts`` and fills it with the
|
||||
public SSH host keys of your minions (collected via the Salt mine)
|
||||
and of hosts listed in you pillar data. It's possible to include
|
||||
minions managed via ``salt-ssh`` by using the ``known_hosts_salt_ssh`` renderer.
|
||||
|
||||
You can restrict the set of minions
|
||||
whose keys are listed by using the pillar data ``openssh:known_hosts:target``
|
||||
and ``openssh:known_hosts:tgt_type`` (those fields map directly to the
|
||||
corresponding attributes of the ``mine.get`` function).
|
||||
|
||||
The **Salt mine** is used to share the public SSH host keys, you must thus
|
||||
configure it accordingly on all hosts that must export their keys. Two
|
||||
mine functions are required, one that exports the keys (one key per line,
|
||||
as they are stored in ``/etc/ssh/ssh_host_*_key.pub``) and one that defines
|
||||
the public hostname that the keys are associated to. Here's the way to
|
||||
setup those functions through pillar::
|
||||
|
||||
# Required for openssh.known_hosts
|
||||
mine_functions:
|
||||
public_ssh_host_keys:
|
||||
mine_function: cmd.run
|
||||
cmd: cat /etc/ssh/ssh_host_*_key.pub
|
||||
python_shell: True
|
||||
public_ssh_hostname:
|
||||
mine_function: grains.get
|
||||
key: id
|
||||
|
||||
The above example assumes that the minion identifier is a valid DNS name
|
||||
that can be used to connect to the host. If that's not the case, you might
|
||||
want to use the ``fqdn`` grain instead of the ``id`` one. The above example
|
||||
also uses the default mine function names used by this formula. If you have to
|
||||
use other names, then you should indicate the names to use in pillar keys
|
||||
``openssh:known_hosts:mine_keys_function`` and
|
||||
``openssh:known_hosts:mine_hostname_function``.
|
||||
|
||||
You can also integrate alternate DNS names of the various hosts in
|
||||
``/etc/ssh/ssh_known_hosts``. You just have to specify all the alternate DNS names as a
|
||||
list in the ``openssh:known_hosts:aliases`` pillar key. Whenever the IPv4 or
|
||||
IPv6 behind one of those DNS entries matches an IPv4 or IPv6 behind the
|
||||
official hostname of a minion, the alternate DNS name will be associated to the
|
||||
minion's public SSH host key.
|
||||
|
||||
To **include minions managed via salt-ssh** install the ``known_hosts_salt_ssh`` renderer::
|
||||
|
||||
# in pillar.top:
|
||||
'*':
|
||||
- openssh.known_hosts_salt_ssh
|
||||
|
||||
# In your salt/ directory:
|
||||
# Link the pillar file:
|
||||
mkdir pillar/openssh
|
||||
ln -s ../../formulas/openssh-formula/_pillar/known_hosts_salt_ssh.sls pillar/openssh/known_hosts_salt_ssh.sls
|
||||
|
||||
You'll find the cached pubkeys in Pillar ``openssh:known_hosts:salt_ssh``.
|
||||
|
||||
It's possible to define aliases for certain hosts::
|
||||
|
||||
openssh:
|
||||
known_hosts:
|
||||
cache:
|
||||
public_ssh_host_names:
|
||||
minion.id:
|
||||
- minion.id
|
||||
- alias.of.minion.id
|
||||
|
||||
The cache is populated by applying ``openssh.gather_host_keys``
|
||||
to the salt master::
|
||||
|
||||
salt 'salt-master.example.test' state.apply openssh.gather_host_keys
|
||||
|
||||
The state tries to fetch the SSH host keys via ``salt-ssh``. It calls the command as user
|
||||
``salt-master`` by default. The username can be changed via Pillar::
|
||||
|
||||
openssh:
|
||||
known_hosts:
|
||||
cache:
|
||||
user: salt-master
|
||||
|
||||
Use a cronjob to populate a host key cache::
|
||||
|
||||
# crontab -e -u salt-master
|
||||
0 1 * * * salt 'salt-master.example.test' state.apply openssh.gather_host_keys
|
||||
|
||||
If you must have the latest pubkeys, run the state before all others::
|
||||
|
||||
# states/top.sls:
|
||||
base:
|
||||
salt:
|
||||
# slooooow!
|
||||
- openssh.gather_host_keys
|
||||
|
||||
You can also use a "golden" known hosts file. It overrides the keys fetched by the cronjob.
|
||||
This lets you re-use the trust estabished in the salt-ssh user's known_hosts file::
|
||||
|
||||
# In your salt/ directory: (Pillar expects the file here.)
|
||||
ln -s /home/salt-master/.ssh/known_hosts ./known_hosts
|
||||
|
||||
# Test it:
|
||||
salt-ssh 'minion' pillar.get 'openssh:known_hosts:salt_ssh'
|
||||
|
||||
To add **public keys of hosts not among your minions** list them under the
|
||||
pillar key ``openssh:known_hosts:static``::
|
||||
|
||||
openssh:
|
||||
known_hosts:
|
||||
static:
|
||||
github.com: 'ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq[...]'
|
||||
gitlab.com: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABA[...]'
|
||||
|
||||
Pillar ``openssh:known_hosts:static`` overrides ``openssh:known_hosts:salt_ssh``.
|
||||
|
||||
To **include localhost** and local IP addresses (``127.0.0.1`` and ``::1``) use this Pillar::
|
||||
|
||||
openssh:
|
||||
known_hosts:
|
||||
include_localhost: True
|
||||
|
||||
``openssh.moduli``
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Manages the system wide ``/etc/ssh/moduli`` file.
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
Linux testing is done with ``kitchen-salt``.
|
||||
|
||||
Requirements
|
||||
^^^^^^^^^^^^
|
||||
|
||||
* Ruby
|
||||
* Docker
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ gem install bundler
|
||||
$ bundle install
|
||||
$ bin/kitchen test [platform]
|
||||
|
||||
Where ``[platform]`` is the platform name defined in ``kitchen.yml``,
|
||||
e.g. ``debian-9-2019-2-py3``.
|
||||
|
||||
``bin/kitchen converge``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Creates the docker instance and runs the ``template`` main state, ready for testing.
|
||||
|
||||
``bin/kitchen verify``
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Runs the ``inspec`` tests on the actual instance.
|
||||
|
||||
``bin/kitchen destroy``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Removes the docker instance.
|
||||
|
||||
``bin/kitchen test``
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Runs all of the stages above in one go: i.e. ``destroy`` + ``converge`` + ``verify`` + ``destroy``.
|
||||
|
||||
``bin/kitchen login``
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Gives you SSH access to the instance for manual testing.
|
||||
|
||||
+80
-5
@@ -39,7 +39,7 @@ Using SaltStack is a simple and effective way to implement configuration managem
|
||||
|
||||
To avoid this situation we can use the `pillar mechanism <http://docs.saltstack.com/en/latest/topics/pillar/>`_, which is designed to provide controlled access to data from the minions based on some selection rules. As pillar data could be easily integrated in the `Jinja <http://docs.saltstack.com/en/latest/topics/tutorials/pillar.html>`_ templates, it is a good mechanism to store values to be used in the final rendering of state files and templates.
|
||||
|
||||
There are a variety of approaches on the usage of pillar and templates as seen in the `saltstack-formulas <https://github.com/saltstack-formulas>`_' repositories. `Some <https://github.com/saltstack-formulas/nginx-formula/pull/18>`_ `developments <https://github.com/saltstack-formulas/php-formula/pull/14>`_ stress the initial purpose of pillar data into a storage for most of the possible variables for a determined system configuration. This, in my opinion, is shifting too much load from the original template files approach. Adding up some `non-trivial Jinja <https://github.com/spsoit/nginx-formula/blob/81de880fe0276dd9488ffa15bc78944c0fc2b919/nginx/ng/files/nginx.conf>`_ code as essential part of composing the state file definitely makes SaltStack state files (hence formulas) more difficult to read. The extreme of this approach is that we could end up with a new render mechanism, implemented in Jinja, storing everything needed in pillar data to compose configurations. Additionally, we are establishing a strong dependency with the Jinja renderer.
|
||||
There are a variety of approaches on the usage of pillar and templates as seen in the `saltstack-formulas <https://github.com/saltstack-formulas>`_' repositories. `Some <https://github.com/saltstack-formulas/nginx-formula/pull/18>`_ `developments <https://github.com/saltstack-formulas/php-formula/pull/14>`_ stress the initial purpose of pillar data into a storage for most of the possible variables for a determined system configuration. This, in my opinion, is shifting too much load from the original template files approach. Adding up some `non-trivial Jinja <https://github.com/saltstack-formulas/nginx-formula/blob/f74254c07e188bd448eaf1c5f9c802d78c4c005e/nginx/files/default/nginx.conf>`_ code as essential part of composing the state file definitely makes SaltStack state files (hence formulas) more difficult to read. The extreme of this approach is that we could end up with a new render mechanism, implemented in Jinja, storing everything needed in pillar data to compose configurations. Additionally, we are establishing a strong dependency with the Jinja renderer.
|
||||
|
||||
In opposition to the *put the code in file_roots and the data in pillars* approach, there is the *pillar as a store for a set of key-values* approach. A full-blown configuration file abstracted in pillar and jinja is complicated to develop, understand and maintain. I think a better and simpler approach is to keep a configuration file templated using just a basic (non-extensive but extensible) set of pillar values.
|
||||
|
||||
@@ -325,6 +325,7 @@ We can simplify the ``conf.sls`` with the new ``files_switch`` macro to use in t
|
||||
|
||||
|
||||
* This uses ``config.get``, searching for ``ntp:tofs:source_files:Configure NTP`` to determine the list of template files to use.
|
||||
* If this returns a result, the default of ``['/etc/ntp.conf.jinja']`` will be appended to it.
|
||||
* If this does not yield any results, the default of ``['/etc/ntp.conf.jinja']`` will be used.
|
||||
|
||||
In ``libtofs.jinja``, we define this new macro ``files_switch``.
|
||||
@@ -426,7 +427,6 @@ The list of ``source_files`` can be given:
|
||||
tofs:
|
||||
source_files:
|
||||
Configure NTP:
|
||||
- '/etc/ntp.conf.jinja'
|
||||
- '/etc/ntp.conf_alt.jinja'
|
||||
|
||||
Resulting in:
|
||||
@@ -434,10 +434,85 @@ Resulting in:
|
||||
.. code-block:: sls
|
||||
|
||||
- source:
|
||||
- salt://ntp/files/theminion/etc/ntp.conf.jinja
|
||||
- salt://ntp/files/theminion/etc/ntp.conf_alt.jinja
|
||||
- salt://ntp/files/Debian/etc/ntp.conf.jinja
|
||||
- salt://ntp/files/theminion/etc/ntp.conf.jinja
|
||||
- salt://ntp/files/Debian/etc/ntp.conf_alt.jinja
|
||||
- salt://ntp/files/default/etc/ntp.conf.jinja
|
||||
- salt://ntp/files/Debian/etc/ntp.conf.jinja
|
||||
- salt://ntp/files/default/etc/ntp.conf_alt.jinja
|
||||
- salt://ntp/files/default/etc/ntp.conf.jinja
|
||||
|
||||
Note: This does *not* override the default value.
|
||||
Rather, the value from the pillar/config is prepended to the default.
|
||||
|
||||
Using sub-directories for ``components``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If your formula is composed of several components, you may prefer to provides files under sub-directories, like in the `systemd-formula <https://github.com/saltstack-formulas/systemd-formula>`_.
|
||||
|
||||
.. code-block::
|
||||
|
||||
/srv/saltstack/systemd-formula/
|
||||
systemd/
|
||||
init.sls
|
||||
libtofs.jinja
|
||||
map.jinja
|
||||
networkd/
|
||||
init.sls
|
||||
files/
|
||||
default/
|
||||
network/
|
||||
99-default.link
|
||||
resolved/
|
||||
init.sls
|
||||
files/
|
||||
default/
|
||||
resolved.conf
|
||||
timesyncd/
|
||||
init.sls
|
||||
files/
|
||||
Arch/
|
||||
resolved.conf
|
||||
Debian/
|
||||
resolved.conf
|
||||
default/
|
||||
resolved.conf
|
||||
Ubuntu/
|
||||
resolved.conf
|
||||
|
||||
For example, the following ``formula.component.config`` SLS:
|
||||
|
||||
.. code-block:: sls
|
||||
|
||||
{%- from "formula/libtofs.jinja" import files_switch with context %}
|
||||
|
||||
formula configuration file:
|
||||
file.managed:
|
||||
- name: /etc/formula.conf
|
||||
- user: root
|
||||
- group: root
|
||||
- mode: 644
|
||||
- template: jinja
|
||||
- source: {{ files_switch(['formula.conf'],
|
||||
lookup='formula',
|
||||
use_subpath=True
|
||||
)
|
||||
}}
|
||||
|
||||
will be rendered on a ``Debian`` minion named ``salt-formula.ci.local`` as:
|
||||
|
||||
.. code-block:: sls
|
||||
|
||||
formula configuration file:
|
||||
file.managed:
|
||||
- name: /etc/formula.conf
|
||||
- user: root
|
||||
- group: root
|
||||
- mode: 644
|
||||
- template: jinja
|
||||
- source:
|
||||
- salt://formula/component/files/salt-formula.ci.local/formula.conf
|
||||
- salt://formula/component/files/Debian/formula.conf
|
||||
- salt://formula/component/files/default/formula.conf
|
||||
- salt://formula/files/salt-formula.ci.local/formula.conf
|
||||
- salt://formula/files/Debian/formula.conf
|
||||
- salt://formula/files/default/formula.conf
|
||||
|
||||
Reference in New Issue
Block a user