EG>>>> Ему не надо этого помнить. Ему надо Release Notes перед мажорным EG>>>> обновлением прочитать и всё. VN>>> И снова про то, что проблема описана там, куда надо ещё догадаться VN>>> добраться VN>>> прочитать, ты игнорируешь EG>> Догадаться прочитать релизнотесы?? Сложность этого игнорировал VN> Это не release notes оси.
Я говорил именно про FreeBSD 11.0 Release Notes, там написано про отключение поддержки этого дела по дефолту.
VN>>>А вычистка из поддержки в аплинке это только два года (август 2015). EG>> "Вычистки" и тогда не было. Вычистка это когда код выкинули,
VN> Выкидывание использования кода из конфига по умолчанию имеет VN> результат, практически идентичный выкидыванию кода.
Hе понял этой фразы: "использование кода из конфига"? Выкидывание кода делает невозможным возврат старого поведения средствами конфигурационного файла. И это очень сильно отличается от факапа, для которого нужно одновременное сочетание множества факторов:
1) в authorized_keys очень давно сохранён ключ DSA вместо RSA (по дефолту генерятся RSA уже долгое время); 2) других ключей (RSA) там нет; 3) никаких альтернативных методов входа кроме ssh по старому ключу не предусмотрено (их несколько даже средствами самого sshd_config, например разрешить пароли для определенных IP через Match address или AllowUsers); 4) релизнотесы перед мажорным релизом не читаны.
Хотя бы один пункт убрать и "практической идентичности выкидыванию кода" нет.
EG>> И тем не менее тенденция началась именно тогда. Ты уверен, EG>> что понимаешь общеупотребительный смысл слова "тенденция"? VN> Понимаю. Особенно когда этих тенденций несколько одновременно VN> конфликтующих, и нет одной универсальной.
И тем не менее, така тенденция была уже 15 лет назад, а началась раньше, а 9 лет назад доросла до начала ломки совместимости в апстриме.
EG>> И всё это ради "священного права" не читать документацию хотя бы при EG>> мажорном апгрейде? Hикто на это не пойдет. VN> Отучаемся говорить за всех (тем более с такими тенденциозными VN> оценками). Чьё правило "tools, not policy"?
Это было моё оценочное мнение.
EG>> А security run output вообще EG>> не для того служит. VN> Если в нём есть упоминания о пакетах, которые надо только через 2 VN> месяца обновлять - значит, _уже_ и для того.
Оформишь Problem Report?
EG>> Hасчет mergemaster -p можно было бы подумать, но во-первых, EG>> как релизнотесы не читают, так и mergemaster -p могут пропускать EG>> (в большинстве случаев он избыточен), а для mergemaster это слегка EG>> поздновато. VN> В данном случае не поздновато - как раз при скрещении конфигов. Ты ж VN> сам сказал, что код не выкидывается, вспоминай :)
Hе припомню, чтобы у mergemaster была функция обучения или предупреждения, это чисто техническая утилита. А под "поздновато" я имел в вид только то, что к моменту запуска mergemaster новый код /usr/sbin/sshd уже установлен и в случае внезапного ребута (по питанию, к примеру) опять вернемся к тому, с чего начали. До обновления надо это делать.
VN>>> И опять двадцать пять за рыбу деньги. Что этого не было в release notes, VN>>> и что VN>>> должно было быть красными буквами, уже выяснили. EG>> Hичего подобного - там это есть. Черными. VN> Здесь должна быть повторена цитата из Адамса.
Релизнотесы это не три уровня индиректности и не подвал, это must read.
