[devel] Минимальный VE огромен -- много мусора

[devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1956 bytes --]

Сегодня пытался сделать минимальный VE. Минимальный это значит состоящий
только из пакета basesystem и его зависимостей + apt.

Результат следующий:

basesystem
==========

требует:
e2fsprogs
losetup
perl-base

первые два пакета не имеют смысла для VE вообще, а perl любым пакетом
которому он требуется и так прекрасно вытягивается по зависимостям.

startup
=======
hwclock, module_init_tools -- невозможно использовать в VE
mount -- мало того что невозможно использовать в VE, так он еще тянет за
собой nfs-utils и portmap.
msulogin -- single user mode в VE -- это оригинально, очень оригинально :)

util-linux
==========

тянет за собой udev-rules из-за единственного файлика, который к тому же
по сути является документацией а не реально работающим файлом. Может его
вынести в %doc просто чтобы не плодить ненужную зависимость?

glibc-utils
===========

В этом пакете есть утилита mtrace. Подозреваю что она не относиться к
особо часто используемым. При этом в отличии от всех остальных утилит в
этом пакете она единственная написана на perl. 

Таким образом установка пакета glibc автоматически устанавливает еще и
perl -- он, конечно, хороший язык программирования но не _настолько_
базовый, мне кажется.

Возможно ли отпилить mtrace  в отдельный пакет?

Для решения проблемы с basesystem я могу создать какой-нибудь
basesystem-ve, но как сделать чтобы он provide'ил basesystem, но при этом
ставился только в VE, и не мог оказаться у нормального пользователя?
Поставить в нем conflicts на kernel?

Как решать проблему с startup я не знаю. По-хорошему стоило бы отпилить
части пригодные только для физических машин, но это задача не на 5 минут.

Насколько я вижу самое полезное среди всего этого -- отпилить perl-base от
glibc и сделать отдельный basesystem для VE.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Sun, Oct 04, 2009 at 03:50:00AM +0400, Денис Смирнов wrote:
> Сегодня пытался сделать минимальный VE. Минимальный это значит
> состоящий только из пакета basesystem и его зависимостей + apt.
> Результат следующий:

Развесишь или помочь?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 832 bytes --]

On Sun, Oct 04, 2009 at 10:49:46PM +0300, Michael Shigorin wrote:
>> Сегодня пытался сделать минимальный VE. Минимальный это значит
>> состоящий только из пакета basesystem и его зависимостей + apt.
>> Результат следующий:
MS> Развесишь или помочь?

Я надеялся на ответ ldv@ здесь, если честно.

По создание basesystem-ve -- я и сам сделаю, если мне объяснят как сделать
чтобы он не мешал нормальным пользователям.

Вторая критичная грабля -- это зависимость glibc на perl-base, ее
без решения ldv@ не пофиксить. Если таковое бует, могу для экономии
времени Димы сам отпилить подпакет.

С startup -- видимо лучше развесить, причем несколькими багами, буду
счастлив если поможешь :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Led]

On Monday, 05 October 2009 02:39:27 Денис Смирнов wrote:
> On Sun, Oct 04, 2009 at 10:49:46PM +0300, Michael Shigorin wrote:
> >> Сегодня пытался сделать минимальный VE. Минимальный это значит
> >> состоящий только из пакета basesystem и его зависимостей + apt.
> >> Результат следующий:
>
> MS> Развесишь или помочь?
>
> Я надеялся на ответ ldv@ здесь, если честно.
>
> По создание basesystem-ve -- я и сам сделаю, если мне объяснят как сделать
> чтобы он не мешал нормальным пользователям.
>
> Вторая критичная грабля -- это зависимость glibc на perl-base, ее
> без решения ldv@ не пофиксить. Если таковое бует, могу для экономии
> времени Димы сам отпилить подпакет.
>
> С startup -- видимо лучше развесить, причем несколькими багами, буду
> счастлив если поможешь :)

Неплохо бы озвучить проблемы в startup (если таковые существуют) и 
предполагамые решения.

-- 
Led

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

On Mon, Oct 05, 2009 at 02:50:44AM +0300, Led wrote:

L> Неплохо бы озвучить проблемы в startup (если таковые существуют) и 
L> предполагамые решения.

В начале треда было :) Лишнии зависимости:

1. на module_init_tools
2. на mount (это очень плохо, потому что за mount
тянутся nfs_utils и portmap)
3. на msulogin

Все это можно полечить только отрезанием всего что использует эти пакеты в
отдельные скрипты, которые будут лежать в отдельном пакете. Увы, это
работа не на 5 минут.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 978 bytes --]

On Sun, Oct 04, 2009 at 03:50:00AM +0400, Денис Смирнов wrote:
> Сегодня пытался сделать минимальный VE. Минимальный это значит состоящий
> только из пакета basesystem и его зависимостей + apt.

Сколько ты хочешь сэкономить?

[at@people ~]$ hsh --init --pkg-build-list=basesystem
<13>Oct  5 04:03:08 rpmi: setup-2.2.12-alt1 installed
...
[at@people ~]$ du -hs $TMPDIR/build/cache/chroot/chroot.cpio.lzo
25M     /tmp/.private/at/build/cache/chroot/chroot.cpio.lzo
[at@people ~]$ hsh-run -- rpm -qa --qf '%{NAME}\t%{SIZE}\n' |sort -k2n |tail
pam     1143641
bash    1144100
libdb4.7        1366662
gawk    1499779
e2fsprogs       1786817
tar     2028610
glibc-core      3189475
perl-base       4206434
util-linux      4780199
coreutils       10922123
[at@people ~]$ 

Отсюда видно что самый большой пакет это coreutils.  Потому что в нём
имеется огроменный перевод с человеческого языка на вернакуляр.

perl-base без боя не отдам, остальное мелочевка.

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

On Mon, Oct 05, 2009 at 08:11:12AM +0400, Алексей Турбин wrote:
>> Сегодня пытался сделать минимальный VE. Минимальный это значит состоящий
>> только из пакета basesystem и его зависимостей + apt.
AT> Сколько ты хочешь сэкономить?
AT> Отсюда видно что самый большой пакет это coreutils.  Потому что в нём
AT> имеется огроменный перевод с человеческого языка на вернакуляр.

coreutils следующий будет в очереди на обдумывание :)

AT> perl-base без боя не отдам, остальное мелочевка.

Мне не нужно удалять perl-base из базовых пакетов при сборке. Мне нужно
чтобы perl-base не был обязательным для любого VE, как сейчас. Для этого
достаточно отпилить mtrace от glibc.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Stanislav Ievlev]

Кстати hasher и некоторые другие пакеты используют вбитый гвоздями
минимальный набор пакетов меньше чем basesystem.
Возможно стоит этот список вынести наружу в виде виртуального пакета.

4 октября 2009 г. 3:50 пользователь Денис Смирнов
<mithraen@altlinux.ru> написал:
> Сегодня пытался сделать минимальный VE. Минимальный это значит состоящий
> только из пакета basesystem и его зависимостей + apt.
>
> Результат следующий:
>
> basesystem
> ==========
>
> требует:
> e2fsprogs
> losetup
> perl-base
>
> первые два пакета не имеют смысла для VE вообще, а perl любым пакетом
> которому он требуется и так прекрасно вытягивается по зависимостям.
>
> startup
> =======
> hwclock, module_init_tools -- невозможно использовать в VE
> mount -- мало того что невозможно использовать в VE, так он еще тянет за
> собой nfs-utils и portmap.
> msulogin -- single user mode в VE -- это оригинально, очень оригинально :)
>
> util-linux
> ==========
>
> тянет за собой udev-rules из-за единственного файлика, который к тому же
> по сути является документацией а не реально работающим файлом. Может его
> вынести в %doc просто чтобы не плодить ненужную зависимость?
>
> glibc-utils
> ===========
>
> В этом пакете есть утилита mtrace. Подозреваю что она не относиться к
> особо часто используемым. При этом в отличии от всех остальных утилит в
> этом пакете она единственная написана на perl.
>
> Таким образом установка пакета glibc автоматически устанавливает еще и
> perl -- он, конечно, хороший язык программирования но не _настолько_
> базовый, мне кажется.
>
> Возможно ли отпилить mtrace  в отдельный пакет?
>
> Для решения проблемы с basesystem я могу создать какой-нибудь
> basesystem-ve, но как сделать чтобы он provide'ил basesystem, но при этом
> ставился только в VE, и не мог оказаться у нормального пользователя?
> Поставить в нем conflicts на kernel?
>
> Как решать проблему с startup я не знаю. По-хорошему стоило бы отпилить
> части пригодные только для физических машин, но это задача не на 5 минут.
>
> Насколько я вижу самое полезное среди всего этого -- отпилить perl-base от
> glibc и сделать отдельный basesystem для VE.
>
> --
> С уважением, Денис
>
> http://freesource.info
> ----------------------------------------------------------------------------
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAkrH4ygACgkQPuR8c4jhFKJHjACcDX7QVegOL8YKFLjV3Mlo8v7M
> sC0AmgNmJPzKHMk6y7y9HKfdHXbJE/Ez
> =tMAJ
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

On Mon, Oct 05, 2009 at 10:57:48AM +0400, Stanislav Ievlev wrote:

SI> Кстати hasher и некоторые другие пакеты используют вбитый гвоздями
SI> минимальный набор пакетов меньше чем basesystem.
SI> Возможно стоит этот список вынести наружу в виде виртуального пакета.

Я могу сделать пакет basesystem-ve, который будет отличаться от basesystem
отсутствием зависимости на ненужные в VE пакеты.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Mon, Oct 05, 2009 at 10:57:48AM +0400, Stanislav Ievlev wrote:

SI> Кстати hasher и некоторые другие пакеты используют вбитый гвоздями
SI> минимальный набор пакетов меньше чем basesystem.
SI> Возможно стоит этот список вынести наружу в виде виртуального пакета.

task 13769 -- там уже есть basesystem-ve и interactivesystem-ve

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Sun, Oct 04, 2009 at 03:50:00AM +0400, Денис Смирнов wrote:
> Сегодня пытался сделать минимальный VE. Минимальный это значит
> состоящий только из пакета basesystem и его зависимостей + apt.

