Обновление системы

В данном разделе описаны действия по обновлению основного экземпляра системы или сателлита (далее — "экземпляр системы").

Обновление состоит из следующих этапов:

Подготовка к обновлению
Обновление системы
Действия после обновления
Авторизация в системе

Если к основному экземпляру системы подключены сателлиты, нужно обновить их после обновления основного экземпляра системы. Инструкция по обновлению сателлитов приведена в разделе Обновление сателлитов.

Подготовка к обновлению

Подготовительные действия перед обновлением

Перед обновлением экземпляра системы до новой версии выполните подготовительные действия:

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

Смена доменного имени системы

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

Подключитесь к терминалу master-узла кластера Kubernetes, в котором установлен основной экземпляр системы.
Обновите доменное имя в секрете evo.infra.global, выполнив следующую команду:
kubectl patch secret evo.infra.global -n <namespace> -p='{"stringData":{"FRONTEND_HOST": "<new_domain_name>","GRAFANA_EXTERNAL_URL": "https://<new_domain_name>/grafana"}}'
Здесь:
- <namespace> — название пространства имен, в котором установлена система.
- <new_domain_name> — новое доменное имя, например, evo-new.company.local.
В результате успешного обновления секрета должно отобразиться следующее сообщение:
secret/evo.infra.global patched
Запустите обновление. После обновления система будет доступна по новому доменному имени.

Особенности обновления системы с определенных версий

При обновлении системы с определенных версий имеется ряд особенностей:

Особенности обновления системы с версии ниже 2.0.0

В системе версии ниже 2.0.0 может возникать ошибка при просмотре логов коллектора в интерфейсе:

Не удалось получить логи коллектора.
connect ECONNREFUSED <...>

В логах пода loki-gateway отображается ошибка:

host not found in resolver "coredns.kube-system.svc.cluster.local." in /etc/nginx/nginx.conf:33

Причина: чарт Loki по умолчанию использует имя coredns для конфигурации разрешения имен пода loki-gateway, однако в кластере может использоваться другое имя для сервиса DNS — например, kube-dns.

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

Решение: нужно исправить конфигурацию сервиса loki-gateway. Для этого:

Получите фактическое имя DNS-сервиса:

K8S_DNS_SERVICE="$(kubectl get service -n kube-system -l k8s-app=kube-dns -o 'jsonpath={.items..metadata.name}')"

Получите конфигурацию loki-gateway:

LOKI_CONFIG="$(get cm loki-gateway -n kube-prometheus-stack -o 'jsonpath={.data.nginx\.conf}')"

Сравните имена DNS-сервисов:
```
echo "K8s DNS: $K8S_DNS_SERVICE"
echo "Loki DNS: $(echo "$LOKI_CONFIG" | grep resolver)"
```
Пример вывода имен DNS-сервисов
```
K8s DNS: kube-dns
Loki DNS: resolver coredns.kube-system.svc.cluster.local.;
```
Если в выводе имена сервисов разные, перейдите к шагу 4.
Откройте ConfigMap loki-gateway:
```
KUBE_EDITOR=nano kubectl edit configmap/loki-gateway -n kube-prometheus-stack
```
Замените имя DNS-сервиса coredns после resolver на значение переменной K8S_DNS_SERVICE. После исправления строка ConfigMap должна принять вид:
```
resolver <dns_name>.kube-system.svc.cluster.local.;
```
Здесь:
- <dns_name> — имя DNS-сервиса Kubernetes, полученное на шаге 3, например, kube-dns.

Сохраните файл и перезапустите loki-gateway:

kubectl rollout restart deployment/loki-gateway -n kube-prometheus-stack

Особенности обновления системы с версии ниже 2.3.0

Начиная с версии 2.3.0 система поставляется на базе платформы R-Vision EVO.

Обновление системы с версий ниже 2.3.0 требует ручных действий.

Выключение коллекторов

Перед обновлением системы с версии ниже 2.3.0 необходимо выключить все работающие коллекторы.

После обновления все необходимые коллекторы и конвейеры нужно будет включить вручную.

Создание общей БД PostgreSQL

