How to Add and Delete Users on Ubuntu 18.04

Introduction

Adding and removing users on a Linux system is one of the most important system administration tasks to familiarize yourself with. When you create a new system, you are often only given access to the root account by default.

While running as the root user gives you complete control over a system and its users, it is also dangerous and can be destructive. For common system administration tasks, it is a better idea to add an unprivileged user and carry out those tasks without root privileges. You can also create additional unprivileged accounts for any other users you may have on your system. Each user on a system should have their own separate account.

For tasks that require administrator privileges, there is a tool installed on Ubuntu systems called sudo. Briefly, sudo allows you to run a command as another user, including users with administrative privileges. In this guide we will cover how to create user accounts, assign sudo privileges, and delete users.

Prerequisites

To follow along with this guide, you will need:

Adding a User

If you are signed in as the root user, you can create a new user at any time by typing:

  • adduser newuser

If you are signed in as a non-root user who has been given sudo privileges, you can add a new user by typing:

  • sudo adduser newuser

Either way, you will be asked a series of questions. The procedure will be:

  • Assign and confirm a password for the new user
  • Enter any additional information about the new user. This is entirely optional and can be skipped by hitting ENTER if you don’t wish to utilize these fields.
  • Finally, you’ll be asked to confirm that the information you provided was correct. Enter Y to continue.

Your new user is now ready for use. You can now log in using the password that you entered.

If you need your new user to have access to administrative functionality, continue on to the next section.

Granting a User Sudo Privileges

If your new user should have the ability to execute commands with root (administrative) privileges, you will need to give the new user access to sudo. Let’s examine two approaches to this problem: adding the user to a pre-defined sudo user group, and specifying privileges on a per-user basis in sudo’s configuration.

Adding the New User to the Sudo Group

By default, sudo on Ubuntu 18.04 systems is configured to extend full privileges to any user in the sudo group.

You can see what groups your new user is in with the groups command:

  • groups newuser
Output
newuser : newuser

By default, a new user is only in their own group which adduser creates along with the user profile. A user and its own group share the same name. In order to add the user to a new group, we can use the usermod command:

  • usermod -aG sudo newuser

The -aG option here tells usermod to add the user to the listed groups.

Specifying Explicit User Privileges in /etc/sudoers

As an alternative to putting your user in the sudo group, you can use the visudo command, which opens a configuration file called /etc/sudoers in the system’s default editor, and explicitly specify privileges on a per-user basis.

Using visudo is the only recommended way to make changes to /etc/sudoers, because it locks the file against multiple simultaneous edits and performs a sanity check on its contents before overwriting the file. This helps to prevent a situation where you misconfigure sudo and are prevented from fixing the problem because you have lost sudo privileges.

If you are currently signed in as root, type:

  • visudo

If you are signed in as a non-root user with sudo privileges, type:

  • sudo visudo

Traditionally, visudo opened /etc/sudoers in the vi editor, which can be confusing for inexperienced users. By default on new Ubuntu installations, visudo will instead use nano, which provides a more convenient and accessible text editing experience. Use the arrow keys to move the cursor, and search for the line that looks like this:

/etc/sudoers
root    ALL=(ALL:ALL) ALL 

Below this line, add the following highlighted line. Be sure to change newuser to the name of the user profile that you would like to grant sudo privileges:

/etc/sudoers
root    ALL=(ALL:ALL) ALL newuser ALL=(ALL:ALL) ALL 

Add a new line like this for each user that should be given full sudo privileges. When you are finished, you can save and close the file by hitting CTRL+X, followed by Y, and then ENTER to confirm.

Testing Your User’s Sudo Privileges

Now, your new user is able to execute commands with administrative privileges.

When signed in as the new user, you can execute commands as your regular user by typing commands as normal:

  • some_command

You can execute the same command with administrative privileges by typing sudo ahead of the command:

  • sudo some_command

You will be prompted to enter the password of the regular user account you are signed in as.

Deleting a User

In the event that you no longer need a user, it is best to delete the old account.

You can delete the user itself, without deleting any of their files, by typing the following command as root:

  • deluser newuser

If you are signed in as another non-root user with sudo privileges, you could instead type:

  • sudo deluser newuser

If, instead, you want to delete the user’s home directory when the user is deleted, you can issue the following command as root:

  • deluser --remove-home newuser

If you’re running this as a non-root user with sudo privileges, you would instead type:

  • sudo deluser --remove-home newuser

If you had previously configured sudo privileges for the user you deleted, you may want to remove the relevant line again by typing:

  • visudo

Or use this if you are a non-root user with sudo privileges:

  • sudo visudo
root    ALL=(ALL:ALL) ALL newuser ALL=(ALL:ALL) ALL   # DELETE THIS LINE 

This will prevent a new user created with the same name from being accidentally given sudo privileges.

Conclusion

You should now have a fairly good handle on how to add and remove users from your Ubuntu 18.04 system. Effective user management will allow you to separate users and give them only the access that they are required to do their job.

For more information about how to configure sudo, check out our guide on how to edit the sudoers file here.

DigitalOcean Community Tutorials

Como Fazer o Benchmark de um Servidor Redis no Ubuntu 18.04

Introdução

O Benchmarking é uma prática importante quando se trata de analisar o desempenho geral dos servidores de banco de dados. É útil para identificar gargalos e oportunidades de melhoria nesses sistemas.

O Redis é um armazenamento de estrutura dados em memória que pode ser usado como banco de dados, cache e intermediador de mensagens ou message broker. Ele suporta desde estruturas de dados simples a complexas, incluindo hashes, strings, conjuntos classificados, bitmaps, dados geoespaciais, entre outros tipos. Neste guia, demonstraremos como fazer o benchmark de um servidor Redis em execução no Ubuntu 18.04, usando algumas ferramentas e métodos distintos.

Pré-requisitos

Para seguir este guia, você precisará de:

Nota: Os comandos demonstrados neste tutorial foram executados em um servidor Redis dedicado rodando em um Droplet da DigitalOcean de 4 GB.

Usando a ferramenta incluída redis-benchmark

O Redis vem com uma ferramenta de benchmark chamada redis-benchmark. Este programa pode ser usado para simular um número arbitrário de clientes se conectando ao mesmo tempo e executando ações no servidor, medindo quanto tempo leva para que as solicitações sejam concluídas. Os dados resultantes vão lhe fornecer uma ideia do número médio de solicitações que o seu servidor Redis é capaz de processar por segundo.

A lista a seguir detalha algumas das opções de comando comuns usadas com o redis-benchmark:

  • -h: Host do Redis. O padrão é 127.0.0.1.
  • -p: Porta do Redis. O padrão é 6379.
  • -a: Se o seu servidor exigir autenticação, você poderá usar esta opção para fornecer a senha.
  • -c: Número de clientes (conexões paralelas) a serem simulados. O valor padrão é 50.
  • -n: Quantas requisições a fazer. O padrão é 100000.
  • -d: Tamanho dos dados para os valores de SET e GET, medidos em bytes. O padrão é 3.
  • -t: Execute apenas um subconjunto de testes. Por exemplo, você pode usar -t get,set para fazer o benchmark dos comandos GET e SET.
  • -q: Modo silencioso, mostra apenas a informação sobre média de requisições por segundo.

