We should use `$Global:ProgressPreference = 'SilentlyContinue';` to disable the progress bar during download.
By doing so, information are directly written to the disk instead of written inside the memory and dumped to the disk afterwards
Fix misleading statement:
```
types = [ Acknowledgement, Recovery ]
```
right after a Notification config block will not help as this will only work on a `User` object.
* Update 09-object-types.md
Because in this document it is not clear which units are allowed for DB Cleanup, I asked in the Community for it: https://community.icinga.com/t/db-ido-cleanup-possible-units/3854/2. We came to the conclusion that it would help if there is a notice which units are possible/allowed for this. For better finding I wrote also a link to the language reference.
* Update 09-object-types.md
changed to the proposed "language reference"
* Update 09-object-types.md
Done. Sorry overlooked
* Update 09-object-types.md
accidentally inserted return undone . Hope now fits 😃
* Update 09-object-types.md
Requested Changes don
* Update 09-object-types.md
changed link to duration-literals
The API call does not explicitly specify `fixed` so the default of `true` is used. For a fixed downtime, `duration` is ignored so there is no reason for specifying it and it's just confusing ("why do I have to give start/end *and* a duration which should be the difference between start and end anyways?").
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