The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

OpenNews: Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО, opennews (?), 24-Июн-08, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


5. "Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"  +/
Сообщение от Дмитрий Ю. Карпов (?), 24-Июн-08, 17:20 
Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии, мир скоро перейдёт на FreeBSD.
Ответить | Правка | Наверх | Cообщить модератору

6. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от Аноним (18), 24-Июн-08, 17:24 
>мир скоро перейдёт на FreeBSD.

Не перейдёт, потому что есть ArchLinux, вобравший в себя самые лучшие особенности FreeBSD

Ответить | Правка | Наверх | Cообщить модератору

55. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от tux2002email (?), 25-Июн-08, 08:42 
>>мир скоро перейдёт на FreeBSD.
>
>Не перейдёт, потому что есть ArchLinux, вобравший в себя самые лучшие особенности
>FreeBSD

Slackware тоже нормально.

Ответить | Правка | Наверх | Cообщить модератору

8. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от Аноним (-), 24-Июн-08, 17:27 
ИМХО там совсем нет системы этих самых пакаджей. Есть система портов, а это вовсе не одно и то же.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

13. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от anonymous (??), 24-Июн-08, 17:42 
Давно портировали, Gentoo называется. И удаление неиспользуемых пакетов работает.
Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

21. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от .3 (?), 24-Июн-08, 19:35 
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии,
>мир скоро перейдёт на FreeBSD.

Ничего хуже системы портов FreeBSD я не знаю. Простая задача: есть самописная софтина, она зависит, ну, например, от стандартного sqlite (не важно). Расскажите, как же мне поставить мою софтину хотя бы на 20 серверов.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

28. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от Guest (??), 24-Июн-08, 22:17 
Пожалуйста, 7 строчек.

PORTNAME=       myprog
PORTVERSION=    1.0
CATEGORIES=     devel
MASTER_SITES=   ftp://local_ftp/

LIB_DEPENDS=    sqlite3.8:${PORTSDIR}/databases/sqlite3

PLIST_FILES=    myprog

.include <bsd.port.mk>

потом touch pkg_descr && make makesum и дальше как угодно
- можно добавить в дерево портов, расшаренное по NFS / в локальное зеркало дерева портов и ставить через for server in "a b c d"; do ssh server "cd /usr/ports/devel/myprog && screen -d -m make install clean"; done
- можно сделать package и сделать то же самое, только с pkg_add -r

Для деплоя как раз лучше портов ничего не придумали.

Ответить | Правка | Наверх | Cообщить модератору

33. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от .3 (?), 24-Июн-08, 22:40 
А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)? И я еще молчу про то, что библиотеки изредка меняются в пределах одной major.minor версии. И проверить это можно только с помощью getosreldate (здравствуй, статическая линковка!).

Собирать на продакшен машинах, конечно, смешная идея, но в некоторых случаях это возможно. Но то, что это будет проходить под рутом (да, я знаю про fakeroot), уже нехорошо.

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

Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. Но сейчас остальные системы куда совершенее.

Ответить | Правка | Наверх | Cообщить модератору

42. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от Guest (??), 25-Июн-08, 01:05 
> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)?

Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?

> Собирать на продакшен машинах, конечно, смешная идея

Ничего смешного. Там что, компилятора нет? Или может процессор 486?

> но в некоторых случаях это возможно. Но то, что это будет проходить под рутом (да, я знаю про fakeroot), уже нехорошо.

А вам что там, надо неизвестно чей софт собирать? Тогда пакаджи, все абсолютно аналогично портам.

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

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

> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом. Но сейчас остальные системы куда совершенее.

Да что вы?

Ответить | Правка | Наверх | Cообщить модератору

46. "*sigh*"  +/
Сообщение от Michael Shigorinemail (ok), 25-Июн-08, 02:11 
Нет, ну это просто феерическое нечто.

>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты
>> (и их синхронизировать каждый день)?
>Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?

Вы всерьёз предлагаете каждый раз собирать?  Никогда не слышали про "воспроизводимость сборки" случайно?  Что вообще-то код, собранный на одной машине -- может работать на тысячах совершенно других и при этом отладка стека ПО на любой физически исправной из них будет эквивалентна, а не уникальна по надцати параметрам?

>> Собирать на продакшен машинах, конечно, смешная идея
>Ничего смешного. Там что, компилятора нет? Или может процессор 486?

Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?  Может, ещё самолёты в рейсе модернизировать?

>Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы.

Телепатов у вас там явно нет вообще, так что не надо про отпуск.  Гадать тоже не умеете: где продакшен, там очень сильно помогает от головной боли воспроизводимость.  А с source-based это свойство не дружит, только с package-based при условии наличия сборочной технологии, включающей создание изолированной воспроизводимой среды сборки и возможности фиксации состояния пакетной базы для этой самой воспроизводимости.

