Linux and Nagios

Yum show the contents of a package

posted 8 Jan 2018, 01:53 by Tristan Self   [ updated 8 Jan 2018, 01:57 ]

Let's say you've identified a dependency that is needed on your machine, but you don't know what package will provide the required file, you can use the "yum search <name> | grep <more granular name>" to narrow it down, but to see inside the package before install you can run the below, in my example I was looking for what provided the "" file, the package "perl-gettext" looked like it might, to be sure I ran:

# repoquery -l perl-gettext

And as you can see its listed, so this is the right package to install.

Install HP LaserJet 1020 USB Driver on Centos 7

posted 9 Dec 2017, 12:58 by Tristan Self

yum install hplip-gui



Follow the wizard through and setup the USB printer.

"Unknown Display" on Centos 7 (Desktop)

posted 2 Dec 2017, 02:13 by Tristan Self   [ updated 2 Dec 2017, 02:32 ]

In a continued bid to build a desktop Linux machine, I was working on getting the three monitors working. One of the monitors uses the onboard graphics, the other two are plugged into a PCI-E riser card. The issue was that the monitor type is not detected by the onboard graphics, so reports the incorrect resolution back. Changing this was proving very difficult. I'm using GNOME on Centos 7 desktop.

To fix I did the following to get the correct modeline I needed:

cvt 1440 900 60

Modeline "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync

All my monitors will be running at 1440x900_60.00.

Now I ran an: xrandr to get the list of all the monitor/adapter names. In my case these were VGA-1-1 (the unknown display, on the motherboard graphics), VGA-2 and DVI-I-1 (the latter two were on the riser PCI-E card).

Finally I created a file called: /etc/X11/xorg.conf.d/10-monitor.conf and adding the following contents:
 Section "Monitor"
    Identifier "VGA-1-1"
    Modeline "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync
    Option "PreferredMode" "1440x900_60.00"
Section "Monitor"
    Identifier "VGA-2"
    Modeline "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync
    Option "PreferredMode" "1440x900_60.00"
Section "Monitor"
    Identifier "DVI-I-1"
    Modeline "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync
    Option "PreferredMode" "1440x900_60.00"

Once this was done I rebooted, but the third monitor was not using the correct resolution.

Using "Settings"->"Display" I set the problem third monitor (VGA-1-1) to 1440x900 which was now an available option and ensured the monitors were in the correct positions.

One more reboot and all was then in order.

"Unknown Display" on Ubuntu

posted 29 Nov 2017, 12:14 by Tristan Self   [ updated 2 Dec 2017, 01:33 ]

Whilst building a new home machine I came across this issue where the third screen in my three screen setup was only seen as an "Unknown Display". My machine has an on-board graphics card and a 2 port PCI-E riser graphics card, the monitors connected to the 2 port riser were working correctly, and the OS saw them as the LG Monitors, the third was showing as "Unknown Display". The problem this caused was that the screen's resolution should be 1440x900@60Hz, but the unknown display was only giving me the option of 1024x768@60 or lower.

So to fix I used xrandr to set the monitor to a resolution I know it supported as follows:

First run cvt to generate a mode, where the 1440 is the Width, 900 the Height and 60 the frequency.
# cvt 1440 900 60

This returned the following:
# 1440x900 59.89 Hz (CVT 1.30MA) hsync: 55.93 kHz; pclk: 106.50 MHz
Modeline "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync

The modeline is what we want, so copy this line and create the following line and hit enter to create a new mode based on these settings:

# xrandr --newmode "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync

Now it is all set you just need to run randr to find out the name of the graphics output you are looking to set to this new mode.

# xrandr
... output omitted.....
VGA-1-1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768      60.00*
   800x600       60.32    56.25 
   848x480       60.00 
   640x480       59.94 
....output omitted....

In my case it was VGA-1-1, so now I have this information I can apply the new mode to the monitor as follows:

# xrandr --addmode VGA-1-1 1440x900_60.00

Now if you go into the "Settings" and "Display" and click on the unknown monitor you'll notice a new resolution available from the drop down. Select it and click on "Apply" and hey presto, your monitor should now be showing the correct resolution.

The only issue is that the next time you reboot, the changes will be gone. To resolve this create a file called .xprofile in your home directory and add the following contents all on a single line:
xrandr --newmode "1440x900_60.00"  106.50  1440 1528 1672 1904  900 903 909 934 -hsync +vsync && xrandr --addmode VGA-1-1 1440x900_60.00

