Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 104
Последний раз, когда я пытался отдать проект в хорошие руки на хабре — меня забанили. Будь осторожнее :)
Эм, за что? оО
Дословно: «Хабр — не магазин на диване». Ответ на возмущенное письмо:
Здравствуйте!
Хабр — не магазин. Рекламировать товары, услуги, события, аккаунты и прочее, размещать в своих топиках ссылку на свой блог/сайт можно только в двух случаях: если топик находится в хабе «Я пиарюсь», либо в корпоративном блоге. Также не разрешается размещать рекламу в хабрацентре.
Отдам домен = ссылки на свои сайты = реклама. Несколько последних таких же топиков подарили их авторам ReadOnly.
— C наилучшими пожеланиями,
Служба психологической помощи Хабрахабра
На всякий случай — текст того топика: gist.github.com/ssbb/4269f7327ddd78dbf880
Они там совсем уже на своей рекламе помешались. Весь интернет только и держится на ссылках. И это ещё руководство технического ресурса такие письма рассылает.
Эх, одно стартаперство в голове.
Эх, одно стартаперство в голове.
последний раз когда я использовал смайлики в конце предложений — меня забанили. Будь осторожнее (:
ps: это не шутка… :)
ps: это не шутка… :)
Это здорово, плюсую. А можно все на github?
Да, сегодня постараемся все выложить.
PHP =(
Нам очень стыдно, правда.
Не понимаю, чего тут стыдиться. Ну PHP и PHP, вполне имеете право на такой выбор. То, что он кому-то не по нраву, проблемы не ваши. Продукт-то работоспособный.
И не зря.
Ведь практический весь софт, который рабоатет с rpm репозиториями (yum, mrepo и т.д.) и сборкой (Mock Project) либо написаны на питоне, либо имеют биндинги в питон. Так что хейтеры-хейтерами, но архитекурно писать такое на пхп, не лучшее решение, вы не находите?
Ведь практический весь софт, который рабоатет с rpm репозиториями (yum, mrepo и т.д.) и сборкой (Mock Project) либо написаны на питоне, либо имеют биндинги в питон. Так что хейтеры-хейтерами, но архитекурно писать такое на пхп, не лучшее решение, вы не находите?
Что только люди не делают, лишь бы gentoo не использовать.
Это шутка или архитектура Gentoo подразумевает всё «из коробки»?
Штука, описанная в топике, и есть главная фишка Gentoo, конечно, она там из коробки. В Gentoo вы выбираете свои параметры сборки нужных вам пакетов.
Что делать в gentto в параметрах сборки нет нужного СТОРОННЕГО модуля?
P.S. Это философский вопрос, ответа на него не требуется. Спасибо за понимание.
P.S. Это философский вопрос, ответа на него не требуется. Спасибо за понимание.
Скопировать ебилд в свой локальный оверлей и исправить его там.
P.S. Не бывает вопросов, на которые ответ не требуется. Если этот ответ не требуется вам, не факт, что он не требуется никому. Если это действительно ответ, который не потребуется никому, оставьте вопрос при себе, не сотрясайте воздух.
P.S. Не бывает вопросов, на которые ответ не требуется. Если этот ответ не требуется вам, не факт, что он не требуется никому. Если это действительно ответ, который не потребуется никому, оставьте вопрос при себе, не сотрясайте воздух.
Вы когда-нибудь слышали о риторических вопросах?
Во-первых, вопрос выше — не риторический. Нормальный технический вопрос и намёк, что «не отвечайте, всё равно вы меня не убедите».
Во-вторых, кому они нужны, риторические вопросы?
Во-вторых, кому они нужны, риторические вопросы?
А кто сказал что вопрос выше риторический? Я написал это на ваше «Не бывает вопросов, на которые ответ не требуется». Риторический вопрос это нормальный элемент речи. Вполне имеет место в некоторых ситуациях
Риторические вопросы неуместны на техническом ресурсе.
Да и вообще, это не нормальный элемент речи. Это демагогический приём.
Да и вообще, это не нормальный элемент речи. Это демагогический приём.
Да кто вам сказал что они не уместны? Бред какой-то.
Бред, конечно. На техническом ресурсе уместны аргументированные доказательства. А риторический вопрос — это из области, как вы понимаете, риторики, т.е. ораторского искусства и красноречия. Эти вопросы несут вред: вместо того, чтобы действительно аргументировать свою точку зрения, иные индивидуумы начинают использовать риторические приёмы (а потом и демагогические), сводя нормальную техническую дискуссию к пустому флейму.
Зачем в локальный оверлей?
Этот вариант тоже поддерживается из коробки — /etc/portage/make.conf:
Этот вариант тоже поддерживается из коробки — /etc/portage/make.conf:
NGINX_ADD_MODULES="/usr/src/nginx/some_other_nginx_module"
чтобы узнать что-нибудь ненужное, нужно спросить что-нибудь ненужное… =)
Для Gentoo:
1. Искать нужный модуль через публичные оверлеи в Layman
2. Добавлять модуль в ебилде локального оверлея
Именно так я поступал, когда мне нужен был http push модуль в nginx, пока его не добавили в основной ебилд.
1. Искать нужный модуль через публичные оверлеи в Layman
2. Добавлять модуль в ебилде локального оверлея
Именно так я поступал, когда мне нужен был http push модуль в nginx, пока его не добавили в основной ебилд.
Зачастую нужно собрать со своими опциями 3-4 пакета и ничего более. Repobuild нацелен на то, чтобы создать репозитарий с нужными пакетами, подключить на сервер и забыть про них. Не нужно каждый раз что-то искать, патчить, компилить, разносить по серверам.
Не нужно каждый раз что-то искать, патчить, компилить, разносить по серверам.
Так и в генте не нужно.
Ну почему же, нужно. Но в подобных случаях разносить по серверам нужно и в других дистрибутивах.
Зато, случаев, когда что-то нужно патчить, в дженте бывает меньше — там сразу есть возможность выбора, как что-то будет собрано, а собирается оно всё равно само и без ручного вмешательства. А если вмешательство требуется, то в дженте это делается гораздо проще, чем в других дистрибутивах.
Зато, случаев, когда что-то нужно патчить, в дженте бывает меньше — там сразу есть возможность выбора, как что-то будет собрано, а собирается оно всё равно само и без ручного вмешательства. А если вмешательство требуется, то в дженте это делается гораздо проще, чем в других дистрибутивах.
Так и я о том, что если для чего-то «Не нужно каждый раз ...», то и в gentoo это не требуется.
Включая пункт «компилировать», ибо это же не вручную делается. Пользователю из всего «компилирования» заметно только время установки.
Включая пункт «компилировать», ибо это же не вручную делается. Пользователю из всего «компилирования» заметно только время установки.
Подождите. Объясните, немного не понимаю. Не холивара ради, а понимания для.
Вот в данном случае, я создаю репозитарий, добавляю туда пакеты, выбираю модули и тыкаю — создать. Получив ссылку на репозитарий, подключил его на 10+ серверов забыл. После выхода обновления я избавлен от поиска модулей, разрешения зависимостей, компиляции. Я просто набираю «yum update» и через минуту у меня уже все обновлено без каких-либо выходов сервера из рабочего режима. Вышла новая версия, опять же «yum update» и все обновлено (либо порсто автоапдейт).
Расскажите, как бы этот процесс выглядел на gentoo и чем он удобнее описанного мною выше?
Вот в данном случае, я создаю репозитарий, добавляю туда пакеты, выбираю модули и тыкаю — создать. Получив ссылку на репозитарий, подключил его на 10+ серверов забыл. После выхода обновления я избавлен от поиска модулей, разрешения зависимостей, компиляции. Я просто набираю «yum update» и через минуту у меня уже все обновлено без каких-либо выходов сервера из рабочего режима. Вышла новая версия, опять же «yum update» и все обновлено (либо порсто автоапдейт).
Расскажите, как бы этот процесс выглядел на gentoo и чем он удобнее описанного мною выше?
В Gentoo: вы создаёте директорию, в ней пару служебных файлов вроде repo_name, а также копируете туда ebuildы нужных вам пакетов и поправляете его по своему вкусу.
Потом настраиваете что-нибудь для доступа к этой директории (rsync, svn, git и так далее) и подключаете её на ваших серверах как layman-овский оверлей. Потом всё, эксплуатируете gentoo как обычно: emerge -akvuDN world и если в оверлее есть новая версия, она обновится. Ключ -k нужен, если вы ещё настроили на своих серверах binhost, чтобы оно использовало уже собранные вами где-то пакеты и не собирало их на серверах заново.
Плюс в том, что вы не используете никаких сторонних сервисов и стороннего кода — всё 100% уже имеющееся в дистрибутиве (ну, кроме своего особого пакета, конечно).
Потом настраиваете что-нибудь для доступа к этой директории (rsync, svn, git и так далее) и подключаете её на ваших серверах как layman-овский оверлей. Потом всё, эксплуатируете gentoo как обычно: emerge -akvuDN world и если в оверлее есть новая версия, она обновится. Ключ -k нужен, если вы ещё настроили на своих серверах binhost, чтобы оно использовало уже собранные вами где-то пакеты и не собирало их на серверах заново.
Плюс в том, что вы не используете никаких сторонних сервисов и стороннего кода — всё 100% уже имеющееся в дистрибутиве (ну, кроме своего особого пакета, конечно).
Небольшое дополнение: про binhost — для тех, кто думает, что в gentoo прям обязательно всё нужно компилировать и другого способа нет.
Вы наверное удивитесь, но на RPM подобных все делается точно так же.
1 Создаете репозиторий с собранным пакетом
2 Подключаете репо на других серверах
3 Наслаждаетесь
Проблема в том, что не каждый системный администратор хочет и имеет технические знания реализовать подобную схему (ОС не важна).
Гораздо проще «натыркать» нужных пакетов и опций и положить ссылку на репо на сервера, всю остальную заботу по актуализации, новым версиям, новым модулям, сборке — берет на себя сервис.
За дополнительные бонусы которого, в виде технической поддержки, реализации дополнительных хотелок — владелец сервиса получает небольшую денежную благодарность.
Согласитесь вполне себе рабочая схема.
1 Создаете репозиторий с собранным пакетом
2 Подключаете репо на других серверах
3 Наслаждаетесь
Проблема в том, что не каждый системный администратор хочет и имеет технические знания реализовать подобную схему (ОС не важна).
Гораздо проще «натыркать» нужных пакетов и опций и положить ссылку на репо на сервера, всю остальную заботу по актуализации, новым версиям, новым модулям, сборке — берет на себя сервис.
За дополнительные бонусы которого, в виде технической поддержки, реализации дополнительных хотелок — владелец сервиса получает небольшую денежную благодарность.
Согласитесь вполне себе рабочая схема.
Системный администратор, которые не имеет технических знаний, чтобы собрать и поставить пакет в своей системе (ОС не важна), у меня вызывает уныние.
А разница, повторюсь, в том, что сделать свою сборку с небольшими изменениями в Gentoo проще, чем в других. Я не голословно говорю, я это делал в центоси и в дебиане, в дженте реально меньше телодвижений.
Техподдержка и «сделайте за меня» — это да, вы придумали сервис «соберу пакет за вас». Фактически — вы изобрели способ как бы подключить оверлей дженты к центоси, за деньги. Хороший сервис, я вовсе не против него. Но я считаю, что ставить бизнес в зависимость от такого сервиса опасно: а ну как сервис закроется вдруг, и что делать теперь? А сисадмина с техническими знаниями или хотя бы с желанием работать не нашлось.
Лично я бы предпочёл такой же сервис для дебиана. Но — эх — подобный функционал и дебиан тоже уже встроен в виде apt-source и иже с ним.
А разница, повторюсь, в том, что сделать свою сборку с небольшими изменениями в Gentoo проще, чем в других. Я не голословно говорю, я это делал в центоси и в дебиане, в дженте реально меньше телодвижений.
Техподдержка и «сделайте за меня» — это да, вы придумали сервис «соберу пакет за вас». Фактически — вы изобрели способ как бы подключить оверлей дженты к центоси, за деньги. Хороший сервис, я вовсе не против него. Но я считаю, что ставить бизнес в зависимость от такого сервиса опасно: а ну как сервис закроется вдруг, и что делать теперь? А сисадмина с техническими знаниями или хотя бы с желанием работать не нашлось.
Лично я бы предпочёл такой же сервис для дебиана. Но — эх — подобный функционал и дебиан тоже уже встроен в виде apt-source и иже с ним.
То что вы описали, реализовывается на любом дистрибутиве. Берем srpm пакета, компилим со своими опциями, инициализируем репозитарий и раздаем на другие сервера любым удобным методом.
Но у этого подхода есть минусы, которые этот проект и пытается поправить.
— Вам не нужно следить за новыми версиям ПО. Выпустил разработчик stable, пакет уже появился в репозитарии.
— Вам не нужно отслеживать обновления модулей и патчей. За вас это делает администрация сервиса.
— Вам не нужно искать ошибки компиляции, править зависимости и конфликты.
— Вам не нужно поднимать каких-то сторонник сервисов, не нужно ничего настраивать. Подключили 1 раз репозитарий и забыли.
Для этих удобств и создавался проект в сабже. Что может быть проще?
А минус в использовании стороннего сервиса — это да.
Но у этого подхода есть минусы, которые этот проект и пытается поправить.
— Вам не нужно следить за новыми версиям ПО. Выпустил разработчик stable, пакет уже появился в репозитарии.
— Вам не нужно отслеживать обновления модулей и патчей. За вас это делает администрация сервиса.
— Вам не нужно искать ошибки компиляции, править зависимости и конфликты.
— Вам не нужно поднимать каких-то сторонник сервисов, не нужно ничего настраивать. Подключили 1 раз репозитарий и забыли.
Для этих удобств и создавался проект в сабже. Что может быть проще?
wget http://repos.repobuild.com/myrepo -o /etc/yum.repos.d/myrepo.repo
yum updateА минус в использовании стороннего сервиса — это да.
Мы по-моему обсуждаем два разных вопроса: «как бы сделать так, чтобы пакеты с нужными мне опциями собирал для меня кто-то другой» и «как реализовать такой сервис для того или иного дистрибутива». По первому пункту — нет вопросов, и в дженте тогда ничем отличаться не будет — всё точно так же сведётся к подключению (платного) оверлея, который обслуживает администрация сервиса. По второму — я хотел сказать, что подобный сервис реализуется на дженте встроенными средствами (привет тегу «говнокод» в топике), и в общем каждый администратор более чем десятка серверов на дженте (а такие есть, в америке есть целая банковская сеть на базе дженты) себе такой сервис сделает.
Мы начали обсуждение с того «Что только люди не делают, лишь бы gentoo не использовать.». Разобравшись с аргументами, пришли к выводу что везде все делается все теми же стандартными средствами и ничуть не сложнее чем в gentoo.
А тег «говнокод» был приурочен уже к реализации этого конкретного сервиса — многопользовательский, юзерфрендли и в «2 клика».
А тег «говнокод» был приурочен уже к реализации этого конкретного сервиса — многопользовательский, юзерфрендли и в «2 клика».
В gentoo гораздо больше настроек доступно прямо из коробки. То есть крайне велика вероятность, что требуемого можно добиться use-флагами. Или подключением существующего оверлея.
Возможно есть ситуации при которых use-флагов не хватит, но я не сталкивался.
Ниже есть пример с nginx. Все это будет обновляться автоматически и не требует дополнительных действий после первой настройки.
Возможно есть ситуации при которых use-флагов не хватит, но я не сталкивался.
Ниже есть пример с nginx. Все это будет обновляться автоматически и не требует дополнительных действий после первой настройки.
Ну, вот как вам уже сказали, в gentoo вам просто такой сервис во многих случаях не понадобился бы. Плюс к этому могу добавить, что в случае проблем с пакетами они в gentoo решаются легче, чем в других дистрибутивах — просят собрать с дебагом — да легко, просят собрать другим gcc — да пожауйлста, просят ещё что-то — вперёд, минимум дополнительных телодвижений. И часто проблема решается ещё до того, как доберёшься с ней до апстрима (непосредственного разработчика приложения), с помощью мейнтейнеров дженты.
К сожалению почему-то все НЕгентушники знают, что в генту надо компилировать, но не знают, что в генту есть BINHOST (PKGDIR) позволяющий компилировать только один раз при одинаковых условиях сборки.
У меня генту и на слабых ВДСках и на ноутбуке samsung r50 и на дедиках. Нигде из них я не собираю. У меня есть билд-ферма: комп с большим количеством ядер и оперативы (6 ядер, 32 гига — не много, но это для личного использования). На нем есть несколько сборочных «цехов» (папок, в которые я хочу через chroot). Один «цех» — это аналог Вашего repobuild. Я могу задать практически любые параметры компиляции каждого пакета в системе. (Какие не могу задать — могу скопировать сборочный скрипт и изменить под себя) Собранные бинарники в виде архивов ложатся через в папочку определенного формата: аналог репозитория. В дальнейшем из этого «репозитория» из бинарников система с помощью того же emerge (основная утилита аналог «пакетного менеджера» в генту: она запускает сборку и установку) развертывается на сервера\ВДСки\ноутбуки и т.п.
Пока что единственное, что я не умею массово скриптом копировать по серверам — это ядро с модулями. То есть собираю его я так же не ферме, но потом ручками через sftp раскидываю на каждую машину. Но было бы у меня всего добра (хостов) больше десятка — написал бы простейший скрипт на шелл+rsync.
В итоге система получается аналогичная repobuild'у за исключением проверенного времени, стабильного способа сборки, которым славится генту.
У меня генту и на слабых ВДСках и на ноутбуке samsung r50 и на дедиках. Нигде из них я не собираю. У меня есть билд-ферма: комп с большим количеством ядер и оперативы (6 ядер, 32 гига — не много, но это для личного использования). На нем есть несколько сборочных «цехов» (папок, в которые я хочу через chroot). Один «цех» — это аналог Вашего repobuild. Я могу задать практически любые параметры компиляции каждого пакета в системе. (Какие не могу задать — могу скопировать сборочный скрипт и изменить под себя) Собранные бинарники в виде архивов ложатся через в папочку определенного формата: аналог репозитория. В дальнейшем из этого «репозитория» из бинарников система с помощью того же emerge (основная утилита аналог «пакетного менеджера» в генту: она запускает сборку и установку) развертывается на сервера\ВДСки\ноутбуки и т.п.
Пока что единственное, что я не умею массово скриптом копировать по серверам — это ядро с модулями. То есть собираю его я так же не ферме, но потом ручками через sftp раскидываю на каждую машину. Но было бы у меня всего добра (хостов) больше десятка — написал бы простейший скрипт на шелл+rsync.
В итоге система получается аналогичная repobuild'у за исключением проверенного времени, стабильного способа сборки, которым славится генту.
А flameeyes (один из мейнтейнеров дженты) собирает (для теста) всё дерево portage, но не в чрутах, а в lxc-контейнерах ;)
во-первых, хидеры и gcc не мешают, а во-вторых — INSTALL_MASK поможет вообще не устанавливать определённые файлы, даже если они есть в бинарном пакете (ну или ставишь из исходников)
в третьих, ROOT=/somewhere/else emerge nginx — и в /somewhere/else будет построен gentoo, да, но gcc или portage там не будет.
в третьих, ROOT=/somewhere/else emerge nginx — и в /somewhere/else будет построен gentoo, да, но gcc или portage там не будет.
1) Чем именно они мешают? Место занимают? «Потому что так надо» — не ответ.
Я могу согласиться частично с аргументом «а если взломают, наличие компилятора и хидеров может помочь взломщику». Но частично, потому что «если» и «может»: если взломают, вас может не спасти и отсутствие комплиятора, да и его вместе с хидерами взломщик может принести с собой. Кроме того, раз уж взломали, проблема явно где-то в другом месте, через хидеры и компилятор не ломают.
2) 3) Нельзя. Нет такой техники на сегодняшний день. Не отвлекайтесь.
Я могу согласиться частично с аргументом «а если взломают, наличие компилятора и хидеров может помочь взломщику». Но частично, потому что «если» и «может»: если взломают, вас может не спасти и отсутствие комплиятора, да и его вместе с хидерами взломщик может принести с собой. Кроме того, раз уж взломали, проблема явно где-то в другом месте, через хидеры и компилятор не ломают.
2) 3) Нельзя. Нет такой техники на сегодняшний день. Не отвлекайтесь.
Т.е. реально аргументов против у вас нет. Место, мусор — это бред в 2013 году, а что касается безопасности — я уже объяснил, что вы не там ищете безопасность. Да, кстати, мы с вами на «ты» не переходили, поэтому ты давай не тыкай, уже научись вежливо общаться, не маленький.
P.S. Я не фанатик Gentoo. Я просто не люблю голословные утверждения типа «я сто лет так делаю поэтому так правильно». Возможно, все эти сто лет вы делаете неправильно и пора пересмотреть отношение к вопросу.
P.S. Я не фанатик Gentoo. Я просто не люблю голословные утверждения типа «я сто лет так делаю поэтому так правильно». Возможно, все эти сто лет вы делаете неправильно и пора пересмотреть отношение к вопросу.
В общем, я несколько вспылил, прошу прощения.
Вы впариваете bleeding edge дистрибутив без какого либо release цикла, взамен вывереного продакшен дистрибутива.Отнюдь. Gentoo пожалуй один из немногих дистрибутивов (всякие CentOS, Ubuntu, Debian и пр. в это число не входят), где из коробки всегда идет действительно стабильная версия nginx без security уязвимостей. Во всех остальных вы по умолчанию получаете той или иной степени дырявости версию с известными (и порой довольно серьезными) багами, да ещё и собранную со сторонним кодом весьма сомнительного качества. Во многом из-за этого приходиться поддерживать отдельные репозитории для этих систем, и строго рекомендовать ставить пакеты только из них.
Вас минусуют потому, что каких-то фактических конкретных аргументов в поддержку своей позиции вы не представили. Делаете непонятные выводы об окружающих — например, я всё никак не пойму, с какого похмелья вы назвали меня дистрибутиво-фанатиком, — в то время, когда это от вас последние пяток комментариев тут брызжет фанатичная НЕНАВИСТЬ. В это же время наблюдается крайне вялая реакция на мою попытку вернуть спор в техническое русло (я про аргумент по поводу безопасности компилятора на боевом сервере).
Ну и что с того, что вы пакетировали там что-то? При этом что-то произошло, вы выловили какие-то баги или недостатки системы сборки или что-то ещё? Почему не пакетируете больше — надоело, или вас попросили из мейнтейнеров, и почему?
Кто тут неадекватен-то? Вот это — ненависть, отсутствие желания вести технический диалог, ответ вопросом на вопрос — за это вас и минусуют.
P.S. Если потом ещё где-то непонятно будет, за что вас минусуют — обращайтесь, разъясню.
Ну и что с того, что вы пакетировали там что-то? При этом что-то произошло, вы выловили какие-то баги или недостатки системы сборки или что-то ещё? Почему не пакетируете больше — надоело, или вас попросили из мейнтейнеров, и почему?
Кто тут неадекватен-то? Вот это — ненависть, отсутствие желания вести технический диалог, ответ вопросом на вопрос — за это вас и минусуют.
P.S. Если потом ещё где-то непонятно будет, за что вас минусуют — обращайтесь, разъясню.
Fedora я не упоминал. Мы для нее и пакетов не собираем, к тому же это leading edge дистрибутив и если регулярно обновлятся, там всё относительно хорошо из коробки.
openSUSE — имеет давнюю традицию по части подмешивания в nginx всякого говна, порой вопиюще отвратительного. Сейчас там nginx собран с Passenger, который славен тем, что делает разную магию в nginx, что порой вызывает совершенно странные баги в непредсказуемых местах. Из относительно свежего: mailman.nginx.org/pipermail/nginx/2013-February/037563.html (обратите внимание, баг проявляется даже если модуль не используется, а просто собран). Из вопиющего, какое-то время назад пользователи openSUSE получали из коробки nginx с печально известным flood_block модулем. Модуль представлял из себя откровенный говнокод, который при первом запросе форкал один из рабочих процессов, а затем каждый запрос подключался к потомку, отправлял в него данные, а тот искал по базе данных и возвращал ответ. Всё это происходило блокированно, причем блокировался не один рабочий процесс, а все, и вне зависимости от настроек, достаточно того, что он просто был собран. Если при этом происходила какая-нибудь ошибка, то всё ещё и падало. Nuff Said.
Что касается CentOS, то наверное нужно поблагодарить пользователей этого дистрибутива за то, что заставляют регулярно тренировать память. Самый большой поток жалоб на баги, исправленные несколько лет назад, приходится на них. Я даже не пойду смотреть, что там за пакет у них сейчас, и с чем они его собирают, и побекпортили ли они все security исправления, или нет (и по опыту, не исключено что не все). Этот дистрибутив базируется на ложных идеях о том, что устаревший (тут даже уместнее — антикварный), не поддерживаемый, протухший софт, с кучей известных багов — является стабильным. Это в корне не так, особенно в случае nginx.
Я не сильно ошибусь, если скажу, что в 95% случаев самый стабильный nginx — это последний коммит в репозитории. У нас драконовский процесс ревью с крайне строгими требованиями к его качеству. Код, который попадает в репозиторий, просматривает построчно от 6-ти до 8-ми глаз разработчиков-перфекционистов. Порой ревью при этом достигает двух десятков итераций. А сам nginx имеет такую структуру, что если и добавляются новые баги, то в большинстве случаев они локализованы строго той новой функциональностью, которая добавляется. В то же время баги в старой функциональности непрерывно исправляются и каждая последующая версия, как правило, является стабильнее всех предыдущих. Нет никакого резона держать версию старее, чем последняя. А если вы параноик и для вас боязнь наступить на новый баг смертельна, то обновляетесь на последнюю с небольшой задержкой (либо просто строго придерживайтесь последней версии stable-ветки по нашей классификации на странице download).
При этом важный момент тут в том, что всё вышесказанное относится исключительно к nginx без сторонних патчей и модулей. Мы не можем гарантировать того же качества кода от третьих лиц, и по наблюдениям, чаще всего оно сильно уступает.
Мейнтейнер дистрибутива чаще всего просто не в состоянии оценить качество того или иного стороннего кода, который он добавляет просто по просьбам пользователей или потому, что ему кажется он полезным. А бэкпортятся чаще всего только совсем критические уязвимости, на которые мы сами выкладываем патчи, и которых, к счастью, очень мало (хотя это не мешало, например, debian-у, при наличии опубликованных CVE и патча, жить примерно пол года с уязвимым nginx-ом). Но речь идет только о security-уязвимостях, а такие вещи как падения или очень досадные баги остаются до тех пор, пока народ не обновит дистрибутив (что может произойти только через несколько лет) или не подключит наш репозиторий.
Я пишу на основе опыта по отдельно взятому продукту, к которому имею отношение, и потому знаю в какой-то степени ситуацию. Но пакетов в системе чаще всего огромное количество и я не думаю, что мой опыт является чем-то экстраординарным. А если его экстраполировать на все остальные пакеты в той или иной степени, то картина становится печальна для некоторых дистрибутивов.
Забавным остается то, что последствия чаще всего остаются незаметны от конечного пользователя. Тот же nginx чаще всего работает с таким запасом по производительности, что если его вдруг замедлить раз в 10, то это останется для многих незамеченным. Ну обрабатывает он запрос за 2мс с пакетом из нашего репозитория и за 20мс с пакетом из репозитория дистрибутива, если сервер не является высоконагруженным, не работает на пределе своих ресурсов, и если не делать специально тестов, это легко может оставаться незамеченным. Также и какие-нибудь баги, внесенные сторонним кодом, которые проявляются только при стечение некоторых обстоятельств и настроек.
openSUSE — имеет давнюю традицию по части подмешивания в nginx всякого говна, порой вопиюще отвратительного. Сейчас там nginx собран с Passenger, который славен тем, что делает разную магию в nginx, что порой вызывает совершенно странные баги в непредсказуемых местах. Из относительно свежего: mailman.nginx.org/pipermail/nginx/2013-February/037563.html (обратите внимание, баг проявляется даже если модуль не используется, а просто собран). Из вопиющего, какое-то время назад пользователи openSUSE получали из коробки nginx с печально известным flood_block модулем. Модуль представлял из себя откровенный говнокод, который при первом запросе форкал один из рабочих процессов, а затем каждый запрос подключался к потомку, отправлял в него данные, а тот искал по базе данных и возвращал ответ. Всё это происходило блокированно, причем блокировался не один рабочий процесс, а все, и вне зависимости от настроек, достаточно того, что он просто был собран. Если при этом происходила какая-нибудь ошибка, то всё ещё и падало. Nuff Said.
Что касается CentOS, то наверное нужно поблагодарить пользователей этого дистрибутива за то, что заставляют регулярно тренировать память. Самый большой поток жалоб на баги, исправленные несколько лет назад, приходится на них. Я даже не пойду смотреть, что там за пакет у них сейчас, и с чем они его собирают, и побекпортили ли они все security исправления, или нет (и по опыту, не исключено что не все). Этот дистрибутив базируется на ложных идеях о том, что устаревший (тут даже уместнее — антикварный), не поддерживаемый, протухший софт, с кучей известных багов — является стабильным. Это в корне не так, особенно в случае nginx.
Я не сильно ошибусь, если скажу, что в 95% случаев самый стабильный nginx — это последний коммит в репозитории. У нас драконовский процесс ревью с крайне строгими требованиями к его качеству. Код, который попадает в репозиторий, просматривает построчно от 6-ти до 8-ми глаз разработчиков-перфекционистов. Порой ревью при этом достигает двух десятков итераций. А сам nginx имеет такую структуру, что если и добавляются новые баги, то в большинстве случаев они локализованы строго той новой функциональностью, которая добавляется. В то же время баги в старой функциональности непрерывно исправляются и каждая последующая версия, как правило, является стабильнее всех предыдущих. Нет никакого резона держать версию старее, чем последняя. А если вы параноик и для вас боязнь наступить на новый баг смертельна, то обновляетесь на последнюю с небольшой задержкой (либо просто строго придерживайтесь последней версии stable-ветки по нашей классификации на странице download).
При этом важный момент тут в том, что всё вышесказанное относится исключительно к nginx без сторонних патчей и модулей. Мы не можем гарантировать того же качества кода от третьих лиц, и по наблюдениям, чаще всего оно сильно уступает.
с хорошим качеством кода, что снижает трудности сопровожденияЭто ложное представление о малых трудностях сопровождения. В действительности код nginx практически не документирован, является весьма сложной системой, не имеющей как такового стабильного обособленного API, и, вообще говоря, всех разработчиков, которые хорошо разбираются в нём, можно сосчитать по пальцам. А если исключить из счета сотрудников Nginx, Inc. то может и хватит одной руки.
Мейнтейнер дистрибутива чаще всего просто не в состоянии оценить качество того или иного стороннего кода, который он добавляет просто по просьбам пользователей или потому, что ему кажется он полезным. А бэкпортятся чаще всего только совсем критические уязвимости, на которые мы сами выкладываем патчи, и которых, к счастью, очень мало (хотя это не мешало, например, debian-у, при наличии опубликованных CVE и патча, жить примерно пол года с уязвимым nginx-ом). Но речь идет только о security-уязвимостях, а такие вещи как падения или очень досадные баги остаются до тех пор, пока народ не обновит дистрибутив (что может произойти только через несколько лет) или не подключит наш репозиторий.
Я пишу на основе опыта по отдельно взятому продукту, к которому имею отношение, и потому знаю в какой-то степени ситуацию. Но пакетов в системе чаще всего огромное количество и я не думаю, что мой опыт является чем-то экстраординарным. А если его экстраполировать на все остальные пакеты в той или иной степени, то картина становится печальна для некоторых дистрибутивов.
Забавным остается то, что последствия чаще всего остаются незаметны от конечного пользователя. Тот же nginx чаще всего работает с таким запасом по производительности, что если его вдруг замедлить раз в 10, то это останется для многих незамеченным. Ну обрабатывает он запрос за 2мс с пакетом из нашего репозитория и за 20мс с пакетом из репозитория дистрибутива, если сервер не является высоконагруженным, не работает на пределе своих ресурсов, и если не делать специально тестов, это легко может оставаться незамеченным. Также и какие-нибудь баги, внесенные сторонним кодом, которые проявляются только при стечение некоторых обстоятельств и настроек.
Вот пример с nginx'ом:
aio debug +http +http-cache ipv6 libatomic +pcre pcre-jit rtmp selinux ssl syslog vim-syntax NGINX_MODULES_HTTP="+access addition +auth_basic auth_pam +autoindex +browser cache_purge +charset dav dav_ext degradation echo +empty_gif fancyindex +fastcgi flv +geo geoip gunzip +gzip gzip_static headers_more image_filter +limit_conn +limit_req lua +map +memcached metrics mp4 naxsi perl +proxy push random_index realip +referer +rewrite +scgi secure_link security slowfs_cache spdy +split_clients +ssi stub_status sub upload_progress upstream_check +upstream_ip_hash +userid +uwsgi xslt" NGINX_MODULES_MAIL="imap pop3 smtp" USERLAND="GNU"
А чем это лучше opensuse build service?
У меня к сожалению нет ответа на Ваш вопрос. Не вижу критериев по которым их можно было бы сравнить.
С точки зрения пользователя этот проект задумывался как быстрый способ создать собственный репозиторий с необходимыми пакетами собранными с вашими модулями и параметрами сборки.
С точки зрения пользователя этот проект задумывался как быстрый способ создать собственный репозиторий с необходимыми пакетами собранными с вашими модулями и параметрами сборки.
В таком случае, разница в том, что топикстартер собирается поддерживать и модифицировать спеки по мере развития дистрибутива. В obs поддерживаешь сам. Вот и вся суть сервиса: для тебя пишут спеки по твоему заказу.
Ради интереса соберите мне Nginx с модулями
drizzle-nginx-module
nginx_syslog
redis-nginx-module
под CentOS 5 архитектуры i386
у меня это заняло 3 минуты времени, и этот пакет я могут устанавливать и обновлять набрав только yum update
Сколько времени это займет у Вас с OBS?
drizzle-nginx-module
nginx_syslog
redis-nginx-module
под CentOS 5 архитектуры i386
у меня это заняло 3 минуты времени, и этот пакет я могут устанавливать и обновлять набрав только yum update
Сколько времени это займет у Вас с OBS?
Проблема в том, что не каждый администратор соберет SRPM и напишет SPEC.
В Вашем случае это сработает, в 99% остальных пользователей нет. Поверьте не каждый напишет Spec, и соберет SRPM, с нужными модулями и патчами.
Наш сервис как раз для них.
В Вашем случае это сработает, в 99% остальных пользователей нет. Поверьте не каждый напишет Spec, и соберет SRPM, с нужными модулями и патчами.
Наш сервис как раз для них.
Ради интереса соберите мне Nginx с модулями<offtop>Это такой способ убить производительность и надежность nginx на корню.</offtop>
…
nginx_syslog
не разбираюсь в этом вот поделии, но нормальный человек без опыта быстрее чем за 2-3 часа инстанс obs не поднимет.
А obs именно позволяет собирать пакеты со своими параметрами компиляции, и подключать результат как отдельный репозиторий?
Я думал, он собирает свой дистрибутив, включив туда нужные пакеты. Только вот пакеты уже готовые собранные стандартные. И соответственно никакой кастомизации процесса сборки пакетов и нет смысла в отдельном репозитории.
Я думал, он собирает свой дистрибутив, включив туда нужные пакеты. Только вот пакеты уже готовые собранные стандартные. И соответственно никакой кастомизации процесса сборки пакетов и нет смысла в отдельном репозитории.
Да, именно для этого он и предназначен.
Только кастомизация процесса сборки заключается с создании или редактировании своего spec-файла.
Только кастомизация процесса сборки заключается с создании или редактировании своего spec-файла.
Это вы с susestudio перепутали. Там можно накликать какие пакеты нужны и получить уже настроенный и готовый к запуску образ. Пакеты можно брать откуда угодно, естественно. (при условии, что они под свободной лицензией)
Не совсем понял, а репозиторий будет после поддерживался сам в актуальном состоянии? Или это просто платформа для сборки, когда лениво самому руками вписать и собрать пакет?
+ nginx и другие открытые проекты иногда выкидывают/добавляют новые модули, как это разруливается (при условии что репа обновляется сама)?
+ nginx и другие открытые проекты иногда выкидывают/добавляют новые модули, как это разруливается (при условии что репа обновляется сама)?
Сейчас автообновление пакетов реализованно просто. Мы просто готовим новую версию SRPMS и у всех пользователей выбравших данный пакет он обновляется с его опциями сборки автоматически, т е без участия пользователя.
С новыми опциями еще проще, мы вносим в БД эту опцию для нужного пакета и у всех пользователей она появляется при выборе опций.
Если появился новый модуль (например для Nginx) тогда мы кладем его в SRPMS пакет и добавляем возможность включения в БД.
Для пользователей процесс прозрачен.
С новыми опциями еще проще, мы вносим в БД эту опцию для нужного пакета и у всех пользователей она появляется при выборе опций.
Если появился новый модуль (например для Nginx) тогда мы кладем его в SRPMS пакет и добавляем возможность включения в БД.
Для пользователей процесс прозрачен.
Например по «наводке» одного из пользователей мы добавили возможность выбора модуля limit_req из проекта tengine в пакете Nginx
И пользователям Nginx которые выберут данную опцию доступны такие конструкции.
Заняло это примерно минут 15. На тестирование ушло времени раз в 10 больше :)
И пользователям Nginx которые выберут данную опцию доступны такие конструкции.
Заняло это примерно минут 15. На тестирование ушло времени раз в 10 больше :)
Отличный проект. Мне он видится как свой локальный апдейт сервис. Т.е. администратор у которого 10+ серверов, может поднять такой сервис для себя и в удобном интерфейсе выбрать чего ему хочется и как это надо собрать. Потом раздавать на свои сервера или рабочие станции уже особым образом собранные пакеты.
Продавать такой сервис на сторону можно, только если площадка гарантирует что они будут онлайн и будут поддерживать сервис 5+лет, другими словами — это проблема того, кто попробует зарабатывать на вашем начинании деньги. :)
Продавать такой сервис на сторону можно, только если площадка гарантирует что они будут онлайн и будут поддерживать сервис 5+лет, другими словами — это проблема того, кто попробует зарабатывать на вашем начинании деньги. :)
Администратор, у которого 10+ серверов, не будет разводить зоопарк с десятком вариаций сборок nginx и сделает себе 1 пакет.
Администратору нужна 1 версия пакета на 10 серверах. С помощью такого сервиса (и не только его) он может легко держать 1 репозиторий с той самой необходимой версией пакета. И устанавливать из своего репозитория nginx на все 10+ cерверов.
Держать больше 1 репозитория 1 администратору смысла я не вижу, хотя такая возможность присутствует.
Держать больше 1 репозитория 1 администратору смысла я не вижу, хотя такая возможность присутствует.
Для задачи «просто держать репозиторий» уже есть много инструментов самого разного масштаба.
+1 к iavael
в RHEL-based дистрибутивах поднять свой yum repo задача на полчаса. В него выкладываются все кастомные rpm пакеты, собранные заранее с помощью rpmbuild с необходимыми ключами. На машинах, где планируется ставить эти пакеты, репо прописывается в yum и установка / апдейт выполняются одной командой (yum update).
Вопросов к стороннему платному сервису куда больше, чем плюшек, которые он может принести в потенциале. Другое дело, если проект перевести в опенсорс, и админ вместо (в дополнение к) локальному yum repo поставит красивую веб морду и будет тыкать в нее. Хотя и тут есть сомнения.
в RHEL-based дистрибутивах поднять свой yum repo задача на полчаса. В него выкладываются все кастомные rpm пакеты, собранные заранее с помощью rpmbuild с необходимыми ключами. На машинах, где планируется ставить эти пакеты, репо прописывается в yum и установка / апдейт выполняются одной командой (yum update).
Вопросов к стороннему платному сервису куда больше, чем плюшек, которые он может принести в потенциале. Другое дело, если проект перевести в опенсорс, и админ вместо (в дополнение к) локальному yum repo поставит красивую веб морду и будет тыкать в нее. Хотя и тут есть сомнения.
В конце концов мы решили, что проектом заниматься больше у нас не получится. Сегодня мы приняли решение отдать все наработки проекта в добрые руки.
Монетизация. Заинтересованный читатель скажет а «Где деньги Зин? (с)». Видятся простые и прозрачные схемы монетизации сервиса:
Поставить ограничение для бесплатных аккаунтов в 5 пакетов в репозитории.
В платных аккаунтах добавить возможность сборки с редкими, но нужными модулями например passenger для Nginx.
Можно ограничить обновления на бесплатных учетных записях.
чувствуется некий подвох во всем этом… может автор сам сподобится рассказать какой и не будет играть в угадай-мелодию?
Монетизация. Заинтересованный читатель скажет а «Где деньги Зин? (с)». Видятся простые и прозрачные схемы монетизации сервиса:
Поставить ограничение для бесплатных аккаунтов в 5 пакетов в репозитории.
В платных аккаунтах добавить возможность сборки с редкими, но нужными модулями например passenger для Nginx.
Можно ограничить обновления на бесплатных учетных записях.
чувствуется некий подвох во всем этом… может автор сам сподобится рассказать какой и не будет играть в угадай-мелодию?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Отдадим проект в хорошие руки