Zabbix 5.0 LTS released!

Zabbix 5.0 LTS released! Viva Zabbix!

Zabbix is one of the our favourite open source monitoring system. It offers dozens of functions, models, templates dedicated to the most importants vendrors (visit Zabbix Share).

What’s New in Zabbix 5.0 LTS
Zabbix 5.0 LTS release comes with significant improvements in usability, security, and integrity.

Here is just a shortlist of the most important functionality included in Zabbix 5.0 LTS.

You choose: deploy on-premise or in the cloud
Zabbix is a Free and Open Source monitoring solution that can be deployed everywhere depending on your needs!

In addition to existing official packages and appliances, Zabbix 5.0 now also caters to the following platforms: SUSE Linux Enterprise Server 15, Debian 10, Ubuntu 20.04, Raspbian 10, Mac OS/X, RHEL 8, CentOS 8, MSI for Windows Agent.

See all available platforms in Downloads

Zabbix introduces a new set of out-of-the-box integrations with industry-standard cloud providers:

  • AWS
  • Azure
  • Google Cloud Platform
  • Digital Ocean
  • Docker
  • IBM/RedHat Cloud
  • Oracle Cloud

SAML authentication for single sign-on
SAML is used to provide a single point of authentication at a secure identity provider, meaning that user credentials never leave the firewall boundary, and then SAML is used to assert the identity to Zabbix and other applications. Support of SAML allows to have out-of-the-box integration of Zabbix with various on-premise and cloud identity providers like Microsoft ADFS, OpenAM, SecurAuth, Okta, Auth0 and many others.

Secure and reliable monitoring
Zabbix 5.0 introduces significant improvements for much more secure monitoring:

  • Support of HTTP Proxy for webhooks that allows to make connections from Zabbix Server to external alerting and ITSM systems more secure and controlled
  • Support of blacklists and whitelists for metrics on agent-side
  • Configurable ciphers for all Zabbix components to avoid using of non-secure ciphers for TLS connections
  • Support of encrypted connections to MySQL and PostgreSQL backends
  • Strong SHA256 for keeping hashes of user passwords

Keep your secrets secure
Zabbix 5.0 supports secret user macros for keeping any sensitive information like passwords and API tokens that you do not want to be exposed to end-users.

Scalability and performance
Zabbix 5.0 supports optional compression of collected data for TimescaleDB. In addition to general TimescaleDB advantages (automatic partitioning, performance and scalability) it also helps to even more improve performance and lower storage costs.

Zabbix UI is also improved to support monitoring and management of millions of monitored devices.

Next generation Zabbix Agent got official support
The new agent offers a wide range of new capabilities and advanced monitoring functions for Linux and Windows:

  • Written in Golang
  • Plugin framework for monitoring of various services and applications
  • Ability to maintain state between checks (for example, keeping persistent DB connections)
  • Support of trapping
  • Built-in scheduler to support flexible time intervals
  • Efficient network usage through bulk data transfer
  • Support of persistent storage of collected data
  • Drop-in replacement of existing agents on Linux and Windows

For a complete list of new features check out the documentation.

NB! Existing Zabbix agent will still be supported.

Next generation Zabbix Agent got official support
Monitoring that is easy to use and manage
Zabbix 5.0 got tons of usability and automation improvements that help:

  • Threading for email notifications generated by the same event
  • New preprocessing operation Replace, new operator for JSONPath
  • Ability to unacknowledge event
  • Support of message templates for media types for straight forward configuration of notifications
  • CLI tool to test JavaScript-based preprocessing and webhooks
  • Ability to test new and existing metrics from UI
  • Support of mass update of user macros
  • SNMP settings moved to host interface level for more simple templates and easier management
  • Host and metric availability monitoring using function nodata() respects availability of proxies
  • Monitoring that is easy to use and manage

Flexibility to monitor anything you want
Zabbix 5.0 extended functionality to make it more flexible:

  • Triggers support operations with text data
  • Support of host macros for host prototypes
  • Support of Float64 datatype
  • Support of override for low level discovery (LLD) helps to create much smarter templates
  • Flexibility to monitor anything you want

Automation and discovery
Automation is an essential part of Zabbix. Zabbix 5.0 brings it forward with support of:

  • Discovery of Windows performance counters
  • Discovery of JMX counters
  • Better ODBC monitoring with ability to configure all options for each metric individually

