Показать статистику
0 голосов
от (1.5тыс. баллов)
12 просмотров 2 ответов

2 Ответы

0 голосов
от (14тыс. баллов)

Подготовка к применению обновлений в Red Hat Linux


Поддержание системы в актуальном состоянии является повседневной задачей системного администратора, а также пользователя настольного компьютера. Применив в системе новейшее (стабильное) доступное программное обеспечение, мы сможем воспользоваться новейшими функциями и будем более защищены от проблем безопасности и, будем надеяться, меньше пострадаем от ошибок. Для обновления системы вам понадобятся настроенные yum репозитории, которые выступают в качестве источника обновленного программного обеспечения. 

Если вы сидите рядом с машиной, на которой запущена операционная система, подлежащая обновлению, вы можете легко действовать, если во время обновления что-то пойдет не так, например, проверить вывод на терминале, или загрузиться с работающей системы, если обновленная система не возвращается из перезагрузки - но это не всегда так. Представьте себе центр обработки данных с сотнями или тысячами (виртуальных) машин или просто физический ПК, который необходимо обновить удаленно.

Есть простые шаги, которые мы можем выполнить, чтобы подготовить систему к обновлению, и, возможно, устранить любые проблемы, которые могут поставить под угрозу успешное обновление.


Процесс обновления


При выполнении безусловного обновления (что означает «обновить все»), он yum извлечет все метаданные из доступных репозиториев и вычислит все пакеты, которые нужно обновить, по rpm базе данных, которая содержит все метаданные о пакетах, установленных в системе. 

Процесс обновления также вычисляет все зависимости обновленных пакетов, может заменить старые пакеты и удалить старые образы ядра в соответствии с его конфигурацией. Количество сохраняемых образов ядра задается в /etc/yum.conf файле конфигурации и по умолчанию равно 3:


installonly_limit=3


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

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

Изучив результаты, мы можем решить, запустить ли обновление или отменить его. Поскольку yum будет обновлять все, для чего он может найти обновления, мы можем захотеть удалить ненужные пакеты заранее. Мы также можем заметить пакет, помеченный для обновления, который заблокирован версией, который необходимо исключить из обновления.

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


yum cache


Исходя из описанного выше процесса, может возникнуть ситуация, что нам нужно место на диске для процесса обновления:
Метаданные всех настроенных репозиториев должны храниться до завершения расчета всех пакетов (и их зависимостей), подлежащих обновлению.
rpm пакеты, которые составляют само обновление, должны храниться локально до правильной установки.
Эти данные, которые вызываются, yum cache нужны только во время обновления, но могут занимать значительное дисковое пространство. Расположение по умолчанию для этого кэша находится в /var/cache/yum каталоге. Само собой разумеется, что если недостаточно места для хранения всех необходимых данных, процесс обновления завершится неудачей. Некоторые незавершенные загрузки будут отброшены, но не все пространство может быть освобождено, что приводит к тому, что система провалила обновление и ее объем /var/cache почти полностью заполнен. 

Многие установки хранят свои /var каталоги на томе, выделенном для ведения журналов, поскольку по умолчанию места для файлов журналов находятся /var/log в большинстве дистрибутивов, и большинство приложений с хорошим поведением перестанут работать или даже выйдут из строя, если они не смогут записать свои файлы журналов. Поэтому заполнять том, в который они пишут, плохо .

Чем больше пакетов необходимо обновить, и чем больше у нас репозиториев, тем больше места будет занимать временное обновление. Рассчитать это пространство от обновления к обновлению сложно, но его можно протестировать с помощью пробного решения, описанного ниже, если у нас есть тестовая машина с точным программным содержанием. Для примера реального времени обновление с RHEL 7.1 до 7.5 (установка на рабочем столе с помощью Gnome) может занять 4 ГБ дискового пространства, но установка нескольких исправлений в системе, которая устарела только на один или два месяца, займет только несколько МБ. 

Чтобы проверить, сколько у нас места, мы можем использовать df команду:


# df -h /var/


В приведенном выше примере у нас есть 4,4 ГБ свободного места, что будет достаточно, учитывая, что сервер был обновлен всего несколько месяцев назад. Чтобы освободить место, тривиальным шагом будет очистка yum cache уже сохраненного (возможно, при последнем обновлении). Чтобы проверить, сколько места занимает кеш в данный момент, мы можем использовать du:

# du -mcd 1 /var/cache/yum



Вышеуказанные числа указаны в МБ, поэтому yum cache в этом примере занимает около 1 ГБ дискового пространства и занимает большую часть пространства на /var томе.

 
Очистка кеша


Мы можем очистить весь кеш с помощью следующей команды:


yum clean all


Но, как yum уведомляет нас в выводе вышеприведенной команды в версиях RHEL 7, могут быть потерянные данные из удаленных или отключенных репозиториев, что, скорее всего, произойдет после незначительных выпусков обновлений, и в этом случае мы можем безопасно удалить данные вручную:


rm -rf /var/cache/yum/*


Мы можем получить больше места для обновления, очистив другие данные, хранящиеся на томе, такие как сжатие / удаление старых файлов журналов, перемещение больших файлов на другие тома или увеличение размера тома.


Перемещение кеша


Чтобы поработать с возможностями: yum, если у нас действительно мало места на диске, мы не можем ничего очистить дальше и не можем добавить больше места на том, мы можем переместить местоположение yum cache на другой том с большим количеством свободного места. Мы можем настроить расположение кэша в yum.conf файле конфигурации, упомянутом выше. Рассмотрим настройку по умолчанию:


cachedir=/var/cache/yum/$basearch/$releasever


Изменяя путь до $basearch следующей операции yum, вы будете работать с той же структурой каталогов, но по другому пути - надеюсь, с большим количеством свободного места для обновления. Мы также можем переместить кеш на другой том, переместив весь каталог:


mv /var/cache/yum /extended_data_volume/


И создать символические ссылки в исходном месте, которые указывает на новое место:


ln -s /extended_data_volume/yum /var/cache/yum


Целесообразно знать, что обновление не завершится ошибкой, такой как нехватка места на диске. В большой системе системные администраторы развертывают инструменты мониторинга, такие как Nagios, которые могут сообщать о нехватке дискового пространства на всех машинах, что делает этот шаг намного менее трудоемким и подверженным ошибкам.

 



 

от (14тыс. баллов)
0

Сетевые ошибки


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

С другой стороны, если обновление инициализируется из интерактивного сеанса, при сбое в сети соединение может разорваться, и машина обновления может остаться без администратора, чтобы ответить на вопросы, которые yum могут быть заданы. Если этап установки / обновления пакета уже начался, он останется без присмотра и может завершиться сбоем. После повторного подключения процесс можно отслеживать в /var/log/yum.log.


Yum неразрешенные зависимости


Помимо недостатка места на диске и проблем с сетью, обновление во многих случаях может завершиться неудачей из-за неразрешенных зависимостей пакетов. Их необходимо решать с помощью инструментов, которые могут рассчитывать и обрабатывать зависимости пакетов , но было бы полезно знать, что будут проблемы до фактического обновления (и, следовательно, не тратить всегда время простоя системы). Чтобы получить эту ценную информацию, мы можем запустить процесс обновления так, как он будет запускать фактическое обновление, но остановить его до того, как произойдет загрузка, установка или обновление какого-либо фактического пакета. 

Вокруг Redhat 6.6 была введена новая опция, которая вызовет yum принять «Нет» на каждый вопрос, который возникает во время обновления, включая утверждение перед фактической стадией манипулирования пакетом, и, как следствие, никакого реального взаимодействия не требуется, выполните пробный прогон:

yum update --assumeno


Это может быть идеальным инструментом для пробного запуска предстоящего обновления, включая обновляемые пакеты, и любых возможных ошибок. Рассмотрим следующий простой bash скрипт:

#!/bin/bash
yum update --assumeno &> $(hostname).yum.dryrun.$(date '+%Y-%m-%d').out
exit $?
 

Приведенный выше сценарий может быть выполнен автоматически и предоставит текстовый отчет о пробном запуске, а также общий код завершения, указывающий на любые проблемы. Выходные данные не нужно сохранять в локальной файловой системе. Целью перенаправления вывода может быть сетевая файловая система или отчет может быть отправлен на некоторый центральный сервер отчетов, который может быть собран другими сценариями или приложениями. Отчеты можно публиковать и распространять среди других ИТ-отделов для утверждения, так что все участники могут точно знать, какие пакеты будут обновлены и до какой версии.
Пробный запуск может быть запланирован на определенный промежуток времени (может быть ночью, чтобы меньше влиять на производительность системы) с cron помощью централизованного источника с настройкой puppet или может быть выполнен из него. Код выхода также может быть сохранен и обработан с помощью мониторинга или facter для агрегирования возможных результатов предстоящего обновления перед продолжением.

Подводя итоги


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

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

0 голосов
от (940 баллов)
Из личного опыта скажу что  обновления всегда важны, но иногда они приводят к тому что теряются какие то данные или ломаются программы.
Перед обновлением я бы рекомендовал делать максимальное резервное копирование данных так как потерять важные данные это очень неприятно и иногда критически... На данном этапе я говорю не о каких то файловых данных, а о конфигах, настройках и так далее. Большинство программных комплексов позволяет делать резервные копии файлов с настройками (например веб сервера apache, nginix).
Если Ваша система работает как сервер (что скорей всего так и есть), то Вам необходимо для начала зарезервировать всё самое важное, сделать бэкапы баз данных, конфигов, каких то скриптов и так далее. Конечно же, обновление системы приводит и к обновлению пакетов, но как показывает практика у семейства RedHat Linux обновления проходят более чем удачно.

Я думаю мой совет Вам поможет в этом, я лично всегда делал так и проблем с обновлением RedHat Linux у меня никогда не возникало. Удачи.
...