Comments 8
Вы лучше сразу скажите: решето, не?
Файнридер покорил — молодцы, все варианты рассматривали.
Поправка, я на хабре не писал про это. Писал я в рассылку и кому-то в почтовом общении. Суть состоит в том, что валидация пакета апдейта осуществляется с помощью расшифровки его gpg. Ключ расшифровки — открытый ключ цитрикса. Если не знать закрытый ключ (а его никто не знает), то «фальшиво зашифровать» не получится.
Относительно жалоб на безопасность: Не выставляйте наружу management-сеть. Просто не выставляйте. Это есть во всех best practicie.
Более того, для параноиков предусмотрен особый режим, в котором нет management интерфейса.
ЗЫ А вот херня с местом в dom0 — известная жопа. Я даже могу рассказать про последствия: если место в dom0 заканчивается, что сервис xapi уходит в неответ и пребывает там до перезапуска (при этом xe-toolstack-restart или /etc/init.d/xapi restart не работает, нужно убивать процесс руками) и расчистки места.
Т.к. именно xapi отвечает за перезапуск доменов, то все операции с VM на хосте останавливаются (т.е. при ребуте машина остаётся running, но не запускается снова — домен висит в -S- состоянии, а xapi его не может domain_destroy(), ибо висит.).
Ситуация ещё лучше с, например, мастером пула. Зависание которого означает переход хостов в полу-автономный режим (только ребут и halt из самих машин).
ЗЫ Уж если тестируете устойчивость xapi к XenAPI, поставьте в 50 потоков команду xe task-list, или там xe vm-memory-target-set для включенной машины. В какой-то момент вы доведёте xapi до засирания логами (xensource.log) со скоростью, которая превышает скорость ротации логов.
У нас в продакте на XCP используется модифицированный образ, у которого логи вынесены на отдельный раздел достаточной ёмкости, как раз для борьбы с подобной порнографией.
ЗЗЫ На полном серьёзе предлагаю изучить опцию pv_bootloader_args — это аргументы, которые передаются программе pygrub, которая запускается от root'а в dom0 при старте любой PV-машины. Там нахулиганить, наверное, тоже можно изрядно.
Относительно жалоб на безопасность: Не выставляйте наружу management-сеть. Просто не выставляйте. Это есть во всех best practicie.
Более того, для параноиков предусмотрен особый режим, в котором нет management интерфейса.
ЗЫ А вот херня с местом в dom0 — известная жопа. Я даже могу рассказать про последствия: если место в dom0 заканчивается, что сервис xapi уходит в неответ и пребывает там до перезапуска (при этом xe-toolstack-restart или /etc/init.d/xapi restart не работает, нужно убивать процесс руками) и расчистки места.
Т.к. именно xapi отвечает за перезапуск доменов, то все операции с VM на хосте останавливаются (т.е. при ребуте машина остаётся running, но не запускается снова — домен висит в -S- состоянии, а xapi его не может domain_destroy(), ибо висит.).
Ситуация ещё лучше с, например, мастером пула. Зависание которого означает переход хостов в полу-автономный режим (только ребут и halt из самих машин).
ЗЫ Уж если тестируете устойчивость xapi к XenAPI, поставьте в 50 потоков команду xe task-list, или там xe vm-memory-target-set для включенной машины. В какой-то момент вы доведёте xapi до засирания логами (xensource.log) со скоростью, которая превышает скорость ротации логов.
У нас в продакте на XCP используется модифицированный образ, у которого логи вынесены на отдельный раздел достаточной ёмкости, как раз для борьбы с подобной порнографией.
ЗЗЫ На полном серьёзе предлагаю изучить опцию pv_bootloader_args — это аргументы, которые передаются программе pygrub, которая запускается от root'а в dom0 при старте любой PV-машины. Там нахулиганить, наверное, тоже можно изрядно.
Можно ссылку где хоть как-то можно почитать про xen api? Интересует именно через XML
Sign up to leave a comment.
«Занимательный XenAPI», или «Новые приключения Citrix XenServer»