One place for hosting & domains

      Securely

      Securely Storing MySQL Credentials using mysql_config_editor


      MySQL includes the
      mysql_config_editor utility, which is used to store your MySQL credentials inside of an encrypted file in your home directory: ~/.mylogin.cnf. The file is obfuscated and cannot be viewed in plaintext unless running the
      print command. Any stored passwords are never made visible. This arrangement adds a layer of security and convenience when connecting to your database using command-line tools like mysql or
      mysqldump.

      Each set of credentials is stored in option groups called login paths. You can create your own custom login paths, which you can then specify when connecting to your database.

      Create or Edit Credentials

      Run the set command to store your credentials and database connection details. Replace [name] with whatever name you wish to use for your custom login path, [username] with your MySQL username, and [host] with the remote host IP or domain (if you are connecting to a remote database). You can also specify the port (--port) and socket (-socket) if needed.

      mysql_config_editor set --login-path=[name] --user=[username] --host=[host] --password --warn

      Note

      You can also use special login path names, which are used by default in certain commands without needing to specify it. These special login paths include client and mysql for the mysql command and mysqldump for the mysqldump command.

      View Stored Credentials

      Run the print command to view all login paths (--all). You can also view a specific login path by adding the --login-path=[name] option, replacing [name] with the name of your login path.

      mysql_config_editor print --all

      In the example output below, there is a single login path called example-path that is storing the user (admin), the password (which cannot be viewed), and the host.

      [example-path]