Сервисы платформы могут использовать как общую БД, так и собственные. В установщиках системы версий ниже 2.3.0 общая БД отсутствует. Необходимо создать ее вручную с помощью команды:

kubectl exec -n <namespace> sts/postgresql -- psql -U <username> -d postgres -c 'CREATE DATABASE evo;'

Здесь:

<namespace> — название пространства имен, в котором установлена система.
<username> — имя пользователя PostgreSQL, которое было указано при установке системы.

Имя пользователя PostgreSQL можно получить из секрета evo.siem.global, выполнив следующую команду:

kubectl -n <namespace> get secrets evo.siem.global -o jsonpath='{.data.POSTGRES_USER}' | base64 -d

Здесь:

<namespace> — название пространства имен, в котором установлена система.

Обновление NATS

Начиная с версии 2.2.0 в поставку системы входит NATS. При обновлении с 2.2.x необходимо предварительно удалить предыдущие helm-релизы NATS, чтобы избежать ошибок. Для этого:

Удостоверьтесь, что NATS развернут в необходимом пространстве имен:
```
helm list -n <namespace> | grep nats-
```

Удалите nats-main и nats-bridge при их наличии:

helm uninstall -n <namespace> nats-bridge
helm uninstall -n <namespace> nats-main

Здесь:

<namespace> — название пространства имен, в котором установлена система.

Устранение проблем при обновлении

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

Если во время обновления системы произошел сбой, выполните следующие действия:

Удалите метаданные модулей, которые успели развернуться до сбоя:
```
kubectl get cm -n <namespace> -o name | grep release-info | xargs -n1 -t kubectl delete -n <namespace>
```
Запустите обновление повторно без распаковки дистрибутива:
```
export PATH=$PATH:/opt/r-vision/common/bin
evoctl instance update -v
```

Добавление разрешений

При обновлении системы с версии ниже 2.3.0 в пользовательских ролях сбрасываются все разрешения. После обновления необходимо заново настроить разрешения ролей.

Особенности обновления системы с версии ниже 2.3.3

Начиная с версии 2.3.3 названия схем активных списков и таблиц обогащения не могут содержать точки.

Перед обновлением системы с версии ниже 2.3.3 удостоверьтесь, что ни одна схема активного списка или таблица обогащения не содержит точки в названии. Если такие схемы или таблицы имеются, необходимо создать их новые версии без точек в названии, а старые версии удалить.

Особенности обновления системы с версии ниже 2.4.0

После обновления системы с версии ниже 2.4.0 тип существующих точек входа HTTP Client изменится на HTTP Client_deprecated в связи с их функциональными обновлениями.

Для обновления точек входа HTTP Client:

Измените тип существующих точек входа HTTP Client_deprecated в конвейерах на обновленный тип без суффикса _deprecated.
Удалите устаревший тип точки входа из таблицы entry_point_type в базе данных коллекторов PostgreSQL. Для этого:
1. Подключитесь к терминалу master-узла кластера.
2. Подключитесь к PostgreSQL, выполнив следующую команду:
  kubectl exec -it -n <namespace> postgresql-0 sh
  Здесь:
  - <namespace> — название пространства имен, в котором установлена система.
3. Подключитесь к базе данных коллекторов:
  psql -U postgres -d collector
4. Удалите из таблицы entry_point_type устаревший тип точки входа:
  delete from "entry_point_type" where "name" like '%_deprecated';

Особенности обновления системы с версии ниже 2.5.0

При обновлении системы с версии ниже 2.5.0 необходимо обновить ClickHouse до поддерживаемой версии.

Особенности обновления системы с версии ниже 2.6.0

Обновление системы с версий ниже 2.6.0 требует ручных действий.

Сохранение настроек стримов в менеджере пространств

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

Чтобы не потерять изменения, внесенные в настройки стримов, перед обновлением системы сохраните их в секрет evo.space.global. Для этого выполните следующую команду для каждой измененной переменной окружения:

kubectl patch secret evo.space.global -n evo-namespace -p='{"stringData":{"<env_var>": "<value>"}}'

Здесь:

