The OpenNET Project / Index page

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



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

Оглавление

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

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


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ообщить модератору

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

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




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

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