Inspired by an Icinga Community thread[^0], it was ensured that Icinga
DB only uses Redis keys in the "icinga" and "icingadb" namespaces[^1].
This change and, more importantly, how to configure Redis ACLs to ensure
only those namespaces can be accessed, are now documented.
[^0]: https://community.icinga.com/t/redis-user-acl-for-icingadb/15309
[^1]: 3a6df542f7
When skipping a version for an Icinga DB upgrade, all intermediate
upgrade steps must be taken. While this is already stated in the
documentation, it might be overlooked.
This happened for one community user, upgrading from v1.1.0 to v1.2.0,
skipping the intermediate schema upgrade for v1.1.1.
> https://community.icinga.com/t/icingadb-failing-exactly-5-minutes-after-start/13955
First, the necessity for all upgrades in their release order was made
more prominent in the documentation, hoping that less users would ignore
this when skimming the upgrade docs.
However, the real change here is adding another check to the CheckSchema
function, verifying that all schema upgrades between the lowest known
version and the highest known version in the icingadb_schema table
exists. If an intermediate schema upgrade was skipped, as in the thread
above, this raises a descriptive error.
Drop the "-source" suffix from the configuration option. Furhtermore,
with the latest IGL release 0.8.1[0], the "api-base-url" is renamed to
just "url".
[0]: https://github.com/Icinga/icinga-go-library/pull/168
Explicitly state that the "icingadb" PostgreSQL database user must be
used for schema upgrades.
The PostgreSQL database user applying a schema upgrade is the table
owner of newly create tables. When applying an Icinga DB schema upgrade
not as the "icingadb" user, but as "postgres", newly created tables
would not be accessible for the "icingadb" user, resulting in Icinga DB
and Icinga DB Web to fail.
Reported in #987.
Add a new section to the documentation about installing in containerized
environments. Also, add a GitHub Action that pushes this new section to
Docker Hub to display it as the container README.
The newly introduced Operations section is a first attempt at an
operational Icinga DB documentation.
It covers
- essential Icinga DB monitoring,
- backups and corner cases for MySQL/MariaDB,
- MySQL/MariaDB configuration options, including AWS RDS and Galera,
- and memory overcommitment for Redis.
As such a section can never be completed, this documentation is a target
for continuous improvement.
Fixes#745.
The logging was slightly modified in #920, resulting in a few log
messages being shown regardless of the user configured log level. Since
this may not be the expected behavior, it is now mentioned in the docs.
Inspired by the "Big Picture" section in the Icinga Notifications
documentation[^0], such a section was introduced for Icinga DB as well.
It aims to describe the essential components in an Icinga DB setup along
the architecture diagram for novice users. This hopefully helps new
users to understand what Icinga DB actually is and how it interconnects.
[^0]: https://icinga.com/docs/icinga-notifications/latest/#big-picture
The fields of both ido and icingadb were not described so far. As being
an IGL database.Config, they match Icinga DB's database configuration,
which was referenced, with the from/to exception.
A new section on how to actually apply the database schema upgrade was
introduced. This new section should take a user's fear to mess up a
schema upgrade.
Fixes#926.
Since I just did a good old-fashioned Icinga DB installation using
PostgreSQL on a vanilla Debian system, there were several tripwires I
successfully stumbled upon while following our PostgreSQL installation
docs. And this is far from the first time I have installed an Icinga DB.
First, I changed the order to put the requirements before the commands
that require them. Otherwise, following the documentation from top to
bottom will result in errors that will be addressed later.
In addition, I added a sentence about where to find the pg_hba.conf. I
also explained how to tighten up network-based access and the
availability of more modern hash algorithms on almost all of the
operating systems we target.
Since the vanilla Debian I was using had almost no locales, PostgreSQL
was unhappy about that as well, and I thought a paragraph on that would
not hurt.
Co-Authored-By: Julian Brost <julian.brost@icinga.com>
New ways to configure Icinga DB were introduced in [icingadb-831] and
[igl-113]. The first change allows configuring Icinga DB using
environment variables instead of or next to the YAML configuration file.
In addition, the second change allows setting certificates and keys as
PEM-encoded strings next to referencing files. This was now documented.
As a structural change, the order of the Database and Redis sections
were changed to reflect the order in the example configuration file.
Some words about the Logging Components were written, as the
documentation previously that they exist.
[icingadb-831]: https://github.com/Icinga/icingadb/pull/831
[igl-113]: https://github.com/Icinga/icinga-go-library/pull/113
Removes the package installation steps for the different operating systems to
have them injected centrally by our icinga.com documentation tools instead,
while maintaining readability and comprehensibility on GitHub and other
viewers.
While working on an issue where the additional logging information
provided by zap fields was missing, I realized that our documentation
did not indicate how to view them. So a new documentation section has
been added explaining how to view the fields when using the
`systemd-journald` logging output.
Also removes one trailing space.