>Собирается долго - ставьте кластер и собирайте на нем.

Под рукой есть три кластера, а вот идиотов, чтобы "собирать на нём" (для чего -- для каждой ноды?  или сэр даже слышал про distcc?) -- пока не нашлось.

Так что совет того, бесплатный.

>> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом.
>> Но сейчас остальные системы куда совершенее.
>Да что вы?

Выдыхай, бобёр.  Выдыхай.  Только осторожно, скрытая камера фиксирует для истории.

Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.

Ответить | Правка | Наверх | Cообщить модератору

51. "*sigh*"  +/
Сообщение от oops (?), 25-Июн-08, 06:54 
>[оверквотинг удален]
>
>>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты
>>> (и их синхронизировать каждый день)?
>>Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?
>
>Вы всерьёз предлагаете каждый раз собирать?  Никогда не слышали про "воспроизводимость
>сборки" случайно?  Что вообще-то код, собранный на одной машине --
>может работать на тысячах совершенно других и при этом отладка стека
>ПО на любой физически исправной из них будет эквивалентна, а не
>уникальна по надцати параметрам?

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

>>> Собирать на продакшен машинах, конечно, смешная идея
>>Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?  Может,
>ещё самолёты в рейсе модернизировать?

Вы давно видели фряху? Там компилятор идет из коробки и всегда присутствует в системе.

>>Телепаты в отпуске, угадывать какие у вас там продакшны и какие программы.
>Телепатов у вас там явно нет вообще, так что не надо про
>отпуск.  Гадать тоже не умеете: где продакшен, там очень сильно
>помогает от головной боли воспроизводимость.  А с source-based это свойство
>не дружит, только с package-based при условии наличия сборочной технологии, включающей
>создание изолированной воспроизводимой среды сборки и возможности фиксации состояния пакетной базы
>для этой самой воспроизводимости.

Фиксируйте на здоровье. Поставьте машинку для этих целей или jail поднимите. Там хоть зафиксируйтесь. Создать собственный пакетный репозиторий времени занимает не так много, и делается один раз.

>>Собирается долго - ставьте кластер и собирайте на нем.
>Под рукой есть три кластера, а вот идиотов, чтобы "собирать на нём"
>(для чего -- для каждой ноды?  или сэр даже слышал
>про distcc?) -- пока не нашлось.

без комментариев.

>Так что совет того, бесплатный.
>>> Порты фри были хороши когда их придумали. Они были не так плохи в 2002--ом.
>>> Но сейчас остальные системы куда совершенее.
>>Да что вы?
>Выдыхай, бобёр.  Выдыхай.  Только осторожно, скрытая камера фиксирует для истории.
>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.

Отложите и подумайте где вы не правы.

Ответить | Правка | Наверх | Cообщить модератору

80. "*sigh*"  +/
Сообщение от Michael Shigorinemail (ok), 26-Июн-08, 02:15 
>>>> Собирать на продакшен машинах, конечно, смешная идея
>>>Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?  Может,
>>ещё самолёты в рейсе модернизировать?
>Вы давно видели фряху?

Недавно последнюю четвёрку хоронил, где был логин, а что?

>Там компилятор идет из коробки и всегда присутствует в системе.

То-то и оно.  Могу ещё раз повторить своё утверждение:
"Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?"

Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем компилятор в basesystem -- чуть выше повторялся про бранчи портов.

>Поставьте машинку для этих целей или jail поднимите.

Спасибо, я вчера походя склонировал два и перенёс ещё два контейнера (на поднятые в т.ч. для них машинки).

>Создать собственный пакетный репозиторий времени занимает не так много,
>и делается один раз.

Репозитории... "дежурные" генерируются инструментарием после каждой успешной сборки (их бывает и десяток пакетов в день), руками genbasedir тоже порой делаю.

Давайте лучше соглашусь с этими Вашими словами, чем буду развивать тему про репо? :)
> За сборку и тесты на продакшне надо отрывать руки.
> За апгрейд без обкатки на тестовой машине - голову.

Только вот ведь какая штука -- инструментально очерченный процесс гораздо более проработан на пакетных линуксах.  Бишь вероятность ошибиться неочевидным образом на порядки меньше.

>>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.
>Отложите и подумайте где вы не правы.

Это было сделано в процессе перечитывания перед отправкой.
Как видите, и то отправил, и это.

Поясните?

Ответить | Правка | Наверх | Cообщить модератору

84. "*sigh*"  +/
Сообщение от oops (?), 26-Июн-08, 06:41 
>>Вы давно видели фряху?
>Недавно последнюю четвёрку хоронил, где был логин, а что?

Значит давно.

>>Там компилятор идет из коробки и всегда присутствует в системе.
>То-то и оно.  Могу ещё раз повторить своё утверждение:
>"Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?"

Вам компилятор жить мешает? Ну так на то и source based система,
порты без компилятора как-то.. сами понимаете. Напомню, что порты являются основным
средством установки софта.

>Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем
>компилятор в basesystem -- чуть выше повторялся про бранчи портов.

тогда рекомендую заглянуть в них на досуге и увидеть например вот это:
databases/mysql41-client
databases/mysql41-scripts
databases/mysql41-server
databases/mysql50-client
databases/mysql50-scripts
databases/mysql50-server
databases/mysql51-client
databases/mysql51-scripts
databases/mysql51-server
вы всерьез полагаете что там нужны бранчи?

>>Поставьте машинку для этих целей или jail поднимите.
>Спасибо, я вчера походя склонировал два и перенёс ещё два контейнера (на
>поднятые в т.ч. для них машинки).

Согласен, это проще.

>Репозитории... "дежурные" генерируются инструментарием после каждой успешной сборки (их бывает и десяток пакетов в день), руками genbasedir тоже порой делаю.

И этот десяток прямо-таки необходим в продакшне, и каждый день? Не смешите.

>Давайте лучше соглашусь с этими Вашими словами, чем буду развивать тему про
>репо? :)

pkg_create -b и получаем готовый репозиторий со свежепоставленной машины.
или make package в портах.

>Только вот ведь какая штука -- инструментально очерченный процесс гораздо более проработан
>на пакетных линуксах.

Не совсем понимаю о каком процессе идет речь.

>Бишь вероятность ошибиться неочевидным образом на порядки
>меньше.

Как это отменяет сборку и тестирование на отдельном железе?

>>>Я вот этот образчик так отложу себе в тематическую коллекцию шедевров.
>>Отложите и подумайте где вы не правы.
>Это было сделано в процессе перечитывания перед отправкой.
>Как видите, и то отправил, и это. Поясните?

Из вашего первого утверждения про снесенную четверку я могу предположить, что вы обсуждаете ось которую можно сказать в глаза не видели. Поэтому подобное высказывание: "фрю к продакшен-системам не отношу по ещё более веским причинам, чем компилятор в basesystem" я склонен не воспринимать всерьез. По своему опыту могу сказать, что люди плюются на фряху больше потому, что она "не как linux", часто не понимая как она живет в реальных условиях и что с ней делать. Я вижу это каждый день.

Ответить | Правка | Наверх | Cообщить модератору

86. "*sigh*"  +/
Сообщение от pavel_simple (??), 26-Июн-08, 08:20 
> Я вижу это каждый
>день.

я вот, до недавнего времени, как и Вы видел это каждый день
и знаете -- мне очень надоело... и я таки закончил миграцию с фряхи.

P.S. И Вы не поверите.... -- "всё правильно сделал!" (C) Какая-то там страховая компания.

Ответить | Правка | Наверх | Cообщить модератору

91. "*sigh*"  +/
Сообщение от Michael Shigorinemail (ok), 26-Июн-08, 16:57 
>>>Вы давно видели фряху?
>>Недавно последнюю четвёрку хоронил, где был логин, а что?
>Значит давно.

К сожалению, в контексте обсуждаемого вопроса та поросшая мхом немигрируемая 4.10 -- это тоже "недавно".

>>Вы всерьёз о компиляторе на продакшене, который не сборочный сервер?
>Вам компилятор жить мешает?

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

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

>Ну так на то и source based система, порты без компилятора как-то.. сами понимаете.
>Напомню, что порты являются основным средством установки софта.

Ну так я и поясняю, куда идёт source based и порты в частности -- лесом.  Если головняка с поддержкой хочется поменьше, конечно.

>>Впрочем, фрю к продакшен-системам не отношу по ещё более веским причинам, чем
>>компилятор в basesystem -- чуть выше повторялся про бранчи портов.
>тогда рекомендую заглянуть в них на досуге и увидеть например вот это:
>вы всерьез полагаете что там нужны бранчи?

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

В качестве нечастой, но яркой иллюстрации -- вспомните, когда последний раз в apache-2.0 одновременно починили дырень и сломали API, а mod_perl2 не успел ещё обновиться.

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

>>Репозитории... "дежурные" генерируются инструментарием после каждой успешной сборки
>>(их бывает и десяток пакетов в день), руками genbasedir тоже порой делаю.
>И этот десяток прямо-таки необходим в продакшне, и каждый день? Не смешите.

Зависит.

Просто немного тут участвую в разработке ALT Linux, соответственно минимум три активных репозитория есть практически всегда (current, stable и oldstable), а обычно есть ещё несколько тематических -- например, обновлённые пакеты с LTSP5 и настраивалками, репо с которыми подключается при сборке инсталяционного исошника терминального сервера.

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

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