Advanced visualization
Presenting data in a human readable way is critical for operations. Zabbix 5.0 helps to make it even better by introducing:

  • New layout of Zabbix UI optimized for wide screens
  • A new view (Monitoring->Hosts) for displaying a list of monitored devices with advanced filtering options
  • Support of filtering by event tags for some dashboard widgets
  • Ability to copy dashboard graphs as pictures
  • Support of UI modules to extend functionality of Zabbix
  • Faster creation of dashboards thanks to ability to copy widgets
  • Improved consistency of map labels

Test item from UI
In previous Zabbix versions, it was difficult to tell if a newly-configured item was configured correctly or not. For that you needed to wait until the item tried to gather some data.

In the new version it is possible to test the item (template item, item prototype, low-level discovery rule) from the user interface even before saving and, if configured correctly, get a real value in return.

Item testing is not supported for active items and some simple checks (icmpping*vmware.* items).

To test the item, click on the Test button at the bottom of the item configuration form.

Built-in integrations with ITSM systems
Zabbix 5.0 introduces a new set of out-of-the-box integrations with industry-standard cloud-based and on-premise ITSM systems.

Official webhook Coding Guideline was introduced to set standard and simplify creation of webhook based integrations.

More integrations with ITSM systems: Integrations

Built-in integrations with alerting systems
Zabbix 5.0 introduces a new set of out-of-the-box integrations with industry-standard alerting and notification systems.

More integrations with alerting systems: Integrations

New and updated templates and plugins
Most of the existing templates are updated and new templates and plugins are introduced for monitoring of different services, applications and devices.

Most of the templates now take advantage of the functionality for smart automatic discovery of various resources.

More templates and plugins: Integrations

Adjust Zabbix to your needs, contribute!
Make your template, plugin or a webhook included into the official Zabbix distribution by following these three steps:

Sign Zabbix Contributor Agreement (ZCA)
Make Zabbix Pull Request
Zabbix Dev Team will review and accept if everything is fine
Congratulations! Your solution is officially supported and thousands of Zabbix users are thankful for your effort!

More newly developed and improved features of Zabbix 5.0 LTS

  • Increased size of acknowledge messages from 255 to 4096 characters
  • Added support of LIBSSH to support newer platforms like RHEL 8
  • Support of Elasticsearch 7.x (7.4, 7.6)
  • Latest data displays data if filter is not set
  • Increased zabbix_sender time resolution to nanoseconds
  • Monitoring->Latest data: show data if filter is empty
  • Base64 processing in JavaScript using new functions atob() and btoa()
  • Do not log[] for local use
  • Increased size of item key from 255 to 2048 characters
  • Ability to flush SNMP cache, SNMPv3 context changes
  • Faster hash function for internal operations
  • Documented how to do filtering for vmware.event monitoring
  • Improved consistency of map labels
  • Filter by individual severities for Monitoring→Problems
  • Ability to use user macros for IPMI user name and password
  • Remote monitoring of versions of Zabbix components
  • Added filter for discovery rules
  • New API method to get auditlog

Removed legacy to build a better product faster

  • No support of Internet Explorer 11
  • Dropped support of IBM DB2
  • mbedTLS (former polarSSL) is no longer supported for encryption. Only OpenSSL and GnuTSL libraries

Minimum supported version for PHP is now 7.2: safer and more strict code
And more! For a complete list of new features check out the Release notes. Release Notes.

More Informations about what’s new is here: Link

How To Design An Effective Naming Convention

While recording my VMware vSphere 5 Training course this past summer, I made mention that I developed a process for building an effective naming convention for enterprises. Server and desktop virtualization significantly increases the number of named objects within our enterprises, so an effective naming convention that describes what an object is, its location, function and purpose is critical. Doing so allows us to identify objects in a speedy way, but it also provides a structured way of searching for objects using keywords in a logical manner.
Even as I developed these guidelines, I did not think it would interest folks very much. But I started receiving near daily tweets and e-mails requesting a copy of the document. So, I’ve decided to publish it and share it with everyone in today’s blog.
Here are my basic guidelines for the object naming convention:

  • A name should identify the device’s location and its purpose/function/service.
  • A name should be simple yet still be meaningful to system administrators, system support, and operations.
  • The standard needs to be consistent. Once set, the name should not change.
  • Avoid special characters; only use alphanumeric characters.
  • Avoid using numeric digits, except for the ending sequence number.
  • Avoid the use of specific product or vendor names, as those can be subject to change. (There are some generally accepted exceptions: Oracle, SMS, SQL, CTX, VMW)