<env_var> — переменная окружения, новое значение которой необходимо сохранить. Например: NATS_CONFIGURATOR_GLOBAL_OBJECTS_OS_MAX_SIZE.
<value> — новое значение переменной окружения. Например: 512MB.

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

Обновление Microsoft Visual C++

Начиная с версии 2.6.0 агенты в ОС Windows совместимы с Microsoft Visual C++ 14.29 и выше. Если ваши агенты работают на хостах с ОС Windows, при обновлении системы с версии ниже 2.6.0 обновите Microsoft Visual C++ до версии не ниже 14.29.

Переход на новые точки входа R-Vision Endpoint

Начиная с версии 2.6.0 тип точек входа R-Vision Endpoint заменен на R-Vision Endpoint_deprecated в силу функционального устаревания, а R-Vision EVO Endpoint — на R-Vision Endpoint.

После обновления системы с версии ниже 2.6.0 рекомендуется перейти со старых точек входа R-Vision Endpoint_deprecated на новые — R-Vision Endpoint. Для этого:

Удалите агенты R-Vision Endpoint и установите системные агенты согласно инструкции в разделе Переход с агентов R-Vision Endpoint на системные агенты.
Измените тип существующих точек входа R-Vision Endpoint_deprecated в конвейерах на обновленный тип без суффикса _deprecated и укажите домен для подключения к шлюзу. Подробности приведены в описании точки входа R-Vision Endpoint.
Удалите устаревший тип точки входа из таблицы entry_point_type в базе данных коллекторов PostgreSQL. Для этого:
1. Подключитесь к терминалу master-узла кластера.
2. Подключитесь к PostgreSQL, выполнив следующую команду:
  kubectl exec -it -n <namespace> postgresql-0 sh
  Здесь:
  - <namespace> — название пространства имен, в котором установлена система.
3. Подключитесь к базе данных коллекторов:
  psql -U postgres -d collector
4. Удалите из таблицы entry_point_type устаревший тип точки входа:
  delete from "entry_point_type" where id = 'f7183617-e756-4fa9-9f59-bd2c2529625c';

Включение поиска по нескольким хранилищам событий

Одновременный поиск по нескольким хранилищам, созданным до версии 2.4.0 и в версии 2.4.0 или выше, недоступен. Это связано с переходом на тип данных DateTime64 в служебных полях моделей событий в версии 2.4.0. В таком случае необходимо ограничиться поиском только по тем хранилищам, которые были созданы либо в версии ниже 2.4.0, либо в версии 2.4.0 или выше.

Для работы поиска по нескольким хранилищам событий выполните процедуру создания недостающих удаленных (remote) и локальных таблиц хранилищ:

Создайте необходимые распределенные таблицы с помощью скрипта, приведенного после заголовка Создать необходимые распределенные таблицы в разделе Настройка существующего кластера ClickHouse. Вы можете выполнить скрипт на любом экземпляре кластера ClickHouse.
Подключитесь к терминалу master-узла кластера.
Откройте ConfigMap сервиса evo.streams.event-storage-manager. Для этого выполните следующую команду:
```
kubectl -n <namespace> edit configmap evo.streams-event-storage-manager-env
```
Здесь:
- <namespace> — название пространства имен, в котором установлена система.

Измените значение переменной EVO_STREAMS_EVENT_STORAGE_MANAGER_RECREATE_EVENT_STORAGES на "true".

Пересоздание таблиц хранилищ событий занимает некоторое время. В процессе пересоздания liveness-пробы сервиса evo.streams.event-storage-manager могут завершиться с ошибкой, что приведет к циклическому перезапуску этого сервиса. Во избежание такого поведения рекомендуется увеличить интервал между liveness-пробами, выполнив следующие действия:

Откройте конфигурацию контроллера Deployment evo.streams.event-storage-manager, выполнив следующую команду:
kubectl -n <namespace> edit deployment evo.streams.event-storage-manager
Здесь:
- <namespace> — название пространства имен, в котором установлена система.
Скопируйте и сохраните текущие значения параметров в секции livenessProbe.
Пример содержимого секции livenessProbe
```
livenessProbe:
  grpc:
    port: 3000
    service: ''
  initialDelaySeconds: 10
  timeoutSeconds: 3
  periodSeconds: 10
  successThreshold: 1
  failureThreshold: 3
```
Увеличьте значения параметров timeoutSeconds, periodSeconds и failureThreshold.
Сохраните изменения.

