systemd, rsyslogd - onde estão os logs?

Question

Eu tenho uma instalação da edição do Fedora 23 Server, na qual não fiz praticamente nada com o administrador, além de configurar ssh , fail2ban , samba e usuários.

Outro dia eu estava completamente fora do meu sistema com a mensagem ssh_exchange_identification: read: Connection reset by peer , que com algum googling me levou a ssh_exchange_identification: read: Conexão redefinida pelo peer

Então eu assumi que fail2ban tinha estragado o banimento. Não é nada demais, basta fazer o login na máquina 'fisicamente' e redefini-los. Ao tentar fazer isso, vejo meu console ficar inundado com uma mensagem de log (que não me lembro, "systemd.service algo algo somente leitura-read"). Essa inundação tornou impossível o login. Comecei a digitar minhas credenciais, apenas para quebrá-las porque uma mensagem de log seria impressa e redefinir as credenciais.

Eu fui forçado a um hard-reboot, ie. pressione o botão de reinicialização / mantenha pressionado o botão liga / desliga na máquina.

Como eu quero chegar ao fundo do problema e descobrir qual foi o problema, eu fiz algumas buscas. Parece que não consigo encontrar a causa, no entanto.

Se eu journalctl --since 2016-04-10 obtenho o seguinte

Apr 10 12:19:32 Server smartd[620]: Device: /dev/sdc [SAT], 47 Currently unreadable (pending) sectors
-- Reboot --
Apr 11 20:27:53 Server systemd-journal[148]: Runtime journal is using 8.0M (max allowed 81.0M, trying to leave 121.5M free of 802.5M available → current limit 81.0M).

Eu abandonei todos os logs, quando presumo que os tróbicos começaram, até que fiz o hard-reboot. (A unidade /dev/sdc tem dado esse erro desde que eu peguei)

Eu também leio no link que você deve verificar /var/log/messages para registros.

As partes relevantes aqui que eu posso ver são

Mar  6 18:52:49 Server audit: USER_AUTH pid=3435 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/sbin/sshd" hostname=183.3.202.108 addr=183.3.202.108 terminal=ssh res=failed'
Apr 11 20:28:46 Server rsyslogd-2177: imjournal: begin to drop messages due to rate-limiting
Apr 11 20:39:15 Server rsyslogd-2177: imjournal: 91404 messages lost due to rate-limiting
Apr 11 20:39:15 Server dnf: repo: using cache for: rpmfusion-free

O que me diz que havia 91404 mensagens de log. Eu não consigo encontrar um único deles no entanto. Todos foram descartados até onde eu sei.

Desde que eu quero saber o que realmente 'quebrou' meu sistema, existe algum outro lugar em que os logs possam ser armazenados? Ou eu só tenho que rezar para que as estrelas não se alinhem para causar o mesmo problema novamente?

    

Answer 1

NOTA: sem mais evidências para confirmar minha suspeita, isso é apenas uma especulação hipotética.

Você mencionou ter visto algo sobre "somente leitura". É possível que seu sistema tenha encontrado danos irrecuperáveis ou uma falha de hardware no disco (ou uma interface de cabo ou sata, etc.) e remontou a raiz fs como readonly para evitar mais danos / danos.

As coisas mais importantes que você precisa fazer o mais rápido possível são: 1. certificar-se de que seus backups estão atualizados; 2. testar seu (s) disco (s) minuciosamente (por exemplo, com smartctl test) ou estar prestes a falhar.

Mas, voltando ao problema do registro:

Se a raiz fs (ou /var/log ) for somente leitura, nenhum registro será gravado no disco.

Se você tiver outro sistema para o qual você possa encaminhar mensagens de log, eu recomendaria configurar o rsyslog para fazer o login em arquivos locais e em um sistema remoto. Esta máquina também pode fornecer o mesmo serviço ao sistema remoto.

por exemplo. em dois dos meus sistemas ( ganesh e kali ), tenho o seguinte em /etc/rsyslog.d/00remote.conf :

$ModLoad imudp   # provides UDP syslog reception
$UDPServerAddress 0.0.0.0
$UDPServerRun 514 

if $fromhost-ip == '127.0.0.1' and $syslogfacility-text == 'kern' then @kali

Esse é o arquivo como está em ganesh . em kali , é idêntico, exceto que @kali é substituído por @ganesh .

Isso encaminha todas as entradas de log kern do recurso originadas do host local para o host de registro remoto. A verificação do endereço IP impede um colapso do loop de registro remoto.

Existem outras maneiras de configurar o log remoto com rsyslog , incluindo o log% tcp em vez de udp . Este é apenas o primeiro método que experimentei quando precisei dele anos atrás - funcionou e foi simples, e ainda não tive necessidade de alterá-lo. Pesquise neste site para outros métodos e mais detalhes.

BTW, certifique-se de que o tráfego de entrada para a porta 514 do UDP esteja bloqueado no seu firewall.