Monthly Archives: March 2019

Troubleshooting check_mk agent in Linux

Different steps to troubleshoot check_mk agent in Linux

check_mk agent checks

Before we start you may want to check our tutorial about setting up check_mk monitoring in Linux. You might experience issues when adding a server into check_mk monitoring. Below are a few steps, you can check to validate your configuration and communication between check_mk server and client works well.

Port 6556 communication

check_mk communicate over port 6556 by default. You need to check if port 6556 is open between client and server.

Also, you need to check if port 6556 is listening on your check_mk client so that server can fetch details by querying the client on port 6556.

root@kerneltalks#  netstat -lpn | grep 6556
tcp6       0      0 :::6556                 :::*                    LISTEN      24303/xinetd

You can even check using telnet on client and from server to client.

root@kerneltalks # telnet localhost 6556
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

How to restart check_mk agent

check_mk agent runs on top of xinetd service in Linux. So if you make any changes to the config file then you need to reload configuration or restart the agent.

Reload check_mk configuration using below command –

root@kerneltalks # service xinetd reload
Redirecting to /bin/systemctl reload xinetd.service

Restart check_mk agent using below command –

root@kerneltalks # service xinetd stop
root@kerneltalks # service xinetd start

check_mk configuration file

Make sure you have a proper configuration file in place. check_mk configuration file is located at /etc/xinetd.d/check_mk_agent. The sample configuration file is as below –

# Created by Check_MK Agent Bakery.
# This file is managed via WATO, do not edit manually or you
# lose your changes next time when you update the agent.


service check_mk_agent
{
        type           = UNLISTED
        port           = 6556
        socket_type    = stream
        protocol       = tcp
        wait           = no
        user           = root
        server         = /usr/bin/check_mk_agent
        log_on_success =
        disable        = no
        only_from      = 10.10.1.2 10.10.1.3
}

only_from field denotes check_mk server IPs to which your agent will communicate. It will be populated by RPM you used to install. If it doesn’t reflect proper values you can edit it and reload check_mk configuration by using commands mentioned above.

check_mk agent updater

Check update for check_mk agent and download from the server using check_mk updater.

root@kerneltalks #  cmk-update-agent -v -v
+-------------------------------------------------------------------+
|                                                                   |
|  Check_MK Agent Updater - Update                                  |
|                                                                   |
+-------------------------------------------------------------------+
Read /etc/cmk-update-agent.state.
Getting target agent configuration from deployment server
Fetching URL: http://kerneltalks1/master/check_mk/deploy_agent.py?...
Response from deployment server:
AgentAvailable: False

Read /etc/cmk-update-agent.state.
Saved deployment status to /etc/cmk-update-agent.state.
No agent available for us.

Using this command you can even see to which server client is registered. If the client is not registered with check_mk server then you will see below error –

root@kerneltalks # cmk-update-agent -v -v
+-------------------------------------------------------------------+
|                                                                   |
|  Check_MK Agent Updater - Update                                  |
|                                                                   |
+-------------------------------------------------------------------+
Read /etc/cmk-update-agent.state.
Getting target agent configuration from deployment server
Fetching URL: http://kerneltalks1/master/check_mk/deploy_agent.py?...
ERROR This host is not registered for deployment

cmk-update-agent can not execute binary error

If you come across below error while executing cmk-update-agent command then it’s probably you are running binary of architecture it is not meant to run. e.g. you are running x86 binary on ARM server

/usr/bin/cmk-update-agent: line 8: /usr/lib/check_mk_agent/plugins/21600/cmk-update-agent: cannot execute binary file

Solution: Make sure you install the proper architecture package on your server which matches your server architecture. Generally x86 check_mk package is marked as noarch package but it will land you up in the above issue when you install it on the ARM arch server.

check_mk xinetd error

---------------------------------------------
WARNING
This package needs xinetd to be installed.
Currently you do not have installed xinetd.
Please install and start xinetd or install
and setup another inetd manually.
It's also possible to monitor via SSH without
an inetd.
---------------------------------------------

Solution: Install xinetd package. Start and enable xinetd service. If you are running a newer kernel/OS like Suse 15 SP1, xinetd is not available in it. Its sockets being served by systemd. You need to install a higher version of check_mk agent RPM which identifies systemd sockets and it won’t show you above error. e.g. version 1.4 packages were showing above error to me while when I used version 1.5 package, it got away and installation succeeded.

check_mk python error

---------------------------------------------
ERROR
Failed to install agent: Could not find a
'python' interpreter.
---------------------------------------------

Solution: It means you have a higher version of python like python3 and agent rpm is looking for python. Use the higher version of check_mk agent which understands the latest python binaries (which has nomenclature with like python3 and not python)

How to add new disk in Linux

Step by step procedure to add disk in Linux machine

New disk addition in Linux

In this article, we will walk you through steps to add a new disk in the Linux machine. Adding a raw disk to the Linux machine may vary depending upon the type of server you have but once the disk is presented to the machine, the procedure of getting it to mount points is almost the same.

Objective: Add a new 10GB disk to the server and create a 5GB mount point out of it using LVM and newly created volume group.

Adding raw disk to Linux machine

If you are using the AWS EC2 Linux server, you may follow these steps to add raw disk. If you are on VMware Linux VM you will have a different set of steps to follow to add disk. If you are running a physical rack-mount/blade server then adding disk will be a physical task.

