[terabithia rpm] conn reported red for all hosts
The problem turned out to be SELinux not allowing fping to write its output: type=AVC msg=audit(1581054673.192:3358): avc:? denied? { write } for? pid=14767 comm="fping" path="/var/lib/xymon/tmp/ping-stderr.14764.00" dev="dm-9" ino=288964 scontext=system_u:system_r:ping_t:s0 tcontext=system_u:object_r:init_tmp_t:s0 tclass=file permissive=1 The rule was set as dontaudit, and I had to rebuild the policy ignoring dontaudit flags to see the denials. Before I create a local rule using audit2allow, does anyone know if it's a known issue with a fix available (from terabithia or xymon)? Thanks! --Marcin
On 1/19/2020 7:10 PM, Marcin Struzak wrote:
I installed xymon-4.3.28-1.fc20.x86_64 from terabithia.org, and all the hosts fail the conn test, e.g.,
Sun Jan 19 18:56:35 2020 conn NOT ok
Service conn on shark is not OK : Host does not respond to ping
Running "/usr/libexec/xymon/xymonnet --ping --no-update --debug <host>" from command line revealed an issue with folders:
<date & timestamp> Cannot create file /usr/share/xymon/tmp/ping-stdout.2138.00 : No such file or directory <date & timestamp> Cannot create file /usr/share/xymon/tmp/ping-stderr.2138.00 : No such file or directory <date & timestamp> xymonping child could not create outputfiles in /usr/share/xymon/tmp <date & timestamp> Cannot open ping output file /usr/share/xymon/tmp/ping-stdout.2138.00
status+30 shark.conn clear <!-- [flags:OrdAstLe] --> Sun Jan 19 18:38:55 2020 conn ok : System failure of the ping test
Service conn on shark is OK Xymon system error
&green
I created a symbolic link from /usr/share/xymon to /var/lib/xymon/tmp/, and now the command line succeeds:
status+30 shark.conn green <!-- [flags:OrdAstLe] --> Sun Jan 19 19:01:57 2020 conn ok
Service conn on shark is OK (up)
&green 10.10.10.1 is alive (0.07 ms)
but the Current Status (Main view) reports conn red.
Any help you can provide to debug this further will be appreciated!
--Marcin
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
On Mon, 2020-02-10 at 21:09 -0800, Marcin Struzak wrote:
The problem turned out to be SELinux not allowing fping to write its output: type=AVC msg=audit(1581054673.192:3358): avc: denied { write } for pid=14767 comm="fping" path="/var/lib/xymon/tmp/ping-stderr.14764.00" dev="dm-9" ino=288964 scontext=system_u:system_r:ping_t:s0 tcontext=system_u:object_r:init_tmp_t:s0 tclass=file permissive=1 The rule was set as dontaudit, and I had to rebuild the policy ignoring dontaudit flags to see the denials. Before I create a local rule using audit2allow, does anyone know if it's a known issue with a fix available (from terabithia or xymon)? Thanks! --Marcin
Hi,
As far as I can see in Xymon 4.3.30 selinux is already modified by the Xymon RPM to cater for this:
=====
rpm -qf /usr/share/doc/xymon-4.3.30/xymon.te
xymon-4.3.30-1.el7.x86_64
Looking at the file shows:
===== #============= ping_t ============== allow ping_t { tmp_t initrc_tmp_t var_lib_t }:file { getattr write };
Running 4.3.30 on CentOS 7 we have had to make no changes to selinux.
John.
-- John Horne | Senior Operations Analyst | Technology and Information Services University of Plymouth | Drake Circus | Plymouth | Devon | PL4 8AA | UK
[http://www.plymouth.ac.uk/images/email_footer.gif]<http://www.plymouth.ac.uk/worldclass>
This email and any files with it are confidential and intended solely for the use of the recipient to whom it is addressed. If you are not the intended recipient then copying, distribution or other use of the information contained is strictly prohibited and you should not rely on it. If you have received this email in error please let the sender know immediately and delete it from your system(s). Internet emails are not necessarily secure. While we take every care, University of Plymouth accepts no responsibility for viruses and it is your responsibility to scan emails and their attachments. University of Plymouth does not accept responsibility for any changes made after it was sent. Nothing in this email or its attachments constitutes an order for goods or services unless accompanied by an official order form.
participants (2)
-
john.horne＠plymouth.ac.uk
-
kunci＠struzak.com