Удаление NRunner

Инструкция описывает удаление серверной установки NRunner на Linux: основного контура, локальной VulnDB и сервиса обновления. Команды выполняйте на сервере с правами root через sudo; под root sudo можно опустить.

Перед началом

Завершите активные задачи и убедитесь, что установка или обновление NRunner сейчас не выполняется.

Если нужно удалить агенты с целевых хостов, сделайте это до остановки сервера: создайте задачу Распространение агента с действием «Удаление» и дождитесь её успешного завершения. Удаление серверных контейнеров не удаляет агенты на других хостах.

Перед удалением данных подготовьте резервные копии основной базы PostgreSQL, локальной VulnDB, серверных данных (включая ключи и сертификаты), журналов и конфигурации. Для штатной установки постоянная конфигурация находится в /etc/nrunner. Храните копии вне каталогов, которые планируете удалить; файлы конфигурации содержат секреты.

Выберите вариант:

• Сохранить данные — удалить контейнеры и сети, оставив Docker volumes и файлы для последующего восстановления.
• Удалить данные — дополнительно удалить volumes и файлы установки. Этот вариант необратим без резервной копии.

Полное удаление уничтожает пользователей, результаты сканирований, базы, файлы и сертификаты NRunner. При работе на сервере клиента согласуйте с ним удаление данных заранее. Для обновления с сохранением данных используйте штатную установку и обновление.

Просмотр существующей установки

Команды просмотра можно выполнять из любого каталога:

sudo docker ps -a --format \
  '{{.Names}} | image={{.Image}} | project={{.Label "com.docker.compose.project"}}'
sudo docker volume ls --format \
  '{{.Name}} | project={{.Label "com.docker.compose.project"}}'
sudo docker network ls
sudo systemctl status nrunner-updater.service --no-pager -l

В поставках встречаются проекты nrunner (основной контур), nrunner-vulndb-private (локальная VulnDB) и nrunner-vulndb (VulnDB ранних поставок). В некоторых ранних установках остались volumes проекта main; их принадлежность нужно проверять отдельно.

Посмотрите каталог поставки и подключения данных по фактическому имени серверного контейнера. Например:

sudo docker inspect nrunner-nrunner-server-1 --format \
  '{{.Name}} | deploy={{index .Config.Labels "com.docker.compose.project.working_dir"}}{{range .Mounts}}{{printf "\n  %s: %s -> %s" .Type .Source .Destination}}{{end}}'

Сохраните пути подключений типа bind: такие каталоги не удаляются вместе с Docker volumes. Проверьте принадлежность компонентов до выполнения команд удаления.

Отключение сервиса обновления

При установке через install.sh сначала остановите и отключите сервис обновления, чтобы он не запускал компоненты во время удаления:

sudo systemctl disable --now nrunner-updater.service
sudo systemctl is-active nrunner-updater.service

Ожидаемый результат проверки — inactive. Команда проверки возвращает ненулевой код для неактивного сервиса. При ручной установке сервис обновления не настраивается; если unit отсутствует, пропустите этот шаг. Если остановка существующего сервиса завершилась ошибкой, устраните её до дальнейшего удаления.

Подготовка команд Docker Compose

Если рабочие Compose-файлы отсутствуют или остались компоненты ранней поставки, используйте раздел Удаление без Compose-файлов.

Для штатной установки перейдите в каталог текущего релиза:

cd /opt/nrunner/current

При ручной установке перейдите в корень фактически использованного комплекта поставки. Убедитесь, что в нём есть release.env, compose/nrunner.yml и рабочие файлы config/server.env, config/client.env. Для локальной VulnDB также нужны compose/vulndb-private.yml и config/vulndb.env.

В текущей Bash-сессии определите команды для двух контуров:

nrunner_compose() {
  sudo docker compose \
    --project-directory "$PWD" \
    --env-file release.env \
    --env-file config/server.env \
    --env-file config/client.env \
    -f compose/nrunner.yml "$@"
}

vulndb_compose() {
  sudo docker compose \
    --project-directory "$PWD" \
    --env-file release.env \
    --env-file config/vulndb.env \
    -f compose/vulndb-private.yml \
    --profile maintenance "$@"
}

Все последующие вызовы этих функций выполняйте в той же сессии и из того же каталога. Если при развёртывании использовалось другое имя Compose-проекта (через -p или COMPOSE_PROJECT_NAME), используйте то же имя при удалении.

Проверьте, что команды обращаются к нужным контейнерам:

nrunner_compose ps -a
vulndb_compose ps -a

Команды vulndb_compose выполняйте только для локальной VulnDB, развёрнутой этим комплектом. Внешний или общий сервис данных об уязвимостях удалять не нужно.

Удаление с сохранением данных

Удалите контейнеры и сети обоих контуров:

nrunner_compose down
vulndb_compose down

Docker volumes, образы и файлы на сервере сохранятся. Не добавляйте --volumes и не удаляйте каталоги установки и конфигурации, если планируете восстановление.

Полное удаление данных

Необратимое удаление

Параметр --volumes удаляет volumes из Compose-конфигурации: основную базу PostgreSQL, Redis, серверные данные с ключами и сертификатами, журналы, дистрибутивы агентов и базу локальной VulnDB. Продолжайте только после сохранения необходимых резервных копий.

Вместо команд предыдущего раздела выполните:

nrunner_compose down --volumes
vulndb_compose down --volumes

Эти команды также можно выполнить после удаления с сохранением данных, пока доступны файлы Compose и конфигурация. Внешние volumes и файлы, подключённые через bind mounts, Docker Compose не удаляет.

Проверка удаления контейнеров

До удаления файлов установки проверьте оба контура:

nrunner_compose ps -a
vulndb_compose ps -a

В списках не должно остаться контейнеров. Если команда удаления завершилась ошибкой, устраните причину перед удалением файлов установки.

Удаление без Compose-файлов

Этот способ подходит для старой или неудачной установки, когда исходные Compose-файлы и конфигурация недоступны. Сначала выполните просмотр компонентов и остановку updater, описанные выше. Команды ниже выполняются в Bash из любого каталога.

Укажите только проверенные проекты удаляемой установки. Например, для основного контура и локальной VulnDB:

projects=(nrunner nrunner-vulndb-private)

Для ранней поставки замените nrunner-vulndb-private на nrunner-vulndb либо добавьте его, если обнаружены принадлежащие этой установке остатки обоих проектов. При нестандартных именах используйте фактические значения меток.

Удаление контейнеров

for project in "${projects[@]}"; do
  sudo docker ps -aq \
    --filter "label=com.docker.compose.project=$project" \
    | xargs -r sudo docker rm -f
done

Если при просмотре обнаружен отдельно созданный контейнер updater без метки проекта, удалите его по точному имени после проверки принадлежности. Удаление контейнеров принудительно останавливает процессы.

Удаление volumes

Только для полного удаления

Следующая команда удаляет данные выбранных проектов. Для варианта с сохранением данных пропустите этот шаг и оставьте конфигурацию и каталоги установки.

for project in "${projects[@]}"; do
  sudo docker volume ls -q \
    --filter "label=com.docker.compose.project=$project" \
    | xargs -r sudo docker volume rm
done

Если volume занят другим контейнером, сначала проверьте этот контейнер и его назначение. В ранних установках могут остаться следующие volumes:

sudo docker volume inspect \
  main_local_postgres_data \
  main_nrunner_server_tmp \
  main_redis_data

Только если подтверждено, что они относятся к удаляемому NRunner и данные больше не нужны, удалите их:

sudo docker volume rm \
  main_local_postgres_data \
  main_nrunner_server_tmp \
  main_redis_data

Не удаляйте весь проект main по метке: это имя может использоваться другим приложением.

Удаление сетей

for project in "${projects[@]}"; do
  sudo docker network ls -q \
    --filter "label=com.docker.compose.project=$project" \
    | xargs -r sudo docker network rm
done

После успешной очистки переходите к удалению системного сервиса и файлов.

Удаление системного сервиса и файлов

После успешного удаления контейнеров удалите unit сервиса обновления, если он был установлен:

sudo rm -f -- /etc/systemd/system/nrunner-updater.service
sudo rm -rf -- /etc/systemd/system/nrunner-updater.service.d
sudo systemctl daemon-reload

Для варианта с сохранением данных оставьте остальные файлы на месте. Для полного удаления штатной установки сначала выйдите из каталога релиза, затем удалите её файлы:

cd /
sudo rm -rf -- /opt/nrunner /etc/nrunner /etc/nrunner-updater \
  /var/lib/nrunner-updater /run/nrunner-updater
sudo rm -f -- /usr/local/sbin/nrunner-updater

Перед выполнением проверьте, что перечисленные каталоги принадлежат удаляемой установке и не содержат нужных резервных копий. Если комплект был распакован в другой каталог или дампы VulnDB хранились вне /opt/nrunner, удалите эти файлы отдельно по их фактическим путям.

Путь /usr/local/sbin/nrunner-updater использовался в ранних поставках. Не удаляйте системные каталоги /tmp, /var/lib/docker и сокет /var/run/docker.sock.

После удаления unit команда systemctl status nrunner-updater.service должна сообщить, что сервис не найден.

Удаление образов

Docker Engine и скачанные контейнерные образы остаются на сервере. Для освобождения места сначала посмотрите образы NRunner из использованного registry:

sudo docker image ls --format '{{.Repository}}:{{.Tag}}' \
  | grep '^registry\.legionsecurity\.ru/nrunner/'

Если все найденные образы относятся к удаляемой установке и больше не нужны другим установкам, удалите их:

sudo docker image ls --format '{{.Repository}}:{{.Tag}}' \
  | grep '^registry\.legionsecurity\.ru/nrunner/' \
  | xargs -r sudo docker image rm

При другом registry используйте его фактический префикс. Общие образы PostgreSQL и Redis могут использоваться другими приложениями. Не используйте глобальную очистку docker system prune --volumes.

Итоговая проверка

sudo docker ps -a --format 'table {{.Names}}\t{{.Image}}'
sudo docker volume ls
sudo docker network ls
sudo systemctl list-unit-files 'nrunner*' --no-pager
df -hT
sudo docker system df

Контейнеров, сетей и сервиса удаляемого NRunner не должно остаться. При полном удалении также должны отсутствовать его volumes; при сохранении данных они остаются. Компоненты других приложений могут остаться.

Очистка после неудачной установки

При ошибке No space left on device проверьте свободное место и inode:

df -hT
df -i
sudo docker info --format '{{.DockerRootDir}}'
sudo docker system df

Проверяйте раздел, на котором находится каталог хранения Docker. Неудачная установка не освобождает автоматически скачанные образы и частично импортированную базу.

Если данные новой установки не нужно сохранять, выполните полный сценарий удаления через Compose либо по меткам проектов, включая volumes локальной VulnDB. Если updater успел установиться, сначала остановите его. Частично импортированную VulnDB нельзя считать корректной базой: перед чистым повторным импортом её volume нужно пересоздать.

Перед повторной установкой NRunner устраните причину нехватки места. После удаления сертификатов и чистой установки оставшиеся агенты могут потребовать повторной настройки доверия к новому CA.