forum.opennet.ru - "Раздел полезных советов: Обновление сертификатов oVirt" (23)

"Раздел полезных советов: Обновление сертификатов oVirt"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Обновление сертификатов oVirt"	+/–
Сообщение от auto_tips (?), 28-Фев-23, 21:17
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 дней, их необходимо обновлять раз в год. Процедура обновления действующих сертификатов описана в официальной [[https://www.ovirt.org/documentation/administration_guide/ind... документации]]. []Если вы допустите истечение срока действия сертификатов, то гипервизоры и центр управления Engine перестанут взаимодействовать. [] В Web-консоль невозможно будет войти, виртуальные машины продолжать работать, но с ними ничего нельзя будет сделать: нельзя изменить параметры виртуального железа, нельзя мигрировать на другой узел, после выключения ВМ её будет невозможно включить снова. Восстановление займёт много времени. Процедура восстановления просроченных сертификатов описана в [[https://access.redhat.com/solutions/3532921 руководстве]]. Для доступа к нему необходима действующая платная подписка Red Hat Virtualization (RHV) 4.x. Решение для восстановления без подписки я обнаружил на [[https://github.com/natman/ovirt_renew_certs 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 Переводим узел (гипервизор) в режим обслуживания (Managament -> Maintenance) - все машины на узле будут мигрированы, привязаные (pinned) машины будут выключены. [[IMG /opennews/pics_base/CFD0C5CECEC5D4_1677558915.png]] Выбираем Installation -> Enroll Certificate [[IMG /opennews/pics_base/CFD0C5CECEC5D4_1677558941.png]] Выводим узел из режима обслуживания [[IMG /opennews/pics_base/CFD0C5CECEC5D4_1677558985.png]] Повторяем операции для всех оставшихся узлов в кластере ++ Обновление сертификатов 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[] [[IMG /opennews/pics_base/CFD0C5CECEC5D4_1677559026.png]] Дожидаемся окончания работы скрипта. С узла Ovirt host выводим центр управления ВМ из режима обслуживания: [root@virt-host1 ~]# hosted-engine --set-maintenance --mode=none Подключаемся к web-консоли и проверяем дату окончания действия сертификата. ++ Обновление сертификатов после истечения сроков действия Если вы допустите истечение срока действия сертификатов, то в web-консоль невозможно будет войти. [[IMG /opennews/pics_base/CFD0C5CECEC5D4_1677559056.png]] Гипервизоры и центр управления Engine перестанут взаимодействовать. [[IMG /opennews/pics_base/CFD0C5CECEC5D4_1677559077.png]] Чтобы восстановить сертификаты выполняем следующие шаги. Подключаемся через 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-консоли необходимо выполнить обновление сертификатов согласно официальной [[https://www.ovirt.org/documentation/administration_guide/ind... документации]]. ++ Обновление сертификатов после истечения сроков действия при недоступном 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 Выполняем обновление сертификатов по процедуре "Обновление сертификатов до истечения сроков действия" ++ Использованные материалы [[https://ovirt.org/documentation/administration_guide/index.html Документация oVirt]] [[https://github.com/natman/ovirt_renew_certs Проект natman]] [[https://en.wikipedia.org/wiki/OVirt Wikipedia]] [[https://blog.it-kb.ru/2016/09/10/install-ovirt-4-0-part-1-cr.../ Блог IT-KB]] URL: Обсуждается: http://www.opennet.me/tips/info/3216.shtml
Ответить \| Правка \| Cообщить модератору

Оглавление

libvirtd 2101 The server certificate etc pki vdsm certs vdsmcert pem has ex, пох. (?), 21:17 , 28-Фев-23, (1)

CA находится на oVirt Engine Если oVirt развёрнут по схеме HostedEngine, то ВМ , casm (ok), 05:34 , 01-Мрт-23, (2)

а она штатно не запущена что-ли Т е это не сама engine а какая-то отдельная то, пох. (?), 16:12 , 05-Мрт-23, (8)

CA сделан на базе openssl, находится на виртуалке с engine работает постоянно, о, casm (ok), 17:03 , 05-Мрт-23, (9)

а, ясно, то есть при штатной работе не требуется, только если сам зачем-то и сло, пох. (?), 17:22 , 05-Мрт-23, (10)

Доступ к документации Red Hat открывается за час 1 регистрируемся в Red Hat Dev, Noname (??), 14:14 , 01-Мрт-23, (3)
Там еще такой сертификат есть etc pki vdsm libvirt-vnc server-cert pem и он тож, RHEL Fan (?), 21:33 , 03-Мрт-23, (4)
Про VDSM забыли, pofigist (?), 12:48 , 04-Мрт-23, (5)
несколько вопросов автору 0 можно ли обойтись без сертификатов вообще наприме, ivan_erohin (?), 08:51 , 05-Мрт-23, (6)

0 сложно сказать - я сисадмин, а не разработчик oVirt Исходный код доступен ht, casm (ok), 10:37 , 05-Мрт-23, (7)

а перезагружать сервис ради обновления сертификатов идея не сомнительная есть un, 54r (?), 06:38 , 06-Мрт-23, (11) –1

1 Сертификаты Let s Encrypt можно использовать только для web-консоли, для хост, casm (ok), 08:58 , 06-Мрт-23, (12)

Честно говоря не вижу большой разницы, на мой вгляд это тоже самое, что менять п, 5к (?), 02:35 , 07-Мрт-23, (15)

а зачем его менять раз в год Вот и с сертификатом такая же херня Чем реже ты ус, пох. (?), 11:01 , 07-Мрт-23, (16)

Это факт, 3 5 калечные насройки, а самое прикольное что оно кэширует результат и, 5к (?), 01:05 , 10-Мрт-23, (17) +1

daemon-reload должен это сбрасывать гуглить ceph war story в окрестностях редд, пох. (?), 17:02 , 11-Мрт-23, (18)

Да, это работает, вот только пока разобрались, У ceph, разве что в заголвке сай, qq (??), 01:20 , 20-Мрт-23, (19)

нет если софтверный архитектор этого продукта был чудак или недотыкомка,то некот, ivan_erohin (?), 15:57 , 06-Мрт-23, (13)

Не согласен Любой удачный инструмент со временем может начать использоваться не, 5к (?), 01:14 , 07-Мрт-23, (14)

во чего нашел зацените https admx help Category Windows_11_2022 Policy Micro, ivan_erohin (?), 07:45 , 31-Мрт-23, (20) +1

да, пока оно еще не ушло совсем в историю - на днях выяснял, что в аналогичном с, пох. (?), 13:57 , 08-Авг-23, (21)
Добрый день Спасибо большое за инструкцию А подскажи, пожалуйста, каким путем л, Alexey (??), 13:26 , 02-Мрт-24, (22)

Изменение времени в гипервизоре при работающих вирт машинах может привести к на, casm (ok), 17:31 , 12-Июн-24, (23)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от пох. (?), 28-Фев-23, 21:17 +/–

  libvirtd[2101]: The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
а что такого волшебного в этом сертификате, что его нельзя сгенерировать вручную, зная имя файла и имея возможность посмотреть параметры, и зачем-то нужно вытанцовывать с разваливанием всего кластера и переводом стре...времени? Ключ и csr наверняка валяются там же рядышком без пароля, как у модных девляпсов же везде и принято.
P.S. за дополнительные $500 я расскажу вам как генерируют сертификаты с altname. За 600 - если выяснится что в редгаде как обычно на десять лет устаревшая версия openssl требует вытанцовывания с шелл-командлетами вместо параметров. Соглашайтесь, удовольствие почитания редхатовского хелпцентра дороже на круг обойдется.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2

2. Сообщение от casm (ok), 01-Мрт-23, 05:34 +/–

CA находится на oVirt Engine. Если oVirt развёрнут по схеме HostedEngine, то ВМ с CA не запустится пока vdsmcert.pem has expired.
Замкнутый круг - чтобы починить сертификат нужен СА, а СА не запустится пока сертификат не починен.
Самоподписной сертификат хоть с altname, хоть без - кластер не примет.
Можно развернуть Engine на физическом сервере, но тогда для него не будет High Availability.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #8

3. Сообщение от Noname (??), 01-Мрт-23, 14:14 +/–

Доступ к документации 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-...

Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от RHEL Fan (?), 03-Мрт-23, 21:33 +/–

Там еще такой сертификат есть /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

Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от pofigist (?), 04-Мрт-23, 12:48 +/–

> oVirt состоит из двух основных компонентов - oVirt engine и oVirt node.
Про VDSM забыли

Ответить | Правка | Наверх | Cообщить модератору

6. Сообщение от ivan_erohin (?), 05-Мрт-23, 08:51 +/–

несколько вопросов автору:
0) можно ли обойтись без сертификатов вообще ? например чисто ssh и его "pki".
1) можно ли выпустить сертификаты сроком действия на 100-500 лет ?
2) можно ли перезавести всю систему на сертификатах летс энкрипт ?
(inb4 "кто они ваще такие чтобы сертифицировать мои ключи").
3) знает ли автор что потеря производительности при виртуализации составляет от 5% до 20% (зависит от настроек ВМ, гипервизора и фазы луны) ? измерял ли автор потери при данном решении ?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

