...
This feature is realized as follows: Update requests to the remote sites get forwarded to the central site – The entire configuration and the agent baking process are done on the central site. Agent packages that got requested once at a remote site will get cached (as long as they are valid) there to save unnecessary traffic. Additionally, the requested data will be checked for consistency on the remote site, again to save unnecessary traffic to the central site.
General Communication Settings
Depending on the setting Update server information in the rule "Agent updater (Linux, Windows, Solaris)" and on the command line options during registration, the communication between the agent updater and the Checkmk servers can be configured granular. That way, you can restrict the communication to either the central Bakery or to the remote site server, if needed.
| CLI options during registration | Settings in Bakery Rule | Remote Site server reachable | Registration Server used | Package Download Server used |
|---|---|---|---|---|
| -s and -i | not used | yes | The server/site provided with -s | The dedicated remote server with the URL configured in the „Distributed Monitoring“ settings |
| none | „use for all connections“ | yes | The server/site provided in the Bakery rule | The server provided in the Bakery rule |
| none | „use for registration and fallback“ | yes | The server/site provided in the Bakery rule | The dedicated remote server with the URL configured in the „Distributed Monitoring“ settings |
| none | „use for registration and fallback“ | no | The server/site provided in the Bakery rule | The server provided in the Bakery rule |
| none | not configured | yes | Interactively asks for server | The dedicated remote server with the URL configured in the „Distributed Monitoring“ settings |
Example:
If you want to restrict the communication of the agent updater to the particular remote server,
- you can skip the Update server information in the Bakery rule.
- That way, you have a single software package per OS to install all your hosts.
- You just have to provide the remote server and site during the registration on the CLI.
- With https, you have to add the certificates of all your servers to the Bakery rule (when using Self signed certificates) or at least the root and intermediate ones (when using a CA).
Registration
| Code Block | ||||
|---|---|---|---|---|
| ||||
Going to register agent at deployment server
2021-02-04 16:18:08,715 DEBUG: Authenticating at Check_MK Server (using requests): http://myhost/myremotesite/check_mk/login.py
2021-02-04 16:18:09,034 DEBUG: Fetching content (using requests): http://myhost/myremotesite/check_mk/register_agent.py
2021-02-04 16:18:09,070 DEBUG: Response from agent bakery:
{"result_code": 0, "result": {"host_secret": "rlkaihuoazcdcnseimvfpzaocsjitoabpieyzubuictninlfdtgciztydmkmfrfj", "update_url": "http:\/\/myhost\/myremotesite\/check_mk\/", "monitored": true}}
2021-02-04 16:18:09,070 INFO: Applying new update URL http://myhost/myremotesite/check_mk/ from deployment server
2021-02-04 16:18:09,071 DEBUG: No state file found yet. New state data will be saved to /etc/cmk-update-agent.state
2021-02-04 16:18:09,073 DEBUG: Saved deployment status to /etc/cmk-update-agent.state.
2021-02-04 16:18:09,073 INFO: Successfully registered agent of host "myremotesite" for deployment.
2021-02-04 16:18:09,073 DEBUG: Secret is rlkaihuoazcdcnseimvfpzaocsjitoabpieyzubuictninlfdtgciztydmkmfrfj.
2021-02-04 16:18:09,073 DEBUG: Successfully read /etc/cmk-update-agent.state.
2021-02-04 16:18:09,075 DEBUG: Saved deployment status to /etc/cmk-update-agent.state.
2021-02-04 16:18:09,076 INFO: Saved your registration settings to /etc/cmk-update-agent.state.
2021-02-04 16:18:09,076 DEBUG: Successfully scheduled an automatic update with next Check_MK Agent execution.
2021-02-04 16:18:09,076 DEBUG: Done. |
...