Traceroute with Zabbix and MTR

At the company I work for, we are using Zabbix to monitor our infrastructure and in some case we are using “traceroute” to keep an eye on our network from different locations.

By keeping a traceroute history, it can help you to understand some networking problem by example when you are facing packet loss from some location.

To keep this history in Zabbix, we are using “MTR” instead of the traditional “traceroute” command.

Here is a small explanation of what MTR is, taken from the Github page of the project :

mtr combines the functionality of the ‘traceroute’ and ‘ping’ programs
in a single network diagnostic tool.

As mtr starts, it investigates the network connection between the host
mtr runs on and a user-specified destination host. After it
determines the address of each network hop between the machines,
it sends a sequence of ICMP ECHO requests to each one to determine the
quality of the link to each machine. As it does this, it prints
running statistics about each machine. 

Here is an example of the command output :

MTR is installed on our Zabbix proxies and on the main server.

Under Debian, the command to install MTR is :

sudo aptitude install mtr

As we are using proxies and active agents, the remote commands are not supported. So we have deployed a local script on the server and proxies.

Here is the local script (GitHub link) :

#!/usr/bin/env bash
mtr -r -c3 -w -b $IP

This local script is named “” and is saved under the “externalscripts” directory of Zabbix. The path can be found in the proxy or server configuration file under the following configuration key : “ExternalScripts“. Under Debian it’s “/usr/lib/zabbix/externalscripts“.

Once you have created the file, you have to allow Zabbix to execute it by using the following commands :

chmod +x
chown zabbix:zabbix

Then import the following template in Zabbix web interface and link it to a host : MTR History (exported from Zabbix 3.2.x)

If you prefer to add it in an existing template, here are the settings :

It will use the first ” IP address” in the “Agent interfaces” part of the host configuration.

You will find the history of data under the application “Traceroute” and in the item ” MTR Trace” on the “Latest data” tab of the configured host.

Here is an example of data from this tab :

Please note that, it’s recommended to increase the “Timeout” value in the Zabbix Server and Proxies configuration files to use this script. On my side it takes 10 seconds in average to be completely executed.

Veeam Backup & Replication 9.5 Update 1 with vSphere 6.5 support is available

A few weeks ago, I was writing about the availability of Veeam Backup & Replication 9.5 Update 1 RC and the way to get it. Today, you can get the official release from Veeam website. After the upgrade, your build version will be Before making this upgrade, be sure that you are running build, or

What’s new


Using VMware tags and Veeam for easy backup configuration

When you have a certain amount of VMs, there is one step that you can easily forgot or that takes time : configure the backup job.

Each time you add a VM you have to open Veeam interface and add the VM to a specific job.

But, today, I have an easy way to add some automation to solve this problem : VMware tags and Veeam backup job based on tag.

Create tags in VMware vCenter

When you are in the web interface of the vCenter, you will find on the left sidebar a link named “Tags”

Click on this link, then “Items” and select the tab “Tags”. You will find all the existing tags on your vCenter. To create a new tag, simply click on the new tag button.

Repeat this step for each tag you want to use.

Adding tags to VMs

Once you have created all the necessary tags, it’s time to add them to your VMs.

Right click on your VM then select “Tags & Custom Attributes” and pick the option “Assign Tag…”image2016-8-17 13-57-50

Select the tag that you want to add to this VM and click on “Assign”

image2016-8-17 13-59-10

The tag that you have assigned will be visible on the “Summary” tab of the given VM.

image2016-8-17 14-0-39

Adding the backup job to Veeam

To use a tag in a Veeam backup job, you have to create a new job :

image2016-8-17 14-9-19

Then give it a name. By example the name of the tag :

image2016-8-17 14-13-56

At the “Virtual Machines” step of the wizard, click on the tag button on the top right toolbar and select the tag on the list :

image2016-8-17 14-15-58

You will find the tag on the “Virtual Machines” list of the wizard :

image2016-8-17 14-17-43

Then configure all the next steps on the Veeam wizard and click “Finish”.

You will find the backup job on the jobs list :

image2016-8-17 14-18-47

At each job launch, Veeam will search for all VMs with the given tag. So you’ll never had to open the Veeam wizard again if you want to add a VM to a backup job.

Full restore of a virtual machine

When you want to make a full restore of a VM with a tag, you have to select the “Restore VM tags” option on the “Full VM Restore Wizard”. If you don’t do this, the VM will  lose its tag :

image2016-8-17 14-35-12

Installing Gitea on Debian

Gitea is a self-hosted Git service forked from Gogs. It’s very easy to deploy and has a low system usage impact.

It has features like :

  • web interface
  • wiki
  • issues management
  • admin dashboard
Gitea web interface

Gitea web interface

In this howto, we will use SQLite as the database backend and the Gitea binary (as there is no Debian package available at this time).

This howto is based on Debian Jessie. But it should work with Debian Stretch (alias testing).

Installing the basics

To be able to run Gitea on Debian you will need a local user without root rights and the git package.

Install git :

sudo aptitude install git

Create a local user without root rights and no right to log on :

sudo adduser --disabled-login --gecos 'gitea' git

Here is the explanation of the two options that I’ve added to the “adduser” command :

  • “–disabled-login” won’t ask for any password. So it means that as long there is no password set for this user, he won’t be allowed to log on
  • “–gecos” followed by a comment, will populate the finger information automatically (First Name, Last Name, …)

Installing Gitea

Switch to the git user that you have previously created :

sudo su - git

Download the Gitea binary (get the last version here or here) :

wget -O gitea

Make the download file executable :

chmod +x gitea

Create the necessary directories :

mkdir -p custom/conf
mkdir data