7. Сообщение от casm (ok), 05-Мрт-23, 10:37 +/–

0) сложно сказать - я сисадмин, а не разработчик oVirt. Исходный код доступен https://github.com/oVirt думаю если его изучить, то найдёте решение
1) теоретически можно отредактировать файлы openssl https://github.com/oVirt/ovirt-engine/blob/master/packaging/...
на практике не проверял
2) сертификаты web-интерфейса oVirt Engine можно перевести на Let's Encrypt https://habr.com/ru/post/424127/, https://www.ovirt.org/documentation/administration_guide/#Re...
для обмена между engine и хостами виртуализации используются самоподписные сертификаты, созданные на engine.
По-умолчанию CA находится на ваших серверах, под вашим управлением. Переводить их в зависимость от внешних служб, для меня - сомнительная идея.
3) потеря производительности при виртуализации будет заметна при интенсивном использовании CPU и памяти (СУБД, задачи САПР) - для таких задач лучше использовать физические сервера. Виртуализацию лучше использовать для мало или средне нагруженных задач - появится возможность миграции между хостами, динамически менять объём ОЗУ и кол-во процессоров ВМ если не будет хватать ресурсов для задачи. На моей практике производительность больше упирается в ограничения ввода/вывода дисковой системы - когда несколько ВМ совместно используют хранилище.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #11

