技術メモメモ: 2019

2019年12月25日水曜日

商用OSのEOSを調べてみた！2019年末版

昨年以下記事でまとめた主要な商用OSのEOSについて、今年も調べてアップデートしてみた。

・商用OSのEOSを調べてみた！2018年末版
https://tech-mmmm.blogspot.com/2018/12/oseos2018.html

2020年にサポート期限を迎える製品については、赤字で強調表示した。

なお、本記事で「EOS」と表現する場合は、製品として完全にすべてのサポートが終了する期限を指すことにする。例えば、通常サポートが終了しても延長サポートが存在するような場合は、EOSとは表現しない。

Windows (PC用)

とうとうWindows 7が2020年1月でEOSとなる。2009年9月にリリースされてから10年経過しているが、極端に古いと感じないのは、今でも使用され続けている環境が多いことが理由だろう。

・製品のライフサイクルの検索
https://support.microsoft.com/ja-jp/lifecycle/search

・ご存知ですか？OS にはサポート期限があります！
https://www.microsoft.com/ja-jp/atlife/article/windows10-portal/eos.aspx

・Windows 7 SP 1
延長サポート：2020/01/14 (SP1必須)

・Windows 8.1
延長サポート：2023/01/10

・Windows 10
Windows 10は、今までのWindows OSとサポートポリシーが異なり、モダンライフサイクルポリシーが適用される。なお、今までの単純なメインストリームサポートと延長サポートの構成を「固定ライフサイクルポリシー」と呼ぶ。

Windows ライフサイクルのファクトシート
https://support.microsoft.com/ja-jp/help/13853/windows-lifecycle-fact-sheet

モダンライフサイクルポリシーについて簡単に説明すると、Windows 10では3月と9月の年2回、機能更新プログラムのリリースが予定されており、この機能更新プログラムのリリースから18ヶ月(EnterpriseとEducationのみ9月更新は30ヶ月)が、その機能更新プログラムを適用したWindows 10のサポート期間となる。

機能更新プログラムはYYMMの形式で表現され、2019年12月現在の最新バージョンは1909となる。

以下に現時点におけるサポート中のバージョンを以下に記載する。

・Windows 10, version 1809 サポート終了：2020/05/12
・Windows 10, version 1903 サポート終了：2020/12/08
・Windows 10, version 1909 サポート終了：2021/05/11

Windows Server

Windows Serverは現時点で、Windows Server 2008 R2、2012、2012 R2、2016、2019の5つのバージョンがサポート中の状況となっている。ただし、Windows Server 2008 R2はWindows 7同様、2020年1月でEOSとなる。

なお、Windows Server 2008 R2は、「プレミアムアシュアランス」と呼ばれる特別サポートにより、6年の追加サポートが可能といった情報もあったが、それは無くなったようだ。代わりに、Azure環境や有償サポートで延長ができるような記載は以下サイトにあった。

・Windows Server 2008 および Windows Server 2008 R2 のサポート終了
https://support.microsoft.com/ja-jp/help/4456235/end-of-support-for-windows-server-2008-and-windows-server-2008-r2

・製品のライフサイクルの検索
https://support.microsoft.com/ja-jp/lifecycle/search

・Windows Server 2008 R2 SP1
延長サポート：2020/01/14 (SP1必須)

・Windows Server 2012 / Windows Server 2012 R2
延長サポート：2023/10/10

・Windows Server 2016
メインストリームサポート：2022/01/11
延長サポート：2027/01/11

・Windows Server 2019
メインストリームサポート：2024/01/09
延長サポート：2029/01/09

vSphere

今年は新しいvSphereのバージョンはリリースされることなく過ぎてしまった。2020年はvSphere 5.5がEOSとなる。

・VMware Lifecycle Product Matrix
https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf

・ESXi 5.5 / vCenter Server 5.5
END OF TECHNICAL GUIDANCE：2020/09/19

・ESXi 6.0 / vCenter Server 6.0
END OF GENERAL SUPPORT：2020/03/12
END OF TECHNICAL GUIDANCE：2022/03/12

・ESXi 6.5 / vCenter Server 6.5
END OF GENERAL SUPPORT：2021/11/15
END OF TECHNICAL GUIDANCE：2023/11/15

・ESXi 6.7 / vCenter Server 6.7
END OF GENERAL SUPPORT：2021/11/15
END OF TECHNICAL GUIDANCE：2023/11/15

Red Hat Enterprise Linux

RHEL 8がとうとうリリースされた年であった。2020年はRHEL 5が完全にEOSとなる。RHEL 6も延長サポートフェーズに移る。

・Red Hat Enterprise Linux Life Cycle
https://access.redhat.com/support/policy/updates/errata

・Red Hat Enterprise Linux 5
End of Extended Life-cycle Support：2020/11/30

・Red Hat Enterprise Linux 6
End of Maintenance Support：2020/11/30
End of Extended Life-cycle Support：2024/06/30

・Red Hat Enterprise Linux 7
End of Maintenance Support：2024/06/30
End of Extended Life-cycle Support：未発表

・Red Hat Enterprise Linux 8
End of Maintenance Support：2029/5月
End of Extended Life-cycle Support：未発表

AIX

AIXはTL (Technology Level)毎にサポート期限が異なる。本記事では各メジャーバージョンの最新TLのEOSを記載する。なお、昨年よりAIX 7.1 TL5のサポート期限が1年延長したようだ。

・AIX support lifecycle information
https://www-01.ibm.com/support/docview.wss?uid=isg3T1012517

・AIX 7.1 TL5
End of Service Pack Support ：2023/04/30 (予想)

・AIX 7.2 TL4
End of Service Pack Support ：2022/11/30 (予想)

HP-UX

HP-UXはあまり頻繁なバージョンアップはなく、2007年4月に発表されたHP-UX 11i v3が未だに最新という状況となっている。HP-UX 11i v2のサポート期限が1年延長したようだ。

・長期間利用のための開発方針とサポートポリシー
https://h50146.www5.hpe.com/products/software/oe/hpux/topics/support/

・HP-UX 11i v2
延長サポート終了：2021/12月

・HP-UX 11i v3
標準サポート終了：未発表

参考

・End Of Support (EOS) の調べ方
https://tech-mmmm.blogspot.jp/2015/04/end-of-support-eos.html

2019年12月18日水曜日

BitLocker暗号化手順

Windows OSにて標準で利用できるドライブ暗号化ツールとして「BitLocker」がある。名前は知っていたのだが、インストールして使ったことがなかったので使ってみた。

