108.2 Lição 1

Certificação:

LPIC-1

Versão:

5.0

Tópico:

108 Serviços essenciais do sistema

Objetivo:

108.2 Registro de eventos do sistema

Lição:

1 de 2

Introdução

Os logs (registros de eventos do sistema) são os melhores amigos do administrador do sistema. Logs são arquivos (geralmente arquivos de texto) nos quais todos os eventos do sistema e da rede são registrados em ordem cronológica a partir do momento em que o sistema é inicializado. Assim, a gama de informações que podem ser encontradas nos logs inclui virtualmente todos os aspectos do sistema: tentativas de autenticação malsucedidas, erros de programas e serviços, hosts bloqueados pelo firewall, etc. Como você pode imaginar, os logs facilitam muito a vida dos administradores de sistema quando se trata de resolução de problemas, verificação de recursos, detecção de comportamento anômalo de programas e assim por diante.

Nesta lição, discutiremos um dos recursos de log mais comuns presentes atualmente nas distribuições GNU/Linux: o rsyslog. Estudaremos os diferentes tipos de logs existentes, onde são armazenados, quais informações incluem e como essas informações podem ser obtidas e filtradas. Também discutiremos como os logs podem ser mantidos em servidores centralizados em redes IP, rotação de log e o buffer de anel do kernel.

Logs do sistema

No momento em que o kernel e os diferentes processos em seu sistema começam a rodar e a se comunicar uns com os outros, muitas informações são geradas na forma de mensagens que são — em sua maioria — enviadas para os logs.

Sem os logs, os administradores de sistema teriam de descascar uma floresta de abacaxis sempre que precisassem procurar um evento que aconteceu em um servidor, donde a importância de se ter uma maneira padronizada e centralizada de rastrear e controlar quaisquer eventos do sistema. Os logs são determinantes e reveladores quando se trata de solucionar problemas e manter a segurança, além de serem fontes de dados confiáveis para se compreender as estatísticas do sistema e fazer previsões de tendências.

Deixando de lado o systemd-journald (que discutiremos na próxima lição), os logs tradicionalmente são tratados por três serviços dedicados principais: syslog, syslog-ng (syslog nova geração) e rsyslog (“o sistema mais veloz para processamento de log”). O rsyslog trouxe melhorias importantes (como suporte a RELP) e se tornou a escolha mais popular hoje em dia. Esses serviços coletam mensagens de outros serviços e programas e as armazenam em arquivos de log, normalmente em /var/log. No entanto, alguns serviços cuidam de seus próprios logs (por exemplo, o servidor web Apache HTTPD ou o sistema de impressão CUPS). Da mesma forma, o kernel do Linux usa um buffer de anel na memória para armazenar suas mensagens de log.

Note	`RELP` significa Reliable Event Logging Protocol (Protocolo confiável de registro de eventos em log) e estende a funcionalidade do protocolo syslog de maneira a assegurar a entrega de mensagens.

Como o rsyslog se tornou o recurso de log padrão de fato em todas as principais distros, vamos nos concentrar nele nesta lição. O rsyslog usa um modelo cliente-servidor. O cliente e o servidor podem existir no mesmo host ou em máquinas diferentes. As mensagens são enviadas e recebidas em um formato específico e podem ser mantidas em servidores rsyslog centralizados em redes IP. O daemon do rsyslog — rsyslogd — trabalha junto com o klogd (que gerencia as mensagens do kernel). Nas próximas seções, discutiremos o rsyslog e sua infraestrutura de registro de eventos.

Note	Um daemon é um serviço executado em segundo plano . Observe o `d` final nos nomes dos daemons: `klogd` or `rsyslogd`.

Tipos de log

Como os logs são dados variáveis, costumam ser encontrados em /var/log. Grosso modo, podem ser classificados em logs do sistema e logs de serviços ou programas.

Vamos conhecer alguns logs do sistema e as informações que eles preservam:

