Comments 64
Исправьте: «что вде ошибки в разных программах»
Касательно вопроса в заголовке: это «конюшня».
Каждый выбирает своё.
да-да: «A man was hospitalized with 6 plastic horses up his ass. The doctors described his condition as stable.»
Какое то у вас неправильно представление о коде линукса, априори я считаю его правильным и он делает то что я хочу, и совсем изредка в нем бывают баги и при желании я могу их сам исправить. Парадигма опенсорса что ли получается.
>Какое то у вас неправильно представление о коде линукса, априори я считаю его правильным
попробуйте обновиться до дебиан ехперементала, арчлинупс тестинга или аналога — в сказки быстро перестанете верить.
попробуйте обновиться до дебиан ехперементала, арчлинупс тестинга или аналога — в сказки быстро перестанете верить.
Скажите, вы когда последний раз LKML читали? Лично у меня иногда волосы дыбом становятся. Ах, да, мы тут забыли, попробуйте-ка загрузиться вот с этим патчем и пришлите нам вывод — это лучшее, на что можно рассчитывать («загрузиться с этим патчем» — в смысле, пересобрать ядро с присланным патчем и посмотреть что будет при следующей загрузке на отладочной консоли по последовательному порту). Разумеется, это даже близко не лежало к продакту.
Использование ночных сборок — эта прогулка по минному полю. Оно, конечно, со стороны не так заметно, но поработав разработчиком в команде начинаешь немного иначе относится к ночным билдам.
Сколько раз бывало, клепаешь какую-нибудь хитрую штуку (например рефакторишь некий функционал под работу в потоках), и вот, пятница, вечер. А тебе осталось совсем чуть-чуть. Задержался на часик, чтобы отдыхать с чистой совестью, вроде всё добил, и вот он, долгожданный коммит. А понедельник смотришь что именно ты за коммитил и крайне удивляешься.
Или другой вариант (кстати, более частый): под вечер осталось часа полтора свободного времени, дай пару ошибок закрою из баг-листа. И таки закрываешь. Вот только мозг уже к вечеру не соображает, и легко можно не учесть, что на это место в коде завязан совсем другой функционал совсем в другом месте.
Я, кстати, заметил тут явную корреляцию, вероятность допустить вечером ошибку в новом коде гораздо ниже таковой при исправлении уже существующей ошибки. Предлагал даже после 4-вечера запретить баги фиксить напрочь.
Сколько раз бывало, клепаешь какую-нибудь хитрую штуку (например рефакторишь некий функционал под работу в потоках), и вот, пятница, вечер. А тебе осталось совсем чуть-чуть. Задержался на часик, чтобы отдыхать с чистой совестью, вроде всё добил, и вот он, долгожданный коммит. А понедельник смотришь что именно ты за коммитил и крайне удивляешься.
Или другой вариант (кстати, более частый): под вечер осталось часа полтора свободного времени, дай пару ошибок закрою из баг-листа. И таки закрываешь. Вот только мозг уже к вечеру не соображает, и легко можно не учесть, что на это место в коде завязан совсем другой функционал совсем в другом месте.
Я, кстати, заметил тут явную корреляцию, вероятность допустить вечером ошибку в новом коде гораздо ниже таковой при исправлении уже существующей ошибки. Предлагал даже после 4-вечера запретить баги фиксить напрочь.
>Использование ночных сборок
так проблема в том, что «протестированные» пакеты с точки зрения мейнтейнеров дистрибутива и с точки зрения автора — две большие разницы.
в том же тестинге арча никаких найтли вобщемто нет, но какие чудеса там иногда творяться…
так проблема в том, что «протестированные» пакеты с точки зрения мейнтейнеров дистрибутива и с точки зрения автора — две большие разницы.
в том же тестинге арча никаких найтли вобщемто нет, но какие чудеса там иногда творяться…
Я ничего не имею против прогулки по минному полю в какой-нибудь фотошопящей программе дома. Ну откачусь на версию, если эта падает, делов-то.
Ну, можно накосячить так, что при сохранении с вероятностью отличной от нуля грохается текущий открытый файл.
Именно для этого и придуманы бэкапы средствами LVM.
Ничего страшного, можно взять файл из бекапа. Ведь довольно странно пользоваться экспериментальными версиями программ, и при этом не делать бекапов.
Когда-то давно я работал в четвертой версией 3dsmax'a. У неё была очень замечатальная особенность, если жестко выключить комп, то текущий открытый файл безвозвратно портился.
Поэтому я периодически сохранял файл под другим именем. Ну вот, однажды выключили свет, и у меня от целой кухни осталось половина, я был сильно опечален этим фактом, и тут свет снова выключили. И у меня от всей кухни осталась одна мойка.
Заметьте, это была stable версия.
Впрочем, я вижу пару причин пользоваться не стэйбл:
а) это наличие какой-нибудь жизненно необходимой фичи, которая отсутсвует в текущем стэйбле;
б) исправление критического бага предыдущего стэйбла.
Поэтому я периодически сохранял файл под другим именем. Ну вот, однажды выключили свет, и у меня от целой кухни осталось половина, я был сильно опечален этим фактом, и тут свет снова выключили. И у меня от всей кухни осталась одна мойка.
Заметьте, это была stable версия.
Впрочем, я вижу пару причин пользоваться не стэйбл:
а) это наличие какой-нибудь жизненно необходимой фичи, которая отсутсвует в текущем стэйбле;
б) исправление критического бага предыдущего стэйбла.
Конкретно указанная фича спокойно решается грошовым упсом с мягким шатдауном.
Насчёт критичных багфиксов — большинство мейнтейнеров вменяемых дистрибьютивов делают бэкпорты багфиксов на предыдущую (текущую) версию, я специально раздел про security updates написал.
Насчёт критичных багфиксов — большинство мейнтейнеров вменяемых дистрибьютивов делают бэкпорты багфиксов на предыдущую (текущую) версию, я специально раздел про security updates написал.
Насколько я помню 4й макс делал автобэкапы каждые 5 минут, так что если вы не сделали половину кухни за 5 минут, то успела сохраниться копия, назывались по моему autosave… ;)
я читал про понедельник и техногенные «катастрофы»
взял за правило «понедельник нужно просто пережить и всё»
взял за правило «понедельник нужно просто пережить и всё»
Кстати, это интересно. Для круглосуточных сервисов обычно обновления выкатывают в понедельник, чтобы иметь 5 дней на исправление. Для энтерпрайзнутых обычно в пятницу, чтобы иметь два дня без пользователей для починики (восстановления обратно).
>Для круглосуточных сервисов обычно обновления выкатывают в понедельник
нифига не обычно. IIRC, тот же фейсбук — по средам.
>иметь 5 дней на исправление
а 5 дней все будет продолжать не работать? крутые системы дейплоймента сами откатят рабочую версию на обратно и там чини хоть два месяца.
нифига не обычно. IIRC, тот же фейсбук — по средам.
>иметь 5 дней на исправление
а 5 дней все будет продолжать не работать? крутые системы дейплоймента сами откатят рабочую версию на обратно и там чини хоть два месяца.
А если бага в системе дейплоймента? 5 дней чинить — это лучше, чем два дня ждать, а потом 5 дней чинить. А ломается обычно там, где этого никто не ждёт.
Мы выкатываем все с понедельника по среду до обеда 8)
У нас корпоративное приложение. Мы выкатываем новые версии в ночь с четверга на пятницу. В пятницу на приложение не такая большая нагрузка, как в среду и четверг, но, все же, приложение оттестируется живыми пользователями. И, в то же время, как вы и сказали, дальше идут выходные, за это время можно пофиксить критичные ошибки и выкатить патч.
Корпоративное — это в смысле вашим приложением пользуется только ваша корпорация? Тогда вам проще. Потому что в случае, когда вы выкатываете релиз для клиентов, все обстоит несколько сложнее.
Представьте себе клиента, у которого из-за вашей ошибки образовалось очередь из бабушек человек в 200.
У нас неплохой вариант обкатать новую версию — это внедрение у очередного клиента.
Представьте себе клиента, у которого из-за вашей ошибки образовалось очередь из бабушек человек в 200.
У нас неплохой вариант обкатать новую версию — это внедрение у очередного клиента.
Корпоративное — это в смысле энтерпрайз. Им пользуются корпоративные клиенты.
Естественно, что наше приложение хорошо тестируется перед тем, как выкатить его в продакшн. А выкатываем мы его перед пятницей как раз для того, чтобы минимизировать риски. Если же это делать перед выходными, то для нас это равнозначно выкатыванию перед понедельником, т.к. за выходные ничего не изменится: приложение в этот период просто-напросто никто не использует.
В то же время, если выкатывать перед пятницей, то, если что-то пойдет не так, то произойдет это в наименее насыщенный день; к тому же, после этого дня у нас будут выходные, чтобы не спеша исправить ошибку.
Естественно, что наше приложение хорошо тестируется перед тем, как выкатить его в продакшн. А выкатываем мы его перед пятницей как раз для того, чтобы минимизировать риски. Если же это делать перед выходными, то для нас это равнозначно выкатыванию перед понедельником, т.к. за выходные ничего не изменится: приложение в этот период просто-напросто никто не использует.
В то же время, если выкатывать перед пятницей, то, если что-то пойдет не так, то произойдет это в наименее насыщенный день; к тому же, после этого дня у нас будут выходные, чтобы не спеша исправить ошибку.
Надо всё таки внятно описать о каких вещах вы говорите: публичный хостинг или что-то ещё. И, прошу, не употребляйте слово «энтерпрайз», оно тут неуместно.
Все ваши рецепты быстро становятся нерабочими и даже вредными, когда речь идет про деплой серверов под одно приложение. Там уже не админы, а программисты заказывают праздник и программисты заказывают сборку самых свежих пакетов с нужными изменениями, возможно даже собственными.
Приведу пример. libx264 (удаленная из дебиана вовсе) за последние 2 года улучшилась в производительности на 30%. Это означает, что можно кодировать на несколько каналов больше тем же железом. Что означает больше профита за те же траты. Если админ отказывается обновить, мотивируя «идеологией stable», то надо искать другого админа, который не мешает извлекать прибыль.
Все ваши рецепты быстро становятся нерабочими и даже вредными, когда речь идет про деплой серверов под одно приложение. Там уже не админы, а программисты заказывают праздник и программисты заказывают сборку самых свежих пакетов с нужными изменениями, возможно даже собственными.
Приведу пример. libx264 (удаленная из дебиана вовсе) за последние 2 года улучшилась в производительности на 30%. Это означает, что можно кодировать на несколько каналов больше тем же железом. Что означает больше профита за те же траты. Если админ отказывается обновить, мотивируя «идеологией stable», то надо искать другого админа, который не мешает извлекать прибыль.
М… в нашей дискуссии мне примерно это же и говорили. Мол, мы сами разберёмся и не мешайте нам работать.
Однако, тут возникает такая простая вещь: приложение это в MBR записано? Или на файловую систему, под управлением ядра, userspace'а с динамической линковкой на libc определённых версий, пачкой init.d скриптов, udev'ом и т.д.? И что программисты будут делать, если оно после очередного наивного apt-get update && apt-get upgrade (сделанного 3 недели назад) при внеочередной перезагрузке не загрузилось, мигает лампочками, срёт на консоль трейсами и вообще, орёт и сисю просит? Собственно, вопрос, кто в ЭТОМ случае будет отвечать за «мешает извлекать прибыль»?
Я не говорю, что нужно всё выпилить намертво и юзать только дефолтное. Если что-то нужно — это нужно долго тестировать, проверять и т.д.
В приведённом вами случае нужно смотреть внимательно на два фактора:
1) Количество занятых серверов под приложение
2) Скорость роста числа серверов
3) Стоимость простоя конфигурации
Я не могу сказать про эту библиотеку ничего специфичного — не работал. Если вопрос только в том, чтобы её одну установить, да ещё только для одного-единственного приложения, обслуживающегося своими силами, то я бы согласился, т.к. «не запустился/упал/мусорит» всё равно целиком и полностью в компетенции программистов.
А вот если бы вопрос стоял «да ну нафиг этот дебиан, давайте убунты поставим», то я бы 30% прироста в обмен на большую стабильность запросто отдал, и более того, отстоял в дискуссии.
PS Вы перепутали, 30% ускорения — это снижение издержек, а не получение прибыли. Если прибыль есть, то издержки второстепенны. Если нет — то зачем всё это делается?
Однако, тут возникает такая простая вещь: приложение это в MBR записано? Или на файловую систему, под управлением ядра, userspace'а с динамической линковкой на libc определённых версий, пачкой init.d скриптов, udev'ом и т.д.? И что программисты будут делать, если оно после очередного наивного apt-get update && apt-get upgrade (сделанного 3 недели назад) при внеочередной перезагрузке не загрузилось, мигает лампочками, срёт на консоль трейсами и вообще, орёт и сисю просит? Собственно, вопрос, кто в ЭТОМ случае будет отвечать за «мешает извлекать прибыль»?
Я не говорю, что нужно всё выпилить намертво и юзать только дефолтное. Если что-то нужно — это нужно долго тестировать, проверять и т.д.
В приведённом вами случае нужно смотреть внимательно на два фактора:
1) Количество занятых серверов под приложение
2) Скорость роста числа серверов
3) Стоимость простоя конфигурации
Я не могу сказать про эту библиотеку ничего специфичного — не работал. Если вопрос только в том, чтобы её одну установить, да ещё только для одного-единственного приложения, обслуживающегося своими силами, то я бы согласился, т.к. «не запустился/упал/мусорит» всё равно целиком и полностью в компетенции программистов.
А вот если бы вопрос стоял «да ну нафиг этот дебиан, давайте убунты поставим», то я бы 30% прироста в обмен на большую стабильность запросто отдал, и более того, отстоял в дискуссии.
PS Вы перепутали, 30% ускорения — это снижение издержек, а не получение прибыли. Если прибыль есть, то издержки второстепенны. Если нет — то зачем всё это делается?
Вот сколько ни работал, а наивный apt-get update upgrade делали при мне только и исключительно админы. Программистам надо, что бы работал тот код, который они выкатывают и что бы админы не мучали своими долбаными файрволами, которые ни от чего не спасают.
Поэтому у админа вообще говоря непростая задача: надо удовлетворять прихоти программистов по требованиям версий и удовлетворять свои хотелки по apt-get update-ам, не ломая ничего.
Поэтому у админа вообще говоря непростая задача: надо удовлетворять прихоти программистов по требованиям версий и удовлетворять свои хотелки по apt-get update-ам, не ломая ничего.
Пардон, да, apt-get это я зря сказал.
ок, без apt-get. Накатывают апдейт (софта). Оно работает. Три недели. Дальше выключают свет на профилактику (на 5 минут), а при следющей загрузке весь кластер «сисю просит».
Виновные? Разбор полётов? Даун на 12 часов ради 30% экономии на железках?
ок, без apt-get. Накатывают апдейт (софта). Оно работает. Три недели. Дальше выключают свет на профилактику (на 5 минут), а при следющей загрузке весь кластер «сисю просит».
Виновные? Разбор полётов? Даун на 12 часов ради 30% экономии на железках?
Ок, перефразирую по-другому.
libx264 из stable репозитория ВООБЩЕ не справляется с задачей на современном железе. Бизнес не может стоять и по хотелке админа ждать, когда интел выпустить процессор на 30% быстрее, что бы начать делать деньги, поэтому НАДО поставить свежую библиотеку, которая работает только и исключительно с tcmalloc, который несовместим с glibc раньше, чем squeeze. Если админ продолжает кочевряжиться, продолжаем поиски админа, который не мешает работе.
Это вполне реальная ситуация.
Если при следующей загрузке весь кластер «сисю просит», значит админы берут и чинят. Если даун на 12 часов, значит отгребают люлей, почему всё так хреново настроено. То, что пишут программисты обычно запускается простым runit-ом.
libx264 из stable репозитория ВООБЩЕ не справляется с задачей на современном железе. Бизнес не может стоять и по хотелке админа ждать, когда интел выпустить процессор на 30% быстрее, что бы начать делать деньги, поэтому НАДО поставить свежую библиотеку, которая работает только и исключительно с tcmalloc, который несовместим с glibc раньше, чем squeeze. Если админ продолжает кочевряжиться, продолжаем поиски админа, который не мешает работе.
Это вполне реальная ситуация.
Если при следующей загрузке весь кластер «сисю просит», значит админы берут и чинят. Если даун на 12 часов, значит отгребают люлей, почему всё так хреново настроено. То, что пишут программисты обычно запускается простым runit-ом.
В смысле не справляется? Кластеры отменили?
Насчёт «админы чинят» — да, разумеется. Но потом идёт разбор полётов, и если выясняется, что добрый программист неглядя сделал make install для приложения, то…
Кстати, то, что пишут программисты определяется типом задачи. Вон, у нас несколько месяцев писали, чтобы клиенты в панельки могли увидеть сообщения ядра при загрузке виртуальной машины. А в перспективе будут ещё более хардкорные вещи делать.
Понимаете, вы сейчас хотите занять позицию «программисты боги, адимны — обслуживающий персонал». В современной реальности это не так, и стабильность работы системы зависит от совместных усилий. Играть «кто важнее — водитель или навигатор» в гонках, как бы чревато.
Насчёт «админы чинят» — да, разумеется. Но потом идёт разбор полётов, и если выясняется, что добрый программист неглядя сделал make install для приложения, то…
Кстати, то, что пишут программисты определяется типом задачи. Вон, у нас несколько месяцев писали, чтобы клиенты в панельки могли увидеть сообщения ядра при загрузке виртуальной машины. А в перспективе будут ещё более хардкорные вещи делать.
Понимаете, вы сейчас хотите занять позицию «программисты боги, адимны — обслуживающий персонал». В современной реальности это не так, и стабильность работы системы зависит от совместных усилий. Играть «кто важнее — водитель или навигатор» в гонках, как бы чревато.
Я вообще не понимаю о чем спор :)
Если вдруг обнаружился приток посетителей и деньги на железо закончились, то все вместе админы и программисты в срочном порядке переходят на другую версию. Причем все вместе еще потом и тестируют.
По-моему, холивар по поводу профессий.
Есть бизнес у него есть четкие цели, а все другие персонал, который реализует эти цели. Поэтому сортируем факторы по приоритетам, затратам и действуем в интересах бизнеса :)
Если вдруг обнаружился приток посетителей и деньги на железо закончились, то все вместе админы и программисты в срочном порядке переходят на другую версию. Причем все вместе еще потом и тестируют.
По-моему, холивар по поводу профессий.
Есть бизнес у него есть четкие цели, а все другие персонал, который реализует эти цели. Поэтому сортируем факторы по приоритетам, затратам и действуем в интересах бизнеса :)
Конечно же отменили. Есть вещи, которые не масштабируются, такие как транскодирование видео. Целый датацентр не поможет, если не справляется _один_ компьютер.
Администраторы — это именно обслуживающе-эксплуатационный персонал.
Программисты — те, кто делают инструмент для работы компании. Админы следят, что бы он работал.
Администраторы — это именно обслуживающе-эксплуатационный персонал.
Программисты — те, кто делают инструмент для работы компании. Админы следят, что бы он работал.
Да ладно, не пугайте меня, пожалуйста. Если задача параллелится в SMP, то она параллелится и в NUMA.
Далее, вы считаете, что администраторы… а теперь я хочу узнать, чем по-вашему занимаются администраторы.
Например, когда вам нужно развернуть хорошенький такой географический кластер на пару континентов, кто этим занимается? _обслуживающий_ персонал? Вы уверены?
Вообще, как я сказал, спор напоминает спор «кто важнее» — навигатор или пилот на рейсе. Разумеется, если навигатор будет тупить, то пилот либо попадёт в аварию, либо безнадёжно опоздает. Разумеется, если пилот будет не те педали жать, то что бы не делал навигатор, «оно не взлетит». И разумеется, они могут делать работу друг друга, только хуже.
Администратор обычно довольно сносно кодит, программист если приспичит, в конфиге пейскипера разберётся. Но знать тонкости — это и есть профессия.
Далее, вы считаете, что администраторы… а теперь я хочу узнать, чем по-вашему занимаются администраторы.
Например, когда вам нужно развернуть хорошенький такой географический кластер на пару континентов, кто этим занимается? _обслуживающий_ персонал? Вы уверены?
Вообще, как я сказал, спор напоминает спор «кто важнее» — навигатор или пилот на рейсе. Разумеется, если навигатор будет тупить, то пилот либо попадёт в аварию, либо безнадёжно опоздает. Разумеется, если пилот будет не те педали жать, то что бы не делал навигатор, «оно не взлетит». И разумеется, они могут делать работу друг друга, только хуже.
Администратор обычно довольно сносно кодит, программист если приспичит, в конфиге пейскипера разберётся. Но знать тонкости — это и есть профессия.
Как показывает моя практика, выполняю работу программиста и админа, разбирать проблемы админа гораздо сложнее, одно дело откатить версию продукта и скомпилировать старую версию, другое дело откатить библиотеки и зависимости, которые поставлены уже.
Да и практически всегда, когда сервис упал — это огромные убытки, а когда есть баг даже критикал — день можно подождать.
Имхо админам можно посочувствовать, тем более, что часто они ограничены в железных ресурсах, что мешает провести, нормальное тестирование продукта в новых условиях.
Да и практически всегда, когда сервис упал — это огромные убытки, а когда есть баг даже критикал — день можно подождать.
Имхо админам можно посочувствовать, тем более, что часто они ограничены в железных ресурсах, что мешает провести, нормальное тестирование продукта в новых условиях.
Пресловутая libx264 именно под Debain'ом вообще отдельный разговор. Доходило до того что на одной и той же машине она собиралась без ошибок под одним ядром, и не собиралась под другим. Не говоря уже о совсем странном софте типа php_ffmpeg, который вообще собирается через раз в зависимости от пятен на Солнце и магнитных бурь
э… _собиралась_? Вы не путаете? Обычно такая путаница бывает из-за версии gcc и наличия заголовочных файлов. (хотя зачем заголовки ядра userspace библиотеке?). Поскольку при компиляции код приложения не исполняется, то вопрос может быть только в gcc. Решается обычно через export CC=/usr/bin/gcc-4.3 или какое вам там понравится.
Не — ну про ядро я, конечно, немного преувеличил. Дело было на lenny, который был в то время testing и поэтому в нем часто менялись какие-то либы и т.п. В итоге — собранные в времена testing в пакеты ffmpeg, x264 и всякие обвязки типа php-ffmpeg и все такое (собранные не с первого раза ввиду поисков разных зависимостей, подбора конекретных версий который заработали вместе) — отказались работать/глючили/не собирались вместе когда он стал stable.
libx264 и прочие подобные вещи лучше сразу собирать руками в /usr/local или куда-нибудь ещё. Не советую надеяться на мейнтейнеров.
типичная ошибка программиста — засунуть всё в /usr/local (спасибо, что в local, а не make install в /usr/lib).
Правильно: собрать свой пакет и запретить установку конфлитующих. Вместо того, чтобы потом ругаться «а зачем ты поставил новую версию библиотеки из-за которой у меня всё поломалось» правильно сделать пакет, где явно прописать зависимости. Это нужно, это нужно не старее такой-то версии, это не новее такой-то, это строго такой-то версии, а с этим мы конфликтуем (потому что на одном порту слушаем, например). С библиотеками аналогично.
Правильно: собрать свой пакет и запретить установку конфлитующих. Вместо того, чтобы потом ругаться «а зачем ты поставил новую версию библиотеки из-за которой у меня всё поломалось» правильно сделать пакет, где явно прописать зависимости. Это нужно, это нужно не старее такой-то версии, это не новее такой-то, это строго такой-то версии, а с этим мы конфликтуем (потому что на одном порту слушаем, например). С библиотеками аналогично.
Отличная статья.
Я из нее еще раз подтвердил свою концепцию: разница в подходе к разработке информационной системы программистами и системными администраторами.
В идеале, это как два разных полюса:
Программисты создают требуемые модули, при необходимости переписывают существующие и исправляют ошибки. Главный подход — если что-то не работает, это можно исправить, переписав неработающий модуль.
Системные администраторы используют существующие модули и внешние приложения. В большинстве случаев имеющееся приложение рассматривается как «черный ящик»: на заданные входные параметры выдаются определенные результаты. Если результаты не те или не в том формате — нужно или «сменить черный ящик», или «добавить еще один», который будет уже результаты первой программы приводить в нужный формат.
Именно по этой причине мои идеи, которые я озвучиваю программистам, иногда кажутся для них странными и непонятными (я долгое время был системным администратором). А они, часто, основаны на использовании дополнительных модулей вместо переписывания имеющегося.
Естественно, что в жизни полюсов не бывает, а бывает какой-то компромисс. Но понимать причины решений той или иной стороны — это очень важно.
Я из нее еще раз подтвердил свою концепцию: разница в подходе к разработке информационной системы программистами и системными администраторами.
В идеале, это как два разных полюса:
Программисты создают требуемые модули, при необходимости переписывают существующие и исправляют ошибки. Главный подход — если что-то не работает, это можно исправить, переписав неработающий модуль.
Системные администраторы используют существующие модули и внешние приложения. В большинстве случаев имеющееся приложение рассматривается как «черный ящик»: на заданные входные параметры выдаются определенные результаты. Если результаты не те или не в том формате — нужно или «сменить черный ящик», или «добавить еще один», который будет уже результаты первой программы приводить в нужный формат.
Именно по этой причине мои идеи, которые я озвучиваю программистам, иногда кажутся для них странными и непонятными (я долгое время был системным администратором). А они, часто, основаны на использовании дополнительных модулей вместо переписывания имеющегося.
Естественно, что в жизни полюсов не бывает, а бывает какой-то компромисс. Но понимать причины решений той или иной стороны — это очень важно.
Например, ubuntu позволяет себе менять версии ПО;
Не сказал бы. По крайней мере пакеты, которые для меня важны, обновляются на новые «мажорные» (то есть с новой функциональностью) версии только со сменой версии дистрибутива, и то не всегда на последнюю на момент замораживания, не говоря о моменте релиза.
А так, в апдейтах, конечно не только исправления безопасности, но исправления, например, утечек памяти или ошибок в какой-нибудь локализации.
Э… не совсем так. Убунта позволяет себе обновлять userspace-софт на новые версии с новыми фичами. Кстати, иногда дебиан делает то же самое, но очень редко и по очень важным поводам. Самый протухший стабильный — это Centos/RHEL. Там до сих пор python2.4 по-дефолту (от чего наши программисты как раз в восторге и были).
Интересная статья!
У меня сейчас возникла задача следить за зоопарком серверов и софта с целью выявления уязвимого софта и последующего его обновления.
Может существуют готовые концепции/философии для решения этой задачи? У меня на уме пока что только такой подход:
У меня сейчас возникла задача следить за зоопарком серверов и софта с целью выявления уязвимого софта и последующего его обновления.
Может существуют готовые концепции/философии для решения этой задачи? У меня на уме пока что только такой подход:
(извиняюсь за разделенный на два пост — глюк хабра):
1) Составить в виде таблицы:
— Список всех серверов
— Список служб компании на всех серверах
— Для каждой службы узнать версию и вписать в таблицу
— Пометить особым цветом те службы, которые опубликованы наружу и доступны миру (неважно запароленны или нет)
2) При помощи специальных сайтов проверить весь серверный софт на предмет уязвимостей
3) Обновить уязвимые версии
X) Проводить процедуру минимум раз в месяц.
Кто что думает на этот счет?
1) Составить в виде таблицы:
— Список всех серверов
— Список служб компании на всех серверах
— Для каждой службы узнать версию и вписать в таблицу
— Пометить особым цветом те службы, которые опубликованы наружу и доступны миру (неважно запароленны или нет)
2) При помощи специальных сайтов проверить весь серверный софт на предмет уязвимостей
3) Обновить уязвимые версии
X) Проводить процедуру минимум раз в месяц.
Кто что думает на этот счет?
Я бы предложил решить проблему проще:
обновить всё (и делать это регулярно)
известный список аккаунтов, с которых есть доступ снаружи к известному списку сервисов.
обновить всё (и делать это регулярно)
известный список аккаунтов, с которых есть доступ снаружи к известному списку сервисов.
Ну так ведь, чтобы обновлять все, нужно знать что обновляешь — можно о чем-то и забыть. К тому же, был ни один печальный опыт, когда обновляешь «все», а потом куча сервисов вдруг перестает работать. Поэтому, обновлять все окружение сервера — ой как не вариант…
Из последнего: обновил Courier IMAP с 4.1.х до 4.3.х — перестали работать shared folders, пока не поставил 4.2 через portdowngrade.
Из последнего: обновил Courier IMAP с 4.1.х до 4.3.х — перестали работать shared folders, пока не поставил 4.2 через portdowngrade.
Я буквально вчера писал про стабильность. Я не помню ситуаций, чтобы что-то капитально ломалось в базовом серверном при накатывании апдейтов консервативных дистрибьютивов.
Основное: не надо менять версии, нужно накатывать security updates, они для этого и есть во всех приличных дистрибьютивах. Извините за прямоту, но слова «portdowngrade» мне говорит о том, что вы используете мягко скажем, нестабильный дистрибьютив.
Основное: не надо менять версии, нужно накатывать security updates, они для этого и есть во всех приличных дистрибьютивах. Извините за прямоту, но слова «portdowngrade» мне говорит о том, что вы используете мягко скажем, нестабильный дистрибьютив.
Sign up to leave a comment.
Что такое 'stable'?