ID: 4921
Title: Users can be limited to a list of authorized sites now
Component: Multisite
Level: 2
Class: New feature
Version: 1.5.0i1
It is now possible to configure a list of authorized sites for each user.
This is especially useful when having a huge number of sites configured,
like several hundred, in a distributed setup. In case you have users that
have their hosts on only some of these sites, you can set the new authorized
sites option for these users.
For the users that have authorized sites configured the GUI will only contact
these sites instead of all sites to build up their views. In large environments
this will be a huge performance improvement.
ID: 4901
Title: Reworked Livestatus Proxy to be more scalable
Component: Livestatus Proxy
Level: 2
Class: New feature
Version: 1.5.0i1
The livestatus proxy daemon has been reworked to use a multi process
architecture. It now has a master process that mainly cares about
monitoring the site processes. Each connected site has an own subprocess
that manages all channels to this site and the clients that use these
channels to communicate with the sites.
When you have a look at ps/top you should see something like this:
C+:
OMD[heute]:~$ ps -ef | grep liveproxyd
UID PID PPID C STIME TTY TIME CMD
heute 9261 1 0 11:40 ? 00:00:00 liveproxyd[master]
heute 9262 9261 0 11:40 ? 00:00:00 liveproxyd[heute_slave_1]
heute 9263 9261 0 11:40 ? 00:00:00 liveproxyd[heute_slave_2]
C-:
As you can may see there is the master process that has the process <tt>1</tt>
as parent process. The site processes have the master as parent.
When one site process terminates for some reason the master will restart it.
When the master is terminated all site processes will terminate too. In case
of a restart or config reload the master will restart itself and stop
all site processes and restart them again.
With this change the load of the livestatus proxy will now spread over
multiple CPUs.
Side note: There is a new global setting <i>Logging of the Livestatus Proxy</i>
that can be used to control the detail level of the log entries written to the
<tt>var/log/liveproxyd.log</tt> log file. In case you experience any issues
with the livestatus proxy daemon take a look at this log file and maybe increase
the log level to get more details.
ID: 4708
Title: Windows Agent/Agent Updater: Fixed race condition which removed the windows service
Component: Checks & agents
Level: 2
Class: Bug fix
Version: 1.5.0i1
The agent updater could kill itself during an update, because the MSI installation process
sent a shutdown signal to the windows service. This shutdown also killed any plugins,
including the agent updater... This has been fixed by detaching the cmk-update-agent.exe
file from the process group of the windows agent.
ID: 4761
Title: Fixed multisite setups with sites using Check_MK/Livestatus < 1.4
Component: Multisite
Level: 2
Class: Bug fix
Version: 1.5.0i1
When updating the central site of a distributed setup to Check_MK 1.4.* and
leaving the slave sites on older versions the other sites were marked as
dead sites while rendering the page.
This issue was caused by the tactical overview snapin that tried to calculate
the numbers for the "Events" of the Event Console. The slave sites using
older Check_MK versions do not support that kind of query. Once this query
is made the sites are marked as dead and are also not shown correctly in the
master control and site status snapin.
A possible workaround would be to update all involved sites to Check_MK
1.4.
Also affected are sites that use the Nagios core and have the Event Console
disabled. They still report an error to the GUI. This will be fixed soon.
ID: 4758
Title: Fixed site status and master control snapin not displaying states of sites
Component: Multisite
Level: 2
Class: Bug fix
Version: 1.5.0i1
The master control snapin was hiding sites with communication errors completely.
It is now displaying a box with the occured error message.
The site status snapin was showing the site, but displaying a site as "online"
while it was reported as "dead" by the livestatus connection. This appeared when
an error was found in a query, for example when a queried table does not exist.
ID: 4757
Title: Fixed possible reflected XSS in webapi.py
Component: Multisite
Level: 2
Class: Security fix
Version: 1.5.0i1
In the Check_MK 1.4 branch URLs like this could be used for a
reflected XSS attack:
<tt>http://<test host>/<site>/check_mk/webapi.py?_username=<script>alert("XSS")</script>&_secret=AnythingHere
The error message was interpreted as HTML while it should be a
plain text error message. This has been fixed now.
ID: 4858
Title: omd_apache data collection: fixed issues caused by missing newline at the end of statsfile(s)
Component: Checks & agents
Level: 2
Class: Bug fix
Version: 1.5.0i1
Sometimes the apache statsfile(s) can miss a newline at the end of the file. This caused the following known issues:
* missing agent section directly after omd_apache section - because the section header was starting in the same line as the omd_apache section's last line
* crashed omd_apache check because of missing data
ID: 4818
Title: Fixed "No Data" in Tactical Overview if missing permissions to see failed notifications
Component: Multisite
Level: 2
Class: Bug fix
Version: 1.5.0i1
Guest do not have permissions to see failed notifications per default which
lead into an empty tactical overview. This bug is in Check_MK since June 2016.
ID: 4780
Title: HW/SW inventory: Removed entries about section ages provided by check_mk_agent; this reverts Werk 3904
Component: HW/SW Inventory
Level: 2
Class: Bug fix
Version: 1.5.0i1
These HW/SW inventory entries filled up inventory archive and slowed
down the monitoring system. See also Werk 4485.
ID: 8656
Title: Button "All Logfiles" in logwatch user interface now works in distributed mode
Component: Multisite
Level: 2
Class: Bug fix
Version: 1.5.0i1
The problem was that this button would only show the log files that are on
the same monitoring site as the currently shown log file or host. This problem
only appeared in a distributed environment.