November 2015 - Xymon - Xymon mailman web

Need help with upgrade from 4.3.17 to 4.3.20
by cleaver＠terabithia.org 17 Jul '18

17 Jul '18

Hmm. So far, the only way I've been able to reproduce this is by replacing the ScriptAlias directives with mere Alias's in the xymon.conf apache config. Has there been any change in the path you've used for the CGI directory since the previous version, or is there any chance that another Alias line is taking precedence over the ScriptAlias? Do you see anything in the apache access/error logs that indicates an error? -jc On Tue, May 19, 2015 10:37 am, Cortes, Manny wrote: > Having the same problem after installing 4.3.20 on both Ubuntu server > 14.04 and 15.04. > > Thanks, > > > Manuel A Cortes > > Systems Programmer III > > [IBM_Cert] > > IBM Certified System Administrator AIX 7 > > Information Services > > 321-841-6534 > > Orlandohealth.com > > Facebook.com/orlandohealth > > Youtube.com/orlandohealth > > @orlandohealth on twitter > > > > 1414 Kuhl Avenue.,MP136 > > Orlando, Florida 32806 > > From: Xymon [mailto:xymon-bounces at xymon.com] On Behalf Of Asif Iqbal > Sent: Tuesday, May 19, 2015 12:59 PM > To: J.C. Cleaver > Cc: xymon at xymon.com > Subject: Re: [Xymon] Need help with upgrade from 4.3.17 to 4.3.20 > > > > On Tue, May 19, 2015 at 12:40 PM, J.C. Cleaver > <cleaver at terabithia.org<mailto:cleaver at terabithia.org>> wrote: > Hmm. It seems like it's trying to pass along the binary rather than > actually execute it. Can you > > a) validate the permissions on the various .sh files inside the > /xymon-cgi/ directory. (Wondering if there's a case where make install > doesn't set permissions properly), and > > > /var/lib/xymon/cgi-bin$ ls -al > total 6560 > drwxr-xr-x 2 root root 4096 May 19 10:19 . > drwxr-xr-x 16 xymon xymon 4096 May 19 10:19 .. > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 acknowledgements.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 appfeed-critical.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 appfeed.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 certreport.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 columndoc.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 confreport-critical.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 confreport.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 criticalview.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 csvinfo.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 datepage.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 eventlog.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 findhost.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 ghostlist.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 historylog.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 history.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 hostgraphs.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 hostlist.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 nongreen.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 notifications.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 perfdata.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 reportlog.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 report.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 showgraph.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 snapshot.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 svcstatus.sh > -rwxr-xr-x 32 xymon xymon 255968 May 19 10:19 topchanges.sh > > > b) verify that the ScriptAlias or ExecCGI options are still present in > apache.conf. > > > grep xymon-cgi /etc/apache2/sites-enabled/xymon-apache.conf > # "/xymon" and "/xymon-cgi" URLs. > ScriptAlias /xymon-cgi/ "/var/lib/xymon/cgi-bin/" > RewriteRule ^/xymon-cgi/bb-hist.sh /xymon-cgi/history.sh [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-eventlog.sh /xymon-cgi/eventlog.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-rep.sh /xymon-cgi/report.sh [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-replog.sh /xymon-cgi/reportlog.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-snapshot.sh /xymon-cgi/snapshot.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-findhost.sh /xymon-cgi/findhost.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-csvinfo.sh /xymon-cgi/csvinfo.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbitcolumn.sh /xymon-cgi/columndoc.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-datepage.sh /xymon-cgi/datepage.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbitgraph.sh /xymon-cgi/showgraph.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-hostsvc.sh /xymon-cgi/svcstatus.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/bb-histlog.sh /xymon-cgi/historylog.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-confreport.sh /xymon-cgi/confreport.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-confreport-critical.sh > /xymon-cgi/confreport-critical.sh [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-nkview.sh /xymon-cgi/criticalview.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-certreport.sh /xymon-cgi/certreport.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-nongreen.sh /xymon-cgi/nongreen.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-hostgraphs.sh /xymon-cgi/hostgraphs.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-ghosts.sh /xymon-cgi/ghostlist.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-notifylog.sh /xymon-cgi/notifications.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-hostlist.sh /xymon-cgi/hostlist.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-perfdata.sh /xymon-cgi/perfdata.sh > [R=permanent,L] > RewriteRule ^/xymon-cgi/hobbit-topchanges.sh /xymon-cgi/topchanges.sh > [R=permanent,L] > > > HTH, > > -jc > > > On Tue, May 19, 2015 7:56 am, Asif Iqbal wrote: >> I am not sure what I need to after the upgrade for the columns to show >> data >> instead of >> something like this >> >> >> ELF ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½>ï¿½ ï¿½ï¿½ï¿½ >> @ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ Ã >> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½8ï¿½ ï¿½@ï¿½%ï¿½"ï¿½ ï¿½ï¿½ï¿½ >> ï¿½ï¿½ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½Ã¸ >> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ã¸ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ >> ï¿½ï¿½ï¿½8 ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½8 >> @ï¿½ï¿½ï¿½ï¿½ï¿½8 @ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ >> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ ï¿½ï¿½ï¿½ >> ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½Ã¤Ã¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½Ã¤Ã¤ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ >> >> I removed FollowSymLinks from xymon-apache.conf file under /xymon-cgi/ >> and /xymon-seccgi/ and restarted. >> >> I am using ubuntu >> >> -- >> Asif Iqbal >> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu<http://pgp.mit.edu> >> A: Because it messes up the order in which people normally read text. >> Q: Why is top-posting such a bad thing? >> _______________________________________________ >> Xymon mailing list >> Xymon at xymon.com<mailto:Xymon at xymon.com> >> http://lists.xymon.com/mailman/listinfo/xymon >> > > > > > -- > Asif Iqbal > PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu<http://pgp.mit.edu> > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > > ________________________________ > > This e-mail message and any attached files are confidential and are > intended solely for the use of the addressee(s) named above. If you are > not the intended recipient, any review, use, or distribution of this > e-mail message and any attached files is strictly prohibited. > > This communication may contain material protected by Federal privacy > regulations, attorney-client work product, or other privileges. If you > have received this confidential communication in error, please notify the > sender immediately by reply e-mail message and permanently delete the > original message. To reply to our email administrator directly, send an > email to: postmaster at orlandohealth.com . > > If this e-mail message concerns a contract matter, be advised that no > employee or agent is authorized to conclude any binding agreement on > behalf of Orlando Health by e-mail without express written confirmation by > an officer of the corporation. Any views or opinions presented in this > e-mail are solely those of the author and do not necessarily represent > those of Orlando Health. >

