目的
私たちの目的は、オペレーティングシステムの更新がスムーズにエラーなしで実行されるようにすることです。
オペレーティングシステムとソフトウェアのバージョン
- オペレーティングシステム： Red Hat Enterprise Linux 6+
要件
システムへの特権アクセス
難易度
簡単
規約
- ＃ –指定されたLinuxコマンドは、rootユーザーとして直接、または
sudoを使用して、root権限で実行する必要があります。 コマンド - $ –通常の非特権ユーザーとして実行されるLinuxコマンドを指定
はじめに
システムを最新の状態に保つことは、システム管理者にとってもデスクトップユーザーにとっても毎日の作業です。システムに最新の（安定した）利用可能なソフトウェアを適用することにより、最新の機能を利用でき、セキュリティの問題からより保護され、バグの影響を受けにくくなります。システムを更新するには、 yumを構成する必要があります 更新されたソフトウェアのソースとして機能するリポジトリ。
更新するオペレーティングシステムを実行しているマシンの隣に座っていると、端末の出力を確認するなど、更新中に問題が発生した場合に簡単に対処できます。また、アップグレードしたシステムがから戻ってこない場合は、稼働中のシステムを起動できます。再起動–ただし、これが常に当てはまるとは限りません。数百または数千の（仮想）マシンを備えたデータセンター、またはリモートでアップグレードする必要がある単なる物理PCを考えてみてください。
アップグレードのためにシステムを準備し、更新の成功を危険にさらす可能性のある問題をクリアするために実行できる簡単な手順があります。
更新プロセス
無条件の更新（「すべて更新」を意味する）を実行する場合、 yum 利用可能なリポジトリからすべてのメタデータをフェッチし、 rpmに対してアップグレードされるすべてのパッケージを計算します システムにインストールされているパッケージに関するすべてのメタデータを含むデータベース。
更新プロセスでは、アップグレードされたパッケージのすべての依存関係も計算され、古いパッケージが置き換えられ、構成に従って古いカーネルイメージが削除される場合があります。保持するカーネルイメージの数は、 /etc/yum.confで設定されます。 構成ファイルであり、デフォルトでは3です：
installonly_limit=3
必要な変更をすべて計算したら、 yum 特定のパッケージをインストールまたはアップグレードする場合と同じように、依存関係のためにアップグレード、削除、またはインストールするすべてのパッケージの広範なリストを提供します。
インタラクティブな更新セッションでyum 以下に示すように、変更するパッケージの概要と、アップグレードのためにダウンロードする必要のあるデータのサイズの計算を提供します。
インタラクティブなyumアップデートの概要 結果を確認した後、更新を開始するかキャンセルするかを決定できます。 yumは更新を見つけることができるすべてのものを更新するので、不要なパッケージを事前に削除することをお勧めします。また、バージョンがロックされており、アップグレードから除外する必要がある、更新のマークが付けられたパッケージに気付く場合があります。
承認後、yumはすべての新しいパッケージをダウンロードし、それらを1つずつインストール/更新します。完了すると、インストール/更新されたパッケージの整合性をチェックし、不要なファイルをクリーンアップします。また、プロセス中にフィードバックを提供し、各ステップのテキスト行と、アップグレードが成功したかどうか、または何らかの問題が発生したかどうかを示唆する終了コードを提供します。また、一貫したシステムの観点から重大と思われる問題が発生した場合は、更新プロセスをキャンセルしますが、すでに手遅れになる場合もあるため、更新の問題が発生しないようにすることをお勧めします。
ディスク容量
yumキャッシュ
上記のプロセスから、更新プロセスにはある程度のディスク容量が必要であると推測できます。
- 更新するすべてのパッケージ（およびそれらの依存関係）の計算が完了するまで、構成されているすべてのリポジトリのメタデータを保存する必要があります。
-
rpmアップデート自体を構成するパッケージは、適切にインストールされるまでローカルに保存する必要があります。
このデータは、 yum cache と呼ばれます 更新中にのみ必要ですが、かなりのディスク領域を占有する可能性があります。このキャッシュのデフォルトの場所は、 / var / cache / yumです。 ディレクトリ。言うまでもなく、必要なすべてのデータを保存するのに十分なスペースがない場合、更新プロセスは失敗します。一部の未完了のダウンロードは削除されますが、すべてのスペースが解放されるわけではないため、システムが更新に失敗し、ボリュームに / var / cacheが含まれることになります。 ほぼ満員です。
多くのインストールでは、 / varが保存されます ログファイルのデフォルトの場所は/var / log であるため、ログ専用のボリューム上のディレクトリ ほとんどのディストリビューションで、ほとんどの正常に動作するアプリケーションは、ログファイルを書き込めない場合、動作を停止するか、クラッシュすることさえあります。したがって、彼らが書き込んでいるボリュームをいっぱいにすることは、悪いことです。 。
より多くのパッケージをアップグレードする必要があり、より多くのリポジトリーがあるほど、更新が一時的に占めるスペースが増えます。更新から更新までのこのスペースを計算するのは困難ですが、正確なソフトウェアコンテンツを備えたテストマシンがあれば、後で説明するドライランソリューションでテストできます。リアルタイムの例では、RHEL 7.1から7.5への更新（Gnomeを使用したデスクトップインストール）には4 GBのキャッシュスペースが必要になる場合がありますが、1〜2か月しか古くないシステムへのいくつかの修正のインストールにかかる時間はわずかです。数MB。
空き容量を確認するには、 dfを使用します コマンド：
# df -h /var/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_sys-var 6.0G 1.7G 4.4G 28% /var
上記の例では、4.4 GBの空き容量があります。これは、サーバーがほんの数か月前に更新されたことを考えると十分です。スペースを解放するための簡単な手順は、 yum cacheをクリアすることです。 すでに保存されています（おそらく最後の更新時）。キャッシュが現在占有しているスペースを確認するには、 duを使用できます。 ：
# du -mcd 1 /var/cache/yum
1103 /var/cache/yum/x86_64
1103 /var/cache/yum
1103 total
上記の数値はMB単位であるため、 yum cache この例では、約1 GBのディスク領域を占有し、 / varの領域の大部分を占めています。 ボリューム。
キャッシュをクリアする
次のコマンドでキャッシュ全体をクリアできます：
yum clean all
しかし、 yumとして RHEL 7バージョンでの上記のコマンドの出力で通知されます。削除または無効化されたリポジトリから孤立したデータが存在する可能性があります。これは、マイナーリリースのアップグレード後に発生する可能性があります。その場合、手動でデータを安全にクリアできます。
rm -rf /var/cache/yum/*
古いログファイルの圧縮/削除、大きなファイルを他のボリュームに移動する、ボリュームサイズを拡張するなど、ボリュームに保存されている他のデータをクリアすることで、更新のためのスペースを増やすことができます。
キャッシュの移動
yumの可能性に取り組むため 、ディスク容量が非常に少なく、それ以上何もクリアできず、ボリュームに容量を追加できない場合は、yumキャッシュの場所を移動できます。 より多くの空き領域がある別のボリュームに。 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などの監視ツールを導入して、すべてのマシンのディスク容量が少ないことを報告できるため、この手順にかかる時間が大幅に短縮され、エラーが発生しやすくなります。
ネットワークエラー
リポジトリと更新を実行するマシン間の接続に問題がある場合、更新が失敗する可能性があります。これは、メタデータまたは新しいrpmのダウンロード段階でのみ発生する可能性があり、システムを破壊することはありません。ネットワークの問題が解決したら、更新プロセスを再開できます。
一方、更新がインタラクティブセッションから初期化された場合、ネットワークが停止すると接続が切断され、更新マシンが管理者なしで yumの質問に答えることができなくなる可能性があります。 尋ねるかもしれません。パッケージのインストール/更新段階がすでに開始されている場合は、無人で続行され、そうでない場合は失敗または完了する可能性があります。再接続後、プロセスは /var/log/yum.logで実行できます。 。
不十分なディスク容量とネットワークの問題は別として、多くの場合、更新は未解決のパッケージ依存関係で失敗する可能性があります。これらは、パッケージの依存関係を計算して処理できるツールで解決する必要がありますが、実際の更新の前に問題が発生することを知っておくと便利です（したがって、システムのダウンタイムが常に短すぎることを無駄にしないでください）。この貴重な情報を取得するために、実際の更新を実行するのと同じように更新プロセスを実行できますが、実際のパッケージのダウンロード、インストール、または更新が行われる前に停止します。
Redhat 6.6の前後で、 yumを引き起こす新しいオプションが導入されました。 実際のパッケージ操作段階の前の承認を含め、更新中に出てくるすべての質問に「いいえ」と想定し、その結果、実際の対話は必要ありません。ドライランを実行します。
yum update --assumeno
これは、アップグレードするパッケージや発生する可能性のあるエラーなど、今後のアップデートのドライランを提供するための理想的なツールになります。次の単純なbashについて考えてみます。 スクリプト：
#!/bin/bash
yum update --assumeno &> $(hostname).yum.dryrun.$(date '+%Y-%m-%d').out
exit $?
上記のスクリプトは自動的に実行でき、ドライランのテキストレポートと、問題を示す全体的な終了コードを提供します。出力をローカルファイルシステムに保存する必要はありません。出力リダイレクトのターゲットは、ネットワークファイルシステムにすることも、レポートを中央のレポートサーバーに投稿することも、他のスクリプトやアプリケーションによって収集することもできます。レポートは公開して他のIT部門に配布し、承認を受けることができます。これにより、関係者全員が、どのパッケージがどのバージョンに更新されるかを正確に確認できます。
ドライランは、 cron を使用して、特定の時間枠（システムのパフォーマンスへの影響を少なくするために夜間）で実行するようにスケジュールできます。 、またはパペット設定で中央ソースから実行されます。終了コードは、監視または facterによって保存および処理することもできます。 、続行する前に、今後のアップグレードの可能な結果を集約します。
結論
1台または数台のコンピューターでも、念のため、オペレーティングシステム全体の更新を開始する前に情報を収集する必要があります。いつの日か問題が発生し、特定のマシンの実際のジョブに影響を与える前に問題を解決できれば、ストレスははるかに少なくなります。大規模な場合、各サーバーまたはデスクトップの隣に座って、更新を問題なく実行するのに役立つことを期待して、プレゼンスでサポートすることは不可能です。
更新プロセスの段階を知ることにより、落とし穴とその解決策が更新を成功させるために不可欠です。問題がないという自信を持ってインフラストラクチャ全体の次の更新段階を開始することは、スタイルを使用して行うことです。