8. Сообщение от пох. (?), 05-Мрт-23, 16:12 +/–

а она штатно не запущена что-ли? Т.е. это не сама engine а какая-то отдельная только-ca виртуалка запускающаяся раз в пятилетку ради подписи?
Паааанятна...
(наверное он тоже где-то на образе диска лежит в виде обычного ca cert, но тут верю, проще время поменять чем колупаться)
Если что - altname в современных openssl можно прямо в командной строке указать (подсмотрев в устаревшем серте образец). В устаревших только через extension config, который бай дизайн не однострочный.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #9

9. Сообщение от casm (ok), 05-Мрт-23, 17:03 +/–

CA сделан на базе openssl, находится на виртуалке с engine работает постоянно, отдельной виртуалки для CA нет.
Но если выключить engine при истекшем сертификате (сбой питания или "у нас консоль не работает, а давайте всё перезагрузим, может заработает"), то обратно она уже не включится.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от пох. (?), 05-Мрт-23, 17:22 +/–

> Но если выключить engine при истекшем сертификате (сбой питания или "у нас
а, ясно, то есть при штатной работе не требуется, только если сам зачем-то и сломал.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

11. Сообщение от 54r (?), 06-Мрт-23, 06:38 –1 +/–

> Переводить их в зависимость от внешних служб, для меня - сомнительная идея.
а перезагружать сервис ради обновления сертификатов идея не сомнительная?
есть unit который умеет менять сертификаты без перезагрузки, не скажу, что сервис на 100% доступен при этом, просто не проверял.
> потеря производительности при виртуализации будет заметна при интенсивном использовании CPU и памяти (СУБД, задачи САПР) - для таких задач лучше использовать физические сервера.
Очень сомнительное утверждение, физический сервер в любой момент может сломаться, и начнется пляска с бубном для его поднимания, для виртуалок даже без HA это решается в пару кликов

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #12, #13

12. Сообщение от casm (ok), 06-Мрт-23, 08:58 +/–

1. Сертификаты Let's Encrypt можно использовать только для web-консоли, для хостов (гипервизоров) используется внутренний CA.
Перезапускать службы при обновлении сертификатов хоть let's encrypt, хоть собственных в любом случае придётся. Только вот с let's encrypt это придётся делать раз в 90 дней, а с собственными - раз с год.
2. Физические сервера, естественно, нужно дублировать. Для защиты служб есть кластерные решения: Pacemaker/Corosync, Oracle Clusterware, MS Cluster Services.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #15

13. Сообщение от ivan_erohin (?), 06-Мрт-23, 15:57 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #14

14. Сообщение от 5к (?), 07-Мрт-23, 01:14 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #20

15. Сообщение от 5к (?), 07-Мрт-23, 02:35 +/–

> раз в 90 дней, а с собственными - раз с год.
Честно говоря не вижу большой разницы, на мой вгляд это тоже самое, что менять пароль root на каждом сервере раз в год.
> 2. Физические сервера, естественно, нужно дублировать. Для защиты служб есть кластерные
> решения: Pacemaker/Corosync, Oracle Clusterware, MS Cluster Services.
есть, но это довольно высокоуровневые решения особенности взаимодействия которых могут быть неожиданными, например у нас недавно сервер лег - сдох диск, из состава ceph, служба отвалилась, systemd решил признать сервер аварийным и перевел его в режим восстановление погасив при этом остальные osd. Какбы не первый диск и даже не из первого десятка, и отрабатывало адекватно, а тут вдруг так.. думаю тут применимо главное правило - работает - не трогай))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #16

16. Сообщение от пох. (?), 07-Мрт-23, 11:01 +/–