環境

今回は、仮想環境のWindows Server 2016を使って、TPM(Trusted Platform Module)を利用できない環境でのBitLocker暗号化手順を確認した。

本当はTPMを使った暗号化を試したかったのだが、TPMはハードウェアとして実装されている機能であり、壊してもよいPCもOSもなかったので、今回は仮想環境で試すことにした。
※ちなみに、vCenter Serverがあれば、仮想環境でも仮想TPMが利用できるようだ。

手順

「サーバーマネージャー」→「役割と機能の追加」→「機能の選択」にて、「BitLocker ドライブ暗号化」を選択する。

同時に、必要な機能管理ツールも選択されるので、併せてインストールする。

インストール後、再起動が必要なので再起動する。
再起動後、Cドライブを右クリックすると「BitLockerを有効にする」が選択できるようになる。

ただし、TPMが使えない場合は「このデバイスではトラステッドプラットフォームモジュールを使用できません」というエラーが表示され有効化できない。

上記エラーを回避するため、gpedit.mscを実行し「ローカルグループポリシーエディター」を開き、以下を選択する。
※【注】この手順はTPMが利用できる環境では実施しなくてよい。

「コンピューターの構成」
　→「管理用テンプレート」
　　→「Windowsコンポーネント」
　　　→「BitLocker ドライブ暗号化」
　　　　→「オペレーティングシステムのドライブ」
　　　　　→「スタートアップ時に追加の認証を要求する」

「スタートアップ時に追加の認証を要求する」の項目を選択し、未構成から有効にする。「互換性のあるTPMが装備されていないBitLockerを許可する」に必ずチェックを入れること。それ以外はデフォルトで問題ない。
※【注】この手順はTPMが利用できる環境では実施しなくてよい。
再度、Cドライブを右クリック→「BitLockerを有効にする」を選択すると、暗号化処理を進めることができる。初めにロック解除方法をパスワードにするか、USBキーにするかを選択できる。今回はパスワードで設定する。
「回復キーのバックアップ方法を指定してください」では、以下のいずれかを選択する。今回は「ファイルに保存する」を選択した。

USBフラッシュドライブに保存する
ファイルに保存する
回復キーを印刷する

なお、回復キーをファイルに保存する場合は、暗号化対象のドライブへの保存はエラーとなり実施できない(以下の通り「この場所は使用できません」のエラーとなる)。別ドライブやNASなどのネットワークドライブに保存すること。

「使用する暗号化モードを選ぶ」では、デフォルトの「新しい暗号化モード」とする。Windows 10以降で利用可能なモードとなるが、今時Windows 10以前のOSを使うこともそうそうないため、特別な理由がない限り「新しい暗号化モード」で問題ないだろう。
「このドライブを暗号化する準備ができましたか？」では、「BitLockeシステムチェックを実行する」にチェック入れたままとする。

これをチェックすると暗号化前に再起動を実施し、起動時のパスワードで問題なくログインできるか確認することができる。
再起動後、バックグラウンドで暗号化処理が開始される。

最初はすごく処理に時間がかかるが、途中で突然早くなったりするので、あまり進捗は気にせず待つほうが良い。ちなみに、10GB程度のファイル暗号化で、5分以内に完了した。
暗号化処理が終わると、「ディスクの管理」からも「BitLockerで暗号化済み」と表示されるようになる。

別OSにBitLocker暗号化済みディスクをマウントした場合

暗号化ディスクが別のOSで見た場合、どのように見えるか確認してみた。先ほど暗号化処理を行った仮想マシンをシャットダウンし、Windows Server 2019 (BitLocker未インストール)の別OSにディスクをマウントしてみた。すると、以下の通り鍵付きマークで表示され、ダブルクリックしても反応はなく内容の確認はできなかった。

マウント先のOSにもBitLockerをインストールすると、ダブルクリックして開こうとするとパスワードを求められるようになるので、設定したパスワードを入力することで内容を確認することができる。

2019年11月13日水曜日

グループポリシーを使ってドメインに所属するコンピュータにGoogle Chromeをインストールする2つの方法

以前はブラウザといえば、Internet Explorerが主流となっていたが、近年ではGoogle ChromeやFirefoxがメジャーとなってきており、新しいPCを導入した際にまずやることとして、ブラウザをダウンロードしてインストールする作業が発生することも多い。このインストール作業も1台であれば苦にならないが、何十台とPCが増えた場合は一苦労となる。

ドメインに所属するコンピュータであれば、グループポリシーで自動インストールさせることが可能となる。今回、Google Chromeを自動でインストール (配布)する方法を検証してみた。1つはmsi形式のインストーラを利用する場合の方法、もう1つはexe形式のインストーラを利用する場合の方法となる。

Google Chromeのオフラインインストーラをダウンロードする

Google Chromeは通常ではインターネット接続を前提としたオンラインインストーラが提供されているが、以下方法でオフラインインストーラ (スタンドアロン版)のダウンロードが可能となる。

msi版

Google Chrome Enterpriseのダウンロードサイトに行く本記事執筆時点では以下URLとなる。
https://cloud.google.com/chrome-enterprise/browser/download/?hl=ja
上記URLにてファイルをダウンロードすると、GoogleChromeEnterpriseBundle64.zipといったzipファイルがダウンロードできる。
zipファイルを解凍すると、「Installers」というフォルダの中にGoogleChromeStandaloneEnterprise64.msiがある。本ファイルを利用することでGoogle Chromeのオフラインインストールが可能となる。
※ファイル名に「Enterprise」と書いてあるが、通常のGoogle Chromeと差異はないようだ。

exe版

Google Chromeのダウンロードサイトに行く。本記事執筆時点では以下URLとなる。
https://www.google.com/intl/ja_jp/chrome/
?standalone=1をURLの末尾に付ける。
https://www.google.com/intl/ja_jp/chrome/?standalone=1
通常通りGoogle Chromeをダウンロードすると、ChromeStandaloneSetup64.exeというように「Standalone」がファイル名に付与されたオフラインインストーラがダウンロードされる。本ファイルを利用することでGoogle Chromeのオフラインインストールが可能となる。

それでは、上記ファイルを利用して、グループポリシーを使ってGoogle Chromeのインストールを実施してみよう。

方法①：msi形式のインストーラの場合

msi形式のインストールはグループポリシーで制御するための設定項目が用意されており、アンインストールすることもできることから、可能な限り本方法で対応することをお勧めする。