Если интересно -- можете глянуть пример здесь:
http://lists.altlinux.org/pipermail/sisyphus-cybertalk/2008-...
(download неинтересно, а вот unmets и bad_elf_symbols бывают крайне полезны)

Это пакет qa-robot (http://sisyphus.ru/srpm/qa-robot).  Опирается на apt (работа с репозиторием), который, в свою очередь, у нас опирается на rpm (работа с зависимостями конкретных пакетов).

>>Бишь вероятность ошибиться неочевидным образом на порядки меньше.
>Как это отменяет сборку и тестирование на отдельном железе?

Никак не отменяет.  То, что порой бывает удобней собирать в контейнере (или на кластере :), а тестировать в qemu -- непринципиальные детали.

Кстати, сборка тут и происходит в сборочных контейнерах :)  Начиная с 32/64-битного current (aka Sisyphus).

>>>Отложите и подумайте где вы не правы.
>>Поясните?
>Из вашего первого утверждения про снесенную четверку я могу предположить,
>что вы обсуждаете ось которую можно сказать в глаза не видели.

Ну как Вам сказать.  Если с 2.2.7 (или 2.2.8?) через 3.4 (или 3.5, что ли) и до 4.10 (или всё-таки 4.11?) нынче считается "в глаза не видел" -- ну ква.

То, что ситуация по конкретно этому вопросу остаётся брежней -- мне и так есть у кого выяснить из тех, чьему мнению и опыту в нём я доверяю (например, netch@).

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

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

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

>Поэтому подобное высказывание: "фрю к продакшен-системам не отношу по ещё более
>веским причинам, чем компилятор в basesystem" я склонен не воспринимать всерьез.

Да пожалуйста :-)

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

Это чуть другой момент, хотя и примерно двоюродный.

Я прекрасно понимаю, что фря -- не линукс (и несколько понимаю, почему).

А собсно говорю как раз о том, что у линуксов получается на эпоху лучше -- управление установленным программным обеспечением.

Хотите -- спорьте, хотите -- попробуйте посмотреть под другим углом, нежели
"в source-based"...

Спорить с умными людьми полезно тем, что узнаёшь что-то новое и излагая то, что знаешь -- находишь в нём неожиданные грани.

Потому на это время и находится порой. :-)

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

75. "*sigh*"  +/
Сообщение от Guest (??), 25-Июн-08, 20:27 
Три кластера под рукой.. Почему сразу не десять?

Боже, даже комментировать не хочу. Дешевый непрофессиональный троллинг.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

81. "*sigh*"  +/
Сообщение от Michael Shigorinemail (ok), 26-Июн-08, 02:25 
>Три кластера под рукой.. Почему сразу не десять?

Потому что СКИТ-1, СКИТ-2, СКИТ-3 -- это три кластера, а не десять.  На КПИ-шный не ходок.

>Боже, даже комментировать не хочу. Дешевый непрофессиональный троллинг.

Ну так и не занимайтесь им, или тоже квалифицируйтесь на нормального тролля :-)

http://icybcluster.org.ua/

[XXXX@ZZZZ ~]$ squeue | awk '{print $2;}' | sort -u
PARTITION
scit1
scit2
scit3

На scit3 вон коллега данные для автоматического переводчика обрабатывает :-)

$ squeue | grep pere | wc -l          
15

60 ядер и 120Gb RAM куда быстрей приводят к появлению и улучшению языковых пар, чем домашняя машинка...

Ответить | Правка | Наверх | Cообщить модератору

60. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от .3 (?), 25-Июн-08, 10:38 
>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)?
> Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?

А pkg_add -r уже научился ходить по разным серверам?

>> Собирать на продакшен машинах, конечно, смешная идея
> Ничего смешного. Там что, компилятора нет? Или может процессор 486?

А то, что машина может быть загружена своей основной работой --- это ничего? После сборки надо прогнать тесты, или где--то не так? У тестов (да и у сборки) может быть еще одна большая куча зависимостей. И ее тоже надо будет поставить на продакшен. И следить за версиями.  

И, прошу обратить внимание, не надо быть телепатом, что бы это знать.

> Собирается долго - ставьте кластер и собирайте на нем.

Если собирать на кластере, то, наверное потом это надо будет принести с кластера, или во фре уже есть libastral?

Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

61. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от Осторожный (?), 25-Июн-08, 10:55 
>>> А ничего, что в случае pkg_add -r мне надо хранить ВСЕ стандартные пакеты (и их синхронизировать каждый день)?
>> Какие пакеты? Зачем хранить? Куда синхронизировать? Что за бред?
>
>А pkg_add -r уже научился ходить по разным серверам?

Вообще-то всегда умел :)

export PACKAGEROOT=ftp://myserver-with-ports.mydomain.ru

pkg_add -r gdbm perl && pkg_add -r bash && pkg_add -r sudo && \
pkg_add -r aspell joe && pkg_add -r lynx && pkg_add -r mc && \
pkg_add -r portaudit

Ответить | Правка | Наверх | Cообщить модератору

66. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от .3 (?), 25-Июн-08, 11:44 
>[оверквотинг удален]
>
>Вообще-то всегда умел :)
>
>export PACKAGEROOT=ftp://myserver-with-ports.mydomain.ru
>
>pkg_add -r gdbm perl && pkg_add -r bash && pkg_add -r sudo
>&& \
>pkg_add -r aspell joe && pkg_add -r lynx && pkg_add -r mc
>&& \
>pkg_add -r portaudit

Я тут вижу только один сервер.

Ответить | Правка | Наверх | Cообщить модератору

62. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от Осторожный (?), 25-Июн-08, 10:59 
>>> Собирать на продакшен машинах, конечно, смешная идея
>> Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>
>А то, что машина может быть загружена своей основной работой --- это
>ничего? После сборки надо прогнать тесты, или где--то не так? У
>тестов (да и у сборки) может быть еще одна большая куча
>зависимостей. И ее тоже надо будет поставить на продакшен. И следить
>за версиями.

1) Выделяется отдельный сервер
2) На нем синхронизуются порты
3) Делается сборка нужных портов с помощью portupgrade
   Включая свою софтину
4) На этом же сервере можно делать тесты
5) Когда убедились что все работает, тогда ставим на production
   Хотя вообще по-хорошему тесты надо делать еще когда пишется софтина :)
   mount /usr/ports
   portupgrade -aPPR my_program
   umount /usr/ports

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

73. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от .3 (?), 25-Июн-08, 14:18 
> Хотя вообще по-хорошему тесты надо делать еще когда пишется софтина :)

На некоторые тесты уходят часы.

>   mount /usr/ports
>   portupgrade -aPPR my_program
>   umount /usr/ports

Не правда ли проще подключить репозаторий, а потом сказать apt-get/yum?

Ответить | Правка | Наверх | Cообщить модератору

71. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от oops (?), 25-Июн-08, 13:28 
>>> Собирать на продакшен машинах, конечно, смешная идея
>> Ничего смешного. Там что, компилятора нет? Или может процессор 486?
>А то, что машина может быть загружена своей основной работой --- это
>ничего? После сборки надо прогнать тесты, или где--то не так? У
>тестов (да и у сборки) может быть еще одна большая куча
>зависимостей. И ее тоже надо будет поставить на продакшен. И следить
>за версиями.
>И, прошу обратить внимание, не надо быть телепатом, что бы это знать.

За сборку и тесты на продакшне надо отрывать руки.
За апгрейд без обкатки на тестовой машине - голову.


Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

72. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от .3 (?), 25-Июн-08, 14:11 
>За сборку и тесты на продакшне надо отрывать руки.
>За апгрейд без обкатки на тестовой машине - голову.

Мне это говорить не надо. Говорите это Guest'у, который не видит в этом ничего странного.

Ответить | Правка | Наверх | Cообщить модератору

76. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от Guest (??), 25-Июн-08, 20:29 
> Говорите это Guest'у, который не видит в этом ничего странного.

Из каких же моих слов вы сделали такой вывод?

Ответить | Правка | Наверх | Cообщить модератору

77. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от .3 (?), 26-Июн-08, 00:25 
>> Говорите это Guest'у, который не видит в этом ничего странного.
>
>Из каких же моих слов вы сделали такой вывод?

Сообщение #42, цитата:
> Собирать на продакшен машинах, конечно, смешная идея

Ничего смешного. Там что, компилятора нет? Или может процессор 486?

Ответить | Правка | Наверх | Cообщить модератору

78. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от fi (ok), 26-Июн-08, 00:37 
> За сборку и тесты на продакшне надо отрывать руки.
> За апгрейд без обкатки на тестовой машине - голову.

Этого мало!!! Лучше начинать с яиц -  безболезненней будет

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

PS за что и признаны пакетные системы - софт уже идет протестенный. что конечно не отменяет обкатки.

Ответить | Правка | К родителю #71 | Наверх | Cообщить модератору

92. "gcc  wget"  +/
Сообщение от Michael Shigorinemail (ok), 26-Июн-08, 17:18 
>Да и сам компилятор лучше удалить с продакшин - большенство локальных уязвимостей
>требуют его.

Вообще-то нет (и по словам опять же людей, которым склонен верить -- сейчас в основном молодёжь со своими бинарниками шарится), но рассматривание ряда .bash_history наводит на мысль, что мера предосторожности всё равно не лишняя.

