cPanel & WHM のリリース：新機能と安全なアップデート戦略

cPanelとWHMを明確に区別する

cPanelとWHMは同じ製品に属していますが、ホスティングサーバーの異なるレベルで機能します。. シーパネル これは、個々のホスティングアカウント用の管理画面です。顧客はこの画面で、ドメイン、メールボックス、ファイル、データベース、および自分のアカウントで利用可能なセキュリティ機能などを管理します。 どの領域が表示され、利用可能になるかは、主に機能リスト、パッケージ、テーマ、アカウント権限、およびホスティングプロバイダーの設定によって決まります。.

一方、WHMはホスティングパネルの管理レベルにあたります。サーバー管理者はここでアカウント、パッケージ、機能リスト、サーバー全体のサービスを設定しますが、マネージドホスティングプロバイダーはさらに、プロビジョニング、アップデート、サポートに関する基準を定めます。 リセラーは、委任された権限に応じて限定されたWHM領域で作業を行います。したがって、オペレーティングシステム、グローバルサービス、あるいはすべてのサーバーポリシーへのアクセス権が自動的に付与されるわけではありません。.

A cPanelのアップデート したがって、これは単に顧客アカウント内の新しい表示画面だけの問題ではありません。変更により、テーマの割り当て、パッケージテンプレートで利用可能な機能、および自動化されたワークフローが変更される可能性があります。システムレベルでは、インターフェース、権限チェック、インストール済みの拡張機能、およびオペレーティングシステムとの相互作用も影響を受けます。 ここでいう「リリース・ティア」は、サーバーで利用可能となる製品バージョンやビルドを決定するものであり、特定の顧客アカウントにおける個々の機能の表示可否を直接決定するものではありません。.

実用的な例として、Meridianの導入が挙げられます。テーマがWHMパッケージを通じて指定される場合、この決定は新規または割り当てられたアカウントのユーザーインターフェースに影響を与えます。 プロビジョニングスクリプトがAPIを併用している場合や、サポートガイドで特定のメニューパスを前提としている場合は、テーマポリシー、パッケージテンプレート、自動化機能を総合的に検証する必要があります。そうしないと、テーマの変更を単独で行っただけで、機能的には問題がないものの、顧客やサポートにとって予期せぬ結果を招く恐れがあります。.

バージョン番号、ビルド、およびリリース階層の違い

確実なアップデート計画を立てるためには、以下のことが必要です。 メジャーバージョン, 、ビルドとリリース・ティアは別個に考える必要があります。文書化された情報によると、cPanel & WHM 138 が公開されている最新の製品用メジャーバージョンです。バージョン 134 は、より長期にわたる計画可能なサポート期間が設定された現在の LTS ブランチです。 バージョン136では個々の変更点の由来が説明されていますが、正規のサポート終了はすでに2026年8月となっており、したがって、新たなアップグレード先として適しているとは言えません。.

メジャーバージョンはリリースブランチ（例：138）を示します。ビルド番号は、そのブランチ内の具体的な状態を特定するものです。変更履歴には、ビルド 138.0.13 までの 138 に関する変更が記載されています。 しかし、だからといって、すべてのサーバーがこのビルドを受け取る、あるいはそもそも138に更新されるというわけではありません。サーバーがどの公開配布チャネルを使用しているかも重要な要素となります。.

仝 リリース・ティア は、どの程度のテストを経て、どのようなペースでアップデートが提供されるかを決定します。したがって、LTS、STABLE、RELEASE、CURRENT、EDGEは、単に同じソフトウェアの状態を表すラベルではありません。 LTS階層にあるサーバーは、一般的に138が最新の本番用メジャーバージョンであるにもかかわらず、RELEASE階層にあるシステムとは意図的に異なるメジャーバージョンブランチ上に配置されることがあります。.

主バージョン番号が奇数のバージョンについては、特に注意が必要です。これらはEDGEブランチの開発リリースに属するものであり、公開済みの本番バージョンとは同一視できません。 これらの存在は、開発が完了したことを示すものでも、顧客のサーバーでの使用に適していることを示すものでもありません。したがって、変更管理やサポート対応の際、管理者は常に、インストールされているバージョン、具体的なビルド、および選択されたティアをまとめて記録しておく必要があります。.

なぜcPanelのアップデートには計画が必要なのか

A バージョンの変更 cPanel & WHM では、元に戻す操作には影響が伴います。以前のメジャーバージョンや以前のリリースティアへのダウングレードはサポートされていません。 大幅なバージョンアップを行う場合、アップdaterは必要な中間バージョンを経由して処理を行い、各ステップの前に互換性を確認します。これにより、不適切なアップグレードの試行は減りますが、自身の環境に対する専門的な事前確認に代わるものではありません。.

