Category Archives: SysAdmin

Fortigate checks for Check_MK updated to 2.2.3

Hi there,

I’ve updated the package to the version 2.2.3. Please consider updating to the new version some time. The change concerns only the check fortigate_ipsec and corrects a bug, that can cause an issue, when a IPSec tunnel doesn’t exist anymore. In this case the check can disturb the execution of other checks and make it not possible to re-execute the inventory.

The new version 2.2.3 is located as always on the check_mk exchange site.

Best regards

Hermann Maurer

Adding a new HDD to the existing VG

Sometimes you need to extend the existing volume group to be able to add free space to the logical volumes in there.

Look at this situation:

[root@localhost ~]# vgs data
 VG #PV #LV #SN Attr VSize VFree
 data 1 1 0 wz--n- 39.99g 0

Continue reading

Fortigate checks for Check_MK updated to 2.2.2

Hi there,

again there has been a bug in the OID in the check fortigate_sessions. Or maybe I didn’t create the package carefully enough. Anyway there is a new version 2.2.2 and it’s located as always on the check_mk exchange site. Please consider updating as soon as possible, because the version 2.2.1 collects wrong values.

Best regards

Hermann Maurer

Collect pnp4nagios data in Check_MK distributed environment

Introduction

I hope you enjoy the great monitoring software Check_MK. If you have a big environment with lots of hosts and services distributed over dozen of sites (company locations) , you might have already configured your Check_MK to use the distributed monitoring in WATO. I assume that you have got a master and some slaves. The master in terms of Check_MK is the host, which you are using to configure your whole Check_MK installation and to look at all hosts and services, whilst slaves are those hosts that receive the configuration from the master and which the master gets the monitoring results from.  Distributed monitoring is an extremely nice and powerful feature of Check_MK that allows you to keep your configuration at one place and that takes care on distributing the changes on the configuration to the slaves. Also it’s very easy to connect a new slave to the master site.

Continue reading

Fortigate checks for Check_MK updated to 2.2.1

I’ve just uploaded a new version of the check to Check_MK Exchange site. This is a bug fixing version, is doesn’t contain any new features.

The new version includes a minor bug fix in fortigate_sslvpn check. I corrected the OID used there to get the value of the active SSL VPN sessions. The old versions might show a wrong number of active sessions. Please update the package.

Reverse proxy timeouts with Check_MK

In some distributed environments and with a lot of configured users and connection to Microsoft active directory configured in Check_MK times to distribute the changes from the master to all slave sites grow up strongly. Check_MK distributed monitoring uses Apache web server acting as reverse proxy. Sometimes one of Apache web server’s instances doesn’t return data within a pre-defined time range. In such cases you can get the error like this while trying to replicate your slave with the master site:

Continue reading

Prepare a Fortigate to configure high availability cluster

If you’ve got a fresh Fortigate and want to configure it as HA, you have to prepare something, because the factory-standard configuration doesn’t let you to enabled High Availability.

The preparation steps are as follows:

  • Remove DHCP server settings
  • Remove existing firewall policies
  • Set the interface mode for all interfaces to static, because pppoe and dhcp modes are not supported in a HA cluster environment
  • Set the hostname
  • Set the mode for interfaces to internal-switch-mode interface

Continue reading

Notes on usage of Check_MK Multisite with LDAPS

I had to configure OMD/Check_MK version 1.2.4p3 to use LDAPS to connect to Windows domain controller. The operating system on the host running OMD/Check_MK is CentOS 6.5 x64.

Continue reading

Postfix in Internet, Relay in LAN

Assume the following scenario:

Your Postfix MTA is located in the Internet (having a public IP address) and you have configured an external DNS server there to be used for DNS requests.  But you are going to send mails using an internal mail server as mail relay. In this case the private IP address of the internal mail relay cannot be re-solved by the external DNS server. In this situation Postfix cannot use the mail relay and shows an error message like this below in the log file:

Aug 26 12:49:12 myclient postfix/error[28425]: B35AF34B: to=<me@company.local>, relay=none, delay=0.14, delays=0.09/0/0/0.04, dsn=4.3.5, status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=mailrelay.company.local type=AAAA: Host not found)

To re-solve the issue you have to add the following statement to main.cf

disable_dns_lookups = yes

and re-load postfix:

service postfix reload

Use the appropriate command to enforce delivery of queued mails.

 

Some useful postfix commands

To re-try delivering of queued mails:

postqueue -f

To remove all deferred mails:

postsuper -d ALL deferred

To remove all mails

postsuper -d ALL