Перейти к основному содержимому

Скачанный архив журнала безопасности не открывается

Симптом​

Вы скачали архивный файл журнала безопасности с вкладки «Archived events» (архивы событий). Файл имеет расширение .csv.gz, но не открывается:

  • архиватор сообщает «not in gzip format» или «неверный формат»;
  • размер скачанного файла заметно больше, чем значение в колонке Size для этой строки архива;
  • контрольная сумма скачанного файла не совпадает с sha256, показанной в таблице.

При этом обычные экспортные выгрузки того же журнала в CSV и JSON открываются без проблем — страдают только сжатые архивные файлы.

Как проверить​

Убедитесь, что перед вами именно этот случай. Проверьте тип файла и его контрольную сумму, затем сравните её с эталоном из таблицы архивов.

# 1. Тип файла: у целого архива в начале должна стоять gzip-сигнатура 1f 8b
file security_log_*.csv.gz

# 2. Первые байты: целый gzip начинается с "1f 8b 08 08 ..."
xxd security_log_*.csv.gz | head -1

# 3. Контрольная сумма скачанного файла
shasum -a 256 security_log_*.csv.gz

Признаки повреждённого файла:

  • file показывает data вместо gzip compressed data;
  • второй байт сигнатуры отличается от 8b (например, вместо него стоят три байта ef bf bd);
  • сумма из шага 3 не совпадает со значением sha256 в строке архива.

Эталонную сумму по каждому архиву также отдаёт метод API security-event-archive-list (поле sha256) — это тот же ориентир, что показан в интерфейсе.

Причина​

Наиболее вероятная причина (сборки ветки 3.0.3). Веб-интерфейс отдаёт архив через путь, который обрабатывает тело ответа как текст. Архив же — бинарный, и при текстовом декодировании все не-ASCII байты подменяются символом-заполнителем. Из-за этого gzip-сигнатура разрушается, файл перестаёт распаковываться, а его объём раздувается (каждый испорченный байт занимает по три). Именно поэтому размер скачанного файла больше, чем в таблице, а контрольная сумма не сходится. Проблема касается только бинарной выгрузки архива; текстовые экспорты (CSV/JSON) проходят целыми.

Реже встречаются другие причины:

  • Архив ещё формируется. В списке у такого файла нет размера и контрольной суммы (он помечен как незавершённый) — скачивать его рано.
  • Файл повреждён уже локально: прерванная передача или распаковка неверным инструментом. Это отсекается сверкой контрольной суммы из шага 3.

Решение​

  1. Сверьте контрольную сумму скачанного файла с эталоном из таблицы. Если суммы совпадают — файл целый, а проблема в способе распаковки; откройте его gzip-совместимым архиватором.

  2. Если суммы расходятся и файл раздут — это описанное выше повреждение при выгрузке. Не пытайтесь «чинить» такой файл, его содержимое искажено безвозвратно.

  3. Получите целый архив в обход веб-выгрузки. Целевой файл лежит на управляющем узле в каталоге хранения архивов (по умолчанию /var/db/vstack/security-archive); его путь возвращает метод security-event-archive-export в поле file_path. Заберите файл напрямую с управляющего узла (например, по SCP) и снова сверьте контрольную сумму.

  4. Убедитесь, что полученный файл распаковывается и проходит проверку:

    gunzip -t security_log_*.csv.gz && echo "архив целый"

Профилактика​

  • После каждого скачивания сверяйте sha256 файла с эталоном из списка архивов — это сразу выявляет повреждение при выгрузке.
  • На затронутых сборках забирайте архивы журнала безопасности напрямую с управляющего узла, а не через кнопку скачивания в интерфейсе.
  • Храните эталонные контрольные суммы вместе с архивами: они нужны при проверках целостности и подтверждают, что выгрузка не была искажена.