Por exemplo, se você deseja verificar o número médio de solicitações por segundo que o seu servidor Redis local pode suportar, você pode usar:

  • redis-benchmark -q

Você obterá resultados semelhantes a este, mas com números diferentes:

Output
PING_INLINE: 85178.88 requests per second PING_BULK: 83056.48 requests per second SET: 72202.16 requests per second GET: 94607.38 requests per second INCR: 84961.77 requests per second LPUSH: 78988.94 requests per second RPUSH: 88652.48 requests per second LPOP: 87950.75 requests per second RPOP: 80971.66 requests per second SADD: 80192.46 requests per second HSET: 84317.03 requests per second SPOP: 78125.00 requests per second LPUSH (needed to benchmark LRANGE): 84175.09 requests per second LRANGE_100 (first 100 elements): 52383.45 requests per second LRANGE_300 (first 300 elements): 21547.08 requests per second LRANGE_500 (first 450 elements): 14471.78 requests per second LRANGE_600 (first 600 elements): 9383.50 requests per second MSET (10 keys): 71225.07 requests per second

Você também pode limitar os testes a um subconjunto de comandos de sua escolha usando o parâmetro -t. O comando a seguir mostra as médias apenas dos comandos GET eSET:

  • redis-benchmark -t set,get -q
Output
SET: 76687.12 requests per second GET: 82576.38 requests per second

As opções padrão usarão 50 conexões paralelas para criar 100000 requisições ao servidor Redis. Se você deseja aumentar o número de conexões paralelas para simular um pico de uso, pode usar a opção -c para isso:

  • redis-benchmark -t set,get -q -c 1000

Como isso usará 1000 conexões simultâneas em vez das 50 padrão, você deve esperar uma diminuição no desempenho:

Output
SET: 69444.45 requests per second GET: 70821.53 requests per second

Se você quiser informações detalhadas na saída, poderá remover a opção -q. O comando a seguir usará 100 conexões paralelas para executar 1000000 requisições SET no servidor:

  • redis-benchmark -t set -c 100 -n 1000000

Você obterá uma saída semelhante a esta:

Output
====== SET ====== 1000000 requests completed in 11.29 seconds 100 parallel clients 3 bytes payload keep alive: 1 95.22% <= 1 milliseconds 98.97% <= 2 milliseconds 99.86% <= 3 milliseconds 99.95% <= 4 milliseconds 99.99% <= 5 milliseconds 99.99% <= 6 milliseconds 100.00% <= 7 milliseconds 100.00% <= 8 milliseconds 100.00% <= 8 milliseconds 88605.35 requests per second

As configurações padrão usam 3 bytes para valores de chave. Você pode mudar isso com a opção -d. O comando a seguir fará o benchmark dos comandos GET e SET usando valores de chave de 1 MB:

  • redis-benchmark -t set,get -d 1000000 -n 1000 -q

Como o servidor está trabalhando com um payload muito maior dessa vez, espera-se uma diminuição significativa do desempenho:

Output
SET: 1642.04 requests per second GET: 822.37 requests per second

É importante perceber que, embora esses números sejam úteis como uma maneira rápida de avaliar o desempenho de uma instância Redis, eles não representam a taxa de transferência máxima que uma instância Redis pode suportar. Usando pipelining, as aplicações podem enviar vários comandos ao mesmo tempo para melhorar o número de requisições por segundo que o servidor pode manipular. Com o redis-benchmark, você pode usar a opção -P para simular aplicações do mundo real que fazem uso desse recurso do Redis.

Para comparar a diferença, primeiro execute o comando redis-benchmark com valores padrão e sem pipelining, para os testes GET e SET:

  • redis-benchmark -t get,set -q
Output
SET: 86281.27 requests per second GET: 89847.26 requests per second

O próximo comando executará os mesmos testes, mas fará o pipeline de 8 comandos juntos:

  • redis-benchmark -t get,set -q -P 8
Output
SET: 653594.81 requests per second GET: 793650.75 requests per second

Como você pode ver na saída, há uma melhoria substancial no desempenho com o uso de pipelining.

Checando a Latência com redis-cli

Se você deseja uma medição simples do tempo médio que uma requisição leva para receber uma resposta, você pode usar o cliente Redis para verificar a latência média do servidor. No contexto do Redis, latência é uma medida de quanto tempo um comando ping leva para receber uma resposta do servidor.

O comando a seguir mostrará estatísticas de latência em tempo real para seu servidor Redis:

  • redis-cli --latency

Você obterá uma saída semelhante a esta, mostrando um número crescente de amostras e uma latência média variável:

Output
min: 0, max: 1, avg: 0.18 (970 samples)

Este comando continuará sendo executado indefinidamente. Você pode pará-lo com um CTRL+C.

Para monitorar a latência por um determinado período, você pode usar:

  • redis-cli --latency-history

Isso irá acompanhar as médias de latência ao longo do tempo, com um intervalo configurável definido como 15 segundos por padrão. Você obterá uma saída semelhante a esta:

Output
min: 0, max: 1, avg: 0.18 (1449 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.16 (1449 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.17 (1444 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.17 (1446 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.17 (1449 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.16 (1444 samples) -- 15.00 seconds range min: 0, max: 1, avg: 0.17 (1445 samples) -- 15.01 seconds range min: 0, max: 1, avg: 0.16 (1445 samples) -- 15.01 seconds range …

Como o servidor Redis em nosso exemplo está ocioso, não há muita variação entre as amostras de latência. Se você tem um pico de uso, no entanto, isso deve ser refletido como um aumento na latência dentro dos resultados.

Se você deseja medir apenas a latência do sistema, pode usar --intrinsic-latency para isso. A latência intrínseca é inerente ao ambiente, dependendo de fatores como hardware, kernel, vizinhança do servidor e outros fatores que não são controlados pelo Redis.

Você pode ver a latência intrínseca como uma linha de base para o desempenho geral do Redis. O comando a seguir verificará a latência intrínseca do sistema, executando um teste por 30 segundos:

  • redis-cli --intrinsic-latency 30

Você deve obter uma saída semelhante a esta:

Output
… 498723744 total runs (avg latency: 0.0602 microseconds / 60.15 nanoseconds per run). Worst run took 22975x longer than the average latency.

Comparar os dois testes de latência pode ser útil para identificar gargalos de hardware ou sistema que podem afetar o desempenho do seu servidor Redis. Considerando que a latência total de uma requisição para o nosso servidor de exemplo tem uma média de 0,18 microssegundos para concluir, uma latência intrínseca de 0,06 microssegundos significa que um terço do tempo total da requisição é gasto pelo sistema em processos que não são controlados pelo Redis.

Usando a Ferramenta Memtier Benchmark

O Memtier é uma ferramenta de benchmark de alto rendimento para Redis e Memcached criada pelo Redis Labs. Embora muito parecido com o redis-benchmark em vários aspectos, o Memtier possui várias opções de configuração que podem ser ajustadas para emular melhor o tipo de carga que você pode esperar no seu servidor Redis, além de oferecer suporte a cluster.

Para instalar o Memtier em seu servidor, você precisará compilar o software a partir do código-fonte. Primeiro, instale as dependências necessárias para compilar o código:

  • sudo apt-get install build-essential autoconf automake libpcre3-dev libevent-dev pkg-config zlib1g-dev

Em seguida, vá para o seu diretório home e clone o projeto memtier_benchmark do repositório Github:

  • cd
  • git clone https://github.com/RedisLabs/memtier_benchmark.git

Navegue para o diretório do projeto e execute o comando autoreconf para gerar os scripts de configuração do aplicativo:

  • cd memtier_benchmark
  • autoreconf -ivf

Execute o script configure para gerar os artefatos do aplicativo necessários para a compilação:

  • ./configure

Agora execute make para compilar o aplicativo:

  • make

Após a conclusão da compilação, você pode testar o executável com:

  • ./memtier_benchmark --version

Isso lhe fornecerá a seguinte saída:

Output
memtier_benchmark 1.2.17 Copyright (C) 2011-2017 Redis Labs Ltd. This is free software. You may redistribute copies of it under the terms of the GNU General Public License <http://www.gnu.org/licenses/gpl.html>. There is NO WARRANTY, to the extent permitted by law.

A lista a seguir contém algumas das opções mais comuns usadas com o comando memtier_benchmark:

  • -s: Host do Servidor. O padrão é localhost.
  • -p: Porta do Servidor. O padrão é 6379.
  • -a: Autentica requisições usando a senha fornecida.
  • -n: Número de requisições por cliente (o padrão é 10000).
  • -c: Número de clientes (o padrão é 50).
  • -t: Número de threads (o padrão é 4).
  • --pipeline: Ativar pipelining.
  • --ratio: Relação entre os comandos SET e GET, o padrão é 1:10.
  • --hide-histogram: Oculta informações detalhadas de saída.

A maioria dessas opções é muito semelhante às opções presentes no redis-benchmark, mas o Memtier testa o desempenho de uma maneira diferente. Para simular melhor os ambientes comuns do mundo real, o benchmark padrão realizado pelo memtier_benchmark testará apenas as solicitações GET e SET, na proporção de 1 a 10. Com 10 operações GET para cada operação SET no teste, esse arranjo é mais representativo de uma aplicação web comum usando o Redis como banco de dados ou cache. Você pode ajustar o valor da taxa com a opção --ratio.

O comando a seguir executa o memtier_benchmark com as configurações padrão, fornecendo apenas informações de saída de alto nível:

  • ./memtier_benchmark --hide-histogram

Nota: se você configurou seu servidor Redis para exigir autenticação, você deve fornecer a opção -a junto com sua senha Redis ao comando memtier_benchmark:

  • ./memtier_benchmark --hide-histogram -a sua_senha_redis

Você verá resultados semelhantes a este:

Output
… 4 Threads 50 Connections per thread 10000 Requests per client ALL STATS ========================================================================= Type Ops/sec Hits/sec Misses/sec Latency KB/sec ------------------------------------------------------------------------- Sets 8258.50 --- --- 2.19800 636.05 Gets 82494.28 41483.10 41011.18 2.19800 4590.88 Waits 0.00 --- --- 0.00000 --- Totals 90752.78 41483.10 41011.18 2.19800 5226.93

De acordo com esta execução do memtier_benchmark, nosso servidor Redis pode executar cerca de 90 mil operações por segundo na proporção 1:10 SET/GET.

É importante observar que cada ferramenta de benchmark possui seu próprio algoritmo para teste de desempenho e apresentação de dados. Por esse motivo, é normal ter resultados ligeiramente diferentes no mesmo servidor, mesmo utilizando configurações semelhantes.

Conclusão

Neste guia, demonstramos como executar testes de benchmark em um servidor Redis usando duas ferramentas distintas: o redis-benchmark incluído e a ferramenta memtier_benchmark desenvolvida pelo Redis Labs. Também vimos como verificar a latência do servidor usando redis-cli. Com base nos dados obtidos com esses testes, você entenderá melhor o que esperar do servidor Redis em termos de desempenho e quais são os gargalos da sua configuração atual.

DigitalOcean Community Tutorials

Como Configurar um Banco de Dados Remoto para Otimizar o Desempenho do Site com o MySQL no Ubuntu 18.04

Introdução

À medida que sua aplicação ou site cresce, pode chegar um momento em que você superou a configuração atual do seu servidor. Se você estiver hospedando o seu servidor web e o back-end do banco de dados na mesma máquina, pode ser uma boa ideia separar essas duas funções para que cada uma possa operar em seu próprio hardware e compartilhar a carga de responder às solicitações dos visitantes.

Neste guia, veremos como configurar um servidor de banco de dados MySQL remoto ao qual sua aplicação web pode se conectar. Usaremos o WordPress como exemplo para ter algo para trabalhar, mas a técnica é amplamente aplicável a qualquer aplicação suportada pelo MySQL.

Pré-requisitos

Antes de iniciar este tutorial, você precisará de:

  • Dois servidores Ubuntu 18.04. Cada um deles deve ter um usuário não-root com privilégios sudo e um firewall UFW habilitado, conforme descrito em nosso tutorial de Configuração Inicial de servidor com Ubuntu 18.04. Um desses servidores hospedará seu back-end MySQL e, ao longo deste guia, o chamaremos de servidor de banco de dados. O outro se conectará ao seu servidor de banco de dados remotamente e atuará como seu servidor web; da mesma forma, iremos nos referir a ele como servidor web ao longo deste guia.
  • Nginx e PHP instalado em seu servidor web. Nosso tutorial How To Install Linux, Nginx, MySQL, PHP (LEMP stack) in Ubuntu 18.04 o guiará no processo, mas observe que você deve pular o Passo 2 deste tutorial, que se concentra na instalação do MySQL, pois você instalará o MySQL no seu servidor de banco de dados.
  • MySQL instalado em seu servidor de banco de dados. Siga o tutorial Como Instalar o MySQL no Ubuntu 18.04 para configurar isso.
  • Opcionalmente (mas altamente recomendado), certificados TLS/SSL da Let’s Encrypt instalados em seu servidor web. Você precisará comprar um nome de domínio e ter registros DNS configurados para seu servidor, mas os certificados em si são gratuitos. Nosso guia Como Proteger o Nginx com o Let’s Encrypt no Ubuntu 18.04 lhe mostrará como obter esses certificados.

Passo 1 — Configurando o MySQL para Escutar Conexões Remotas

Ter os dados armazenados em um servidor separado é uma boa maneira de expandir elegantemente após atingir o limite máximo de desempenho de uma configuração de uma única máquina. Ela também fornece a estrutura básica necessária para balancear a carga e expandir sua infraestrutura ainda mais posteriormente. Após instalar o MySQL, seguindo o tutorial de pré-requisitos, você precisará alterar alguns valores de configuração para permitir conexões a partir de outros computadores.

A maioria das mudanças na configuração do servidor MySQL pode ser feita no arquivo mysqld.cnf, que é armazenado no diretório /etc/mysql/mysql.conf.d/ por padrão. Abra este arquivo em seu servidor de banco de dados com privilégios de root em seu editor preferido. Aqui, iremos usar o nano:

  • sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

Este arquivo é dividido em seções indicadas por labels entre colchetes ([ e ]). Encontre a seção com o label mysqld:

/etc/mysql/mysql.conf.d/mysqld.cnf
. . . [mysqld] . . . 

Nesta seção, procure um parâmetro chamado bind-address. Isso informa ao software do banco de dados em qual endereço de rede escutar as conexões.

Por padrão, isso está definido como 127.0.0.1, significando que o MySQL está configurado para escutar apenas conexões locais. Você precisa alterar isso para fazer referência a um endereço IP externo onde seu servidor pode ser acessado.

Se os dois servidores estiverem em um datacenter com recursos de rede privada, use o IP da rede privada do seu servidor de banco de dados. Caso contrário, você pode usar seu endereço IP público:

/etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld] . . . bind-address = ip_do_servidor_de_banco_de_dados 

Como você se conectará ao seu banco de dados pela Internet, é recomendável que você exija conexões criptografadas para manter seus dados seguros. Se você não criptografar sua conexão MySQL, qualquer pessoa na rede poderá fazer sniff por informações confidenciais entre seus servidores web e de banco de dados. Para criptografar conexões MySQL, adicione a seguinte linha após a linha bind-address que você acabou de atualizar:

/etc/mysql/mysql.conf.d/mysqld.cnf
[mysqld] . . . require_secure_transport = on . . . 

Salve e feche o arquivo quando terminar. Se você estiver usando nano, faça isso pressionando CTRL+X, Y e, em seguida, ENTER.

Para que as conexões SSL funcionem, você precisará criar algumas chaves e certificados. O MySQL vem com um comando que os configura automaticamente. Execute o seguinte comando, que cria os arquivos necessários. Ele também os torna legíveis pelo servidor MySQL, especificando o UID do usuário mysql:

  • sudo mysql_ssl_rsa_setup --uid=mysql

Para forçar o MySQL a atualizar sua configuração e ler as novas informações de SSL, reinicie o banco de dados:

  • sudo systemctl restart mysql

Para confirmar que o servidor agora está escutando na interface externa, execute o seguinte comando netstat:

  • sudo netstat -plunt | grep mysqld
Output
tcp 0 0 ip_do_servidor_de_banco_de_dados:3306 0.0.0.0:* LISTEN 27328/mysqld

O netstat imprime estatísticas sobre o sistema de rede do seu servidor. Esta saída nos mostra que um processo chamado mysqld está anexado ao ip_do_servidor_de_banco_de_dados na porta 3306, a porta padrão do MySQL, confirmando que o servidor está escutando na interface apropriada.

Em seguida, abra essa porta no firewall para permitir o tráfego através dela:

  • sudo ufw allow mysql

Essas são todas as alterações de configuração que você precisa fazer no MySQL. A seguir, veremos como configurar um banco de dados e alguns perfis de usuário, um dos quais você usará para acessar o servidor remotamente.

Passo 2 — Configurando um Banco de Dados para o WordPress e Credenciais Remotas

Embora o próprio MySQL agora esteja escutando em um endereço IP externo, atualmente não há usuários ou bancos de dados habilitados para controle remoto configurados. Vamos criar um banco de dados para o WordPress e um par de usuários que possam acessá-lo.

Comece conectando-se ao MySQL como o usuário root do MySQL:

  • sudo mysql

Nota: Se você tiver a autenticação por senha ativada, conforme descrito no Passo 3 do pré-requisito do tutorial do MySQL, você precisará usar o seguinte comando para acessar o shell do MySQL:

  • mysql -u root -p

Depois de executar este comando, você será solicitado a fornecer sua senha de root do MySQL e, após inseri-la, receberá um novo prompt mysql>.

No prompt do MySQL, crie um banco de dados que o WordPress usará. Pode ser útil atribuir a esse banco de dados um nome reconhecível para que você possa identificá-lo facilmente mais tarde. Aqui, vamos chamá-lo de wordpress:

  • CREATE DATABASE wordpress;

Agora que você criou seu banco de dados, você precisará criar um par de usuários. Criaremos um usuário somente local e um usuário remoto vinculado ao endereço IP do servidor web.

Primeiro, crie seu usuário local, wpuser, e faça com que esta conta corresponda apenas às tentativas de conexão local usando localhost na declaração:

  • CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'senha';

Em seguida, conceda a esta conta acesso total ao banco de dados wordpress:

  • GRANT ALL PRIVILEGES ON wordpress.* TO 'wpuser'@'localhost';

Agora, esse usuário pode executar qualquer operação no banco de dados do WordPress, mas essa conta não pode ser usada remotamente, pois corresponde apenas às conexões da máquina local. Com isso em mente, crie uma conta complementar que corresponda às conexões exclusivamente do seu servidor web. Para isso, você precisará do endereço IP do seu servidor web.

Observe que você deve usar um endereço IP que utilize a mesma rede que você configurou no seu arquivo mysqld.cnf. Isso significa que, se você especificou um IP de rede privada no arquivo mysqld.cnf, precisará incluir o IP privado do seu servidor web nos dois comandos a seguir. Se você configurou o MySQL para usar a internet pública, você deve fazer isso corresponder ao endereço IP público do servidor web.

  • CREATE USER 'remotewpuser'@'ip_do_servidor_web' IDENTIFIED BY 'senha';

Depois de criar sua conta remota, conceda a ela os mesmos privilégios que o usuário local:

  • GRANT ALL PRIVILEGES ON wordpress.* TO 'remotewpuser'@'ip_do_servidor_web';

Por fim, atualize os privilégios para que o MySQL saiba começar a usá-los:

  • FLUSH PRIVILEGES;

Então saia do prompt do MySQL digitando:

  • exit

Agora que você configurou um novo banco de dados e um usuário habilitado remotamente, você pode testar se consegue se conectar ao banco de dados a partir do seu servidor web.

Passo 3 — Testando Conexões Remotas e Locais

Antes de continuar, é melhor verificar se você pode se conectar ao seu banco de dados tanto a partir da máquina local — seu servidor de banco de dados — quanto pelo seu servidor web.

Primeiro, teste a conexão local a partir do seu servidor de banco de dados tentando fazer login com sua nova conta:

  • mysql -u wpuser -p

Quando solicitado, digite a senha que você configurou para esta conta.

Se você receber um prompt do MySQL, então a conexão local foi bem-sucedida. Você pode sair novamente digitando:

  • exit

Em seguida, faça login no seu servidor web para testar as conexões remotas:

  • ssh sammy@ip_do_servidor_web

Você precisará instalar algumas ferramentas de cliente para MySQL em seu servidor web para acessar o banco de dados remoto. Primeiro, atualize o cache de pacotes local se você não tiver feito isso recentemente:

  • sudo apt update

Em seguida, instale os utilitários de cliente do MySQL:

  • sudo apt install mysql-client

Depois disso, conecte-se ao seu servidor de banco de dados usando a seguinte sintaxe:

  • mysql -u remotewpuser -h ip_do_servidor_de_banco_de_dados -p

Novamente, você deve certificar-se que está usando o endereço IP correto para o servidor de banco de dados. Se você configurou o MySQL para escutar na rede privada, digite o IP da rede privada do seu banco de dados. Caso contrário, digite o endereço IP público do seu servidor de banco de dados.

Você será solicitado a inserir a senha da sua conta remotewpuser. Depois de inseri-la, e se tudo estiver funcionando conforme o esperado, você verá o prompt do MySQL. Verifique se a conexão está usando SSL com o seguinte comando:

  • status

Se a conexão realmente estiver usando SSL, a linha SSL: indicará isso, como mostrado aqui:

Output
-------------- mysql Ver 14.14 Distrib 5.7.18, for Linux (x86_64) using EditLine wrapper Connection id: 52 Current database: Current user: remotewpuser@203.0.113.111 SSL: Cipher in use is DHE-RSA-AES256-SHA Current pager: stdout Using outfile: '' Using delimiter: ; Server version: 5.7.18-0ubuntu0.16.04.1 (Ubuntu) Protocol version: 10 Connection: 203.0.113.111 via TCP/IP Server characterset: latin1 Db characterset: latin1 Client characterset: utf8 Conn. characterset: utf8 TCP port: 3306 Uptime: 3 hours 43 min 40 sec Threads: 1 Questions: 1858 Slow queries: 0 Opens: 276 Flush tables: 1 Open tables: 184 Queries per second avg: 0.138 --------------

Depois de verificar que você pode se conectar remotamente, vá em frente e saia do prompt:

  • exit

Com isso, você verificou o acesso local e o acesso a partir do servidor web, mas não verificou se outras conexões serão recusadas. Para uma verificação adicional, tente fazer o mesmo em um terceiro servidor para o qual você não configurou uma conta de usuário específica para garantir que esse outro servidor não tenha o acesso concedido.

Observe que antes de executar o seguinte comando para tentar a conexão, talvez seja necessário instalar os utilitários de cliente do MySQL, como você fez acima:

  • mysql -u wordpressuser -h ip_do_servidor_de_banco_de_dados -p

Isso não deve ser concluído com êxito e deve gerar um erro semelhante a este:

Output
ERROR 1130 (HY000): Host '203.0.113.12' is not allowed to connect to this MySQL server

Isso é esperado, já que você não criou um usuário do MySQL que tem permissão para se conectar a partir deste servidor, e também é desejado, uma vez que você quer ter certeza de que seu servidor de banco de dados negará o acesso de usuários não autorizados ao seu servidor do MySQL.

Após testar com êxito sua conexão remota, você pode instalar o WordPress em seu servidor web.

Passo 4 — Instalando o WordPress

Para demonstrar os recursos do seu novo servidor MySQL com capacidade remota, passaremos pelo processo de instalação e configuração do WordPress — o popular sistema de gerenciamento de conteúdo — em seu servidor web. Isso exigirá que você baixe e extraia o software, configure suas informações de conexão e então execute a instalação baseada em web do WordPress.

No seu servidor web, faça o download da versão mais recente do WordPress para o seu diretório home:

  • cd ~
  • curl -O https://wordpress.org/latest.tar.gz

Extraia os arquivos, que criarão um diretório chamado wordpress no seu diretório home:

  • tar xzvf latest.tar.gz

O WordPress inclui um arquivo de configuração de exemplo que usaremos como ponto de partida. Faça uma cópia deste arquivo, removendo -sample do nome do arquivo para que ele seja carregado pelo WordPress:

  • cp ~/wordpress/wp-config-sample.php ~/wordpress/wp-config.php

Quando você abre o arquivo, sua primeira abordagem será ajustar algumas chaves secretas para fornecer mais segurança à sua instalação. O WordPress fornece um gerador seguro para esses valores, para que você não precise criar bons valores por conta própria. Eles são usados apenas internamente, portanto, não prejudicará a usabilidade ter valores complexos e seguros aqui.

Para obter valores seguros do gerador de chave secreta do WordPress, digite:

  • curl -s https://api.wordpress.org/secret-key/1.1/salt/

Isso imprimirá algumas chaves na sua saída. Você as adicionará momentaneamente ao seu arquivo wp-config.php:

Atenção! É importante que você solicite seus próprios valores únicos sempre. Não copie os valores mostrados aqui!

Output
define('AUTH_KEY', 'L4|2Yh(giOtMLHg3#] DO NOT COPY THESE VALUES %G00o|te^5YG@)'); define('SECURE_AUTH_KEY', 'DCs-k+MwB90/-E(=!/ DO NOT COPY THESE VALUES +WBzDq:7U[#Wn9'); define('LOGGED_IN_KEY', '*0kP!|VS.K=;#fPMlO DO NOT COPY THESE VALUES +&[%8xF*,18c @'); define('NONCE_KEY', 'fmFPF?UJi&(j-{8=$ - DO NOT COPY THESE VALUES CCZ?Q+_~1ZU~;G'); define('AUTH_SALT', '@qA7f}2utTEFNdnbEa DO NOT COPY THESE VALUES t}Vw+8=K%20s=a'); define('SECURE_AUTH_SALT', '%BW6s+d:7K?-`C%zw4 DO NOT COPY THESE VALUES 70U}PO1ejW+7|8'); define('LOGGED_IN_SALT', '-l>F:-dbcWof%4kKmj DO NOT COPY THESE VALUES 8Ypslin3~d|wLD'); define('NONCE_SALT', '4J(<`4&&F (WiK9K#] DO NOT COPY THESE VALUES ^ZikS`es#Fo:V6');

Copie a saída que você recebeu para a área de transferência e abra o arquivo de configuração no seu editor de texto:

  • nano ~/wordpress/wp-config.php

Encontre a seção que contém os valores fictícios para essas configurações. Será algo parecido com isto:

/wordpress/wp-config.php
. . . define('AUTH_KEY',         'put your unique phrase here'); define('SECURE_AUTH_KEY',  'put your unique phrase here'); define('LOGGED_IN_KEY',    'put your unique phrase here'); define('NONCE_KEY',        'put your unique phrase here'); define('AUTH_SALT',        'put your unique phrase here'); define('SECURE_AUTH_SALT', 'put your unique phrase here'); define('LOGGED_IN_SALT',   'put your unique phrase here'); define('NONCE_SALT',       'put your unique phrase here'); . . . 

Exclua essas linhas e cole os valores que você copiou a partir da linha de comando.

Em seguida, insira as informações de conexão para seu banco de dados remoto. Essas linhas de configuração estão na parte superior do arquivo, logo acima de onde você colou suas chaves. Lembre-se de usar o mesmo endereço IP que você usou no teste de banco de dados remoto anteriormente:

/wordpress/wp-config.php
. . . /** The name of the database for WordPress */ define('DB_NAME', 'wordpress');  /** MySQL database username */ define('DB_USER', 'remotewpuser');  /** MySQL database password */ define('DB_PASSWORD', 'password');  /** MySQL hostname */ define('DB_HOST', 'db_server_ip'); . . . 

E, finalmente, em qualquer lugar do arquivo, adicione a seguinte linha que diz ao WordPress para usar uma conexão SSL para o nosso banco de dados MySQL:

/wordpress/wp-config.php
define('MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL); 

Salve e feche o arquivo.

Em seguida, copie os arquivos e diretórios encontrados no diretório ~/wordpress para a raiz de documentos do Nginx. Observe que este comando inclui a flag -a para garantir que todas as permissões existentes sejam transferidas:

  • sudo cp -a ~/wordpress/* /var/www/html

Depois disso, a única coisa a fazer é modificar a propriedade do arquivo. Altere a propriedade de todos os arquivos na raiz de documentos para www-data, o usuário padrão do servidor web do Ubuntu:

  • sudo chown -R www-data:www-data /var/www/html

Com isso, o WordPress está instalado e você está pronto para executar sua rotina de configuração baseada em web.

Passo 5 — Configurando o WordPress Através da Interface Web

O WordPress possui um processo de configuração baseado na web. Conforme você avança, ele fará algumas perguntas e instalará todas as tabelas necessárias no seu banco de dados. Aqui, abordaremos as etapas iniciais da configuração do WordPress, que você pode usar como ponto de partida para criar seu próprio site personalizado que usa um back-end de banco de dados remoto.

Navegue até o nome de domínio (ou endereço IP público) associado ao seu servidor web:

http://example.com 

Você verá uma tela de seleção de idioma para o instalador do WordPress. Selecione o idioma apropriado e clique na tela principal de instalação:

WordPress install screen

Depois de enviar suas informações, você precisará fazer login na interface de administração do WordPress usando a conta que você acabou de criar. Você será direcionado para um painel onde poderá personalizar seu novo site WordPress.

Conclusão

Ao seguir este tutorial, você configurou um banco de dados MySQL para aceitar conexões protegidas por SSL a partir de uma instalação remota do WordPress. Os comandos e técnicas usados neste guia são aplicáveis a qualquer aplicação web escrita em qualquer linguagem de programação, mas os detalhes específicos da implementação serão diferentes. Consulte a documentação do banco de dados da aplicação ou linguagem para obter mais informações.

DigitalOcean Community Tutorials

RoseHosting Blog: How to Install pip on Ubuntu 18.04

In this tutorial, we will show you how to install pip on an Ubuntu 18.04 VPS. Pip is a package management system which can be used to install and manage packages written in Python. Python is a programming language that allows you to perform web development, software development, system administration, scientific and numeric data analysis, […]
Planet Python

How To Configure MTA-STS and TLS Reporting for Your Domain Using Apache on Ubuntu 18.04

The author selected Electronic Frontier Foundation Inc to receive a donation as part of the Write for DOnations program.

Introduction

Mail Transport Agent Strict Transport Security (MTA-STS) is a new internet standard that allows you to enable strict force-TLS for email sent between supported email providers. It is similar to HTTP Strict Transport Security (HSTS), where a force-TLS policy is set and then cached for a specified amount of time, reducing the risk of man-in-the-middle or downgrade attacks.

MTA-STS is complemented by SMTP TLS Reporting (TLSRPT), which gives you insight into which emails are successfully delivered over TLS, and which aren’t. TLSRPT is similar to DMARC reporting, but for TLS.

The primary reason for implementing MTA-STS for your domain is to ensure that confidential email that is sent to you is transmitted securely over TLS. Other methods for requiring TLS for email communications are still susceptible to man-in-the-middle attacks, as the initial connection is unencrypted. MTA-STS ensures that the initial incoming connection is using TLS by default, which greatly reduces the risk of these attacks.

An example use case for MTA-STS and TLS Reporting is to help create a secure customer service email system for your business. Customers may send support tickets via email that contain confidential personal information, which needs a secure TLS connection. MTA-STS provides that secure connection, and TLSRPT will deliver daily reports identifying any emails that weren’t sent securely—giving crucial insight into any ongoing or previous attacks against your email system.

In this tutorial, you will learn how to configure MTA-STS and TLSRPT for your domain name, and then interpret your first TLS Report. While this tutorial covers the steps for using Apache on Ubuntu 18.04 with a Let’s Encrypt certificate, the MTA-STS/TLSRPT configuration will also work on alternatives, such as Nginx on Debian.

Prerequisites

Before you begin this guide, you’ll need:

Once you have these ready, log in to your server as your non-root user to begin.

Note: Once you have completed the implementation steps for MTA-STS and TLSRPT, you may have to wait up to 24 hours to receive your first TLS Report. This is because most email providers send reports once per day. You may resume the tutorial from Step 5 once you’ve received your first report.

Step 1 — Creating an MTA-STS Policy File

MTA-STS is enabled and configured using a plain text configuration file that you host on your website. Supported mail servers will then automatically connect to your website to retrieve the file, which causes MTA-STS to be enabled. In this first step you’ll understand the available options for this file and choose the most appropriate for your file.

Firstly, open a new text file in your home directory so that you have somewhere to write down your desired configuration:

  • nano mta-sts.txt

We will first go over an example, and then you will write your own configuration file.

Following is an example of an MTA-STS configuration file:

Example MTA-STS Configuration File
version: STSv1 mode: enforce mx: mail1.your-domain mx: mail2.your-domain max_age: 604800 

This example configuration file specifies that all email delivered to mail1.your-domain and mail2.your-domain from supported providers must be delivered over a valid TLS connection. If a valid TLS connection cannot be established with your mail server (for example, if the certificate has expired or is self-signed), the email will not be delivered.

This will make it much more challenging for an attacker to intercept and snoop on/modify your email in a situation like a man-in-the-middle attack. This is because having MTA-STS enabled properly only allows email to be transmitted over a valid TLS connection, which requires a valid TLS certificate. It would be hard for an attacker to acquire such a certificate, as doing so usually requires privileged access to your domain name and/or website.

As shown in the example earlier in this step, the configuration file consists of a number of key/value pairs:

  • version:

    • Purpose: To specify the version of the MTA-STS specification to use.
    • Accepted Values: Currently the only accepted value is STSv1.
    • Example: version: STSv1
  • mode:

    • Purpose: Specify which mode MTA-STS should be enabled in.
    • Accepted Values:
      • enforce: Force all incoming email from supported providers to use valid TLS.
      • testing: Report-only mode. email will not be blocked, but TLSRPT reports are still sent.
      • none: Disable MTA-STS.
    • Example: mode: enforce
  • mx:

    • Purpose: To specify which mail servers are allowed to handle email for your domain. This should match the servers specified in your mx records.
    • Accepted Values: Fully-qualified domain name of a mail server, or a wildcard host. Multiple mx: values must be used to specify multiple mail servers.
    • Example: mx: mail1.your-domain, mx: mail2.your-domain, mx: *.example.org
  • max_age:

    • Purpose: To specify the maximum lifetime of the MTA-STS policy, in seconds.
    • Accepted Values: Any positive integer up to 31557600.
    • Example: max_age: 604800 (1 week)

You can also view the official specification for the key/value pairs in Section 3.2 of the MTA-STS RFC.

Warning: Enabling MTA-STS in enforce mode could unexpectedly cause some email not to be delivered to you. Instead, it is recommended to use mode: testing and a low max_age: value at first, in order to ensure that everything is working correctly before turning on MTA-STS fully.

Using the example file earlier in the step, as well as the preceding key/value pair examples, write your desired MTA-STS policy file and save it to the file that you created at the start of the step.

The following example file is ideal for testing MTA-STS, as it will not cause any emails to be unexpectedly blocked, and has a max_age of only 1 day, meaning that if you decide to disable it, the configuration will expire quickly. Note that some email providers will only send TLSRPT reports if the max_age is greater than 1 day, which is why 86401 seconds is a good choice (1 day and 1 second).

Example Test MTA-STS Configuration File
version: STSv1 mode: testing mx: mail1.your-domain mx: mail2.your-domain max_age: 86401 

In this step you created your desired MTA-STS configuration file and saved it to your home area. In the next step, you will configure an Apache web server to serve the file in the correct format.

Step 2 — Configuring Apache to Serve Your MTA-STS Policy File

In this step, you’ll configure an Apache virtual host to serve your MTA-STS configuration file, and then add a DNS record to allow the site to be accessed from a subdomain.

In order for your MTA-STS configuration file to be automatically discovered by mail servers, it must be served at exactly the right path: https://mta-sts.your-domain/.well-known/mta-sts.txt. You must use the mta-sts subdomain over HTTPS and the /.well-known/mta-sts.txt path, otherwise your configuration will not work.

This can be achieved by creating a new Apache virtual host for the mta-sts subdomain, which will serve the MTA-STS policy file. This step builds upon the base configuration that you’ll have set up in the prerequisite step How to Install the Apache Web Server on Ubuntu 18.04.

Firstly, create a directory for your virtual host:

  • sudo mkdir /var/www/mta-sts

If you’re hosting multiple different domains on your web server, it is recommended to use a different MTA-STS virtual host for each, for example /var/www/mta-sts-site1 and /var/www/mta-sts-site2.

Next, you need to create the .well-known directory, which is where your MTA-STS configuration file will be stored. .well-known is a standardized directory for ‘well-known’ files, such as TLS certificate validation files, security.txt, and more.

  • sudo mkdir /var/www/mta-sts/.well-known

Now you can move the MTA-STS policy file that you created in Step 1 into the web server directory that you just created:

  • sudo mv ~/mta-sts.txt /var/www/mta-sts/.well-known/mta-sts.txt

You can check that the file was copied correctly if you wish:

  • cat /var/www/mta-sts/.well-known/mta-sts.txt

This will output the contents of the file that you created in Step 1.

In order for Apache to serve the file, you’ll need to configure the new virtual host and enable it. MTA-STS only works over HTTPS, so you’ll use port 443 (HTTPS) exclusively, rather than using port 80 (HTTP) as well.

Firstly, create a new virtual host configuration file:

  • sudo nano /etc/apache2/sites-available/mta-sts.conf

Like with the virtual host directory, if you are hosting multiple different domains on the same web server, it is recommended to use a different virtual host name for each.

Then, copy the following sample configuration into the file, and populate the variables where required:

~/etc/apache2/sites-available/mta-sts.conf
<IfModule mod_ssl.c> <VirtualHost your-server-ipv4-address:443 [your-server-ipv6-address]:443>     ServerName mta-sts.your-domain     DocumentRoot /var/www/mta-sts      ErrorDocument 403 "403 Forbidden - This site is used to specify the MTA-STS policy for this domain, please see '/.well-known/mta-sts.txt'. If you were not expecting to see this, please use <a href=\"https://your-domain\" rel=\"noopener\">https://your-domain</a> instead."      RewriteEngine On     RewriteOptions IgnoreInherit     RewriteRule !^/.well-known/mta-sts.txt - [L,R=403]      SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem     SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key     Include /etc/letsencrypt/options-ssl-apache.conf </VirtualHost> </IfModule> 

This configuration will create the mta-sts virtual host, which will be served at mta-sts.your-domain. It will also redirect all requests, except for those to the mta-sts.txt file itself, to a custom 403 Forbidden error page, with a friendly explanation of what the subdomain site is for. This is to help ensure that any visitors who accidentally come across your MTA-STS site aren’t inadvertently confused.

Currently, a self-signed TLS certificate is used. This is not ideal, as a fully valid/trusted certificate is required for MTA-STS to work correctly. In Step 3, you will acquire a TLS certificate using Let’s Encrypt.

Next, ensure that the required Apache modules are enabled:

  • sudo a2enmod rewrite ssl

After that, enable the new virtual host:

  • sudo a2ensite mta-sts

Then, run a syntax check of the Apache configuration files, to ensure that there aren’t any unexpected errors:

  • sudo apachectl configtest

When the test passes with no errors, you can restart Apache to fully enable the new virtual host:

  • sudo service apache2 restart

Now that the Apache virtual host has been set up and configured, you need to create the required DNS record(s) to allow it to be accessed using the fully-qualified domain name mta-sts.your-domain.

The way that this is done depends on the DNS hosting provider that you use. However, if you use DigitalOcean as your DNS provider, simply navigate to your project, followed by clicking on your domain.

Finally, add the required DNS records for the mta-sts subdomain. If your Droplet only uses IPv4, create an A record for mta-sts, pointing to your-server-ipv4-address. If you use IPv6 as well, create an AAAA record pointing to your-server-ipv6-address.

A screenshot of the DigitalOcean DNS control panel, showing an example DNS record for mta-sts pointing to an IPv4 address.

In this step, you created and configured a new Apache virtual host for your MTA-STS subdomain, then added the required DNS record(s) to allow it to be accessed easily. In the next step, you will acquire a trusted Let’s Encrypt certificate for your MTA-STS subdomain.

Step 3 — Acquiring a Let’s Encrypt Certificate for Your MTA-STS Subdomain

In this step, you’ll acquire a TLS certificate from Let’s Encrypt, to allow your mta-sts.your-domain site to be served correctly over HTTPS.

In order to do this, you’ll use certbot, which you set up as part of the prerequisite step How To Secure Apache with Let’s Encrypt on Ubuntu 18.04.

Firstly, run certbot to issue a certificate for your mta-sts subdomain using the Apache plugin verification method:

  • sudo certbot --apache -d mta-sts.your-domain

This will automatically issue a trusted certificate and install it on your Apache web server. When the Certbot wizard asks about configuring a HTTP -> HTTPS redirect, select ‘No’, as this is not required for MTA-STS.

To finish, test your new virtual host to ensure that it is working correctly. Use a web browser to visit https://mta-sts.your-domain/.well-known/mta-sts.txt, or use a command-line tool such as curl:

  • curl https://mta-sts.your-domain/.well-known/mta-sts.txt

This will output the MTA-STS policy file that you created in Step 1:

Output
version: STSv1 mode: testing mx: mail1.your-domain mx: mail2.your-domain max_age: 86401

If an error occurs, ensure that the virtual host configuration from Step 2 is correct, and that you have added a DNS record for the mta-sts subdomain.

In this step, you issued a Let’s Encrypt TLS certificate for your mta-sts subdomain, and tested that it’s working. Next, you’ll set some DNS TXT records to fully enable MTA-STS and TLSRPT.

Step 4 — Configuring the DNS Records Required to Enable MTA-STS and TLSRPT

In this step, you’ll configure two DNS TXT records, which will fully enable the MTA-STS policy that you have already created, and also enable TLS Reporting (TLSRPT).

These DNS records can be configured using any DNS hosting provider, but in this example, DigitalOcean is used as the provider.

Firstly, log on to your DigitalOcean control panel and navigate to your project, followed by clicking on your domain.

You then need to add the following two TXT records:

_mta-sts.your-domain IN TXT "v=STSv1; id=id-value" _smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=reporting-address" 

id-value is a string used to identify the version of your MTA-STS policy in place. If you update your policy, you’ll need to also update the id value to ensure that the new version is detected by mail providers. It is recommended to use the current date stamp as the id, for example 20190811231231 (23:12:31 on 11th Aug 2019).

reporting-address is the address where your TLS reports will be sent to. This can be either an email address prefixed with mailto:, or a web URI, for example for an API that collects reports. The reporting address doesn’t have to be an address on your-domain. You may use a completely different domain if you wish.

For example, the following two sample records are both valid:

_mta-sts.your-domain IN TXT "v=STSv1; id=20190811231231" _smtp._tls.your-domain IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@your-domain" 

Adjust the variables as required, and set these DNS TXT records in your DigitalOcean control panel (or whichever DNS provider you’re using):

A screenshot of the DigitalOcean control panel, showing the _mta-sts DNS TXT record being set.

A screenshot of the DigitalOcean control panel, showing the _smtp._tls DNS TXT record being set.

Once these DNS records have been set and have propagated, MTA-STS will be enabled with the policy that you created in Step 1, and will begin to receive TLSRPT reports at the address that you specified.

In this step, you configured the DNS records required for MTA-STS to be enabled. Next, you will receive and then interpret your first TLSRPT report.

Step 5 — Interpreting Your First TLSRPT Report

Now that you’ve enabled MTA-STS and TLSRPT (TLS Reporting) for your domain, you will begin to receive reports from supported email providers. These reports will show the number of emails that were or were not successfully delivered over TLS, and the reasons for any errors.

Different email providers send their reports at different times; for example, Google Mail sends their reports daily at around 10:00 UTC.

Depending on how you configured the TLSRPT DNS record in Step 5, you will either receive your reports via email, or via a web API. This tutorial focuses on the email method, as that is the most common configuration.

If you’ve just completed the rest of this tutorial, wait until you receive your first report, then you can resume.

Your daily TLSRPT report via email will usually have a subject line similar to the following:

Report Domain: your-domain Submitter: google.com Report-ID: <2019.08.10T00.00.00Z+your-domain@google.com> 

This email will have an attachment in .gz format, which is a Gzip compressed archive, with a file name similar to the following:

google.com!your-domain!1565222400!1565308799!001.json.gz 

For the rest of this tutorial this file will be referred to as report.json.gz.

Save this file to your local machine, and extract it using whichever tool you prefer.

If you’re using a Debian-based Linux system, you will be able to run the gzip -d command to decompress the archive:

  • gzip -d report.json.gz

This will result in a JSON file called report.json.

Next, you can view the report either directly as the raw JSON string, or use your favorite JSON prettifier to put it into a more readable format. In this example, jq will be used, but you could also use Python’s json.tool if you wish.

Note: If you don’t have jq installed, you can install it using apt install jq. Or, for other operating systems use the necessary installation instructions from jq.

  • jq . report.json

This will output something similar to the following:

Prettified report.json
{ "organization-name": "Google Inc.", "date-range": { "start-datetime": "2019-08-10T00:00:00Z", "end-datetime": "2019-08-10T23:59:59Z" }, "contact-info": "smtp-tls-reporting@google.com", "report-id": "2019-08-10T00:00:00Z_your-domain", "policies": [ { "policy": { "policy-type": "sts", "policy-string": [ "version: STSv1", "mode: testing", "mx: mail1.your-domain", "mx: mail2.your-domain", "max_age: 86401" ], "policy-domain": "your-domain" }, "summary": { "total-successful-session-count": 230, "total-failure-session-count": 0 } } ] }

The report shows the provider that generated the report and the reporting period, as well as the MTA-STS policy that was applied. However, the main section that you’ll be interested in is summary, specifically the successful and failed session counts.

This sample report shows that 230 emails were successfully delivered over TLS from the mail provider that generated the report, and 0 email deliveries failed to establish a proper TLS connection.

In the event that there is a failure—for example, if a TLS certificate expires or there is an attacker on the network—the failure mode will be documented in the report. Some examples of failure modes are:

  • starttls-not-supported: If the receiving mail server doesn’t support STARTTLS.
  • certificate-expired: If a certificate has expired.
  • certificate-not-trusted: If a self-signed or other non-trusted certificate is used.

In this final step, you received and then interpreted your first TLSRPT report.

Conclusion

In this article you set up and configured MTA-STS and TLS Reporting for your domain, and interpreted your first TLSRPT report.

Once MTA-STS has been enabled and working stably for a while, it is recommended to adjust the policy, increasing the max_age value, and eventually switching it to enforce mode once you are sure that all email from supported providers is being delivered successfully over TLS.

Finally, if you’d like to learn more about the MTA-STS and TLSRPT specifications, you can review the RFCs for both of them:

DigitalOcean Community Tutorials