On Tue, 24 Jul 2018, Martha McConaghy wrote:
> We use Xymon a great deal, it monitors all of our servers and network
> equipment (several thousand items). We run the server on zLinux (SLES) and
> the client runs just about anywhere. There are even clients for z/VM and z/OS
> (thanks Rich!).
It looks as though a non 'package system mediated' build and
setup process is described at:
http://xymon.sourceforge.net/xymon/help/install.html#commonsystems
It appears to do an 'interview' as part of the configuration
process, both as to the build path decisions, and the
hostname and network ports to be listened to, rather than
relying on abstraction and later configuration
Also a bunch of hard linking rather than relative symlinking
in that package's manual setup, which is usually very poor
form, as it locks in potentially vulnerable library decisions
(I see some compression / decompression libraries which have
had CVE type vulnerabilities in them, so this matters -- a
stale 'carried in the tarball' lzo [YIKES], a stale 'carried
in the tarball' l4 [YIKES], zlib, more with unpackaged perl
modules [YIKES])
The _problem_ with this approach is that one can unknowingly
carry around exploitable libraries rather than have the
benefit one's upsteam's maintenance, when a perl module or a
library shows up in the security issues lists. The crackers
read these lists and more daily these just as I do [Credit
card data security matters --- EDS is a big player in this
market as well and I was ** shocked ** at the lack of
awareness of such issues when I was dealing with them; the old
Sterling Software had holes which I found as well, in the pre
IBM days]. Anyway, the crackers can use stale and vulnerable
matter as a way to prise open an entry to a remote system. I
'cc' the 'whitehat' exploit scanner developers 'soldier of
fortran' and 'bigendiansmalls' so they can add coverage to
their penetration testing tool kit
Also there is not at the SF reference site a set of
instructions for systemd so some 'cribbing' from the work of
others may be needed there. Why is it not in RawHide /
Fedoraproject already, I wonder ... a license problem (the old
BB had that issue when it was taken non-FOSS
> On 7/24/2018 8:43 AM, Frank M. Ramaekers wrote:
> > Anyone doing xymon on zLinux? Know where a RPM for ClefOS might be found?
Long ago and far away I ran the old Big Brother, which being
based on lots of early perl scripts, was somewhat loady. I
was unaware of this package, as I run the FOSS Nagios, which
plays well with SNMP, and had not needed to look further
Let me look at license matters and if I can solve it for an
acceptable packaging it for ClefOS. All the build
Requirements are present in ClefOS, and I have a build solved
already which I have rebuild under s390x
/home/herrold/rpmbuild/SRPMS/xymon-4.3.28-1.orc7.src.rpm
Wrote:
/home/herrold/rpmbuild/RPMS/s390x/xymon-4.3.28-1.el7.s390x.rpm
Wrote:
/home/herrold/rpmbuild/RPMS/s390x/xymon-client-4.3.28-1.el7.s390x.rpm
Wrote:
/home/herrold/rpmbuild/RPMS/s390x/xymon-client-local-4.3.28-1.el7.s390x.rpm
Wrote:
/home/herrold/rpmbuild/RPMS/s390x/xymon-devel-4.3.28-1.el7.s390x.rpm
Wrote:
/home/herrold/rpmbuild/RPMS/s390x/xymon-tools-4.3.28-1.el7.s390x.rpm
Wrote:
/home/herrold/rpmbuild/RPMS/s390x/xymon-debuginfo-4.3.28-1.el7.s390x.rpm
Although I do NOT like some of its choices from a system
security POV. a copy of my WIP SRPM is up at:
ftp://ftp.owlriver.com/pub/local/ORC/xymon/
but I will have a better and safer and more maintainable one
later
-- Russ herrold
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
