When committing an item with `ignore_on_error` flag set fails, the `Commit()` method only returns `nullptr`
and the current item is not being dropped from `m_Items`. `CommittNewItems()` also doesn't check the return
value of `Commit()` but just continues and tries to commit all items from `m_Items` in recursive call. Since
this corrupt item is never removed from `m_Items`, it ends up in an endless recursion till it finally crashes.
The point of logging to the Windows Event Log was to catch errors that happen
before the full logging configuration has been loaded and enabled. Messages
like the number of loaded objects per type just cause noise in the log and
provide little benefit. Therefore raise the required log level at this stage.
Note that this commit removes the (never documented) ability to use the -x flag
to change the level. But doing so would require patching the command line of
the service in the registry anyways.
Raspbian builds were running on Ubuntu 20.04 but with qemu-user-static from Ubuntu 21.10 (impish) due to need for newer features. However, the impish package repos are no longer available as that version reached its EOL. ubuntu-latest still refers to 20.04 on GitHub Actions but 22.04 is already available when explicitly specified. This commit switches the build over to that version and removes the workaround.
Almost every Icinga 2 node setup requires the Icinga 2 API, as Icinga
Web connects to it, Icinga DB requires it, and although it's not clearly
mentioned anywhere in the documentation at the moment, it enables the
cluster communication functionality.
We are using a central DB-Cluster, therefor Icinga2 got a database on this remote cluster.
We used the icinga DB user, created during the step before, to import the DB schema.
For this, the additional GRANT options `ALTER` and `CREATE` where needed to install the schema successfully via:
```bash
mysql -u icinga -p icinga < /usr/share/icinga2-ido-mysql/schema/mysql.sql
```
Someone may find this a security problem. But I see two benefits:
* these GRANT options are only set for the icinga.* database
* this setup allows to execute also all later UPGRADE commands as the database user `icinga` - and not as the DB Administrator.
Two additional notes:
* I also included a small warning about the used default DB password
* sadly, I have no way to change this also in the provided mariadb-centos7.png image, so this is left unchanged at the moment
