The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Обновление сертификатов oVirt
oVirt - свободная, кроссплатформенная система управления виртуализацией.
Была разработана компанией Red Hat как проект сообщества, на котором основан
продукт Red Hat Virtualization.

oVirt состоит из двух основных компонентов - oVirt engine и oVirt node.

oVirt engine управляет всеми хостами виртуализации, общими дисковыми ресурсами
и виртуальными сетями. Может быть размещён как на отдельном сервере
(standalone), так и на виртуальной машине внутри гипервизоров, которыми
управляет (self-hosted engine).

oVirt node - физический сервер с RHEL, Centos, Scientific Linux с KVM
гипервизором и службой VDSM (Virtual Desktop and Server Manager), которая
управляет всеми ресурсами, доступными серверу (вычисления, ОЗУ, хранилище,
сеть), а также управляет запуском виртуальных машин. Несколько узлов могут быть
объединены в кластер.

В примерах ниже будут один oVirt engine и три oVirt node:

  • oVirt engine - virt-he.example.test
  • oVirt node - virt-host1.example.test, virt-host2.example.test, virt-host3.example.test Обмен данными между oVirt engine и oVirt node осуществляется с использованием SSL-сертификатов. Автоматическое обновление сертификатов не производится, поэтому очень важно обновлять сертификаты вручную до истечения сроков их действия. Стандартными средствами обновить сертификаты можно, если до окончания срока действия осталось менее 60 дней (для версии 4.5). В oVirt необходимо обновлять вручную два типа сертификатов:
  • сертификаты oVirt Engine - службы, которая предоставляет графический интерфейс и REST API для управления ресурсами виртуальных машин
  • сертификаты для обмена данным между гипервизорами oVirt node и центром управления виртуальными машинами oVirt Engine Определить дату окончания действия сертификатов oVirt Engine можно в свойствах сертификата сайта. Определить дату окончания действия сертификатов oVirt node можно с помощью openssl:
  • Подключаемся через SSH на физический сервер oVirt node
  • Определяем дату: [root@virt-host1 ~]# openssl x509 -noout -enddate -in /etc/pki/vdsm/certs/vdsmcert.pem В версиях oVirt до 4.5, у всех сертификатов время жизни составляет 398 дней. Начиная с версии 4.5, у самоподписанных сертификатов для обмена данным между гипервизорами oVirt node и центром управления виртуальными машинами oVirt engine установлено время действия 5 лет. У сертификатов, которые видят браузеры, срок действия установлен в 398 дней, их необходимо обновлять раз в год. Процедура обновления действующих сертификатов описана в официальной документации. Если вы допустите истечение срока действия сертификатов, то гипервизоры и центр управления Engine перестанут взаимодействовать. В Web-консоль невозможно будет войти, виртуальные машины продолжать работать, но с ними ничего нельзя будет сделать: нельзя изменить параметры виртуального железа, нельзя мигрировать на другой узел, после выключения ВМ её будет невозможно включить снова. Восстановление займёт много времени. Процедура восстановления просроченных сертификатов описана в руководстве. Для доступа к нему необходима действующая платная подписка Red Hat Virtualization (RHV) 4.x. Решение для восстановления без подписки я обнаружил на GitHub. Автор подготовил решения для Ansible в соответствии с рекомендациями от Red Hat. Если вы знакомы с Ansible и у вас много гипервизоров с просроченными сертификатами, то можно использовать решение от natman. Решение ниже подходит для небольшого числа гипервизоров, но при условии, что центр управления Engine у вас запущен, и вы можете получить к нему доступ через ssh. Предполагается, что в качестве центра управления используется HostedEngine - центр управления гипервизорами запускается внутри самого гипервизора. Если центр управления Engine выключен и не запускается, а в журнале journalctl на гипервизоре появляются записи libvirtd[2101]: The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired ... systemd[1]: Failed to start Virtualization daemon то единственным вариантом восстановления будет изменение времени на гипервизоре на более ранее (в пределах срока действия сертификатов) и обновление сертификатов стандартным образом. Обновление сертификатов до истечения сроков действия Обновление сертификатов oVirt node Переводим узел (гипервизор) в режим обслуживания (Managеment -> Maintenance) - все машины на узле будут мигрированы, привязанные (pinned) машины будут выключены. Выбираем Installation -> Enroll Certificate Выводим узел из режима обслуживания Повторяем операции для всех оставшихся узлов в кластере Обновление сертификатов oVirt Engine Подключаемся к физическому серверу гипервизору oVirt node через SSH С узла Ovirt host переводим центр управления ВМ в режим обслуживания (для Self-hosted типа развёртывания) [root@virt-host1 ~]# hosted-engine --set-maintenance --mode=global Подключаемся к виртуальной машине с центром управления oVirt engine через SSH, запускаем настройку engine (web-консоль будет остановлена) [root@virt-he ~]# engine-setup --offline Отвечаем на вопросы Если до истечения срока действия сертификата осталось менее 60 дней, то скрипт предложит обновить сертификаты: Renew certificates? (Yes, No) [No]: Yes Дожидаемся окончания работы скрипта. С узла Ovirt host выводим центр управления ВМ из режима обслуживания: [root@virt-host1 ~]# hosted-engine --set-maintenance --mode=none Подключаемся к web-консоли и проверяем дату окончания действия сертификата. Обновление сертификатов после истечения сроков действия Если вы допустите истечение срока действия сертификатов, то в web-консоль невозможно будет войти. Гипервизоры и центр управления Engine перестанут взаимодействовать. Чтобы восстановить сертификаты выполняем следующие шаги. Подключаемся через SSH на узел гипервизора oVirt node с истёкшим сертификатом (в примере имя узла virt-host1). Создаем запрос сертификата на основании ключа службы VDSM /etc/pki/vdsm/keys/vdsmkey.pem [root@virt-host1 ~]# openssl req -new \ -key /etc/pki/vdsm/keys/vdsmkey.pem \ -out /tmp/test_virt-host1_vdsm.csr \ -batch \ -subj "/" Подписываем запрос с помощью корневого сертификата oVirt engine, для этого подключаемся через SSH на ВМ с oVirt engine, копируем запрос с oVirt node (virt-host1) на oVirt engine в /tmp и выполняем команды [root@virt-he ~]# cd /etc/pki/ovirt-engine/ [root@virt-he ~]# openssl ca -batch \ -policy policy_match \ -config openssl.conf \ -cert ca.pem \ -keyfile private/ca.pem \ -days +"365" \ -in /tmp/test_virt-host1_vdsm.csr \ -out /tmp/test_virt-host1_vdsm.cer \ -startdate `(date --utc --date "now -1 days" +"%y%m%d%H%M%SZ")` \ -subj "/O=example.test/CN=virt-host1.example.test\ -utf8 Имя субъекта в сертификате должно быть в формате "/O=example.test/CN=virt-host1.example.test", укажите ваши значения. Копируем новый сертификат с oVirt engine на oVirt node (virt-host1) в /tmp. Копируем новый сертификат в каталоги служб предварительно создав копию существующих сертификатов [root@virt-host1 ~]# cp /etc/pki/vdsm/certs/vdsmcert.pem /etc/pki/vdsm/certs/vdsmcert.pem.bak [root@virt-host1 ~]# cp /tmp/test_virt-host1_vdsm.cer /etc/pki/vdsm/certs/vdsmcert.pem [root@virt-host1 ~]# cp /etc/pki/vdsm/libvirt-spice/server-cert.pem /etc/pki/vdsm/libvirt-spice/server-cert.pem.bak [root@virt-host1 ~]# cp /etc/pki/vdsm/certs/vdsmcert.pem /etc/pki/vdsm/libvirt-spice/server-cert.pem [root@virt-host1 ~]# cp /etc/pki/libvirt/clientcert.pem /etc/pki/libvirt/clientcert.pem.bak [root@virt-host1 ~]# cp /etc/pki/vdsm/certs/vdsmcert.pem /etc/pki/libvirt/clientcert.pem Перезапускаем службы: [root@virt-host1 ~]# systemctl restart libvirtd [root@virt-host1 ~]# systemctl restart vdsmd Проверяем срок действия сертификата [root@virt-host1 ~]# openssl x509 -noout -enddate -in /etc/pki/vdsm/certs/vdsmcert.pem Повторяем процедуру на остальных узлах с истёкшим сроком действия сертификатов. Выполняем обновления сертификатов центра управления, как описано в "Обновление сертификатов oVirt Engine" Заходим на web-консоль и проверяем работу кластера. У созданных таким образом сертификатов будет отсутствовать subject alternative name, о чём будет выдано предупреждение (через несколько часов): Certificate of host virt-host1.example.test is invalid. The certificate doesn't contain valid subject alternative name, please enroll new certificate for the host. Поэтому после восстановления доступа к web-консоли необходимо выполнить обновление сертификатов согласно официальной документации. Обновление сертификатов после истечения сроков действия при недоступном HostedEngine На практике данное решение не проверялось, но теоретически оно должно сработать. Если центр управления Engine выключен и не запускается, а в журнале journalctl на гипервизоре появляются записи libvirtd[2101]: The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired ... systemd[1]: Failed to start Virtualization daemon Оставляем включенным один гипервизор oVirt node. Определяем время окончания действия сертификата гипервизора: [root@virt-host1 ~]# openssl x509 -noout -enddate -in /etc/pki/vdsm/certs/vdsmcert.pem Устанавливаем дату и время до окончания действия сертификата [root@virt-host1 ~]# systemctl stop chronyd [root@virt-host1 ~]# timedatectl set-time "2023-01-01 12:00:00" Перезапускаем службы [root@virt-host1 ~]# systemctl restart libvirtd [root@virt-host1 ~]# systemctl restart vdsmd Подключаемся к libvirtd через virsh и ждём, когда запустится HostedEngine [root@virt-host1 ~]# virsh -c qemu:///system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf virsh # list --all Id Name State ------------------------------ 1 HostedEngine running Выполняем обновление сертификатов по процедуре "Обновление сертификатов до истечения сроков действия" Использованные материалы Документация oVirt Проект natman Wikipedia Блог IT-KB
  •  
    27.02.2023 , Автор: casm
    Ключи: ovirt, cert, ssl / Лицензия: CC-BY
    Раздел:    Корень / Безопасность / Виртуализация - Xen, OpenVZ, KVM, Qemu

    Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, пох. (?), 21:17, 28/02/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
      libvirtd[2101]: The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
    а что такого волшебного в этом сертификате, что его нельзя сгенерировать вручную, зная имя файла и имея возможность посмотреть параметры, и зачем-то нужно вытанцовывать с разваливанием всего кластера и переводом стре...времени? Ключ и csr наверняка валяются там же рядышком без пароля, как у модных девляпсов же везде и принято.

    P.S. за дополнительные $500 я расскажу вам как генерируют сертификаты с altname. За 600 - если выяснится что в редгаде как обычно на десять лет устаревшая версия openssl требует вытанцовывания с шелл-командлетами вместо параметров. Соглашайтесь, удовольствие почитания редхатовского хелпцентра дороже на круг обойдется.

     
     
  • 2.2, casm (ok), 05:34, 01/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    CA находится на oVirt Engine. Если oVirt развёрнут по схеме HostedEngine, то ВМ с CA не запустится пока vdsmcert.pem has expired.
    Замкнутый круг - чтобы починить сертификат нужен СА, а СА не запустится пока сертификат не починен.
    Самоподписной сертификат хоть с altname, хоть без - кластер не примет.
    Можно развернуть Engine на физическом сервере, но тогда для него не будет High Availability.
     
     
  • 3.8, пох. (?), 16:12, 05/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    а она штатно не запущена что-ли? Т.е. это не сама engine а какая-то отдельная только-ca виртуалка запускающаяся раз в пятилетку ради подписи?

    Паааанятна...
    (наверное он тоже где-то на образе диска лежит в виде обычного ca cert, но тут верю, проще время поменять чем колупаться)

    Если что - altname в современных openssl можно прямо в командной строке указать (подсмотрев в устаревшем серте образец). В устаревших только через extension config, который бай дизайн не однострочный.

     
     
  • 4.9, casm (ok), 17:03, 05/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    CA сделан на базе openssl, находится на виртуалке с engine работает постоянно, отдельной виртуалки для CA нет.
    Но если выключить engine при истекшем сертификате (сбой питания или "у нас консоль не работает, а давайте всё перезагрузим, может заработает"), то обратно она уже не включится.
     
     
  • 5.10, пох. (?), 17:22, 05/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Но если выключить engine при истекшем сертификате (сбой питания или "у нас

    а, ясно, то есть при штатной работе не требуется, только если сам зачем-то и сломал.

     

  • 1.3, Noname (??), 14:14, 01/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Доступ к документации Red Hat открывается за час:
    1. регистрируемся в Red Hat Developer program https://developers.redhat.com
    2. устанавливаем в виртуалку RHEL и активируем его на свой аккаунт из п.1

    далее раз в год ставим и активируем RHEL, для продления подписки

    https://developers.redhat.com/products/rhel/download
    https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux

     
  • 1.4, RHEL Fan (?), 21:33, 03/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Там еще такой сертификат есть /etc/pki/vdsm/libvirt-vnc/server-cert.pem и он тоже может протухнуть. Причем, в каких-то версиях oVirt он при обновлении сертификатов не обновлялся. Если протухнет, виртуалки на хосте запустить не получится, в т.ч. и hosted engine.

    on host just copy renewed vdsm key and cert to libvirt-vnc

    cp /etc/pki/vdsm/certs/vdsmcert.pem
    /etc/pki/vdsm/libvirt-vnc/server-cert.pem
    cp /etc/pki/vdsm/keys/vdsmkey.pem /etc/pki/vdsm/libvirt-vnc/server-key.pem

     
  • 1.5, pofigist (?), 12:48, 04/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > oVirt состоит из двух основных компонентов - oVirt engine и oVirt node.

    Про VDSM забыли

     
  • 1.6, ivan_erohin (?), 08:51, 05/03/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    несколько вопросов автору:

    0) можно ли обойтись без сертификатов вообще ? например чисто ssh и его "pki".

    1) можно ли выпустить сертификаты сроком действия на 100-500 лет ?

    2) можно ли перезавести всю систему на сертификатах летс энкрипт ?
    (inb4 "кто они ваще такие чтобы сертифицировать мои ключи").

    3) знает ли автор что потеря производительности при виртуализации составляет от 5% до 20% (зависит от настроек ВМ, гипервизора и фазы луны) ? измерял ли автор потери при данном решении ?

     
     
  • 2.7, casm (ok), 10:37, 05/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    0) сложно сказать - я сисадмин, а не разработчик oVirt. Исходный код доступен https://github.com/oVirt думаю если его изучить, то найдёте решение
    1) теоретически можно отредактировать файлы openssl https://github.com/oVirt/ovirt-engine/blob/master/packaging/pki/openssl.conf
    на практике не проверял
    2) сертификаты web-интерфейса oVirt Engine можно перевести на Let's Encrypt https://habr.com/ru/post/424127/, https://www.ovirt.org/documentation/administration_guide/#Replacing_the_Manage
    для обмена между engine и хостами виртуализации используются самоподписные сертификаты, созданные на engine.
    По-умолчанию CA находится на ваших серверах, под вашим управлением. Переводить их в зависимость от внешних служб, для меня - сомнительная идея.
    3) потеря производительности при виртуализации будет заметна при интенсивном использовании CPU и памяти (СУБД, задачи САПР) - для таких задач лучше использовать физические сервера. Виртуализацию лучше использовать для мало или средне нагруженных задач - появится возможность миграции между хостами, динамически менять объём ОЗУ и кол-во процессоров ВМ если не будет хватать ресурсов для задачи. На моей практике производительность больше упирается в ограничения ввода/вывода дисковой системы - когда несколько ВМ совместно используют хранилище.
     
     
  • 3.11, 54r (?), 06:38, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Переводить их в зависимость от внешних служб, для меня - сомнительная идея.

    а перезагружать сервис ради обновления сертификатов идея не сомнительная?

    есть unit который умеет менять сертификаты без перезагрузки, не скажу, что сервис на 100% доступен при этом, просто не проверял.

    > потеря производительности при виртуализации будет заметна при интенсивном использовании CPU и памяти (СУБД, задачи САПР) - для таких задач лучше использовать физические сервера.

    Очень сомнительное утверждение, физический сервер в любой момент может сломаться, и начнется пляска с бубном для его поднимания, для виртуалок даже без HA это решается в пару кликов

     
     
  • 4.12, casm (ok), 08:58, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    1. Сертификаты Let's Encrypt можно использовать только для web-консоли, для хостов (гипервизоров) используется внутренний CA.
    Перезапускать службы при обновлении сертификатов хоть let's encrypt, хоть собственных в любом случае придётся. Только вот с let's encrypt это придётся делать раз в 90 дней, а с собственными - раз с год.

    2. Физические сервера, естественно, нужно дублировать. Для защиты служб есть кластерные решения: Pacemaker/Corosync, Oracle Clusterware, MS Cluster Services.

     
     
  • 5.15, (?), 02:35, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > раз в 90 дней, а с собственными - раз с год.

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

    > 2. Физические сервера, естественно, нужно дублировать. Для защиты служб есть кластерные
    > решения: Pacemaker/Corosync, Oracle Clusterware, MS Cluster Services.

    есть, но это довольно высокоуровневые решения особенности взаимодействия которых могут быть неожиданными, например у нас недавно сервер лег - сдох диск, из состава ceph, служба отвалилась, systemd решил признать сервер аварийным и перевел его в режим восстановление погасив при этом остальные osd. Какбы не первый диск и даже не из первого десятка, и отрабатывало адекватно, а тут вдруг так.. думаю тут применимо главное правило - работает - не трогай))

     
     
  • 6.16, пох. (?), 11:01, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Честно говоря не вижу большой разницы, на мой вгляд это тоже самое,
    > что менять пароль root на каждом сервере раз в год.

    а зачем его менять раз в год? Вот и с сертификатом такая же херня.
    Чем реже ты устраиваешь сам себе катастрофу - тем меньше шансов что что-то пойдет не так.

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

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

    ну в целом ничего неожиданного - мы и так знаем что и системдрянь дерьмо и ceph оно же ж, и несколько osd на одном сервере плохая идея и так делают от бедности, не всегда понимая даже что это не redundancy а наоборот spof.

    Но в копилочку идеям bare-metal-фобов добавлю еще один аргумент - у нас с некоторых пор даже плохо ложащиеся в концепцию хосты с черезмерным требованием к ресурсам (то есть для них нет никакой live migration, к примеру, некуда) - решено ставить в вм... если это линукс.
    Причина - ... ага, правильно - современные энтерпрайзные железки с ним плохо совместимы (браво dell с сертификацией 16й убунты... ну да, 16я на него ставится. Вот с 22 уже не все так красиво).

    А так он ничего напрямую не видит - вот и не страдает. Ни тебе spirious interrupts полный лог, ни внезапных крэшей xfs...

    (Правда, у нас все же sphere. Например, с vNUMA и многими другими неожиданными фичами. Не уверен что с kvm получилось бы хорошо.)

     
     
  • 7.17, (?), 01:05, 10/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > системдрянь дерьмо

    Это факт, 3.5 калечные насройки, а самое прикольное что оно кэширует результат и при явной команде запуска службы ничего не делает вообще, просто сообщает что запуск был неудачным, а то что это было 20 мин назад и все починили дозвезды.

    > и ceph оно же ж

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

    > современные энтерпрайзные железки с ним плохо совместимы

    Сравнительно недавно выкинули железный сервер на убунте 10 или 12, где был контроллер потока е1, с проприетарным разумеется драйвером только для того конкретного ядра, так что "современность" несовместимости это такое, всегда была.. надо просто избегать подобных решений, и открытые проекты отлично этому способствуют, поэтому как-то так вышло что у нас тут секта свидетелей столмана образовалась.

    > несколько osd на одном сервере плохая идея

    осд это которые диск обслуживают, pg может быть?  по одному диску на сервер - вообще глупость получается, сервер как преобразователь с сата на эзернет работает, причем чертовски неэффективный

     
     
  • 8.18, пох. (?), 17:02, 11/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    daemon-reload должен это сбрасывать гуглить ceph war story в окрестностях ред... большой текст свёрнут, показать
     
     
  • 9.19, qq (??), 01:20, 20/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Да, это работает, вот только пока разобрались, У ceph, разве что в заголвке са... текст свёрнут, показать
     
  • 4.13, ivan_erohin (?), 15:57, 06/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > а перезагружать сервис ради обновления сертификатов идея не сомнительная?

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

     
     
  • 5.14, (?), 01:14, 07/03/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Не согласен.

    Любой удачный инструмент со временем может начать использоваться "не совсем" так как задумывалось автором, начиная с ethernet и ip, эти костыли буквально составляют мир it.

    И тот факт, что какойто параметр надо менять онлайн и есть часть "не совсем" составляющей.

     
     
  • 6.20, ivan_erohin (?), 07:45, 31/03/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    во чего нашел. зацените:

    https://admx.help/?Category=Windows_11_2022&Policy=Microsoft.Policies.Removabl

    "Note: If no reboot is forced, the access right does not take effect until the operating system is restarted."

    > Любой удачный инструмент со временем может начать использоваться "не совсем" так как задумывалось автором

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

     

  • 1.21, пох. (?), 13:57, 08/08/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    да, пока оно еще не ушло совсем в историю - на днях выяснял, что в аналогичном случае бывает у вмвари (с семерки разумеется тоже сплошные ненужно-сертификаты).

    А... ничего... Если выведенный в оффлайн (и соответственно не способный автоматически ничего сделать) хост вернуть в кластер, и выяснится что у него просрочен сертификат - он автоматически обновится, потому что раз ты такой д-л, то уже не надо тебе ничего ни сообщать, ни требовать от тебя.

    В остальных случаях (пока все еще способно обновляться само) - загорается аларм и ты идешь тыкать кнопку "обновить". Нагрузка на сервер в этот момент немного подскакивает, вероятней всего - фейковая, просто он не может правильно коммуницировать с остальным кластером. И больше не происходит ровно ничего.

     
  • 1.22, Alexey (??), 13:26, 02/03/2024 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Добрый день!

    Спасибо большое за инструкцию.
    А подскажи, пожалуйста, каким путем лучше пойти, если срок действия истек, но гипервизор работает.  Не проще пойти путем с изменением даты и затем стандартным обновлением?

    И на какой версии выполнялась описанная здесь процедура.  
    Для 4.4.3 на базе CentOS 8 релевантно?

    Спасибо!

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру