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.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 может быть? по одному диску на сервер - вообще глупость получается, сервер как преобразователь с сата на эзернет работает, причем чертовски неэффективный
| |
|
|
|
|
|
|
1.21, пох. (?), 13:57, 08/08/2023 [ответить] [﹢﹢﹢] [ · · · ] [↑] [п©б╘п▒Б┬≥Б∙≈ п©б╘п▒Б┬≥Б∙≥п©б╘п▒Б┬≥Б∙⌡п©б╘п▒Б┬≥Б∙▓п©б╘п▒Б┬≥я▒я▐Б√░п▒Б√═Б■─п©б╘п▒Б┬≥ц╥я▐Б√░п▒Б√═Б√└п©б╘п▒Б┬≥Б∙⌡я▐Б√░п▒Б√═Б■─я▐Б√░п▒Б√═Б√▒]
| +/– |
да, пока оно еще не ушло совсем в историю - на днях выяснял, что в аналогичном случае бывает у вмвари (с семерки разумеется тоже сплошные ненужно-сертификаты).
А... ничего... Если выведенный в оффлайн (и соответственно не способный автоматически ничего сделать) хост вернуть в кластер, и выяснится что у него просрочен сертификат - он автоматически обновится, потому что раз ты такой д-л, то уже не надо тебе ничего ни сообщать, ни требовать от тебя.
В остальных случаях (пока все еще способно обновляться само) - загорается аларм и ты идешь тыкать кнопку "обновить". Нагрузка на сервер в этот момент немного подскакивает, вероятней всего - фейковая, просто он не может правильно коммуницировать с остальным кластером. И больше не происходит ровно ничего.
| |
|