Manage CryptPad with Salt and Podman.
Table of Contents
See the full SaltStack Formulas installation and usage instructions.
If you are interested in writing or contributing to formulas, please pay attention to the Writing Formula Section.
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.
See Formula Versioning Section for more details.
If you need (non-default) configuration, please refer to:
- how to configure the formula with map.jinja
- the
pillar.examplefile - the Special notes section
- This formula is written with the custom compose modules in mind and will not work without them.
- The semi-official containers (which this formula is intended to manage) are currently unmaintained. They are still on v5.2.1, while the latest release is 5.3. Furthermore, the (default) dual-service container's nginx.conf is broken. This formula contains a patch that should make the
cryptpad:nginxcontainer run again until the official ones are released. At this point, this formula will be updated to use those.
An example pillar is provided, please see pillar.example. Note that you do not need to specify everything by pillar. Often, it's much easier and less resource-heavy to use the parameters/<grain>/<value>.yaml files for non-sensitive settings. The underlying logic is explained in map.jinja.
The following states are found in this formula:
Meta-state.
This installs the cryptpad containers, manages their configuration and starts their services.
Installs the cryptpad containers only. This includes creating systemd service units.
Generates a TLS certificate + key for Cryptpad. Has a dependency on cryptpad.package.
Manages the configuration of the cryptpad containers. Has a dependency on cryptpad.package.
Starts the cryptpad container services and enables them at boot time. Has a dependency on cryptpad.config.
Meta-state.
Undoes everything performed in the cryptpad meta-state
in reverse order, i.e. stops the cryptpad services,
removes their configuration and then removes their containers.
Removes the cryptpad containers
and the corresponding user account and service units.
Has a depency on cryptpad.config.clean.
If remove_all_data_for_sure was set, also removes all data.
Removes generated Cryptpad TLS certificate + key. Depends on cryptpad.service.clean.
Removes the configuration of the cryptpad containers and has a dependency on cryptpad.service.clean.
This does not lead to the containers/services being rebuilt and thus differs from the usual behavior.
Stops the cryptpad container services and disables them at boot time.
Commit message formatting is significant!
Please see How to contribute for more details.
pre-commit is configured for this formula, which you may optionally use to ease the steps involved in submitting your changes.
First install the pre-commit package manager using the appropriate method, then run bin/install-hooks and
now pre-commit will run automatically on each git commit.
$ bin/install-hooks pre-commit installed at .git/hooks/pre-commit pre-commit installed at .git/hooks/commit-msg
There is a script that semi-autodocuments available states: bin/slsdoc.
If a .sls file begins with a Jinja comment, it will dump that into the docs. It can be configured differently depending on the formula. See the script source code for details currently.
This means if you feel a state should be documented, make sure to write a comment explaining it.
Linux testing is done with kitchen-salt.
- Ruby
- Docker
$ 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.
Creates the docker instance and runs the cryptpad main state, ready for testing.
Runs the inspec tests on the actual instance.
Removes the docker instance.
Runs all of the stages above in one go: i.e. destroy + converge + verify + destroy.
Gives you SSH access to the instance for manual testing.