Особенно если libc и ядро -- не точь-в-точь убунто-редхатовские, а немного специфичны ;-)

BTW дочитавшим досюда маленький бонус: http://sisyphus.ru/srpm/apache-honeypot

Ответить | Правка | Наверх | Cообщить модератору

22. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от kostbebixemail (?), 24-Июн-08, 20:20 
Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог строчкой) - установило, сиди и пили сколько угодно дальше, потом еще пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то фигня с сэндмэйлом, которая так и не заработала (лень разбираться).

Попробовал на Gentoo. Тоже. Из портов сначала не собралось, потом где-то чего-то подпилили, собралось. Пилил пилил - та же фигня что и во фре с сэндмэйлом. Снова лень разбираться (в генте тоже никогда ничего не делал, да и сервак не мой, экспериментировать сильно не хотел).

Ради чистоты эксперимента попробовал у себя под федорой.
yum -y install bugzilla
а далее - создать пользователя bugs и запустить скрипт багзилловский.


Сорри что много текста лишнего, просто наболело. Я к чему это все - в портах минус: не всегда оно собирается, надо чего-то делать еще. В rpm и deb'ах все куда вероятнее что заработает с полупинка (по крайней мере у меня так).

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

52. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от oops (?), 25-Июн-08, 06:58 
>Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На
>сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог
>строчкой) - установило, сиди и пили сколько угодно дальше, потом еще
>пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то
>фигня с сэндмэйлом, которая так и не заработала (лень разбираться).

pkg_add -r <pkgname> или portupgrade -PP <origin>
с сэндмейлом надо понимать на месте. или отключить его и поставить MTA который вы знаете.

Ответить | Правка | Наверх | Cообщить модератору

63. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от kostbebixemail (?), 25-Июн-08, 11:25 
>>Кхм кхм. Совершенно недавно на работе я таки добился установки bugzilla. На
>>сервак с freebsd - пишу фигню с портом (спасибо сисадмину, помог
>>строчкой) - установило, сиди и пили сколько угодно дальше, потом еще
>>пилил... Установил. Почти. Заняло ~2 часа, должно работать, но там какая-то
>>фигня с сэндмэйлом, которая так и не заработала (лень разбираться).
>
>pkg_add -r <pkgname> или portupgrade -PP <origin>
>с сэндмейлом надо понимать на месте. или отключить его и поставить MTA
>который вы знаете.

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

чтоб проинсталлировать пхп надо сделать
yum install php

Чтобы подключить поддержку mysql не надо ничего пересобирать или еще чего. Достаточно сделать
yum install php-mysql

Так же и с перлом и остальными.

Ответить | Правка | Наверх | Cообщить модератору

68. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от oops (?), 25-Июн-08, 13:07 
>Ну там основное время ушло на сборку модулей перла (руками надо было
>каждую прописывать, а потом, по идее, отвечать на кучу вопросов, но
>я делал yes2all, и все равно не все установилось).

Случайно не через cpan ставились?

>Чтобы подключить поддержку mysql не надо ничего пересобирать или еще чего. Достаточно
>сделать
>yum install php-mysql
>
>Так же и с перлом и остальными.

Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно бинарный пакет безо всяких пересборок и приплясываний..

Ответить | Правка | Наверх | Cообщить модератору

87. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от kostbebixemail (?), 26-Июн-08, 11:07 
>Случайно не через cpan ставились?

Да, он.

>Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно
>бинарный пакет безо всяких пересборок и приплясываний..

Типа установлен php, не надо его пересобирать с флагом --with-gd (к примеру), а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r php-gd2? (чисто интуитивно)

Ответить | Правка | Наверх | Cообщить модератору

89. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от oops (?), 26-Июн-08, 13:27 
>>Случайно не через cpan ставились?
>Да, он.

тогда получаете кучу вопросов и не факт что соберется. ставьте портом.

>>Чем это сложнее pkg_add -r или portupgrade -PP? оба варианта поставят исключительно
>>бинарный пакет безо всяких пересборок и приплясываний..
>
>Типа установлен php, не надо его пересобирать с флагом --with-gd (к примеру),
>а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r
>php-gd2? (чисто интуитивно)

portupgrade -PP graphics/php5-gd (или graphics/php4-gd)
Для pkg_add нужно знать точное имя пакета. можно посмотреть в порту.

Ответить | Правка | Наверх | Cообщить модератору

90. "Решит ли?! :-D"  +/
Сообщение от Andrey Mitrofanov (?), 26-Июн-08, 13:31 
>>а можно сделать что-то вроде yum install php-gd2? типа pkg_add -r
>>php-gd2? (чисто интуитивно)
>portupgrade -PP graphics/php5-gd (или graphics/php4-gd)
>Для pkg_add нужно знать точное имя пакета. можно посмотреть в порту.

