☰

обновления yum — являются ли файлы .rpmnew критически важными/важными для принятия мер?

tag-icon • tag-icon centos redhat yum
обновления yum — являются ли файлы .rpmnew критически важными/важными для принятия мер?

Иногда, когда yum устанавливает обновления, он выдает сообщение вроде:

warning: /etc/ssh/sshd_config created as /etc/ssh/sshd_config.rpmnew

Я считаю, что было бы разумно отреагировать на это, поскольку иногда в конфигурационный файл может потребоваться внести некоторые изменения, которые важно выполнить по соображениям безопасности. Однако мне интересно, не слишком ли я осторожен и не является ли это всего лишь теоретическим беспокойством, которое на самом деле не является проблемой.

Думаю, я спрашиваю, знает ли кто-нибудь о случаях за последние несколько лет, когда отсутствие слияния в файле .rpmnew имело бы какие-то заметные нежелательные последствия — особенно с точки зрения безопасности, но и другие аспекты, такие как стабильность или желательность конфигурации, могут быть достойны упоминания.

решение1

ЕгооченьРедко бывает, чтобы изменения в конфигурации по умолчанию имели последствия для безопасности или стабильности. Однако «очень редко» не означает «никогда», и хорошей практикой системной гигиены является просмотр всех .rpmnewфайлов и повторная проверка того, что они не содержат важных изменений, а затем их удаление.

В качестве дополнительной проверки вам также следует организовать получение уведомлений о безопасности и информации обо всех доступных для установки обновлениях — чтение журналов изменений и бюллетеней даст вам хорошее представление о характере устраняемых проблем.

решение2

Я бы рекомендовал действовать как с файлами *.rpmnew, так и с *.rpmsave после обновлений. Создание этих файлов обычно указывает на одно из следующих трех:

  1. вы не были осторожны (или не было другого способа сделать это) и изменили файл конфигурации, который находится под управлением пакета. Обычно, если пакет предоставляет каталог для фрагментов конфигурации (например, /etc/<package>.d/ как в /etc/php.d/ для PHP), вы должны сбрасывать свои локальные изменения туда и не подвергаться влиянию изменений конфигурации, предоставленных пакетом.

  2. упаковщик был невнимателен и изменил определение соответствующей записи файла в файле спецификации (например, он забыл пометить определенный файл как %config или изменил модификаторы макроса %config()).

  3. происходит что-то подозрительное, и соответствующий файл конфигурации был подделан.

В любом случае, если в результате обновления был создан файл *.rpmnew или *.rpmsave, полезно сделать следующее:

  1. сделайте сравнение старого и нового файлов с помощью diff -uw old_file new_file(опция -w проигнорирует изменения в количестве пробелов);

  2. если нет никаких различий (кроме пробелов) и вы исследуете создание файла *.rpmnew, замените исходный файл на *.rpmnew, используя mv config_file.rpmnew config_file. Это гарантирует сохранение метаданных набора пакетов (например, временных меток, прав доступа к файлам и, возможно, возможностей)

  3. если есть различия, то перебазируйте свои изменения в файл, предоставленный пакетом (т. е. если вы работаете с *.rpmnew - скопируйте этот файл *.rpmnew под временным именем и настройте его так, чтобы он соответствовал желаемым изменениям из исходного файла конфигурации; если вы работаете с *.rpmsave - примените изменения к файлу конфигурации, предоставленному пакетом). Это гарантирует, что дальнейшие обновления будут проще, и если был введен новый формат файла конфигурации, то вы используете его

  4. после разрешения этого «конфликта» удалите соответствующий файл *.rpmnew или *.rpmsave, поскольку они не отслеживаются системой управления пакетами.

Это даст вам чистую и удобную для работы систему, а также гарантирует, что вы будете в курсе последних изменений в файлах конфигурации.

Связанный контент