Есть некоторый интерес всё-таки это сделать, чтобы к следующему
бранчу не спохватываться (он ведь когда-то будет).

http://lists.altlinux.org/pipermail/devel/2009-October/175682.html

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

On Wed, Apr 23, 2014 at 08:13:25PM +0300, Michael Shigorin wrote:

>> Сегодня пытался сделать минимальный VE. Минимальный это значит
>> состоящий только из пакета basesystem и его зависимостей + apt.
> Есть некоторый интерес всё-таки это сделать, чтобы к следующему
> бранчу не спохватываться (он ведь когда-то будет).
> http://lists.altlinux.org/pipermail/devel/2009-October/175682.html

Чем я могу в этом помочь?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Thu, Apr 24, 2014 at 10:55:02PM +0400, Денис Смирнов wrote:
> >> Сегодня пытался сделать минимальный VE. Минимальный это значит
> >> состоящий только из пакета basesystem и его зависимостей + apt.
> > Есть некоторый интерес всё-таки это сделать, чтобы к следующему
> > бранчу не спохватываться (он ведь когда-то будет).
> > http://lists.altlinux.org/pipermail/devel/2009-October/175682.html
> Чем я могу в этом помочь?

Если хочешь, перечитай и перепроверь свои тогдашние выводы
применительно к ситуации сегодня; если некогда, не морочь
себе голову, тогда было изложено достаточно хорошо.

Как вариант -- проверь в режиме test-only NMU.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 599 bytes --]

On Thu, Apr 24, 2014 at 11:01:36PM +0300, Michael Shigorin wrote:

>>> http://lists.altlinux.org/pipermail/devel/2009-October/175682.html
>> Чем я могу в этом помочь?
> Если хочешь, перечитай и перепроверь свои тогдашние выводы
> применительно к ситуации сегодня; если некогда, не морочь
> себе голову, тогда было изложено достаточно хорошо.
> Как вариант -- проверь в режиме test-only NMU.

Проверил. Актуально:

- basesystem требует perl-base
- startup требует hwclock, mount, msulogin

А mount в свою очередь тащит еще и nfs-utils

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 458 bytes --]

On Thu, Apr 24, 2014 at 11:01:36PM +0300, Michael Shigorin wrote:

> Если хочешь, перечитай и перепроверь свои тогдашние выводы
> применительно к ситуации сегодня; если некогда, не морочь
> себе голову, тогда было изложено достаточно хорошо.
> Как вариант -- проверь в режиме test-only NMU.

Да, и mtrace от glibc-utils все же хорошо бы отпилить -- тогда perl не
будет необходимой частью любого VE.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Farygin]

On 27.04.2014 02:41, Денис Смирнов wrote:
> On Thu, Apr 24, 2014 at 11:01:36PM +0300, Michael Shigorin wrote:
>
>> Если хочешь, перечитай и перепроверь свои тогдашние выводы
>> применительно к ситуации сегодня; если некогда, не морочь
>> себе голову, тогда было изложено достаточно хорошо.
>> Как вариант -- проверь в режиме test-only NMU.
>
> Да, и mtrace от glibc-utils все же хорошо бы отпилить -- тогда perl не
> будет необходимой частью любого VE.

Ладно perl. от графических библиотек бы избавиться на серверной системе.

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 326 bytes --]

On Sun, Apr 27, 2014 at 09:18:41AM +0400, Anton Farygin wrote:

>> Да, и mtrace от glibc-utils все же хорошо бы отпилить -- тогда perl не
>> будет необходимой частью любого VE.
> Ладно perl. от графических библиотек бы избавиться на серверной системе.

А кто их тащит?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Gorlov]

27.04.2014 11:34, Денис Смирнов пишет:
>>> Да, и mtrace от glibc-utils все же хорошо бы отпилить -- тогда perl не
>>> >>будет необходимой частью любого VE.
>> >Ладно perl. от графических библиотек бы избавиться на серверной системе.
> А кто их тащит?
полагаю больше всего всякие libgd и те кто с ними линкуется.. особенно 
php-gd

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 494 bytes --]

On Sun, Apr 27, 2014 at 11:47:29AM +0400, Anton Gorlov wrote:

> полагаю больше всего всякие libgd и те кто с ними линкуется.. особенно 
> php-gd

Ну, то что php5-gd2 хочет для себя libjpeg, libpng, libt1 и libfreetype
попросту необходимо для выполнения им своей работы. И там где стоит php,
экономия единиц мегабайт на выгрызании лишнего уже не так существенно.

Кстати, php5-gd2 не зависит от libgd2 (видать статически слинкован?).

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Gorlov]

27.04.2014 13:33, Денис Смирнов пишет:
> Ну, то что php5-gd2 хочет для себя libjpeg, libpng, libt1 и libfreetype
> попросту необходимо для выполнения им своей работы. И там где стоит php,
> экономия единиц мегабайт на выгрызании лишнего уже не так существенно.
>
> Кстати, php5-gd2 не зависит от libgd2 (видать статически слинкован?).

Да это понятно. А всякие libjpeg засобой тянут кучку иксовых либ..

Да gd2 у нас кажется слинкован статически.. Хм.. не уверен что это хорошо..

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 987 bytes --]

On Sun, Apr 27, 2014 at 01:42:10PM +0400, Anton Gorlov wrote:

>> Кстати, php5-gd2 не зависит от libgd2 (видать статически слинкован?).
> Да это понятно. А всякие libjpeg засобой тянут кучку иксовых либ..

$ rpm -q --requires libjpeg
libc.so.6(GLIBC_2.14)(64bit)  
libc.so.6(GLIBC_2.2.5)(64bit)  
libc.so.6(GLIBC_2.3.4)(64bit)  
libc.so.6(GLIBC_2.4)(64bit)  
libc.so.6(GLIBC_2.7)(64bit)  
rtld(GNU_HASH)  
rpmlib(PayloadIsLzma)  

Не вижу тут иксовых либ.

Вот libgd2 действительно тянет libXpm, который уже тянет libX11 и так далее.

> Да gd2 у нас кажется слинкован статически.. Хм.. не уверен что это хорошо..

Если на то нет веских причин - это ошибка упаковки. Там по-хорошему надо
добавить еще buildrequires на libvpx-devel, libXpm-devel и libgd2-devel.

А лоакальную копию libgd2 прибить прямо в php5-devel. Там, вероятно,
наверняка и другие примеры подобной ошибки есть из-за локальных копий
библиотек.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Gorlov]

Попробовал оторвать и наткнулся на https://bugs.php.net/bug.php?id=64281

30.04.2014 23:04, Anton Gorlov пишет:
> Кстати насчёт php-gd и gdlib нашёл  не7могоччтива на ночь
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321237
> Оно конечно откопано с руин  времени существования мамонтов, но тем не 
> менее php с dotdeb так же собран с bundled  libgd

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]

On Wed, Apr 30, 2014 at 11:23:13PM +0400, Anton Gorlov wrote:
> Попробовал оторвать и наткнулся на https://bugs.php.net/bug.php?id=64281

Забей. Геморрой не стоит ожидаемого выхлопа, сейчас PHP собран достаточно
хорошо, чтобы быть юзабельным. А собрать его совсем хорошо без
переписывания from scratch невозможно.

Лучший фикс PHP -- это Perl :)

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Gorlov]

я щас руби изучаю :)
Ну я так чисто ради интереса попробовал. А вообще да улыбнуло что у них 
считай свой форк с поэтессами libgd..

01.05.2014 00:45, Денис Смирнов пишет:
> n Wed, Apr 30, 2014 at 11:23:13PM +0400, Anton Gorlov wrote:
>> >Попробовал оторвать и наткнулся наhttps://bugs.php.net/bug.php?id=64281
> Забей. Геморрой не стоит ожидаемого выхлопа, сейчас PHP собран достаточно
> хорошо, чтобы быть юзабельным. А собрать его совсем хорошо без
> переписывания from scratch невозможно.
>
> Лучший фикс PHP -- это Perl:)

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Farygin]

On 27.04.2014 11:34, Денис Смирнов wrote:
> On Sun, Apr 27, 2014 at 09:18:41AM +0400, Anton Farygin wrote:
>
>>> Да, и mtrace от glibc-utils все же хорошо бы отпилить -- тогда perl не
>>> будет необходимой частью любого VE.
>> Ладно perl. от графических библиотек бы избавиться на серверной системе.
>
> А кто их тащит?
glib-networking, libgio, libsoup

а вот кто уже их тащит - надо разбираться.

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 260 bytes --]

On Sun, Apr 27, 2014 at 03:38:07PM +0400, Anton Farygin wrote:

>> А кто их тащит?
> glib-networking, libgio, libsoup
> а вот кто уже их тащит - надо разбираться.

rpm -q --whatrequires libgio

и т.д.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Farygin]

On 28.04.2014 02:55, Денис Смирнов wrote:
> On Sun, Apr 27, 2014 at 03:38:07PM +0400, Anton Farygin wrote:
>
>>> А кто их тащит?
>> glib-networking, libgio, libsoup
>> а вот кто уже их тащит - надо разбираться.
>
> rpm -q --whatrequires libgio
>
> и т.д.

Знаю, я собственно так до glib-networking дошёл.

Есть способ проще - ставишь систему в виртуалку, а потом начинаешь rpm 
-e делать

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Mon, Apr 28, 2014 at 09:57:35AM +0400, Anton Farygin wrote:

> Знаю, я собственно так до glib-networking дошёл.
> Есть способ проще - ставишь систему в виртуалку, а потом начинаешь rpm 
> -e делать

Ага, так часто и делаю.

Собственно возвращаясь к теме -- что-нибудь с перловкой в basesystem
делать будем, или где?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

On Mon, Apr 28, 2014 at 10:24:13PM +0400, Денис Смирнов wrote:
> Собственно возвращаясь к теме -- что-нибудь с перловкой в basesystem
> делать будем, или где?

Перловку из basesystem можно убрать.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Mon, Apr 28, 2014 at 10:56:05PM +0400, Dmitry V. Levin wrote:
> > Собственно возвращаясь к теме -- что-нибудь с перловкой
> > в basesystem делать будем, или где?
> Перловку из basesystem можно убрать.

Готов проверять, а то у меня сейчас мелкий образ на лицо ужасен:
http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles.git;a=blob;f=conf.d/regular.mk;h=15b4c36170edbf1e45123cf388acd4fb35e0b518;hb=HEAD#l46

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

On Mon, Apr 28, 2014 at 10:56:05PM +0400, Dmitry V. Levin wrote:

>> Собственно возвращаясь к теме -- что-нибудь с перловкой в basesystem
>> делать будем, или где?
> Перловку из basesystem можно убрать.

А mtrace от glibc-utils положить в отдельный подпакет?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

On Mon, Apr 28, 2014 at 11:30:01PM +0400, Денис Смирнов wrote:
> On Mon, Apr 28, 2014 at 10:56:05PM +0400, Dmitry V. Levin wrote:
> 
> >> Собственно возвращаясь к теме -- что-нибудь с перловкой в basesystem
> >> делать будем, или где?
> > Перловку из basesystem можно убрать.
> 
> А mtrace от glibc-utils положить в отдельный подпакет?

Отдельный пакет ради небольшого скрипта?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Mon, Apr 28, 2014 at 11:42:07PM +0400, Dmitry V. Levin wrote:
> > > Перловку из basesystem можно убрать.
> > А mtrace от glibc-utils положить в отдельный подпакет?
> Отдельный пакет ради небольшого скрипта?

Ради небольшого perl-base, или есть варианты?

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Минимальный VE огромен -- много мусора

[Led]

On Monday 28 April 2014 23:35:23 Michael Shigorin wrote:
> On Mon, Apr 28, 2014 at 11:42:07PM +0400, Dmitry V. Levin wrote:
> > > > Перловку из basesystem можно убрать.
> > >
> > > А mtrace от glibc-utils положить в отдельный подпакет?
> >
> > Отдельный пакет ради небольшого скрипта?
>
> Ради небольшого perl-base, или есть варианты?

Действительно системные утилиты - положить в glibc, а в glibc-utils оставить всё остальное.

-- 
Led

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

On Mon, Apr 28, 2014 at 11:50:18PM +0300, Led wrote:

>> Ради небольшого perl-base, или есть варианты?
> Действительно системные утилиты - положить в glibc, а в glibc-utils оставить всё остальное.

Будет очередной геморрой при обновлении. Сам-то пакет маленький и
незаметный, и если бы не зависимость одной единственной утилиты от
перловки -- вопросов бы к нему не было.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Led]

On Monday 28 April 2014 23:57:06 Денис Смирнов wrote:
> On Mon, Apr 28, 2014 at 11:50:18PM +0300, Led wrote:
> >> Ради небольшого perl-base, или есть варианты?
> >
> > Действительно системные утилиты - положить в glibc, а в glibc-utils
> > оставить всё остальное.
>
> Будет очередной геморрой при обновлении.

Не будет.

-- 
Led

Re: [devel] Минимальный VE огромен -- много мусора

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Tue, Apr 29, 2014 at 12:10:23AM +0300, Led wrote:
> On Monday 28 April 2014 23:57:06 Денис Смирнов wrote:
> > On Mon, Apr 28, 2014 at 11:50:18PM +0300, Led wrote:
> > >> Ради небольшого perl-base, или есть варианты?
> > >
> > > Действительно системные утилиты - положить в glibc, а в glibc-utils
> > > оставить всё остальное.
> >
> > Будет очередной геморрой при обновлении.
> 
> Не будет.

glibc - это сейчас виртуальный пакет, зависящий в т.ч. и от glibc-utils.
Если переносить из glibc-utils в glibc, то возникнут проблемы.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Led]

On Tuesday 29 April 2014 00:17:16 Dmitry V. Levin wrote:
> On Tue, Apr 29, 2014 at 12:10:23AM +0300, Led wrote:
> > On Monday 28 April 2014 23:57:06 Денис Смирнов wrote:
> > > On Mon, Apr 28, 2014 at 11:50:18PM +0300, Led wrote:
> > > >> Ради небольшого perl-base, или есть варианты?
> > > >
> > > > Действительно системные утилиты - положить в glibc, а в glibc-utils
> > > > оставить всё остальное.
> > >
> > > Будет очередной геморрой при обновлении.
> >
> > Не будет.
>
> glibc - это сейчас виртуальный пакет, зависящий в т.ч. и от glibc-utils.
> Если переносить из glibc-utils в glibc, то возникнут проблемы.

Скажем так, опытным путём проверено, что объединение содержимого glibc-core и glibc-utils в пакет glibc (с уничтожением 
первых двух) к проблемам не приводит. Естественно, нужно правильно необходимые Provides расставить.

-- 
Led

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 597 bytes --]

On Tue, Apr 29, 2014 at 12:32:21AM +0300, Led wrote:

>> glibc - это сейчас виртуальный пакет, зависящий в т.ч. и от glibc-utils.
>> Если переносить из glibc-utils в glibc, то возникнут проблемы.
> Скажем так, опытным путём проверено, что объединение содержимого glibc-core и glibc-utils в пакет glibc (с уничтожением 
> первых двух) к проблемам не приводит. Естественно, нужно правильно необходимые Provides расставить.

Это параллельная задача. Ценности отпиливания mtrace в отдельный пакет,
для избавления от перловки это не отменяет.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Led]

On Tuesday 29 April 2014 02:23:47 Денис Смирнов wrote:
> On Tue, Apr 29, 2014 at 12:32:21AM +0300, Led wrote:
> >> glibc - это сейчас виртуальный пакет, зависящий в т.ч. и от glibc-utils.
> >> Если переносить из glibc-utils в glibc, то возникнут проблемы.
> >
> > Скажем так, опытным путём проверено, что объединение содержимого
> > glibc-core и glibc-utils в пакет glibc (с уничтожением первых двух) к
> > проблемам не приводит. Естественно, нужно правильно необходимые Provides
> > расставить.
>
> Это параллельная задача. Ценности отпиливания mtrace в отдельный пакет,
> для избавления от перловки это не отменяет.

Это не задача. Это то, что реально проверено.

-- 
Led

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1826 bytes --]

On Tue, Apr 29, 2014 at 02:39:11AM +0300, Led wrote:

>> Это параллельная задача. Ценности отпиливания mtrace в отдельный пакет,
>> для избавления от перловки это не отменяет.
> Это не задача. Это то, что реально проверено.

И ты предлагаешь это изменение ради какой-то задачи, которая похоже
отличается от моей, и потому я прошу её озвучить -- чтобы все понимали что
и зачем делаем.

Сейчас ситуация такая -- пакет с именем 'glibc' имеет непрямую зависимость
на 'perl-base', что с любой точки зрения является некорректным как чисто
технически (кольцевая зависимость), с точки зрения безопасности и качества 
(любая лишняя зависимость на объемное приложение -- зло).

Предложенное тобой изменение оставит mtrace в пакете glibc-utils, что хоть
и решит проблему частично, но оставит неочевидную зависимость.

Цель предложенного мной изменения -- минимизация зависимостей и отделение
имеющих существенные зависимости приложений в отдельные подпакеты, ради
возможности проще создавать компактные минималистичные VE, что является
существенным в связи с тенденцией использовать подход 'одно приложение --
одно VE'

Единственным препятствием для отделение mtrace в отдельный подпакет
является тот факт, что отдельный пакет для маленького скриптика это
overhead.

Я уверен, что возможность легче создавать минималистичные VE, вместе с
отсутствием неочевидной зависимости от пакетов с именем 'glibc*' от
перловки стоит того, чтобы потратить на это несколько килобайт метаданных
в репоизтории.

Поэтому вне зависимости от решения по переносу бинарников между glibc и
glibc-utils, отпилить конкретно mtrace в отдельный пакет с именем, не
содержащим префикс 'glibc' считаю необходимым, или как минимум лучшим чем
любое другое известное мне решение.

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Tue, Apr 29, 2014 at 05:40:44PM +0400, Денис Смирнов wrote:
> Поэтому вне зависимости от решения по переносу бинарников между
> glibc и glibc-utils, отпилить конкретно mtrace в отдельный
> пакет с именем, не содержащим префикс 'glibc' считаю
> необходимым, или как минимум лучшим чем любое другое
> известное мне решение.

Да собственно, в пакет mtrace.
Ну или %add_findreq_skiplist %_bindir/mtrace

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Tue, Apr 29, 2014 at 06:46:44PM +0300, Michael Shigorin wrote:

>> Поэтому вне зависимости от решения по переносу бинарников между
>> glibc и glibc-utils, отпилить конкретно mtrace в отдельный
>> пакет с именем, не содержащим префикс 'glibc' считаю
>> необходимым, или как минимум лучшим чем любое другое
>> известное мне решение.
> Да собственно, в пакет mtrace.
> Ну или %add_findreq_skiplist %_bindir/mtrace

Лично меня устроят оба варианта, хотя первый и корректнее.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Led]

On Tuesday 29 April 2014 16:40:44 Денис Смирнов wrote:
> On Tue, Apr 29, 2014 at 02:39:11AM +0300, Led wrote:
> >> Это параллельная задача. Ценности отпиливания mtrace в отдельный пакет,
> >> для избавления от перловки это не отменяет.
> >
> > Это не задача. Это то, что реально проверено.
>
> И ты предлагаешь это изменение ради какой-то задачи, которая похоже
> отличается от моей, и потому я прошу её озвучить -- чтобы все понимали что
> и зачем делаем.

Я всего лишь привёл пример подобного опыта.

>
> Сейчас ситуация такая -- пакет с именем 'glibc' имеет непрямую зависимость
> на 'perl-base', что с любой точки зрения является некорректным как чисто
> технически (кольцевая зависимость),

И где там "кольцевая зависимость"?

> с точки зрения безопасности и качества 
> (любая лишняя зависимость на объемное приложение -- зло).

Не спорю.

>
> Предложенное тобой изменение оставит mtrace в пакете glibc-utils, что хоть
> и решит проблему частично, но оставит неочевидную зависимость.

Какую?

>
> Цель предложенного мной изменения -- минимизация зависимостей и отделение
> имеющих существенные зависимости приложений в отдельные подпакеты, ради
> возможности проще создавать компактные минималистичные VE, что является
> существенным в связи с тенденцией использовать подход 'одно приложение --
> одно VE'
>
> Единственным препятствием для отделение mtrace в отдельный подпакет
> является тот факт, что отдельный пакет для маленького скриптика это
> overhead.
>
> Я уверен, что возможность легче создавать минималистичные VE, вместе с
> отсутствием неочевидной зависимости от пакетов с именем 'glibc*' от
> перловки стоит того, чтобы потратить на это несколько килобайт метаданных
> в репоизтории.
>
> Поэтому вне зависимости от решения по переносу бинарников между glibc и
> glibc-utils, отпилить конкретно mtrace в отдельный пакет с именем, не
> содержащим префикс 'glibc' считаю необходимым, или как минимум лучшим чем
> любое другое известное мне решение.

В glibc-utils находятся как утилиты, которые ИМХО должны быть в любой (даже 
самой минимальной) системе (getconf, getent, ldd), так и утилиты, 
которые "возможно, когда-нибудь, кому-нибудь, в каких-то случаях могут 
понадобиться" (среди них и mtrace). Зачем вводить новые субпакеты, когда 
можно первые внести в glibc, туда же положить сиротливый iconv и утилиты из 
glibc-timezones, и оторвать в glibc зависимости на glibc-tools, iconv, 
glibc-locales, glibc-timezones.

-- 
Led

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Tue, Apr 29, 2014 at 07:17:06PM +0300, Led wrote:

>> Сейчас ситуация такая -- пакет с именем 'glibc' имеет непрямую зависимость
>> на 'perl-base', что с любой точки зрения является некорректным как чисто
>> технически (кольцевая зависимость),
> И где там "кольцевая зависимость"?

Сорри, ошибся.

>> Предложенное тобой изменение оставит mtrace в пакете glibc-utils, что хоть
>> и решит проблему частично, но оставит неочевидную зависимость.
> Какую?

Пакет с именем ^glibc-.* зависящий от перловки -- это неочевидно. С
технической точки зрения корректно, но с админской -- нет.

> В glibc-utils находятся как утилиты, которые ИМХО должны быть в любой (даже 
> самой минимальной) системе (getconf, getent, ldd), так и утилиты, 
> которые "возможно, когда-нибудь, кому-нибудь, в каких-то случаях могут 
> понадобиться" (среди них и mtrace).

Согласен.

> Зачем вводить новые субпакеты, когда 
> можно первые внести в glibc, туда же положить сиротливый iconv и утилиты из 
> glibc-timezones,

А нафига в каждой системе эти утилиты? Ни разу в жизни не одну из них не
запускал, а полезность tzselect вообще в современной системе неочевидна.
Её точно не нужно оторвать нафиг?

> и оторвать в glibc зависимости на glibc-tools, iconv, 
> glibc-locales, glibc-timezones.

$ du -hs /usr/lib64/gconv
6,4M	/usr/lib64/gconv

это все действительно нужно в каждой минимальной системе?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Farygin]

On 29.04.2014 20:57, Денис Смирнов wrote:
> On Tue, Apr 29, 2014 at 07:17:06PM +0300, Led wrote:
>
>>> Сейчас ситуация такая -- пакет с именем 'glibc' имеет непрямую зависимость
>>> на 'perl-base', что с любой точки зрения является некорректным как чисто
>>> технически (кольцевая зависимость),
>> И где там "кольцевая зависимость"?
>
> Сорри, ошибся.
>
>>> Предложенное тобой изменение оставит mtrace в пакете glibc-utils, что хоть
>>> и решит проблему частично, но оставит неочевидную зависимость.
>> Какую?
>
> Пакет с именем ^glibc-.* зависящий от перловки -- это неочевидно. С
> технической точки зрения корректно, но с админской -- нет.

А чем тебе perl на сервере не угодил ? маленький и позволяет делать 
много всего делать.

Один чёрт вытянется чем-нибуть. Давай лучше плясать от другой 
минимальной системы - что ты планируешь разворачивать, и что ему нужно.

>
>> В glibc-utils находятся как утилиты, которые ИМХО должны быть в любой (даже
>> самой минимальной) системе (getconf, getent, ldd), так и утилиты,
>> которые "возможно, когда-нибудь, кому-нибудь, в каких-то случаях могут
>> понадобиться" (среди них и mtrace).
>
> Согласен.
>
>> Зачем вводить новые субпакеты, когда
>> можно первые внести в glibc, туда же положить сиротливый iconv и утилиты из
>> glibc-timezones,
>
> А нафига в каждой системе эти утилиты? Ни разу в жизни не одну из них не
> запускал, а полезность tzselect вообще в современной системе неочевидна.
> Её точно не нужно оторвать нафиг?

Ей могут пользоваться какие-то утилиты.

>
>> и оторвать в glibc зависимости на glibc-tools, iconv,
>> glibc-locales, glibc-timezones.
>
> $ du -hs /usr/lib64/gconv
> 6,4M	/usr/lib64/gconv
>
> это все действительно нужно в каждой минимальной системе?

Насчёт минимальной не уверен, но без gconv могут очень забавные ляпы 
начать вылезать на серверах в самых странных местах.

Это же вся конвертация кодировок отрывается.

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Tue, Apr 29, 2014 at 09:57:25PM +0400, Anton Farygin wrote:

> А чем тебе perl на сервере не угодил ? маленький и позволяет делать 
> много всего делать.

На сервере очень даже угодил. Писать-то больше и не на чем :)
А вот иметь возможжность создавать минималистичные VE хотелось бы.

> Один чёрт вытянется чем-нибуть. Давай лучше плясать от другой 
> минимальной системы - что ты планируешь разворачивать, и что ему нужно.

Один сервис -- одна VE. И чем меньше эта VE, тем лучше. Тот же астер
держать в отдельной VE.

>> А нафига в каждой системе эти утилиты? Ни разу в жизни не одну из них не
> > запускал, а полезность tzselect вообще в современной системе неочевидна.
>> Её точно не нужно оторвать нафиг?
> Ей могут пользоваться какие-то утилиты.

И что полезного они ей делают?

>>> и оторвать в glibc зависимости на glibc-tools, iconv,
>>> glibc-locales, glibc-timezones.
>> $ du -hs /usr/lib64/gconv
>> 6,4M	/usr/lib64/gconv
>> это все действительно нужно в каждой минимальной системе?
> Насчёт минимальной не уверен, но без gconv могут очень забавные ляпы 
> начать вылезать на серверах в самых странных местах.
> Это же вся конвертация кодировок отрывается.

Напомню, мы говорим не о серверах вроде server-light (который является
хоть и минималистичным, но таки полноценным серверным дистрибутивом), а о
нано VE :)

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Farygin]

On 29.04.2014 23:39, Денис Смирнов wrote:
> On Tue, Apr 29, 2014 at 09:57:25PM +0400, Anton Farygin wrote:
>
>> А чем тебе perl на сервере не угодил ? маленький и позволяет делать
>> много всего делать.
>
> На сервере очень даже угодил. Писать-то больше и не на чем :)
> А вот иметь возможжность создавать минималистичные VE хотелось бы.
>
>> Один чёрт вытянется чем-нибуть. Давай лучше плясать от другой
>> минимальной системы - что ты планируешь разворачивать, и что ему нужно.
>
> Один сервис -- одна VE. И чем меньше эта VE, тем лучше. Тот же астер
> держать в отдельной VE.

А насколько хорошо астериск держать в VE ? И чем тебе не нравится на 
одном сервере класса small office держать всё в одной системе, но 
изолировав по максимуму процессы ?


>
>>>> и оторвать в glibc зависимости на glibc-tools, iconv,
>>>> glibc-locales, glibc-timezones.
>>> $ du -hs /usr/lib64/gconv
>>> 6,4M	/usr/lib64/gconv
>>> это все действительно нужно в каждой минимальной системе?
>> Насчёт минимальной не уверен, но без gconv могут очень забавные ляпы
>> начать вылезать на серверах в самых странных местах.
>> Это же вся конвертация кодировок отрывается.
>
> Напомню, мы говорим не о серверах вроде server-light (который является
> хоть и минималистичным, но таки полноценным серверным дистрибутивом), а о
> нано VE :)

Nano VE ? Но что это ? И чем тебя пугает лишние 100 мегабайт на диске в VE ?
Нет, я не возражаю, мне просто интересно.
Надо всё-таки идти от задачи, а не от цели.

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]

On Wed, Apr 30, 2014 at 12:25:42AM +0400, Anton Farygin wrote:

>> Один сервис -- одна VE. И чем меньше эта VE, тем лучше. Тот же астер
>> держать в отдельной VE.
> А насколько хорошо астериск держать в VE ?

В OpenVZ ничем не хуже, чем на хост системе, по крайней мере если не
используется DAHDI.

И я уже не раз сталкивался с задачами, где проще запустить несколько
астерисков, чем заставить эту скотину не глючить, не падать и не
дедлочиться.

> И чем тебе не нравится на 
> одном сервере класса small office держать всё в одной системе, но 
> изолировав по максимуму процессы ?

Управляемостью. Собрав один раз VE для конкретной функциональности я могу
её полностью изолировать, и совершенно отдельно обновлять и т.д.

>> Напомню, мы говорим не о серверах вроде server-light (который является
>> хоть и минималистичным, но таки полноценным серверным дистрибутивом), а о
>> нано VE :)
> Nano VE ? Но что это ? И чем тебя пугает лишние 100 мегабайт на диске в VE ?
> Нет, я не возражаю, мне просто интересно.
> Надо всё-таки идти от задачи, а не от цели.

Задача -- кроме пустого read-only chroot использовать изолированную VE с
жестко специфицированной функциональностью. Такая VE является простым
строительным блоком системы, который существенно упрощает
администрирование.

Идеальная система с моей точки зрения это вообще "одна функция -- один
компьютер", но для SOHO это неприемлимо дорого и сложно в
администрировании. "одна функция -- одна VE" это приемлемый компромисс.