インストール対象のmsiファイルを共有フォルダに配置する。今回は以下のように共有設定を行いファイルを配置した。Authenticated Usersに権限がないと権限不足でインストールに失敗するようなので追加をしている。
- 共有：Everyone/フルコントロール
- セキュリティ：Authenticated Users/フルコントロールを追加
- パス：\\t1081w219\share
インストール対象のコンピュータアカウントをOUに所属させ、そのOUに適用するGPOを作成する。今回は「msi_test」という名前でOU及びGPOを作成した。
GPOを編集し、「コンピューターの構成」→「ポリシー」→「ソフトウェアの設定」→「ソフトウェアインストール」を選択する。
右クリック→「新規作成」→「パッケージ」を選択する。
ファイル選択のダイアログボックスが表示されるので、共有フォルダに配置したmsiファイルを選択する。
展開方法は「割り当て」を選択する。これでGPOの設定は完了となる。
GPO適用対象のコンピュータを再起動すると、GPOが適用され、ソフトウェアのインストールが自動で実行される。なお、インストール中は「Group Policy Client の処理が完了するのをお待ちください」と表示され、ログインが待機されるようだ。

方法②：exe形式のインストーラの場合

グループポリシーでソフトウェアのインストール制御を行う場合は、インストール・アンインストールの制御が可能なmsi形式のファイルを使った方法①で行うことが望ましい。しかし、msi形式のインストーラが提供されない場合もあるので、その場合は、スタートアップスクリプトとしてexeファイルを指定して実行させることが可能である。

ただし、この方法ではコンピュータを再起動するたびにインストーラが起動してしまうことや、アンインストールの制御は手動対応となる点に注意する必要がある。

インストール対象のexeファイルを共有フォルダに配置する。今回は以下のように共有設定を行いファイルを配置した。Authenticated Usersに権限がないと権限不足でインストールに失敗するようなので追加をしている。
- 共有：Everyone/フルコントロール
- セキュリティ：Authenticated Users/フルコントロールを追加
- パス：\\t1081w219\share
インストール対象のコンピュータアカウントをOUに所属させ、そのOUに適用するGPOを作成する。今回は「msi_test」という名前でOU及びGPOを作成した。
GPOを編集し、「コンピューターの構成」→「Windowsの設定」→「スクリプト」を選択する。
「スタートアップ」をダブルクリックし、「スクリプト」タブで「追加」ボタンを選択する。
「スクリプト名」の「参照」ボタンを選択し、共有フォルダに配置したexeファイルを選択する。これでGPOの設定は完了となる。
GPO適用対象のコンピュータを再起動すると、GPOが適用され、ソフトウェアのインストールが自動で実行される。

2019年11月5日火曜日

Windows ファイアウォールで特定のアプリケーションのみインターネット通信を許可する

WSUSの更新ファイルの取得や、ウイルス対策ソフトの定義ファイル更新などで、Windowsサーバをインターネットと通信させる要件がある場合、単純にインターネット通信をすべて許可してしまうと、ブラウザ等でもインターネット閲覧ができてしまうため、セキュリティ的に問題となる場合がある。

インターネット通信を行うソフトウェアの実行ファイルを特定できる場合は、Windowsファイアウォール (Windows Defenderファイアウォール)にて通信制御を行うことができる。

ただし、Windowsファイアウォールは若干癖のある設定が必要となるので、今回はその設定方法を記載する。

今回の通信要件

以下通信をできるようWindowsファイアウォールを構成する。

対象はWSUSサーバ
ドメインに所属
WSUSのみインターネットから更新ファイルの取得を許可 (WsusService.exeはインターネット通信を許可)
その他の通信はインターネット接続をブロック

それでは、上記を満たすようWindowsファイアウォールを構成してみよう。

Windowsファイアウォールのデフォルトの許可・拒否の動作

Windowsファイアウォールは「受信の規則」と「送信の規則」で分かれており、それぞれのデフォルトの動作は以下の通りとなる。

受信の規則はデフォルト「ブロック」 (変更可)
送信の規則はデフォルト「許可」 (変更可)
規則の中に「許可」と「ブロック」がある場合は、「ブロック」が優先される (変更不可)

拒否が優先して処理される仕様があり、一部許可ルールを書いてからその他をすべて拒否するといった使い方はできないので注意が必要。今回はWSUSのみインターネット通信を許可する必要があるため、送信の規則のデフォルトの動作を「ブロック」に変更する。

デフォルト「ブロック」にするとドメインコントローラとの通信もできなくなる

しかし、送信の規則に対して、デフォルト「ブロック」に変更すると、もともと通信が必要なものまでブロックされてしまうため、サーバ動作に支障をきたしてしまう。ドメイン環境の場合はドメインコントローラとの通信もブロックされてしまう。
以下、送信の規則をデフォルト「ブロック」にした際のドメインコントローラとの通信確認 (ログイン認証及びNTP) の通信を確認した結果となる。どちらもエラーになっていることがわかる。

PS C:\> nltest.exe /SC_QUERY:intrat.local
フラグ: 0
信頼された DC 名
信頼された DC 接続状態 Status = 1311 0x51f ERROR_NO_LOGON_SERVERS
コマンドは正常に完了しました

PS C:\> w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
時刻データが利用できなかったため、コンピューターは同期をとり直しませんでした。

PS C:\> w32tm /query /status
閏インジケーター: 3 (同期未実行)
階層: 0 (未指定)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0004561s
ルート分散: 14.3052780s
参照 ID: 0x00000000 (未指定)
最終正常同期時刻: 2019/11/02 20:17:15
ソース: t1061w216.intrat.local
ポーリング間隔: 6 (64s)

上記も考慮し、Windowsファイアウォールの規則の追加を行う。

Windowsファイアウォールの規則の追加

今回の通信要件を満たすためには、以下2つの規則を追加すればよい。

ルール1：WSUSのインターネット通信を許可

操作：接続を許可する
名前：WSUSダウンロード
プログラム：%ProgramFiles%\Update Services\Services\WsusService.exe
スコープ：リモートIPアドレスにて「事前定義されたコンピューターセット」を選択し、「インターネット」を指定 (下図参照)

ルール2：ドメインコントローラとの通信を許可

操作：接続を許可する
名前：Active Directory
スコープ：リモートIPアドレスに「ドメインコントローラのIPアドレス」を指定

以下の通り2つの規則が追加

インターネット通信の確認

