If you have decided to install Zabbix from the source, you will need to obtain the source, configure it, and compile it. After the daemons are put in place, the frontend will have to be set up manually as well.

At first, we will only set up the Zabbix server and agent, both running on the same system. We will set up additional components later during the course of this book.

Now, we should get to compiling the various components of Zabbix, so make sure to install the minimum required packages to get Zabbix working with MySQL. Here they are:

• GCC
• Automake
• MariaDB (or any compatible MySQL DB)

Depending on your distribution and the desired functionality, you might also need some or all of the following packages:

• zlib-devel
• mariadb-devel (for MySQL support)
• glibc-devel
• curl-devel (for web monitoring)
• libidn-devel (curl-devel might depend on it)
• openssl-devel (curl-devel might depend on it)
• net-snmp-devel (for SNMP support)
• popt-devel (net-snmp-devel might depend on it)
• rpm-devel (net-snmp-devel might depend on it)
• OpenIPMI-devel (for IPMI support)
• libssh2-devel (for direct SSH checks)
• libxm2-devel (for VMware monitoring)
• unixODBC-devel (for database monitoring)
• Java SDK (for Java gateway/JMX checks)

There are several ways of downloading the source code of Zabbix. You can get it from a Subversion (SVN) repository, which will be discussed in Appendix B, Being part of the Community; however, for this installation procedure, I suggest you download version 4.0.0 from the Zabbix home page, https://www.zabbix.com/. While it should be possible to use the latest stable version, using 4.0.0 will allow you to follow instructions more closely. Go to the Download section and grab the compressed source package. Usually, only the latest stable version is available on the download page, so you might have to browse the source archives, but do not take a development or beta version, which might be available.

To make further references easy, I suggested you choose a directory to work in, for example, ~/zabbix (~ being your home directory). Download the archive into this directory.

Once the archive has finished downloading, open a Terminal and extract it:

$ cd ~/zabbix; tar -zxvf zabbix-4.0.0.tar.gz

I suggest you install the prerequisites and compile Zabbix with external functionality right away so that you don't have to recompile as we progress.

For the purpose of this book, we will compile Zabbix with server, agent, MySQL, CURL, SNMP, SSH, ODBC, XML (VMware), and IPMI support.

To continue, enter the following in the Terminal:

$ cd zabbix-4.0.0
$ ./configure --enable-server --with-mysql --with-net-snmp --with-libcurl --with-openipmi --enable-agent --with-libxml2 --with-unixodbc --with-ssh2 --with-openssl

In the end, a summary of the compiled components will be printed. Verify that you have the following enabled:

 Enable server:         yes
 Server details:
 With database:         MySQL
 WEB Monitoring:        CURL
 SNMP:                  yes
 IPMI:                  yes
 SSH:                   yes
 TLS:                   OpenSSL
 ODBC:                  yes
 Enable agent:          yes  

If the configuration completes successfully, it's all good. If it fails, check the error messages printed in the console and verify that all prerequisites have been installed. A file named config.log might provide more detail about the errors. If you can't find out what's wrong, check Appendix A, Troubleshooting, which lists some common compilation problems.

To actually compile Zabbix, issue the following command:

$ make

You can grab a cup of tea, but don't expect to have much time—Zabbix compilation doesn't take too long; even an old 350-MHz Pentium II compiles it in approximately five minutes. On a modern machine, give it less than a minute. After the make process has finished, check the last lines for any error messages. If there are none, congratulations—you have successfully compiled Zabbix!

Now, we should install it. I suggest you create proper packages, but that will require some effort and will be distribution dependent. Another option is to run make install. This will place the files in the filesystem but will not register Zabbix as an installed package—removing and upgrading such software is harder.

If you have experience with creating distribution packages, do so—it is a better approach. If this is just a test installation, run the following:

# make install

But remember that test installations have a tendency of becoming production installations later—it might be a good idea to do things properly from the very beginning.

Depending on the method of installation, you might get Zabbix binaries and configuration files using either a dash (minus) or an underscore, as in the following:

• zabbix_server versus zabbix-server
• zabbix_agentd versus zabbix-agentd
• zabbix_server.conf versus zabbix-server.conf

