Простите, что задерживаемся с ответом, конец года, много забот :)
Я могу сказать вам из своего опыта, что также работал с cobbler, затем перешел на spacewalk (cobbler являлся частью этого проекта), затем на foreman. Для тех задач которые описываем мы, cobbler вполне подошел бы, но foreman, как наследник spacewalk предлагает более комплексный сервис. Не только PXE-деплой, но и комплексное управление жизненным циклом ПО в организации. То-есть, кроме функциональности PXE этот продукт дает вам возможность из одной точки управлять ПО на уже развернутых машинах. Плюс, являясь апстримом для RHN Satellite, Foreman хорошо интегрируется с другими продуктами RedHat, например Enterprise Virtualisation и его апстримом oVirt, который также присутствует в нашей инфраструктуре.
В случае ванильных установок (все Windows такие) - только базовая система с определенными небольшими преднастройками и необходимым набором драйверов. Исключение - при установке виртуальных машин - автоматически приезжают guest-utils.
В случае установок на базе Linux - вариантов много и мы сейчас активно расширяем список возможного предустановленного ПО. Так мы ставим машины с предустановленными панелями управления, готовый Proxmox, отдельные готовые сервисы (например, готовится к выходу предустановленная инсталляция с сервером RocketChat) и так далее.
Да, мы сразу по-разворачивании и первым тестам заметили заметные проблемы производительности. Поэтому отбросили план сосредоточить все в логгере без фильтрации. Наша цель - до 1000-2000 тысяч сообщений при нормальном функционировании системы. На случай пиков, как защита от потерь и предлагается система в статье. С Реббитом в качестве кеша - система будет медленнее пережевывать сообщения, но их не потеряет.
Мы только начали развивать систему, и далеко не все, что хотим в ней видеть, в ней сейчас есть. Сейчас мы собираем и фильтруем логи с файрволов и деплоя, предстоит добавить различные веб-проекты, сетевое оборудование, виртуализацию и прочее. То-есть речь идет только о части того что должно приходить в систему и обрабатываться ей, поэтому мы заранее закладываем вопросы производительности и масштабирования.
Деплой, файрволы и ресурсы, обеспечивающие деплой дают сейчас поток примерно в 9 миллионов сообщений в сутки, то-есть около 100 сообщений в секунду.
Спасибо за комментарий, особенно за последний, проглядели этот проект, syncthing выглядит оптимальным решением, как минимум по лицензии.
По остальным пунктам: пример указали для тех пользователей, кто не работает с deb/rpm. Пункт 2 - определенно закравшаяся в пост ностальгия, вы совершенно правы :)
Задачей заметки было показать применимость torrent для синхронизации данных внутри инфраструктуры. По странному стечению обстоятельств, на практике технология применяется не так часто, хотя очень удобна и уместна для решения подобных задач.
Нет, все как в ранних версиях, есть Trust, который позволяет "доверять" записям в AD, есть winsync, который работает как синхронизация LDAP, то-есть пользователи в AD и IPA автономны. Скрипт в статье позволяет доработать функциональность winsync, который умеет только синхронизировать пользователей в какой-либо подструктуре LDAP AD. Наш скрипт также синхронит группы, то-есть получается полная копия данных и все сервера не зависят друг от друга, то-есть падение AD не выведет из строя инфраструткру, завязанную на IPA, и наоборот.
Не мониторил коментарии под статьей, поэтому отвечаю поздно. Это именно синхронизация, а не доверие. Доверие нам не подошло, так как AD не было изначально, он появился позже как вторичный сервер.
Не забыли, здесь речь о конкретном кейсе, в котором нужна бинарная совместимость. То-есть, если вам буквально нужен RHEL, но без инфраструктуры редхат, то выбор ограничен. "Забыли", в этом контексте, разве что Oracle Linux.
В остальном, каждый самостоятельный настоящий дистрибутив, в котором не просто "обои от убунты поменяли", а действительно проделали инженерную работу, интересен. В том числе и РЕД ОС.
Посмотрел, спасибо за наводку, не знал об этом проекте. Мы по сути и сделали что-то подобное сами на основе Foreman. По части того как они реализуют работу с Windows - мы тоже пришли к такому способу разворачивания через sysprep, пока тестируем его и живем на старой версии с установкой через Windows PE, попробуем взять наработки из Fog и скрестить с нашим деплоем.
Вам, в свою очередь, как "алаверды", рекомендую посмотреть в сторону Foreman, так как с точки зрения возможностей он значительно мощнее Fog, его функция не ограничена первичным развертыванием ОС, он позволяет управлять всем жизненным циклом ПО (для Linux).
Полный цикл описать трудно, так как не ясно что взять за точку отсчета. Инфраструктура - это довольно комплексная штука и система разворачивания ОС сильно завязана на зеркала, DNS, DHCP, систему сборки и прочее. Мы периодически будем публиковать статьи по отдельным механизмам, но комплексные решения - задача ваша как архитектора и администратора, они зависят от вашей специфики. В этой статье задача была показать как можно разворачивать nix ОС, и что для этой процедуры не просто не обязательно, но даже не нужно использовать собственный инсталлятор. Тот же debian-installer - это та еще "заноза", shell или любой другой язык, используемый вашей командой, куда приятнее и мощнее его инструментария :)
Простите, что задерживаемся с ответом, конец года, много забот :)
Я могу сказать вам из своего опыта, что также работал с cobbler, затем перешел на spacewalk (cobbler являлся частью этого проекта), затем на foreman. Для тех задач которые описываем мы, cobbler вполне подошел бы, но foreman, как наследник spacewalk предлагает более комплексный сервис. Не только PXE-деплой, но и комплексное управление жизненным циклом ПО в организации. То-есть, кроме функциональности PXE этот продукт дает вам возможность из одной точки управлять ПО на уже развернутых машинах. Плюс, являясь апстримом для RHN Satellite, Foreman хорошо интегрируется с другими продуктами RedHat, например Enterprise Virtualisation и его апстримом oVirt, который также присутствует в нашей инфраструктуре.
В случае ванильных установок (все Windows такие) - только базовая система с определенными небольшими преднастройками и необходимым набором драйверов. Исключение - при установке виртуальных машин - автоматически приезжают guest-utils.
В случае установок на базе Linux - вариантов много и мы сейчас активно расширяем список возможного предустановленного ПО. Так мы ставим машины с предустановленными панелями управления, готовый Proxmox, отдельные готовые сервисы (например, готовится к выходу предустановленная инсталляция с сервером RocketChat) и так далее.
Да, мы сразу по-разворачивании и первым тестам заметили заметные проблемы производительности. Поэтому отбросили план сосредоточить все в логгере без фильтрации. Наша цель - до 1000-2000 тысяч сообщений при нормальном функционировании системы. На случай пиков, как защита от потерь и предлагается система в статье. С Реббитом в качестве кеша - система будет медленнее пережевывать сообщения, но их не потеряет.
Мы только начали развивать систему, и далеко не все, что хотим в ней видеть, в ней сейчас есть. Сейчас мы собираем и фильтруем логи с файрволов и деплоя, предстоит добавить различные веб-проекты, сетевое оборудование, виртуализацию и прочее. То-есть речь идет только о части того что должно приходить в систему и обрабатываться ей, поэтому мы заранее закладываем вопросы производительности и масштабирования.
Деплой, файрволы и ресурсы, обеспечивающие деплой дают сейчас поток примерно в 9 миллионов сообщений в сутки, то-есть около 100 сообщений в секунду.
Спасибо за комментарий, особенно за последний, проглядели этот проект, syncthing выглядит оптимальным решением, как минимум по лицензии.
По остальным пунктам: пример указали для тех пользователей, кто не работает с deb/rpm. Пункт 2 - определенно закравшаяся в пост ностальгия, вы совершенно правы :)
Задачей заметки было показать применимость torrent для синхронизации данных внутри инфраструктуры. По странному стечению обстоятельств, на практике технология применяется не так часто, хотя очень удобна и уместна для решения подобных задач.
Отвечая на ваш вопрос - синхронизация паролей в такой схеме - это штатная опция IPA, через утилиту PasswordSync для 389ds
https://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/pass-sync.html подробности тут. Наша статья добавляет к штатному механизму - возможность наладить синхронизацию групп, чего очень не хватает в winsync.
Нет, все как в ранних версиях, есть Trust, который позволяет "доверять" записям в AD, есть winsync, который работает как синхронизация LDAP, то-есть пользователи в AD и IPA автономны. Скрипт в статье позволяет доработать функциональность winsync, который умеет только синхронизировать пользователей в какой-либо подструктуре LDAP AD. Наш скрипт также синхронит группы, то-есть получается полная копия данных и все сервера не зависят друг от друга, то-есть падение AD не выведет из строя инфраструткру, завязанную на IPA, и наоборот.
Не мониторил коментарии под статьей, поэтому отвечаю поздно. Это именно синхронизация, а не доверие. Доверие нам не подошло, так как AD не было изначально, он появился позже как вторичный сервер.
Не забыли, здесь речь о конкретном кейсе, в котором нужна бинарная совместимость. То-есть, если вам буквально нужен RHEL, но без инфраструктуры редхат, то выбор ограничен. "Забыли", в этом контексте, разве что Oracle Linux.
В остальном, каждый самостоятельный настоящий дистрибутив, в котором не просто "обои от убунты поменяли", а действительно проделали инженерную работу, интересен. В том числе и РЕД ОС.
Посмотрел, спасибо за наводку, не знал об этом проекте. Мы по сути и сделали что-то подобное сами на основе Foreman. По части того как они реализуют работу с Windows - мы тоже пришли к такому способу разворачивания через sysprep, пока тестируем его и живем на старой версии с установкой через Windows PE, попробуем взять наработки из Fog и скрестить с нашим деплоем.
Вам, в свою очередь, как "алаверды", рекомендую посмотреть в сторону Foreman, так как с точки зрения возможностей он значительно мощнее Fog, его функция не ограничена первичным развертыванием ОС, он позволяет управлять всем жизненным циклом ПО (для Linux).
Еще раз спасибо за наводку, очень ценно.
Полный цикл описать трудно, так как не ясно что взять за точку отсчета. Инфраструктура - это довольно комплексная штука и система разворачивания ОС сильно завязана на зеркала, DNS, DHCP, систему сборки и прочее. Мы периодически будем публиковать статьи по отдельным механизмам, но комплексные решения - задача ваша как архитектора и администратора, они зависят от вашей специфики. В этой статье задача была показать как можно разворачивать nix ОС, и что для этой процедуры не просто не обязательно, но даже не нужно использовать собственный инсталлятор. Тот же debian-installer - это та еще "заноза", shell или любой другой язык, используемый вашей командой, куда приятнее и мощнее его инструментария :)