Now once the disk is attached to the Linux machine physically/virtually, it will be identified by the kernel and then our rally starts.

Identifying newly added disk in Linux

After the attachment of the raw disk, you need to ask the kernel to scan a new disk. Mostly it’s done now automatically by the kernel in new versions.

First thing is to identify the newly added disk and its name in the kernel. There are numerous ways to achieve this. I will list a few –

  • You can observer lsblk output before and after adding/scanning disk to get a new disk name.
  • Check newly created disk files in /dev filesystem. Match timestamp of file and disk addition time.
  • Observer fdisk -l output before and after adding/scanning disk to get a new disk name.

For our example, I am using the AWS EC2 server and I added 5GB disk to my server. here is my lsblk output –

[root@kerneltalks ~]# lsblk
NAME    MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda    202:0    0  10G  0 disk
├─xvda1 202:1    0   1M  0 part
└─xvda2 202:2    0  10G  0 part /
xvdf    202:80   0  10G  0 disk

You can see xvdf is our newly added disk. Full path for disk is /dev/xvdf.

Add new disk in LVM

We are using LVM here since its widely used and flexible volume manager on the Linux platform. Make sure you have lvm or lvm2 package installed on your system. If not, install lvm/lvm2 package.

Now, we are going to add this RAW disk in Logical Volume Manager and create 10GB of mount point out of it. List of commands you need to follow are –

If you are willing to add a disk to the existing mount point and use its space to extend mount point then vgcreate should be replaced by vgextend.

Sample outputs from my session –

[root@kerneltalks ~]# pvcreate /dev/xvdf
  Physical volume "/dev/xvdf" successfully created.
[root@kerneltalks ~]# vgcreate vgdata /dev/xvdf
  Volume group "vgdata" successfully created
[root@kerneltalks ~]# lvcreate -L 5G -n lvdata vgdata
  Logical volume "lvdata" created.

Now, you have a logical volume created. You need to format it with the filesystem on your choice and mount it. We are choosing ext4 filesystem here and formatting using mkfs.ext4 .

[root@kerneltalks ~]# mkfs.ext4 /dev/vgdata/lvdata
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
327680 inodes, 1310720 blocks
65536 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1342177280
40 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

Mounting volume from new disk on mount point

Lets mount the logical volume of 5GB which we created and formatted on /data mount point using mount command.

[root@kerneltalks ~]# mount /dev/vgdata/lvdata /data
[root@kerneltalks ~]# df -Ph /data
Filesystem                 Size  Used Avail Use% Mounted on
/dev/mapper/vgdata-lvdata  4.8G   20M  4.6G   1% /data

Verify your mount point with df command as above and you are all done! You can always add an entry in /etc/fstab to make this mount persistent over reboots.

You have attached a 10GB disk to the Linux machine and created a 5GB mount point out of it!

How to use sudo access in winSCP

Learn how to use sudo access in winSCP with screenshots.

sudo access in winSCP

Before you move into configurations, make sure that the user is having NOPASSWD access to sudo to target user or root account. This means /etc/sudoers file must have entry something like below –

user1 ALL=(root) NOPASSWD: ALL

Once you have proper sudo configuration you can go ahead with WinSCP config. This is to ensure that once shell tries sudo it should be non-interactive.

First of all, you need to check where is your SFTP server binary located on the server you are trying to connect with WinSCP.

You can check SFTP server binary location with below command –

[root@kerneltalks ~]# cat /etc/ssh/sshd_config |grep -i sftp-server
Subsystem sftp  /usr/libexec/openssh/sftp-server

Here you can see sftp server binary is located at /usr/libexec/openssh/sftp-server

Now open winSCP and click Advanced button to open up advanced settings.

winSCP advance settings

It will open up an advanced setting window like one below. Here select SFTP under Environment on the left-hand side panel. You will be presented with an option on the right hand side.

Now, add SFTP server value here with the command sudo su -c here as displayed in the screenshot below –

SFTP server setting in winSCP

So we added sudo su -c /usr/libexec/openssh/sftp-server in settings here. Now click Ok and connect to the server as you normally do.

After connection, you will be able to transfer files from the directory where you normally need sudo permission to access.

That’s it! You logged to server using WinSCP and sudo access.

How to redirect port in Linux using iptables

Short post to explain how to redirect port in Linux using iptables.

Port redirection using iptables

In this short tutorial, we will walk you through the process to redirect port using iptables. How to check port redirection in Linux and how to save iptables rules.

Here are few iptables tutorials for your basics :

  1. Basics of iptables
  2. Configuration of iptables policies
  3. Flushing iptables rules
  4. Disable iptables temporarily

Our requirement is to redirect port 80 to port 8080 in the same server. This can be done by adding rules in PREROUTING chain. So run below command –

[root@kerneltalks ~]# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080

If you have an interface name other than eth0 then you need to edit your command accordingly. You can even add your source and destinations as well in same command using --src and --dst options. Without them, it’s assumed to any source and any destination.

How to check port redirection in iptable

Verify port redirect rule in iptables using below command –

[root@kerneltalks ~]# iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REDIRECT   tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80 redir ports 8080
..............

You can see port 80 is being redirected to port 8080 on the server. Note here target is REDIRECT. Do not get confused with port redirection with port forwarding.

How to save iptables rules

To save iptables rules and make them persistent over reboots use below command –

[root@kerneltalks ~]# iptables-save