...что снова возвращает нас к вопросу, "Решит ли возрождение проекта Berlin API проблемы с инсталляцией ПО"?? :-))))

Ответить | Правка | Наверх | Cообщить модератору

35. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от Guest (??), 24-Июн-08, 22:47 
> Мне кажется весьма удобной система пакаджей во FreeBSD

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

> пора бы портировать её в Linux

Гентушный portage в некотором смысле аналог, хотя у него есть смои большие плюсы и большие минусы
pkgsrc можно использовать вообще почти везде, от linux до solaris, он к портам гораздо ближе.

Вообще дело не в этом. Дело в том имхо, что любая система пакетов должна основываться на исходниках, но при этом уметь порождать самодостаточные бинарные пакеты. Это значит, что не maintainer'ы не собирают пакеты как хотят, а пишут инструкцию, как пакет собрать (аналог порта FreeBSD или ebuild'а), после чего добавляют ее в репозиторий. Заодно могут залить и сам пакет, по ней собранный.

Итого: имеем все плюсы source-based систем. Автоматизированная проверка и сборка подо все архитектуры, возможность быстро обновить порт до новой версии (просто взяв существующий и изменив циферку) и т.д. В то же время из этого должны получаться пакеты, которые как минимум знают, с какими версиями зависимых пакетов они могут работать. FreeBSD'шные пакаджи, например, не знают. Будут писать ворнинги, если версии не совпадают, и если, например, shared lib версия поменялась или еще какой косяк, ничего сделать не cмогут.
Ну и системная библиотека для управления этим всем, чтобы любой пакет можно было установить одной командой, причем установка из исходников/бинарников меняется одним ключиком.