> Честно говоря не вижу большой разницы, на мой вгляд это тоже самое,
> что менять пароль root на каждом сервере раз в год.
а зачем его менять раз в год? Вот и с сертификатом такая же херня.
Чем реже ты устраиваешь сам себе катастрофу - тем меньше шансов что что-то пойдет не так.
С сертификатом используемым через браузер есть ровно одна проблема - что современные браузеры под контролем то ли вредителей из спецслужб то ли полезных идиотов перестают вообще поддерживать сертификаты более чем с годовым сроком действия. Но внутри системы где нет никакого браузера, полагаю, действительно можно хоть раз в сто лет их менять.
> есть, но это довольно высокоуровневые решения особенности взаимодействия которых могут
> быть неожиданными, например у нас недавно сервер лег - сдох диск,
ну в целом ничего неожиданного - мы и так знаем что и системдрянь дерьмо и ceph оно же ж, и несколько osd на одном сервере плохая идея и так делают от бедности, не всегда понимая даже что это не redundancy а наоборот spof.
Но в копилочку идеям bare-metal-фобов добавлю еще один аргумент - у нас с некоторых пор даже плохо ложащиеся в концепцию хосты с черезмерным требованием к ресурсам (то есть для них нет никакой live migration, к примеру, некуда) - решено ставить в вм... если это линукс.
Причина - ... ага, правильно - современные энтерпрайзные железки с ним плохо совместимы (браво dell с сертификацией 16й убунты... ну да, 16я на него ставится. Вот с 22 уже не все так красиво).
А так он ничего напрямую не видит - вот и не страдает. Ни тебе spirious interrupts полный лог, ни внезапных крэшей xfs...
(Правда, у нас все же sphere. Например, с vNUMA и многими другими неожиданными фичами. Не уверен что с kvm получилось бы хорошо.)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от 5к (?), 10-Мрт-23, 01:05 +1 +/–

> системдрянь дерьмо
Это факт, 3.5 калечные насройки, а самое прикольное что оно кэширует результат и при явной команде запуска службы ничего не делает вообще, просто сообщает что запуск был неудачным, а то что это было 20 мин назад и все починили дозвезды.
> и ceph оно же ж
ну тут хз, работает уже сколько лет, скорость конечно так себе, но блин, работает и сервера вылетали и упски дохли и кондишены умирали, а данные живы.
> современные энтерпрайзные железки с ним плохо совместимы
Сравнительно недавно выкинули железный сервер на убунте 10 или 12, где был контроллер потока е1, с проприетарным разумеется драйвером только для того конкретного ядра, так что "современность" несовместимости это такое, всегда была.. надо просто избегать подобных решений, и открытые проекты отлично этому способствуют, поэтому как-то так вышло что у нас тут секта свидетелей столмана образовалась.
> несколько osd на одном сервере плохая идея
осд это которые диск обслуживают, pg может быть?  по одному диску на сервер - вообще глупость получается, сервер как преобразователь с сата на эзернет работает, причем чертовски неэффективный

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #18

18. Сообщение от пох. (?), 11-Мрт-23, 17:02 +/–

> Это факт, 3.5 калечные насройки, а самое прикольное что оно кэширует результат
daemon-reload должен это сбрасывать.
> ну тут хз, работает уже сколько лет
гуглить "ceph war story" в окрестностях реддита. Я, увы, не имею доступа к той системе где осталась закладочка. Там все прекрасно - и причина, и эффект, и как разбирались, и как починили - но наиболее прекрасное из именно относящегося к самому ceph - это поиски тех физических носителей из-за которых все навернулось. Шерклокхламс отдыхает.
> Сравнительно недавно выкинули железный сервер на убунте 10 или 12, где был контроллер потока е1
с ними в линуксах исторически было неочень - производители категорически не давали спеки, а желающих воевать тоже не слишком много находилось.
Но тут все проще - энтерпрайзные железяки (то есть такое что производится сотнями тыщ и стоит по всем цодам всего мира), дрова к которым вроде бы даже и нормальные (ну, вот не считая spirious interrupts и отвалов fc потому что линух не умеет нормально в fc) но ты попробуй-ка установись. Вот к примеру убунта при установке - норовит без предупреждения пощупать всю usb-периферию. Ой, и сресетить заодно виртуальную шинку на которой висит образ установочного диска. Потому что она видимо по факту usb, в sata превращается где-то по дороге виртуально. 16 так не делала, вот для нее и сертифицировано.
Что там было с редхатоидами - уже не упомню, но тоже что-то не слава Б-гу, и еще и отвалы xfs по неведомым причинам. (Тоже известная фича, и.. тоже прекрасно лечится виртуализацией вот ровно на той же самой железке)
> осд это которые диск обслуживают
угу. Последствия при отвале сервера с таким цирком - иногда немного превышают ожидания (по сути всегда когда кластер достаточно большой - не уследишь просто).
Угадаешь, что предлагает редхат в качестве основного и рекомендуемого решения? Ну чтоб вот не один диск на сервер (на самом деле - хорошо. но дорого. sas2ethernet коннектор это _хорошо_ пока мы можем их параллельно задействовать МНОГО)
Ой: "а вы ставьте их поверх hardware raid6". Спасибо, ребята, как бы мы без вас...
(Если что, для gluster, который куда меньше чреват сюпризами при такой работе - тем не менее, у них действует та же самая рекомендация. Там, правда, подоплека другая.)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #19

