О, а что не так с тоном? А то там минусовали поначалу, возможно как раз это.
> Запас мощностей в 2 раза нужен всегда. Этот подход используется в гугле.
Этот подход используется в гугле в настоящее время, когда они уже не попадают под определение «стартап» в том значении, которое имеется ввиду в статье. У меня речь про самых-самых маленьких, скажем так.
За подачу наверное.
Каждый совет, взятый по отдельности — вредным не является, по сути.
Надо рассчитывать нагрузки до релиза, чтобы не получился хабра/лепро/чтотоещё-эффект, когда после статьи в «Я пиарюсь» сервис падает, можно срезать углы на автоматизации и мониторинге (держа всё же задачи в бэклоге), да и облачные сервисы совсем не так плохи до определённого момента.
Статья родилась после того, как в нескольких проектах закончились деньги, а на самоокупаемость так и не вышли — и мне пришлось перетаскивать всё из разных мест на один VDS. То ещё удовольствие.
Ну, с PHP я бы так не горячился. Питон/Перл, да тот же Руби, на котором остальной проект писан — было бы идеальным решением (не потому, что PHP плох, но потому, что Питон и Перл есть вообще везде, Руби — язык проекта, т.е. тоже в наличии по-умолчанию).
> И для вас стало сложностью перейти от сорцов к общим для всех серверов бинарникам?
Да. Ибо ленив я, неохота мне даже один раз пересобирать систему с целью обновления, ненужная трата времени это.
> Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам.
Ну вот я и решил для себя — в тех проектах, в которых я учавствую/учавствовал это не нужно.
> Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие.
Про Дебиан не знаю, для CentOS — не вижу проблем вообще. Пример с Nginx + openssl к слову показательный (хотя и надуманый ИМХО, ни разу не приходилось так извращаться). Решается выкладыванием своей сборки openssl рядом с Nginx, с кастомными путями (привет, слоты Генту), и пишем правильный spec для Nginx (чтоб линковался не с системным openssl, а с тем, что нужно).
> В третьих systemd невозможно выпилить а это тянет за собой кучу проблем.
Зачем его выпиливать? Его просто готовить нужно научиться, всего делов. Мне SysV init в CentOS 3 после фряшных rc-скриптов тоже непонятен был — ничо, разобрался.
> Полностью убитые зависимости из-за ошибок в пакетах.
За 12 лет сталкивался с таким ровно один раз на Ubuntu 6.06. Возможно в Debian sid, или Fedora rawhide такое до сих пор есть — не в курсе, не пользуюсь bleeding edge версиями.
> Невозможность обновления из-за отсутствия поддержки слотов для библиотек.
Слоты в Генту конечно сила, этого не отнять. Но реальные юзкейсы слотов в других дистрах уже пару лет как покрыты — version pinning в Дебиан, Software Collections в Федоре/ЦентОС, плюс механизм alternatives что там, что там. Это если говорить про Python 2/3 например, или подобное. Зачем мне слотировать glibc (или любую другую библиотеку, от которой всё равно пол-системы зависит) — ума не приложу.
> Крах сервисов при обновлении glibc
Инфа из начала двухтысячных? Ни разу на моей практике yum update glibc не приводил к «краху сервисов».
> Вы уж извините, но вы просто не осилили работу с генту на проде
Опыт с Gentoo — около пяти лет, так что скорее не захотел. Есть более интересные и полезные задачи. Для прода никогда не буду никому советовать source-based дистр, и сам не буду использовать — в 99% случаев это принесёт скорее вред, чем пользу, и сузит количество людей, способных поддерживать это окружение после меня.
> напороться на серьезную проблему при update системы сильно уменьшается
Что есть «серьёзная проблема»?
> организует кэш бинарных сборок на NFS и автоматизирует ежедневное-еженедельное обновление gentoo
Ага, а кто потом этот кэш обслуживать будет? Ну и потом — чем сценарий с кешем отличается от бинарного дистрибутива тогда? Тем, что «минимум зависимостей»? Сомнительное преимущество.
> В случае бинарных дистрибутивов велик риск привести систему в убитое состояние
Это с чего вдруг?
> Временной период существования известных, не закрытых проблем безопасности, существенно выше.
В теории — да. На практике — Дебиан/РедХат на второй-третий день выпускают обновление, yum upgrade/apt-get dist-upgrade — и всё в шоколаде. В случае более-менее большого деплоя Генту (5+ машин) у одного человека те же два-три дня займёт обновить этот зоопарк.
Ну и стоимость для бизнеса не забываем. Клиентам обычно неважно, на чём крутится их интернет-магазин, главное чтобы было стабильно. Плюс лично мне как админу приятней ковыряться с чем-то новым, или улучшать существующее, а не проводить часы с емержем в зубах. Гента — не для бизнеса, бессысленно это.
Плохо всё было по производительности. Упёрлись в пару говённо сделаных реализаций, и при 400-500 пользователей динамическая часть сайта тормозила страшно.
Отказоустойчивости не было, если падал один сервис — ложилось всё.
Ну количество человеко-часов затраченое на поддержку Gentoo всё-ж поболее будет, чем на поддержку rpm- или deb-based дистрибутива. «Какой дистрибутив» в контексте «Debian или CentOS» и правда не имеет значения, но вот «source-based или binary» — очень даже. Я про это немного во второй части пишу.
wut? Для pacman только и нужно было что ключи -Sy для установки пакетов. С GPG ключами (если пользовался yum/apt) тоже не проблема разобраться быстро.
systemd лично мне нужен был только в задании с MariaDB, в остальных случаях прокатывало просто пустить демона.
Вообще-то нет, прекратите спекулировать.
Это уже обсуждалось: seclists.org/oss-sec/2014/q3/659
Возможность запихивать функции в переменные — фича интерпретатора, и довольно используемая: codesearch.debian.net/search?q=export\+-f
Говорить, что это уязвимость — то же самое что считать дырой возможность использовать SSH-авторизацию по ключам, которые не защищены паролем. Или возможность сделать «yum remove glibc».
Смысл в том, что если у атакующего есть возможность выставить в окружении переменную ls — то скорее всего у него уже есть достаточно контроля над системой, и экспорт функции — последнее, о чём стоит в данном случае беспокоиться.
Все остальные дыры, о которых речь в посте позволяли выполнять вредоносный код *без* вмешательства — если в окружении есть переменная "() { :; };echo zlo" — echo zlo будет выполнено при любых раскладах на непатченой системе. То, что описывает Mark R Bannister — можно рассматривать как hardening, не более.
О, а что не так с тоном? А то там минусовали поначалу, возможно как раз это.
> Запас мощностей в 2 раза нужен всегда. Этот подход используется в гугле.
Этот подход используется в гугле в настоящее время, когда они уже не попадают под определение «стартап» в том значении, которое имеется ввиду в статье. У меня речь про самых-самых маленьких, скажем так.
Спасибо за фразу, распечатал и повесил на стенку перед глазами :D
> Когда для одного конкурса грантов
Вот тут я бы просил «по максимуму», если честно. Дадут всё равно меньше, чем просишь — зато как раз хватит на реальные потребности.
Каждый совет, взятый по отдельности — вредным не является, по сути.
Надо рассчитывать нагрузки до релиза, чтобы не получился хабра/лепро/чтотоещё-эффект, когда после статьи в «Я пиарюсь» сервис падает, можно срезать углы на автоматизации и мониторинге (держа всё же задачи в бэклоге), да и облачные сервисы совсем не так плохи до определённого момента.
Статья родилась после того, как в нескольких проектах закончились деньги, а на самоокупаемость так и не вышли — и мне пришлось перетаскивать всё из разных мест на один VDS. То ещё удовольствие.
Да. Ибо ленив я, неохота мне даже один раз пересобирать систему с целью обновления, ненужная трата времени это.
> Нужно ли это если есть готовые бинарные дистры? Каждый конечно решает сам.
Ну вот я и решил для себя — в тех проектах, в которых я учавствую/учавствовал это не нужно.
> Вот только поддерживать свой репозиторий на debian/centos то еще удовольствие.
Про Дебиан не знаю, для CentOS — не вижу проблем вообще. Пример с Nginx + openssl к слову показательный (хотя и надуманый ИМХО, ни разу не приходилось так извращаться). Решается выкладыванием своей сборки openssl рядом с Nginx, с кастомными путями (привет, слоты Генту), и пишем правильный spec для Nginx (чтоб линковался не с системным openssl, а с тем, что нужно).
Зачем его выпиливать? Его просто готовить нужно научиться, всего делов. Мне SysV init в CentOS 3 после фряшных rc-скриптов тоже непонятен был — ничо, разобрался.
За 12 лет сталкивался с таким ровно один раз на Ubuntu 6.06. Возможно в Debian sid, или Fedora rawhide такое до сих пор есть — не в курсе, не пользуюсь bleeding edge версиями.
> Невозможность обновления из-за отсутствия поддержки слотов для библиотек.
Слоты в Генту конечно сила, этого не отнять. Но реальные юзкейсы слотов в других дистрах уже пару лет как покрыты — version pinning в Дебиан, Software Collections в Федоре/ЦентОС, плюс механизм alternatives что там, что там. Это если говорить про Python 2/3 например, или подобное. Зачем мне слотировать glibc (или любую другую библиотеку, от которой всё равно пол-системы зависит) — ума не приложу.
> Крах сервисов при обновлении glibc
Инфа из начала двухтысячных? Ни разу на моей практике yum update glibc не приводил к «краху сервисов».
Опыт с Gentoo — около пяти лет, так что скорее не захотел. Есть более интересные и полезные задачи. Для прода никогда не буду никому советовать source-based дистр, и сам не буду использовать — в 99% случаев это принесёт скорее вред, чем пользу, и сузит количество людей, способных поддерживать это окружение после меня.
Не все умеют правильно настроить USE-флаги.
> напороться на серьезную проблему при update системы сильно уменьшается
Что есть «серьёзная проблема»?
> организует кэш бинарных сборок на NFS и автоматизирует ежедневное-еженедельное обновление gentoo
Ага, а кто потом этот кэш обслуживать будет? Ну и потом — чем сценарий с кешем отличается от бинарного дистрибутива тогда? Тем, что «минимум зависимостей»? Сомнительное преимущество.
> В случае бинарных дистрибутивов велик риск привести систему в убитое состояние
Это с чего вдруг?
> Временной период существования известных, не закрытых проблем безопасности, существенно выше.
В теории — да. На практике — Дебиан/РедХат на второй-третий день выпускают обновление, yum upgrade/apt-get dist-upgrade — и всё в шоколаде. В случае более-менее большого деплоя Генту (5+ машин) у одного человека те же два-три дня займёт обновить этот зоопарк.
Ну и стоимость для бизнеса не забываем. Клиентам обычно неважно, на чём крутится их интернет-магазин, главное чтобы было стабильно. Плюс лично мне как админу приятней ковыряться с чем-то новым, или улучшать существующее, а не проводить часы с емержем в зубах. Гента — не для бизнеса, бессысленно это.
Отказоустойчивости не было, если падал один сервис — ложилось всё.
Продолжение: https://habrahabr.ru/post/317408/
systemd лично мне нужен был только в задании с MariaDB, в остальных случаях прокатывало просто пустить демона.
Это уже обсуждалось: seclists.org/oss-sec/2014/q3/659
Возможность запихивать функции в переменные — фича интерпретатора, и довольно используемая: codesearch.debian.net/search?q=export\+-f
Говорить, что это уязвимость — то же самое что считать дырой возможность использовать SSH-авторизацию по ключам, которые не защищены паролем. Или возможность сделать «yum remove glibc».
Смысл в том, что если у атакующего есть возможность выставить в окружении переменную ls — то скорее всего у него уже есть достаточно контроля над системой, и экспорт функции — последнее, о чём стоит в данном случае беспокоиться.
Все остальные дыры, о которых речь в посте позволяли выполнять вредоносный код *без* вмешательства — если в окружении есть переменная "() { :; };echo zlo" — echo zlo будет выполнено при любых раскладах на непатченой системе. То, что описывает Mark R Bannister — можно рассматривать как hardening, не более.