После перезапуска сервиса evo.streams.event-storage-manager рекомендуется восстановить настройки liveness-проб по умолчанию.

Удалите под сервиса evo.streams.event-storage-manager, выполнив следующую команду:
```
kubectl -n <namespace> delete pods -l app.kubernetes.io/name=evo.streams.event-storage-manager
```
Под будет пересоздан автоматически.
Дождитесь, когда под evo.streams.event-storage-manager перейдет в статус Running. Инструкция по проверке статуса пода приведена в разделе Просмотр состояния подов кластера.
Когда под перейдет в статус Running, перейдите в веб-интерфейс системы и убедитесь, что поиск по хранилищам событий выполняется успешно и события поступают в хранилища.
Откройте ConfigMap сервиса evo.streams.event-storage-manager. Для этого выполните следующую команду:
```
kubectl -n <namespace> edit configmap evo.streams-event-storage-manager-env
```
Здесь:
- <namespace> — название пространства имен, в котором установлена система.
Измените значение переменной EVO_STREAMS_EVENT_STORAGE_MANAGER_RECREATE_EVENT_STORAGES обратно на "false".
Если вы меняли интервал liveness-проб, восстановите интервал по умолчанию в конфигурации evo.streams.event-storage-manager. Ее можно открыть, выполнив следующую команду:
kubectl -n <namespace> edit deployment evo.streams.event-storage-manager
Здесь:
- <namespace> — название пространства имен, в котором установлена система.

Восстановление работы сервисов оповещений

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

Особенности обновления системы с версии ниже 2.7.0

При обновлении системы с версии ниже 2.7.0 необходимо обновить ClickHouse до поддерживаемой версии.

Особенности обновления системы с версии ниже 2.7.1

Пересоздание системных активных списков

Начиная с версии 2.7.1 в активных списках изменена логика срока жизни записей, а также добавлен специальный тип данных для хранения VRL в записях. Теперь срок жизни записи можно задавать в секундах через поле ttl типа integer вместо поля dueDate. Из-за этого при обновлении системы с версии 2.7.0 системные активные списки могут начать работать некорректно.

Чтобы восстановить корректную работу системных активных списков, перед обновлением системы с версии 2.7.0 их необходимо удалить. Для этого:

Удостоверьтесь, что системные активные списки не используются ни в одном из конвейеров. В противном случае удалите их из конвейеров.

Сбросьте тип системных активных списков на Пользовательский, запустив в СУБД PostgreSQL следующий скрипт:

-- Сброс типа для белого и черного списков.
UPDATE active_list
SET is_system = false
WHERE active_list_name IN ('system-whitelist', 'system-blacklist');

-- Сброс типа для схем белого и черного списков.
UPDATE expertise
SET object_type = 'custom'
WHERE name IN ('system-whitelist', 'system-blacklist');

-- Удаление скрипта добавления исключений.
DELETE FROM executed_script WHERE name = 'ScriptAddExceptionActiveList';

Удалите системные активные списки:
1. Перейдите в раздел Ресурсы → Активные списки.
2. Найдите активные списки system-whitelist и system-blacklist.
3. Удостоверьтесь, что найденные активные списки имеют тип Пользовательский. В противном случае повторите шаг 2 текущей инструкции.
4. Удалите активные списки system-whitelist и system-blacklist.
Удалите схемы системных активных списков:
1. Перейдите в раздел Экспертиза.
2. Найдите схемы активных списков system-whitelist и system-blacklist.
3. Удостоверьтесь, что найденные схемы активных списков имеют тип создания Пользовательский. В противном случае повторите шаг 2 текущей инструкции.
4. Удалите схемы активных списков system-whitelist и system-blacklist.

Обновление настроек NATS Object Store