И в этом случае подразумевается, что могут быть VE, у которых даже ssh (о
ужас!) не будет. Вообще-то для этой идеи было бы идеальным даже заменить
sh+coreutils на busybox, но это совершенно не ясно как сделать более-менее
удобно и дистрибутивно.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Farygin]

On 30.04.2014 03:40, Денис Смирнов wrote:
> On Wed, Apr 30, 2014 at 12:25:42AM +0400, Anton Farygin wrote:
>
>>> Один сервис -- одна VE. И чем меньше эта VE, тем лучше. Тот же астер
>>> держать в отдельной VE.
>> А насколько хорошо астериск держать в VE ?
>
> В OpenVZ ничем не хуже, чем на хост системе, по крайней мере если не
> используется DAHDI.
>
> И я уже не раз сталкивался с задачами, где проще запустить несколько
> астерисков, чем заставить эту скотину не глючить, не падать и не
> дедлочиться.

Хм... а я ещё думал отказаться от FreeSWITCH. Оно как-то работает, не 
глючит и не падает.

OpenVZ ещё жив ? Там ядро всё ещё 2.6.32 ? А как на этом ядре живёт 
современный юзерспейс ?

>
>> И чем тебе не нравится на
>> одном сервере класса small office держать всё в одной системе, но
>> изолировав по максимуму процессы ?
>
> Управляемостью. Собрав один раз VE для конкретной функциональности я могу
> её полностью изолировать, и совершенно отдельно обновлять и т.д.

А мне кажется что это как раз немного раздувает ресурсы по 
администрированию. Хотя, если ты не планируешь с этим VE ничего делать, 
то наверное ты прав ;)


>
>>> Напомню, мы говорим не о серверах вроде server-light (который является
>>> хоть и минималистичным, но таки полноценным серверным дистрибутивом), а о
>>> нано VE :)
>> Nano VE ? Но что это ? И чем тебя пугает лишние 100 мегабайт на диске в VE ?
>> Нет, я не возражаю, мне просто интересно.
>> Надо всё-таки идти от задачи, а не от цели.
>
> Задача -- кроме пустого read-only chroot использовать изолированную VE с
> жестко специфицированной функциональностью. Такая VE является простым
> строительным блоком системы, который существенно упрощает
> администрирование.
>
> Идеальная система с моей точки зрения это вообще "одна функция -- один
> компьютер", но для SOHO это неприемлимо дорого и сложно в
> администрировании. "одна функция -- одна VE" это приемлемый компромисс.

А не кажется ли тебе что одна функция - один VE может привнести больше 
проблем в долгосрочной перспективе, чем одна функция - один сервер или 
много функций-один сервер ?

Ну, например, у тебя будет пачка очень старых протухших VE с 
потенциально дырявым userspace, или в случае слома хост-системы все VE 
будут тоже взломаны.


>
> И в этом случае подразумевается, что могут быть VE, у которых даже ssh (о
> ужас!) не будет. Вообще-то для этой идеи было бы идеальным даже заменить
> sh+coreutils на busybox, но это совершенно не ясно как сделать более-менее
> удобно и дистрибутивно.

Если тебя не напрягает ещё одно ядро, то это как раз делается тривиально 
- kvm + kernel + initramfs
Но Overhead по памяти выше VZ. Правда и плюсов тоже приличное 
количество, включая разные ядра и разные ОС.

А при теперешней стоимости памяти оно ещё и дёшево получается.

Re: [devel] VZ vs LXC

[Anton Farygin]

On 30.04.2014 13:00, Anton Farygin wrote:
> On 30.04.2014 03:40, Денис Смирнов wrote:
>> On Wed, Apr 30, 2014 at 12:25:42AM +0400, Anton Farygin wrote:
>>
>>>> Один сервис -- одна VE. И чем меньше эта VE, тем лучше. Тот же астер
>>>> держать в отдельной VE.
>>> А насколько хорошо астериск держать в VE ?
>>


Кстати, отвлекаясь от темы.

А не выгоднее ли изолировать процессы другими способами ? Сейчас же есть 
как минимум два инструмента, позволяющих очень жёстко изолировать 
процессы от хост системы. SELinux и механизмы LXC (которыми, кстати, 
частично пользуется systemd)

[devel] VZ vs LXC

[Dmitry Derjavin]

Ср, 30 апр 2014, 13:06, Anton Farygin:

> А не выгоднее ли изолировать процессы другими способами ? Сейчас же
> есть как минимум два инструмента, позволяющих очень жёстко изолировать
> процессы от хост системы. SELinux и механизмы LXC (которыми, кстати,
> частично пользуется systemd)

«Механизмы LXC» — это ведь те же самые механизмы, которые использует
OpenVZ. Кстати, vzctl у нас давно уже работает на свежих ядрах. Но в
режиме ограниченной функциональности, конечно. И эти же механизмы
использует docker-io. И ip netns, кстати, тоже.

Причём, ip netns из коробки умеет не только сетевые namespace-ы, но и
монтирует /etc/netns/<ns>/resolv.conf в /etc/resolv.conf в отдельном
mount namespace! Очень рекомендую.

Предлагаю с этим в sysadmins@.

-- 
~dd

Re: [devel] VZ vs LXC

[Anton Farygin]

On 30.04.2014 18:51, Dmitry Derjavin wrote:
> Ср, 30 апр 2014, 13:06, Anton Farygin:
>
>> А не выгоднее ли изолировать процессы другими способами ? Сейчас же
>> есть как минимум два инструмента, позволяющих очень жёстко изолировать
>> процессы от хост системы. SELinux и механизмы LXC (которыми, кстати,
>> частично пользуется systemd)
>
> «Механизмы LXC» — это ведь те же самые механизмы, которые использует
> OpenVZ. Кстати, vzctl у нас давно уже работает на свежих ядрах. Но в
> режиме ограниченной функциональности, конечно. И эти же механизмы
> использует docker-io. И ip netns, кстати, тоже.
>
> Причём, ip netns из коробки умеет не только сетевые namespace-ы, но и
> монтирует /etc/netns/<ns>/resolv.conf в /etc/resolv.conf в отдельном
> mount namespace! Очень рекомендую.
>
> Предлагаю с этим в sysadmins@.

Дима, а расскажи здесь, пожалуйста. Чрут то всё равно ведь нужен ?

Как бы сделать так, что бы не нужно было бы загонять приложение в чрут, 
а просто ограничить его доступ к системному окружению и сети.

Тем для всё-таки не для sysadmins@. docker - это насколько я понял, 
несколько иное решение - он делает чруты на основе... ну на какой-то основе.

ip netns вообще для другого - изоляция сети дело хорошее, но это лишь 
малая часть того, что нужно для полного счастья.

Было бы здорово описывать в конфиге необходимость изоляции сервиса и 
сети, а дальше всё на себя берёт initscript (или systemd, кому как 
удобнее ;) )

Re: [devel] VZ vs LXC

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]

On Wed, Apr 30, 2014 at 06:51:40PM +0400, Dmitry Derjavin wrote:
> Ср, 30 апр 2014, 13:06, Anton Farygin:
> 
> > А не выгоднее ли изолировать процессы другими способами ? Сейчас же
> > есть как минимум два инструмента, позволяющих очень жёстко изолировать
> > процессы от хост системы. SELinux и механизмы LXC (которыми, кстати,
> > частично пользуется systemd)
> 
> «Механизмы LXC» — это ведь те же самые механизмы, которые использует OpenVZ.

Не совсем те же самые, скорее родственные.

> Кстати, vzctl у нас давно уже работает на свежих ядрах. Но в
> режиме ограниченной функциональности, конечно.

https://openvz.org/Vzctl_for_upstream_kernel#Limitations

> И эти же механизмы использует docker-io. И ip netns, кстати, тоже.

docker-io - это lxc на стероидах. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] VZ vs LXC

[Dmitry Derjavin]

Fri, 02 May 2014, 03:51, Dmitry V. Levin:

> docker-io - это lxc на стероидах. :)

По-моему, скорее, «с человеческим лицом». :)

-- 
~dd

Re: [devel] VZ vs LXC

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 600 bytes --]

On Wed, Apr 30, 2014 at 01:06:19PM +0400, Anton Farygin wrote:

> Кстати, отвлекаясь от темы.
> А не выгоднее ли изолировать процессы другими способами ? Сейчас же есть 
> как минимум два инструмента, позволяющих очень жёстко изолировать 
> процессы от хост системы. SELinux и механизмы LXC (которыми, кстати, 
> частично пользуется systemd)

И то и другое требует усилий для внедрения в дистрибутив и начала
активного применения. Чтобы это было столь же просто как chrooted сервисы.

Насколько я вижу желающих пока так и не находится :(

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] VZ vs LXC

[Anton Farygin]

On 01.05.2014 00:57, Денис Смирнов wrote:
> On Wed, Apr 30, 2014 at 01:06:19PM +0400, Anton Farygin wrote:
>
>> Кстати, отвлекаясь от темы.
>> А не выгоднее ли изолировать процессы другими способами ? Сейчас же есть
>> как минимум два инструмента, позволяющих очень жёстко изолировать
>> процессы от хост системы. SELinux и механизмы LXC (которыми, кстати,
>> частично пользуется systemd)
>
> И то и другое требует усилий для внедрения в дистрибутив и начала
> активного применения. Чтобы это было столь же просто как chrooted сервисы.
>
> Насколько я вижу желающих пока так и не находится :(

Желающие есть. Времени не находится.

Все живут по принципу: "Зачем это делать, когда есть работающее решение".

Re: [devel] VZ vs LXC

[Anton Gorlov]

Я пробовал docker посмотреть.. Но так и не осилил его систему сборки. То 
что нащупал слабо подаётся (по кр мере моему) даже осмыслению как 
пакетик вот это вот всё..

01.05.2014 09:27, Anton Farygin пишет:
>
> Желающие есть. Времени не находится.
>
> Все живут по принципу: "Зачем это делать, когда есть работающее решение". 

[devel] docker-io: посмотреть (was: Re: VZ vs LXC)

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

On Thu, May 01, 2014 at 12:23:47PM +0400, Anton Gorlov wrote:
> Я пробовал docker посмотреть.. Но так и не осилил его систему сборки. То что
> нащупал слабо подаётся (по кр мере моему) даже осмыслению как пакетик вот
> это вот всё..

docker import
принимает разнообразные тарболлы, в том числе, сделанные с помощью
mkimage-profiles.

Поскольку я запушил, сейчас можно сделать сразу вот так:

$ docker run -t -i fotengauer/altlinux-sisyphus:latest bash

и оно скачает вам образ.
А формат Dockerfile кажется очевидным вполне.

-- 
glebfm
 
Глеб Фотенгауэр-Малиновский

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] docker-io: посмотреть

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 914 bytes --]