19. Сообщение от qq (??), 20-Мрт-23, 01:20 +/–

> daemon-reload
Да, это работает, вот только пока разобрались,..
> Ой: "а вы ставьте их поверх hardware raid6"
У ceph, разве что в заголвке сайта нет варнинга не использовать его поверх других прослоек.
> gluster, который куда меньше чреват сюпризами при такой работе
Возможно, но старый баг лучше новых двух, вот на 8 марта очередной диск улетел в края вечной охоты, и никто и не заметил, хотя перебалансировка обычно заметно просаживает производительность, но на выходных как-то так прошло само.
> еще и отвалы xfs по неведомым причинам
не сталкивался, хотя допускаю, всякое бывало, например, - утечки памяти mysql базы которой размещены на btrfs которая лежит виртуалкой на zfs, вот это просто ох...ня история, mysql выполняет запрос, и толи нить бтрфс виснит, толи самой бд, но со временем именно бд быхватывает terminate от oom.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

20. Сообщение от ivan_erohin (?), 31-Мрт-23, 07:45 +1 +/–

во чего нашел. зацените:
https://admx.help/?Category=Windows_11_2022&Policy=Microsoft...
"Note: If no reboot is forced, the access right does not take effect until the operating system is restarted."
> Любой удачный инструмент со временем может начать использоваться "не совсем" так как задумывалось автором
групповые политики проектировались так, чтобы применяться и действовать сразу без всяких перезагрузок.
но кто-то где-то не осилил ...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

21. Сообщение от пох. (?), 08-Авг-23, 13:57 +/–

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

Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от Alexey (??), 02-Мрт-24, 13:26 +/–

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

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23

23. Сообщение от casm (ok), 12-Июн-24, 17:31 +/–

> Не проще пойти путем с изменением даты и затем стандартным обновлением?
Изменение времени в гипервизоре при работающих вирт. машинах может привести к нарушению работы ВМ, особенно если ВМ входят в домен Active Directory или внутри них работают СУБД.
Если у вас есть возможность выключить все ВМ, изменить время и перезагрузить гипервизоры, можете проверить вариант с изменением времени.
> на какой версии выполнялась описанная здесь процедура
oVirt Node 4.5 на базе CentOS 8
> Для 4.4.3 на базе CentOS 8 релевантно?
думаю, да

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от пох. (?), 28-Фев-23, 21:17	+/–
libvirtd[2101]: The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired а что такого волшебного в этом сертификате, что его нельзя сгенерировать вручную, зная имя файла и имея возможность посмотреть параметры, и зачем-то нужно вытанцовывать с разваливанием всего кластера и переводом стре...времени? Ключ и csr наверняка валяются там же рядышком без пароля, как у модных девляпсов же везде и принято. P.S. за дополнительные $500 я расскажу вам как генерируют сертификаты с altname. За 600 - если выяснится что в редгаде как обычно на десять лет устаревшая версия openssl требует вытанцовывания с шелл-командлетами вместо параметров. Соглашайтесь, удовольствие почитания редхатовского хелпцентра дороже на круг обойдется.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #2

2. Сообщение от casm (ok), 01-Мрт-23, 05:34	+/–
CA находится на oVirt Engine. Если oVirt развёрнут по схеме HostedEngine, то ВМ с CA не запустится пока vdsmcert.pem has expired. Замкнутый круг - чтобы починить сертификат нужен СА, а СА не запустится пока сертификат не починен. Самоподписной сертификат хоть с altname, хоть без - кластер не примет. Можно развернуть Engine на физическом сервере, но тогда для него не будет High Availability.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1 Ответы: #8

3. Сообщение от Noname (??), 01-Мрт-23, 14:14	+/–
Доступ к документации 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-...
Ответить \| Правка \| Наверх \| Cообщить модератору

4. Сообщение от RHEL Fan (?), 03-Мрт-23, 21:33	+/–
Там еще такой сертификат есть /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
Ответить \| Правка \| Наверх \| Cообщить модератору

5. Сообщение от pofigist (?), 04-Мрт-23, 12:48	+/–
> oVirt состоит из двух основных компонентов - oVirt engine и oVirt node. Про VDSM забыли
Ответить \| Правка \| Наверх \| Cообщить модератору

6. Сообщение от ivan_erohin (?), 05-Мрт-23, 08:51	+/–
несколько вопросов автору: 0) можно ли обойтись без сертификатов вообще ? например чисто ssh и его "pki". 1) можно ли выпустить сертификаты сроком действия на 100-500 лет ? 2) можно ли перезавести всю систему на сертификатах летс энкрипт ? (inb4 "кто они ваще такие чтобы сертифицировать мои ключи"). 3) знает ли автор что потеря производительности при виртуализации составляет от 5% до 20% (зависит от настроек ВМ, гипервизора и фазы луны) ? измерял ли автор потери при данном решении ?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #7

7. Сообщение от casm (ok), 05-Мрт-23, 10:37	+/–
0) сложно сказать - я сисадмин, а не разработчик oVirt. Исходный код доступен https://github.com/oVirt думаю если его изучить, то найдёте решение 1) теоретически можно отредактировать файлы openssl https://github.com/oVirt/ovirt-engine/blob/master/packaging/... на практике не проверял 2) сертификаты web-интерфейса oVirt Engine можно перевести на Let's Encrypt https://habr.com/ru/post/424127/, https://www.ovirt.org/documentation/administration_guide/#Re... для обмена между engine и хостами виртуализации используются самоподписные сертификаты, созданные на engine. По-умолчанию CA находится на ваших серверах, под вашим управлением. Переводить их в зависимость от внешних служб, для меня - сомнительная идея. 3) потеря производительности при виртуализации будет заметна при интенсивном использовании CPU и памяти (СУБД, задачи САПР) - для таких задач лучше использовать физические сервера. Виртуализацию лучше использовать для мало или средне нагруженных задач - появится возможность миграции между хостами, динамически менять объём ОЗУ и кол-во процессоров ВМ если не будет хватать ресурсов для задачи. На моей практике производительность больше упирается в ограничения ввода/вывода дисковой системы - когда несколько ВМ совместно используют хранилище.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #6 Ответы: #11

8. Сообщение от пох. (?), 05-Мрт-23, 16:12	+/–
а она штатно не запущена что-ли? Т.е. это не сама engine а какая-то отдельная только-ca виртуалка запускающаяся раз в пятилетку ради подписи? Паааанятна... (наверное он тоже где-то на образе диска лежит в виде обычного ca cert, но тут верю, проще время поменять чем колупаться) Если что - altname в современных openssl можно прямо в командной строке указать (подсмотрев в устаревшем серте образец). В устаревших только через extension config, который бай дизайн не однострочный.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2 Ответы: #9

9. Сообщение от casm (ok), 05-Мрт-23, 17:03	+/–
CA сделан на базе openssl, находится на виртуалке с engine работает постоянно, отдельной виртуалки для CA нет. Но если выключить engine при истекшем сертификате (сбой питания или "у нас консоль не работает, а давайте всё перезагрузим, может заработает"), то обратно она уже не включится.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8 Ответы: #10

10. Сообщение от пох. (?), 05-Мрт-23, 17:22	+/–
> Но если выключить engine при истекшем сертификате (сбой питания или "у нас а, ясно, то есть при штатной работе не требуется, только если сам зачем-то и сломал.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9

11. Сообщение от 54r (?), 06-Мрт-23, 06:38	–1 +/–
> Переводить их в зависимость от внешних служб, для меня - сомнительная идея. а перезагружать сервис ради обновления сертификатов идея не сомнительная? есть unit который умеет менять сертификаты без перезагрузки, не скажу, что сервис на 100% доступен при этом, просто не проверял. > потеря производительности при виртуализации будет заметна при интенсивном использовании CPU и памяти (СУБД, задачи САПР) - для таких задач лучше использовать физические сервера. Очень сомнительное утверждение, физический сервер в любой момент может сломаться, и начнется пляска с бубном для его поднимания, для виртуалок даже без HA это решается в пару кликов
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #7 Ответы: #12, #13

12. Сообщение от casm (ok), 06-Мрт-23, 08:58	+/–
1. Сертификаты Let's Encrypt можно использовать только для web-консоли, для хостов (гипервизоров) используется внутренний CA. Перезапускать службы при обновлении сертификатов хоть let's encrypt, хоть собственных в любом случае придётся. Только вот с let's encrypt это придётся делать раз в 90 дней, а с собственными - раз с год. 2. Физические сервера, естественно, нужно дублировать. Для защиты служб есть кластерные решения: Pacemaker/Corosync, Oracle Clusterware, MS Cluster Services.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #15

13. Сообщение от ivan_erohin (?), 06-Мрт-23, 15:57	+/–
> а перезагружать сервис ради обновления сертификатов идея не сомнительная? нет. если софтверный архитектор этого продукта был чудак или недотыкомка, то некоторые параметры можно сменить только через рестарт сервиса (или вообще через полную перезагрузку. так тоже бывает).
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #11 Ответы: #14

14. Сообщение от 5к (?), 07-Мрт-23, 01:14	+/–
Не согласен. Любой удачный инструмент со временем может начать использоваться "не совсем" так как задумывалось автором, начиная с ethernet и ip, эти костыли буквально составляют мир it. И тот факт, что какойто параметр надо менять онлайн и есть часть "не совсем" составляющей.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #13 Ответы: #20

15. Сообщение от 5к (?), 07-Мрт-23, 02:35	+/–
> раз в 90 дней, а с собственными - раз с год. Честно говоря не вижу большой разницы, на мой вгляд это тоже самое, что менять пароль root на каждом сервере раз в год. > 2. Физические сервера, естественно, нужно дублировать. Для защиты служб есть кластерные > решения: Pacemaker/Corosync, Oracle Clusterware, MS Cluster Services. есть, но это довольно высокоуровневые решения особенности взаимодействия которых могут быть неожиданными, например у нас недавно сервер лег - сдох диск, из состава ceph, служба отвалилась, systemd решил признать сервер аварийным и перевел его в режим восстановление погасив при этом остальные osd. Какбы не первый диск и даже не из первого десятка, и отрабатывало адекватно, а тут вдруг так.. думаю тут применимо главное правило - работает - не трогай))
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12 Ответы: #16

16. Сообщение от пох. (?), 07-Мрт-23, 11:01	+/–
> Честно говоря не вижу большой разницы, на мой вгляд это тоже самое, > что менять пароль root на каждом сервере раз в год. а зачем его менять раз в год? Вот и с сертификатом такая же херня. Чем реже ты устраиваешь сам себе катастрофу - тем меньше шансов что что-то пойдет не так. С сертификатом используемым через браузер есть ровно одна проблема - что современные браузеры под контролем то ли вредителей из спецслужб то ли полезных идиотов перестают вообще поддерживать сертификаты более чем с годовым сроком действия. Но внутри системы где нет никакого браузера, полагаю, действительно можно хоть раз в сто лет их менять. > есть, но это довольно высокоуровневые решения особенности взаимодействия которых могут > быть неожиданными, например у нас недавно сервер лег - сдох диск, ну в целом ничего неожиданного - мы и так знаем что и системдрянь дерьмо и ceph оно же ж, и несколько osd на одном сервере плохая идея и так делают от бедности, не всегда понимая даже что это не redundancy а наоборот spof. Но в копилочку идеям bare-metal-фобов добавлю еще один аргумент - у нас с некоторых пор даже плохо ложащиеся в концепцию хосты с черезмерным требованием к ресурсам (то есть для них нет никакой live migration, к примеру, некуда) - решено ставить в вм... если это линукс. Причина - ... ага, правильно - современные энтерпрайзные железки с ним плохо совместимы (браво dell с сертификацией 16й убунты... ну да, 16я на него ставится. Вот с 22 уже не все так красиво). А так он ничего напрямую не видит - вот и не страдает. Ни тебе spirious interrupts полный лог, ни внезапных крэшей xfs... (Правда, у нас все же sphere. Например, с vNUMA и многими другими неожиданными фичами. Не уверен что с kvm получилось бы хорошо.)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от 5к (?), 10-Мрт-23, 01:05	+1 +/–
> системдрянь дерьмо Это факт, 3.5 калечные насройки, а самое прикольное что оно кэширует результат и при явной команде запуска службы ничего не делает вообще, просто сообщает что запуск был неудачным, а то что это было 20 мин назад и все починили дозвезды. > и ceph оно же ж ну тут хз, работает уже сколько лет, скорость конечно так себе, но блин, работает и сервера вылетали и упски дохли и кондишены умирали, а данные живы. > современные энтерпрайзные железки с ним плохо совместимы Сравнительно недавно выкинули железный сервер на убунте 10 или 12, где был контроллер потока е1, с проприетарным разумеется драйвером только для того конкретного ядра, так что "современность" несовместимости это такое, всегда была.. надо просто избегать подобных решений, и открытые проекты отлично этому способствуют, поэтому как-то так вышло что у нас тут секта свидетелей столмана образовалась. > несколько osd на одном сервере плохая идея осд это которые диск обслуживают, pg может быть? по одному диску на сервер - вообще глупость получается, сервер как преобразователь с сата на эзернет работает, причем чертовски неэффективный
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #16 Ответы: #18