/var/log/auth.log: Atividades relacionadas aos processos de autenticação: usuários registrados, informações de sudo, cron jobs, tentativas de login malsucedidas etc.
/var/log/syslog: Um arquivo centralizado para praticamente todos os logs capturados pelo rsyslogd. Por incluir muitas informações, os logs são distribuídos por outros arquivos de acordo com a configuração fornecida em /etc/rsyslog.conf.
/var/log/debug: Informações de depuração dos programas.
/var/log/kern.log: Mensagens do kernel.
/var/log/messages: Mensagens informativas que não estão relacionadas ao kernel, mas a outros serviços. É também o destino padrão do log do cliente remoto em uma implementação de servidor de log centralizado.
/var/log/daemon.log: Informações relacionadas aos daemons ou serviços em execução em segundo plano.
/var/log/mail.log: Informações relacionadas ao servidor de email, por exemplo o postfix.
/var/log/Xorg.0.log: Informações relacionadas à placa de vídeo.
/var/run/utmp e /var/log/wtmp: Logins bem-sucedidos.
/var/log/btmp: Tentativas de login malsucedidas, por exemplo ataques de força bruta via ssh.
/var/log/faillog: Tentativas de autenticação malsucedidas.
/var/log/lastlog: Data e hora dos logins recentes do usuário.

Vejamos agora alguns exemplos de logs de serviço:

/var/log/cups/: Diretório para logs do Common Unix Printing System. Geralmente inclui os seguintes arquivos de log padrão: error_log, page_log e access_log.
/var/log/apache2/ or /var/log/httpd: Diretório para logs do Apache Web Server. Geralmente inclui os seguintes arquivos de log padrão: access.log, error_log e other_vhosts_access.log.
/var/log/mysql: Diretório para logs do MySQL Relational Database Management System. Geralmente inclui os seguintes arquivos de log padrão: error_log, mysql.log e mysql-slow.log.
/var/log/samba/: Diretório para logs do protocolo Session Message Block (SMB). Geralmente inclui os seguintes arquivos de log padrão: log., log.nmbd and log.smbd.

Note	O nome e o conteúdo exatos dos arquivos de log podem variar de acordo com as distribuições Linux. Existem também logs específicos para distribuições específicas como `/var/log/dpkg.log` (contendo informações relacionadas aos pacotes `dpkg`) no Debian GNU/Linux e seus derivados.

Lendo logs

Para ler os arquivos de log, é preciso ser o usuário root ou ter permissões de leitura para o arquivo. Podemos usar uma variedade de utilitários, como:

less ou more

Paginadores que permitem visualizar e rolar uma página por vez:

root@debian:~# less /var/log/auth.log
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:49:46 debian sshd[905]: Accepted password for carol from 192.168.1.65 port 44296 ssh2
Sep 12 18:49:46 debian sshd[905]: pam_unix(sshd:session): session opened for user carol by (uid=0)
Sep 12 18:49:46 debian systemd-logind[331]: New session 2 of user carol.
Sep 12 18:49:46 debian systemd: pam_unix(systemd-user:session): session opened for user carol by (uid=0)
(...)

zless or zmore

O mesmo que less e more, mas usados para logs que foram compactados com o gzip (uma função comum de logrotate):