Here are some basic recommendations:

  • The name should begin with a rigid header portion that identifies the location and optionally a type identifier. These should be followed by a delimiter to signify the end of the header portion. This delimiter shall be a ” – ” (dash) unless the system does not recognize a “-“. In this case, substitute the dash for another suitable agreed-upon character (i.e. $ or #).
  • Allow for a variable section that completes the identification (function, service, purpose, application).
  • End the name with a unique ID, a sequence number, which can be multi-purpose.
  • Allow for flexibility. Since technology is constantly evolving, this standard must also be able to evolve. When necessary, this standard can be modified to account for technological, infrastructure, and or business changes.
  • There must be enforcement, along with accurate and current documentation for all devices.Here is an example of the proposed naming convention standard


Naming Convention
Naming Convention

Header portion

  • GG — Geographical location
  • L — Location should be generic and not vendor- or building-specific to facilitate moves, building name changes due to mergers, acquisitions or dissolution of business, etc.
  • T — Type – — Dash is a required delimiter to signify the end of the header portion

Variable portion:

  • AAA — Function /Service/Purpose
  • BBB — Application(Unique ID)
  • ## — 2 digit sequence #

Values Defined:


  • CH — Chicago
  • NY — New York
  • LN — London
  • SY — Sydney
  • MA — Madrid
  • SI — Singapore
  • MU — Mumbai


  • D — Main Data Center
  • C — COLO Data Center
  • T — Test Area (should be used for test machines that are to permanently stay in the test area)

Type (optional):

  • V — Virtual
  • C — Cluster server
  • P — Physical
  • O — Outsourced or vendor supported system

Delimiter (required):

  • – A “-” (dash) will be used unless the system does not recognize a “-” at which point an agreed upon character can be substituted. This could be a $ or # or other character.

Variable portion – AAA Identify the primary purpose of the device:

  • DC — Domain Controller
  • FS — File Server
  • PS — Print Server
  • ORA — Oracle database
  • SQL — SQL database
  • DB — other database(s)
  • EXH — Microsoft Exchange
  • CTX — Citrix Server
  • ESX — VMware ESX Server

Variable portion BBB Identify the Application on this server.

If the server is for a specific application, then an application identifier should be the second part of this portion of the name, preceded by the service:

  • JDE — JDEdwards
  • DYN — Dyna
  • EPC — Epic

This area of the name offers a lot of flexibility to handle identifiers for specific purposes, functions, and/or applications. There are many challenges to select identifiers that are meaningful and consistent and are not subject to frequent change. Here are some examples based on th guidelines I propose above:

  • CHD-DC01 — Chicago Office, Data Center, Domain Controller, sequence # 1
  • CHD-FS01 — Chicago Office, Data Center, File Server, sequence # 1
  • CHD-EXH01 — Chicago Office, Data Center, Microsoft Exchange, sequence # 1
  • CHD-ESX01 — Chicago Office, Data Center, VMware ESX Server, sequence # 1
  • CHC-CTXJDE01 — Chicago Office, Data Center, Citrix Server,JDEdwards Application, sequence # 1
  • CHC-WEB01 — Chicago Office, Data Center, Web Server, sequence # 1

Unique ID / sequence number

## This is a 2 digit sequence number

I would love to hear your comments on this naming convention and if you have ideas to improve it.

Related Article: Link

Manutenzione server: checklist per i data center

Come tutte le macchine, a maggior ragione se sofisticate, anche i server del data center richiedono una regolare manutenzione per conservare un’operatività ottimale e mantenere le massime prestazioni. Da questo punto di vista, alcune semplici procedure possono aiutare a ridurre i casi più gravi di chiamate al servizio di assistenza e a estendere la vita utile dei server.

In effetti, se è vero che i server moderni hanno alte prestazioni e sono dotati di caratteristiche e funzionaltà ridondanti, va anche considerato che il crescente consolidamento dei workload e le aspettative degli utenti sul livello di affidabilità delle macchine obbliga a mantenerle sempre in perfetto stato.

Quindi la ‘checklist’, ossia la lista dei controlli da eseguire, dovrebbe coprire sia i componenti hardware e gli elementi fisici, sia la componente software e gli aspetti che riguardano le configurazioni critiche del sistema.

Un altro fattore da non trascurare riguarda il tempismo negli interventi: troppo spesso, infatti, gli amministratori dei server sottovalutano una metodica pianificazione dei tempi di manutenzione, riducendosi a intervenire quando ormai il guasto è manifesto. Per scongiurare tali rischi è quindi consigliabile riservare del tempo per eseguire sui server manutenzioni di routine preventive.
Come programmare e preparare gli interventi sui server

Spesso la frequenza di manutenzione dipende da quanto l’attrezzatura è datata, dall’ambiente di data center, dal numero di server che richiedono manutenzione, e da altri fattori.
Ad esempio, le attrezzature più vecchie, collocate in armadi server e sale dati con diversi anni di vita, richiedono ispezioni più frequenti dei nuovi server, installati in data center ben raffreddati e dotati di filtri HEPA (high efficiency particulate air).

Per quanto riguarda le programmazioni della manutenzione di routine, esse possono ispirarsi a quelle del vendor o fornitore di terze parti: se, ad esempio, il contratto di servizio del vendor richiede ispezioni del sistema ogni quattro o sei mesi, si può seguire quel programma.
Prima di procedere, affrontando i singoli punti della checklist di manutenzione del server, è bene predisporre un piano di controllo dei registri di sistema, atto a evidenziare errori o eventi che richiedono una più diretta attenzione: ad esempio, se i log di sistema denotano errori in uno specifico modulo di memoria, si dovrebbe ordinare un modulo DIMM in sostituzione, e mantenerlo disponibile per l’installazione. In maniera analoga, se sono disponibili firmware, sistema operativo o patch e update, è meglio collaudarli e verificarli, prima di procedere con la manutenzione.

Spegnimento e pulizia del server

Occorre anche definire un piano preciso per mettere offline il sistema e riportarlo in servizio una volta terminati gli interventi. Ma con alcune differenze rispetto al passato. Se prima dell’avvento della virtualizzazione, il server e l’applicazione ospitata su di esso richiedevano una fase di ‘downtime’ per eseguire la manutenzione, costringendo spesso il personale a effettuare le operazioni di notte o nel week-end, oggi lo scenario è diverso: i server virtualizzati abilitano la migrazione dei workload, quindi le applicazioni si possono spostare, e mantenere attive e disponibili, su altri server, anche quando si fa la manutenzione sul server host di partenza. Una volta verificato che le macchine virtuali, e i rispettivi workload, che si sono fatti migrare sui sistemi selezionati, funzionano, è possibile spegnere il server, e rimuoverlo dal rack o dall’enclosure, per eseguire la manutenzione.
A questo punto, una prima cosa importante è ispezionare tutte le vie di deflusso dell’aria, rimuovendo accumuli di polvere e detriti in grado di impedire il raffrescamento del sistema, e controllando punti critici come il dissipatore della CPU, le ventole, i moduli di memoria. La pulizia si esegue con aria compressa e al riparo da elettricità statica. Polvere e ostacoli al passaggio dell’aria causano maggior consumo di energia da parte del server, e portano a premature avarie dei componenti.

Controllare hard disk locali e registro eventi

Altro aspetto chiave da verificare è l’integrità degli hard disk locali, i cui problemi influenzano seriamente prestazioni e stabilità, spesso portando a prematuri guasti dell’unità. Negli hard disk magnetici i problemi comuni includono settori danneggiati e frammentazione del disco. Tra gli strumenti disponibili, l’utilità CHKDSK (Check Disk) permette di verificare l’integrità del supporto, tentando di recuperare ogni settore danneggiato. La frammentazione, invece, è in grado di rallentare un disco del server, causando guasti. In questi casi, una utility come Optimize-Volume, disponibile in Windows Server 2012, organizza ciascun cluster in maniera contigua sul disco, correggendo il problema.
La checklist della manutenzione del server deve comprendere anche un’attenta analisi del registro eventi, per individuare eventuali problemi di minor entità che però possono rivelare difetti cronici o ricorrenti. Occorre, ad esempio, controllare la configurazione del sistema di segnalazione allarmi, verificare che i destinatari degli alert siano corretti e, in caso di cambiamenti del personale tecnico, aggiornare il sistema di reporting.

Verificare patch e aggiornamenti e registrare le modifiche

Nessun software in produzione dovrebbe essere in grado di aggiornarsi in automatico, poiché deve essere sempre l’amministratore del sistema a stabilire se determinate patch o upgrade sono davvero necessari. Infatti, talvolta, questi ultimi possono creare più problemi di quelli che risolvono sullo specifico server o stack software. E questo, occorre aggiungere, è un rischio che tende a crescere, soprattutto con l’avvento delle metodologie DevOps, che si fondano su aggiornamenti piccoli e più frequenti.
Un’ultima raccomandazione, una volta completata la checklist, è bene registrare tutti i cambiamenti (hardware, software, configurazione) attuati nel server, in modo che le informazioni restino a disposizione dello staff IT. Una verifica va fatta anche sulla ‘security posture’ (impostazioni firewall, IDS/IPS, versioni anti-malware) del sistema. In aggiunta, una volta che il server è di nuovo online, non va nemmeno trascurata la verifica, ed eventuale aggiornamento, delle sue impostazioni di backup e disaster recovery.

Articolo Originale: ZeroUNO

Initial Network Setup with UBUNTU Server

How do I change the hostname without a restart?

sudo hostname your-new-name

Assigning a static IP to Ubuntu Server

vi /etc/network/interfaces


auto eth0
 iface eth0 inet static


How to disable IPv6 in Ubuntu?

vi /etc/sysctl.conf

insert the following lines at the end:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

Linux Proxy Server Settings – Set Proxy For Command Line

env | grep -i proxy

check the file :

cat /etc/apt/apt.conf
cat /etc/environment

To Modify contents of file (remove everything from apt.conf for no proxy and only proxy sentences from environment)!

sudo nano /etc/apt/apt.conf
sudo nano /etc/environment
Acquire::http::Proxy "";

Manually edit DNS in Ubuntu

sudo nano /etc/resolvconf/resolv.conf.d/base

Add your DNS to the file :


Update resolv configuration:

sudo resolvconf -u

Setting up NTP on Ubuntu

sudo apt-get install ntp ntpdate

sudo nano /etc/ntp.conf

server myserverdnsname1 or IP
server myserverdnsname2 or IP
server myserverdnsname3 or IP

sudo service ntp start

sudo ntpd -gq

watch ntpq -cpe -cas

Grab you Ubuntu server HERE

Error message when you add a user to a local computer


When you use a Microsoft Windows Server domain controller to join a Microsoft Windows based client computer to a domain, you may receive an error message that resembles the following on the client computer:

The following error occurred attempting to join the domain “”: Not enough storage is available to complete this operation.

Additionally, the following Warning message may be logged in the System log on the client computer.


This problem occurs because the Kerberos token that is generated during authentication is more than the fixed maximum size. In the original release version of Microsoft Windows 2000, the default value of the MaxTokenSize registry entry was 8,000 bytes. In Windows 2000 with Service Pack 2 (SP2) and in later versions of Windows, the default value of the MaxTokenSize registry entry is 12,000 bytes.

For example, if a user is a member of a group either directly or by membership in another group, the security ID (SID) for that group is added to the user’s token. For a SID to be added to the user’s token, the SID information must be communicated by using the Kerberos token. If the required SID information exceeds the size of the token, authentication is unsuccessful.


To resolve this problem, increase the Kerberos token size. To do this, follow these steps on the client computer that logs the Kerberos event.

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate and then click the following registry subkey:


    Note If the Parameters key is not present, create the key. To do this, follow these steps:

    a) Locate and then click the following registry subkey:


    b) On the Edit menu, point to New, and then click Key.

    c) Type Parameters, and then press ENTER.

  3. On the Edit menu, point to New, and then click DWORD Value.
  4. Type MaxTokenSize, and then press ENTER.
  5. On the Edit menu, click Modify.
  6. In the Base area, click Decimal, type 65535 in the Value data box, and then click OK.
  7. Exit Registry Editor.
  8. Restart the computer.

Related Article: Article ID 935744