On Mon, May 05, 2014 at 03:45:55PM +0400, Anton Gorlov wrote:
> 05.05.2014 13:42, Gleb Fotengauer-Malinovskiy пишет:
> >docker import
> >принимает разнообразные тарболлы, в том числе, сделанные с помощью
> >mkimage-profiles.
> >
> >Поскольку я запушил, сейчас можно сделать сразу вот так:
> >
> >$ docker run -t -i fotengauer/altlinux-sisyphus:latest bash
> >
> >и оно скачает вам образ.
> >А формат Dockerfile кажется очевидным вполне.
> 
> Не. Я про сборку самого доккера. У нас версия
> Current version: 0.10.0-alt2, а речь про обновить до актуальной

0.10.0 нынче и есть актуальная.

-- 
glebfm
 
Глеб Фотенгауэр-Малиновский

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] docker-io: посмотреть

[Igor Zubkov]

2014-05-05 19:52 GMT+03:00 Gleb Fotengauer-Malinovskiy:
> On Mon, May 05, 2014 at 03:45:55PM +0400, Anton Gorlov wrote:
>> 05.05.2014 13:42, Gleb Fotengauer-Malinovskiy пишет:
>> >docker import
>> >принимает разнообразные тарболлы, в том числе, сделанные с помощью
>> >mkimage-profiles.
>> >
>> >Поскольку я запушил, сейчас можно сделать сразу вот так:
>> >
>> >$ docker run -t -i fotengauer/altlinux-sisyphus:latest bash
>> >
>> >и оно скачает вам образ.
>> >А формат Dockerfile кажется очевидным вполне.
>>
>> Не. Я про сборку самого доккера. У нас версия
>> Current version: 0.10.0-alt2, а речь про обновить до актуальной
>
> 0.10.0 нынче и есть актуальная.

Кто-то перепутал docker и lxc которые выпустили 1.0.0 версию?

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] VZ vs LXC

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

On Thu, May 01, 2014 at 09:27:54AM +0400, Anton Farygin wrote:

>> Насколько я вижу желающих пока так и не находится :(
> Желающие есть. Времени не находится.

Это и значит нет по-настоящему желающих :)

> Все живут по принципу: "Зачем это делать, когда есть работающее решение".

Ага. И, в принципе, OpenVZ + пустые read-only chroot проблему решают
вполне неплохо.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Led]

On Wednesday 30 April 2014 12:00:48 Anton Farygin wrote:
> On 30.04.2014 03:40, Денис Смирнов wrote:
> > On Wed, Apr 30, 2014 at 12:25:42AM +0400, Anton Farygin wrote:
> >>> Один сервис -- одна VE. И чем меньше эта VE, тем лучше. Тот же астер
> >>> держать в отдельной VE.
> >>
> >> А насколько хорошо астериск держать в VE ?
> >
> > В OpenVZ ничем не хуже, чем на хост системе, по крайней мере если не
> > используется DAHDI.
> >
> > И я уже не раз сталкивался с задачами, где проще запустить несколько
> > астерисков, чем заставить эту скотину не глючить, не падать и не
> > дедлочиться.
>
> Хм... а я ещё думал отказаться от FreeSWITCH. Оно как-то работает, не
> глючит и не падает.
>
> OpenVZ ещё жив ?

Жив.

> Там ядро всё ещё 2.6.32 ?

Там ядро EL6 - это ни разу не 2.6.32, хотя как шутка/мэм упоминается.

> А как на этом ядре живёт  
> современный юзерспейс ?

glibc собран с "2.6.32 и выше". Если какому-то "юзерспейсу" этого недостаточно 
(?) (не будем тыкать пальцами), то это проблемы этого "юзерспейса" и на 
совести того, кто подобное собирает:)

> > И в этом случае подразумевается, что могут быть VE, у которых даже ssh (о
> > ужас!) не будет. Вообще-то для этой идеи было бы идеальным даже заменить
> > sh+coreutils на busybox, но это совершенно не ясно как сделать
> > более-менее удобно и дистрибутивно.
>
> Если тебя не напрягает ещё одно ядро, то это как раз делается тривиально
> - kvm + kernel + initramfs
> Но Overhead по памяти выше VZ. Правда и плюсов тоже приличное
> количество, включая разные ядра и разные ОС.
>
> А при теперешней стоимости памяти оно ещё и дёшево получается.

Память для KVM купить можно, а IO - не купишь.

-- 
Led

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Gorlov]

Кстати да.. как человек жующий kvm могу сказать что дисковое  io там не 
шибко весело местами.

30.04.2014 13:33, Led пишет:
>> Если тебя не напрягает ещё одно ядро, то это как раз делается тривиально
>> >- kvm + kernel + initramfs
>> >Но Overhead по памяти выше VZ. Правда и плюсов тоже приличное
>> >количество, включая разные ядра и разные ОС.
>> >
>> >А при теперешней стоимости памяти оно ещё и дёшево получается.
> Память для KVM купить можно, а IO - не купишь.

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Farygin]

Я lvm отдаю через virtio и вроде не замечал проблем.

Правда, для хэшера использую ОЗУ.

On 30.04.2014 15:13, Anton Gorlov wrote:
> Кстати да.. как человек жующий kvm могу сказать что дисковое  io там не
> шибко весело местами.
>
> 30.04.2014 13:33, Led пишет:
>>> Если тебя не напрягает ещё одно ядро, то это как раз делается тривиально
>>> >- kvm + kernel + initramfs
>>> >Но Overhead по памяти выше VZ. Правда и плюсов тоже приличное
>>> >количество, включая разные ядра и разные ОС.
>>> >
>>> >А при теперешней стоимости памяти оно ещё и дёшево получается.
>> Память для KVM купить можно, а IO - не купишь.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Gorlov]

30.04.2014 17:01, Anton Farygin пишет:
> Я lvm отдаю через virtio и вроде не замечал проблем.
>
> Правда, для хэшера использую ОЗУ.
У меня на shared хостинге онное. В смысле внутри  kvm 100500 
апачевхостов ( и не только апаче).. заметно что по ио таки оверхед есть. 
Так же lvm+virtio

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]

On Wed, Apr 30, 2014 at 01:00:48PM +0400, Anton Farygin wrote:

>> И я уже не раз сталкивался с задачами, где проще запустить несколько
>> астерисков, чем заставить эту скотину не глючить, не падать и не
>> дедлочиться.
> Хм... а я ещё думал отказаться от FreeSWITCH. Оно как-то работает, не 
> глючит и не падает.

Мы его, возможно, сильно по-разному используем. Там где я юзаю меня мучают
хитрыми AGI и AMI приложениями. И я периодически матерюсь, например, что
эта скотина умудряется в AMI при неудачных звонках отправить сообщение о
завершении соединения _до_ сообщения о начале попытки.

> OpenVZ ещё жив ? Там ядро всё ещё 2.6.32 ? А как на этом ядре живёт 
> современный юзерспейс ?

OpenVZ вряд ли сдохнет, уж слишком много кто на него завязывается.

>> Управляемостью. Собрав один раз VE для конкретной функциональности я могу
>> её полностью изолировать, и совершенно отдельно обновлять и т.д.
> А мне кажется что это как раз немного раздувает ресурсы по 
> администрированию. Хотя, если ты не планируешь с этим VE ничего делать, 
> то наверное ты прав ;)

Идеальная VE -- это практически не требующая администрирования. Моя мечта
:)

>> Идеальная система с моей точки зрения это вообще "одна функция -- один
>> компьютер", но для SOHO это неприемлимо дорого и сложно в
>> администрировании. "одна функция -- одна VE" это приемлемый компромисс.
> А не кажется ли тебе что одна функция - один VE может привнести больше 
> проблем в долгосрочной перспективе, чем одна функция - один сервер или 
> много функций-один сервер ?
> Ну, например, у тебя будет пачка очень старых протухших VE с 
> потенциально дырявым userspace, или в случае слома хост-системы все VE 
> будут тоже взломаны.

Там, где допустимы редкие сбои с оперативностью "пока админ не добежит"
вообще в таких VE можно делать apt-get upgrade по крону.

Ну и с точки зрения безопасности -- пока не взломана HN, такая пачка
надежнее будет. Как минимум из-за изолированности данных разных сервисов,
и возможности более жестко контролировать какой сервис к какому, и к каким
данным имеет доступ.

>> И в этом случае подразумевается, что могут быть VE, у которых даже ssh (о
>> ужас!) не будет. Вообще-то для этой идеи было бы идеальным даже заменить
>> sh+coreutils на busybox, но это совершенно не ясно как сделать более-менее
>> удобно и дистрибутивно.
> Если тебя не напрягает ещё одно ядро, то это как раз делается тривиально 
> - kvm + kernel + initramfs
> Но Overhead по памяти выше VZ. Правда и плюсов тоже приличное 
> количество, включая разные ядра и разные ОС.
> А при теперешней стоимости памяти оно ещё и дёшево получается.

А initramfs чем собирать? И, кстати, VoIP и прочее риалтайм добро как себя
в KVM чувствует?

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Anton Farygin]

On 01.05.2014 00:54, Денис Смирнов wrote:
> On Wed, Apr 30, 2014 at 01:00:48PM +0400, Anton Farygin wrote:
>
>>> И я уже не раз сталкивался с задачами, где проще запустить несколько
>>> астерисков, чем заставить эту скотину не глючить, не падать и не
>>> дедлочиться.
>> Хм... а я ещё думал отказаться от FreeSWITCH. Оно как-то работает, не
>> глючит и не падает.
>
> Мы его, возможно, сильно по-разному используем. Там где я юзаю меня мучают
> хитрыми AGI и AMI приложениями. И я периодически матерюсь, например, что
> эта скотина умудряется в AMI при неудачных звонках отправить сообщение о
> завершении соединения _до_ сообщения о начале попытки.

