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:
filemostradataem vez degzip compressed data.- O segundo byte da assinatura é diferente de
8b(por exemplo, foi substituído pelos três bytesef 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
-
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.
-
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.
-
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étodosecurity-event-archive-exportretorna seu caminho no campofile_path. Obtenha o arquivo diretamente do nó de gerenciamento (por exemplo, usando SCP) e compare o checksum novamente. -
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.