Начиная с версии 2.7.1 в системе исправлена проблема, из-за которой при сбросе метрик в глобальной шине могла очиститься очередь событий.

Теперь в новых коллекторах сброс метрик не будет приводить к очистке очереди в глобальной шине. Однако в существующих коллекторах данная проблема по-прежнему может наблюдаться. Чтобы исправить ее, необходимо изменить настройки объектного хранилища NATS Object Store. Для этого после обновления на версию 2.7.1 или выше выполните следующие действия для центрального кластера и каждого кластера сателлита:

Подключитесь к терминалу master-узла кластера.
Откройте терминал контейнера пода nats-space-box:
```
kubectl exec -n <namespace> -it deployment/nats-space-box -- sh
```
Здесь:
- <namespace> — название пространства имен, в котором установлена система.

Создайте скрипт script.sh, например, с помощью команды:

vi script.sh

Содержимое скрипта script.sh

filter="<object_id>"

data="$(nats obj ls -n r-space-siem-collector-objects | grep "$filter")"
set -- $data

list="$@"

changed=1
while [ $changed -eq 1 ]; do
  changed=0
  new_list=""
  prev=""
  for item in $list; do
    if [ -z "$prev" ]; then
      prev="$item"
      continue
    fi
    prev_prefix="${prev:0:105}"
    curr_prefix="${item:0:105}"

    if [ "$curr_prefix" \< "$prev_prefix" ]; then
      new_list="$new_list $item"
      prev="$prev"
      changed=1
    elif [ "$curr_prefix" == "$prev_prefix" ]; then
      prev_suffix="${prev:105}"
      curr_suffix="${item:105}"
      prev_p2=$(echo "$prev_suffix" | cut -d '_' -f2)
      curr_p2=$(echo "$curr_suffix" | cut -d '_' -f2)
      if [[ "$prev_p2" =~ ^[0-9]+$ && "$curr_p2" =~ ^[0-9]+$ && "$curr_p2" \< "$prev_p2" ]]; then
        new_list="$new_list $item"
        prev="$prev"
        changed=1
      else
        new_list="$new_list $prev"
        prev="$item"
      fi
    else
      new_list="$new_list $prev"
      prev="$item"
    fi
  done

  new_list="$new_list $prev"
  list="$new_list"
done