技術的な要件によって、アップデートの実行が妨げられたり、その実行パスが決定されたりする場合があります。これには、使用しているオペレーティングシステムや、以下の場所にある十分な空き容量などが含まれます。 /usr/local/cpanel およびパッケージマネージャーによるアクティブなブロック。文書化された例として、Ubuntu 22はcPanel & WHM 136にアップデートできません。このような注意書きは、古いブランチに切り替えるよう促すものではなく、OSのバージョンや予定されている移行経路を事前に確認するきっかけとなるものです。.

基本システムに加え、このアップデートには運用チェックリストが含まれています。SSL API の権限変更やアカウンティングヘルパーの削除に関する記録から、自社独自の自動化システムや課金システムとの連携に影響が出る可能性があることがわかります。 また、MeridianおよびCSFの変更により、テーマの割り当て、機能リスト、ローカルファイアウォールの調整、および関連する拡張機能も、確認すべき重要な項目となります。これらはアップデータによって保証された確認事項ではなく、ご自身の環境において個別に評価する必要がある依存関係です。.

運用上の予防措置として、更新作業は、自社の環境に適した復旧計画、事前に検証済みのバックアップ状態、および明確な責任分担が整った上で開始すべきです。 メーカーのドキュメントでは、新しいメジャーバージョンをまず互換性のあるテストシステムでステージングし、自社での機能テストを経てから、本番環境への展開を段階的に行うことを推奨しています。ダウングレードは想定されていないため、バックアップからの復元と、リリースティアのロールバックを混同しないように注意する必要があります。.

事業目標に応じたリリースティアの選択

リリースレベルは、サーバーにどの開発版およびテスト版が適用されるかを決定するものであり、単なる自動更新の設定ではなく、運用上の決定事項です。LTSは、そのサポート期間中、セキュリティ、重要、および互換性に関する更新に重点を置いています。 STABLEはRELEASEよりもリリース頻度が低い一方、新規インストールにおいてはRELEASEが文書化された標準となっています。.

CURRENTは更新頻度が高く、まだ開発中の機能が含まれている場合があります。EDGEは基本的なテストのみが行われているため、管理されたテスト環境でのみ使用してください。 EDGEブランチにおける奇数番地のメジャーバージョン番号は、開発リリースを示すものであり、本番環境での使用に適していることや、個々の機能が確実に利用可能であることを保証するものではありません。.

計画可能な共有ホスティングについては、 LTS 新しいインターフェースや早期の自動化機能よりも、長期的に予測可能な動作状態が重要である場合に適しています。これは、アップデートを停止することを意味するわけではありません。セキュリティ修正や重要な修正は、引き続き運用の一部として実施されます。依存関係を事前に確認し、メンテナンスウィンドウを計画している限り、新しいサーバーの導入は「RELEASE」が推奨されます。.

また、その選択はテスト環境にも適合している必要があります。他のホスティングパネルと同様、重要なのは単一のバージョン番号ではなく、パネル、拡張機能、オペレーティングシステム、および顧客のスタックが相互に連携して機能することです。この記事 ホスティングプロバイダー向けのPleskアップデートの計画的な実施 この一般的な原則を、別のプラットフォームについて具体的に示しています。更新ドキュメントによると、数営業日の遅延が生じるのは、RELEASEティアにおける次のメジャーバージョンへの自動アップグレードに限られ、かつそこに記載された条件の下でのみ発生します。EDGE、CURRENT、STABLE、およびLTSは、この対象外となります。.

バージョン138の新機能を確認する

バージョン138では、 子午線 顧客向けインターフェースとして導入されます。WHM管理者にとって重要なのは、レイアウトの変更だけではありません。テーマの選択、パッケージの割り当て、機能リスト、トレーニング資料、サポートプロセスが互いに整合している必要があります。 リリース・ティアによって、サーバー上で必要な製品およびビルドのバージョンが利用可能かどうかが決まります。一方、個々のアカウントに表示される範囲は、主にテーマ、パッケージ、機能リスト、およびプロバイダーの設定によって決まります。.

Meridian では、ポリシーを定めないまま全面的な移行を行うのはリスクが高い。Meridian で作成され、Jupiter を一度も使用したことのないアカウントは、自身で Jupiter に戻ることができない。 ただし、管理者はWHM、パッケージ、またはAPIを通じてテーマを設定することができます。そのため、本格的な導入に先立ち、パッケージテンプレートや小規模なパイロットグループへの周知内容について、確実に調整しておく必要があります。.