Launch Gitea for the fist time :

./gitea web

Open a webpage in your browser using the IP of your server on the TCP port 3000 (by example : and complete all the information asked by Gitea.

Your configuration file will be in the “custom/conf/” directory on the “app.ini” file. You can find the standard configuration file here if you want to check what you can change.

If you want to change some advanced settings, you’ll want to read the “Configuration Cheat Sheet“.

Installing Supervisor

To be able to run Gitea as a service, we will use Supervisor.

Install it :

sudo aptitude install supervisor

Create the log directory for the Gitea service :

sudo mkdir /var/log/gitea

Create the configuration file for the Gitea service :

sudo vi /etc/supervisor/conf.d/gitea.conf

Put the following information in this file :

command=/home/git/gitea web
environment = HOME="/home/git", USER="git"

Restart the supervisor service :

sudo service supervisor restart

Check the content of the Gitea log file :

sudo tail /var/log/gitea/stdout.log

Check if the service is running :

ps -ef | grep gitea

You should have something like that :

Use Gitea with Nginx as a Reverse Proxy

If you want to use Gitea behind a reverse proxy using Nginx with SSL (using Let’s Encrypt with certbot) you can use the following configuration file :

        listen 80;
        server_name mygitserver.tld;

        location /.well-known/acme-challenge {
                root /var/www/git;
        location / {
                return 301 https://$host$request_uri;

        listen 443;
        ssl on;
        server_name mygitserver.tld;
        ssl_certificate /etc/letsencrypt/live/mygitserver.tld/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/mygitserver.tld/privkey.pem;
        location / {
                proxy_set_header Host             $host;
                proxy_set_header X-Real-IP        $remote_addr;
                proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
                #max_body_size will allow you to upload a large git repository
                client_max_body_size 100M;

In this case, Nginx will be configured to allow the Let’s Encrypt server to get the challenge file in the “/.well-known/acme-challenge” directory. To do that, you will have to create the following directory : “/var/www/git” and give Nginx the right to read files on it.

Then you will have to install certbot. You can find it in Debian Backports.

sudo apt-get install certbot -t jessie-backports

To get the certificate file, you can use the following command :

certbot certonly --webroot -w /var/www/git -d mygitserver.tld

Remember that Let’s Encrypt certificate is only valid during 90 days, so put this in your crontab to automatically generate new certificate before it expires :

0       1       1       *       *       certbot renew --quiet
36      8       2       *       *       certbot renew --quiet

You will find the following settings in the “[server]” part of the Gitea “app.ini” file :

DOMAIN = localhost
HTTP_PORT = 3000

Change them by :

PROTOCOL               = http
DOMAIN                 = mygitserver.tld
ROOT_URL               = https://mygitserver.tld
HTTP_ADDR              =
HTTP_PORT              = 3000

Then, to apply, restart the supervisor service :

sudo service supervisor restart

Veeam Backup&Replication 9.5 Update 1 RC is available

Update on 22th January 2017Veeam Backup & Replication 9.5 Update 1 with vSphere 6.5 support is available

On the 15th November VMware has announced the General Availability (GA) of vSphere 6.5 and on the 16th Veeam has done the same with the GA of Veeam Availability Suite 9.5.

Two big announcements but one problem : Veeam 9.5 is not compatible with vSphere 6.5. We will have to wait until Veeam 9.5 Update 1 that will be available at least two months after the last release of VMware.

On the 30th December, Veeam has announced on his forum that the release candidate is available and that if you want to try it, you have to open a case via the customer portal. You only have to ask to try this release and they will send you all the links to download each part of Veeam 9.5 Update 1 RC.

The update path is the same as the traditional stable Veeam updates : extract the EXE from the ZIP and execute it.

After the update you will have the following build number :

Currently, we are testing this release in the company I work for within an all new VMware 6.5 infrastructure (not in production) and it’s running fine.

Caution : It’s a Release Candidate version and there is no support from Veeam for this one. So be careful and don’t use it in your production environment.

Backup your WinSCP configuration file

If like me, you are a user of WinSCP, maybe you would like to save your configuration.
The configuration of WinSCP contains all the information needed to get access to your servers (IP, protocol, …). It could be valuable to save all those information in case of computer crash or if you want to sync this configuration between two computers.

To do this, you have two choices. You can manually export the configuration file after each change or you can add the WinSCP file to your backup or synchronization software.

If you want to use the second method, you can get all the settings from the Windows registry or from a text file stored in the AppData.

To use this last method you have to go to the settings and select the “Storage” sub-menu.

In this menu, you have to select “INI file”.

WinSCP Preferences

As soon this settings is validated, you will find a “WinSCP.ini” file under the “Roaming” directory of the AppData linked to your Windows profile.

WinSCP's configuration file


QNAP – Multiple outgoing connection on UDP port 6881

A few weeks ago, while analyzing a customer’s network, I’ve discovered that their QNAP NAS was making a lot of outgoing connections on UDP port 6881.

Knowing that this NAS is only used as an internal repository for Veeam backup, I knew that this traffic was not wanted.

Here is an example of the traffic :

After a quick search, it appears that this port is a BitTorrent port. This search confirms that this is an unwanted network traffic.

So, I’ve looked up on the QNAP documentation and forum, and I’ve discovered a post that was speaking about this problem.

This problem is linked to the package “Download Station” that is installed on this QNAP.

Here is the way to solve the problem :

  • Open the Download Station
  • Go to the Settings and then “BT”
  • On the “BT” tabs, select the “Connection” and then uncheck the two boxes “Enable DHT network” and “Enable UPnP port mapping
  • After a few seconds, all the connections will be terminated