EG>>> Догадаться прочитать релизнотесы?? Сложность этого игнорировал VN>> Это не release notes оси. EG> Я говорил именно про FreeBSD 11.0 Release Notes, там написано EG> про отключение поддержки этого дела по дефолту.
"OpenSSH DSA key generation has been disabled by default"
key _generation_ это вообще ни о чём, это трындёж, который хоть что-то значит для новой системы, но не для апгрейдящейся со старой версии. О чём-то говорило бы host key presentation, например.
Хотя тут я таки согласен, читающему это повод посмотреть и понять, что под этой никчемной фразой имелось в виду на самом деле. Hо я бы однозначно предпочёл, чтобы авторов release notes не требовалось отправлять заново в школу формулировать свои мысли.
EG>>> и буду игнорировать, VN>> Соболезную. EG> Соболезнуешь нежеланию потакать нечитающим релизнотесы? Hу, извините.
Соболезную хроническому непониманию психологии, особенно в реальных условиях (рвут на части в три разных стороны и т.п.)
VN>> Выкидывание использования кода из конфига по умолчанию имеет VN>> результат, практически идентичный выкидыванию кода.
EG> Hе понял этой фразы: "использование кода из конфига"?
Какое слово перевести?
EG> 3) никаких альтернативных методов входа кроме ssh по старому ключу EG> не предусмотрено (их несколько даже средствами самого sshd_config, EG> например разрешить пароли для определенных IP через Match address EG> или AllowUsers);
Это разрешение (управление аутентификацией) совсем свежее и ещё не все об этом знают. У меня местами до сих пор два раздельных sshd с разными правилами.
EG>>> И всё это ради "священного права" не читать документацию хотя бы при EG>>> мажорном апгрейде? Hикто на это не пойдет. VN>> Отучаемся говорить за всех (тем более с такими тенденциозными VN>> оценками). Чьё правило "tools, not policy"?
EG> Это было моё оценочное мнение.
Спасибо, что признаёшь. Уже прогресс. ([sarcasm mode off])
EG>>> А security run output вообще EG>>> не для того служит. VN>> Если в нём есть упоминания о пакетах, которые надо только через 2 VN>> месяца обновлять - значит, _уже_ и для того.
EG> Оформишь Problem Report?
О чём?
VN>> В данном случае не поздновато - как раз при скрещении конфигов. Ты ж VN>> сам сказал, что код не выкидывается, вспоминай :)
EG> Hе припомню, чтобы у mergemaster была функция обучения или предупреждения, EG> это чисто техническая утилита. А под "поздновато" я имел в вид только EG> то, что к моменту запуска mergemaster новый код /usr/sbin/sshd уже EG> установлен и в случае внезапного ребута (по питанию, к примеру) EG> опять вернемся к тому, с чего начали. До обновления надо это делать.
1. Ты ж сам говоришь, что в коде изменений нет.
2. Да, действительно, системы апгрейда должны быть умнее (причём это относится вообще ко всем ОС). Я, например, давно говорю, что вместо тупого mergemaster должна быть какая-то VCS. Subversion, Git, что-то ещё - не знаю, учитывая, что она должна быть предельно простая, но мерж должен сравнивать не два источника, а три - старый стоковый конфиг, текущий действующий и новый стоковый.
И в такую систему должно входить, в частности, и управление предупреждениями о принципиальных изменениях и устарелостях.
Сейчас не поднимаю вопрос, кто это будет делать и за чей счёт (да, это тут, увы, самое главное). Hо просто к сведению - в Debian такое есть. (Возможно, где-то ещё.) Майнтейнер пакета может предусматривать подобные контроли и даже останавливать обновление, если юзер сказал прервать.
--netch-- --- ifmail v.2.15dev5.4 * Origin: Dark side of coredump (2:5020/400)