Then finally make it executable with:

# chmod +x .xprofile

SSH Reverse Tunnel

posted 21 Oct 2017, 13:12 by Tristan Self

If you need to SSH to a host but don't have direct SSH access, you can perform a reverse SSH tunnel. For this you need a host that will except inbound connections to work as a "jump host", it is possible without it, where you could SSH back to your client computer; however for the purposes of this example the setup is as follows:

1. TARGETSRV - Target host you want to connect to, you will start the SSH reverse tunnel from here.
2. JUMPHOST - The host you'll be connecting the reverse tunnel to from the TARGETSRV.
3. CLIENT - Your client computer that you'll be SSHing from to the JUMPHOST.

The first step is to start the SSH reverse tunnel from the TARGETSRV. Here we are creating a tunnel from port 22 on the TARGETSRV to port 19999 on the JUMPHOST over port 22 SSH.

# ssh -p 22 -R 19999:localhost:22 JUMPHOST -l <user>

Now SSH to the JUMPHOST from CLIENT and run the following command:

ssh -p 19999 -l <user>

Now you will have connected to the TARGETSRV down the reverse tunnel.Especially useful if your target host is behind a firewall where direct access is not possible.

Raspberry Pi Time Synch

posted 22 May 2017, 12:50 by Tristan Self   [ updated 21 Oct 2017, 12:15 ]

The Raspberry Pi lacks a real time clock, which means that the time can drift, so much so that NTP fails to update the software clock because its skewed so much.

To resolve this you can do the following:

Add this to /etc/ntp.conf:

tinker panic 0

That will cause ntpd to sync despite the large clock offset.

sudo service ntpd stop
sudo ntpd -gq
sudo service ntpd start

Now run a "date" and check the time has synched as expected.

You can also try to create a cron job to force the synch to a remote server if the above still does not keep it in synch, Setting this every 5 minutes or 15 minutes interval should do the trick.

/etc/init.d/ntp stop
/usr/sbin/ntpdate -s
/etc/init.d/ntp start

NagiosXI check_ldap Error - Could not bind to the LDAP server

posted 4 Jan 2017, 03:25 by Tristan Self

When attempting to use the check_ldap plugin, I found that unsecured LDAP lookups on port 389/TCP worked fine, but attempting a secure lookup on 636 or using TLS failed.

Attempting a check_ldap check normally worked fine (i.e. to port 389), but attempting an LDAPS or LDAP TLS check failed with the following error:

# /usr/local/nagios/libexec/check_ldaps -H <HOSTNAME> -p 636 -S -a "(objectclass=organizationalUnit)" -b "dc=domain,dc=co,dc=uk" -3 -v
ldap_bind: Can't contact LDAP server (-1)
        additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.
Could not bind to the LDAP server

The check_ldap plugin makes use of OpenLDAP, the OpenLDAP package is installed as part of the NagiosXI installation because the plugins have dependencies on it but it is left in a non-configured state.

To resolve the problem on each node (wtgc-nagios-01 and wtgc-nagios-02) the following is required, firstly edit the file: /etc/openldap/ldap.conf and at the bottom of the file add the following line:


Then performing the check again gives the expected response:

# /usr/local/nagios/libexec/check_ldaps -H <HOSTNAME> -p 636 -S -a "(objectclass=organizationalUnit)" -b "dc=domain,dc=co,dc=uk" -3 -v
LDAP OK - 0.050 seconds response time|time=0.049688s;;;0.000000

Setup SSH Gateway on Raspberry Pi

posted 19 Dec 2016, 13:17 by Tristan Self   [ updated 19 Dec 2016, 13:24 ]

So looking for something to use your Raspberry Pi for? I had a Mk1 Raspberry Pi laying around and thought it might be good to set it up as a SSH gateway, so I could easily and securely access my home machines when out and about.

These instructions assume you have a Raspberry Pi which has Raspbian Jessie installed, i'm assuming you've also enabled SSH and have a named account created which you have already used to SSH to the Raspberry Pi over your network.

These instructions also get you to set SSH onto a non-standard port, setup two factor authentication using Google's authenticator and setup Fail2Ban to ensure hacking attempts can be blocked somewhat.

Assuming you've done this, you are ready to start, note you should make sure you run an apt-get update and apt-get upgrade to ensure that you are running the latest security updates.

SSH and Google Authenticator Configuration