While Zabbix itself uses an underscore, many distributions will replace it with a dash to follow their own guidelines. There is no functional difference; you just have to keep in mind the character that your installation uses. In this book, we will reference binaries and files using an underscore.

After compilation or installation from the package, we have to configure some basic parameters for the server and agent. Default configuration files are provided with Zabbix. The location of these files will depend on the installation method you chose:

• Source installation: /usr/local/etc
• RHEL/CentOS/Debian/Ubuntu package installation: /etc

On other distributions, the files might be located in a different directory. In this book, we will reference binaries and configuration files using relative names, except in situations where the absolute path is recommended or required.

To configure the Zabbix agent, we don't have to do anything. The default configuration will do just fine for now. That was easy, right?

For the server, we will need to make some changes. Open the zabbix_server.conf file in your favorite editor (you will need to edit it as the root user) and find the following entries in the file:

• DBName
• DBUser
• DBPassword

DBName should be zabbix by default; we can leave it as is. DBUser is set to root, and we don't like that, so let's change it to zabbix. For DBPassword, choose any password. You won't have to remember it, so be creative.

In UNIX-like solutions, a hash character or # at the beginning of a line usually means that the line is commented out. Make sure not to start lines you want to have an effect with a hash.

For the Zabbix server to store the data, we need a database. As we have installed our Zabbix server with MySQL support, we need to install the MySQL server first. You will see that we install MariaDB instead of MySQL. This is because now most distributions prefer to deliver MariaDB instead of MySQL as MySQL was acquired by Oracle and people were afraid Oracle would change the license. Zabbix also has support for other databases, such as Oracle, IBM DB2, and PostgreSQL. The reason we use MySQL is because it's the most widely known and also the preferred database by Zabbix SIA. This does not mean other solutions are worse or less tested. It's just because the best knowledge in Zabbix SIA is with MySQL and not PostgreSQL or any other supported database:

CentOS/Red Hat 7
# yum install mariadb-server

Ubuntu/Debian
# apt install mysql-server

We also have to create a database. Start a MySQL client to connect to the MySQL Server:

CentOS/Red Hat 7  Start the database first and set a DB root password
# systemctl start mariadb; systemctl enable mariadb    
# mysql_secure_installation 
# mysql -u root -p

Ubuntu/Debian Start the database first and set a DB root password
# mysql_secure_installation
# mysql -u root -p

Using mysql_secure_installation is easy to set a root password for your database. It also allows you to configure MySQL/MariaDB easy in a more secure way.

Enter the root user's password for MySQL (you will have set this during the installation of MariaDB or the password could be something that is the default for your distribution). If you do not know the password, you can try omitting -p. This switch will tell the client to attempt to connect without a password (or with an empty password).

If you are using MySQL Community Edition from the packages and the version is 5.7.6 or higher, it generates a random password that is stored in logfiles. Check out the MySQL documentation at http://dev.mysql.com/doc/refman/5.7/en/linux-installation-rpm.html for more details.

Now, let's create the database. Add the user through which Zabbix will connect to the database and grant the necessary permissions to this user:

mysql> create database zabbix character set utf8 collate utf8_bin;
Query OK, 1 row affected (0.01 sec)
mysql> grant all privileges on zabbix.* to 'zabbix'@'localhost' identified by 'mycreativepassword';
Query OK, 0 rows affected (0.12 sec)  

Use the password you set in the zabbix_server.conf file instead of mycreativepassword.

Quit the MySQL client by entering the following command:

mysql> quit

Let's populate the newly created database with a Zabbix schema and initial data. The following commands refer to the files as they appear in the Zabbix source. When installing from packages, this file could be located in a directory such as /usr/share/doc/zabbix-server-mysql-4.0.0/ or /usr/share/zabbix-server-mysql:

# zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -uzabbix -p zabbix

This processes should complete without any messages. If there are any errors, review the messages, fix the issue, and retry the failed operation. If the import is interrupted in the middle of the process, you might have to clear the database—the easiest way to do this is to delete the database by typing this:

mysql> drop database zabbix;
Query OK, 0 rows affected (0.00 sec)

By now, we should have the Zabbix server and agent installed and ready to start.

You should never start the Zabbix server or agent as root, which is common sense for most daemon processes. If you installed Zabbix from distribution packages, system users should have been created already—if not, let's create a new user to run these processes. You can use tools provided by your distribution or use the most widely available command, useradd, which we need to execute as root:

# useradd -m -s /bin/bash zabbix

For production systems, consider using different user accounts for the Zabbix server and agent. Otherwise, users with configuration rights will be able to discover Zabbix database credentials by instructing the agent to read the server configuration file. Some distribution packages, such as the EPEL and OpenSUSE ones, already use a separate user account called zabbixsrv or zabbixs by default.

This will create a user named zabbix with a home directory in the default location, /home/zabbix usually, and a shell at /bin/bash.

If you installed from source, let's try the direct approach—running the binaries. The location of the binaries will depend on the chosen method of installation. Installing from the source without any extra parameters will place the agent and server binaries in /usr/local/sbin; distribution packages are likely to place them in /usr/sbin. Assuming they are in your path, you can determine where the binaries are by running this:

# which zabbix_server

This will show something similar to the following:

/usr/sbin/zabbix_server

Alternatively, the whereis command can also list configuration and other related files:

# whereis zabbix_server

This would likely list the binary, configuration file, and main page:

zabbix_server: /usr/sbin/zabbix_server /usr/local/etc/zabbix_server.conf /usr/share/man/man3/zabbix_server

Once you know the exact location of the binaries, execute the following as the root user:

# <path>/zabbix_agentd

This will start the Zabbix agent daemon, which should start up silently and daemonize. If the command produces errors, resolve them before proceeding. If it succeeds, continue by starting the Zabbix server:

# <path>/zabbix_server

If you installed from the packages, execute this:

# systemctl start zabbix-agent    
# systemctl start zabbix-server    

Feel free to experiment with other parameters, such as stop and restart—it should be obvious what these two do.

You can verify whether services are running with the status parameter. For a service that is not running, you would get the following:

# systemctl status zabbix-server

A running service would yield the following:

zabbix-server.service - Zabbix Server
Loaded: loaded (/usr/lib/systemd/system/zabbix-server.service; disabled; vendor preset: disabled)
Active: active (running) since Sun 2018-08-05 12:57:13 CEST; 1min 39s ago
Process: 1972 ExecStart=/usr/sbin/zabbix_server -c $CONFFILE (code=exited, status=0/SUCCESS)
Main PID: 1974 (zabbix_server)
CGroup: /system.slice/zabbix-server.service
├─1974 /usr/sbin/zabbix_server -c /etc/zabbix/zabbix_server.conf
├─1979 /usr/sbin/zabbix_server: configuration syncer [synced
configuration in 0.008373 sec, idle 60 sec]
....

While it's nice to have Zabbix processes running, it's hardly a process one expects to do manually upon each system boot, so the server and agent should be added to your system's startup sequence. This is fairly distribution specific, so all possible variations can't be discussed here. With RHEL or CentOS, a command such as this should help:

# systemctl enable zabbix-agent
# systemctl enable zabbix-server

This will add both services to be started at boot time.

A nice summary of Systemd can be found at https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet.

While the systemd method is a nice way to check a service's state for some distributions, it's not available everywhere and isn't always enough. Sometimes, you might want to use these other methods to check whether the Zabbix server or agent is running:

• Checking running processes: The most common method to check whether a particular process is running is by looking at the running processes. You can verify whether the Zabbix agent daemon processes are actually running using this command:

    $ ps -C zabbix_agentd

• Output from the ss command: Sometimes, an agent daemon might start up but fail to bind to the port or the port might be used by some other process. You can verify whether some other process is listening on the Zabbix port or whether the Zabbix agent daemon is listening on the correct port by issuing this command:

    # ss -tlnp

Process names won't be printed for other users' processes unless you are the root user. In the output, look for a line similar to this:

State  Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN  0     128    *:10050            *:* users:(("zabbix_agentd",pid=1965,fd=4),("zabbix_agentd",pid=1964,fd=4),("zabbix_agentd",pid=1963,fd=4),
...
LISTEN  0     128   *:10051             *:* users:(("zabbix_server",pid=2011,fd=5),("zabbix_server",pid=2010,fd=5),("zabbix_server",pid=2009,fd=5),
...
LISTEN  0     50   *:3306               *:* users:(("mysqld",pid=1832,fd=14))
LISTEN 0 128 *:22 *:* users:(("sshd",pid=1033,fd=3))
LISTEN  0     100   127.0.0.1:25        *:* users:(("master",pid=1278,fd=13))
LISTEN 0 128 :::10050 :::* users:(("zabbix_agentd",pid=1965,fd=5),
...
LISTEN  0     128   :::10051            :::* users:(("zabbix_server",pid=2011,fd=6),("zabbix_server",pid=2010,fd=6),("zabbix_server",pid=2009,fd=6),
...
LISTEN  0     128    :::22              :::* users:(("sshd",pid=1033,fd=4))
LISTEN 0 100 ::1:25 :::* users:(("master",pid=1278,fd=14))  

This indicates that the zabbix_agentd process is running and listening on all addresses on port 10050—just what we need.

• Telnetting to the port: Even when a service starts up and successfully binds to a port, there might be some connectivity issues, perhaps due to a local firewall. To quickly check connectivity on the desired port, you can try this:

    $ telnet localhost 10050

This command should open a connection to the Zabbix agent daemon, and the daemon should not close the connection immediately. All of this applies to the Zabbix server as well, except that it uses a different port by default: 10051.

On CentOS, it is possible that telnet will not work—that's because we have to install it first. This can be done by running the following:

    # yum install telnet

Now that we have the Zabbix server and agent either compiled and installed or installed from the distribution packages, and both daemons are running, you probably have a feeling that something's missing. We have only configured some low-level behavior, so where's the meat?

That's what the frontend is for. While, in theory, Zabbix can have multiple frontends, the only one with full functionality so far is the Zabbix web frontend, which is written in PHP. We have to set it up to configure Zabbix and get to those nice graphs everybody likes.

Of course, being a Zabbix web frontend, it will require a platform to run on—a web server with a PHP environment. We will need the following installed:

• A web server that is supported by PHP; Apache is the most common choice
• PHP version 5.4.0 or higher

In the next code block, we will show you how to install the webserver on CentOS and Debian:

On CentOS
# yum install httpd php php-ldap php-mysql
# systemctl enable httpd
# systemct start httpd

On Debian/Ubuntu
# apt install apache2 php php7.2-cli php7.2-mysql php7.2-common php7.2-curl php7.2-json php7.2-cgi libapache2-mod-php7.2 php7.2 php7.2-ldap

It is easiest to install these from the distribution packages as it will take care of all of the dependencies we need. Just make sure you install the correct PHP connector for your database—in our case, this is php-mysql. If you would like to make a connection to your AD/LDAP, you also need to make sure that php-ldap is installed.

Once you have all of these installed, it's time to set up the frontend. Again, there's a choice of using packages or installing from source. If you decided to go with the packages, you should have the frontend installed already and should be able to proceed with the configuration wizard section explained next. If you went with the source installation, it's just a simple copying of some files.

First, you have to decide where the frontend code has to go. Most distributions that package web servers use /srv/www/htdocs or /var/www. If you compiled the Apache web server from the source, it would be /usr/local/apache2/htdocs (unless you manually changed the prefix or installed an older Apache version). We will place the frontend in a simple subdirectory, zabbix.

Assuming you have Apache distribution packages installed with the web root directory at /srv/www/htdocs, placing the frontend where it is needed is as simple as executing the following as the root user:

# cp -r frontends/php /srv/www/htdocs/zabbix

The last thing we need to do is open our firewall so that our browser can connect on the web server port of our server:

CentOS/Red Hat
# firewall-cmd --add-service=http --permanent
# firewall-cmd --reload

Debian / Ubuntu
(standard there is no firewall installed you could use iptables or ufw or similar solution)
 # apt install firewalld