root@debian:~# zless /var/log/auth.log.3.gz
Aug 19 20:05:57 debian sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/sbin/shutdown -h now
Aug 19 20:05:57 debian sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Aug 19 20:05:57 debian lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event2 (Power Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event3 (Sleep Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event4 (Video Bus)
Aug 19 23:50:49 debian systemd-logind[333]: New seat seat0.
Aug 19 23:50:49 debian sshd[409]: Server listening on 0.0.0.0 port 22.
(...)

tail

Visualizar as últimas linhas de um arquivo (por padrão, 10 linhas). O poder de tail reside — em grande parte — na opção -f, que mostra novas linhas dinamicamente conforme elas são anexadas:

root@suse-server:~# tail -f /var/log/messages
2019-09-14T13:57:28.962780+02:00 suse-server sudo: pam_unix(sudo:session): session closed for user root
2019-09-14T13:57:38.038298+02:00 suse-server sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/messages
2019-09-14T13:57:38.039927+02:00 suse-server sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
2019-09-14T14:07:22+02:00 debian carol: appending new message from client to remote server...

head

Visualizar as primeiras linhas de um arquivo (por padrão, 10 linhas):

root@suse-server:~# head -5 /var/log/mail
2019-06-29T11:47:59.219806+02:00 suse-server postfix/postfix-script[1732]: the Postfix mail system is not running
2019-06-29T11:48:01.355361+02:00 suse-server postfix/postfix-script[1925]: starting the Postfix mail system
2019-06-29T11:48:01.391128+02:00 suse-server postfix/master[1930]: daemon started -- version 3.3.1, configuration /etc/postfix
2019-06-29T11:55:39.247462+02:00 suse-server postfix/postfix-script[3364]: stopping the Postfix mail system
2019-06-29T11:55:39.249375+02:00 suse-server postfix/master[1930]: terminating on signal 15

grep

Utilitário de filtragem que permite buscar por strings específicas:

root@debian:~# grep "dhclient" /var/log/syslog
Sep 13 11:58:48 debian dhclient[448]: DHCPREQUEST of 192.168.1.4 on enp0s3 to 192.168.1.1 port 67
Sep 13 11:58:49 debian dhclient[448]: DHCPACK of 192.168.1.4 from 192.168.1.1
Sep 13 11:58:49 debian dhclient[448]: bound to 192.168.1.4 -- renewal in 1368 seconds.
(...)

Como você deve ter notado, a saída é impressa no seguinte formato:

Carimbo de data/hora
Nome do host a partir do qual a mensagem se originou
Nome do programa/serviço que gerou a mensagem
O PID do programa que gerou a mensagem
Descrição da ação que ocorreu

Existem alguns exemplos em que os registros não são em forma de texto, mas arquivos binários e — conseqüentemente — você deverá usar comandos especiais para analisá-los:

/var/log/wtmp

Use who (ou w):

root@debian:~# who
root    pts/0        2020-09-14 13:05 (192.168.1.75)
root    pts/1        2020-09-14 13:43 (192.168.1.75)

/var/log/btmp

Use utmpdump ou last -f:

root@debian:~# utmpdump /var/log/btmp
Utmp dump of /var/log/btmp
[6] [01287] [    ] [dave     ] [ssh:notty   ] [192.168.1.75        ] [192.168.1.75   ] [2019-09-07T19:33:32,000000+0000]

/var/log/faillog

Use faillog:

root@debian:~# faillog -a | less
Login       Failures Maximum Latest                   On

root            0        0   01/01/70 01:00:00 +0100
daemon          0        0   01/01/70 01:00:00 +0100
bin             0        0   01/01/70 01:00:00 +0100
sys             0        0   01/01/70 01:00:00 +0100
sync            0        0   01/01/70 01:00:00 +0100
games           0        0   01/01/70 01:00:00 +0100
man             0        0   01/01/70 01:00:00 +0100
lp              0        0   01/01/70 01:00:00 +0100
mail            0        0   01/01/70 01:00:00 +0100
(...)

/var/log/lastlog

Use lastlog:

root@debian:~# lastlog | less
Username         Port     From             Latest
root                                       Never logged in
daemon                                     Never logged in
bin                                        Never logged in
sys                                        Never logged in
(...)
sync                                       Never logged in
avahi                                      Never logged in
colord                                     Never logged in
saned                                      Never logged in
hplip                                      Never logged in
carol            pts/1    192.168.1.75     Sat Sep 14 13:43:06 +0200 2019
dave             pts/3    192.168.1.75     Mon Sep  2 14:22:08 +0200 2019

Note	Também existem ferramentas gráficas para ler arquivos de log, como `gnome-logs` e `KSystemLog`.

Como as mensagens são transformadas em logs

O processo a seguir ilustra como uma mensagem é gravada em um arquivo de log:

Aplicativos, serviços e o kernel gravam mensagens em arquivos especiais (sockets e buffers de memória), por exemplo, /dev/log ou /dev/kmsg.
O rsyslogd obtém as informações dos sockets ou buffers de memória.
Dependendo das regras encontradas em /etc/rsyslog.conf e/ou dos arquivos em /etc/ryslog.d/, o rsyslogd move as informações para o arquivo de log correspondente (normalmente encontrado em /var/log).

Note	Um socket é um arquivo especial usado para transferir informações entre diferentes processos. Para listar todos os sockets em seu sistema, você pode usar o comando `systemctl list-sockets --all`.

Recursos, prioridades e ações

O arquivo de configuração de rsyslog é /etc/rsylog.conf (em algumas distribuições, também podemos encontrar arquivos de configuração em /etc/rsyslog.d/). Ele normalmente é dividido em três seções: MODULES, GLOBAL DIRECTIVES e RULES. Vamos dar uma olhada neles explorando o arquivo rsyslog.conf em nosso host GNU/Linux 10 (buster) host — para isso, usamos sudo less /etc/rsyslog.conf.

MODULES inclui suporte modular para registro de eventos, capacidade de mensagem e recepção de log UDP/TCP:

#################
#### MODULES ####
#################

module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
#module(load="immark")  # provides --MARK-- message capability

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")

GLOBAL DIRECTIVES permite configurar uma série de coisas, como logs e permissões de diretório de log:

###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

RULES é onde entram os recursos, prioridades e ações. As configurações desta seção dizem ao daemon de log para filtrar mensagens de acordo com certas regras e registrá-las no log ou enviá-las quando necessário. Para entender essas regras, devemos primeiro explicar os conceitos de recursos e prioridades do rsyslog. Cada mensagem de log recebe um número de recurso (facility) e uma palavra-chave, ambos associados ao subsistema interno do Linux que produz a mensagem:

Número Palavra-chave Descrição

0

kern

Mensagens do kernel do Linux

1

user

Mensagens no nível do usuário

2

mail

Sistema de email

3

daemon

Daemons do sistema

4

auth, authpriv

Mensagens de segurança/autorização

5

syslog

Mensagens do syslogd

6

lpr

Subsistema de impressora de linha

7

news

Subsistema de notícias da rede

8

uucp

Subsistema UUCP (Unix-to-Unix Copy Protocol)

9

cron

Daemon do relógio

10

auth, authpriv

Mensagens de segurança/autorização

11

ftp

Daemon FTP (File Transfer Protocol)

12

ntp

Daemon NTP (Network Time Protocol)

13

security

Auditoria do log

14

console

Alerta do log

15

cron

Daemon do relógio

16 - 23

local0 até local7

Uso local 0 - 7

Além disso, cada mensagem recebe um nível de prioridade:

Código Gravidade Palavra-chave Descrição

0

Emergência

emerg, panic

O sistema está inutilizável

1

Alerta

alert

É necessário agir imediatamente

2

Crítico

crit

Condições críticas

3

Erro

err, error

Condições de erro

4

Aviso

warn, warning

Condições de aviso

5

Atenção

notice

Condição normal, mas com alguma importância

6

Informativo

info

Mensagens informativas

7

Debug

debug

Mensagens de nível de depuração

Eis um trecho do rsyslog.conf de nosso sistema Debian GNU/Linux 10 (buster) que inclui alguns exemplos de regras:

###############
#### RULES ####
###############

# First some standard log files.  Log by facility.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

#
# Some "catch-all" log files.
#
*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
	cron,daemon.none;\
	mail,news.none          -/var/log/messages

O formato das regras é o seguinte: <facility>.<priority> <action>

O seletor <facility>.<priority> filtra as mensagens correspondentes. Os níveis de prioridade são hierarquicamente inclusivos, o que significa que o rsyslog vai procurar mensagens com a prioridade especificada e superiores. O <action> mostra qual ação tomar (para onde enviar a mensagem de log). Aqui estão alguns exemplos para maior clareza:

auth,authpriv.*                 /var/log/auth.log

Independentemente de sua prioridade (*), todas as mensagens dos recursos auth ou authpriv serão enviadas para /var/log/auth.log.

*.*;auth,authpriv.none          -/var/log/syslog

Todas as mensagens — independentemente de sua prioridade (*) — de todos os recursos (*) — excetuando-se as de auth ou authpriv (por isso o sufixo .none) — serão gravadas em /var/log/syslog (o sinal de menos (-) antes do caminho evita gravações em disco excessivas). Note o ponto e vírgula (;) para dividir o seletor e a vírgula (,) para concatenar dois recursos na mesma regra (auth,authpriv).

mail.err                        /var/log/mail.err

As mensagens do recurso mail com um nível de prioridade de error ou superior (critical, alert ou emergency) serão enviadas para /var/log/mail.err.

*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug

As mensagens de todos os recursos com a prioridade debug e nenhuma outra (=) serão gravadas em /var/log/debug — excluindo-se todas as mensagens que venham dos recursos auth, authpriv, news e mail (note a sintaxe: ;\).

Entradas manuais no log do sistema: `logger`

O comando logger é prático para scripts do shell ou para testes. O logger anexa todas as as mensagens recebidas a /var/log/syslog (ou a /var/log/messages quando o registro for feito em um servidor de log remoto centralizado, como veremos mais adiante):

carol@debian:~$ logger this comment goes into "/var/log/syslog"

Para imprimir a última linha de /var/log/syslog, use o comando tail com a opção -1:

root@debian:~# tail -1 /var/log/syslog
Sep 17 17:55:33 debian carol: this comment goes into /var/log/syslog

`rsyslog` como servidor central de log

Para explicar este tópico, vamos adicionar um novo host à nossa configuração. O layout é o seguinte:

Papel Nome do host SO Endereço IP

Servidor de log central

suse-server

openSUSE Leap 15.1

192.168.1.6

Cliente

debian

Debian GNU/Linux 10 (buster)

192.168.1.4

Vamos começar configurando o servidor. Em primeiro lugar, verificamos se rsyslog está instalado e funcionando:

root@suse-server:~# systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-17 18:45:58 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 832 (rsyslogd)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─832 /usr/sbin/rsyslogd -n -iNONE

O openSUSE vem com um arquivo de configuração dedicado para log remoto: /etc/rsyslog.d/remote.conf. Vamos habilitar o recebimento de mensagens de clientes (hosts remotos) via TCP. Precisamos descomentar as linhas que carregam o módulo e iniciar o servidor TCP na porta 514:

# ######### Receiving Messages from Remote Hosts ##########
# TCP Syslog Server:
# provides TCP syslog reception and GSS-API (if compiled to support it)
$ModLoad imtcp.so  # load module
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
$InputTCPServerRun 514  # Starts a TCP server on selected port

# UDP Syslog Server:
#$ModLoad imudp.so  # provides UDP syslog reception
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
#$UDPServerRun 514  # start a UDP syslog server at standard port 514

Feito isso, precisamos reiniciar o serviço rsyslog e verificar se o servidor está escutando na porta 514:

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# netstat -nltp | grep 514
[sudo] password for root:
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      2263/rsyslogd
tcp6       0      0 :::514                  :::*                    LISTEN      2263/rsyslogd

Em seguida, vamos abrir as portas no firewall e recarregar a configuração:

root@suse-server:~# firewall-cmd --permanent --add-port 514/tcp
success
root@suse-server:~# firewall-cmd --reload
success

Note	Com a chegada do openSUSE Leap 15.0, `firewalld` substituiu inteiramente o clássico `SuSEFirewall2`.

Modelos e condições de filtragem

Por padrão, os logs do cliente serão gravados no arquivo /var/log/messages do servidor — junto com os do próprio servidor. Porém, nós vamos criar um modelo e uma condição de filtragem para armazenar os logs de nosso cliente em diretórios próprios. Para isso, adicionamos o seguinte a /etc/rsyslog.conf (ou /etc/rsyslog.d/remote.conf):

$template RemoteLogs,"/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log"
if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
& stop

Modelo

O modelo corresponde à primeira linha e permite especificar um formato para os nomes de log usando a geração dinâmica de nomes de arquivo. Um modelo consiste em:

Diretriz do modelo ($template)
Nome do modelo (RemoteLogs)
Texto do modelo ("/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log")
Opções (opcional)

Nosso modelo se chama RemoteLogs e seu texto consiste em um caminho em /var/log. Todos os logs de nosso host remoto irão para o diretório remotehosts, onde um subdiretório será criado com base no nome de host da máquina (%HOSTNAME%). Os nomes de arquivos neste diretório consistirão na data (%$NOW%), na gravidade (ou seja, a prioridade) da mensagem em formato de texto (%syslogseverity-text%) e no sufixo .log. As palavras entre os símbolos de porcentagem são propriedades e permitem acessar o conteúdo da mensagem de log (data, prioridade, etc.). Uma mensagem de syslog tem uma série de propriedades bem definidas que podem ser usadas em modelos. Essas propriedades são acessadas — e podem ser modificadas — pelo chamado substituidor de propriedades, que implica em escrevê-las entre símbolos de porcentagem.

Condição de filtragem

As duas linhas restantes correspondem à condição de filtragem e à ação que lhe é associada:

Filtro baseado na expressão (if $FROMHOST-IP=='192.168.1.4')
Ação (then ?RemoteLogs, & stop)

A primeira linha verifica o endereço IP do host remoto enviando o log e — se ele for igual ao de nosso cliente Debian — aplica o modelo RemoteLogs. A última linha (& stop) garante que as mensagens não estão sendo enviadas simultaneamente para /var/log/messages (mas apenas para arquivos no diretório /var/log/remotehosts).

Note	Para saber mais sobre modelos, propriedades e regras, você pode consultar a página de manual de `rsyslog.conf`.

Com a configuração atualizada, reiniciamos o rsyslog novamente e confirmamos que ainda não existe um diretório remotehosts em /var/log:

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# ls /var/log/
acpid             chrony     localmessages   pbl.log          Xorg.0.log
alternatives.log  cups       mail            pk_backend_zypp  Xorg.0.log.old
apparmor          firebird   mail.err        samba            YaST2
audit             firewall   mail.info       snapper.log      zypp
boot.log          firewalld  mail.warn       tallylog         zypper.log
boot.msg          krb5       messages        tuned
boot.omsg         lastlog    mysql           warn
btmp              lightdm    NetworkManager  wtmp

O servidor agora está configurado. A seguir, vamos configurar o cliente.

Novamente, precisamos verificar se rsyslog está instalado e em execução:

root@debian:~# sudo systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset:
   Active: active (running) since Thu 2019-09-17 18:47:54 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 351 (rsyslogd)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─351 /usr/sbin/rsyslogd -n

Em nosso ambiente de exemplo, implementamos a resolução de nomes no cliente adicionando a linha 192.168.1.6 suse-server a /etc/hosts. Assim, podemos nos referir ao servidor por nome (suse-server) ou endereço IP (192.168.1.6).

Nosso cliente Debian não veio com um arquivo remote.conf em /etc/rsyslog.d/, então aplicaremos nossas configurações em /etc/rsyslog.conf. Vamos incluir a seguinte linha no final do arquivo:

*.* @@suse-server:514

Finalmente, reiniciamos rsyslog.

root@debian:~# systemctl restart rsyslog

Agora, voltamos à nossa máquina suse-server e verificamos a existência de remotehosts em /var/log:

root@suse-server:~# ls /var/log/remotehosts/debian/
2019-09-17.info.log  2019-09-17.notice.log

Já temos dois logs em /var/log/remotehosts, conforme descrito em nosso modelo. Para completar esta parte, executamos tail -f 2019-09-17.notice.log em suse-server enquanto enviamos um log manualmente de nosso cliente Debian e confirmamos que as mensagens são anexadas ao arquivo de log como esperado (a opção -t fornece uma etiqueta para a mensagem):

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)

carol@debian:~$ logger -t DEBIAN-CLIENT Hi from 192.168.1.4

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)
2019-09-17T21:04:21+02:00 debian DEBIAN-CLIENT: Hi from 192.168.1.4