Короче, потенциально есть куда развиваться всем существующим пакетным менеджерам, но то, что `Установка ПО в Linux - задача достаточно сложная', и идеи о новом API, основанном на D-BUS (!!!) и XML - такой концентрированный параноидальный бред, что мне даже страшно.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

45. "какие пакаджи..."  +/
Сообщение от Michael Shigorinemail (ok), 25-Июн-08, 02:00 
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux.

Дмитрий, от Вас не ожидал.

Во-первых, пакетные системы в линуксах -- как минимум apt -- на порядок более развиты, чем зачаточная пакетная система FreeBSD.  Можете поискать да хотя бы и в архивах r.o.c разборы полётов :-)

Во-вторых, _портаджи_ в Gentoo и ряде подобных дистров тоже есть и несмотря на улучшения относительно портов FreeBSD -- продолжают иметь ряд принципиальных и архитектурных проблем оригинала (например, отсутствие бранчей по версиям поддерживаемых дистрибутивов, когда желательно поддерживать их в режиме минимальных изменений).

В-третьих, порты даже в той же NetBSD по последнему пункту сделаны куда грамотней, чем во фряке.

Когда кажется -- креститься пора :-)

>Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии,
>мир скоро перейдёт на FreeBSD.

Бздюшники пытались жёстко гнобить тех, кто нарушил даже не текст их лицензии, а то, что они себе возомнили.  Всё равно за бортом.

Впрочем, не верьте мне на слово -- просто смотрите внимательно сами.

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

50. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от oops (?), 25-Июн-08, 06:41 
>Мне кажется весьма удобной система пакаджей во FreeBSD - пора бы портировать
>её в Linux. Впрочем, если линуксоиды будут жестоко преследовать нарушителей GPL-лицензии,
>мир скоро перейдёт на FreeBSD.

Система пакаджей во фряхе довольно убога:
1. Пакетная база - набор каталогов с информацией о структуре и содержимом пакета. На большом количестве установленного софта начинаются заметные тормоза, так как упираемся в дисковую подсистему.
2. Жесткие зависимости. т.е. при обновлении пакета на который ссылается другой пакет получаем битую зависимость.
3. Отсутствие апгрейда как такового.

Система портов тоже не без недостатков. В частности:
1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться скажем именно с апачем версии 2.0 и с нужными опциями, которые не всегда можно получить по make config(но присутствуют в Makefile порта).
2. Зачастую невозможно собрать два пакета с разными опциями с одного порта и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее всего совпадут. Бывают правда и исключения например для опции WITH_THREADS.
3. Апгрейд никакой.

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

Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

53. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от oops (?), 25-Июн-08, 07:04 
Из плюсов могу отметить гибкость портовой системы и _предсказуемость_ поведения как портов так и пакетов. Для админа эти плюсы легко перевешивают все минусы перечисленные выше.
Ответить | Правка | Наверх | Cообщить модератору

64. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от Осторожный (?), 25-Июн-08, 11:25 
>Система пакаджей во фряхе довольно убога:
>1. Пакетная база - набор каталогов с информацией о структуре и содержимом
>пакета. На большом количестве установленного софта начинаются заметные тормоза, так как
>упираемся в дисковую подсистему.
>2. Жесткие зависимости. т.е. при обновлении пакета на который ссылается другой пакет
>получаем битую зависимость.
>3. Отсутствие апгрейда как такового.

Обновлений нет.
А раз так, то в пункте 2 написана фигня - "при обновлении пакета". При каком обновлении ?

Получить битую зависимость можно если удалить пакет с ключом "force".
Иначе pkg_delete просто не даст удалить пакет если есть зависящие от него.
Ну а раз использовал "force" - то наверное знал что делаешь ? :)


>Система портов тоже не без недостатков. В частности:
>1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться
>скажем именно с апачем версии 2.0 и с нужными опциями, которые
>не всегда можно получить по make config(но присутствуют в Makefile порта).

А зачем подгонять make.conf ?
Нужно использовать
1) make config
2_ portupgrade c pkgtools.conf - там прописывают все остальные опции которые не входят в конфиг.

Да один раз нужно создать /var/db/ports/ и pkgtools.conf под себя.

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

>
>2. Зачастую невозможно собрать два пакета с разными опциями с одного порта
>и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее
>всего совпадут. Бывают правда и исключения например для опции WITH_THREADS.

Да - это проблема в FreeBSD.
Нельзя собрать два конфликтующих пакета. Cам с собой пакет конфликтует по определению.
Имена пакетов в принципе можно разрулить подправив Makefile.
Но вот в FreeBSD сделано так, что для сборки пакета его нужно обязательно установить.
И это мешает.

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

portupgrade хорошая вещь, но все равно не решает всех проблем.

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

69. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от oops (?), 25-Июн-08, 13:22 
>[оверквотинг удален]
>>3. Отсутствие апгрейда как такового.
>
>Обновлений нет.
>А раз так, то в пункте 2 написана фигня - "при обновлении
>пакета". При каком обновлении ?
>Получить битую зависимость можно если удалить пакет с ключом "force".
>Иначе pkg_delete просто не даст удалить пакет если есть зависящие от него.
>
>Ну а раз использовал "force" - то наверное знал что делаешь ?
>:)

гхм csup на /usr/ports и обновляемся за порта. а заодно получаем битую зависимость. Сюрприз.

>>Система портов тоже не без недостатков. В частности:
>>1. Приходится долго и аккуратно подгонять make.conf под свои нужды, чтобы собраться
>>скажем именно с апачем версии 2.0 и с нужными опциями, которые
>>не всегда можно получить по make config(но присутствуют в Makefile порта).
>А зачем подгонять make.conf ?
>Нужно использовать
>1) make config
>2_ portupgrade c pkgtools.conf - там прописывают все остальные опции которые не
>входят в конфиг.

1. make config, как я уже написал не всегда содержит _все_ опции доступные в Makefile. И еще не для всех портов существует.
2. portupgrade не покрывает случаи когда я говорю make install в самом порту. Если это не апгрейд, то portupgrade никакого смысла использовать нет. make.conf _всегда_ предпочтительнее чем конфиг сторонней тулзы.

>Да один раз нужно создать /var/db/ports/ и pkgtools.conf под себя.

Это хорошо для одной машины. т.к. подразумевает определенный интерактив.(make config)

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

Проблем будет гораздо больше, так как заточены на пакеты.

>>2. Зачастую невозможно собрать два пакета с разными опциями с одного порта
>>и сложить в один пакетный репозиторий, т.к. имена таких пакетов вероятнее
>>всего совпадут. Бывают правда и исключения например для опции WITH_THREADS.
>
>Да - это проблема в FreeBSD.
>Нельзя собрать два конфликтующих пакета. Cам с собой пакет конфликтует по определению.
>Имена пакетов в принципе можно разрулить подправив Makefile.
>Но вот в FreeBSD сделано так, что для сборки пакета его нужно
>обязательно установить.

Собрать можно например в chroot(DESTDIR=<chroot path> -DCHROOTED), сложить нельзя.

>portupgrade хорошая вещь, но все равно не решает всех проблем.

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


Ответить | Правка | Наверх | Cообщить модератору

74. "Решит ли возрождение проекта Berlin API проблемы с инсталляц..."  +/
Сообщение от .3 (?), 25-Июн-08, 14:21 
> Получить битую зависимость можно если удалить пакет с ключом "force".
> Иначе pkg_delete просто не даст удалить пакет если есть зависящие от него.

Еще можно запустить portupgrade. Даже в мане написано:
> After performing a binary upgrade, it is strongly recommended that
> you run ``pkgdb -F'' to fix broken dependencies introduced by the
> newly installed packages.t

Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру