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.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, 5к (?), 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, 5к (?), 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, 5к (?), 01:14, 07/03/2023 [^] [^^] [^^^] [ответить]
| +/– |
Не согласен.
Любой удачный инструмент со временем может начать использоваться "не совсем" так как задумывалось автором, начиная с ethernet и ip, эти костыли буквально составляют мир it.
И тот факт, что какойто параметр надо менять онлайн и есть часть "не совсем" составляющей.
| |
|
|
|
|
1.21, пох. (?), 13:57, 08/08/2023 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
да, пока оно еще не ушло совсем в историю - на днях выяснял, что в аналогичном случае бывает у вмвари (с семерки разумеется тоже сплошные ненужно-сертификаты).
А... ничего... Если выведенный в оффлайн (и соответственно не способный автоматически ничего сделать) хост вернуть в кластер, и выяснится что у него просрочен сертификат - он автоматически обновится, потому что раз ты такой д-л, то уже не надо тебе ничего ни сообщать, ни требовать от тебя.
В остальных случаях (пока все еще способно обновляться само) - загорается аларм и ты идешь тыкать кнопку "обновить". Нагрузка на сервер в этот момент немного подскакивает, вероятней всего - фейковая, просто он не может правильно коммуницировать с остальным кластером. И больше не происходит ровно ничего.
| |
1.22, Alexey (??), 13:26, 02/03/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Добрый день!
Спасибо большое за инструкцию.
А подскажи, пожалуйста, каким путем лучше пойти, если срок действия истек, но гипервизор работает. Не проще пойти путем с изменением даты и затем стандартным обновлением?
И на какой версии выполнялась описанная здесь процедура.
Для 4.4.3 на базе CentOS 8 релевантно?
Спасибо!
| |
|
2.23, casm (ok), 17:31, 12/06/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Не проще пойти путем с изменением даты и затем стандартным обновлением?
Изменение времени в гипервизоре при работающих вирт. машинах может привести к нарушению работы ВМ, особенно если ВМ входят в домен Active Directory или внутри них работают СУБД.
Если у вас есть возможность выключить все ВМ, изменить время и перезагрузить гипервизоры, можете проверить вариант с изменением времени.
> на какой версии выполнялась описанная здесь процедура
oVirt Node 4.5 на базе CentOS 8
> Для 4.4.3 на базе CentOS 8 релевантно?
думаю, да
| |
|
|