Trying to understand the Apache configuration

Troubleshooting
1

CMK version: check-mk-raw-2.0.0p12-sles15sp2-38.x86_64
OS version: SLES 15 SP3

Error message:

Output of “cmk --debug -vvn hostname”: (If it is a problem with checks or plugins)

vm58820-8:/omd/sites/test/etc/apache # su -l -c "/opt/omd/versions/2.0.0p12.cre/bin/cmk --debug -vvn check-mk" test
Checkmk version 2.0.0p12
Try license usage history update.
Trying to acquire lock on /omd/sites/test/var/check_mk/license_usage/next_run
Got lock on /omd/sites/test/var/check_mk/license_usage/next_run
Trying to acquire lock on /omd/sites/test/var/check_mk/license_usage/history.json
Got lock on /omd/sites/test/var/check_mk/license_usage/history.json
Next run time has not been reached yet. Abort.
Releasing lock on /omd/sites/test/var/check_mk/license_usage/history.json
Released lock on /omd/sites/test/var/check_mk/license_usage/history.json
Releasing lock on /omd/sites/test/var/check_mk/license_usage/next_run
Released lock on /omd/sites/test/var/check_mk/license_usage/next_run
Updating IPv4 DNS cache for check-mk: 10.201.25.252
Trying to acquire lock on /omd/sites/test/var/check_mk/ipaddresses.cache
Got lock on /omd/sites/test/var/check_mk/ipaddresses.cache
Releasing lock on /omd/sites/test/var/check_mk/ipaddresses.cache
Released lock on /omd/sites/test/var/check_mk/ipaddresses.cache
+ FETCHING DATA
  Source: SourceType.HOST/FetcherType.PIGGYBACK
[cpu_tracking] Start [7f5940ac2880]
No piggyback files for 'check-mk'. Skip processing.
No piggyback files for '10.201.25.252'. Skip processing.
[PiggybackFetcher] Fetch with cache settings: NoCache(base_path=PosixPath('/omd/sites/test/tmp/check_mk/data_source_cache/piggyback/check-mk'), max_age=MaxAge(checking=0, discovery=120, inventory=120), disabled=False, use_outdated=False, simulation=False)
[PiggybackFetcher] Execute data source
[cpu_tracking] Stop [7f5940ac2880 - Snapshot(process=posix.times_result(user=0.0, system=0.0, children_user=0.0, children_system=0.0, elapsed=0.0))]
[cpu_tracking] Start [7f5940ac2760]
+ PARSE FETCHER RESULTS
  Source: SourceType.HOST/FetcherType.PIGGYBACK
No persisted sections loaded
  -> Add sections: []
Received no piggyback data
Loading item states
Trying to acquire lock on /omd/sites/test/tmp/check_mk/counters/check-mk
Got lock on /omd/sites/test/tmp/check_mk/counters/check-mk
Releasing lock on /omd/sites/test/tmp/check_mk/counters/check-mk
Released lock on /omd/sites/test/tmp/check_mk/counters/check-mk
No piggyback files for 'check-mk'. Skip processing.
No piggyback files for '10.201.25.252'. Skip processing.
[cpu_tracking] Stop [7f5940ac2760 - Snapshot(process=posix.times_result(user=0.010000000000000009, system=0.010000000000000009, children_user=0.0, children_system=0.0, elapsed=0.020000003278255463))]
execution time 0.0 sec | execution_time=0.020 user_time=0.010 system_time=0.010 children_user_time=0.000 children_system_time=0.000 cmk_time_agent=0.000

Hi,

i try to understand the apache configuration from checkmk.
Can you help me to sort this out ?
And it’s the first time i have to deal with a reverse proxy.
There seem to be two apache installations.
The one is from suse and the other is from checkmk.
Let’s call the one from suse “system” and the one from checkmk “site”.
The system apache opens port 80 and listens on it.
The site apache opens 127.0.0.1:5000 and listens on it.
If i understand the comments in the conf files correctly the system apache is a reverse proxy. Right ?
But why don’t i find there any “proxy” directive in the conf files under /etc/apache ? The reverse proxy should accept packets on 0.0.0.0:80 and forward them to 127.0.0.1. Correct ?
I find proxy directives in the conf from the site apache, but i don’t expect them there.
The site apache is not the proxy, it’s the one who delivers the content. Correct ?
But how does the packets come from 0.0.0.0:80 to 127.0.0.1:5000 ?

Bernd

2

Hello Bernd,

the system-apache acts as a reverse proxy and passes the site-specific requests to the site-apache. You can use the system-apache also for other stuff, it will only proxy the requests for the /<SITENAME>-paths to the site-apache. The system-apache listens on port 80 and the site-apache listens on port 5000 (by default).
For how the system-apache proxies the requests there is somewhat of a “config-file-chain”.
Inside the config-directory for your system-apache there should be a file called zzz_omd.conf, at least that’s what its called on Debian-based systems. This file just tells the system-apache to include all config files in the directory /omd/apache/. There you will find a config file for every site you have on that server. These files in turn link to the config-files inside your sites, for exaple /omd/sites/SITE/etc/apache/mode.conf. In that file the config file /omd/sites/SITE/etc/apache/proxy-port.conf is included and there you will finally find the proxy-directives for your site.
The last file is also automatically created and updated when you for example change the site-apache-port from 5000 to anything else. That is how the system-apache then knows where to reach your site.
Hope that helps!

Cheers,
Lorenz

5 Likes
3

Hi Lorenz,

i get now. The “config-file-chain” was a bit difficult to find out.
Thanks for your help.

Bernd

4

Hi Lorenz,
one more question:
what is the sense/benefit of a reverse proxy ?

Bernd

5

Hello Bernd,

there are many reasons why yould would use a reverse proxy and how it is used in OMD/checkmk is only one use case. I think one of the main reasons for this construct is that you have the ability to run multiple sites on one server and have a single “entry point” with the system apache. You can reach all your sites on that server via the default http/https-port and access the sites via the corresponding url-path. You can disable or shut down one site and you can still access the other site(s) the way you’re used to. Also you don’t have to open multiple ports on your machine to the outside for every site (5000 for the first site, 5001 for the second and so on). So it’s a simplification from a usability standpoint, even if when trying to understand the configuration it seems confusing at first.
There are other reasons i can think of, compartmentalization of the configuration and processes inside the site, or abstracting away the configuration-differences between distros, for example, but i think the system-apache always being the “entry-point” to your system is one of the main reasons.
I could but wrong of course, maybe if one of the developers reads this they can shed a little more light on this topic.

Cheers,
Lorenz

6

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.