O mecanismo de rotação do log

Os logs são rotacionados regularmente, o que serve a dois propósitos principais:

Evitar que arquivos de log antigos usem mais espaço em disco do que o necessário.
Manter os registros em um tamanho gerenciável para facilitar a consulta.

O utilitário responsável pela rotação de log é logrotate. Dentre suas responsabilidades estão ações como mover arquivos de log para um novo nome, arquivá-los e/ou compactá-los, às vezes enviando-os por email para o administrador do sistema e, eventualmente, excluí-los quando ficam obsoletos. Existem diversas convenções para nomear esses arquivos de log rotacionados (por exemplo, adicionar um sufixo com a data ao nome do arquivo); no entanto, a prática mais comum é simplesmente adicionar um sufixo com um número inteiro:

root@debian:~# ls /var/log/messages*
/var/log/messages  /var/log/messages.1  /var/log/messages.2.gz  /var/log/messages.3.gz  /var/log/messages.4.gz

Vamos agora explicar o que acontecerá na próxima rotação do log:

messages.4.gz será excluído e perdido.
O conteúdo de messages.3.gz será movido para messages.4.gz.
O conteúdo de messages.2.gz será movido para messages.3.gz.
O conteúdo de messages.1 será movido para messages.2.gz.
O conteúdo de messages será movido para messages.1 e messages estará vazio e pronto para registrar novas entradas de log.

Observe como — de acordo com as diretrizes de logrotate que veremos em breve — os três arquivos de log mais antigos são compactados, mas os dois mais recentes não. Além disso, preservamos os registros das últimas 4-5 semanas. Para ler mensagens com 1 semana de idade, consultamos messages.1 (e assim por diante).

O logrotate é executado diariamente como um processo automatizado ou cron job por meio do script /etc/cron.daily/logrotate. Ele consulta o arquivo de configuração /etc/logrotate.conf. Este arquivo inclui algumas opções globais e é bem comentado; cada opção é apresentada por uma breve explicação de sua finalidade:

carol@debian:~$ sudo less /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

(...)

Como vemos, os arquivos de configuração em /etc/logrotate.d para pacotes específicos também estão incluídos. Esses arquivos contêm — na maioria — definições locais e especificam os arquivos de log a serem rotacionados (lembre-se, as definições locais têm precedência sobre as globais e as definições mais novas substituem as mais antigas). O que se segue é um trecho de uma definição em /etc/logrotate.d/rsyslog:

/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Como vemos, cada diretriz é separada de seu valor por um espaço em branco e/ou um sinal de igual opcional (=). As linhas entre postrotate e endscript, porém, devem aparecer em linhas próprias. A explicação é a seguinte:

rotate 4: Preserva 4 semanas de logs.
weekly: Rotaciona arquivos de log semanalmente.
missingok: Não emite uma mensagem de erro se o arquivo de log estiver ausente; simplesmente passa para o seguinte.
notifempty: Não rotaciona o log se estiver vazio.
compress: Compacta arquivos de log com o gzip (padrão).
delaycompress: Adia a compactação do arquivo de log anterior para o próximo ciclo de rotação (válido apenas quando usado em combinação com compress). Útil quando um programa não pode ser instruído a fechar seu arquivo de log e, portanto, pode continuar gravando no arquivo de log anterior por algum tempo.
sharedscripts: Relacionado aos scripts prerotate e postrotate. Para evitar que um script seja executado várias vezes, esse comando executa os scripts apenas uma vez, independentemente de quantos arquivos de log correspondem a um determinado padrão (por exemplo, /var/log/mail/*). Porém, os scripts não serão executados se nenhum dos logs no padrão requerir a rotação. Além disso, se os scripts forem encerrados com erros, as ações restantes não serão executadas em nenhum log.
postrotate: Indica o início de um script postrotate.
invoke-rc.d rsyslog rotate > /dev/null: Usa /bin/sh para executar invoke-rc.d rsyslog rotate > /dev/null depois de rotacionar os logs.
endscript: Indica o fim do script postrotate.

Note	Para uma lista completa de diretrizes e explicações, consulte a página de manual de `logrotate.conf`.

O buffer de anel do kernel

Uma vez que o kernel gera diversas mensagens antes de rsyslogd se tornar disponível na inicialização, torna-se necessário um mecanismo para registrar essas mensagens. É aqui que o buffer de anel do kernel entra em ação. Trata-se de uma estrutura de dados de tamanho fixo e — portanto — à medida que novas mensagens são gravadas, as mais antigas vão desaparecendo.

O comando dmesg imprime o buffer de anel do kernel. Devido ao tamanho do buffer, este comando é normalmente usado em combinação com o utilitário de filtragem de texto grep. Por exemplo, para pesquisar mensagens relacionadas a dispositivos Universal Serial Bus:

root@debian:~# dmesg | grep "usb"
[    1.241182] usbcore: registered new interface driver usbfs
[    1.241188] usbcore: registered new interface driver hub
[    1.250968] usbcore: registered new device driver usb
[    1.339754] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.19
[    1.339756] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
(...)

Exercícios Guiados

Quais utilitários/comandos você usaria nos seguintes contextos:

Finalidade e arquivo de log Utilitário

Ler /var/log/syslog.7.gz

Ler /var/log/syslog

Filtrar pela palavra renewal em /var/log/syslog

Ler /var/log/faillog

Ler /var/log/syslog dinamicamente

Reorganize as seguintes entradas de registro de forma que representem uma mensagem de registro válida com a estrutura apropriada:
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  A ordem correta é:
Quais regras você adicionaria a /etc/rsyslog.conf para realizar as seguintes tarefas:
- Enviar todas as mensagens do recurso mail e uma prioridade/gravidade de crit (e acima) para /var/log/mail.crit:
- Enviar todas as mensagens do recurso mail com prioridades de alert e emergency para /var/log/mail.urgent:
- Excetuando-se as mensagens vindas dos recursos cron e ntp, enviar todas as mensagens — independentemente de seu recurso e prioridade — para /var/log/allmessages:
- Com todas as configurações necessárias feitas apropriadamente, enviar todas as mensagens do recurso mail para um host remoto cujo endereço IP é 192.168.1.88 usando TCP e especificando a porta padrão:
- Independentemente do recurso, enviar todas as mensagens com a prioridade warning (somente com a prioridade warning) para /var/log/warnings, evitando gravações excessivas no disco:

Considere a estrofe a seguir de /etc/logrotate.d/samba e explique as diferentes opções:

carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba
/var/log/samba/log.smbd {
        weekly
        missingok
        rotate 7
        postrotate
                [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null
        endscript
        compress
        delaycompress
        notifempty
}

Opção Significado

weekly

missingok

rotate 7

postrotate

endscript

compress

delaycompress

notifyempty

Exercícios Exploratórios

Na seção “Modelos e condições de filtragem”, usamos um filtro baseado em expressão como condição de filtragem. Os filtros baseados em propriedades são outro tipo de filtro exclusivo ao rsyslogd. Traduza nosso filtro baseado em expressão como um filtro baseado em propriedades:

Filtro baseado em expressão Filtro baseado em propriedades

if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
omusrmsg é um módulo interno do rsyslog que facilita a notificação dos usuários (ele envia mensagens de log para o terminal do usuário). Escreva uma regra para enviar todas as mensagens de emergência de todas as instalações para root e para o usuário comum carol.

Resumo

Nesta lição, você aprendeu:

O registro de eventos é essencial para a administração do sistema.
rsyslogd é o utilitário encarregado de manter os logs limpos e organizados.
Alguns serviços cuidam de seus próprios logs.
Grosso modo, os logs podem ser classificados em logs do sistema e logs de serviços/programas.
Existem vários utilitários convenientes para a leitura de logs: less, more, zless, zmore, grep, head e tail.
A maioria dos arquivos de log são arquivos de texto simples; no entanto, existe um pequeno número de arquivos de log binários.
Em relação aos logs, o rsyslogd recebe as informações relevantes de arquivos especiais (sockets e buffers de memória) antes de processá-las.
Para classificar os logs, o rsyslogd usa as regras de /etc/rsyslog.conf ou /etc/rsyslog.d/*.
Qualquer usuário pode inserir suas próprias mensagens no log do sistema manualmente com o utilitário logger.
O rsyslog pwermite manter todos os logs de redes IP em um servidor de log centralizado.
Os modelos são úteis para formatar os nomes de arquivos de log de forma dinâmica.
A finalidade da rotação de log é dupla: evitar que logs antigos ocupem espaço excessivo em disco e facilitar a consulta de logs.

Respostas aos Exercícios Guiados

Quais utilitários/comandos você usaria nos seguintes contextos:

Finalidade e arquivo de log Utilitário

Ler /var/log/syslog.7.gz

zmore ou zless

Ler /var/log/syslog

more ou less

Filtrar pela palavra renewal em /var/log/syslog

grep

Ler /var/log/faillog

faillog -a

Ler /var/log/syslog dinamicamente

tail -f

Reorganize as seguintes entradas de registro de forma que representem uma mensagem de registro válida com a estrutura apropriada:
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  A ordem correta é:
  Sep 13 21:47:56 debian-server sshd[515]: Server listening on 0.0.0.0 port 22
Quais regras você adicionaria a /etc/rsyslog.conf para realizar as seguintes tarefas:
- Enviar todas as mensagens do recurso mail e uma prioridade/gravidade de crit (e acima) para /var/log/mail.crit:
  mail.crit /var/log/mail.crit
- Enviar todas as mensagens do recurso mail com prioridades de alert e emergency para /var/log/mail.urgent:
  mail.alert /var/log/mail.urgent
- Excetuando-se as mensagens vindas dos recursos cron e ntp, enviar todas as mensagens — independentemente de seu recurso e prioridade — para /var/log/allmessages:
  *.*;cron.none;ntp.none /var/log/allmessages
- Com todas as configurações necessárias feitas apropriadamente, enviar todas as mensagens do recurso mail para um host remoto cujo endereço IP é 192.168.1.88 usando TCP e especificando a porta padrão:
  mail.* @@192.168.1.88:514
- Independentemente do recurso, enviar todas as mensagens com a prioridade warning (somente com a prioridade warning) para /var/log/warnings, evitando gravações excessivas no disco:
  *.=warning -/var/log/warnings