WHM-API-1 関数 set_primary_domain_docroot プライマリドメインのドキュメントルートを変更できるようになり、この機能は134および136に遡って実装されました。これにより、プロビジョニングや移行が容易になりますが、アプリケーションの検証に代わるものではありません。 CMS、リダイレクト、ファイル権限、またはデプロイスクリプトによっては、依然として従来のパスを前提としている場合があります。Updaterの実行が成功しても、こうした業務上の前提条件を自動的に検知することはありません。.

ビルド 138.0.10 以降、SSL 証明書および鍵を取得するための API 関数では、この機能が必要となります。 sslinstall 或いは sslmanager. 。そのため、機能リストの制限や外部課金システムとの連携については、個別に確認する必要があります。さらに、cPanelは古いヘルパーファイルを Cpanel/Accounting; 個別の請求システムへの直接連携は、カスタマイズが必要なケースであり、自動的に解決される互換性の問題ではありません。.

また、ビルド 138.0.13 では、以下の要件も変更されています。 リセラーACL ネームサーバーの設定において。DNSクラスタリングを管理するリセラーは、以下の権限が必要になる場合があります all, 、サーバーのネームサーバー設定を変更するためです。したがって、更新を行う前に、委任された運用モデル、利用されているリセラーの役割、および自動化されたDNSクラスタのプロセスを確認してください。この権限はアクセス範囲を大幅に拡大するため、一律に付与するのではなく、役割とセキュリティの確認を行った上で付与する必要があります。.

棚卸しとパイロット運用を伴う更新の準備

アップデートに先立ち、まず現状を把握します。具体的には、インストールされているバージョン、リリースティア、オペレーティングシステム、サードパーティ製プラグイン、独自のAPI呼び出し、ファイアウォールの設定、およびバックアップと復元の手順などです。 バージョンは、システムに変更を加えることなくターミナルで確認できます。この現状把握により、技術的なコンポーネントとその担当者を紐付け、アップデート後に不明確な依存関係が明らかになることを防ぎます。.

/usr/local/cpanel/cpanel -V

アップグレードを実行するには、cPanel では以下の場所に少なくとも 5 GB の空き容量が必要です。 /usr/local/cpanel. 有効になっているパッケージマネージャーのロックにより、この処理がブロックされる可能性があります。また、OSのパスもバージョンによっては制限となる場合があります。これらの点は、メンテナンスウィンドウの前に確認しておく必要があります。同様に、手順やアクセス権限が事前に明確になっている復元作業についても同様です。.

その後に続くのは ステージング 別の、同等のテスト環境上で実施します。そこでは、関連するパッケージ、テーマ、プラグイン、および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バージョンに遡及適用されました。そのため、インストールされているcPanelビルドのみからCSFのバージョンを確実に特定することはできません。.

テストの基盤として、インストール済みの cPanel-CSF パッケージのバージョン, 、個別のCSF変更履歴、パッケージ管理の状況、およびローカル設定を確認してください。独自のルール、許可リストと拒否リスト、フック、通知、プラグイン、デプロイスクリプトを保存して比較してください。 さらに、外部ツールが以前のCSFインストールに由来するファイルやコマンドを前提としていないか確認してください。cPanelビルドは一般的な更新の文脈において依然として重要ですが、このパッケージチェックやローカルファイアウォール設定の評価に代わるものではありません。.

アップデート後の不具合を体系的に絞り込む

アップデート後に機能が動作しなくなった場合、分析は選択されたリリース・ティアと実際にインストールされているビルドから開始されます。一般的に最新のメジャーバージョンが、必ずしもサーバーの状態と一致するとは限りません。重要なのは、設定されたティアで提供されたビルドがどれであるかです。 また、想定される不具合の修正に向けた変更を行う前に、発生時刻、影響を受けたアカウント、および具体的な機能を記録しておいてください。.

その後、更新ログと可能性のある アップグレードブロッカー 。バージョン番号の大きな変更がある場合、アップデーターは中間バージョンを経由して互換性チェックを行います。パッケージマネージャーによるロックが有効になっている場合や、OSのパス設定が不適切な場合は、この処理に影響を与える可能性があります。 アップグレードが中断されたり、一部のみ完了したりした場合でも、無理やりオプションを指定して安易に再実行するのではなく、まずログに記録された原因を特定する必要があります。.

その後、依存関係を決まった順序でテストします。まず、独自のWHMまたはcPanel API呼び出し、次に機能リストとテーマの割り当て、その後にプラグインおよびファイアウォールルールをテストします。 このようにして、トラブルシューティングにおいて、システム全体の権限変更と、個々の顧客アカウントや拡張機能との区別を明確に行います。変更内容は追跡可能な形で文書化し、可能な限りまずステージング環境または隔離されたアカウントでテストを行うようにしてください。.

具体的な不具合の一つは、SSLの自動化機能に関するものです。ビルド138.0.10以降、SSL証明書や鍵を取得するためのAPI関数では、この機能が必要となります。 sslinstall 或いは sslmanager. 。アップデート後にスクリプトが証明書データを返さなくなった場合は、ネットワークや証明書の在庫だけでなく、まずそのアカウントに割り当てられている機能リストと、使用しているアクセス権限を確認してください。.

ドキュメントルートが変更された場合、API呼び出しが成功したとしても、ウェブサイトが正常に動作しているとは限りません。この関数 set_primary_domain_docroot プライマリドメインのパスを設定できる一方で、CMSの設定、リダイレクト、ファイル権限、vHostの仮定、またはデプロイスクリプトは、引き続き古いパスを指し続けている可能性があります。そのため、アプリケーションの配信、管理画面、および書き込み処理を個別にテストしてください。.

個別に組み込まれた会計システムとの連携機能も影響を受ける可能性があります。これは、 Cpanel/Accounting 削除されました。決済プロセスが業務上不可欠であり、互換性のある修正プログラムが利用できない場合は、さらなる強制的な更新を行うよりも、メンテナンス停止や検証済みのバックアップからの復元を行う方が適切です。その場合、メーカーのドキュメントやログが、堅牢な対応計画の基礎となります。.

適切なアップデート戦略を明確に定める

持続可能なアップデート戦略は、目に見えるバージョン番号の最大値ではなく、運用目標から始まる。決定的な要素となるのは、サポート期間、新機能の必要性、顧客への予想される影響、利用可能なテストリソース、サードパーティへの依存関係、そしてセキュリティ運用である。 これらの基準は、サーバーグループごとに評価する必要があります。共有ホスティングクラスター、新しいマネージドプラットフォーム、社内テストシステムでは、それぞれリスクや変更の頻度が異なります。.

LTSは、継続的な新機能の追加よりも、長期的な計画が立てられる安定性が重視される場合に適しています。サポート期間中、このブランチには主にセキュリティ、重要な修正、および互換性に関する更新が提供されます。したがって、LTSは更新の停止を意味するものではなく、バックアップ、復元、および依存関係テストに代わるものでもありません。 確立された共有ホスティングサービスにおいては、機能変更が制限されることで、サポートのコストをより正確に見積もることが可能になります。.

STABLEはRELEASEよりもリリース頻度が低く、より多くの公開テストを経ています。 RELEASEは機能が完全であり、新規インストールにおける標準となります。新しい機能が必要だが、広範な導入に先立ってテストが行われる場合、どちらのバージョンも有意義な選択肢となります。したがって、どちらのバージョンが適しているかは、そのプラットフォームにおいて、早期の入手可能性と追加のテスト期間のどちらがより重要かによって決まります。.

CURRENTは更新頻度が高く、今後さらに開発が進む機能が含まれている場合があります。EDGEは基本的なテストのみが行われており、管理されたテスト環境でのみ使用することを想定しています。奇数のメジャーバージョン番号はEDGEブランチの開発リリースに属するものであり、その機能が本番環境で安定して利用可能であることを示すものではありません。 したがって、本番環境の顧客サーバーにおいて、EDGEは以前の機能への近道とはなりません。.

を リリースポリシー 書面で明確に定める：サーバークラスごとの許容動物数、承認責任者、ステージングテストの最低範囲、メンテナンスウィンドウ、および中止の基準。 数営業日にわたる遅延は、RELEASEティアにおける次のメジャーバージョンへの自動アップグレードにのみ適用されます。ただし、アップグレードが手動または強制的に開始されず、かつ1つのメジャーバージョンのみをスキップする場合に限ります。 EDGE、CURRENT、STABLE、LTS、および固定登録されたバージョンについては、この遅延は適用されません。.

典型的な誤った判断としては、本番環境でのEDGEの使用や、個々のビルド番号を /etc/cpupdate.conf, 、ステージングの欠如、そしてLTSにはセキュリティ更新プログラムが不要だという前提。同様に問題となるのは、アップデーターの実行が成功したことを、技術的な承認と同一視してしまうことです。 顧客向け機能、自動化、プラグイン、および保護メカニズムが計画された範囲で検証されて初めて、技術的なアップデートは管理された運用移行となるのです。.