Да, до AGI и AMI приложений я ещё не добрался.

>
>> OpenVZ ещё жив ? Там ядро всё ещё 2.6.32 ? А как на этом ядре живёт
>> современный юзерспейс ?
>
> OpenVZ вряд ли сдохнет, уж слишком много кто на него завязывается.
>
>>> Управляемостью. Собрав один раз VE для конкретной функциональности я могу
>>> её полностью изолировать, и совершенно отдельно обновлять и т.д.
>> А мне кажется что это как раз немного раздувает ресурсы по
>> администрированию. Хотя, если ты не планируешь с этим VE ничего делать,
>> то наверное ты прав ;)
>
> Идеальная VE -- это практически не требующая администрирования. Моя мечта
> :)

Чудес не бывает, всё-равно что-то делать в ней придётся. Ну, как минимум 
обновления накатывать твоего чудесного приложения ;)

>
>>> Идеальная система с моей точки зрения это вообще "одна функция -- один
>>> компьютер", но для SOHO это неприемлимо дорого и сложно в
>>> администрировании. "одна функция -- одна VE" это приемлемый компромисс.
>> А не кажется ли тебе что одна функция - один VE может привнести больше
>> проблем в долгосрочной перспективе, чем одна функция - один сервер или
>> много функций-один сервер ?
>> Ну, например, у тебя будет пачка очень старых протухших VE с
>> потенциально дырявым userspace, или в случае слома хост-системы все VE
>> будут тоже взломаны.
>
> Там, где допустимы редкие сбои с оперативностью "пока админ не добежит"
> вообще в таких VE можно делать apt-get upgrade по крону.

Надо попробовать.

>
> Ну и с точки зрения безопасности -- пока не взломана HN, такая пачка
> надежнее будет. Как минимум из-за изолированности данных разных сервисов,
> и возможности более жестко контролировать какой сервис к какому, и к каким
> данным имеет доступ.

Здесь спору нет. Тут скорее возникает вопрос о хост системе - там то по 
крону совсем страшно делать обновления, и это самое уязвимое место с 
точки зрения архитектуры.

>
>>> И в этом случае подразумевается, что могут быть VE, у которых даже ssh (о
>>> ужас!) не будет. Вообще-то для этой идеи было бы идеальным даже заменить
>>> sh+coreutils на busybox, но это совершенно не ясно как сделать более-менее
>>> удобно и дистрибутивно.
>> Если тебя не напрягает ещё одно ядро, то это как раз делается тривиально
>> - kvm + kernel + initramfs
>> Но Overhead по памяти выше VZ. Правда и плюсов тоже приличное
>> количество, включая разные ядра и разные ОС.
>> А при теперешней стоимости памяти оно ещё и дёшево получается.
>
> А initramfs чем собирать? И, кстати, VoIP и прочее риалтайм добро как себя
> в KVM чувствует?
initramfs собирать с помощью mkimage

VOIP в kvm не запускал, у меня весь VoIP крутится на атомах (такая вот 
аппаратная виртуализация). Из серии один сервер - одна задача. Очень 
чудно, IPMI только не хватает.

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1911 bytes --]

On Thu, May 01, 2014 at 09:46:48AM +0400, Anton Farygin wrote:

>> Мы его, возможно, сильно по-разному используем. Там где я юзаю меня мучают
>> хитрыми AGI и AMI приложениями. И я периодически матерюсь, например, что
>> эта скотина умудряется в AMI при неудачных звонках отправить сообщение о
>> завершении соединения _до_ сообщения о начале попытки.
> Да, до AGI и AMI приложений я ещё не добрался.

О, это самое вкусное. Астер же изначально IVR-платформа, а софтсвич из
него был есть и будет средней паршивости. 

>> Идеальная VE -- это практически не требующая администрирования. Моя мечта
>> :)
> Чудес не бывает, всё-равно что-то делать в ней придётся. Ну, как минимум 
> обновления накатывать твоего чудесного приложения ;)

А это можно делать в продакшн поднимаю новую аналогичную VE с новой
версией и переключаясь. Что очень облегчает задачу "откатиться назад ежели
что-то взорвалось".

>> Ну и с точки зрения безопасности -- пока не взломана HN, такая пачка
>> надежнее будет. Как минимум из-за изолированности данных разных сервисов,
>> и возможности более жестко контролировать какой сервис к какому, и к каким
>> данным имеет доступ.
> Здесь спору нет. Тут скорее возникает вопрос о хост системе - там то по 
> крону совсем страшно делать обновления, и это самое уязвимое место с 
> точки зрения архитектуры.

На HN ничего кроме ssh, iptables и vzctl жить не должно. И ежели доступ к
ssh ограничен по IP, то вероятность взлома сводится к минимуму.

>> А initramfs чем собирать? И, кстати, VoIP и прочее риалтайм добро как себя
>> в KVM чувствует?
> initramfs собирать с помощью mkimage
> VOIP в kvm не запускал, у меня весь VoIP крутится на атомах (такая вот 
> аппаратная виртуализация). Из серии один сервер - одна задача. Очень 
> чудно, IPMI только не хватает.

Эх... Хочу маленькие дешевые ARM с IPMI :)

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Thu, May 01, 2014 at 09:46:48AM +0400, Anton Farygin wrote:
> Здесь спору нет. Тут скорее возникает вопрос о хост системе -
> там то по крону совсем страшно делать обновления, и это самое
> уязвимое место с точки зрения архитектуры.

Там пакетов раз-два и обчёлся, по сути ядро.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

[devel] KVM "vs" OpenVZ (was: Минимальный VE огромен -- много мусора)

[Michael Shigorin]

On Thu, May 01, 2014 at 12:54:55AM +0400, Денис Смирнов wrote:
> А initramfs чем собирать?

http://git.altlinux.org/people/legion/packages/?p=make-initrd.git;a=shortlog;h=refs/heads/sysinit

> И, кстати, VoIP и прочее риалтайм добро как себя в KVM чувствует?

Не смотрел, но нагруженный kvm под erlang изрядно дурил таймером
(если кому будет важно, посмотрю/спрошу подробности -- насколько
помню, тогда это "всего лишь" убивало производительность).

А под ovz * с dahdi работал, что просовывалось -- могу глянуть.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Tue, Apr 29, 2014 at 08:57:34PM +0400, Денис Смирнов wrote:
> $ du -hs /usr/lib64/gconv
> 6,4M	/usr/lib64/gconv
> 
> это все действительно нужно в каждой минимальной системе?

Почти: без него даже man не заработает.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

On Tue, Apr 29, 2014 at 11:03:38PM +0300, Michael Shigorin wrote:

>> $ du -hs /usr/lib64/gconv
>> 6,4M	/usr/lib64/gconv
>> это все действительно нужно в каждой минимальной системе?
> Почти: без него даже man не заработает.

Я имел в виду _все ли_ они нужны в минимальной системе? Я в реальной жизни
EBCDIC не встречал.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Led]

On Tuesday 29 April 2014 19:57:34 Денис Смирнов wrote:
> On Tue, Apr 29, 2014 at 07:17:06PM +0300, Led wrote:
> >> Сейчас ситуация такая -- пакет с именем 'glibc' имеет непрямую
> >> зависимость на 'perl-base', что с любой точки зрения является
> >> некорректным как чисто технически (кольцевая зависимость),
> >
> > И где там "кольцевая зависимость"?
>
> Сорри, ошибся.
>
> >> Предложенное тобой изменение оставит mtrace в пакете glibc-utils, что
> >> хоть и решит проблему частично, но оставит неочевидную зависимость.
> >
> > Какую?
>
> Пакет с именем ^glibc-.* зависящий от перловки -- это неочевидно. С
> технической точки зрения корректно, но с админской -- нет.

Ну, это уже "игра в ассоциации":)

>
> > В glibc-utils находятся как утилиты, которые ИМХО должны быть в любой
> > (даже самой минимальной) системе (getconf, getent, ldd), так и утилиты,
> > которые "возможно, когда-нибудь, кому-нибудь, в каких-то случаях могут
> > понадобиться" (среди них и mtrace).
>
> Согласен.
>
> > Зачем вводить новые субпакеты, когда
> > можно первые внести в glibc, туда же положить сиротливый iconv и утилиты
> > из glibc-timezones,
>
> А нафига в каждой системе эти утилиты? Ни разу в жизни не одну из них не
> запускал, а полезность tzselect вообще в современной системе неочевидна.
> Её точно не нужно оторвать нафиг?

shell-скрипт размером 7k? Зачем его "отрывать":) Хотя, если он никем не используется, можно и его в glibc-utils. 
Возможно, и остальные утилиты из glibc-timezones - туда же.

>
> > и оторвать в glibc зависимости на glibc-tools, iconv,
> > glibc-locales, glibc-timezones.
>
> $ du -hs /usr/lib64/gconv
> 6,4M	/usr/lib64/gconv
>
> это все действительно нужно в каждой минимальной системе?

Ну, про iconv/glibc-gconv-modules можно ещё подумать. Хотя ~6M врядли тянет на "оверхэд"...

И да, glibc-utils, конечно же, а не glibc-tools.

-- 
Led

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1290 bytes --]

On Wed, Apr 30, 2014 at 08:54:31AM +0300, Led wrote:

>> Пакет с именем ^glibc-.* зависящий от перловки -- это неочевидно. С
>> технической точки зрения корректно, но с админской -- нет.
> Ну, это уже "игра в ассоциации":)

Бесспорно, но все же "неаккуратненько" ;)

>> А нафига в каждой системе эти утилиты? Ни разу в жизни не одну из них не
>> запускал, а полезность tzselect вообще в современной системе неочевидна.
>> Её точно не нужно оторвать нафиг?
> shell-скрипт размером 7k? Зачем его "отрывать":) Хотя, если он никем не используется, можно и его в glibc-utils. 
> Возможно, и остальные утилиты из glibc-timezones - туда же.