まず、ブラウザでインターネット通信を試みると以下の通りエラーとなって接続できないことがわかる (プロキシ環境となるため、プロキシ通信がエラーとなる)。

一方、WSUSは以下の通りインターネット通信が成功することがわかる (プロキシ環境となるが、問題なく成功した)。

ドメインコントローラとの通信確認

先ほどエラーとなったドメインコントローラの通信も確認しておこう。
ドメインコントローラの認証はSuccessになっていることがわかる。

PS C:\> nltest.exe /SC_QUERY:intrat.local
フラグ: 30 HAS_IP  HAS_TIMESERV
信頼された DC 名 \\t1061w216.intrat.local
信頼された DC 接続状態 Status = 0 0x0 NERR_Success
コマンドは正常に完了しました

NTPによる時刻同期の状況も問題なし。

PS C:\> w32tm /resync
再同期コマンドをローカル コンピューターに送信しています
コマンドは正しく完了しました。

PS C:\> w32tm /query /status
閏インジケーター: 0 (警告なし)
階層: 2 (二次参照 - (S)NTP で同期)
精度: -23 (ティックごとに 119.209ns)
ルート遅延: 0.0010275s
ルート分散: 18.2840513s
参照 ID: 0xC0A80B3D (ソース IP:  192.168.11.61)
最終正常同期時刻: 2019/11/02 20:20:14
ソース: t1061w216.intrat.local
ポーリング間隔: 6 (64s)

以上でWindowsファイアウォールを使って、特定のアプリケーションのみインターネット接続を許可することができた。

2019年9月4日水曜日

RHEL 7やCentOS7でPolicy Based Routing (PBR)を設定する

RHELのサーバにてNICを複数持つ場合、両方のNICから適切に通信できるよう設定しないと、通信の行きと戻りが異なる「非対称ルーティング」となる場合がある。非対称ルーティングの場合、途中にファイアウォール等があると正常に通信を許可することができず、想定した通信ができない。

このような状況を解消するため、RHELにてPolicy Based Routing (PBR)を設定し検証してみた。以下に検証内容と設定手順を記載する。

環境

OS : RHEL 7
NIC1 (ens192) : 192.168.11.191/24
NIC2 (ens224) : 192.168.33.191/24

通信要件

以下通信要件を実現するルーティングテーブルを作成する。

NIC1で受けた通信はNIC1から返す
NIC2で受けた通信はNIC2から返す
対象サーバから送信する通信はNIC1側から行う

通信概要図を以下に記載する。図示されているすべての矢印で問題なく通信できるようにすることが目的となる。

Policy Based Routing設定手順

デフォルトゲートウェイの設定
デフォルトゲートウェイは「サーバ自身から通信を行うNIC」に対して設定する。今回はNIC1 (ens192)で設定しておく。

# ip route show
default via 192.168.11.31 dev ens192 proto static metric 100    ←★NIC1 (ens192)にデフォルトゲートウェイを設定
192.168.11.0/24 dev ens192 proto kernel scope link src 192.168.11.191 metric 100
192.168.33.0/24 dev ens224 proto kernel scope link src 192.168.33.191 metric 101

NIC2用のルーティングテーブルを追加
NIC1用のIPアドレスから送信する場合のルーティングテーブルを作成する。

# ip rule add from 192.168.33.191 table 100 prio 100
# ip rule show
0:      from all lookup local
100:    from 192.168.33.191 lookup 100    ←★追加されたテーブル
32766:  from all lookup main
32767:  from all lookup default

NIC2用のルーティングテーブルにルーティングを設定
NIC1用のテーブルにデフォルトゲートウェイと同セグのルーティングテーブルを追加する。

# ip route add 192.168.33.0/24 dev ens224 proto kernel scope link metric 100 table 100
# ip route add default via 192.168.33.31 table 100
# ip route show table 100
default via 192.168.33.31 dev ens224
192.168.33.0/24 dev ens224 proto kernel scope link metric 100

NIC1用のルーティングテーブルを追加
NIC2用のIPアドレスから送信する場合のルーティングテーブルを作成する。

# ip rule add from 192.168.11.191 table 101 prio 101
# ip rule show
0:      from all lookup local
100:    from 192.168.33.191 lookup 100
101:    from 192.168.11.191 lookup 101    ←★追加されたテーブル
32766:  from all lookup main
32767:  from all lookup default

NIC1用のルーティングテーブルにルーティングを設定
NIC2用のテーブルにデフォルトゲートウェイと同セグのルーティングテーブルを追加する。

# ip route add 192.168.11.0/24 dev ens192 proto kernel scope link metric 100 table 101
# ip route add default via 192.168.11.31 table 101
# ip route show table 101
default via 192.168.11.31 dev ens192
192.168.11.0/24 dev ens192 proto kernel scope link metric 100

これで完了となる。

一見すると、NIC1とNIC2の両方にデフォルトゲートウェイが設定されているため、通常のルーティングテーブル(ip route showで表示されるテーブル)は不要となるように見えるが、サーバ自身から通信を行う場合は、通常のルーティングテーブルを使用するようなので、設定は必要となる。試しに通常のデフォルトゲートウェイを設定せずにpingを実行してみると、ルーティングがないためネットワークに到達できない旨のエラーが表示された。

[root@localhost ~]# ping 192.168.55.1
connect: ネットワークに届きません

動作確認

NIC1側のクライアントからping

192.168.11.0/24のセグメントにいるクライアントからpingを実施して確認してみる。

# ping -c 1 192.168.11.191
PING 192.168.11.191 (192.168.11.191) 56(84) bytes of data.
64 bytes from 192.168.11.191: icmp_seq=1 ttl=64 time=0.114 ms    ←★OK！

--- 192.168.11.191 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.114/0.114/0.114/0.000 ms

# ping -c 1 192.168.33.191
PING 192.168.33.191 (192.168.33.191) 56(84) bytes of data.
64 bytes from 192.168.33.191: icmp_seq=1 ttl=63 time=0.365 ms    ←★OK！

--- 192.168.33.191 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.365/0.365/0.365/0.000 ms

NIC2側のクライアントからping

192.168.33.0/24のセグメントにいるクライアントからpingを実施して確認してみる。

# ping -c 1 192.168.11.191
PING 192.168.11.191 (192.168.11.191) 56(84) bytes of data.
64 bytes from 192.168.11.191: icmp_seq=1 ttl=63 time=0.219 ms    ←★OK！

--- 192.168.11.191 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.219/0.219/0.219/0.000 ms

# ping -c 1 192.168.33.191
PING 192.168.33.191 (192.168.33.191) 56(84) bytes of data.
64 bytes from 192.168.33.191: icmp_seq=1 ttl=64 time=0.110 ms    ←★OK！

--- 192.168.33.191 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.110/0.110/0.110/0.000 ms

再起動してもルーティングテーブルが消えないようにする

NetworkManager-dispatcher-routing-rulesをインストール
NetworkManager-dispatcher-routing-rulesは、以前はNetworkManager-config-routing-rulesと呼ばれていたパッケージとなるが、以下にある通り、パッケージ名が変更されているだけで同じものになるようだ。
- Bug 1334876 - rename package NetworkManager-config-routing-rules to NetworkManager-dispatcher-routing-rules
NetworkManager-dispatcher-routing-rulesは、RHELのインストールISOイメージに含まれていないので、RHELのサイトからRPMファイルをダウンロードしてインストールする。インストール後、NetworkManager-dispatcher.serviceが自動起動するよう設定する。

# rpm -ivh NetworkManager-dispatcher-routing-rules-1.18.0-5.el7.noarch.rpm
警告: NetworkManager-dispatcher-routing-rules-1.18.0-5.el7.noarch.rpm: ヘッダー V3 RSA/SHA256 Signature、鍵 ID fd431d51: NOKEY
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:NetworkManager-dispatcher-routing################################# [100%]
# systemctl enable NetworkManager-dispatcher.service
# systemctl start NetworkManager-dispatcher.service

NIC1用のルーティング設定を追加
以下のようにrule-<デバイス名>とroute-<デバイス名>のファイルを作成する。先ほど手動で設定する際に使ったコマンドから、ip rule addやip route addを省略して書けばよい。

# cat /etc/sysconfig/network-scripts/rule-ens192
from 192.168.11.191 table 101 prio 101
# cat /etc/sysconfig/network-scripts/rule-ens192
default via 192.168.11.31 table 101
192.168.11.0/24 dev ens192 proto kernel scope link metric 100 table 101

NIC2用のルーティング設定を追加
同様にNIC2用のファイルを作成する。

# cat /etc/sysconfig/network-scripts/rule-ens224
from 192.168.33.191 table 100 prio 100

# cat /etc/sysconfig/network-scripts/route-ens224
default via 192.168.33.31 table 100
192.168.33.0/24 dev ens224 proto kernel scope link metric 100 table 100

OS再起動
OS再起動してルーティングテーブルを確認すると、以下の通り問題なく設定されていることがわかる。

# ip rule show
0:      from all lookup local
100:    from 192.168.33.191 lookup 100
101:    from 192.168.11.191 lookup 101
32766:  from all lookup main
32767:  from all lookup default

# ip route show table 100
default via 192.168.33.31 dev ens224
192.168.33.0/24 dev ens224 proto kernel scope link metric 100

# ip route show table 101
default via 192.168.11.31 dev ens192
192.168.11.0/24 dev ens192 proto kernel scope link metric 100

(参考) 削除コマンド

参考までに、削除コマンドは以下の通りとなる。

# ip route del default table 100
# ip route del 192.168.33.0/24 table 100
# ip rule del table 100

# ip route del default table 101
# ip route del 192.168.11.0/24 table 101
# ip rule del table 101

参考

2019年8月21日水曜日

最小インストールしたRHEL 7に、GUI環境 (Gnome)を追加インストールする方法

個人的にRed Hat Enterprise Linux 7 (以降、(RHEL 7))を使う場合、ほとんどGUI環境 (Gnome)をインストールして使うことはないのだが、今回使う必要性がでてきたため、最小インストールした状態のRHEL 7に対して、後からGUI環境をインストールする手順を確認してみた。

環境

RHEL 7.6

手順

DVDのOSイメージをマウント

# mount /dev/cdrom /mnt

マウントしたイメージをレポジトリとして設定

# vi /etc/yum.repos.d/dvd.repo

[dvd]
baseurl=file:///mnt/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release

yumでインストールを実施
dvd.repoファイルを作成することで、yumが使えるようになる。982件のパッケージが追加インストールされる。

# yum groupinstall "Server with GUI"
読み込んだプラグイン:product-id, search-disabled-repos, subscription-manager
This system is not registered with an entitlement server. You can use subscription-manager to register.
リポジトリー 'dvd' は構成中に名前がありませんので ID を使います
There is no installed groups file.
Maybe run: yum groups mark convert (see man yum)
dvd                                                      | 4.3 kB     00:00
(1/2): dvd/group_gz                                        | 146 kB   00:00
(2/2): dvd/primary_db                                      | 4.2 MB   00:00
パッケージ 1:NetworkManager-config-server-1.12.0-6.el7.noarch はインストール済みか最新バージョンです
Warning: Group core does not have any packages to install.
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ ModemManager.x86_64 0:1.6.10-1.el7 を インストール
--> 依存性の処理をしています: ModemManager-glib(x86-64) = 1.6.10-1.el7 のパッケ ージ: ModemManager-1.6.10-1.el7.x86_64
--> 依存性の処理をしています: libmbim-utils のパッケージ: ModemManager-1.6.10-1.el7.x86_64

～(中略)～

トランザクションの要約
================================================================================
インストール  275 パッケージ (+707 個の依存関係のパッケージ)

総ダウンロード容量: 701 M
インストール容量: 2.1 G
Is this ok [y/d/N]:y　　　←★yを入力
Downloading packages:
警告: /mnt/Packages/GConf2-3.2.6-8.el7.x86_64.rpm: ヘッダー V3 RSA/SHA256 Signature、鍵 ID fd431d51: NOKEY
GConf2-3.2.6-8.el7.x86_64.rpm の公開鍵がインストールされていません
--------------------------------------------------------------------------------
合計                                                43 MB/s | 701 MB  00:16
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release から鍵を取得中です。
Importing GPG key 0xFD431D51:
 Userid     : "Red Hat, Inc. (release key 2) <security@redhat.com>"
 Fingerprint: 567e 347a d004 4ade 55ba 8a5f 199e 2f91 fd43 1d51
 Package    : redhat-release-server-7.6-4.el7.x86_64 (@anaconda/7.6)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
上記の処理を行います。よろしいでしょうか？ [y/N]y　　　←★yを入力
Importing GPG key 0x2FA658E0:
 Userid     : "Red Hat, Inc. (auxiliary key) <security@redhat.com>"
 Fingerprint: 43a6 e49c 4a38 f4be 9abf 2a53 4568 9c88 2fa6 58e0
 Package    : redhat-release-server-7.6-4.el7.x86_64 (@anaconda/7.6)
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
上記の処理を行います。よろしいでしょうか？ [y/N]y　　　←★yを入力
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
警告: RPMDB は yum 以外で変更されました。
  インストール中          : atk-2.28.1-1.el7.x86_64                       1/982
  インストール中          : fontpackages-filesystem-1.44-8.el7.noarch     2/982

～(中略)～

ランレベル変更
RHEL 6では/etc/inittabを変更してランレベルを変更していたが、RHEL 7ではコマンドで変更する。

# systemctl get-default
multi-user.target

# systemctl set-default graphical.target
Removed symlink /etc/systemd/system/default.target.
Created symlink from /etc/systemd/system/default.target to /usr/lib/systemd/system/graphical.target.

OS再起動

# reboot

再起動後確認
再起動すると無事GUI環境で起動してくる。初回起動時は、初期セットアップウィザードが表示されるので、適宜設定する。なお、root以外のアカウントが設定されていない場合は、新規に1つユーザ作成が必要となるので注意。

初期セットアップウィザードの画面。言語やタイムゾーンなどを選択する。

ウィザードが終了すると、ようやくGUI環境が使えるようになる。

ログイン後の画面。特にエラーもなく、問題なく動作しているようだ。

2019年8月14日水曜日

Red Hat Enterprise Linux 8をインストールして、動作確認してみた

とうとうRed Hat Enterprise Linux 8 (以降RHEL 8)が2019年5月7日にリリースされた。忙しくて試すことができていなかったが、ようやく評価ライセンスとISOをダウンロードして試すことができたので、インストール手順と簡単に動作確認をした結果を記載する。

インストール手順はRHEL 7と大差ない

ESXi 6.7 Update 1環境にインストールしてみる。

ESXiで仮想マシン作成時に「Red Hat Enterprise Linux 8 (64ビット)」を選択しておく。
ISOイメージから起動させ、「Install Red Hat Enterprise Linux 8.0.0」を選択する。デフォルトでは、「Test this media 8 install Red Hat Enterprise Linux 8.0.0」が選ばれているが、メディアスキャンが必要な場合はほとんどないし、時間もかかるのでお勧めしない。
言語はいつも通り日本語を選ぶ。
RHEL 7に比べて、設定画面は見やすくなった。
RHEL 7はデフォルトで「最小限のインストール」だったが、RHEL 8ではデフォルトが「サーバー (GUI使用)」なので注意。GUI環境が不要な場合は、必ず変更しよう。今回は「最小限のインストール」でインストールすることにし、仮想環境なので「ゲストエージェント」のみにチェックを入れてみた。
インストールが開始される。

最小限のインストールであれば、10分もかからないで完了するはず。
特にエラーもなく起動できた。

設定コマンド等もRHEL 7と大差ない

基本的なコマンドはRHEL 7と変更になっていないようだ。以下、変更がなかったコマンドを列挙する。

設定項目	コマンド
サービス設定	`systemctl`
パッケージ管理	`yum` (後述するが実態は`dnf`へのシンボリックリンク)
リソース確認	`top`, `vmstat`
NIC設定	`nmcli`, `nmtui`
ネットワーク確認	`ip a`, `ip r`, `ss`, `ping`, `tracepath`
ディスク設定	`fdisk`, `parted`, `pvcreate`, `vgcreate`, `lvcreate`
ディスク確認	`df`, `pvdisplay`, `vgdisplay`, `lvdisplay`

OS基本情報を確認

カーネルバージョンが4.x台になっている。

[root@localhost ~]# uname -a
Linux localhost.localdomain 4.18.0-80.el8.x86_64 #1 SMP Wed Mar 13 12:02:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.0 (Ootpa)

ファイルシステムを確認

RHEL 7をvSphere環境で作る際はBIOSが選択されていたが、RHEL 8の場合はUEFIが選択されるようになる。それによるディスクパーティション構成に差異があるようだ。
最も大きな違いは、パーティションテーブルが「GPT」になっていることだと思う。

[root@localhost ~]# df -h
ファイルシス          サイズ  使用  残り 使用% マウント位置
devtmpfs                900M     0  900M    0% /dev
tmpfs                   915M     0  915M    0% /dev/shm
tmpfs                   915M  8.7M  907M    1% /run
tmpfs                   915M     0  915M    0% /sys/fs/cgroup
/dev/mapper/rhel-root    13G  1.3G   12G   11% /
/dev/sda2              1014M  158M  857M   16% /boot
/dev/sda1               599M  6.6M  593M    2% /boot/efi
tmpfs                   183M     0  183M    0% /run/user/0

[root@localhost ~]# parted /dev/sda p
モデル: VMware Virtual disk (scsi)
ディスク /dev/sda: 17.2GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:

番号  開始    終了    サイズ  ファイルシステム  名前                  フラグ
 1    1049kB  630MB   629MB   fat32             EFI System Partition  boot, esp
 2    630MB   1704MB  1074MB  xfs
 3    1704MB  17.2GB  15.5GB                                          lvm

YumがDNFになった

Yumが後継のDNFに代わっている。yumコマンドはdnfコマンドのシンボリックリンクとなっている。なお、DNFは「Dandified Yum」の略称。「ダンディーなYum」ってこと？

[root@localhost ~]# yum
Updating Subscription Management repositories.
Unable to read consumer identity
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
usage: dnf [options] COMMAND

～(以下略)～

2019年7月31日水曜日

Windows ServerにVMware Toolsをサイレントインストールする方法

Windows版のVMware Toolsは、昔からGUIによるインストーラが提供されており、GUIによるインストール操作が必要となっていた。

しかし、仮想マシンの台数が増えるとGUIで操作するのは手間となるので、サイレントインストールする手順を調べてみた。

VMware Toolsサイレントインストール手順

結論から言うと以下をコマンドプロンプトまたはPowerShellで実行すればよい。

PS C:\> D:\setup.exe /S /v "/qn"

なお、VMwareのKBなどでは、/vオプションの後の""はスペースなしで実行しているが、なぜかPowerShellでは実行できない(GUIのウィザードが表示される)。上記で示したコマンドのように、/vオプションの後にスペースを入れれば、コマンドプロンプトでもPowerShellでも、どちらでも問題なく実行できるようだ。

実際に試してみよう。

DドライブにVMware Toolsのメディアがマウントされた状態となる。

PowerShellを「管理者として実行」で開く。

先ほどのコマンドを実行してインストールを開始する。タスクマネージャーを開くと、「VMware installation launcher」などが実行されていることがわかる。

インストール終了後、自動でOSが再起動される。

OS再起動後、問題なければESXiにてVMware Toolsがインストール済み状態となる。

なお、インストール後に自動再起動を抑制したい場合は、以下コマンドを実行すればよい。

PS C:\> D:\setup.exe /S /v "/qn REBOOT=ReallySuppress"

参考

Windows 仮想マシンに VMware Tools をインストールする (1018377)
https://kb.vmware.com/s/article/1018377?lang=ja

2019年7月24日水曜日

RHEL 7でpartedコマンドを使って、2TB以上のディスクをLVMとして使えるようにする

RHEL 7で2TB以上のサイズのディスクを使用する場合、fdiskでパーティション作成をしようとすると、以下のようにWARNINGメッセージで怒られる。

[root@localhost ~]# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.23.2).

Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x5a730435.

WARNING: The size of this disk is 3.2 TB (3221225472000 bytes).
DOS partition table format can not be used on drives for volumes
larger than (2199023255040 bytes) for 512-byte sectors. Use parted(1) and GUID
partition table format (GPT).

どうやらディスクサイズが2TB以上の場合は、DOS partition (いわゆるMBR)形式ではフォーマットできないので、partedコマンドを使ってGPT形式でフォーマットせよ、とのことらしい。

といわけで、partedコマンドでパーティション作成を実施してみよう。

環境

OSはRHEL 7.6となる。fdisk -lで確認したディスクの認識状況は以下の通り。

[root@localhost ~]# fdisk -l

Disk /dev/sda: 17.2 GB, 17179869184 bytes, 33554432 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト
Disk label type: dos
ディスク識別子: 0x000b36a6

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sda1   *        2048     2099199     1048576   83  Linux
/dev/sda2         2099200    33554431    15727616   8e  Linux LVM

Disk /dev/sdb: 3221.2 GB, 3221225472000 bytes, 6291456000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O サイズ (最小 / 推奨): 512 バイト / 512 バイト

/dev/sdbが、3221GBほどあるので、これを「GPT形式」で「LVM」のディスクとして使えるようにする。

`parted`でパーティションを作成

1. パーティション作成前の状況を確認

作業前にpartedコマンドを使ってディスクの状況を確認する。操作体系はfdiskと似ており、「p」コマンドにて確認できる。

[root@localhost ~]# parted /dev/sdb
GNU Parted 3.1
/dev/sdb を使用
GNU Parted へようこそ！ コマンド一覧を見るには 'help' と入力してください。
(parted) p　　　←★pで状況表示
エラー: /dev/sdb: ディスクラベルが認識できません。
モデル: VMware Virtual disk (scsi)
ディスク /dev/sdb: 3221GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: unknown
ディスクフラグ:

2. GPT形式に設定

mklabelでGPT形式に設定する。

(parted) mklabel gpt　　　←★GPTに設定
(parted) p
モデル: VMware Virtual disk (scsi)
ディスク /dev/sdb: 3221GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt　　　←★GPTになっている
ディスクフラグ:

番号  開始  終了  サイズ  ファイルシステム  名前  フラグ

3. パーティション作成

mkpartでパーティションを作成する。「パーティションの名前」や「ファイルシステムの種類」は空白で問題ないようだ。
ただし、設定値を誤ると「アライメントが正しくないためにパフォーマンスがでません」という警告が出る。以下に実行例を記載する。

(parted) mkpart
パーティションの名前?  []?　　　　　　←★空白でOK
ファイルシステムの種類?  [ext2]?　　　←★空白でOK
開始? 0
終了? 3221G
警告: 操作の結果できるパーティションはアライメントが正しくないためにパフォーマンスがでません。
　　　↑★警告が表示される
無視(I)/Ignore/取消(C)/Cancel? I
(parted) p
モデル: VMware Virtual disk (scsi)
ディスク /dev/sdb: 3221GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:

番号  開始    終了    サイズ  ファイルシステム  名前  フラグ
 1    17.4kB  3221GB  3221GB

警告を出さないようにするには、単位を「%」で指定すればよい。これでエラーなくパーティション「1」が作成された。

(parted) mkpart
パーティションの名前?  []?　　　　　　←★空白でOK
ファイルシステムの種類?  [ext2]?　　　←★空白でOK
開始? 0%
終了? 100%
(parted) p
モデル: VMware Virtual disk (scsi)
ディスク /dev/sdb: 3221GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:

番号  開始    終了    サイズ  ファイルシステム  名前  フラグ
 1    1049kB  3221GB  3221GB

4. LVMに設定

パーティション番号「1」に対して、LVMを有効に設定する。

(parted) set 1 lvm on
(parted) p
モデル: VMware Virtual disk (scsi)
ディスク /dev/sdb: 3221GB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:

番号  開始    終了    サイズ  ファイルシステム  名前  フラグ
 1    1049kB  3221GB  3221GB                          lvm
↑★フラグに「lvm」と表示されている

(parted)

5. `parted`を終了

これでパーティション作成は終了となる。partedを終了すると、「/etc/fstabの更新を忘れないように」と、親切に表示される。

(parted) q
通知: 必要であれば /etc/fstab を更新するのを忘れないようにしてください。

PV・VG・LVを作成

PV・VG・LV作成は、MBRと同様の手順で実施できる。簡単に作業結果のみ記載する。ちなみに、確認系コマンドはコマンドが短くて打ちやすかったので以下を使ってみた。

確認対象	定番コマンド	今回コマンド
PV	`pvdisplay`	`pvs`
VG	`vgdisplay`	`vgs`
LV	`lvdisplay`	`lvs`

1. PV作成

[root@localhost ~]# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created.
[root@localhost ~]# pvs
  PV         VG   Fmt  Attr PSize   PFree
  /dev/sda2  rhel lvm2 a--  <15.00g     0
  /dev/sdb1       lvm2 ---   <2.93t <2.93t

2. VG作成

LVMの時代はPEの個数に65536個上限の制約があり、-sオプションでPEサイズを大きく指定する必要があったようだが、現在はLVM2が使われており、PE個数の上限の心配はしなくてよい。

[root@localhost ~]# vgcreate data /dev/sdb1
  Volume group "data" successfully created
[root@localhost ~]# vgs
  VG   #PV #LV #SN Attr   VSize   VFree
  data   1   0   0 wz--n-  <2.93t <2.93t
  rhel   1   2   0 wz--n- <15.00g     0

3. LV作成

[root@localhost ~]# lvcreate -n data -l 100%FREE data
  Logical volume "data" created.
[root@localhost ~]# lvs
  LV   VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data data -wi-a----- <2.93t                                                   
  root rhel -wi-ao---- 13.39g                                                   
  swap rhel -wi-ao----  1.60g

4. ファイルシステム作成

RHEL 7だったのでxfsにする。

[root@localhost ~]# mkfs.xfs /dev/data/data
meta-data=/dev/data/data         isize=512    agcount=4, agsize=196603904 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=786415616, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=383992, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

5. マウント

試しに手動でマウントしてみる。

[root@localhost ~]# mkdir /data
[root@localhost ~]# mount /dev/mapper/data-data /data
[root@localhost ~]# df -h
ファイルシス          サイズ  使用  残り 使用% マウント位置
/dev/mapper/rhel-root    14G  1.1G   13G    8% /
devtmpfs                908M     0  908M    0% /dev
tmpfs                   920M     0  920M    0% /dev/shm
tmpfs                   920M  8.9M  911M    1% /run
tmpfs                   920M     0  920M    0% /sys/fs/cgroup
/dev/sda1              1014M  146M  869M   15% /boot
tmpfs                   184M     0  184M    0% /run/user/0
/dev/mapper/data-data   3.0T   33M  3.0T    1% /data

6. OS起動時の自動マウント設定

partedコマンド終了時に親切に言われているので、/etc/fstabにマウント設定を追記しておこう。

[root@localhost ~]# cat /etc/fstab

/dev/mapper/rhel-root   /                       xfs     defaults        0 0
UUID=1b3eb24d-7d2c-4023-9d4d-933bea63cd3f /boot                   xfs     defaults        0 0
/dev/mapper/rhel-swap   swap                    swap    defaults        0 0
/dev/mapper/data-data   /data                   xfs     defaults        0 0
　↑★追記

以上で作業は完了となる。

2019年7月17日水曜日

RHEL 7のemergency modeを体験した話

先日RHEL 7のディスクマウントの検証をしていた際に、OS再起動後、emergency modeになって正常に起動できなくなってしまった。

対処した内容

rootパスワードでログインせよ、と記載されているのでrootパスワードを入力してログインしてみる。

ログインすると通常のコマンドを受け付ける状態になる。

emergency modeの冒頭のメッセージに記載されていたjournalctl -xbを素直に叩いてみる。すると、大量の起動時のログが出力されるので、ひたすらスペースキーを押して確認していくと、ログの終盤に赤字のエラーログを発見した。

メッセージは以下。

Time out waiting for device dev-mapper-rhel\x2ddata.device.

どうやらLVM2のデーモンがデバイスのタイムアウトで異常終了している模様。直前に設定した/etc/fstabがあやしいので確認してみると、デバイス名をミスっている。。。

[root@localhost ~]# cat /etc/fstab

/dev/mapper/rhel-root   /                       xfs     defaults        0 0
UUID=1b3eb24d-7d2c-4023-9d4d-933bea63cd3f /boot                   xfs     defaults        0 0
/dev/mapper/rhel-swap   swap                    swap    defaults        0 0
/dev/mapper/rhel-data   /data                   xfs     defaults        0 0
　↑★rhel-dataではなくdata-dataが正しい

上記を修正して再起動すると、問題なく起動することができた。よかったよかった。

……と思ったのだが、fstabの記述ミスはともかく、障害等でディスクが見えない状況となった場合もemergency modeになってしまい、OSが起動できなくなるという問題がある。

そこで今回は、もしマウントが失敗する場合であっても、該当のマウント処理をスキップしてOSを起動させる方法も調べてみた。

回避策「fstabで`nofail`をオプションを指定する」

emergency modeとなった原因の「/etc/fstab」は、以下構文で記載する。

<ストレージデバイス> <マウントポイント> <ファイルシステム> <マウントオプション> <dumpコマンドの対象とするか> <起動時にfsckでファイルチェックを行うか>

上記の「マウントオプション」は通常defaultsのみ指定をすることが多いが、ここにnofailオプションも追加し、nofail,defaultsを指定する。このオプションにより、OS起動時にストレージデバイスが存在しない場合でもエラーとならず、OS起動に成功する。

# cat /etc/fstab
/dev/mapper/rhel-root   /                       xfs     defaults        0 0
UUID=68f1f8f7-ab56-410a-aa4c-8401fc6f7894 /boot                   xfs     defaults        0 0
/dev/mapper/rhel-swap   swap                    swap    defaults        0 0
/dev/mapper/vg_sdb1-lv_sdb1   /                 xfs     nofail,defaults 0 0　←★nofailを指定

「/var/log/messages」にはemergency mode時と同様に、Timed out waiting for device dev-mapper-vg_sdb1\x2dlv_sdb1.device.のエラーメッセージが出力されるが、その後Startup finishedと表示されており、起動に成功していることがわかる。

# tail /var/log/messages
Aug 29 16:01:01 localhost systemd: Removed slice User Slice of root.
Aug 29 16:01:37 localhost systemd: Job dev-mapper-vg_sdb1\x2dlv_sdb1.device/start timed out.
Aug 29 16:01:37 localhost systemd: Timed out waiting for device dev-mapper-vg_sdb1\x2dlv_sdb1.device.
Aug 29 16:01:37 localhost systemd: Dependency failed for /mnt2.
Aug 29 16:01:37 localhost systemd: Job mnt2.mount/start failed with result 'dependency'.
Aug 29 16:01:37 localhost systemd: Startup finished in 498ms (kernel) + 3.065s (initrd) + 1min 30.363s (userspace) = 1min 33.927s.
Aug 29 16:01:37 localhost systemd: Job dev-mapper-vg_sdb1\x2dlv_sdb1.device/start failed with result 'timeout'.
Aug 29 16:01:49 localhost systemd: Created slice User Slice of root.
Aug 29 16:01:49 localhost systemd: Started Session 2 of user root.
Aug 29 16:01:49 localhost systemd-logind: New session 2 of user root.

上記設定をしたのち、試しに仮想ディスクを取り外した状態で仮想マシンを起動させてみたところ、問題なく起動することができた。

登録: 投稿 (Atom)