> Нет, не враньё, буквально две недели назад поднял минорную (!) версию php
> на 3 единицы, и сразу перестал работать очень важный сайт для
> внутренних нужд. Я ведь не придумываю, а говорю причины за которые
> уже получал втык.Я вообще на 5.4 даже смотрю, зачем, если есть 5.3? Потестить на себе какие-то рюшечки и фишечки, которые еще ломают и переламывают?
> Меня вообще возмущает Ваше отношение. Что значит вранье? Я лгу тут по-Вашему?
> Или не понимаю что происходит? Вы сами то понимаете, что речь
> не про хостинг, где крутятся сайты, среди которых 95% какие-то CMS-ки,
> а о что ни есть само-кривописных монструозных сайтах, где никому не
> было дела до рекомендаций и warning-ов, где критически необходимо сохранять работоспособность
> _всего_ функционала.
Врать можно и заблуждаясь. 95% - это много, если бы все было так, да еще юзеры обновляли cms-ки... А то ведь есть и такое, что построен сайт на распространенной cms-ке, но разработчики сайта влезли в ее код, что-то убрали, что-то переписали, что-то дописали и просто взять и обновить ее не получится... Такое сплошь и рядом и это можно считать за криворукую писульку или нет?
> Ну, тут много проблем. Во-первых ровно та же, что и объяснялась для
> сайтов для внутренних нужд. Во-вторых, вам прямо _никогда_ не требуется останавливать
> ненадолго работу систему при обновлении, так что ли? Есть например проект
> федеральных масштабов. Софт там морально давно устаревший, там систему нужно обновлять
> весьма кардинально, о чём я неоднократно высказывал своё мнение. Но "заказчики"
> по этому проекту, считают, что его лучше не трогать, ибо в
> следующем году проект заканчивает своё существование.
Если мне бы пришла по наследству такая система и через год она бы была выведена из строя, то я бы туда даже пальцем не сунулся, зачем, если поддерживать ее не придется?
> Но даже если абстрагироваться об этих федеральных проектах о которых я просто
> не могу ничего толком конкретного говорить (ибо NDA), то можно спутиться
> до обычного ftp.ru.debian.org. Безопасные обновления проводить - пожалуйста, а требующие
> хотя бы минутной остановки сервисов пытаемся избегать насколько это возможно.
тут проблему решает резервирование, если уж говорить о HA.
> Ещё пример, давай посмотрим на yandex:
> [xaionaro@imperium ~]$ telnet mirror.yandex.ru 80
> [...]
> <hr><center>nginx/1.1.8</center>
> [...]
> Что-то не похоже это на ежемесячное обновление. А знаете почему? Потому что
> не подвержено уязвимостям и _работает_!
да, там уязвимость есть только в ngx_http_mp4_module. Я не знаю, с чего вы взяли, что я призываю что-то обновлять если нет уязвимостей. Обновлять ради обновления? Ну извините, это не мой путь... Да, обновлять нужно и не уязвимые системы/софт, но только тогда, когда у них заканчивается период поддержки разработчиком.
>>> Есть ресурсы непубличные (неглючные и невзламываемые), которые работают и трогать которые вообще не за чем.
>> Распространенное заблуждение, оставим это на вашей совести.
> Ну млин, есть, например, ресурс с картой коммутаторов и mrtg-шными графиками, где
> по IP-адресу разрешён доступ только из нашего управления + где закрыто
> всё что только можно и вход всё-равно по паролю. В чём
> заблуждение? Как я сказал, когда находится какая-то жёсткая уязвимость (которая даже
> такую систему подвергает опасности), то проводятся обязательные обновления (даже таких
> систем).
ну если проводится, то и флаг вам в руки, только проводить обновление уязвимостей нужно своевременно, а не раз в год.
>>> Есть, например, у нас расчётный кластер, где задачи считаются по несколько месяцев.
>>> Там проводить профилактику раз в месяц, это значит просто убить всю
>>> работу на кластере.
>> Выводи из кластера, для обновления, можно не все машины разом, а по
>> одной.
> Вы издеваетесь? Вы вообще знаете что такое HPC? Вы понимаете к чему
> там приводит гетерогенность систем? Да и даже если обновлять кластер по
> узлам по-штучно, то всё-равно большинство узлов не будут обновляться по несколько
> месяцев, ибо считаемые задачи. Что приводит по сути к той схеме
> обновления, о которой я сказал вначале.
у меня HA, а не HPC, поэтому со мной тут можно и не разговаривать, я дуб и могу ошибаться, но... у вас падают железяки? из-за их падений не приходится начинать многомесячные расчеты с самого начала? что мешает так же выводить из кластера уязвимые сервера, скажем, штук по пять, обновлять и возвращать их назад? гетерогенность? т.е. заплатка на уязвимость в ядре создает гетерогенность системы которая уже не может функционировать? теоретически конечно быть может, но жутко сомневаюсь. в любом случае, накатил пару серверов для тестов, воткнул в сеть, есть проблемы - откатил и думаешь, или в этом случае все вычисления тоже идут прахом? А, извините, боюсь спросить, как делаются распределенные расчеты на машинах обычных, домашних, хомячков, где не только большая гетерогенность систем, но и установленного софта и где выпадание железки выполняющей расчеты не только вероятно, но и даже неминуемо с довольно неплохим процентом?
Обновление говорите слишком долгое и требует много ресурсов самого кластера? ну... если не обновляться и не прикрывать зад, то можно потом еще дольше и больше тратить времени и ресурсов. сколько у вас серверов? 10000? сколько не работает в любой момент времени по тем или иным причинам? 2-5%? (процент не с потолка, кстати, со статистики гугла и собственной статистики) + к этому проценту еще 5-ть лежачих серверов, в любой момент времени, много? сколько такой кластер будет обновляться? если обновление машины занимает 5-ть минут (раскатать готовый, подготовленный образ, много времени не нужно), то: 10000/(60/5*24*5)=6.94 суток, т.е. неделя. Если машинки загружаются по сети, и обновить нужно только сетевой образ, а дальше машинки поребутить/порестартить какие-то сервисы, то понадобится времени и того меньше...
> P.S.: По поводу первого пункта, я ради любопытства решил вспомнить с какой
> версии PHP на какую было обновление. Ошибся, не на 3, а
> на 5 отличается минорная версия — 5.4.5 VS 5.4.0. Витоге появился
> баг, в результате которого получил втык начальник отдела разработок, из-за чего
> потом получил втык я.
как сказал выше: я на 5.4 еще не смотрю, нех и нах.
>[оверквотинг удален]
> базе большого количества пакетов, некоторые из которых писались людьми, которые давно
> недоступны (и исходный код тоже). И опять же, биллингом занимаются другие
> люди, что всё ещё сильнее усложняло. Дак вот там, насколько я
> помню, год потратили, чтобы перевести этот биллинг на новую версию СУБД
> на новом сервере с новой системой. Не стоит забывать, что там
> ещё СУБД проприетарная+закрытая и завязана на конкретные бинарные библиотеки. Т.е. просто
> обновить конкретно всю остальную систему представляет достаточно проблематичным (тем
> более то было на solaris, откуда очень хотелось вообще съехать), если
> только, конечно, не создавать отдельное локальное окружение для СУБД, что частично
> лишено смысла, ибо уязвимости старых библиотек будут проявлять себя через СУБД...
Это уже проблема менеджера или главного админа/разработчика или ген. директора, который(ые) не знали/забили/не смогли сделать так, что бы в любой момент времени был хотя бы один разработчик который точно знал, что, где и почем. Примеров я таких знаю не мало и знаю конторы, у которых до сих пор работает оборудования родом из середины девяностых и на которое стараются не дышать, ибо кто-то не подумав зарулил жизненно важный софт для компании, работющий только на этом оборудовании, на пропреетарщину, которая давно сдохла не оставив от себя и следа; или тупо ушли разработчики и некому разобраться в коде...
> А теперь подумайте. С данным СУБД работает только какой-то набор программ,
> который не менялся годами и ничего плохого не происходило. Доступ открыт
> только для конкретного DMZ из которого работают эти программы. Неужели Вы
> считаете, что подобную систему стоит обновлять чаще, чем раз в год?
Обновлять стоит как только находятся дыры, есть ли возможность обновлять - вопрос другой.
> Меня вообще удивляет, что я это Вам рассказываю и Вы сами
> не в курсе про существование подобных проблем.
Я прекрасно знаю и в курсе и сам разгребал такое и ни кому не желаю этого, по-этому строю все так, что бы и без меня жить могло, если перейдет в нормальные руки.
> P.P.P.S: И вообще. Изначальной моей мыслью было то, что не каждый ресурс
> можно сидеть и обновлять каждый день. Намёк на то, что надо
> всегда всё настраивать так, чтобы и без этого подобная мелочь так
> не сказывалась. У меня например все сервера синхронизируются через собственный NTP-сервер,
> который на данный момент использует большой pool других серверов, а в
> скоре собираемся приделать к нему GPS и получить stratum 1. Витоге
> несмотря на то, что некоторые сервера не удаётся постоянно обновлять, данной
> атаке они не подвержены.
Есть уязвимости которым вы подвержены и есть уязвимости которым вы не подвержены, а со всех сторон не окопаешься, обновляться все равно придется.
Вариант для распечатки