Насколько я вижу -- туда же, ибо в системе они не особо нужны.

>>> и оторвать в glibc зависимости на glibc-tools, iconv,
>>> glibc-locales, glibc-timezones.
>> $ du -hs /usr/lib64/gconv
>> 6,4M	/usr/lib64/gconv
>> это все действительно нужно в каждой минимальной системе?
> Ну, про iconv/glibc-gconv-modules можно ещё подумать. Хотя ~6M врядли тянет на "оверхэд"...

Моих знаний не хватает, чтобы определить разумно ли их распиливать.
Возможно EBCDIC и китайские можно было бы в glibc-gconv-modules-extra
отпилить.

> И да, glibc-utils, конечно же, а не glibc-tools.

Ok.

-- 
С уважением, Денис

http://mithraen.ru/


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Thu, May 01, 2014 at 12:48:39AM +0400, Денис Смирнов wrote:
> Возможно EBCDIC и китайские можно было бы
> в glibc-gconv-modules-extra отпилить.

С этим бы помог, т.к. всё равно приходится этим заниматься в
http://git.altlinux.org/people/mike/packages/?p=mkimage-profiles.git;a=blob;f=features.in/install2/install2/image-scripts.d/90-install2-cleanup-l10n;hb=HEAD

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Минимальный VE огромен -- много мусора

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1064 bytes --]

On Tue, Apr 29, 2014 at 12:32:21AM +0300, Led wrote:
> On Tuesday 29 April 2014 00:17:16 Dmitry V. Levin wrote:
> > On Tue, Apr 29, 2014 at 12:10:23AM +0300, Led wrote:
> > > On Monday 28 April 2014 23:57:06 Денис Смирнов wrote:
> > > > On Mon, Apr 28, 2014 at 11:50:18PM +0300, Led wrote:
> > > > >> Ради небольшого perl-base, или есть варианты?
> > > > >
> > > > > Действительно системные утилиты - положить в glibc, а в glibc-utils
> > > > > оставить всё остальное.
> > > >
> > > > Будет очередной геморрой при обновлении.
> > >
> > > Не будет.
> >
> > glibc - это сейчас виртуальный пакет, зависящий в т.ч. и от glibc-utils.
> > Если переносить из glibc-utils в glibc, то возникнут проблемы.
> 
> Скажем так, опытным путём проверено, что объединение содержимого glibc-core и glibc-utils в пакет glibc (с уничтожением 
> первых двух) к проблемам не приводит. Естественно, нужно правильно необходимые Provides расставить.

Если объединить glibc-core и glibc-utils в один пакет, то возникнут
нехорошие циклические зависимости.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Led]

On Tuesday 29 April 2014 03:21:17 Dmitry V. Levin wrote:
> On Tue, Apr 29, 2014 at 12:32:21AM +0300, Led wrote:
> > On Tuesday 29 April 2014 00:17:16 Dmitry V. Levin wrote:
> > > On Tue, Apr 29, 2014 at 12:10:23AM +0300, Led wrote:
> > > > On Monday 28 April 2014 23:57:06 Денис Смирнов wrote:
> > > > > On Mon, Apr 28, 2014 at 11:50:18PM +0300, Led wrote:
> > > > > >> Ради небольшого perl-base, или есть варианты?
> > > > > >
> > > > > > Действительно системные утилиты - положить в glibc, а в
> > > > > > glibc-utils оставить всё остальное.
> > > > >
> > > > > Будет очередной геморрой при обновлении.
> > > >
> > > > Не будет.
> > >
> > > glibc - это сейчас виртуальный пакет, зависящий в т.ч. и от
> > > glibc-utils. Если переносить из glibc-utils в glibc, то возникнут
> > > проблемы.
> >
> > Скажем так, опытным путём проверено, что объединение содержимого
> > glibc-core и glibc-utils в пакет glibc (с уничтожением первых двух) к
> > проблемам не приводит. Естественно, нужно правильно необходимые Provides
> > расставить.
>
> Если объединить glibc-core и glibc-utils в один пакет, то возникнут
> нехорошие циклические зависимости.

Да я ж не предлагаю объединять glibc-core и glibc-utils. Я предложил использовать пустой на данный момент glibc, убрав 
из него зависимость на glibc-utils и поместив в него "системные" файлы из glibc-utils (getconf, getent, ldd, может ещё 
что-то?)

-- 
Led

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

On Mon, Apr 28, 2014 at 11:42:07PM +0400, Dmitry V. Levin wrote:

>> А mtrace от glibc-utils положить в отдельный подпакет?
> Отдельный пакет ради небольшого скрипта?

Для редко используемого скрипта, который тянет за собой большой перл и
находится в базовом для системе пакете? Ага. 

От glibc-utils зависят, например: glibc, chrooted, gnupg2, make-initrd,
postfix.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

On Sun, Apr 27, 2014 at 03:38:07PM +0400, Anton Farygin wrote:
> >>Ладно perl. от графических библиотек бы избавиться на серверной системе.
> >А кто их тащит?
> glib-networking, libgio, libsoup
> а вот кто уже их тащит - надо разбираться.

Припоминаются gtk2/3 и fontconfig/freetype, которые пришлось
разматывать при создании regular-jeos.iso.

В общем, круг заинтересованных будто наметился, предлагаю
переходить к подготовке экспериментального тестового задания.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] Минимальный VE огромен -- много мусора

[Michael Shigorin]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

On Sun, Oct 04, 2009 at 03:50:00AM +0400, Денис Смирнов wrote:
> Сегодня пытался сделать минимальный VE. Минимальный это значит
> состоящий только из пакета basesystem и его зависимостей + apt.

(разглядывая ve/.base) Без сети?

> glibc-utils
> ===========
[...]
> Возможно ли отпилить mtrace  в отдельный пакет?

На всякий: патчик для отпиливания прилагается, при отсутствии
противопоказаний предлагаю всё же докатить хотя бы до сизифа.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

[-- Attachment #2: 0001-6-2.17-alt8.1.patch --]
[-- Type: text/x-patch, Size: 2513 bytes --]

>From 898b89befa8aca3011734d0492c7bd8de7288f28 Mon Sep 17 00:00:00 2001
From: Michael Shigorin <mike@altlinux.org>
Date: Sat, 30 Aug 2014 20:27:05 +0300
Subject: [PATCH] 6:2.17-alt8.1

- NMU: split mtrace into a subpackage of its own due to perl dependency
  as it is the only perl script there, and a rather obscure one; see also
  http://lists.altlinux.org/pipermail/devel/2009-October/175682.html
---
 alt/glibc.spec | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/alt/glibc.spec b/alt/glibc.spec
index cf09756..cc83321 100644
--- a/alt/glibc.spec
+++ b/alt/glibc.spec
@@ -1,6 +1,6 @@
 Name: glibc
 Version: 2.17
-Release: alt8
+Release: alt8.1
 Epoch: 6
 
 Summary: The GNU libc libraries
@@ -163,6 +163,11 @@ Obsoletes: gencat
 # due to rpcinfo
 Conflicts: rpcbind < 0.2.1-alt0.4
 
+%package -n mtrace
+Summary: A program to help interpret memory trace output
+Group: Development/Debuggers
+Conflicts: glibc-utils <= 2.17-alt8
+
 %package devel
 Summary: Include and object files required for C development
 Group: Development/C
@@ -253,6 +258,10 @@ timezones data in the system.
 This package contains miscellaneous non-essential %name utilities that
 didn't fit in specific packages.
 
+%description -n mtrace
+This package contains a program which interprets the memory traces
+and outputs a summary in an user-friendly way.
+
 %description nss
 NSS is a Name Service Switch subsystem.  The basic idea is to put the
 implementation of the different services offered to access the databases
@@ -612,6 +621,7 @@ fi
 %exclude %_bindir/iconv*
 %exclude %_bindir/locale*
 %exclude %_bindir/memusage*
+%exclude %_bindir/mtrace
 %exclude %_bindir/pcprofiledump
 %exclude %_bindir/tzselect
 %exclude %_bindir/xtrace
@@ -619,6 +629,9 @@ fi
 %_libdir/audit/sotruss-lib.so
 %exclude /var/db/Makefile
 
+%files -n mtrace
+%_bindir/mtrace
+
 %files devel -f devel.files
 %_libdir/lib*.so
 %exclude %_libdir/libmemusage.so
@@ -660,6 +673,11 @@ fi
 %_datadir/i18n
 
 %changelog
+* Sat Aug 30 2014 Michael Shigorin <mike@altlinux.org> 6:2.17-alt8.1
+- NMU: split mtrace into a subpackage of its own due to perl dependency
+  as it is the only perl script there, and a rather obscure one; see also
+  http://lists.altlinux.org/pipermail/devel/2009-October/175682.html
+
 * Wed Jan 15 2014 Dmitry V. Levin <ldv@altlinux.org> 6:2.17-alt8
 - libc.so: link libc.so.6 both before and after libc_nonshared.a,
   to fix spurious undefined reference with --as-needed reported
-- 
1.8.5.5

Re: [devel] Минимальный VE огромен -- много мусора

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

On Sat, Aug 30, 2014 at 10:08:29PM +0400, Michael Shigorin wrote:

>> Сегодня пытался сделать минимальный VE. Минимальный это значит
>> состоящий только из пакета basesystem и его зависимостей + apt.
> (разглядывая ve/.base) Без сети?

Вот тут не знаю. Для меня машина без сети, пусть и виртуальная,
бесполезная. Но могут быть и другие мнения.

Однако для меня сеть в VE -- это iproute + etcnet. Остальное опционально.
Уж по крайней мере какой-нибудь mount.nfs

Кстати большинство зависимостей пакета basesystem тоже излишни, вон даже
половина util-linux бесполезна в VE.

> > glibc-utils
> > ===========
> > Возможно ли отпилить mtrace  в отдельный пакет?
> На всякий: патчик для отпиливания прилагается, при отсутствии
> противопоказаний предлагаю всё же докатить хотя бы до сизифа.

Спасибо.

-- 
С уважением, Денис

http://mithraen.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]