// This file is being generated by .github/workflows/gh-pages.yml - all local changes will be lost eventually! = ansible-role-checkmk_server Jonas Pammer opensource@jonaspammer.at; :toc: :toclevels: 2 :toc-placement!: :source-highlighter: rouge :no_change_needed: These variables do not need to be changed under normal circumstances, and certainly not if you are using the default version of the server.

[IMPORTANT] This role is deprecated in favor of the https://github.com/Checkmk/ansible-collection-tribe29.checkmk[official role from tribe29].

An Ansible role for installing https://checkmk.com/product/raw-edition[CheckMK RAW edition], setting up a site and configuring basic CheckMk functionality parameters.

This role does not

• configure NTP (recommended by CheckMk)
• configure a SMTP-Server
• support SUSE Linux Enterprise Server (pull request welcome if requested, though)

toc::[]

[[meta]] == 🔎 Metadata Below you can find information on…

• the role's required Ansible version
• the role's supported platforms
• the role's https://docs.ansible.com/ansible/latest/user_guide/playbooks_reuse_roles.html#role-dependencies[role dependencies]

.link:meta/main.yml[] [source,yaml]

---

---

galaxy_info: role_name: "checkmk_server" description: "Deprecated in favor of the official checkmk_server role." standalone: true

author: "jonaspammer" license: "MIT"

min_ansible_version: "2.11" platforms: # note: text after "actively tested: " represent the docker image name - name: EL # (Enterprise Linux) versions: - "8" # actively tested: rockylinux8 # available after 2.1.0p13 # - "9" # actively tested: rockylinux9 - name: Debian versions: - buster # actively tested: debian10 - bullseye # actively tested: debian11 - name: Ubuntu versions: - xenial # actively tested: ubuntu1604 - bionic # actively tested: ubuntu1804 - focal # actively tested: ubuntu2004 - jammy # actively tested: ubuntu2204

galaxy_tags: []

dependencies: []

[[requirements]] == 📌 Requirements // Any prerequisites that may not be covered by this role or Ansible itself should be mentioned here. The Ansible User needs to be able to become.

The https://galaxy.ansible.com/community/general[`community.general` collection] must be installed on the Ansible controller.

[[variables]] == 📜 Role Variables // A description of the settable variables for this role should go here // and any variables that can/should be set via parameters to the role. // Any variables that are read from other roles and/or the global scope (ie. hostvars, group vars, etc.) // should be mentioned here as well.

[source,yaml]

checkmk_site_url: "http://localhost/{{ checkmk_server_site }}"

URL resolving to the CheckMk site. Must not end with an /.

[source,yaml]

checkmk_server_site: "main"

Name of OMD "site" to create; this is often shown as my-site in the CheckMK documentation examples.

[source,yaml]

checkmk_server_download_checksum: [OS-specific, see /defaults directory] checkmk_server_version: "2.0.0p27"

---

Version of CheckMK RAW edition to install.

The default value of these variables is semi-automatically being updated to the latest non-beta CheckMk RAW v2 Release through the help of a CI Workflow and some accompanying python scripts which can be found in __scripts.

Every said update is accompanied with a new release of at least a minor version bump. See <> for an overview.

[NOTE] Even though you could pin the version of this role to get a pinned version of checkmk, I recommend that you install the latest version of this role and change these variables yourself instead as I do not backport actual patches made to this role into older versions (if that is even possible).

[[variables--installation]] === Role Variables used for installing [source,yaml]

---

checkmk_server_prerequisites: [OS-specific by default, see /vars directory]

List of packages to install using the system's package manager.

Note that this role makes use of the https://linuxhint.com/enable-powertools-repository-centos/[PowerTools] repository if dnf is the system's package manager (as defined by ansible_pkg_mgr).

[source,yaml]

checkmk_server_install_cache_valid_time: "3600"

(Debian/Ubuntu only) cache_valid_time passed to the apt module.

[source,yaml]

checkmk_server_download_package: [OS-specific, see /defaults directory] checkmk_server_download_url: "https://download.checkmk.com/checkmk/{{ checkmk_server_version }}/{{ checkmk_server_download_package }}" checkmk_server_download_pubkey_url: "https://download.checkmk.com/checkmk/Check_MK-pubkey.gpg" checkmk_server_download_dest: "{{ checkmk_server_download_dest_folder }}/{{ checkmk_server_download_package }}" checkmk_server_download_dest_folder: "/opt" checkmk_server_download_mode: u=rw,g=r,o=r

checkmk_server_man_path: "/usr/share/man/man8" checkmk_server_man_mode: u=rwx,g=rx,o=rx

checkmk_server_omd_setup_command: "omd setup" checkmk_server_omd_setup_creates: "/opt/omd"

---

{no_change_needed}

[[variables--site]] === Role Variables used for site creation

[source,yaml]

checkmk_server_htpasswd: ~ # not defined by default

If not defined, CheckMk generates a random password and outputs it into checkmk_server_omd_create_creates.

[source,yaml]

checkmk_server_omd_create_command: "omd create {{ checkmk_server_site }}" checkmk_server_omd_create_creates: "/opt/omd/sites/{{ checkmk_server_site }}" checkmk_server_log_dest: "/opt/omd/sites/{{ checkmk_server_site }}/omd-create.log" checkmk_server_log_group: "{{ checkmk_server_site }}" checkmk_server_log_mode: 'u=rw,g=,o=' checkmk_server_log_owner: "{{ checkmk_server_site }}"

checkmk_server_htpasswd_group: "{{ checkmk_server_site }}" checkmk_server_htpasswd_mode: u=rw,g=rw,o= # pragma: allowlist secret checkmk_server_htpasswd_name: "cmkadmin" # pragma: allowlist secret checkmk_server_htpasswd_owner: "{{ checkmk_server_site }}" checkmk_server_htpasswd_path: "/opt/omd/sites/{{ checkmk_server_site }}/etc/htpasswd"

checkmk_server_omd_start_command: "omd start {{ checkmk_server_site }}" checkmk_server_omd_start_creates: "/opt/omd/sites/{{ checkmk_server_site }}/tmp/apache/run/apache.pid"

checkmk_apache_service: [OS-specific, see /defaults directory]

{no_change_needed}

[[variables--component_config]] === Role Variables used to configure CheckMk's components

OMD is a system that integrates multiple software components into a monitoring system. In so doing, some components are optional, and for some there are alternatives or different operational settings. https://docs.checkmk.com/latest/en/omd_basics.html#omdconfig[All of this] can be comfortably configured with these variables (actually issues omd config).

#Note that the CheckMk site must temporarily be stopped if a change is required.#

The most important are:

CORE:: Selection of the monitoring core. MKEVENTD:: Activates the Checkmk Event Console, with which the syslog messages, SNMP-Traps and other events can be processed MKNOTIFYD:: Enterprise Editions: Activates the notification spooler. AUTOSTART:: This is primarily of interest for test installations that should not normally start by themselves. LIVESTATUS_TCP:: Allows external access to the status data for this site. A distributed monitoring can be constructed with this. The status of this instance can be incorporated into the central instance. Please only activate it in a secure network.

[source,yaml]

checkmk_server_site_conf: true

Enable/Disable configuration of site configuration by this role.

[source,yaml]

checkmk_server_omd_config_show_command: "omd config {{ checkmk_server_site }} show {{ item.var }}" checkmk_server_omd_config_set_command: "omd config {{ checkmk_server_site }} set {{ item.var }} {{ item.val }}"

checkmk_server_omd_stop_command: "omd stop {{ checkmk_server_site }}" checkmk_server_omd_stop_changed_when: '"killing" in __register.stdout'

---

Shouldn't need to be changed but can

==== General

[source,yaml]

checkmk_server_site_conf_admin_mail: checkmk_server_site_conf_autostart: "on" checkmk_server_site_conf_core: nagios checkmk_server_site_conf_tmpfs: "on"

---

==== Web GUI

[source,yaml]

checkmk_server_site_conf_apache_mode: own checkmk_server_site_conf_apache_tcp_addr: 127.0.0.1 checkmk_server_site_conf_apache_tcp_port: 5000 checkmk_server_site_conf_multisite_authorisation: "on" checkmk_server_site_conf_multisite_cookie_auth: "on" checkmk_server_site_conf_nagios_theme: classicui

---

==== Addons [source,yaml]

---

checkmk_server_site_conf_mkeventd: "on" checkmk_server_site_conf_mkeventd_snmptrap: "off" checkmk_server_site_conf_mkeventd_syslog: "off" checkmk_server_site_conf_mkeventd_syslog_tcp: "off" checkmk_server_site_conf_pnp4nagios: "on"

---

==== Distributed Monitoring [source,yaml,subs="+quotes,macros"]

---

checkmk_server_site_conf_livestatus_tcp: "off" checkmk_server_site_conf_ncsa: "off"

---

[[public_vars]] == 📜 Facts/Variables defined by this role

Each variable listed in this section is dynamically defined when executing this role (and can only be overwritten using ansible.builtin.set_facts) and is meant to be used not just internally.

[[tags]] == 🏷️ Tags

// Checkout https://github.com/tribe29/ansible-collection-tribe29.checkmk/blob/main/roles/server/README.md#tags // for an awesome example of grouping tasks using tags

Tasks are tagged with the following https://docs.ansible.com/ansible/latest/user_guide/playbooks_tags.html#adding-tags-to-roles[tags]:

[cols="1,1"] |=== |Tag | Purpose

2+| This role does not have officially documented tags yet.

// | download-xyz // | // | install-prerequisites // | // | install // | // | create-xyz // | |===

You can use Ansible to skip tasks, or only run certain tasks by using these tags. By default, all tasks are run when no tags are specified.

[[dependencies]] == 👫 Dependencies // A list of other roles should go here, // plus any details in regard to parameters that may need to be set for other roles, // or variables that are used from other roles.

apache__service:: Overwrites this role's version of the default for checkmk_apache_service

[[example_playbooks]] == 📚 Example Playbook Usages // Including examples of how to use this role in a playbook for common scenarios is always nice for users.

[NOTE]

This role is part of https://github.com/JonasPammer/ansible-roles[ many compatible purpose-specific roles of mine].

The machine needs to be prepared. In CI, this is done in molecule/default/prepare.yml which sources its soft dependencies from requirements.yml:

.link:molecule/default/prepare.yml[] [source,yaml]

---

Unresolved directive in README.orig.adoc - include::molecule/default/prepare.yml[]

The following diagram is a compilation of the "soft dependencies" of this role as well as the recursive tree of their soft dependencies.

image:https://raw.githubusercontent.com/JonasPammer/ansible-roles/master/graphs/dependencies_checkmk_server.svg[ requirements.yml dependency graph of jonaspammer.checkmk_server] ====

.Minimum Viable Play

[source,yaml]

roles:

• role: jonaspammer.checkmk_server

vars: some_var: "some_value"

---

====

[[tested-distributions]] == 🧪 Tested Distributions

A role may work on different distributions, like Red Hat Enterprise Linux (RHEL), even though there is no test for this exact distribution.

|=== | OS Family | Distribution | Distribution Release Date | Distribution End of Life | Accompanying Docker Image

| Rocky | Rocky Linux 8 (https://www.howtogeek.com/devops/is-rocky-linux-the-new-centos/[RHEL/CentOS 8 in disguise]) | 2021-06 | 2029-05 | https://github.com/geerlingguy/docker-rockylinux8-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux8-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Rocky | Rocky Linux 9 | 2022-07 | 2032-05 | https://github.com/geerlingguy/docker-rockylinux9-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-rockylinux9-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Ubuntu 1604 | 2016-04 | 2026-04 | https://github.com/geerlingguy/docker-ubuntu1604-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu1604-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Ubuntu 1804 | 2018-04 | 2028-04 | https://github.com/geerlingguy/docker-ubuntu1804-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu1804-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Ubuntu 2004 | 2021-04 | 2030-04 | https://github.com/geerlingguy/docker-ubuntu2004-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2004-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Ubuntu 2204 | 2022-04 | 2032-04 | https://github.com/geerlingguy/docker-ubuntu2204-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-ubuntu2204-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Debian 10 | 2019-07 | 2022-08 | https://github.com/geerlingguy/docker-debian10-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian10-ansible/workflows/Build/badge.svg?branch=master[CI]]

| Debian | Debian 11 | 2021-08 | 2024-07~ | https://github.com/geerlingguy/docker-debian11-ansible/actions?query=workflow%3ABuild[image:https://github.com/geerlingguy/docker-debian11-ansible/workflows/Build/badge.svg?branch=master[CI]] |===

[[tested-ansible-versions]] == 🧪 Tested Ansible versions

The tested ansible versions try to stay equivalent with the https://github.com/ansible-collections/community.general#tested-with-ansible[ support pattern of Ansible's community.general collection]. As of writing this is:

• 2.11 (Ansible 4)
• 2.12 (Ansible 5)
• 2.13 (Ansible 6)

[[development]] == 📝 Development // Badges about Conventions in this Project https://conventionalcommits.org[image:https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg[Conventional Commits]] https://results.pre-commit.ci/latest/github/JonasPammer/ansible-role-checkmk_server/master[image:https://results.pre-commit.ci/badge/github/JonasPammer/ansible-role-checkmk_server/master.svg[pre-commit.ci status]] // image:https://img.shields.io/badge/pre--commit-enabled-brightgreen?logo=pre-commit&logoColor=white[pre-commit, link=https://github.com/pre-commit/pre-commit]

[[development-system-dependencies]] === 📌 Development Machine Dependencies

• Python 3.9 or greater
• Docker

[[development-dependencies]] === 📌 Development Dependencies Development Dependencies are defined in a https://pip.pypa.io/en/stable/user_guide/#requirements-files[pip requirements file] named requirements-dev.txt. Example Installation Instructions for Linux are shown below:

---

"optional": create a python virtualenv and activate it for the current shell session

$ python3 -m venv venv $ source venv/bin/activate

$ python3 -m pip install -r requirements-dev.txt

[[development-guidelines]] === ℹ️ Ansible Role Development Guidelines

Please take a look at my https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_GUIDELINES.adoc[ Ansible Role Development Guidelines].

If interested, I've also written down some https://github.com/JonasPammer/cookiecutter-ansible-role/blob/master/ROLE_DEVELOPMENT_TIPS.adoc[ General Ansible Role Development (Best) Practices].

[[versioning]] === 🔢 Versioning

Versions are defined using https://git-scm.com/book/en/v2/Git-Basics-Tagging[Tags], which in turn are https://galaxy.ansible.com/docs/contributing/version.html[recognized and used] by Ansible Galaxy.

Versions must not start with v.

When a new tag is pushed, https://github.com/JonasPammer/ansible-role-checkmk_server/actions/workflows/release-to-galaxy.yml[ a GitHub CI workflow] (image:https://github.com/JonasPammer/ansible-role-checkmk_server/actions/workflows/release-to-galaxy.yml/badge.svg[Release CI]) takes care of importing the role to my Ansible Galaxy Account.

[[testing]] === 🧪 Testing Automatic Tests are run on each Contribution using GitHub Workflows.

The Tests primarily resolve around running https://molecule.readthedocs.io/en/latest/[Molecule] on a <<tested-distributions,varying set of linux distributions>> and using <<tested-ansible-versions,various ansible versions>>.

The molecule test also includes a step which lints all ansible playbooks using https://github.com/ansible/ansible-lint#readme[`ansible-lint`] to check for best practices and behaviour that could potentially be improved.

To run the tests, simply run tox on the command line. You can pass an optional environment variable to define the distribution of the Docker container that will be spun up by molecule:

---

$ MOLECULE_DISTRO=ubuntu2204 tox

For a list of possible values fed to MOLECULE_DISTRO, take a look at the matrix defined in link:.github/workflows/ci.yml[].

==== 🐛 Debugging a Molecule Container

1. Run your molecule tests with the option MOLECULE_DESTROY=never, e.g.:

• [subs="quotes,macros"]

---

$ MOLECULE_DESTROY=never MOLECULE_DISTRO=#ubuntu1604# tox -e py3-ansible-#5# ... TASK [ansible-role-pip : (redacted).] pass:[************************] failed: [instance-py3-ansible-5] => changed=false ... pass:[___________________________________ summary ____________________________________] pre-commit: commands succeeded ERROR: py3-ansible-5: commands failed

---

2. Find out the name of the molecule-provisioned docker container:

• [subs="quotes"]

---

$ docker ps #30e9b8d59cdf# geerlingguy/docker-debian10-ansible:latest "/lib/systemd/systemd" 8 minutes ago Up 8 minutes instance-py3-ansible-5

---

3. Get into a bash Shell of the container, and do your debugging:

• [subs="quotes"]

---

$ docker exec -it #30e9b8d59cdf# /bin/bash

root@instance-py3-ansible-2:/# root@instance-py3-ansible-2:/# python3 --version Python 3.8.10 root@instance-py3-ansible-2:/# ...

---

• [TIP]

  If the failure you try to debug is part of verify.yml step and not the actual converge.yml, you may want to know that the output of ansible's modules (vars), hosts (hostvars) and environment variables have been stored into files on both the provisioner and inside the docker machine under:

• /var/tmp/vars.yml
• /var/tmp/hostvars.yml
• /var/tmp/environment.yml

  grep, cat or transfer these as you wish!

• [TIP]

  You may also want to know that the files mentioned in the admonition above are attached to the GitHub CI Artifacts of a given Workflow run. + This allows one to check the difference between runs and thus help in debugging what caused the bit-rot or failure in general.

image::https://user-images.githubusercontent.com/32995541/178442403-e15264ca-433a-4bc7-95db-cfadb573db3c.png[]

4. After you finished your debugging, exit it and destroy the container:

• [subs="quotes"]

---

root@instance-py3-ansible-2:/# exit

$ docker stop #30e9b8d59cdf#

$ docker container rm #30e9b8d59cdf# or $ docker container prune

---

==== 🐛 Debugging installed package versions locally

Although a standard feature in tox 3, this https://github.com/tox-dev/tox/pull/2794[now] only happens when tox recognizes the presence of a CI variable. For example:

---

$ CI=true tox

[[development-container-extra]] === 🧃 TIP: Containerized Ideal Development Environment

This Project offers a definition for a "1-Click Containerized Development Environment".

This Container even enables one to run docker containers inside of it (Docker-In-Docker, dind), allowing for molecule execution.

To use it:

1. Ensure you fullfill the link:https://code.visualstudio.com/docs/remote/containers#_system-requirements[ the System requirements of Visual Studio Code Development Containers], optionally following the Installation-Section of the linked page section. + This includes: Installing Docker, Installing Visual Studio Code itself, and Installing the necessary Extension.
2. Clone the project to your machine
3. Open the folder of the repo in Visual Studio Code (File - Open Folder…).
4. If you get a prompt at the lower right corner informing you about the presence of the devcontainer definition, you can press the accompanying button to enter it. Otherwise, you can also execute the Visual Studio Command Remote-Containers: Open Folder in Container yourself (View - Command Palette -> type in the mentioned command).

[TIP]

I recommend using Remote-Containers: Rebuild Without Cache and Reopen in Container once here and there as the devcontainer feature does have some problems recognizing changes made to its definition properly some times. ====

[NOTE]

You may need to configure your host system to enable the container to use your SSH/GPG Keys.

The procedure is described https://code.visualstudio.com/remote/advancedcontainers/sharing-git-credentials[ in the official devcontainer docs under "Sharing Git credentials with your container"]. =====

[[cookiecutter]] === 🍪 CookieCutter

This Project shall be kept in sync with https://github.com/JonasPammer/cookiecutter-ansible-role[the CookieCutter it was originally templated from] using https://github.com/cruft/cruft[cruft] (if possible) or manual alteration (if needed) to the best extend possible.

.Official Example Usage of cruft update

---

image::https://raw.githubusercontent.com/cruft/cruft/master/art/example_update.gif[Official Example Usage of cruft update]

---

==== 🕗 Changelog When a new tag is pushed, an appropriate GitHub Release will be created by the Repository Maintainer to provide a proper human change log with a title and description.

[[pre-commit]] === ℹ️ General Linting and Styling Conventions General Linting and Styling Conventions are https://stackoverflow.blog/2020/07/20/linters-arent-in-your-way-theyre-on-your-side/[*automatically* held up to Standards] by various https://pre-commit.com/[`pre-commit`] hooks, at least to some extend.

Automatic Execution of pre-commit is done on each Contribution using https://pre-commit.ci/[`pre-commit.ci`]<<note_pre-commit-ci,*>>. Pull Requests even automatically get fixed by the same tool, at least by hooks that automatically alter files.

[NOTE]

Not to confuse: Although some pre-commit hooks may be able to warn you about script-analyzed flaws in syntax or even code to some extend (for which reason pre-commit's hooks are part of the test suite), pre-commit itself does not run any real Test Suites. For Information on Testing, see <>. ====

[TIP]

[[note_pre-commit-ci]] Nevertheless, I recommend you to integrate pre-commit into your local development workflow yourself.

This can be done by cd'ing into the directory of your cloned project and running pre-commit install. Doing so will make git run pre-commit checks on every commit you make, aborting the commit themselves if a hook alarm'ed.

You can also, for example, execute pre-commit's hooks at any time by running pre-commit run --all-files.

[[contributing]] == 💪 Contributing https://open.vscode.dev/JonasPammer/ansible-role-checkmk_server[image:https://img.shields.io/static/v1?logo=visualstudiocode&label=&message=Open%20in%20Visual%20Studio%20Code&labelColor=2c2c32&color=007acc&logoColor=007acc[Open in Visual Studio Code]] image:https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square[PRs Welcome]

// Included in README.adoc :toc: :toclevels: 3

The following sections are generic in nature and are used to help new contributors. The actual "Development Documentation" of this project is found under <>.

=== 🤝 Preamble First off, thank you for considering contributing to this Project.

Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.

[[cookiecutter--contributing]] === 🍪 CookieCutter This Project owns many of its files to https://github.com/JonasPammer/cookiecutter-ansible-role[the CookieCutter it was originally templated from].

Please check if the edit you have in mind is actually applicable to the template and if so make an appropriate change there instead. Your change may also be applicable partly to the template as well as partly to something specific to this project, in which case you would be creating multiple PRs.

=== 💬 Conventional Commits

A casual contributor does not have to worry about following https://github.com/JonasPammer/JonasPammer/blob/master/demystifying/conventional_commits.adoc[__the spec__] https://www.conventionalcommits.org/en/v1.0.0/[__by definition__], as pull requests are being squash merged into one commit in the project. Only core contributors, i.e. those with rights to push to this project's branches, must follow it (e.g. to allow for automatic version determination and changelog generation to work).

=== 🚀 Getting Started

Contributions are made to this repo via Issues and Pull Requests (PRs). A few general guidelines that cover both:

• Search for existing Issues and PRs before creating your own.
• If you've never contributed before, see https://auth0.com/blog/a-first-timers-guide-to-an-open-source-project/[ the first timer's guide on Auth0's blog] for resources and tips on how to get started.

==== Issues

Issues should be used to report problems, request a new feature, or to discuss potential changes before a PR is created. When you https://github.com/JonasPammer/ansible-role-checkmk_server/issues/new[ create a new Issue], a template will be loaded that will guide you through collecting and providing the information we need to investigate.

If you find an Issue that addresses the problem you're having, please add your own reproduction information to the existing issue rather than creating a new one. Adding a https://github.blog/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/[reaction] can also help be indicating to our maintainers that a particular problem is affecting more than just the reporter.

==== Pull Requests

PRs to this Project are always welcome and can be a quick way to get your fix or improvement slated for the next release. https://blog.ploeh.dk/2015/01/15/10-tips-for-better-pull-requests/[In general], PRs should:

• Only fix/add the functionality in question OR address wide-spread whitespace/style issues, not both.
• Add unit or integration tests for fixed or changed functionality (if a test suite already exists).
• Address a single concern
• Include documentation in the repo
• Be accompanied by a complete Pull Request template (loaded automatically when a PR is created).

For changes that address core functionality or would require breaking changes (e.g. a major release), it's best to open an Issue to discuss your proposal first.

In general, we follow the "fork-and-pull" Git workflow

1. Fork the repository to your own Github account
2. Clone the project to your machine
3. Create a branch locally with a succinct but descriptive name
4. Commit changes to the branch
5. Following any formatting and testing guidelines specific to this repo
6. Push changes to your fork
7. Open a PR in our repository and follow the PR template so that we can efficiently review the changes.

[[changelog]] == 🗒 Changelog Please refer to the https://github.com/JonasPammer/ansible-role-checkmk_server/releases[Release Page of this Repository] for a human changelog of the corresponding https://github.com/JonasPammer/ansible-role-checkmk_server/tags[Tags (Versions) of this Project].

Note that this Project adheres to Semantic Versioning. Please report any accidental breaking changes of a minor version update.

[[license]] == ⚖️ License

.link:LICENSE[]

MIT License

Copyright (c) 2022, Jonas Pammer

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

---