18. Сообщение от пох. (?), 11-Мрт-23, 17:02	+/–
> Это факт, 3.5 калечные насройки, а самое прикольное что оно кэширует результат daemon-reload должен это сбрасывать. > ну тут хз, работает уже сколько лет гуглить "ceph war story" в окрестностях реддита. Я, увы, не имею доступа к той системе где осталась закладочка. Там все прекрасно - и причина, и эффект, и как разбирались, и как починили - но наиболее прекрасное из именно относящегося к самому ceph - это поиски тех физических носителей из-за которых все навернулось. Шерклокхламс отдыхает. > Сравнительно недавно выкинули железный сервер на убунте 10 или 12, где был контроллер потока е1 с ними в линуксах исторически было неочень - производители категорически не давали спеки, а желающих воевать тоже не слишком много находилось. Но тут все проще - энтерпрайзные железяки (то есть такое что производится сотнями тыщ и стоит по всем цодам всего мира), дрова к которым вроде бы даже и нормальные (ну, вот не считая spirious interrupts и отвалов fc потому что линух не умеет нормально в fc) но ты попробуй-ка установись. Вот к примеру убунта при установке - норовит без предупреждения пощупать всю usb-периферию. Ой, и сресетить заодно виртуальную шинку на которой висит образ установочного диска. Потому что она видимо по факту usb, в sata превращается где-то по дороге виртуально. 16 так не делала, вот для нее и сертифицировано. Что там было с редхатоидами - уже не упомню, но тоже что-то не слава Б-гу, и еще и отвалы xfs по неведомым причинам. (Тоже известная фича, и.. тоже прекрасно лечится виртуализацией вот ровно на той же самой железке) > осд это которые диск обслуживают угу. Последствия при отвале сервера с таким цирком - иногда немного превышают ожидания (по сути всегда когда кластер достаточно большой - не уследишь просто). Угадаешь, что предлагает редхат в качестве основного и рекомендуемого решения? Ну чтоб вот не один диск на сервер (на самом деле - хорошо. но дорого. sas2ethernet коннектор это _хорошо_ пока мы можем их параллельно задействовать МНОГО) Ой: "а вы ставьте их поверх hardware raid6". Спасибо, ребята, как бы мы без вас... (Если что, для gluster, который куда меньше чреват сюпризами при такой работе - тем не менее, у них действует та же самая рекомендация. Там, правда, подоплека другая.)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17 Ответы: #19

19. Сообщение от qq (??), 20-Мрт-23, 01:20	+/–
> daemon-reload Да, это работает, вот только пока разобрались,.. > Ой: "а вы ставьте их поверх hardware raid6" У ceph, разве что в заголвке сайта нет варнинга не использовать его поверх других прослоек. > gluster, который куда меньше чреват сюпризами при такой работе Возможно, но старый баг лучше новых двух, вот на 8 марта очередной диск улетел в края вечной охоты, и никто и не заметил, хотя перебалансировка обычно заметно просаживает производительность, но на выходных как-то так прошло само. > еще и отвалы xfs по неведомым причинам не сталкивался, хотя допускаю, всякое бывало, например, - утечки памяти mysql базы которой размещены на btrfs которая лежит виртуалкой на zfs, вот это просто ох...ня история, mysql выполняет запрос, и толи нить бтрфс виснит, толи самой бд, но со временем именно бд быхватывает terminate от oom.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #18

20. Сообщение от ivan_erohin (?), 31-Мрт-23, 07:45	+1 +/–
во чего нашел. зацените: https://admx.help/?Category=Windows_11_2022&Policy=Microsoft... "Note: If no reboot is forced, the access right does not take effect until the operating system is restarted." > Любой удачный инструмент со временем может начать использоваться "не совсем" так как задумывалось автором групповые политики проектировались так, чтобы применяться и действовать сразу без всяких перезагрузок. но кто-то где-то не осилил ...
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #14

21. Сообщение от пох. (?), 08-Авг-23, 13:57	+/–
да, пока оно еще не ушло совсем в историю - на днях выяснял, что в аналогичном случае бывает у вмвари (с семерки разумеется тоже сплошные ненужно-сертификаты). А... ничего... Если выведенный в оффлайн (и соответственно не способный автоматически ничего сделать) хост вернуть в кластер, и выяснится что у него просрочен сертификат - он автоматически обновится, потому что раз ты такой д-л, то уже не надо тебе ничего ни сообщать, ни требовать от тебя. В остальных случаях (пока все еще способно обновляться само) - загорается аларм и ты идешь тыкать кнопку "обновить". Нагрузка на сервер в этот момент немного подскакивает, вероятней всего - фейковая, просто он не может правильно коммуницировать с остальным кластером. И больше не происходит ровно ничего.
Ответить \| Правка \| Наверх \| Cообщить модератору

22. Сообщение от Alexey (??), 02-Мрт-24, 13:26	+/–
Добрый день! Спасибо большое за инструкцию. А подскажи, пожалуйста, каким путем лучше пойти, если срок действия истек, но гипервизор работает. Не проще пойти путем с изменением даты и затем стандартным обновлением? И на какой версии выполнялась описанная здесь процедура. Для 4.4.3 на базе CentOS 8 релевантно? Спасибо!
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #23

23. Сообщение от casm (ok), 12-Июн-24, 17:31	+/–
> Не проще пойти путем с изменением даты и затем стандартным обновлением? Изменение времени в гипервизоре при работающих вирт. машинах может привести к нарушению работы ВМ, особенно если ВМ входят в домен Active Directory или внутри них работают СУБД. Если у вас есть возможность выключить все ВМ, изменить время и перезагрузить гипервизоры, можете проверить вариант с изменением времени. > на какой версии выполнялась описанная здесь процедура oVirt Node 4.5 на базе CentOS 8 > Для 4.4.3 на базе CentOS 8 релевантно? думаю, да
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #22