Как обновить Centos 5 до 7
Обновлено: 21.11.2024
Время от времени обновление ОС может быть обременительным, вызывая простои сервера или неправильную работу веб-сайта. Именно по этой причине некоторые хостинг-провайдеры уклоняются от своевременного обновления серверной ОС.
Однако обновление операционной системы сервера до последней стабильной версии необходимо для защиты от взлома и уязвимостей. Вот почему в Bobcare наши эксперты по безопасности постоянно следят за обновлениями уязвимостей и последними версиями всего серверного программного обеспечения и приложений.
При выпуске новых версий мы настраиваем серверы наших клиентов с этим программным обеспечением после тщательного тестирования. Не существует универсального решения для обновлений серверов, так как каждый сервер отличается своим содержимым и требованиями.
На хостинговых серверах часто используется конфигурация CentOS с cPanel. Как и в случае с большинством программного обеспечения, новые версии CentOS продолжают выпускаться, а старые устаревают и достигают своего EOL (окончание срока службы).
Почему вам следует обновить ОС CentOS 5 на ваших серверах?
Поскольку CentOS 7 является последней версией программного обеспечения, более ранние выпуски, такие как CentOS 4 и 5, уже достигли своего EOL, а CentOS 6 скоро приблизится к своему EOL.
<р>1. Отсутствие поддержки продуктов. Поставщики обычно не поддерживают свои устаревшие продукты или те, которые достигли своего EOL. В результате устаревшая ОС становится ненадежной для работы на рабочем сервере. <р>2. Угрозы безопасности. Поскольку обновления безопасности и исправления уязвимостей в устаревших ОС больше не доступны, эти серверы могут быть взломаны в любой момент злоумышленниками, которые ищут устаревшее серверное программное обеспечение. <р>3. Проблемы с функциональностью. При запуске новых функций и функций они будут доступны и совместимы только с последними версиями программного обеспечения. Использование устаревшей ОС может отрицательно сказаться на этих функциях. <р>4. Затраты на техническое обслуживание. Из-за отсутствия поддержки поставщиков обслуживание устаревшей ОС практически невозможно и требует больших затрат. Сбой или сбой сервера из-за устаревшей ОС также может дорого обойтись хостинг-провайдеру. <р>5. Подводные камни производительности. Запуск ОС, достигшей своего EOL, также увеличивает риск низкой производительности ваших серверов. Они также могут приводить к периодическим сбоям или неожиданным ошибкам на веб-сайтах.[ Используйте свое время для развития своего бизнеса. Мы позаботимся о ваших серверах. Ознакомьтесь с нашими услугами по переносу серверов, чтобы узнать больше. ]
Как обновить ОС CentOS 5 на серверах?
CentOS 5 достигла своего EOL 31 марта 2017 года. Таким образом, все серверы, на которых установлена эта устаревшая версия, должны быть обновлены до более поздних версий – 6 или 7, без каких-либо задержек.
Но обновление CentOS 5 до более поздних версий невозможно на том же сервере. Единственный возможный обходной путь — настроить новый сервер с последней версией CentOS (в идеале CentOS 7) и перенести содержимое на этот сервер.
Миграция, которая не была спланирована или протестирована должным образом, может привести к сбою и простою бизнеса. В Bobcares мы проводим оценку серверов перед миграцией и выполняем миграцию только после соответствующих проверок.
Оценка перед миграцией и критические задачи, выполняемые нашими экспертами по серверам для обеспечения эффективной работы сервера, включают:
<р>1. Настройка нового сервера и панели управленияЭто очень важное действие, которое мы выполняем перед переносом данных. Мы настраиваем последние версии ОС и панели управления, например, CentOS 7 и cPanel, на новом сервере и настраиваем сеть для плавной миграции.
2. Настройка пользовательских модулей и приложений
Помимо ОС и панели управления, на каждом сервере могут быть и другие пользовательские настройки. Мы проверяем эти пользовательские настройки и настраиваем их и в новом — скажем, в модулях PHP/MySQL, модулях Apache, другом стороннем программном обеспечении и т. д.
3. Выделение ресурсов на новом сервере
Количество разделов и дисковое пространство на новом сервере выделяются после проверки исходной настройки сервера, возможных будущих расширений и требований к резервному копированию.
4. Обеспечение минимального времени простоя
Для некоторых доменов может потребоваться выделенный IP-адрес, а для некоторых – общий IP-адрес. Мы выполняем сопоставление и выделение IP-адресов для доменов на новом сервере после подготовки их к минимальным задержкам распространения DNS.
<р>5. Функции, зависящие от аккаунтаДругие специфичные для домена требования, такие как SSL-сертификаты, учетные записи торговых посредников, припаркованные домены и другие пользовательские приложения, также оцениваются и обеспечиваются при переносе данных.
[ Вам не нужно терять сон из-за устаревшего серверного программного обеспечения. Наши специалисты по серверам работают круглосуточно и без выходных, чтобы обновить ваши серверы. ]
Как мы обеспечиваем миграцию без потери данных и простоев
Часто незапланированный перенос данных приводит к разделению данных и потере данных. Из-за задержки распространения DNS некоторые данные могут оставаться на старом сервере.
В Bobcares мы тщательно синхронизируем копии данных, избегаем конфликтов служб и своевременно выполняем переключение DNS, чтобы свести к нулю потерю данных и время простоя.
Создав подробный список точек сбоя, тщательно отслеживая миграцию для обеспечения непрерывности обслуживания и выполняя тщательное тестирование перед миграцией, мы можем добиться нулевого времени простоя для доменов.
Мы видели, что повреждение данных может произойти при переносе данных между разными версиями программного обеспечения или совершенно другим серверным программным обеспечением. Преобразовывая данные в взаимозаменяемый формат и систематически устраняя ограничения, мы обеспечиваем плавный переход.
Команда специалистов по управлению серверами Bobcares выполняет надежную миграцию данных для владельцев серверов с различной конфигурацией и настройками, начиная от предприятий малого и среднего бизнеса и заканчивая центрами обработки данных.
Если вы хотите узнать, как мы организуем миграцию серверов без простоев, свяжитесь с нами.
Похожие сообщения:
ОБНОВИТЕ СВОЙ СЕРВЕР СЕГОДНЯ!
Никогда больше не теряйте свой бизнес из-за устаревшего серверного программного обеспечения! Позвольте нам помочь вам.
Мы постоянно оптимизируем, защищаем и обновляем ваши серверы. Наши инженеры круглосуточно следят за вашими приложениями и устраняют проблемы до того, как они затронут ваших клиентов.
Зарегистрируйтесь один раз. Наслаждайтесь спокойствием навсегда!
Bobcares предоставляет аутсорсинговую поддержку веб-хостинга и аутсорсинговое управление сервером для интернет-компаний. Наши услуги включают круглосуточную поддержку серверов, поддержку службы поддержки, поддержку в чате и поддержку по телефону.
Мне нужно обновить множество серверов (CentOS 5.x) до новейшей версии, например 7.X.
Я прочитал тонны статей о том, что нельзя перейти напрямую с 5 на 7 и лучше всего сделать новую установку.
Но вот мой вопрос: после сохранения сервера, должен ли я переустановить CentOS 7 напрямую и сделать резервную копию данных, или я должен сделать это шаг за шагом с установкой CentOS 6, резервным копированием и сделать то же самое с CentOS 7 ?
Если эти серверы объединены в кластер, вам также придется учитывать пути обновления любых файловых систем в масштабе кластера и механизмов резервного копирования. Кроме того, есть стороннее программное обеспечение, механизмы организации очередей и проверяющие компиляторы.
Нет прямого пути обновления с 5 на 6 или 7, поэтому переход на последнюю версию не сложнее, чем переход на 6 (которая перестанет существовать еще через 2 года, так что в любом случае это не имеет смысла). р>
Прежде всего, спасибо за ответ.
@Avij @TrevorH : Хорошо, я перейду сразу к CentOS 7.
@MartinR: Да, они сгруппированы, поэтому я буду помнить обо всем этом. Есть ли что-то еще, на что я должен обратить внимание перед обновлением?
Последний раз я столкнулся с такой проблемой при работе с системой на основе GPFS. В этом случае я мог бы обновить некоторые узлы, но кластер в целом остался использовать старые протоколы. Как только все узлы были обновлены, кластеру можно было приказать начать использовать новые функции. Существует лишь ограниченный диапазон совместимых версий, поэтому необходимо поэтапное обновление, чтобы избежать перестроения основной файловой системы размером 50 ТиБ. Torque был полностью несовместим между версиями, поэтому пользователям какое-то время приходилось мириться с двумя системами очередей.
Главный совет — RTFM. Я взял пару узлов для личного пользования, чтобы выполнить накат и устранить самые серьезные ошибки. Как и все, YMMV.
Главный совет — RTFM. Я захватил пару узлов для личного использования, чтобы выполнить накат и устранить самые серьезные ошибки.
Установка кикстарта через загрузку PXE хороша, если у вас есть правильный файл кикстарта.
Выполнение ручной установки сохраняет варианты в файле кикстарта, который является хорошей отправной точкой для написания фактического развертываемого кикстарта.
В CentOS 7 есть systemd, firewalld и NetworkManager. Они отличаются от «chkconfig», простых «iptables» и сценариев ifup. Вам нужно где-то узнать/проверить, как достичь с ними желаемого состояния (или как обойти это). Не пытайтесь создать ту же конфигурацию, что и в CentOS 5.
IME, никакое количество чтения не дает того же результата, что чтение в сочетании с биением головой о стену.
Мой принцип заключается в том, что на ПК нет ничего ценного. Пользовательские данные находятся на сетевых файловых серверах. У меня есть кластеры SLURM, но нет проблем с кластерными файловыми системами.
Сервер, на котором запущена служба, — это другое дело. Как установить и запустить этот сервис на новой платформе? Как мигрировать? Зависит от сервиса.
При переходе на следующую основную версию набора продуктов Red Hat Enterprise Linux вы столкнетесь с огромными изменениями. Вот мои заметки о том, что меняется при обновлении с одной основной версии Red Hat Enterprise Linux, ее клона CentOS или Oracle Linux. Другими словами, как перейти с RHEL, CentOS или Oracle Linux 5 на 6, 7, 8. Основные выпуски RHEL появляются все дальше и дальше друг от друга во времени, а это означает, что изменения становились все более и более сложными в основной версии 7.Изменения с 7 на 8, хотя и значительные, были не такими значительными, как с 6 на 7.
Помните, что Red Hat не меняет все эти вещи. Их установщик и их графические инструменты настройки, конечно, это изменения Red Hat. Но большая часть этого является результатом изменения многих базовых проектов. Таким образом, этот набор страниц также применим к Oracle Linux, где основные номера выпусков 5, 6, 7, 8 совпадают с RHEL и CentOS, и фактически к любому дистрибутиву, поскольку его компоненты обновлялись за последние несколько лет.
RHEL 2.1 | 26 марта 2002 г. | |
RHEL 3 | 22 октября 2003 г. | |
RHEL 4 | 15 февраля 2005 г. | |
RHEL 5 | 14 марта 2007 г. | |
RHEL 6 | 10 ноября 2010 г. | |
RHEL 7 | 10 июня 2014 г. | |
RHEL 8 | 7 мая 2019 г. |
Выпуск | По умолчанию | Необязательно |
RHEL 5 | Gnome 2.16 | KDE 3.5 |
RHEL 6 | Gnome 2.28 | KDE 4.3 | tr>
RHEL 7 | Gnome 3.8 | KDE 4.10 |
RHEL 8 | Gnome 3.28.2 | — |
Графический пользовательский интерфейс рабочего стола претерпевает серьезные изменения, особенно при переходе с RHEL 6 на 7. Как стандартный Gnome, так и дополнительный графический интерфейс KDE претерпевают значительные изменения версии. RHEL 8 удалил оконный менеджер KDE. Linux Mint также отказался от KDE после версии 18.3.
Gnome 3.8 на удивление требователен к ресурсам. Вероятно, вы захотите указать autospawn = no в вашем файле ~/.pulse/client.conf, а также в /etc/skel. В противном случае pulseaudio всегда будет запускаться и всегда перезапускаться, а иногда это приведет к неожиданной нагрузке на ЦП.
В RHEL 7 многие другие пакеты перешли на использование одного основного файла конфигурации и коллекции, как это делал xinetd в течение некоторого времени. Например, sudo помещает свои общесистемные настройки в /etc/sudoers, а затем читает все пользовательские файлы /etc/sudoers.d/* . Rsyslog читает /etc/rsyslog.conf, а затем все файлы в /etc/rsyslog.d/* .
Это не что-то конкретное для Red Hat, это тенденция для всей Linux, которая стала общей между выпусками RHEL 6 и 7. Это также похоже на оболочки, которые с некоторых пор впервые используют /etc/profile. а затем /etc/profile.d/* , а затем ~/.profile .
Это хорошо, воспользуйтесь этим. Цель состоит в том, чтобы вы не трогали предоставленный дистрибутивом файл /etc/*.conf . Когда пакет обновляется, rpm обнаруживает, что основной файл конфигурации все еще находится в первозданном виде, и у вас нет запутанных *.rpmnew , *.rpmold и т. д., чтобы отслеживать и вручную объединять изменения. Пусть файл конфигурации, предоставленный дистрибутивом, делает то, что он задумал, а ваши локально созданные файлы могут «исправить» любые общесистемные настройки, которые вы хотите изменить.
В RHEL 7 существует значительная разница между запуском vi и vim. Многие дистрибутивы, в том числе ранний RHEL, действительно запускали vim, улучшенную версию с большими возможностями, когда вы набирали просто vi. (это было связано с некоторыми хитростями с /etc/alternatives ).
vim — ваш друг, он действительно помогает, раскрашивая синтаксис в файлах конфигурации, языках программирования, HTML и многом другом. У меня была привычка всегда набирать vim, поэтому я выбрал лучший вариант для ОС, отличных от Linux, таких как OpenBSD и Solaris. Прими мою привычку!
Зарегистрировано
Я нахожусь в ситуации, когда наша компания имеет 32-разрядную систему CentOS 5 с cPanel на совместно расположенном собственном сервере HP, и из-за отсутствия SNI, а также окончания поддержки CentOS 5 мы вынуждены каким-то образом перенести эту систему на CentOS 7 64 бит.
Я знаю, что обновление на месте невозможно, но новая система должна быть установлена на том же физическом оборудовании (она не такая старая, на самом деле система CentOS 5 работает с пользовательским ядром, потому что она была слишком новой для чтобы даже увидеть жесткие диски и датчики).
Что у нас есть прямо сейчас:
- публичный IP-адрес, скажем, 123.456.789.50 (этот IP-адрес, очевидно, недействителен, просто пример) с несколькими доменами и веб-сайтами на нем; часть наша, часть клиентов
- физическая машина на указанном выше IP
Что мы можем использовать:
- новый сервер, на котором будут работать "другие" (не cPanel и не веб-хостинг) вещи, но я смогу использовать его в ближайший месяц, прежде чем он перейдет в интенсивное производство. , и при необходимости он может запускать довольно много гостей KVM
- общедоступный IP-адрес для этого нового сервера, скажем, 400.500.600.12 , и несколько дополнительных сетевых карт, которые потенциально могут быть подключены в центре обработки данных, где мы размещаем наш инфраструктура
- хороший офис, где я могу работать с оборудованием, устанавливать новую ОС, тестировать вещи
Мой план таков, и именно здесь мне нужно ваше мнение по этой теме, если вы обнаружите какие-либо проблемы или у вас есть идеи получше:
1.) Я могу запланировать два техобслуживания по 4–6 часов в этом году без особых жалоб клиентов.
2.) Я бы использовал первое окно обслуживания, чтобы создать виртуальную машину на новой машине, закрыть старую и скопировать в нее систему CentOS 5 с помощью rsync с live CD. Некоторые ручные исправления в копии, и она может загружаться в виртуальной машине.
После этого я бы попросил операторов центра обработки данных отсоединить кабель Ethernet от старого сервера, установить коммутаторы и подключить запасную сетевую карту к этой новой машине, чтобы она могла использовать IP-адрес старого сервера. Когда виртуальная машина загружается, она имеет доступ к этому сетевому адаптеру, имеет старый IP-адрес и может продолжать обслуживать веб-сайты и обрабатывать электронную почту. В этот момент я могу удалить старый сервер из центра обработки данных, чтобы делать с ним все, что захочу.
До этого момента это было довольно тривиально, клиенты не замечали разницы, и это стоило нам всего нескольких часов простоя.
Для некоторых избранных сайтов я должен предоставить PHP 5.2, который был EOL в CentOS 5 лет назад и даже тогда был реальной проблемой из-за требований к версии libpcre (нам пришлось использовать с ним 8.20, в то время как система PCRE 8.36 прямо сейчас, но это уже другая история). На самом деле он отлично работал с трюками suPHP и .htaccess, но в системе был EasyApache3. Я понятия не имею, насколько сложно будет с EA4 и CentOS 7.
4.) После тестов придет время каким-то образом перенести данные виртуальной машины CentOS 5 в новую систему CentOS 7; это второе запланированное окно простоя.
Поэтому старое оборудование с CentOS 7 отправится в центр обработки данных. Я вижу 2 возможных решения:
a) Сделайте полное резервное копирование учетной записи в системе CentOS 5, выключите ее, запустите машину CentOS 7 и установите для нее IP-адрес 123.456.789.50.Затем я могу смонтировать файловые системы виртуальной машины по сети и восстановить оттуда резервные копии, как если бы они были локальными резервными копиями; вероятно, используя /scripts/restorepkg и собственный сценарий вокруг него, чтобы убедиться, что учетные записи посредников восстанавливаются в первую очередь.
Моя проблема с этим подходом заключается в том, что системы CentOS 5 и 7 будут иметь разные версии cPanel (старая на данный момент застряла на 11.56), разные архитектуры (i686 и amd64), и это может привести к ошибкам во время восстановления. ; только разработчики cPanel могли сказать наверняка.
b) Используйте инструмент переноса ( Transfers - Documentation - cPanel Documentation ), пока оба сервера работают. Мне нужна система CentOS 7, чтобы в итоге использовать исходный IP-адрес, 123.456.789.50 , и я думаю, что лучше сделать это раньше, чем позже. Я могу изменить IP-адрес виртуальной машины CentOS 5 на что-то вроде 10.1.2.123 и настроить брандмауэр хоста на переадресацию почти всех портов 1: 1 с его внешнего IP-адреса 400.500.600.12, а затем настроить систему CentOS 7 на использование 123.456.789.50. . На этом этапе система CentOS 7 сможет получить доступ к старой CentOS 5 через SSH (или что-то еще, что ей нужно для передачи) и имеет желаемый внешний IP-адрес.
Тем не менее, система CentOS 5 теперь находится за NAT и на совершенно новом внешнем IP-адресе с точки зрения лицензии, так что еще один поход на NDCHost за еще одной пробной лицензией?
Нужно ли мне изменить зоны DNS для каждой учетной записи, чтобы иметь IP-адрес 400.500.600.12 перед переносом в систему CentOS 5? Некоторые файлы зон также имеют настраиваемые дополнения, такие как добавленные вручную записи CNAME, A, TXT и несколько поддоменов, делегированных другим DNS-серверам, поэтому мне было бы лучше оставить их в покое и просто скопировать в систему CentOS 7 как есть. Каковы ожидания от Transfer Tool? Будет ли он удивлен, если увидит там свой собственный «общий IP-адрес», ожидая, что он будет иметь основной IP-адрес удаленного сервера?
Очевидно, что обе системы должны быть защищены брандмауэром во время переноса, чтобы домены, возникающие в них, не были доступны клиентам во время переноса, особенно электронные письма (которые могут задерживаться на исходных SMTP-серверах и приходить с опозданием на несколько часов, здесь нет проблем, но если некоторые из них появятся на старой CentOS 5 из-за некоторых различий DNS, а клиент, использующий новую систему CentOS 7, будет катастрофой, особенно когда система CentOS 5 уже отсутствует).
Итак, это план, и я должен решить, делать ли 4/a или 4/b. Может быть, решение 4/c? Было бы неплохо минимизировать время простоя, и у меня есть ощущение, что последовательность резервного копирования-подключения-восстановления сети, вероятно, занимает больше времени, чем средство переноса между двумя работающими системами, но изменения IP/DNS могут запутать его.
Читайте также:
- Как установить тему в Windows 10
- Размытие не работает в Windows 10
- Office 365 не активирует Windows 7
- Как вызвать командную строку при установке Windows 7
- Обновление функций до Windows 10 версии 20h2, как отменить