1. Lets firstly disable root login via SSH.
sudo nano /etc/ssh/sshd_config

Changing the line PermitRootLogin to no.

2. Now within the same file change the port number from 22 to something non-standard like 2222 for example. Do this by changing the line Port 22 to read Port 2222.

3. At this point you should reboot the Raspberry Pi, then attempt to login on port 2222, don't go any further until you have got this working.

4. Now we need to install the Google Authenticator package.

# sudo apt-get install libpam-google-authenticator

5. Once installed you will then need to run the google authenticator, ensure you are logged in as the user you will be SSHing onto the box with to ensure you setup the authenticator configuration into your user's home area.

# google-authenticator

Answer yes to all the prompts in the wizard, you should also make a note of the scratch codes just in case you need them in future.

6. At the end you'll see a QR code, now you need to get out your smart phone and install the Google Authenticator App from your devices Application Store.

7. Now scan in the QR code using the App or enter the code manually. When done, your phone and your Raspberry Pi will be paired via the Google Authenticator to trust each other for authentication.

8. Finally we need to set SSH to use the google Authenticator as part of the authentication process, so you'll need to enter your username/password followed by the code generated by your phone to be able to logon.

9. Open the/etc/pam.d/sshd file with sudo nano /etc/pam.d/sshd add the following line to the end file:

auth required

10. Next open /etc/ssh/sshd_config then locate the ChallengeResponseAuthentication line (normally set to "no") and then set it to "yes".

11. Finally restart the SSH server.

# sudo /etc/init.d/sshd restart

Do not close the active ssh window you are working in. If something went wrong then you can quick debug it. Open a new ssh window instead and you should be prompted for a password followed by the code, all being well you should login fine!

Common Issue: Check that your timezone and time are set correctly on the Raspberry Pi, if they are not you will find your connection attempts will be rejected.

Tip: Check your logs for any errors with: sudo cat /var/log/auth.log | more

Also here you'll need to have punched a hole through your firewall on port 2222/TCP to the IP address of your Raspberry Pi, if you want to access it externally.

Fail2Ban Install and Configuration

We will now install Fail2Ban, and configure it to check on port 2222/TCP which we are now using for SSH, if more than two password failures are created, the IP address will be added to the block list permanently. The configuration for different services can be found in /etc/fail2ban/jail.conf. The default configuration only monitors SSH and bans the suspicious IP after 6 unsuccessful attempts for 600 seconds.

1. Firstly install fail2ban with

# apt-get install fail2ban

2. Then you need to edit the file /etc/fail2ban/jail.local, you may need to create it if you do not yet have it.

# vi /etc/fail2ban/jail.local

3. Once you are editing the file add the following:

banaction = iptables-allports
bantime = -1
maxretry = 2

This will block all IP traffic from a host forever if they get two failed connection attempts.

Then edit the file: /etc/fail2ban/jail.conf, and then add the following:

(within the DEFAULT section, add your local subnet e.g., stops you locking yourself out!)
ignoreip =

Then in the SSH section add the additional port 2222 to the line so it reads:

enabled  = true
port     = ssh,2222
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6

4. To avoid these blocks disappearing after a reboot, add the following to  /etc/fail2ban/action.d/iptables-allports.conf file to the actionstart section:

# cat /etc/fail2ban/ip.list-<name> | while read IP; do iptables -I fail2ban-<name> 1 -s $IP -j DROP; done

and following line to the actionban section:

# echo '<ip>/24' >> /etc/fail2ban/ip.list-<name>

These settings mean that any banned IP address is added to the  /etc/fail2ban/ip.list file and after restart of the Pi they are readded to the iptables firewall. Note this blocks the whole /24 subnet, you can omit this from the echo command above if you just want to block on an IP by IP basis.

Restart the fail2ban service:

# sudo service fail2ban restart

Overtime you'll see some IPs that are permanently banned. Check in iptables for the firewall block rules with:

# sudo iptables -L -n --line


Ubuntu, find used disk space.

posted 5 Sep 2016, 07:15 by Tristan Self

To easily find where your disk space is being used from the command line you can use the NCDU utilty.

To run this use:

# ncdu -x /

Check an SSL Certificate File in plain English

posted 7 Mar 2016, 05:13 by Tristan Self

You need to verify that a file cert.pem contains the certificate you expected, to do this you can use this command to view the certificate in plain text with expiry date etc visible.

# openssl x509 -in cert.pem -noout -text

1-10 of 25