user = "admin"
password = *****
host = "db-server.example.com"

      Remove Stored Credentials

      If you don’t want your system user to be able to access the database, it’s recommended that you delete any stored credentials. In addition to being able to remove the entire login path, you can also remove an individual option if needed.

      To remove the entire login path, run the following command. Replace [name] with the name of your login path.

      mysql_config_editor remove --login-path=[name]

      To only remove a specific option from the login path, append the option you wish to remove. For example, the command below removes the --host option from the stored login path.

      mysql_config_editor remove --login-path=[name] --host

      Connecting to a Database Using Stored Credentials

      To specify a set of stored credentials in the mysql or mysqldump command, use the --login-path=[] (or -G []) option as show below. Replace [name] with the name of your login path.

      mysqldump --login-path=[name] exampledatabase > backup.sql

      More Information

      You may wish to consult the following resources for additional information
      on this topic. While these are provided in the hope that they will be
      useful, please note that we cannot vouch for the accuracy or timeliness of
      externally hosted materials.



      Source link

      How To Securely Manage Secrets with HashiCorp Vault on Ubuntu 20.04


      Introduction

      Vault is an open-source tool that provides a secure, reliable way to store and distribute secrets like API keys, access tokens, and passwords. Software like Vault can be critically important when deploying applications that require the use of secrets or sensitive data.

      In this tutorial, you will:

      • Install Vault and configure it as a system service
      • Initialize an encrypted on-disk data store
      • Store and retrieve a sensitive value securely over TLS

      With some additional policies in place, you’ll be able to use Vault to securely manage sensitive data for your various applications and tools.

      As with any service that manages sensitive information, you should consider reading additional documentation regarding Vault’s deployment best practices before using it in a production-like environment. For example, Vault’s production hardening guide covers topics such as policies, root tokens, and auditing.

      Prerequisites

      Before you begin this guide you’ll need the following:

      Note: Vault generates a self-signed TLS certificate when you install the package for the first time. If you do not have a domain name or TLS certificate to use with Vault but would like to follow the steps in this tutorial, you can skip TLS verification by adding the -tls-skip-verify flag to the commands in this tutorial, or by defining the VAULT_SKIP_VERIFY environment variable.

      This option is only suitable for experimenting with Vault and should not be used in a production environment.

      Step 1 — Installing Vault

      HashiCorp provides Vault as a typical Debian/Ubuntu package, so we’ll go through the normal steps of adding their package repository to our server’s list of package sources:

      First, add Hashicorp’s GPG key to your package manager, so that your system trusts their package repositories:

      • curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -

      Then add the repository itself to your list of package sources, so it’ll be checked for regular updates:

      • sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"

      Then install the package:

      You can now use the vault command. Try checking Vault’s version to make sure it works.

      Output
      Vault v1.8.5 (647eccfe0bd5817bdd8628f3c3171402dfc8a8fc)

      The Vault executable is installed on your server, so the next step is to configure it to run as a system service.

      Step 2 — Configuring Vault

      Installing the Vault package automatically creates a vaultvault user on your system and sets up a system service for running Vault in the background. We need to make a couple of changes to its default configuration in order to use the HTTPS certificates generated by Let’s Encrypt.

      Note: In this tutorial and by default, Vault uses the filesystem backend to store encrypted secrets on the local filesystem at /opt/vault. This is suitable for local or single-server deployments that do not need to be replicated. Other Vault backends, such as the Consul backend, will store encrypted secrets at rest within a distributed key/value store.

      Vault’s default configuration is stored in /etc/vault.d/vault.hcl. You’ll use this file to control various options in Vault, such as where encrypted secrets are stored.

      Open vault.hcl using nano or your favorite text editor.

      • sudo nano /etc/vault.d/vault.hcl

      Find the listener "tcp" section of the file that contains this block. If you are using nano, you can press Ctrl+W then enter listener “tcp” to find that line directly:

      /etc/vault.hcl

      listener "tcp" {
  address       = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/tls.crt"
  tls_key_file  = "/opt/vault/tls/tls.key"
...
}

      Edit the tls_cert_file and tls_key_file lines to point to your Let’s Encrypt certificate and key files. Don’t forget to substitute in your own domain name in place of the highlighted your_domain part of each line.

      /etc/vault.hcl

      listener "tcp" {
...
  tls_cert_file = "/etc/letsencrypt/live/your_domain/fullchain.pem"
  tls_key_file = "/etc/letsencrypt/live/your_domain/privkey.pem"
}

      Note: You should also change address = "0.0.0.0:8200" to address = “127.0.0.1:8200” to prevent external connections to this server for now. 127.0.0.1 is a reserved address for localhost only. This is to ensure that the service is not exposed to the public internet before it has been properly secured. You can update this later, but for now, this configuration change will let us use the vault command and correctly resolve the HTTPS-secured domain name.

      Save and close the file. If you are using nano, press Ctrl+X, then Y when prompted to save the file, and Enter to confirm.

      Next, the vault system user also needs permission to read these certificates. By default, these certificates and private keys are only accessible by root. To make these available securely, we’ll create a special group called pki to access these files. We will create the group and then add the vault user to it.

      Update the permissions on the two directories in the /etc/letsencrypt directory to allow members of the pki group to read the contents.

      • sudo chgrp pki /etc/letsencrypt/archive

      • sudo chgrp pki /etc/letsencrypt/live

      • sudo chmod g+rx /etc/letsencrypt/archive

      • sudo chmod g+rx /etc/letsencrypt/live

      Then add the vault user to the pki group. This will grant Vault access to the certificates so that it can serve requests securely over HTTPS.

      • sudo usermod -a -G pki vault

      As a final step for convenience, add a rule in /etc/hosts to direct requests to Vault to localhost.

      Replace your_domain in the following command with the domain you acquired the Let’s Encrypt certificate for:

      • echo 127.0.0.1 your_domain.com | sudo tee -a /etc/hosts

      This command appends the line 127.0.0.1 your_domain.com to /etc/hosts so that any HTTP requests that you make on your Vault server to your_domain.com ignore DNS and are sent to localhost directly.

      With the Vault service set up and the Vault configuration file complete, we’re now ready to start Vault and initialize the secret store.

      Step 3 — Initializing Vault

      When you first start Vault, it will be uninitialized, which means that it isn’t ready to receive and store data. In this section of the tutorial, you will start the Vault server, and then initialize it with a set of secret keys that will be used to unseal (open) Vault’s secret stores.

      The first time you start Vault, the backend that actually stores the encrypted secrets is uninitialized, too. Start the Vault system service to initialize the backend and start running Vault itself.

      • sudo systemctl start vault.service

      You can run a quick check to confirm the service has started successfully.

      • sudo systemctl status vault.service

      You should receive output similar to the following:

      Output
      ● vault.service - "HashiCorp Vault - A tool for managing secrets"
     Loaded: loaded (/lib/systemd/system/vault.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2021-11-16 21:55:13 UTC; 22s ago
       Docs: https://www.vaultproject.io/docs/
   Main PID: 104207 (vault)
      Tasks: 7 (limit: 1137)
     Memory: 179.3M
     CGroup: /system.slice/vault.service
             └─104207 /usr/bin/vault server -config=/etc/vault.d/vault.hcl

      The output of that command should include several pieces of information about the running service, such as its process ID and resource usage. Ensure that the following line is included in the output, which indicates that the service is running correctly.

      Output
      . . .
Active: active (running)
. . .

      If the service is not active, take a look at the accompanying log lines at the end of the command’s output to see Vault’s output, which can help pinpoint any issues.

      Next, we’ll set an environment variable to tell the vault command how to connect to the Vault server. In Step 1 you configured Vault to only listen on the local loopback interface, so set the VAULT_ADDR environment variable to the local HTTPS endpoint.

      • export VAULT_ADDR=https://your_domain:8200

      The vault command can now communicate with the daemon. Note that defining the actual hostname instead of simply localhost or 127.0.0.1 is necessary to properly validate the HTTPS certificate.

      Confirm that the vault server is in an uninitialized state by checking its status.

      The server should return some output so that you can tell it is working but not yet initialized.

      Key Value
--- -----
Seal Type shamir
Initialized false
Sealed true
Total Shares 0
Threshold 0
Unseal Progress 0/0
Unseal Nonce n/a
Version 1.8.5
Storage Type file
HA Enabled false

      There are two pieces of information that Vault will expose at initialization time that will not be available at any other point:

      • Initial root token. This is equivalent to root permissions to your Vault deployment, which allows the management of all Vault policies, mounts, and secrets.
      • Unseal keys. These are used to unseal Vault when the daemon starts, which permits the Vault daemon to decrypt the backend secret store.

      More specifically, Vault’s unsealing process decrypts the backend using a key formed by key shares. When you first initialize Vault, you may choose how many unseal keys to create and how many are necessary at unseal time to successfully unseal Vault. To learn more about Vault’s sealing mechanism, you can refer to the Vault documentation.

      A typical configuration for the unseal parameters would be to create three keys and require at least two of those keys at unseal time. This permits the important key shares to be separated and stored in distinct locations to ensure that compromising one is not sufficient to unseal Vault.

      In other words, whenever Vault is started, at least two unseal keys will be required in order to make the service become available and ready to use. While sealed, the files that store the actual secret values will remain encrypted and inaccessible.

      Initialize Vault with three unseal keys using the -key-shares=3 option, and require at least two keys to unseal the vault with the -key-threshold=2 flag::

      • vault operator init -key-shares=3 -key-threshold=2

      You will receive output like the following:

      Output
      Unseal Key 1: eZcJeydRrqeSMZ1zTN+VVll9TFT2KvJy7VlnxUgtvuz5
Unseal Key 2: ntmqCKq8rgNnKT1YSLCjVmCCZBAA3NwUeqxIyRpYD4Wm
Unseal Key 3: 3FK1+Hsorh4p8/L9mki3VskaEU2eQhLqGOI/pJkTHMbx

Initial Root Token: s.hY0ieybfDqCadz7JpL88uO3x

      Be sure to save each unseal token and the initial root token in a secure way. You will not be able to retrieve these keys and root token again. For example, one option would be to store one unseal key in a password manager, another on a USB drive, and another in a GPG-encrypted file.

      If you examine vault status again, the Initialized status will now be set to true, and the Total Shares and Threshold values will reflect the number of key shards and minimum number of keys that you will need to unseal the vault.

      Output
      . . .
Initialized     true
Sealed          true
Total Shares    3
Threshold       2
Unseal Progress 0/2
. . .

      Note that the Unseal Progess line shows the value 0/2. Begin unsealing Vault using your newly created unseal tokens. Run the vault operator unseal command and input any of your keys when prompted:

      The command will ask for an unseal token:

      Output
      Key (will be hidden):

      After entering it, the output from the command will indicate that the unsealing is in progress, but still requires one more unsealing key before Vault is ready for use.

      Output
      Key                Value
---                -----
Seal Type          shamir
Initialized        true
Sealed             true
Total Shares       3
Threshold          2
Unseal Progress    1/2
Unseal Nonce       0f3a328b-e0c6-6294-d6a2-56da49271dff
Version            1.8.5
Storage Type       file
HA Enabled         false

      Notice how the Unseal Progress 1/2 line has changed in the output. Run the unseal command again.

      And enter a different key than the one you already used:

      Output
      Key (will be hidden):

      The command’s output indicates that the unseal process had completed successfully.

      Output
      Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    3
Threshold       2
Version         1.8.5
Storage Type    file
Cluster Name    vault-cluster-3042c7bc
Cluster ID      c3e9d814-cf2a-2901-f0e4-ebc52d29e5cc
HA Enabled      false

      Vault is now unsealed and ready for use. These unseal steps are necessary whenever Vault is started or restarted.

      However, unsealing is a distinct process from normal interaction with Vault (such as reading and writing values), which are authenticated by tokens. In the next steps, we’ll create the necessary access tokens and policies to store secret values and read/write to specific paths in Vault.

      Step 4 — Reading and Writing Secrets

      There are several [secret backends]](https://www.vaultproject.io/docs/secrets/index.html) that you can use with Vault, but for this example we will use the kv secret backend. This backend stores simple key/value pairs in Vault. However, it is not enabled by default.

      In this section of the tutorial, you will enable the kv secret backend, and then learn how to read and write secrets to it.

      First, save the previously generated root token to a shell variable for ease of use.

      • root_token=your_root_token_here

      Next, while authenticating with the root token, enable the kv backend:

      • VAULT_TOKEN=$root_token vault secrets enable kv

      You will receive output like the following if the command is successful:

      Output
      Success! Enabled the kv secrets engine at: kv/

      You can then verify that it’s been added to your local list of available secrets backends:

      • VAULT_TOKEN=$root_token vault secrets list

      You should receive output like the following:

      Output
      Path          Type         Accessor              Description
----          ----         --------              -----------
cubbyhole/    cubbyhole    cubbyhole_abc1631b    per-token private secret storage
identity/     identity     identity_631fe262     identity store
kv/           kv           kv_4d5855c8           n/a
sys/          system       system_79b13f2f       system endpoints used for control, policy and debugging

      Note the highlighted line that indicates the new kv backend is enabled. Now we can store some data with this backend.

      • VAULT_TOKEN=$root_token vault write kv/message value=mypassword

      In this command, the highlighted kv/ prefix indicates that we are writing to the kv backend mounted at the kv path, and we are storing the key value at the path message with the value mypassword. We used the root token, which has superuser privileges, to write the generic secret.

      Check the secret that you created using the vault read command:

      • VAULT_TOKEN=$root_token vault read kv/message

      You should receive output like the following, with the contents of the secret that you created:

      Output
      Key                 Value
---                 -----
refresh_interval    768h
value               mypassword

      However, creating, reading, and otherwise interacting with Vault using the Root Token only is not secure, scalable in a team setting, and does not allow for fine-grained access control to secrets. In the next section you’ll learn how to define policies and create additional access tokens to restrict how users can interact with Vault.

      Step 5 — Creating an Authorization Policy

      In a real-world scenario, you may store values like API keys or passwords that external tools can consume. Although you may read the secret value again using the root token, it is illustrative to generate a less privileged token with read-only permissions to our single secret.

      In this section of the tutorial you will create a Vault policy that will enforce read-only access to secrets. To create the policy you’ll need to edit a file and then load it into Vault using the vault policy command.

      To get started creating a policy, open a file called policy.hcl using nano or your preferred editor:

      Populate the file with the following Vault policy, which defines read-only access to the secret path::

      policy.hcl

      path "kv/message" {
     capabilities = ["read"]
}

      Save and close the file, then write this policy to Vault. The following command will load the policy.hcl file into Vault and create a policy named message-readonly with the read-only capability

      • VAULT_TOKEN=$root_token vault policy write message-readonly policy.hcl

      Next, create a token that you will use for read-only access to Vault. Add the -policy=”message-readonly” flag to the vault token create command to use the new policy that you created:

      • VAULT_TOKEN=$root_token vault token create -policy="message-readonly"

      The output will look like this:

      Output
      Key                  Value
---                  -----
token                your_token_value
token_accessor       your_token_accessor
token_duration       768h0m0s
token_renewable      true
token_policies       ["default" "message-readonly"]
identity_policies    []
policies             ["default" "message-readonly"]

      Save the highlighted your_token_value value to an environment variable called app_token:

      • app_token=your_token_value

      You can use the value of app_token to access the data stored in the path kv/message (and no other values in Vault).

      • VAULT_TOKEN=$app_token vault read kv/message

      Output
      Key                     Value
---                     -----
refresh_interval        768h0m0s
value                   mypassword

      You can also test that this unprivileged token cannot perform other operations, such as listing secrets in Vault.

      • VAULT_TOKEN=$app_token vault list kv/

      Output
      Error reading kv/: Error making API request.

URL: GET https://your_domain:8200/v1/secret?list=true
Code: 403. Errors:

* 1 error occurred:
    * permission denied

      This verifies that the less-privileged app token cannot perform any destructive actions or access other secret values aside from those explicitly stated in its Vault policy. If you would like to continue using the read-only token, be sure to record it somewhere safe for future use.

      Conclusion

      In this article you installed, configured, and deployed Vault on Ubuntu 20.04. You also created a sharded key to unseal Vault, enabled the kv backend secret store, and defined a read-only policy to limit how a user can interact with Vault secrets.

      Although this tutorial only demonstrated how to use an unprivileged token, the Vault documentation has more examples of additional ways to store and access secrets as well as alternative authentication methods.

      These instructions demonstrated how to deploy and use some of the core features of Vault. Your needs may require other configuration changes and more complex policies. Be sure to read the Vault documentation and make appropriate configuration changes for your needs. Some production-ready changes may include:

      • Generating lesser-privileged tokens for everyday use. The specific policies that these tokens should use depends on your specific use cases, but the example app_token in this tutorial illustrates how you can create limited-privilege tokens and policies.

      • If you are deploying Vault as part of a service that will be used by a team, initialize Vault with unseal keys for each team member. This approach can ensure that Vault’s storage is only decrypted when more than one team member participates in the process.



      Source link

      How To Install and Configure Zabbix to Securely Monitor Remote Servers on Ubuntu 20.04


      Not using Ubuntu 20.04?


      Choose a different version or distribution.

      The author selected the Computer History Museum to receive a donation as part of the Write for DOnations program.

      Introduction

      Zabbix is open-source monitoring software for networks and applications. It offers real-time monitoring of thousands of metrics collected from servers, virtual machines, network devices, and web applications. These metrics can help you determine the current health of your IT infrastructure and detect problems with hardware or software components before customers complain. Useful information is stored in a database so you can analyze data over time and improve the quality of provided services or plan upgrades of your equipment.

      Zabbix uses several options for collecting metrics, including agentless monitoring of user services and client-server architecture. To collect server metrics, it uses a small agent on the monitored client to gather data and send it to the Zabbix server. Zabbix supports encrypted communication between the server and connected clients, so your data is protected while it travels over insecure networks.

      The Zabbix server stores its data in a relational database powered by MySQL or PostgreSQL. You can also store historical data in NoSQL databases like Elasticsearch and TimescaleDB. Zabbix provides a web interface so you can view data and configure system settings.

      In this tutorial, you will configure Zabbix on two Ubuntu 20.04 machines. One will be configured as the Zabbix server, and the other as a client that you’ll monitor. The Zabbix server will use a MySQL database to record monitoring data and use Nginx to serve the web interface.

      Prerequisites

      To follow this tutorial, you will need:

      • Two Ubuntu 20.04 servers set up by following the Initial Server Setup Guide for Ubuntu 20.04, including a non-root user with sudo privileges and a firewall configured with ufw. On one server, you will install Zabbix; this tutorial will refer to this as the Zabbix server. It will monitor your second server; this second server will be referred to as the second Ubuntu server.

      • The server that will run the Zabbix server needs Nginx, MySQL, and PHP installed. Follow Steps 1–3 of our Ubuntu 20.04 LEMP Stack guide to configure those on your Zabbix server.

      • A registered domain name. This tutorial will use your_domain throughout. You can purchase a domain name from Namecheap, get one for free with Freenom, or use the domain registrar of your choice.

      • Both of the following DNS records set up for your Zabbix server. If you are using DigitalOcean, please see our DNS documentation for details on how to add them.

        • An A record with your_domain pointing to your Zabbix server’s public IP address.
        • An A record with www.your_domain pointing to your Zabbix server’s public IP address.

      Additionally, because the Zabbix Server is used to access valuable information about your infrastructure that you would not want unauthorized users to access, it’s important that you keep your server secure by installing a TLS/SSL certificate. This is optional but strongly encouraged. If you would like to secure your server, follow the Let’s Encrypt on Ubuntu 20.04 guide after Step 3 of this tutorial.

      Step 1 — Installing the Zabbix Server

      First, you need to install Zabbix on the server where you installed MySQL, Nginx, and PHP. Log in to this machine as your non-root user:

      • ssh sammy@zabbix_server_ip_address

      Zabbix is available in Ubuntu’s package manager, but it’s outdated, so use the official Zabbix repository to install the latest stable version. Download and install the repository configuration package:

      • wget https://repo.zabbix.com/zabbix/5.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.0-1+focal_all.deb

      • sudo dpkg -i zabbix-release_5.0-1+focal_all.deb

      You will see the following output:

      Output
      Selecting previously unselected package zabbix-release.
(Reading database ... 64058 files and directories currently installed.)
Preparing to unpack zabbix-release_5.0-1+focal_all.deb ...
Unpacking zabbix-release (1:5.0-1+focal) ...
Setting up zabbix-release (1:5.0-1+focal) ...

      Update the package index so the new repository is included:

      Then install the Zabbix server and web frontend with MySQL database support:

      • sudo apt install zabbix-server-mysql zabbix-frontend-php

      Also, install the Zabbix agent, which will let you collect data about the Zabbix server status itself.

      • sudo apt install zabbix-agent

      Before you can use Zabbix, you have to set up a database to hold the data that the Zabbix server will collect from its agents. You can do this in the next step.

      Step 2 — Configuring the MySQL Database for Zabbix

      You need to create a new MySQL database and populate it with some basic information in order to make it suitable for Zabbix. You’ll also create a specific user for this database so Zabbix isn’t logging in to MySQL with the root account.

      Log in to MySQL as the root user:

      Create the Zabbix database with UTF-8 character support:

      • create database zabbix character set utf8 collate utf8_bin;

      Then create a user that the Zabbix server will use, give it access to the new database, and set the password for the user:

      • create user zabbix@localhost identified by 'your_zabbix_mysql_password';

      • grant all privileges on zabbix.* to zabbix@localhost;

      That takes care of the user and the database. Exit out of the database console.

      Next you have to import the initial schema and data. The Zabbix installation provided you with a file that sets this up.

      Run the following command to set up the schema and import the data into the zabbix database. Use zcat since the data in the file is compressed:

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

      Enter the password for the zabbix MySQL user that you configured when prompted.

      This command may take a minute or two to execute. If you see the error ERROR 1045 (28000): Access denied for userzabbix@'localhost' (using password: YES) then make sure you used the right password for the zabbix user.

      In order for the Zabbix server to use this database, you need to set the database password in the Zabbix server configuration file. Open the configuration file in your preferred text editor. This tutorial will use nano:

      • sudo nano /etc/zabbix/zabbix_server.conf

      Look for the following section of the file:

      /etc/zabbix/zabbix_server.conf

      ...
### Option: DBPassword                           
#       Database password. Ignored for SQLite.   
#       Comment this line if no password is used.
#                                                
# Mandatory: no                                  
# Default:                                       
# DBPassword=
...

      These comments in the file explain how to connect to the database. You need to set the DBPassword value in the file to the password for your database user. Add this line after those comments to configure the database:

      /etc/zabbix/zabbix_server.conf

      ...
DBPassword=your_zabbix_mysql_password
...

      Save and close zabbix_server.conf by pressing CTRL+X, followed by Y and then ENTER if you’re using nano.

      You’ve now configured the Zabbix server to connect to the database. Next, you will configure the Nginx web server to serve the Zabbix frontend.

      Step 3 — Configuring Nginx for Zabbix

      To configure Nginx automatically, install the automatic configuration package:

      • sudo apt install zabbix-nginx-conf

      As a result, you will get the configuration file /etc/zabbix/nginx.conf, as well as a link to it in the Nginx configuration directory /etc/nginx/conf.d/zabbix.conf.

      Next, you need to make changes to this file. Open the configuration file:

      • sudo nano /etc/zabbix/nginx.conf

      The file contains an automatically generated Nginx server block configuration. It contains two lines that determine the server name and what port it is listening on:

      /etc/zabbix/nginx.conf

      server {
#        listen          80;
#        server_name     example.com;
...

      Uncomment the two lines, and replace example.com with your domain name. Your settings will look like this:

      /etc/zabbix/nginx.conf

      server {
        listen          80;
        server_name     your_domain;
...

      Save and close the file. Next, test to make sure that there are no syntax errors in any of your Nginx files and reload the configuration:

      • sudo nginx -t

      • sudo nginx -s reload

      Now that Nginx is set up to serve the Zabbix frontend, you will make some modifications to your PHP setup in order for the Zabbix web interface to work properly.

      Note: As mentioned in the Prerequisites section, it is recommended that you enable SSL/TLS on your server. If you would like to do this, follow our Ubuntu 20.04 Let’s Encrypt tutorial before you move on to Step 4 to obtain a free SSL certificate for Nginx. This process will automatically detect your Zabbix server block and configure it for HTTPS. After obtaining your SSL/TLS certificates, you can come back and complete this tutorial.

      Step 4 — Configuring PHP for Zabbix

      The Zabbix web interface is written in PHP and requires some special PHP server settings. The Zabbix installation process created a PHP-FPM configuration file that contains these settings. It is located in the directory /etc/zabbix and is loaded automatically by PHP-FPM. You need to make a small change to this file, so open it up with the following:

      • sudo nano /etc/zabbix/php-fpm.conf

      The file contains PHP settings that meet the necessary requirements for the Zabbix web interface. However, the timezone setting is commented out by default. To make sure that Zabbix uses the correct time, you need to set the appropriate timezone:

      /etc/zabbix/php-fpm.conf

      ...
php_value[max_execution_time] = 300
php_value[memory_limit] = 128M
php_value[post_max_size] = 16M
php_value[upload_max_filesize] = 2M
php_value[max_input_time] = 300
php_value[max_input_vars] = 10000
; php_value[date.timezone] = Europe/Riga

      Uncomment the timezone line highlighted in the preceding code block and change it to your timezone. You can use this list of supported time zones to find the right one for you. Then save and close the file.

      Now restart PHP-FPM to apply these new settings:

      • sudo systemctl restart php7.4-fpm.service

      You can now start the Zabbix server:

      • sudo systemctl start zabbix-server

      Then check whether the Zabbix server is running properly:

      • sudo systemctl status zabbix-server

      You will see the following status:

      Output
      ● zabbix-server.service - Zabbix Server
     Loaded: loaded (/lib/systemd/system/zabbix-server.service; disabled; vendor preset: enabled)
     Active: active (running) since Fri 2020-06-12 05:59:32 UTC; 36s ago
    Process: 27026 ExecStart=/usr/sbin/zabbix_server -c $CONFFILE (code=exited, status=0/SUCCESS)
  ...

      Finally, enable the server to start at boot time:

      • sudo systemctl enable zabbix-server

      The server is set up and connected to the database. Next, set up the web frontend.

      Step 5 — Configuring Settings for the Zabbix Web Interface

      The web interface lets you see reports and add hosts that you want to monitor, but it needs some initial setup before you can use it. Launch your browser and go to the address http://zabbix_server_name or https://zabbix_server_name if you set up Let’s Encrypt. On the first screen, you will see a welcome message. Click Next step to continue.

      On the next screen, you will see the table that lists all of the prerequisites to run Zabbix.

      Prerequisites

      All of the values in this table must be OK, so verify that they are. Be sure to scroll down and look at all of the prerequisites. Once you’ve verified that everything is ready to go, click Next step to proceed.

      The next screen asks for database connection information.

      DB Connection

      You told the Zabbix server about your database, but the Zabbix web interface also needs access to the database to manage hosts and read data. Therefore enter the MySQL credentials you configured in Step 2. Click Next step to proceed.

      On the next screen, you can leave the options at their default values.

      Zabbix Server Details

      The Name is optional; it is used in the web interface to distinguish one server from another in case you have several monitoring servers. Click Next step to proceed.

      The next screen will show the pre-installation summary so you can confirm everything is correct.

      Summary

      Click Next step to proceed to the final screen.

      The web interface setup is now complete. This process creates the configuration file /usr/share/zabbix/conf/zabbix.conf.php, which you could back up and use in the future. Click Finish to proceed to the login screen. The default user is Admin and the password is zabbix.

      Before you log in, set up the Zabbix agent on your second Ubuntu server.

      Step 6 — Installing and Configuring the Zabbix Agent

      Now you need to configure the agent software that will send monitoring data to the Zabbix server.

      Log in to the second Ubuntu server:

      • ssh sammy@second_ubuntu_server_ip_address

      Just like on the Zabbix server, run the following commands to install the repository configuration package:

      • wget https://repo.zabbix.com/zabbix/5.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_5.0-1+focal_all.deb

      • sudo dpkg -i zabbix-release_5.0-1+focal_all.deb

      Next, update the package index:

      Then install the Zabbix agent:

      • sudo apt install zabbix-agent

      While Zabbix supports certificate-based encryption, setting up a certificate authority is beyond the scope of this tutorial. But you can use pre-shared keys (PSK) to secure the connection between the server and agent.

      First, generate a PSK:

      • sudo sh -c "openssl rand -hex 32 > /etc/zabbix/zabbix_agentd.psk"

      Show the key by using cat so you can copy it somewhere:

      • cat /etc/zabbix/zabbix_agentd.psk

      The key will look something like this:

      Output
      75ad6cb5e17d244ac8c00c96a1b074d0550b8e7b15d0ab3cde60cd79af280fca

      Save this for later; you will need it to configure the host.

      Now edit the Zabbix agent settings to set up its secure connection to the Zabbix server. Open the agent configuration file in your text editor:

      • sudo nano /etc/zabbix/zabbix_agentd.conf

      Each setting within this file is documented via informative comments throughout the file, but you only need to edit some of them.

      First you have to edit the IP address of the Zabbix server. Find the following section:

      /etc/zabbix/zabbix_agentd.conf

      ...
### Option: Server
#       List of comma delimited IP addresses, optionally in CIDR notation, or DNS names of Zabbix servers and Zabbix proxies.
#       Incoming connections will be accepted only from the hosts listed here.
#       If IPv6 support is enabled then '127.0.0.1', '::127.0.0.1', '::ffff:127.0.0.1' are treated equally
#       and '::/0' will allow any IPv4 or IPv6 address.
#       '0.0.0.0/0' can be used to allow any IPv4 address.
#       Example: Server=127.0.0.1,192.168.1.0/24,::1,2001:db8::/32,zabbix.example.com
#
# Mandatory: yes, if StartAgents is not explicitly set to 0
# Default:
# Server=

Server=127.0.0.1
...

      Change the default value to the IP of your Zabbix server:

      /etc/zabbix/zabbix_agentd.conf

      ...
Server=zabbix_server_ip_address
...

      By default, Zabbix server connects to the agent. But for some checks (for example, monitoring the logs), a reverse connection is required. For correct operation, you need to specify the Zabbix server address and a unique host name.

      Find the section that configures the active checks and change the default values:

      /etc/zabbix/zabbix_agentd.conf

      ...
##### Active checks related

### Option: ServerActive
#       List of comma delimited IP:port (or DNS name:port) pairs of Zabbix servers and Zabbix proxies for active checks.
#       If port is not specified, default port is used.
#       IPv6 addresses must be enclosed in square brackets if port for that host is specified.
#       If port is not specified, square brackets for IPv6 addresses are optional.
#       If this parameter is not specified, active checks are disabled.
#       Example: ServerActive=127.0.0.1:20051,zabbix.domain,[::1]:30051,::1,[12fc::1]
#
# Mandatory: no
# Default:
# ServerActive=

ServerActive=zabbix_server_ip_address

### Option: Hostname
#       Unique, case sensitive hostname.
#       Required for active checks and must match hostname as configured on the server.
#       Value is acquired from HostnameItem if undefined.
#
# Mandatory: no
# Default:
# Hostname=

Hostname=Second Ubuntu Server
...

      Next, find the section that configures the secure connection to the Zabbix server and enable pre-shared key support. Find the TLSConnect section, which looks like this:

      /etc/zabbix/zabbix_agentd.conf

      ...
### Option: TLSConnect
#       How the agent should connect to server or proxy. Used for active checks.
#       Only one value can be specified:
#               unencrypted - connect without encryption
#               psk         - connect using TLS and a pre-shared key
#               cert        - connect using TLS and a certificate
#
# Mandatory: yes, if TLS certificate or PSK parameters are defined (even for 'unencrypted' connection)
# Default:
# TLSConnect=unencrypted
...

      Then add this line to configure pre-shared key support:

      /etc/zabbix/zabbix_agentd.conf

      ...
TLSConnect=psk
...

      Next, locate the TLSAccept section, which looks like this:

      /etc/zabbix/zabbix_agentd.conf

      ...
### Option: TLSAccept
#       What incoming connections to accept.
#       Multiple values can be specified, separated by comma:
#               unencrypted - accept connections without encryption
#               psk         - accept connections secured with TLS and a pre-shared key
#               cert        - accept connections secured with TLS and a certificate
#
# Mandatory: yes, if TLS certificate or PSK parameters are defined (even for 'unencrypted' connection)
# Default:
# TLSAccept=unencrypted
...

      Configure incoming connections to support pre-shared keys by adding this line:

      /etc/zabbix/zabbix_agentd.conf

      ...
TLSAccept=psk
...

      Next, find the TLSPSKIdentity section, which looks like this:

      /etc/zabbix/zabbix_agentd.conf

      ...
### Option: TLSPSKIdentity
#       Unique, case sensitive string used to identify the pre-shared key.
#
# Mandatory: no
# Default:
# TLSPSKIdentity=
...

      Choose a unique name to identify your pre-shared key by adding this line:

      /etc/zabbix/zabbix_agentd.conf

      ...
TLSPSKIdentity=PSK 001
...

      You’ll use this as the PSK ID when you add your host through the Zabbix web interface.

      Then set the option that points to your previously created pre-shared key. Locate the TLSPSKFile option:

      /etc/zabbix/zabbix_agentd.conf

      ...
### Option: TLSPSKFile
#       Full pathname of a file containing the pre-shared key.
#
# Mandatory: no
# Default:
# TLSPSKFile=
...

      Add this line to point the Zabbix agent to your PSK file you created:

      /etc/zabbix/zabbix_agentd.conf

      ...
TLSPSKFile=/etc/zabbix/zabbix_agentd.psk
...

      Save and close the file. Now you can restart the Zabbix agent and set it to start at boot time:

      • sudo systemctl restart zabbix-agent

      • sudo systemctl enable zabbix-agent

      For good measure, check that the Zabbix agent is running properly:

      • sudo systemctl status zabbix-agent

      You will see the following status, indicating the agent is running:

      Output
      ● zabbix-agent.service - Zabbix Agent
   Loaded: loaded (/lib/systemd/system/zabbix-agent.service; enabled; vendor preset: enabled)
   Active: active (running) since Fri 2020-06-12 08:19:54 UTC; 25s ago
  ...

      The agent will listen on port 10050 for connections from the server. Configure UFW to allow connections to this port:

      You can learn more about UFW in How To Set Up a Firewall with UFW on Ubuntu 20.04.

      Your agent is now ready to send data to the Zabbix server. But in order to use it, you have to link to it from the server’s web console. In the next step, you will complete the configuration.

      Step 7 — Adding the New Host to the Zabbix Server

      Installing an agent on a server you want to monitor is only half of the process. Each host you want to monitor needs to be registered on the Zabbix server, which you can do through the web interface.

      Log in to the Zabbix Server web interface by navigating to the address http://zabbix_server_name or https://zabbix_server_name:

      The Zabbix login screen

      When you have logged in, click on Configuration and then Hosts in the left navigation bar. Then click the Create host button in the top right corner of the screen. This will open the host configuration page.

      Creating a host

      Adjust the Host name and IP address to reflect the host name and IP address of your second Ubuntu server, then add the host to a group. You can select an existing group, for example Linux servers, or create your own group. The host can be in multiple groups. To do this, enter the name of an existing or new group in the Groups field and select the desired value from the proposed list.

      Before adding the group, click the Templates tab.

      Adding a template to the host

      Type Template OS Linux by Zabbix agent in the Search field and then select it from the list to add this template to the host.

      Next, navigate to the Encryption tab. Select PSK for both Connections to host and Connections from host. Then set PSK identity to PSK 001, which is the value of the TLSPSKIdentity setting of the Zabbix agent you configured previously. Then set PSK value to the key you generated for the Zabbix agent. It’s the one stored in the file /etc/zabbix/zabbix_agentd.psk on the agent machine.

      Setting up the encryption

      Finally, click the Add button at the bottom of the form to create the host.

      You will see your new host in the list. Wait for a minute and reload the page to see green labels indicating that everything is working fine and the connection is encrypted.

      Zabbix shows your new host

      If you have additional servers you need to monitor, log in to each host, install the Zabbix agent, generate a PSK, configure the agent, and add the host to the web interface following the same steps you followed to add your first host.

      The Zabbix server is now monitoring your second Ubuntu server. Now, set up email notifications to be notified about problems.

      Step 8 — Configuring Email Notifications

      Zabbix automatically supports many types of notifications: email, OTRS, Slack, Telegram, SMS, etc. You can see the full list of integrations at the Zabbix website.

      As an example, this tutorial will configure notifications for the Email media type.

      Click on Administration, and then Media types in the left navigation bar. You will see the list of all media types. There are two preconfigured options for emails: for the plain text notification and for the HTML notifications. In this tutorial you will use plain text notification. Click on Email.

      Adjust the SMTP options according to the settings provided by your email service. This tutorial uses Gmail’s SMTP capabilities to set up email notifications; if you would like more information about setting this up, see How To Use Google’s SMTP Server.


      Note: If you use 2-Step Verification with Gmail, you need to generate an App Password for Zabbix. You’ll only have to enter an App password once during setup. You will find instructions on how to generate this password in the Google Help Center.

      If you are using Gmail, type in smtp.gmail.com for the SMTP server field, 465 for the SMTP server port field, gmail.com for SMTP helo, and your email for SMTP email. Then choose SSL/TLS for Connection security and Username and password for Authentication. Enter your Gmail address as the Username, and the App Password you generated from your Google account as the Password.

      Setting up email media type

      On the Message templates tab you can see the list of predefined messages for various types of notifications. Finally, click the Update button at the bottom of the form to update the email parameters.

      Now you can test sending notifications. To do this, click the Test underlined link in the corresponding line.

      You will see a pop-up window. Enter your email address in the Send to field and click the Test button. You will see a message about the successful sending and you will receive a test message.

      Testing email

      Close the pop-up by clicking the Cancel button.

      Now, create a new user. Click on Administration, and then Users in the left navigation bar. You will see the list of users. Then click the Create user button in the top right corner of the screen. This will open the user configuration page:

      Creating a user

      Enter the new username in the Alias field and set up a new password. Next, add the user to the administrator’s group. Type Zabbix administrators in the Groups field and select it from the proposed list.

      Once you’ve added the group, click the Media tab and click on the Add underlined link (not the Add button below it). You will see a pop-up window.

      Adding an email

      Select the Email option from the Type drop down. Enter your email address in the Send to field. You can leave the rest of the options at the default values. Click the Add button at the bottom to submit.

      Now navigate to the Permissions tab. Select Zabbix Super Admin from the User type drop-down menu.

      Finally, click the Add button at the bottom of the form to create the user.

      Note: Using the default password is not safe. In order to change the password of the built-in user Admin click on the alias in the list of users. Then click Change password, enter a new password, and confirm the changes by clicking Update button.

      Now you need to enable notifications. Click on the Configuration tab and then Actions in the left navigation bar. You will see a pre-configured action, which is responsible for sending notifications to all Zabbix administrators. You can review and change the settings by clicking on its name. For the purposes of this tutorial, use the default parameters. To enable the action, click on the red Disabled link in the Status column.

      Now you are ready to receive alerts. In the next step, you will generate one to test your notification setup.

      Step 9 — Generating a Test Alert

      In this step, you will generate a test alert to ensure everything is connected. By default, Zabbix keeps track of the amount of free disk space on your server. It automatically detects all disk mounts and adds the corresponding checks. This discovery is executed every hour, so you need to wait a while for the notification to be triggered.

      Create a temporary file that’s large enough to trigger Zabbix’s file system usage alert. To do this, log in to your second Ubuntu server if you’re not already connected:

      • ssh sammy@second_ubuntu_server_ip_address

      Next, determine how much free space you have on the server. You can use the df command to find out:

      The command df will report the disk space usage of your file system, and the -h will make the output human-readable. You’ll see output like the following:

      Output
      Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        78G  1.4G   77G    2% /

      In this case, the free space is 77G. Your free space may differ.

      Use the fallocate command, which allows you to pre-allocate or de-allocate space to a file, to create a file that takes up more than 80% of the available disk space. This will be enough to trigger the alert:

      • fallocate -l 70G /tmp/temp.img

      After around an hour, Zabbix will trigger an alert about the amount of free disk space and will run the action you configured, sending the notification message. You can check your inbox for the message from the Zabbix server. You will see a message like:

      Problem started at 09:49:08 on 2020.06.12
Problem name: /: Disk space is low (used > 80%)
Host: Second Ubuntu Server
Severity: Warning
Operational data: Space used: 71.34 GB of 77.36 GB (92.23 %)
Original problem ID: 106

      You can also navigate to the Monitoring tab and then Dashboard to see the notification and its details.

      Main dashboard

      Now that you know the alerts are working, delete the temporary file you created so you can reclaim your disk space:

      After a minute Zabbix will send the recovery message and the alert will disappear from the main dashboard.

      Conclusion

      In this tutorial, you learned how to set up a simple and secure monitoring solution that will help you monitor the state of your servers. It can now warn you of problems, and you have the opportunity to analyze the processes occurring in your IT infrastructure.

      To learn more about setting up monitoring infrastructure, check out our Monitoring topic page.



      Source link

      Forgot Your Password ?