Pular para o conteúdo principal

Um arquivo compactado do log de segurança baixado não abre

Sintoma​

Você baixou um arquivo compactado do log de segurança na guia Archived events (arquivos de eventos). O arquivo tem a extensão .csv.gz, mas não abre:

  • O descompactador informa "not in gzip format" ou "formato inválido".
  • O arquivo baixado é visivelmente maior do que o valor na coluna Size para essa linha de arquivo.
  • O checksum do arquivo baixado não corresponde ao sha256 mostrado na tabela.

As exportações comuns em CSV e JSON do mesmo log abrem sem problemas; apenas os arquivos compactados são afetados.

Como verificar​

Confirme que este é o problema que você está enfrentando. Verifique o tipo do arquivo e seu checksum e compare-o com o valor de referência na tabela de arquivos.

# 1. File type: an intact archive must start with the gzip signature 1f 8b
file security_log_*.csv.gz

# 2. First bytes: an intact gzip starts with "1f 8b 08 08 ..."
xxd security_log_*.csv.gz | head -1

# 3. Checksum of the downloaded file
shasum -a 256 security_log_*.csv.gz

Sinais de um arquivo corrompido:

  • file mostra data em vez de gzip compressed data.
  • O segundo byte da assinatura é diferente de 8b (por exemplo, foi substituído pelos três bytes ef bf bd).
  • O checksum da etapa 3 não corresponde ao valor sha256 na linha do arquivo.

O método da API security-event-archive-list também retorna o checksum de referência de cada arquivo (o campo sha256). É o mesmo valor de referência mostrado na interface.

Causa​

A causa mais provável (builds da ramificação 3.0.3): a interface web entrega o arquivo por um caminho que processa o corpo da resposta como texto. O arquivo é binário, e a decodificação de texto substitui todos os bytes não ASCII por um caractere de substituição. Isso destrói a assinatura gzip, impede a descompactação do arquivo e aumenta seu tamanho (cada byte corrompido ocupa três bytes). É por isso que o arquivo baixado é maior do que o mostrado na tabela e o checksum não corresponde. O problema afeta apenas downloads de arquivos binários; as exportações de texto (CSV/JSON) permanecem íntegras.

Outras causas são menos comuns:

  • O arquivo ainda está sendo gerado. Esse arquivo não tem tamanho nem checksum na lista (está marcado como incompleto); ainda é cedo para baixá-lo.
  • O arquivo foi corrompido localmente: uma transferência interrompida ou descompactação com a ferramenta errada. A comparação dos checksums na etapa 3 descarta essa hipótese.

Resolução​

  1. Compare o checksum do arquivo baixado com o valor de referência na tabela. Se corresponderem, o arquivo está íntegro e o problema é o método de descompactação; abra-o com um descompactador compatível com gzip.

  2. Se os checksums forem diferentes e o arquivo estiver inflado, ele sofreu a corrupção de download descrita acima. Não tente "repará-lo"; seu conteúdo foi alterado de forma irreversível.

  3. Obtenha um arquivo íntegro sem passar pelo download pela web. O arquivo de destino está no nó de gerenciamento, no diretório de armazenamento de arquivos (por padrão, /var/db/vstack/security-archive); o método security-event-archive-export retorna seu caminho no campo file_path. Obtenha o arquivo diretamente do nó de gerenciamento (por exemplo, usando SCP) e compare o checksum novamente.

  4. Verifique se o arquivo obtido pode ser descompactado e passa na validação:

    gunzip -t security_log_*.csv.gz && echo "archive OK"

Prevenção​

  • Após cada download, compare o sha256 do arquivo com o valor de referência na lista de arquivos; isso detecta imediatamente a corrupção no download.
  • Nos builds afetados, obtenha os arquivos do log de segurança diretamente do nó de gerenciamento, e não pelo botão de download da interface.
  • Guarde os checksums de referência junto com os arquivos: eles são necessários para verificações de integridade e confirmam que o download não foi alterado.