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 при истекшем сертификате (сбой питания или "у нас консоль не работает, а давайте всё перезагрузим, может заработает"), то обратно она уже не включится.
| |
|
|
|
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.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 может быть? по одному диску на сервер - вообще глупость получается, сервер как преобразователь с сата на эзернет работает, причем чертовски неэффективный
| |
|
|
|
|
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 релевантно?
думаю, да
| |
|
|