Summary: | Добавить фичу для создания сервера виртуализации VirtualBox | ||||||
---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | solo <solo> | ||||
Component: | mkimage-profiles | Assignee: | Антон Мидюков <antohami> | ||||
Status: | CLOSED NOTABUG | QA Contact: | qa-sisyphus | ||||
Severity: | enhancement | ||||||
Priority: | P3 | CC: | antohami, evg, mike, shadowsbrother | ||||
Version: | unstable | Keywords: | patch | ||||
Hardware: | all | ||||||
OS: | Linux | ||||||
Bug Depends on: | |||||||
Bug Blocks: | 26300 | ||||||
Attachments: |
|
Description
solo
2015-09-25 13:39:42 MSK
(В ответ на комментарий №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... |