8 25

Recovery notifications not generated when test goes red->yellow->green?
by hobbit＠elyograg.org 13 Dec '17

13 Dec '17

It appears that if a test goes from the red state, to the yellow state, and then to the green state, no recovery notification is sent. If it goes directly from red to green, then we get a notification. Initial notifications are only sent on RED and PURPLE. We have recovery notifications configured for most tests. Xymon server is 4.3.21, built using makerpm.sh and installed with yum on CentOS 6. I do not know whether our previous version (4.3.14) behaved similarly. It was almost an accident that I discovered the problem at all. Is this expected behavior? If it is, can I change it? Thanks, Shawn

4 3

DNS failures causing "runtime longer than time limit"
by jlaidman＠rebel-it.com.au 11 Sep '17

11 Sep '17

Hi I'm running Xymon v4.3.10 on Linux, and I'm quite sure it's compiled with c-ares support. I have 12 new DNS servers that were added to Xymon about one month ago. All of my server entries in hosts.cfg have "testip". The tasks.cfg runs xymonet with "--dns-timeout=3". The hosts entries look like so: 10.10.10.1 dnshost1.example.com # testip dns=NS:example.com,SOA: example.com About a week ago, connectivity to all of these servers failed, and at the same time, the xymonnet run time jumped from less than 15 seconds to about 330 seconds, so about 315 seconds extra. The xymonnet page says 295 seconds is taken up by DNS tests. If the increase in time taken is about 315 and is entirely due to the 12 servers failing, then each failed server is adding about 26 seconds to the total run time. I don't think this should be happening like this. With two DNS checks per server, the DNS checks should be taking 6 seconds each to time-out, not 26. If I run xymonnet with "--timing --no-update" and specify only one hostname, I can view the results and the timing. This shows that the ping check gets reported after about 3 seconds, and then the DNS tests are executed and take 26 seconds total. My naiive assumption was that when a server failed a ping (and didn't have "noclear" defined in hosts.cfg) then the network checks would be skipped. On re-reading the man page for hosts.cfg, it dawned on me that a failed ping simply suppresses failed test /results/, but doesn't stop the tests from being run. So the real problem is that the "--dns-timeout=3" is not being taken into consideration by xymonnet. If I run xymonnet with "--debug" it tells me: 1900 2015-06-03 12:02:20 ares_search: tlookup='example.com', class=1, type=2 1900 2015-06-03 12:02:20 ares_search: tlookup='example.com', class=1, type=6 1900 2015-06-03 12:02:20 Processing 0 DNS lookups with ARES 1900 2015-06-03 12:02:46 Finished ARES queue after loop 423 This is peculiar. Why would it say "processing 0 DNS lookups" when there are two lookups to test? Could this be because xymonnet hasn't actually been built with ARES support and I didn't know it? Is there a good way to tell? If I add "--no-ares" I get the same results perhaps suggesting a lack of ARES support. On the other hand, if I add "timeout:3" and "attempts:1" into resolv.conf, I also get the same results. If I run "nm /path/to/xymonnet | grep gethostby" it returns "ares_gethostbyname". Just for fun, I compiled Xymon v4.3.21 and ran the xymonnet binary from there, with no change in behaviour. I also tried removing the "--dns-timeout" option so that it defaults to 30 seconds, but still no change - 26 seconds for two DNS tests. So, I'm not really sure what the problem is, but xymonnet certainly isn't behaving as I would expect. Cheers Jeremy

2 3

EXTIME still valid ?
by rltexas1＠gmail.com 22 Jun '16

22 Jun '16

Is the EXTIME option still valid in the alerts.cfg I am having problems testing the following EXTIME=1:1140:1240 Should be exclude Monday's 11:40 to 12:40. Will test EXTIME=M:1140:1240 But if it's M for Monday what would Sunday be ? Thanks

4 4

MAGMA XYMon Web GUI Admin Now Available!
by sanderson＠CORNETSER.com 07 Jan '16

07 Jan '16

Henrik and Fellow Xymoners, Just for you I have pushed off any real work for today just to get you all a first release of MAGMA the XYMon Web GUI Admin. MAGMA is an add-on web GUI for managing Host, Groups and Alarms on a XYmon 4.3 or newer system. You can find MAGMA at http://www.squidworks.net/magma/ There you will find the description, screen shots and features of MAGMA along with the link to download the source package. It requires MySQL and PHP5 and is very simple to install. All supporting information is included in the tarball. How does it work? --------------------------- It stores all alarm and host/group configs in the SQL database and rewrites the Host.cfg, Analysis.cfg and Alarms.cfg files causing the XYmon system to update its tests and pages based on the changes in these files. It will overwrite the files each time a host is added or edited making the process of updating automatic. To get the full benefit of MAGMA you should place all hosts in "central" mode, although this is not required, without it your management is somewhat restrictive (external test management only). In Central mode you get full management features for all tests. If you have any questions or need some help just send me a email @ sanderson @ squidworks.net Cubert 8-) Aka Shannon Anderson

6 5

Xymon and Oracle ASM?
by betsy.schwartz＠gmail.com 30 Dec '15

30 Dec '15

Anyone got any good scripts for xymon and Oracle ASM?

5 4

Xymon swarm proposal
by henrik＠hswn.dk 30 Nov '15

30 Nov '15

Hi, the recent talk on xymon-developer about rewriting xymonproxy to support TLS, IPv6 and other good stuff made me think about other ways of scaling Xymon across large installations. Which led me to the idea of having multiple independent Xymon servers - a swarm, because no one Xymon server depends on the others, but they can cooperate. Simply put, you have a number of independent Xymon installations. Each of them handles a group of servers - it could be one in each of your datacentres, one for each organisational unit, one in each network segment, or just a because you have such a large installation that a single Xymon server cannot cope with the load (and that would be a really big installation, judging by the numbers I hear). This all works just like the Xymon you have today. The only thing that is needed to have all of these independent Xymon servers show up as a single (virtual) Xymon installation is to have the Xymon webpages - generated by xymongen - to display a set of webpages showing the status of all of the Xymon servers in the swarm. When you click on the detailed status log, you are transparently sent to the Xymon server that holds the data about that server (the URL points to the Xymon server handling the particular server you want to check on). The nice thing about this is that I think it can be implemented fairly easily, i.e. without having to change anything fundamental in the way the various Xymon programs work. Which means it will also be easy to adapt into an existing Xymon installation, and with a good chance of not introducing difficult-to-troubleshoot bugs (difficult because bugs involving remote systems are always a headache to reproduce). There are of course a few nitty-gritty details, e.g. "Find host" really should be able to search across all of the servers in the swarm. But those cases are rather few and fairly isolated to not be too much of a headache. Multiple independent Xymon servers * Each site runs just like today. * A new sites.cfg file lists the other sites (just a site ID and how to contact xymond there) * Each site UI (the static webpages from xymongen) merges data from all sites Advantages * More resilient - if one site dies, the others will remain operational * Less cross-site traffic (local data remain local except when needed) * Less load on each site (updates only go to one Xymon server) * Horizontally scalable Limitations * Hostnames must be unique globally. Probably not a significant problem. * Functions that fetch data directly from disk-files cannot be cross-site (rrd-files, history-logs), unless you can retrieve the data via a network request. In a standard Xymon installation that would be: o Availability reports o Event log reports (but see below) o Multi-host graphs, unless all of the hosts are local * Alerts are always handled locally xymongen * hosts.cfg file for the page layout must be merged from all sites. Can be a simple append-one-after-the-other (built-in) or perhaps allow foran externally generated hosts.cfg - if you want to have servers from multiple locations on one page. * How do we handle non-unique pagenames? Transparently prefix them with the remote site-ID? * xymondboard data is fetched from multiple sites and combined (appended) - handled in sendmessage() * cgi-URL's are generated with a prefix of /SITE/ - no change otherwise. The local webserver then proxies /SITE/ requests to the remote site. * Should there be both a local and a global "all non-green" page? Maybe even a full set of local and global webpages? That would be easy by running xymongen twice - one for the local and one for the global set of pages. sendmessage() function * No changes for sending status- or data-updates (status, combo, extcombo, client, data, modify) * Option to fetch data from multiple sites. This is already in place for sending to multiple Xymon servers, so we just need to combine the output response from multiple sites. * When processing host-related requests, we learn where the host is located. Cache this for use by various tools. Must be disk-based (e.g. SQLite file) so it can be shared. xymond * hostinfo requests should only answer for the local hosts. No need to consult the SQLite cache - no changes. CGI programs * "Find host" must be cross-site * Ack-alert: Suggest making it local-only. Since alerts are only generated locally, it makes sense to also only ack the local alerts. * Enable/disable only on the local site? Use the "info" page enable/disable (automatically local). Global enable/disable needs some more looking into. * Critical systems - would probably be nice to be able to do both a local and a global version. * Eventlog - would be nice to have both local and global, even though that means fetching a (large) remote logfile. Will probably require a new "eventlog" CGI interface for retrieving a remote logfile. It is probably not something we want to do on every critical-systems/all-nongreen webpage update. So those could keep the local eventlog display (as-is), and then the eventlog CGI could have the option of combining logs from all sites (or maybe a selection of sites). xymon commands _Commands re. specific hosts_ First check via hostinfo cache (see below) if we know where the host is (performance optimization). If not then simply broadcast the message to all sites and combining any data that is returned - there will only be data from one server. * notify * disable * enable * query * xymondlog, xymondxlog, clientlog * hostinfo - sendmessage() will fetch the data for us, whether from the local xymond or from the SQLite cache. _Commands that collect data on multiple hosts_ * xymondboard, xymondxboard - option from user whether to fetch local or global info. Handled in sendmessage() _Command that only work locally_ * ghostlist * drop * rename * schedule. If done via web i/f it becomes automatically transparent, but not for scripts. Probably only used for disable/enable/drop/rename so makes most sense to do it locally. Doing global would have to parse the message to detect which host it is about. Comments are very welcome. Regards, Henrik

5 4

rclient on new xymon install via rpms
by sys1002＠yahoo.com 30 Nov '15

30 Nov '15

I am trying to set up monitoring for about 2,000 servers, and unfortunately, it is going to take a while to get a port open, so I want to use rclient via ssh.Normally I would su into the xymon user, create the ssh keys and push them out. On this new server via terabith rpms ( RHEL 6.6 ), I get # su - xymon This account is currently not available. What is a workaround for this so that I can use rclient ? Thanks !

3 3

error installing rpm xymon-client-4.3.24-1.el6.x86_64
by cleaver＠terabithia.org 29 Nov '15

29 Nov '15

On Sun, November 29, 2015 6:03 am, Michael Resnick wrote: > This is on a server with no Internet access, so I copied the 3 rpms as > shown below. > relevant portion seems to beÂ > Error in PREIN scriptlet in rpm package xymon-client-4.3.24-1.el6.x86_64 > xymon logfetch requires group 'adm' to be present first > error: %pre(xymon-client-4.3.24-1.el6.x86_64) scriptlet failed, exit > status 1 > error:Â Â install: %pre scriptlet failed (2), skipping > xymon-client-4.3.24-1.el6 > > Any help appreciated. Hi, When creating the 'xymon' user, the RPM adds it to the 'adm' group (traditionally used for administrative log scanning). If the standard 'adm' group has been removed from the system it'll fail, so it's scanned for in %pre. To remove this check, rebuild the SRPM with the "--without logreader" option: rpmbuild -ba --without logreader xymon-4.3.24-1.el6.src.rpm. You can also adjust the 'logReaderGroup' value to something appropriate for your system. If it's just a one-off or test, you can also add the group, do the install, then remove it as well. HTH, -jc

1 0

error installing rpm xymon-client-4.3.24-1.el6.x86_64
by sys1002＠yahoo.com 29 Nov '15

29 Nov '15

This is on a server with no Internet access, so I copied the 3 rpms as shown below. relevant portion seems to be Error in PREIN scriptlet in rpm package xymon-client-4.3.24-1.el6.x86_64 xymon logfetch requires group 'adm' to be present first error: %pre(xymon-client-4.3.24-1.el6.x86_64) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping xymon-client-4.3.24-1.el6 Any help appreciated. Full session : # yum localinstall --nogpgcheck lz4-r131-1.el6.x86_64.rpm xymon-client-4.3.24-1.el6.x86_64.rpm zlib-1.2.3-29.el6.x86_64.rpm Loaded plugins: product-id, security, subscription-manager Updating certificate-based repositories. Setting up Local Package Process Examining lz4-r131-1.el6.x86_64.rpm: lz4-r131-1.el6.x86_64 Marking lz4-r131-1.el6.x86_64.rpm to be installed Examining xymon-client-4.3.24-1.el6.x86_64.rpm: xymon-client-4.3.24-1.el6.x86_64 Marking xymon-client-4.3.24-1.el6.x86_64.rpm to be installed Examining zlib-1.2.3-29.el6.x86_64.rpm: zlib-1.2.3-29.el6.x86_64 Marking zlib-1.2.3-29.el6.x86_64.rpm as an update to zlib-1.2.3-27.el6.x86_64 Resolving Dependencies --> Running transaction check ---> Package lz4.x86_64 0:r131-1.el6 will be installed ---> Package xymon-client.x86_64 0:4.3.24-1.el6 will be installed ---> Package zlib.x86_64 0:1.2.3-27.el6 will be updated ---> Package zlib.x86_64 0:1.2.3-29.el6 will be an update --> Finished Dependency Resolution Dependencies Resolved ===================================================================================================================== Package Arch Version Repository Size ===================================================================================================================== Installing: lz4 x86_64 r131-1.el6 /lz4-r131-1.el6.x86_64 213 k xymon-client x86_64 4.3.24-1.el6 /xymon-client-4.3.24-1.el6.x86_64 1.1 M Updating: zlib x86_64 1.2.3-29.el6 /zlib-1.2.3-29.el6.x86_64 149 k Transaction Summary ===================================================================================================================== Install 2 Package(s) Upgrade 1 Package(s) Total size: 1.5 M Is this ok [y/N]: y Downloading Packages: Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Warning: RPMDB altered outside of yum. ** Found 3 pre-existing rpmdb problem(s), 'yum check' output follows: glibc-2.12-1.47.el6.i686 has missing requires of libfreebl3.so glibc-2.12-1.47.el6.i686 has missing requires of libfreebl3.so(NSSRAWHASH_3.12.3) readline-devel-6.0-3.el6.x86_64 has missing requires of ncurses-devel Updating : zlib-1.2.3-29.el6.x86_64 1/4 Installing : lz4-r131-1.el6.x86_64 2/4 Error in PREIN scriptlet in rpm package xymon-client-4.3.24-1.el6.x86_64 xymon logfetch requires group 'adm' to be present first error: %pre(xymon-client-4.3.24-1.el6.x86_64) scriptlet failed, exit status 1 error: install: %pre scriptlet failed (2), skipping xymon-client-4.3.24-1.el6 Cleanup : zlib-1.2.3-27.el6.x86_64 4/4 Installed products updated. Installed: lz4.x86_64 0:r131-1.el6 Updated: zlib.x86_64 0:1.2.3-29.el6 Failed: xymon-client.x86_64 0:4.3.24-1.el6 rpms taken from : http://terabithia.org/rpms/xymon/

1 0