Выпуск cPanel & WHM: новые функции и стратегии безопасного обновления

Чётко разграничить cPanel и WHM

Хотя cPanel и WHM относятся к одному и тому же продукту, они обслуживают разные уровни хостинг-сервера. cPanel — это интерфейс для отдельной учетной записи хостинга: клиенты могут управлять там, например, доменами, почтовыми ящиками, файлами, базами данных и функциями безопасности, доступными для их учетной записи. То, какие разделы отображаются и доступны для использования, в первую очередь определяется списками функций, пакетами, темой, правами доступа к учётной записи и настройками хостинг-провайдера.

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

A Обновление cPanel поэтому касается не только нового вида личного кабинета клиента. Изменения могут повлиять на привязку тем, доступные функции в шаблонах пакетов и автоматизированные процессы. На системном уровне к этому добавляются интерфейсы, проверка прав доступа, установленные расширения и взаимодействие с операционной системой. При этом уровень выпуска (Release Tier) определяет, какая версия продукта и какой билд станут доступны для сервера, а не непосредственно видимость отдельных функций в конкретной учетной записи клиента.

Практическим примером служит внедрение Meridian: если тема задается через пакет WHM, это решение влияет на интерфейс новых или привязанных учетных записей. Если скрипты провижининга одновременно используют API или инструкции службы поддержки предполагают наличие определённых путей в меню, необходимо совместно проверить политику использования тем, шаблон пакета и автоматизацию. В противном случае изолированная смена темы может привести к функционально корректным, но неожиданным для клиентов и службы поддержки последствиям.

Различия между версиями, сборками и уровнями выпуска

Для надежного планирования обновлений необходимо Основная версия, при этом следует рассматривать уровни сборки (Build) и выпуска (Release) отдельно. Согласно документации, cPanel & WHM 138 является самой последней выпущенной основной версией для производственной среды. Версия 134 представляет собой текущую ветвь LTS с более длительным и предсказуемым сроком поддержки. Хотя в версии 136 и объясняется происхождение отдельных изменений, срок её регулярной поддержки истек ещё в августе 2026 года; поэтому она не является целесообразной новой целью обновления.

Основная версия обозначает ветку выпуска, например 138. Номер сборки уточняет конкретную версию в рамках этой ветки; в журнале изменений для версии 138 задокументированы изменения вплоть до сборки 138.0.13. Из этого не следует, что каждый сервер получит эту сборку или вообще будет обновлён до версии 138. Важно также, какой общедоступный канал распространения использует сервер.

Das Уровень выпуска определяет, с какой степенью тестирования и с какой периодичностью предоставляются обновления. Таким образом, LTS, STABLE, RELEASE, CURRENT и EDGE — это не просто метки для одной и той же версии программного обеспечения. Сервер, находящийся на уровне LTS, может сознательно работать на другой ветке основной версии, чем система на уровне RELEASE, хотя 138, как правило, является самой последней основной версией, используемой в производственной среде.

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

Почему обновление cPanel требует предварительного планирования

A Смена версии В cPanel & WHM откат не может быть выполнен без последствий: переход на более раннюю основную версию или более ранний уровень выпуска не поддерживается. При значительных скачках версий программа обновления проходит через необходимые промежуточные версии и перед каждым шагом проверяет совместимость. Это сокращает количество неудачных попыток обновления, но не заменяет предварительную экспертную проверку вашей собственной среды.

Технические условия могут препятствовать обновлению или определять его путь. К ним относятся используемая операционная система, наличие достаточного объема свободного места на /usr/local/cpanel а также активные блокировки пакетного менеджера. В качестве задокументированного примера можно привести то, что Ubuntu 22 нельзя обновить до cPanel & WHM 136. Такие указания не являются призывом перейти на старую ветвь, а служат поводом для предварительного уточнения версии операционной системы и запланированного пути миграции.

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

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

Выбор уровней выпуска в зависимости от производственной цели

Уровень выпуска определяет, какую версию разработки и тестирования получит сервер; таким образом, это операционное решение, а не просто настройка для автоматических обновлений. В течение срока поддержки LTS уделяет основное внимание обновлениям, связанным с безопасностью, критическим исправлениям и обеспечением совместимости. Версия STABLE выпускается реже, чем RELEASE, тогда как RELEASE является документально закреплённым стандартом для новых установок.

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

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

Кроме того, выбор должен соответствовать структуре тестирования. Как и в случае с другими панелями хостинга, решающим фактором является не отдельный номер версии, а взаимодействие панели, расширений, операционной системы и клиентского стека. Статья Планирование обновлений Plesk для хостинг-провайдеров с контролем иллюстрирует этот общий принцип для другой платформы. Согласно документации по обновлениям, задержка в несколько рабочих дней касается только автоматических обновлений до следующей основной версии в уровне RELEASE и только при условиях, указанных там; уровни EDGE, CURRENT, STABLE и LTS исключаются из этого правила.

Проверить новые функции в версии 138

Версия 138 включает Меридиан в качестве интерфейса для клиентов. Для администраторов WHM важно не только изменение макета: выбор темы, назначение пакетов, списки функций, учебные материалы и процедуры поддержки должны быть согласованы между собой. Уровень выпуска (Release Tier) определяет, доступна ли на сервере необходимая версия продукта и сборки; то же, какие разделы видит отдельная учетная запись, зависит, в первую очередь, от темы, пакета, списков функций и конфигурации провайдера.

В случае с Meridian проведение массового перехода без соответствующей политики сопряжено с риском. Учетные записи, созданные с помощью Meridian и никогда не использовавшие Jupiter, не могут самостоятельно вернуться к Jupiter. Однако администраторы могут задать тему через WHM, пакет или API. Поэтому шаблоны пакетов и коммуникация с небольшой пилотной группой должны быть тщательно согласованы перед широким внедрением.

Функция WHM-API-1 set_primary_domain_docroot может изменять корневую папку документа (Document Root) основного домена и была обратно интегрирована в версии 134 и 136. Это упрощает развертывание или миграцию, но не заменяет проверку приложения. CMS, перенаправление, права доступа к файлам или скрипт развертывания могут по-прежнему предполагать использование прежнего пути; успешный запуск программы обновления не распознает это функциональное допущение автоматически.

Начиная со сборки 138.0.10 для функций API, используемых для получения SSL-сертификатов и ключей, требуется функция sslinstall или sslmanager. Поэтому необходимо тщательно проверять ограниченные списки функций и интеграции с внешними системами биллинга. Кроме того, cPanel удалил устаревшие вспомогательные файлы из Cpanel/Accounting; прямая интеграция с отдельными системами расчетов требует настройки и не является автоматически обеспеченной совместимостью.

Сборка 138.0.13 также изменяет требования к ACL для реселлеров при настройке серверов имен. Реселлерам, управляющим кластеризацией DNS, может потребоваться привилегия all, чтобы изменить настройки серверов имен данного сервера. Поэтому перед обновлением необходимо проверить делегированные модели работы, роли задействованных реселлеров и автоматизированные процессы работы кластера DNS. Данное право значительно расширяет доступ и не должно предоставляться без разбора, а только после проверки ролей и безопасности.

Подготовка обновлений с проведением инвентаризации и пилотного внедрения

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

/usr/local/cpanel/cpanel -V

Для выполнения обновления cPanel требует не менее 5 ГБ свободного места в папке /usr/local/cpanel. Активные блокировки пакетного менеджера могут препятствовать выполнению операции; кроме того, ограничения могут налагаться со стороны операционной системы в зависимости от версии. Эти моменты необходимо учесть до начала окна обслуживания, равно как и восстановление, порядок проведения которого и права доступа к нему должны быть заранее согласованы.

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

Пилотное внедрение в производственную среду следует рассматривать отдельно. Реальные клиентские счета включаются в процесс только после получения явного разрешения, с ограниченным объемом, под контролем и с заранее согласованным каналом поддержки. Заранее определите, какие функциональные проверки будут проводиться, кто будет принимать решения в случае сбоя и какие меры по восстановлению возможны для конкретного счёта или сервера. Тестирование на имитированных счётах не заменяет данное разрешение на ввод в эксплуатацию; и наоборот, тестирование на реальных клиентских счётах не является безрисковой стадией подготовки.

В WHM функция „Upgrade to Latest Version“ обновляет систему до самой последней сборки выбранного уровня выпуска. Таким образом, эта функция не гарантирует переход на самую последнюю основную версию. Кроме того, для RELEASE может действовать автоматическая задержка; принудительное обновление позволяет обойти эту задержку. Параллельно с процессом обновления следует выполнять меры безопасности, касающиеся доступа, резервного копирования и брандмауэра; практические основы описаны в данной статье Безопасность панели управления хостингом в WHM и cPanel.

Управляйте Meridian и CSF в контролируемом режиме

Meridian в cPanel & WHM 138 — это не просто новый интерфейс для клиентов. Эта тема объединяет задачи в таких областях, как веб-сайты, электронная почта, файлы, базы данных, безопасность и производительность. Поэтому при эксплуатации важно не только то, насколько интерфейс визуально привлекателен, но и то, могут ли клиенты по-прежнему легко находить и выполнять предусмотренные задачи с помощью заказанных ими функций.

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

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

Переход обратно на Jupiter должен быть частью этого плана. Учетные записи, созданные с помощью Meridian и никогда не использовавшие Jupiter, не могут самостоятельно перейти обратно на Jupiter. Администраторы по-прежнему могут изменять тему в WHM, с помощью пакета или через API. Отсюда следует: назначение темы и соответствующий процесс должны быть определены до того, как новые учетные записи будут создаваться по умолчанию с использованием Meridian.

CSF следует рассматривать отдельно от основной версии cPanel & WHM. WebPros предоставляет этот форк в виде отдельного пакета с собственной версией для поддерживаемых версий cPanel & WHM. cpanel-csf Готово; установка и обновление осуществляются через систему управления пакетами cPanel. Ранее анонсированная миграция неподдерживаемых или устаревших установок CSF на поддерживаемый форк была обратно портирована на все поддерживаемые версии cPanel и WHM. Поэтому невозможно достоверно определить версию CSF только по установленной сборке cPanel.

В качестве базы для тестирования тебе понадобится установленный Состояние пакета cpanel-csf, отдельный журнал изменений CSF, состояние системы управления пакетами и локальную конфигурацию. Сохраните и сравните собственные правила, списки разрешений и запретов, хуки, уведомления, а также плагины или скрипты развертывания. Кроме того, проверьте, требуют ли внешние инструменты наличия файлов или команд из предыдущей установки CSF. Сборка cPanel остается актуальной в общем контексте обновления, но не заменяет ни эту проверку пакетов, ни оценку локальной конфигурации брандмауэра.

Систематическое выявление причин ошибок после обновления

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

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

Затем проверяйте зависимости в строгом порядке: сначала собственные вызовы API WHM или cPanel, затем списки функций и назначения тем, а после — плагины и правила брандмауэра. Таким образом, при поиске неисправностей можно отделить глобальное изменение прав доступа от изменений, связанных с отдельной учетной записью клиента или плагином. Изменения должны быть подробно задокументированы и, по возможности, сначала протестированы на тестовой среде или в изолированной учетной записи.

Одна из конкретных проблем касается автоматизации SSL: начиная со сборки 138.0.10, для вызова функций API, предназначенных для получения SSL-сертификатов и ключей, требуется функция sslinstall или sslmanager. Если после обновления скрипт перестает предоставлять данные о сертификатах, сначала проверь список функций, назначенных учетной записи, и права доступа используемого аккаунта, а не только сеть или набор сертификатов.

Даже при изменении корневых каталогов документов успешный вызов API ещё не гарантирует работоспособности веб-сайта. Функция set_primary_domain_docroot Можно установить путь к основному домену, при этом настройки CMS, перенаправления, права доступа к файлам, настройки виртуальных хостов или скрипты развертывания могут по-прежнему указывать на старый путь. Поэтому следует отдельно протестировать отображение контента, панель администрирования и операции записи в приложении.

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

Обязательно определить подходящую стратегию обновлений

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

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

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

CURRENT обновляется чаще и может содержать функции, которые ещё находятся в стадии разработки. EDGE проходит только базовое тестирование и предназначен исключительно для контролируемых тестовых сред. Нечетные номера основных версий относятся к разработческим выпускам в ветке EDGE; они не означают, что та или иная функция готова к стабильному использованию в производственной среде. Поэтому для производственных серверов клиентов EDGE не является «ярлыком» для доступа к более ранним функциям.

Положи Политика выпуска зафиксировано в письменной форме: допустимое количество серверов каждого класса, лица, ответственные за выдачу разрешений, минимальный объем тестирования на промежуточном этапе, окна технического обслуживания и критерии для прекращения работ. Задержка в несколько рабочих дней применяется исключительно к автоматическим обновлениям до следующей основной версии на уровне RELEASE, при условии, что обновление не запускается вручную или принудительно и пропускается только одна основная версия. На уровни EDGE, CURRENT, STABLE, LTS и фиксированные версии эта задержка не распространяется.

Типичными примерами неверных решений являются использование EDGE в производственной среде, а также фиксация отдельных номеров сборок в /etc/cpupdate.conf, отсутствие этапов тестирования и предположение, что версии LTS не требуют обновлений безопасности. Не менее проблематично приравнивать успешное выполнение программы обновления к официальному утверждению со стороны специалистов. Только после того, как клиентские функции, автоматизация, плагины и механизмы защиты будут проверены в запланированном объеме, техническое обновление превращается в контролируемый переход на новую версию.