for oldKey in $list; do
  suffix="${oldKey:105}"

  p1=$(echo "$suffix" | cut -d'_' -f1)
  p2=$(echo "$suffix" | cut -d'_' -f2)
  p3=$(echo "$suffix" | cut -d'_' -f3)

  if [[ -z "$p1" && "$p2" =~ ^[0-9]+$ ]]; then
    suffix=""
    if [[ "$p3" == "mongodb/mongodb.checkpoints.json" ]]; then suffix="/mongodb.checkpoints.json"; fi
    if [[ "$p3" == "sftp/checkpoints.json" ]];            then suffix="/checkpoints.json"        ; fi
    if [[ "$p3" == "smb/checkpoints.json" ]];             then suffix="/checkpoints.json"        ; fi
    if [[ "$p3" == "database/checkpoints.json" ]];        then suffix="/checkpoints.json"        ; fi
    if [[ "$p3" == "http" ]];                             then suffix="/http_checkpoints.json"   ; fi

    if [[ -n "$suffix" ]]; then
      prefix="${oldKey:0:105}"
      newKey=$(echo "$prefix""$suffix")
      oldConnectionId=$(echo "$oldKey" | cut -d'/' -f2)
      newConnectionId=$(echo "$newKey" | cut -d'/' -f2)

      echo ">>>>> rename object key in bucket r-space-siem-collector-objects"
      echo "  old key: $oldKey"
      echo "  new key: $newKey"
      echo "  get obj: $(nats object get r-space-siem-collector-objects "$oldKey" -f -O ./tmp.json)"

      content=$(cat tmp.json)
      contentIndex=$((${#oldConnectionId}+18))
      contentSuffix="${content:$contentIndex}"
      newContent="{\"connection_id\":\"""$newConnectionId""$contentSuffix"
      echo "$newContent" > ./tmp_new.json

      echo "  put obj: $(nats object put r-space-siem-collector-objects --name "$newKey" -f ./tmp_new.json)"
      echo "  del obj: $(nats object del r-space-siem-collector-objects "$oldKey" -f)"
    fi
  fi
done

Здесь:

<object_id> — идентификатор коллектора или конвейера, для которого необходимо изменить настройки NATS Object Store.

При необходимости вы можете указать несколько идентификаторов, разделяя их вертикальной чертой. Например: 7f901c19-451f-698e-a5f4-6ea53f074bb6|e7bebc60-41cf-8bf3-68b1-382332a74f57.

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

Обновите настройки NATS Object Store. Для этого выполните следующие действия для каждого коллектора в кластере:

Отключите конфигурации всех конвейеров в коллекторе.
Выключите коллектор.
Отредактируйте скрипт script.sh, добавленный ранее, указав идентификатор коллектора вместо <object_id>.
Запустите скрипт, например, с помощью команды:
```
sh script.sh
```
Для коллектора будут обновлены настройки NATS Object Store.
Включите коллектор и установите конфигурации его конвейеров.

Вы также можете обновить настройки сразу всех коллекторов в кластере. Для этого:

Отключите конфигурации всех конвейеров во всех коллекторах кластера.
Выключите все коллекторы в кластере.
Укажите пустое значение вместо <object_id> в скрипте script.sh.
Запустите скрипт, например, с помощью команды:
```
sh script.sh
```
Включите нужные коллекторы и установите конфигурации их конвейеров.

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

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

Обновление системы

Чтобы обновить экземпляр системы до новой версии:

Запустите установщик и выберите режим установки Updating previous version.

При выборе обновления выполняется распаковка пакетов в каталог продукта и управление передается скрипту установщика.
Выберите пространство имен, в котором установлен экземпляр системы.
Задайте параметры Ansible:
1. Имя пользователя.
2. Метод аутентификации: через ключ или по паролю.
3. Пароль: задайте и подтвердите пароль пользователя.

В целевом пространстве имен будут обновлены все чарты модуля Streams.

После обновления системы убедитесь, что у вас установлена поддерживаемая версия ClickHouse. Если ваша версия ClickHouse отличается от поддерживаемой, обновите ClickHouse до требуемой версии.

После обновления на экран будет выведен URL-адрес для подключения к системе.

Обновление сателлитов

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

Скопируйте архив TLS-сертификатов $SETUP_ROOT_DIR/r-vision/nats-tls.tar.gz из основного экземпляра системы в каталог $SETUP_ROOT_DIR/r-vision сателлита.

Каталоги установки (значения переменной $SETUP_ROOT_DIR) основного экземпляра системы и сателлита могут отличаться.

Обновите сателлит с помощью установщика аналогично основному экземпляру системы.

Действия после обновления

После обновления выполните следующие действия:

Создание недостающих пользователей и таблиц ClickHouse
Перезапуск коллекторов и конвейеров

Создание недостающих пользователей и таблиц ClickHouse

После обновления системы необходимо создать необходимых пользователей и недостающие таблицы в ClickHouse, если они отсутствуют. Для этого выполните следующий скрипт на любом экземпляре кластера ClickHouse:

-- Создать пользователя owner и выдать ему необходимые права.
CREATE USER IF NOT EXISTS owner ON CLUSTER '{cluster}' IDENTIFIED WITH sha256_password BY '<OwnerPassword>';
GRANT ON CLUSTER '{cluster}' ALL on default.* TO 'owner';
GRANT ON CLUSTER '{cluster}' REMOTE on *.* TO 'owner';
GRANT ON CLUSTER '{cluster}' CLUSTER on *.* TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.disks TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.storage_policies TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.query_log TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.columns TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts_columns TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.tables TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.clusters TO 'owner';
GRANT ON CLUSTER '{cluster}' SELECT ON system.asynchronous_metrics TO 'owner';

-- Создать пользователя writer и выдать ему необходимые права.
CREATE USER IF NOT EXISTS writer ON CLUSTER '{cluster}' IDENTIFIED WITH sha256_password BY '<WriterPassword>';
GRANT ON CLUSTER '{cluster}' SELECT ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' INSERT ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' ALTER UPDATE ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' ALTER DELETE ON default.* TO 'writer';
GRANT ON CLUSTER '{cluster}' REMOTE on *.* TO 'writer';
GRANT ON CLUSTER '{cluster}' CLUSTER on *.* TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.disks TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.storage_policies TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.query_log TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.columns TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts_columns TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.tables TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.clusters TO 'writer';
GRANT ON CLUSTER '{cluster}' SELECT ON system.asynchronous_metrics TO 'writer';

-- Создать пользователя reader и выдать ему необходимые права.
CREATE USER IF NOT EXISTS reader ON CLUSTER '{cluster}' IDENTIFIED WITH sha256_password BY '<ReaderPassword>';
GRANT ON CLUSTER '{cluster}' SELECT ON default.* TO 'reader';
GRANT ON CLUSTER '{cluster}' REMOTE on *.* TO 'reader';
GRANT ON CLUSTER '{cluster}' CLUSTER on *.* TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.disks TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.storage_policies TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.query_log TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.columns TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.parts_columns TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.tables TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.clusters TO 'reader';
GRANT ON CLUSTER '{cluster}' SELECT ON system.asynchronous_metrics TO 'reader';

-- Создать необходимые распределенные таблицы.
CREATE TABLE IF NOT EXISTS default.disks ON CLUSTER '{cluster}' AS system.disks ENGINE = Distributed('{cluster}', system, disks);
CREATE TABLE IF NOT EXISTS default.storage_policies ON CLUSTER '{cluster}' AS system.storage_policies ENGINE = Distributed('{cluster}', system, storage_policies);
CREATE TABLE IF NOT EXISTS default.parts ON CLUSTER '{cluster}' AS system.parts ENGINE = Distributed('{cluster}', system, parts);
CREATE TABLE IF NOT EXISTS default.query_log ON CLUSTER '{cluster}' AS system.query_log ENGINE = Distributed('{cluster}', system, query_log);
CREATE TABLE IF NOT EXISTS default.columns ON CLUSTER '{cluster}' AS system.columns ENGINE = Distributed('{cluster}', system, columns);
CREATE TABLE IF NOT EXISTS default.parts_columns ON CLUSTER '{cluster}' AS system.parts_columns ENGINE = Distributed('{cluster}', system, parts_columns);
CREATE TABLE IF NOT EXISTS default.tables ON CLUSTER '{cluster}' AS system.tables ENGINE = Distributed('{cluster}', system, tables);
CREATE TABLE IF NOT EXISTS default.clusters ON CLUSTER '{cluster}' AS system.clusters ENGINE = Distributed('{cluster}', system, clusters);
CREATE TABLE IF NOT EXISTS default.asynchronous_metrics ON CLUSTER '{cluster}' AS system.asynchronous_metrics ENGINE = Distributed('{cluster}', system, asynchronous_metrics);

Здесь <OwnerPassword>, <WriterPassword> и <ReaderPassword> — это пароли пользователей owner, writer и reader соответственно.

Необходимо указывать пароли, которые были использованы на этапах настройки общесистемного экземпляра ClickHouse и ClickHouse для событий ИБ при установке системы.

Перезапуск коллекторов и конвейеров

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

Чтобы выполнить вход в систему:

В адресной строке браузера введите URL-адрес, выведенный на экран после обновления системы. На экране отобразится страница авторизации.
Укажите логин и пароль учетной записи пользователя и нажмите на кнопку Войти.

Если вы обновляли сателлиты, после обновления может потребоваться перезапуск выполняющихся на них коллекторов и сервисов из интерфейса основного экземпляра системы.

Была ли полезна эта страница?

Обратная связь

Обновление системы

Подготовка к обновлению

Подготовительные действия перед обновлением

Смена доменного имени системы

Особенности обновления системы с определенных версий

Обновление системы

Обновление сателлитов

Действия после обновления

Создание недостающих пользователей и таблиц ClickHouse

Перезапуск коллекторов и конвейеров

Авторизация в системе