Предлагаю добавить в mkimage-profiles фичу use/server/vbox, предназначенную для создания серверов виртуализации VirtualBox. Суть активации фичи: 1. Должен быть установлены пакеты: 1.а) virtualbox 1.б) Серверные модули virtualbox`а 2. Среди установлеваемых пакетов не должно быть гостевых драйверов virtualbox`а -- сильно мешают тестировать полученный дистрибутив в VirtualBox`овой же виртуалке. 3. Должен быть настроен автостарт демона virtualbox. (Актуально, пока не закрыт https://bugzilla.altlinux.org/show_bug.cgi?id=29112.) Предлагаемый мной вариант находится в бранче vbox (см. http://git.altlinux.org/people/solo/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=shortlog;h=refs/heads/vbox) репозитория git://git.altlinux.org/people/solo/packages/mkimage-profiles.git (см. http://git.altlinux.org/people/solo/packages/mkimage-profiles.git). Состав коммитов: 7b2271520f6eea06c487e4bcfe59d6f1a0a2381f -- Добавлено описание группы vbox-server и соответсвующий ей список пакетов (см. http://git.altlinux.org/people/solo/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=commitdiff;h=7b2271520f6eea06c487e4bcfe59d6f1a0a2381f). 7ef669104326d86e83d26ac74ea212683098a1e3 -- в фичу server добавлена цель use/server/vbox (см. http://git.altlinux.org/people/solo/packages/mkimage-profiles.git?p=mkimage-profiles.git;a=commitdiff;h=7ef669104326d86e83d26ac74ea212683098a1e3).
(В ответ на комментарий №0) > 2. Среди установлеваемых пакетов не должно быть гостевых драйверов > virtualbox`а-- сильно мешают тестировать полученный дистрибутив > в VirtualBox`овой же виртуалке. А кто их принёс? (посмотри по build/distcfg.mk или расскажи, от какого образа отталкивался -- regular-server, так понимаю)
(В ответ на комментарий №1) > (В ответ на комментарий №0) > > 2. Среди установлеваемых пакетов не должно быть гостевых драйверов > > virtualbox`а-- сильно мешают тестировать полученный дистрибутив > > в VirtualBox`овой же виртуалке. > А кто их принёс? (посмотри по build/distcfg.mk или расскажи, от какого образа > отталкивался -- regular-server, так понимаю) Нет, у меня в основе distro/regular-xfce (даёт хорошую основу для последующего отрезания лишнего). Но в конечном итоге (когда функционал устаканится) основу придётся менять -- слишком много лишнего в дистрибутив попадает (тот же firefox, к примеру). Сейчас (в период бутстрапа) цепочка зависимостей следующая: distro/regular-xfce <- distro/.regular-desktop <- distro/.regular-wm <- distro/.regular-wm <- distro/.regular-x11 <- +vmguest.
(В ответ на комментарий №2) > Нет, у меня в основе distro/regular-xfce (даёт хорошую основу > для последующего отрезания лишнего). Вообще в m-p идеология построения, а не отчекрыживания -- сформулируй требования (нужно ли DE или предполагается исключительно удалённый/безголовый запуск?), затем найди наиболее близкий к нему образ БЕЗ необходимости что-либо из него выкидывать; если "почти такой", то можно из данной цели выделить "техническую" промежуточную (см. вывод git grep -F distro/.), подцепив к ней взятую за основу цель с тем, чтобы сама она не изменилась, и свою новую, которая при этом будет содержать всё то, что ты вынес в промежуточную, и не обязана содержать всё, что было в "почти подходящей". Разумеется, если добавка закопана глубоко в дереве наследования, так не выйдет. regular-* вообще не очень хорошая база для того, что должно расти "вбок", а не надстраиваться над ними, потому что в них включено довольно много функциональности по постановке задачи; более компактные примеры есть в conf.d/{desktop,live,server}.mk, только вот distro/.server-base включает use/cleanup/x11-alterator, а тот выносит libX* и qt4-common, среди прочего... Так что давай-ка расскажи постановку задачи по образу и сделаем как положено, на сегодняшний выпуск целиться уже не буду.
(В ответ на комментарий №3) > (В ответ на комментарий №2) > > Нет, у меня в основе distro/regular-xfce (даёт хорошую основу > > для последующего отрезания лишнего). > Вообще в m-p идеология построения, а не отчекрыживания -- сформулируй > требования (нужно ли DE или предполагается исключительно удалённый/безголовый > запуск?), затем найди наиболее близкий к нему образ БЕЗ необходимости что-либо > из него выкидывать; если "почти такой", то можно из данной цели выделить > "техническую" промежуточную (см. вывод git grep -F distro/.), подцепив к ней > взятую за основу цель с тем, чтобы сама она не изменилась, и свою новую, > которая при этом будет содержать всё то, что ты вынес в промежуточную, и не > обязана содержать всё, что было в "почти подходящей". Примерно по такому пути и собираюсь двигаться. Но этот путь потребует вдумчивого анализа каждой из подключаемых фич. На данном же этапе -- мне нужен прообраз рабочего прототипа. (К созданию оного с 0 пока неготов: в межфичном взаимодействии ещё плоховато ориентируюсь. В дальнейшем -- буду приводить его к нужному виду, методом последовательных приближений.) > > Разумеется, если добавка закопана глубоко в дереве наследования, так не выйдет. Это вижу, по структуре зависимостей между целями сборки. Но пока, без работающего прототипа, непонятно что вообще нужно, кроме основного функционала... > > Так что давай-ка расскажи постановку задачи по образу и сделаем как положено, > на сегодняшний выпуск целиться уже не буду. OK. Основная задача -- получить инсталлятор графической пускалки для VirtualBox`а (и управляющего им софта). При этом: 1. Обычные пользователи -- имеют доступ только к заданному множеству VM из под сильно кастрированного openbox`а. 2. Всем этим хозяйством управляет администратор, работающий из под Xfce. + в конечном итоге в систему не должно подать ничего лишнего. Но пока непонятно что именно считать лишним... Список лишнего будет получен в процессе исследования прототипа.
Created attachment 6387 [details] рефакторинг server.mk с добавлением distro/server-vbox Собственно, если сделать distro/server-vbox: distro/server-mini use/server/vbox; @: и собрать его -- то после завершения установки пакет virtualbox будет отсутствовать, останется только virtualbox-common; поэтому сделал по мотивам вышепредложенного proof-of-concept без X-сервера, прилагаю (он же проверен без добавленных тобой CLEANUP_PACKAGES, которые я склонен считать относящимися к конкретному образу скорее, чем к предложенной фиче -- если не сделать use/vmguest/vbox или в ручном эквиваленте, то никто выбрасываемые модули в образ и не положит).
(В ответ на комментарий №4) > Основная задача -- получить инсталлятор графической пускалки для VirtualBox`а > (и управляющего им софта). При этом: > > 1. Обычные пользователи -- имеют доступ только к заданному множеству VM из под > сильно кастрированного openbox`а. Если ничего от WM и не надо -- можно ещё посмотреть на ratpoison, см. применение в livecd-webkiosk. > 2. Всем этим хозяйством управляет администратор, работающий из под Xfce. Так это не сервер, а десктоп. Собственно, не стоит и в фичу добавлять, и даже группу разводить на ровном месте -- просто опиши образ, в который добавь virtualbox. И всё. :) > + в конечном итоге в систему не должно подать ничего лишнего. > Но пока непонятно что именно считать лишним... EFI, kernel-modules-*, спасательные пакеты/списки?.. Ещё для понимания может быть полезно внимательное изучение build/distcfg.mk. PS: возможно, Сергей решал отчасти перекликающиеся задачи, на всякий подписываю.
(В ответ на комментарий №5) > Created an attachment (id=6387) [details] > рефакторинг server.mk с добавлением distro/server-vbox > > Собственно, если сделать > > distro/server-vbox: distro/server-mini use/server/vbox; @: > > и собрать его -- то после завершения установки пакет virtualbox будет > отсутствовать, останется только virtualbox-common; поэтому сделал по мотивам > вышепредложенного proof-of-concept без X-сервера, прилагаю (он же проверен без > добавленных тобой CLEANUP_PACKAGES, которые я склонен считать относящимися к > конкретному образу скорее, чем к предложенной фиче -- если не сделать > use/vmguest/vbox или в ручном эквиваленте, то никто выбрасываемые модули в > образ и не положит). Такое решение выглядит достаточно красивым. CLEANUP_PACKAGES позволяет быстро приложить фичу к любому десктопному distro/* и оценить полученный результат. Что, на мой взгляд -- заметно экономит время создания начального варианта прототипа.
(В ответ на комментарий №6) > (В ответ на комментарий №4) > > Основная задача -- получить инсталлятор графической пускалки для VirtualBox`а > > (и управляющего им софта). При этом: > > > > 1. Обычные пользователи -- имеют доступ только к заданному множеству VM из под > > сильно кастрированного openbox`а. > Если ничего от WM и не надо -- можно ещё посмотреть на ratpoison, см. > применение в livecd-webkiosk. Нужна корректная работа мультимониторной конфигурации. (Есть подводные камни, как оказалось.) > > > 2. Всем этим хозяйством управляет администратор, работающий из под Xfce. > Так это не сервер, а десктоп. Собственно, не стоит и в фичу добавлять, и даже > группу разводить на ровном месте -- просто опиши образ, в который добавь > virtualbox. И всё. :) Данную фичу завёл, т. к. решил что у меня получился вполне законченный блок, который может пригодиться кому нибудь ещё. :-) (Для моих цели её мало, но там слишком много частностей появляется.) > > > + в конечном итоге в систему не должно подать ничего лишнего. > > Но пока непонятно что именно считать лишним... > EFI, kernel-modules-*, спасательные пакеты/списки?.. Ага. + всякая мультимедиа.
(В ответ на комментарий №6) > PS: возможно, Сергей решал отчасти перекликающиеся задачи, на всякий > подписываю. Если бы решал, то решение уже бы было. Но впопыхах чёткого ТЗ не было, поэтому держал в уме несколько вариантов. В итоге от этого варианта полностью отказались (точнее, дальше наброска дело не пошло, хотя сам набросок вполне себе работал). PS Да, там было отличие от предлагаемого здесь варианта: в iso включался заранее подготовленный образ системы, который требовалось запускать в headless режиме при запуске развернутого на машине iso-шника.
(В ответ на комментарий №7) > CLEANUP_PACKAGES позволяет быстро приложить фичу к любому десктопному distro/* > и оценить полученный результат. Что, на мой взгляд -- заметно экономит время > создания начального варианта прототипа. Ну это всё-таки для оценки, а не для мержа, согласись. :) У меня тоже куча мелких веточек с кучками временных коммитов, некоторые из которых дозревают до cherry-pick или merge... (В ответ на комментарий №8) > Нужна корректная работа мультимониторной конфигурации. > (Есть подводные камни, как оказалось.) В своё время сталкивался с некоторыми, но это уже не про m-p, почтой пиши. > > > Но пока непонятно что именно считать лишним... > > EFI, kernel-modules-*, спасательные пакеты/списки?.. > Ага. + всякая мультимедиа. Если у тебя есть жёсткое ТЗ, то может быть лучше отталкиваться от совсем базовых целей вроде distro/.installer и формировать по списку -- см. тот же regular-jeos (там CLEANUP_PACKAGES обусловлены неоптимальностями пакетной базы и отсутствием возможности пометить и удалить начисто пакеты, временно установленные для работы инсталятора). В m-p изначально заложено много точек выбора между уже готовым, но неконтролируемым заимствуемым и тем, что описываешь врукопашную, зато и гарантируешь... См. тж.: https://www.altlinux.org/Mkimage/Profiles/m-p/howto https://www.altlinux.org/Mkimage/Profiles/m-p/objects 2 sb: понял, спасибо.
(В ответ на комментарий №10) > (В ответ на комментарий №7) > > CLEANUP_PACKAGES позволяет быстро приложить фичу к любому десктопному distro/* > > и оценить полученный результат. Что, на мой взгляд -- заметно экономит время > > создания начального варианта прототипа. > Ну это всё-таки для оценки, а не для мержа, согласись. :) Не, не соглашусь. :-) Основное назначение данной фичи -- гарантированое исключение ситуации, когда гостевой и серверный драйвера имеют возможность загрузится одновременно, т. к. при этом в виртуалке ломаются X`ы. (У нас не тестировал, но на Fedora такой слом был стабильным, см. https://bugzilla.rpmfusion.org/show_bug.cgi?id=3425.) Так что, для меня ценность данной фичи очевидна. Но настаивать что оно важно всем (и потому обязательно должно быть в в пакете) -- не буду. :-) > > В m-p изначально заложено много точек выбора между уже готовым, но > неконтролируемым заимствуемым и тем, что описываешь врукопашную, зато и > гарантируешь... И в этом плане он сильно удобней Fedora`овской anaconda...
