Red Hat Enterprise Linux 7 インストール時の注意点

RED HAT ENTERPRISE LINUX 71

Red Hat Enterprise Linux 7 インストール時の注意点

レッドハット株式会社ソリューションアーキテクト

森若和雄 <[email protected]>2015-03-07


この資料の位置づけ

● 対象: RHEL6までのインストール経験がある方● 目的:

● RHEL6から7で大きく変更があった点についての紹介● RHEL7のインストール・構築で問題になりがちな点の解

説


目次

● インストール前の確認事項● 実際のインストール● systemd● NetworkManager● 既知の問題


インストール前の確認事項


ドキュメント

RHEL7公式ドキュメントから http://red.ht/1AtNyO1

● Installation Guide

● インストールを手順に従って紹介しています● Networking Guide

● RHEL7で大きく変更があったネットワーク管理について紹介しています

● Storage Administration Guide

● ストレージ管理について紹介しています● Release Notes

● Known Issueに既知の問題が記載されています● Migration Planning Guide

● RHEL6からRHEL7での変更点を紹介しています


各種認定の確認

サポートされる環境を整えます● ハードウェアの認定

● https://access.redhat.com/certifications● ISV製品の認定

● ISVによる認定● 利用予定のISVへ対応OSをご確認ください

● ストレージの認定● ストレージベンダによる認定● 利用予定のストレージベンダへ対応OSをご確認く

ださい


https://access.redhat.com/certifications

2. Red Hat Enterprise Linux 7を

選択してから

3. submitで検索

1. Browse CertifiedHardware をクリック


ソフトウェアの入手

● RHEL7は、RHN Classicからの入手ができません● カスタマーポータル下の「Quick Link」から

「Downloads」を選択→Product Downloadsページ

Red Hat Enterprise Linuxを

選択


BIOSかUEFIか?

● 起動ディスクの容量がBIOSの制限(2TB)に収まらない場合はUEFIを選択

● インストーラの動作環境によりパーティショニングの動作が変わります:

● UEFIの場合、GPTだけを利用します● BIOSか、UEFIのBIOS互換モードの場合

● ディスクのサイズが2TBより大きい→GPT、 2TB以下→MSDOS式

● ”inst.gpt”オプションで小さな容量のディスクへGPTを強制します

● 2TB以上のディスクに対してMSDOS式のパーティションテーブルを強制する方法はありません


パーティション分割

RHEL6以前から大きく変わったもの● /と/usrを分割しないことをおすすめします

● /binや/libなどの実体も/usr以下にあるため、/だけをmountしてもほぼ何も作業ができません。そのためトラブルシュート時に手間が増えます

● /boot は500MB● /bootは従来250MBが推奨されていましたが、現在は

事実上全てのファームウェアで500MBまで利用できるため、推奨サイズが500MBなっています


swap容量の推奨

RAM容量推奨

2GB以下 RAM容量の2倍

2GBから8GB RAM容量と同量

8GBから64GB RAM容量の半分

64GB以上ワークロードに依存します。特に推奨値はありません

RHEL6からここが変わりました


デフォルトファイルシステムがext4からXFSへ

● XFS: デフォルト。500TBまでサポート● ext4: 50TBまでサポート

● ext2, ext3: ext4ドライバで引き続きサポート● btrfs: Technology Preview

種類サイズ上限 Root Boot メモ

Single-node

XFS 500TB Yes Yes デフォルト

ext4 50TB Yes Yes ext2, ext3は16TBまで

btrfs 50TB Yes Yes Technology Preview

Network/Multi-node

GFS2 250TB No No 共有ストレージ


NIC命名規則

● デバイス名をファームウェアの情報から命名するようになりました。物理的な位置と対応した名前が命名されます。

● 例: eno1, ens1, enp3, enp2p0, wlp3

enwl

o<index>s<slot>p<bus>s<slot>

ethernet (en)wireless (wl)

on boardslotPCI

1スロットに2つ以上機器や機能がある場合

function番号(fX)やdevice番号(dX)を付与

(カードの構成によります)

f<function>d<device>

詳しくは「Networking Guide」内「Consistent Network Device Naming」http://red.ht/1DwBVoq


KVM(virtio-net)でのNIC命名

● KVMで利用されるvirtio-netについては、従来と同様の命名（eth0など）がおこなわれます

● このときNIC名の維持には、 /etc/sysconfig/network-scripts/ifcfg-eth0 などの中のHWADDRが利用されています

● HWADDRの設定を削除するとethXの名前が安定して付けられなくなります。

● 仮想マシンイメージをコピーして利用する時などに問題になります


VLANネットワークデバイス名

● サポートされる vlanのネットワークデバイス名の命名規則が増えました

● vlan<VLANタグ番号> 例: vlan0005, vlan0024● vlan<パディングなしVLANタグ番号> 例: vlan5,

vlan24● <物理NIC名>.<VLANタグ番号> 例: ens1.0005,

enp3s0f1.0024● <物理NIC名>.<パディングなしVLANタグ番号> 例:

eno1.5, enp2s1.24● デバイス名が長く、linux kernelの15文字制限に影響をうける場合vlanXXXXの命名を利用して回避します


bondingかteamdか?

● ほとんど全てのユースケースでbondingでよいです● teamdが欲しいケースは?

● active-standbyでポートに優先度を付けたい/failbackを禁止したい場合

● NS/NA (IPv6) link monitoringを使いたい場合● 経路毎にリンク確認方法が違うなどの変則的な場合

● teamdの設定の書き方は……?● 現状NetworkManagerではあまり支援がなく、JSON

を手で書く必要がある● /usr/share/doc/teamd-*/example_configs/ に例が多数あります


firewalldかiptablesか?

● デフォルトのファイアウォール機能としてfirewalldが含まれました

● iptablesサービスも引き続き利用可能ですが、firewalldと競合します

● firewalldを使いたいケースは?

● 複数ネットワークがからむケース● ネットワーク別のポリシー設定が非常に簡単です

● ネットワーク環境がころころかわるようなケース● 後述するNetworkManagerのコネクションとfirewalldのzone

をひもづけられ、ネットワーク環境の変化にあわせて適切にファイアウォール設定を更新できます

● 通信するサービスがころころかわるようなケース● サービスの追加・削除時に既存のコネクションを切らずに設

定変更が可能です● iptablesサービスを使いたいケースは?

● 既存のiptables設定を引き続き利用したい場合


kickstartか対話インストールか?

● kickstartが便利なシーン

● 同一構成サーバを多数構築する場合● パッケージ単位の導入指定が必要な場合● ファイアウォールの設定を含む場合● SELinuxのdisableをしたい場合

● kickstartの注意点

● kickstart-configurator(system-config-kickstart)は開発が停止しており、RHEL7に含まれていますがanacondaの更新に追従していません

● カスタマーポータル内「kickstat configuration tool」がRHEL7に対応しています

● https://access.redhat.com/labs/kickstartconfig/



実際のインストール


インストール時の登場人物

● anaconda インストーラ本体● initial-setup 再起動後の処理をおこなう

従来のfirstbootに相当● ユーザ作成● EULAへの同意確認

● firstboot initial-setup後に実行● （7.0のみ） kdump設定● サブスクリプション登録


anacondaの画面フロー

● 基本的にはハブ&スポークとよばれるモデル● UIは残念ながらあまり直感的ではない

● 特にひっかかりやすいディスク切り分けの設定は、以下ページで紹介します

● 各種Alertが画面最下部にオレンジ色背景で出ますが、これを見逃しやすいので注意

start hub hub end

spoke spoke

spoke spoke

spoke

spoke


ディスク選択&パーティショニング

新しいanacondaで最大の難所?

こまかく見ていきましょう……


インストール先の選択

アラートはここにでます



1. 使う物理ディスクを選択

2. ネットワーク経由のiSCSIなどの追加

3. パーティションを自分で設定する指定


4. [Done]で詳細の画面へ移動他のspokeではhubに戻るボタンなので

ここでビックリしがち


ついつい上から下に操作していきたくなりますよね

でも操作の順番はそうではないのです……


1. 先にこちらでパーティショニングのしくみを選択して

2. パーティショニングを自動生成させる（オプション）


自動生成?

● 自動生成はしなくてもOK● もろもろの推奨値を反映してくれるので、自動生成

してから編集すると便利です● 手動設定時の注意

● /boot, /boot/efiをパーティション上に置く● swap容量などを推奨値にあわせる


“Standard Partition”は起動環境とディスク容量から

GPTかMS-DOS式か自動設定

パーティショニング方式の選択


2. 追加、削除、パラメータ変更をおこないます

1. 変更したいパーティションを選択して

3. 全部消してやり直しボタンundoではないので注意


anacondaが自動生成した操作プランの確認画面

1から順に実施していくよ


kdump設定のタイミング

● kdump設定はRHEL7.0時点ではanacondaに統合されておらず、再起動後のfirstbootのタイミングで行われていました

● RHEL7.1からはanaconda内で設定をおこないます


システム登録

● RHEL7ではRed Hat Satelliteを利用している場合をのぞき、 subscription-managerによる登録が必要です

● Red Hat Network Classicへの登録はできなくなりました● # subscription-manager register --username <username> --password <password> --auto-attach

● 詳しくは「サブスクリプション管理ガイド」● https://access.redhat.com/documentation/en-US/

Red_Hat_Subscription_Management/● Registration Assistant

● https://access.redhat.com/labs/registrationassistant/● RHELのバージョンや登録先を選択すると適切なコマン

ドを表示します



systemd


systemdって？

● RHEL7で導入されたシステムとサービスの管理をおこなうたくさんのユーティリティ、サービス、ライブラリ群

● 「 SysV initの置き換え」とよく言われますが単純な置き換えではありません

● 目標は？● 高速化● ディストリビューション独自実装の統廃合

● RHEL, Fedora, OpenSUSE, Debian, Gentoo, ArchLinux, Ubuntu でsystemd利用可(または予定)

● ベストプラクティスの統合● よくあるバグの回避● セキュリティ向上の工夫を簡単に利用


systemdでの互換性の維持

● SysV, LSBの init scriptsからunitファイルを自動生成● インタフェースの互換性維持

● dbus: ConsoleKit等● ソケット: /dev/initctl, /dev/log互換ソケット● 「ランレベル」への対応: runlevelX.target, カーネルコマン

ドラインオプション(1,2,3,4,5,6,S,emergency 等)● 互換コマンドの提供

● halt, init, poweroff, reboot, runlevel, shutdown, telinit の置き換えを同梱

● serviceコマンドを実行するとsystemctlを呼びだす

# service cups startRedirecting to /bin/systemctl start cups.service


どのあたりをカバーするのか?

● 起動・終了・再起動に必要な処理全般

● デバイスの検出・命名・初期化● fsのmount, autmount, 暗号化block device対応● サービス起動・管理● ロギング● 起動失敗時のレスキュー処理● パスワード確認● システムのlocale, TimeZone, キーボード, 仮想コンソール● 電源管理

● サービス管理で典型的に必要な属性全般の管理

● control groups, namespace, ulimit, 通知, /tmp の掃除● ユーザセッション管理


どのあたりをカバーするのか?

● 起動・終了・再起動に必要な処理全般

● デバイスの検出・命名・初期化 ← udev

● fsのmount, autmount, 暗号化block device対応 ← systemd-fstab-generator, systemd-cryptsetup-generator

● サービス起動・管理 ← systemd本体● ロギング ← journald

● 起動失敗時のレスキュー処理 ← rescue.service

● パスワード確認 ← systemd-ask-password-*

● システムのlocale, TimeZone, キーボード, 仮想コンソール ← localectl, timedatectl, systemd-vconsole-setup

● 電源管理 ← systemd-sleep

● サービス管理で典型的に必要な属性全般の管理

● control groups, namespace, ulimit, 通知, /tmp の掃除 ← systemd本体, systemd-tmpfiles*

● ユーザセッション管理 ← systemd-logind


https://wiki.tizen.org/wiki/File:Systemd_arch.PNG より


サービス管理

● serviceコマンドからsystemctlに

● サービスの定義が宣言的

● 「unit」と呼ばれるオブジェクト群として管理する● /etc/init.d/* の微妙に異なる多数のシェルスクリプトは徐々

になくして行く。RHEL7ではほとんどのサービスが移行済み● 起動の高速化、メンテナンスの省力化、よくある問題の根絶● 設定変更時は systemctl daemon-reload で読み直させる

● 実行するタイミングでファイル内容を反映しないので注意

● systemdがunit間の依存関係や起動順序を計算して決定● 従来は人間が依存関係を考慮して起動・終了の順序を決定

● 起動・終了するだけでなくサービスの状態やログ、関係するプロセスを管理


/etc/init.d/* をどうする?

● (ほとんどの場合)そのままでOK:

● systemdは/etc/init.d以下のスクリプトを自動変換してserviceユニットを作成します

● service コマンドでのサブコマンドを独自拡張している場合は /usr/libexec/initscripts/legacy-actions/(ユニット名)/(サブコマンド名) に対応するスクリプトを配置する

● unitファイルへ移植● 基本的な起動・終了等ができるのは同じ● 起動エラー時の処理、タイムアウト処理、リソース制限

(ulimit)、異常終了時の自動再起動などを宣言的に記載するだけで利用

● 他プロセスと共有しない/tmp, capabilityの制限, localのnetworkにのみ接続できる制限などによるセキュリティ強化も容易


serviceコマンドの独自拡張への対応

● 従来のserviceコマンドで利用できた非標準操作はそのままでは利用できません

● 例: service iptables save

● LSBの規格にはなく、/etc/init.dスクリプトでの独自拡張

● 通常のスクリプト以外に以下のファイルを配置して対応します

● /usr/libexec/initscripts/legacy-actions/iptables/save

● service iptables save → このスクリプトを実行● systemctlから呼びだす方法はありません

● ”systemctl save iptables.service” 等はエラーになります


systemdの注意点

● SysVのサービスと、systemdのunitで定義されるサービスの起動順序が重要な場合

● systemdのサービスは遅延して起動します● 一方/etc/init.d以下のサービスはrunlevel相当のtarget後、順番に

起動● 今までの「番号がXXだからこのサービスは動いているはず」という仮定がなりたたない場合があります

● systemdのunit側で依存関係定義が必要

● サービスについてsystemd用のunit定義ファイルがみつからない場合、sysvinitのスクリプトを <スクリプト名>.service のようなunitとみなします

● Before=<スクリプト名>.service として必要なunitが事前に起動するようにします

● その他、設計上の非互換性について以下にまとまっていますhttp://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/


NetworkManager


「コネクション」

● NetworkManagerでは「コネクション」という概念を導入しています。

● コネクションはネットワーク接続に関する設定のセットで、接続のタイプ（ethernet, bonding, VPNなど）や各種の設定をまとめています。

● コネクションを有効化・無効化することでネットワークへの接続・切断を実施します。

● コネクションは特定のMACアドレスや、特定の名前のインタフェースでのみ利用できるようひもづけることも、ひもづけないで設定することもできます。


NetworkManagerでの管理

● 基本的には「コネクション」の管理を行います● コネクションを作成する (nmcli con add ...)● コネクションを有効化する (nmcli con up ...)● コネクションを更新する (nmcli con edit ...,

nmcli con modify ...)● Linuxのネットワークデバイスに対応する「デバイス」に

ついて現状確認やlink up等ができます● nmcli dev connect ens1

● デバイスから対応するコネクションをみつけて利用● デバイスに対応するコネクションがない場合DHCPでの自動設定を前提として初期化し、対応するコネクションを自動作成


nmcli使用例

● manページ nmcliおよび nmcli-examplesに例が多数あります。パラメータ一覧はnm-settingsに。

● 特定のインタフェースの設定だけでなくDNSサーバやリゾルバの設定も含みます

$ nmcli con add con-name my-con # 名前 ifname ens1 # ひもづけるインタフェース type ethernet # コネクションの種類 ip4 192.168.100.100/24 # IPv4アドレス(ネットワーク) gw4 192.168.100.1 # ゲートウェイ ip4 1.2.3.4 # IPv4アドレス ip4.dns “8.8.8.8” # DNSサーバ ip4.dns-search “example.com” # 検索ドメイン$ nmcli con mod my-con +ipv4.dns "8.8.4.4" # DNSサーバの追加$ nmcli con show my-con


NetworkManagerの各種UI

● CLI: nmcli -- kickstartやスクリプト等で利用● コンソールベース: nmtui -- インストール後対話的に利用● GUI: nm-connection-editor -- anaconda GUI中, インス

トール後のGUI環境で利用


既知の問題

● UEFIへの対応● 一部グラフィックカードで解像度設定ができなくな

る既知の問題あり● BIOSのVideo service(INT 10H)に依存するもの

● インストール後のホスト名の設定● NetworkManagerでのホスト名の変更には既知の問

題があるので、インストーラでの設定かhostnamectlによる設定をおねがいします