падает bind

[madf 279]

 

 

Gentoo слабо поможет в сборке чего-то "особым образом".

Поможет, почти все ключики вынесены в use-флаги.

 

 

В моем понимании, "особым образом" - это с наложением нестандартных патчей. Ключиками, обычно, помечены вполне стандартные патчи, которые в бинарных дистрибутивах все включены. А тут можно просто лишнее выключить.

[NiTr0 583]

Слепить свой ебилд с патчами никто не помешает. Если сильно уж надо...

[madf 279]

Слепить свой ебилд с патчами никто не помешает. Если сильно уж надо...

Так же как и deb-пакет. Или rpm. Берем сущетсвующий ебилд (спеку в случае deb/rpm), добавляем в нее свой патч, ложим все в правильное место, скармливаем утилитам — готово.

Единственное что реально упрощает этот процесс в Gentoo это хак с epatch_user: http://blog.tremily.us/posts/Portage/

Но это нестандартное использование возможностей системы.

Что реально дает Gentoo по сравнению с deb/rpm-based, так это гибкое управление зависимостями и относительно свежий софт (наличие ебилдов для сборки софта прямо из девелоперского репозитория).

[ttttt 195]

Ну это все из расчета, что ничего меняться не будет и деплой, как таковой, вообще отсутствует, т.е. все ручками из терминала устанавливается. Тогда, наверное, можно и с deb и с rpm и с портами под фрей повозиться.

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

 

UPD: тс, обновил бинд?

Відредаговано 2013-05-28 21:03:42 ttttt

[madf 279]

Ну это все из расчета, что ничего меняться не будет и деплой, как таковой, вообще отсутствует, т.е. все ручками из терминала устанавливается. Тогда, наверное, можно и с deb и с rpm и с портами под фрей повозиться.

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

Как раз наоборот! В случае Gentoo просто создается ебилд нацеленный на git/mercurial/whatever и обновляться можно хоть после каждого коммита. В случае deb/rpm создается централизованный репозиторий куда, при правильной организации, пакеты попадают после 1-2 команд. Например make package, make deploy. Как под фрей — не знаю, наверное примерно как и под Gentoo.

Я такое не просто проходил, именно так все и было устроенно на прошлом месте работы. По крайней мере для софта разрабатываемого у нас.

[ttttt 195]

 

и обновляться можно хоть после каждого коммита

Ну вот пример, есть библиотека в новой версии которой обновили API немного и часть софта с ней не может работать без модификаций, а части нужна новая версия как раз из-за новых фич и что тогда делать и как долго? Собираем из исходников и софт и все зависимости изолированно от всего остального в отдельной директории, точнее ложим этот весь процесс в шел скрипт и вместе с исходниками в git/mercurial, туда же и скрипт деплоя на все машины - теперь мы можем и легко обновлять, никого не задевая, и легко менять и легко откатываться, и не зависеть от системы пакетов. Это проще, никак не ограничивает и времени почти не занимает.

[madf 279]

 

 

и обновляться можно хоть после каждого коммита

Ну вот пример, есть библиотека в новой версии которой обновили API немного и часть софта с ней не может работать без модификаций, а части нужна новая версия как раз из-за новых фич и что тогда делать и как долго? Собираем из исходников и софт и все зависимости изолированно от всего остального в отдельной директории, точнее ложим этот весь процесс в шел скрипт и вместе с исходниками в git/mercurial, туда же и скрипт деплоя на все машины - теперь мы можем и легко обновлять, никого не задевая, и легко менять и легко откатываться, и не зависеть от системы пакетов. Это проще, никак не ограничивает и времени почти не занимает.

 

 

В этом случае проще слинковать библиотеку статически.

 

 

 

и обновляться можно хоть после каждого коммита

Ну вот пример, есть библиотека в новой версии которой обновили API немного и часть софта с ней не может работать без модификаций, а части нужна новая версия как раз из-за новых фич и что тогда делать и как долго? Собираем из исходников и софт и все зависимости изолированно от всего остального в отдельной директории, точнее ложим этот весь процесс в шел скрипт и вместе с исходниками в git/mercurial, туда же и скрипт деплоя на все машины - теперь мы можем и легко обновлять, никого не задевая, и легко менять и легко откатываться, и не зависеть от системы пакетов. Это проще, никак не ограничивает и времени почти не занимает.

 

 

Ну и держать несколько версий библиотеки никто не запрещает, на самом деле. Для этого после .so идут циферки, обозначающие версию ABI.

[ttttt 195]

 

В этом случае проще слинковать библиотеку статически.

Нет, это не проще и настолько не проще, что нет смысла даже пытаться. Нужно чтобы все библиотеки изначально были созданы для статической линковки, как в golang, тогда это проще. 

 

 

Ну и держать несколько версий библиотеки никто не запрещает, на самом деле. Для этого после .so идут циферки, обозначающие версию ABI.

Ну да и как это поможет сэкономить время? 

Да и не весь софт компилируемый и библиотеки почти всегда используют другие библиотеки. Т.е. нужно целые иерархии разных версий как-то держать в этом случае. Нереально.

[madf 279]

 

 

В этом случае проще слинковать библиотеку статически.

Нужно чтобы все библиотеки изначально были созданы для статической линковки, как в golang, тогда это проще.

 

 

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

 

 

Ну и держать несколько версий библиотеки никто не запрещает, на самом деле. Для этого после .so идут циферки, обозначающие версию ABI.

Ну да и как это поможет сэкономить время? 

Да и не весь софт компилируемый и библиотеки почти всегда используют другие библиотеки. Т.е. нужно целые иерархии разных версий как-то держать в этом случае. Нереально.

 

 

Обычно изменение версии библиотеки очень редко требует обновления ее зависимостей.

 

Может давайте перейдем к конкретным примерам?

[ttttt 195]

 

Может давайте перейдем к конкретным примерам?

Та зачем. Вы фокусируетесь на вещах, которые отнимают относительно много времени. А я нет, мне время самое главное, т.е. чтобы можно было пересобрать что-то новой версии или с другой библиотекой/модулем на всех машинах, и линуксах и бсд, ничего не задеть, и чтобы это происходило "по нажатию кнопки" и также "по кнопке" можно было вернуть предыдущую сборку, и чтобы хотя бы правильность конфига проверялась перед деплоем. 

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

 

 

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

Ну да и что с того? Как это мне сэкономит время? Что проще, LD_LIBRARY_PATH к бинарнику добавить или патчить все, чтобы собирать статически?

[madf 279]

 

 

Может давайте перейдем к конкретным примерам?

Та зачем. Вы фокусируетесь на вещах, которые отнимают относительно много времени. А я нет, мне время самое главное, т.е. чтобы можно было пересобрать что-то новой версии или с другой библиотекой/модулем на всех машинах, и линуксах и бсд, ничего не задеть, и чтобы это происходило "по нажатию кнопки" и также "по кнопке" можно было вернуть предыдущую сборку, и чтобы хотя бы правильность конфига проверялась перед деплоем. 

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

 

 

Эти вещи при правильной организации не отнимают времени. И они позволяют содержать ОС "в чистоте". Когда нужно будет создать копию машины - не придется думать о том что, где и как собрано.

 

 

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

Ну да и что с того? Как это мне сэкономит время? Что проще, LD_LIBRARY_PATH к бинарнику добавить или патчить все, чтобы собирать статически?

 

 

В качестве временного решения это работает. Но когда нужно будет передать работу коллеге это уже не работает. Потому что половину того, что и кому нужно прописать в LD_LIBRARY_PATH вы к тому моменту забудете. Запуск сервера не должен превращаться в чехарду с компилированием и подсовыванием нужных библиотек. Софт должен ставиться штатными средствами из официальных репозиториев или репозиториев предприятия. В софте надо соблюдать порядок.

Пока все держится на make install и LD_LIBRARY_PATH - вы незаменимый человек, а это плохо как для вас так и для предприятия.

[prototip 284]

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

[ttttt 195]

 

В качестве временного решения это работает. Но когда нужно будет передать работу коллеге это уже не работает. Потому что половину того, что и кому нужно прописать в LD_LIBRARY_PATH вы к тому моменту забудете. Запуск сервера не должен превращаться в чехарду с компилированием и подсовыванием нужных библиотек. Софт должен ставиться штатными средствами из официальных репозиториев или репозиториев предприятия. В софте надо соблюдать порядок.

Пока все держится на make install и LD_LIBRARY_PATH - вы незаменимый человек, а это плохо как для вас так и для предприятия.

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

[ttttt 195]

 

 Софт должен ставиться штатными средствами из официальных репозиториев или репозиториев предприятия. 

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

[madf 279]

 

 

В качестве временного решения это работает. Но когда нужно будет передать работу коллеге это уже не работает. Потому что половину того, что и кому нужно прописать в LD_LIBRARY_PATH вы к тому моменту забудете. Запуск сервера не должен превращаться в чехарду с компилированием и подсовыванием нужных библиотек. Софт должен ставиться штатными средствами из официальных репозиториев или репозиториев предприятия. В софте надо соблюдать порядок.

Пока все держится на make install и LD_LIBRARY_PATH - вы незаменимый человек, а это плохо как для вас так и для предприятия.

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

 

 

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

[madf 279]

 

 

Софт должен ставиться штатными средствами из официальных репозиториев или репозиториев предприятия.

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

 

 

Я не хочу больше спорить. По видимому это проблема из разряда тех, что пока сам по граблям не потопчешься — не видишь ни проблемы ни граблей. Я сам этим страдал всего полтора года и больше не занимаюсь. А говорить от имени человека который занимается этим „в промышленных масштабах“ я не буду. Захочет — сам расскажет. Хочу только сказать что прямо сейчас я наблюдаю результаты предлагаемого вами подхода со стороны пользователя сервера, и они плачевны. Куча софта растыкана по отдельным каталогам, что где лежит непонятно, что от кого зависит и как его запускать — тем более. В результате миграция на новый сервер с переменным успехом тянется уже с месяц.

[ttttt 195]

 

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

У меня миграция и вообще ввод нового сервера меньше чем за пол часа, после получения доступа. Потому что досаточно только добавить его в конфиг, добавить ключи в ssh и запустить скрипты деплоя нужного софта. Я забыл выше об этом сказать, что это тоже одно из самого главного. Видимо поэтому не поняли сути. Основная суть - ничего не делать руками. Вот, например, бинд: есть скрипт для сборки, для запуска, дла остановки, для проверки конфига и переконфигурирования и скрипт для деплоя на все машины. Если мне надо запустить его на новой машине, я просто добавлю машину в конфиг подобный rc.conf, закоментирую остальные машины и запущу деплой. Через пару минут я получу рабочий бинд с точно таким же конфигом и зонами, как на всех других машинах. Этот же скрипт деплоя может не пересобирать бинд, а только перегенеривать конфиг и зоны. Так же для всего остального софта и он весь очень аккуратненько разложен по директориям в одном месте, откуда на все машины и деплоится хоть по сто раз в день.

 

 

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

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

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

[bondarchuk 2]

обновили до BIND 9.7.3

 

подняли историю, на аналогичном сервере, но собранным более позже (уже с 9.7.3) bind не падал ни разу