Jump to content
  1. このガイドについて
  2. I 共通のタスク
    1. 1 BashとBashスクリプト
    2. 2 sudo
    3. 3 YaSTオンラインアップデート
    4. 4 YaST
    5. 5 テキストモードのYaST
    6. 6 コマンドラインツールによるソフトウェアの管理
    7. 7 Snapperを使用したシステムの回復とスナップショット管理
    8. 8 VNCによるリモートアクセス
    9. 9 rsyncによるファイルのコピー
  3. II Linuxシステムのブート
    1. 10 ブートプロセスの概要
    2. 11 UEFI (Unified Extensible Firmware Interface)
    3. 12 ブートローダGRUB 2
    4. 13 systemdデーモン
  4. III システム
    1. 14 64ビットシステム環境での32ビットと64ビットのアプリケーション
    2. 15 journalctl:systemdジャーナルのクエリ
    3. 16 ネットワークの基礎
    4. 17 プリンタの運用
    5. 18 X Windowシステム
    6. 19 FUSEによるファイルシステムへのアクセス
    7. 20 カーネルモジュールの管理
    8. 21 udevによる動的カーネルデバイス管理
    9. 22 kGraftを使用したLinuxカーネルのライブパッチ適用
    10. 23 特別なシステム機能
  5. IV サービス
    1. 24 NTPによる時刻の同期
    2. 25 ドメインネームシステム
    3. 26 DHCP
    4. 27 NFS共有ファイルシステム
    5. 28 Samba
    6. 29 Autofsによるオンデマンドマウント
    7. 30 SLP
    8. 31 Apache HTTPサーバ
    9. 32 YaSTを使用したFTPサーバの設定
    10. 33 Squidプロキシサーバ
    11. 34 SFCBを使用したWebベースの企業管理
  6. V モバイルコンピュータ
    1. 35 Linuxでのモバイルコンピューティング
    2. 36 NetworkManagerの使用
    3. 37 電源管理
  7. VI トラブルシューティング
    1. 38 ヘルプとドキュメント
    2. 39 サポート用システム情報の収集
    3. 40 最も頻繁に起こる問題およびその解決方法
  8. A マニュアルの更新
  9. B サンプルネットワーク
  10. C GNU利用許諾契約書
SUSE Linux Enterprise Server 12 SP4

管理ガイド

当初のインストールシステムの保守、監視、およびカスタマイズなど、システム管理タスクについて説明します。

発行日: 2018 年 12 月 11 日
このガイドについて
利用可能なマニュアル
フィードバック
マニュアルの表記規則
本マニュアルの作成について
I 共通のタスク
1 BashとBashスクリプト
1.1 シェルとは何か?
1.2 シェルスクリプトの作成
1.3 コマンドイベントのリダイレクト
1.4 エイリアスの使用
1.5 Bashでの変数の使用
1.6 コマンドのグループ化と結合
1.7 よく使用されるフローコンストラクトの操作
1.8 詳細情報
2 sudo
2.1 sudoの基本的な使用方法
2.2 sudoの設定
2.3 一般的な用途
2.4 詳細情報
3 YaSTオンラインアップデート
3.1 オンライン更新ダイアログ
3.2 パッチのインストール
3.3 自動オンラインアップデート
4 YaST
4.1 高度なキーの組み合わせ
5 テキストモードのYaST
5.1 モジュールでのナビゲーション
5.2 高度なキーの組み合わせ
5.3 キーの組み合わせの制約
5.4 YaSTコマンドラインオプション
6 コマンドラインツールによるソフトウェアの管理
6.1 Zypperの使用
6.2 RPM—パッケージマネージャ
7 Snapperを使用したシステムの回復とスナップショット管理
7.1 デフォルト設定
7.2 Snapperを使用した変更の取り消し
7.3 スナップショットからのブートによるシステムロールバック
7.4 Snapper設定の作成と変更
7.5 スナップショットの手動での作成と管理
7.6 スナップショットの自動クリーンアップ
7.7 よくある質問とその回答
8 VNCによるリモートアクセス
8.1 vncviewerクライアント
8.2 Remmina: リモートデスクトップクライアント
8.3 一時的VNCセッション
8.4 永続的VNCセッション
8.5 暗号化されたVNC通信
9 rsyncによるファイルのコピー
9.1 概念の概要
9.2 基本的な構文
9.3 ファイルとディレクトリのローカルでのコピー
9.4 ファイルとディレクトリのリモートでのコピー
9.5 rsyncサーバの設定と使用
9.6 詳細情報
II Linuxシステムのブート
10 ブートプロセスの概要
10.1 用語集
10.2 Linuxのブートプロセス
11 UEFI (Unified Extensible Firmware Interface)
11.1 セキュアブート
11.2 その他の情報
12 ブートローダGRUB 2
12.1 GRUB LegacyとGRUB 2の主な相違点
12.2 設定ファイルの構造
12.3 YaSTによるブートローダの設定
12.4 z Systemsにおける端末の使用上の相違点
12.5 役立つGRUB 2コマンド
12.6 詳細情報
13 systemdデーモン
13.1 systemdの概念
13.2 基本的な使用方法
13.3 システムの起動とターゲットの管理
13.4 YaSTを使用したサービスの管理
13.5 systemdのカスタマイズ
13.6 高度な使用方法
13.7 詳細情報
III システム
14 64ビットシステム環境での32ビットと64ビットのアプリケーション
14.1 ランタイムサポート
14.2 カーネル仕様
15 journalctl:systemdジャーナルのクエリ
15.1 ジャーナルの永続化
15.2 journalctlの便利なスイッチ
15.3 ジャーナル出力のフィルタ
15.4 systemdエラーの調査
15.5 Journaldの設定
15.6 YaSTを使用したsystemdジャーナルのフィルタ
16 ネットワークの基礎
16.1 IPアドレスとルーティング
16.2 IPv6—次世代インターネット
16.3 ネームレゾリューション
16.4 YaSTによるネットワーク接続の設定
16.5 ネットワークの手動環境設定
16.6 ルータの基本セットアップ
16.7 ボンディングデバイスの設定
16.8 ネットワークチーミング用チームデバイスの設定
16.9 Open vSwitchによるソフトウェア定義型ネットワーキング
17 プリンタの運用
17.1 CUPSのワークフロー
17.2 プリンタに接続するための方法とプロトコル
17.3 ソフトウェアのインストール
17.4 ネットワークプリンタ
17.5 コマンドラインツールによるCUPS設定
17.6 コマンドラインからの印刷
17.7 SUSE Linux Enterprise Serverの特別な機能
17.8 トラブルシューティング
18 X Windowシステム
18.1 フォントのインストールと設定
18.2 その他の情報
19 FUSEによるファイルシステムへのアクセス
19.1 FUSEの設定
19.2 NTFSパーティションのマウント
19.3 その他の情報
20 カーネルモジュールの管理
20.1 lsmodおよびmodinfoによるロード済みモジュールの一覧作成
20.2 カーネルモジュールの追加と削除
21 udevによる動的カーネルデバイス管理
21.1 /devディレクトリ
21.2 カーネルのueventudev
21.3 ドライバ、カーネルモジュールおよびデバイス
21.4 ブートおよび初期デバイスセットアップ
21.5 実行中のudevデーモンの監視
21.6 udevルールによるカーネルデバイスイベント処理への影響
21.7 永続的なデバイス名の使用
21.8 udevで使用するファイル
21.9 詳細情報
22 kGraftを使用したLinuxカーネルのライブパッチ適用
22.1 kGraftの利点
22.2 kGraftの機能の詳細
22.3 kGraftパッチのインストール
22.4 パッチのライフサイクル
22.5 kGraftパッチの削除
22.6 カーネル実行スレッドのスタック
22.7 kgrツール
22.8 kGraftテクノロジの範囲
22.9 SLE Live Patchingの範囲
22.10 サポートプロセスとの相互作用
23 特別なシステム機能
23.1 特殊ソフトウェアパッケージ
23.2 バーチャルコンソール
23.3 キーボードマッピング
23.4 言語および国固有の設定
IV サービス
24 NTPによる時刻の同期
24.1 YaSTでのNTPクライアントの設定
24.2 ネットワークでのntpの手動設定
24.3 ランタイム時の動的時刻同期
24.4 ローカルリファレンスクロックの設定
24.5 ETR(External Time Reference)とのクロックの同期
25 ドメインネームシステム
25.1 DNS用語
25.2 インストール
25.3 YaSTでの設定
25.4 BINDネームサーバの起動
25.5 The /etc/named.conf環境設定ファイル
25.6 ゾーンファイル
25.7 ゾーンデータの動的アップデート
25.8 安全なトランザクション
25.9 DNSセキュリティ
25.10 その他の情報
26 DHCP
26.1 YaSTによるDHCPサーバの設定
26.2 DHCPソフトウェアパッケージ
26.3 DHCPサーバdhcpd
26.4 その他の情報
27 NFS共有ファイルシステム
27.1 概要
27.2 NFSサーバのインストール
27.3 NFSサーバの設定
27.4 クライアントの設定
27.5 詳細情報
28 Samba
28.1 用語集
28.2 Sambaサーバのインストール
28.3 Sambaの起動および停止
28.4 Sambaサーバの設定
28.5 クライアントの設定
28.6 ログインサーバとしてのSamba
28.7 Active Directoryネットワーク内のSambaサーバ
28.8 詳細トピック
28.9 その他の情報
29 Autofsによるオンデマンドマウント
29.1 インストール
29.2 環境設定
29.3 操作とデバッグ
29.4 NFS共有の自動マウント
29.5 詳細トピック
30 SLP
30.1 SLPフロントエンドslptool
30.2 SLPによるサービスの提供
30.3 詳細情報
31 Apache HTTPサーバ
31.1 クイックスタート
31.2 Apacheの設定
31.3 Apacheの起動および停止
31.4 モジュールのインストール、有効化、および設定
31.5 CGIスクリプトの有効化
31.6 SSLをサポートするセキュアWebサーバのセットアップ
31.7 複数のApacheインスタンスを同じサーバで実行
31.8 セキュリティ問題の回避
31.9 トラブルシューティング
31.10 詳細情報
32 YaSTを使用したFTPサーバの設定
32.1 FTPサーバの起動
32.2 FTP一般設定
32.3 FTPパフォーマンス設定
32.4 認証
32.5 エキスパート設定
32.6 さらに詳細な説明が必要な場合は
33 Squidプロキシサーバ
33.1 プロキシキャッシュに関する注意事項
33.2 システム要件
33.3 Squidの基本的な使用法
33.4 YaST Squidモジュール
33.5 Squid環境設定ファイル
33.6 透過型プロキシの設定
33.7 SquidキャッシュマネージャのCGIインタフェース(cachemgr.cgi)
33.8 squidGuard
33.9 Calamarisを使用したキャッシュレポート生成
33.10 詳細情報
34 SFCBを使用したWebベースの企業管理
34.1 概要および基本概念
34.2 SFCBの設定
34.3 SFCB CIMOM設定
34.4 高度なSFCBタスク
34.5 詳細情報
V モバイルコンピュータ
35 Linuxでのモバイルコンピューティング
35.1 ラップトップ
35.2 モバイルハードウェア
35.3 携帯電話とPDA
35.4 詳細情報
36 NetworkManagerの使用
36.1 NetworkManagerの使用
36.2 NetworkManagerの有効化/無効化
36.3 ネットワーク接続の設定
36.4 NetworkManagerとセキュリティ
36.5 FAQ (よくある質問と答え)
36.6 トラブルシューティング
36.7 その他の情報
37 電源管理
37.1 省電力機能
37.2 ACIP(詳細設定と電源インタフェース)
37.3 ハードディスクの休止
37.4 トラブルシューティング
37.5 その他の情報
VI トラブルシューティング
38 ヘルプとドキュメント
38.1 ドキュメントディレクトリ
38.2 manページ
38.3 情報ページ
38.4 リソースのオンライン化
39 サポート用システム情報の収集
39.1 現在のシステム情報の表示
39.2 Supportconfigによるシステム情報の収集
39.3 グローバルテクニカルサポートへの情報の送信
39.4 システム情報の分析
39.5 インストール時の情報収集
39.6 カーネルモジュールのサポート
39.7 その他の情報
40 最も頻繁に起こる問題およびその解決方法
40.1 情報の検索と収集
40.2 インストールの問題
40.3 ブートの問題
40.4 Loginの問題
40.5 ネットワークの問題
40.6 データの問題
40.7 IBM z Systems: initrdのレスキューシステムとしての使用
A マニュアルの更新
A.1 2018年9月(SUSE Linux Enterprise Server 12 SP3のマニュアルのメンテナンスリリース)
A.2 2018年6月(SUSE Linux Enterprise Server 12 SP3のマニュアルのメンテナンスリリース)
A.3 2017年12月(SUSE Linux Enterprise Server 12 SP3のメンテナンスリリース)
A.4 2017年9月(SUSE Linux Enterprise Server 12 SP3の初期リリース)
A.5 2016年11月(SUSE Linux Enterprise Server 12 SP2の初期リリース)
A.6 2016年3月(SUSE Linux Enterprise Server 12 SP1のメンテナンスリリース)
A.7 2015年12月 (SUSE Linux Enterprise Server 12 SP1の初期リリース)
A.8 2015年2月(マニュアル保守更新)
A.9 2014年10月(SUSE Linux Enterprise Server 12の初期リリース)
B サンプルネットワーク
C GNU利用許諾契約書
C.1 GNU Free Documentation License
図の一覧
3.1 YaSTオンラインアップデート
5.1 テキストモードのYaSTのメインウィンドウ
5.2 ソフトウェアインストールモジュール
7.1 ブートローダ: スナップショット
8.1 vncviewer
8.2 Remminaのメインウィンドウ
8.3 リモートデスクトップ初期設定
8.4 クイックスタート
8.5 RemminaのSLES 15リモートセッションの表示
8.6 プロファイルファイルへのパスの読み込み
8.7 リモート管理
8.8 VNCセッション設定
8.9 永続的VNCセッションへの参加
11.1 セキュアブートサポート
11.2 UEFIのセキュアブートプロセス
12.1 GRUB 2ブートエディタ
12.2 ブートコードオプション
12.3 コードオプション
12.4 ブートローダのオプション:
12.5 カーネルパラメータ
13.1 サービスマネージャ
15.1 YaST systemdジャーナル
16.1 TCP/IPの簡易階層モデル
16.2 TCP/IPイーサネットパケット
16.3 ネットワーク設定の実行
16.4 wickedアーキテクチャ
24.1 YaST: NTPサーバ
24.2 高度なNTP設定:セキュリティの設定
25.1 DNSサーバのインストール:フォワーダの設定
25.2 DNSサーバのインストール:DNSゾーン
25.3 DNSサーバのインストール:完了ウィザード
25.4 DNSサーバ:ログの記録
25.5 DNSサーバ: ゾーンエディタ(基本)
25.6 DNSサーバ:ゾーンエディタ(NSレコード)
25.7 DNSサーバ:ゾーンエディタ(MXレコード)
25.8 DNSサーバ:ゾーンエディタ(SOA)
25.9 マスタゾーンのレコードを追加
25.10 逆引きゾーンの追加
25.11 逆引きレコードの追加
26.1 DHCPサーバ:カードの選択
26.2 DHCPサーバ:グローバル設定
26.3 DHCPサーバ:ダイナミックDHCP
26.4 DHCPサーバ:起動
26.5 DHCPサーバ:ホスト管理
26.6 DHCPサーバ:Chroot Jailと宣言
26.7 DHCPサーバ:宣言タイプの選択
26.8 DHCPサーバ:サブネットの設定
26.9 DHCPサーバ:TSIGの設定
26.10 DHCPサーバ:ダイナミックDNS用のインタフェースの設定
26.11 DHCPサーバ:ネットワークインタフェースとファイアウォール
27.1 NFSサーバ設定ツール
28.1 Windowsドメインメンバーシップの決定
28.2 Windowsエクスプローラの属性の詳細ダイアログ
28.3 Windowsエクスプローラでの圧縮ファイルのディレクトリリスト
28.4 スナップショットが有効な新しいSamba共有の追加
28.5 Windowsエクスプローラの以前のバージョンタブ
31.1 HTTP Server Wizard:デフォルトホスト
31.2 HTTP Server Wizard:概要
31.3 HTTP Server Configuration:設定:リッスンポートとアドレス
31.4 HTTP Server Configuration:サーバモジュール
32.1 FTPサーバの設定 - 起動
34.1 Webベースの企業管理パターンのパッケージ選択
34.2 追加CIMプロバイダのパッケージ選択
35.1 既存環境でのモバイルコンピュータの統合
36.1 GNOMEネットワーク接続のダイアログ
39.1 SCAツールによって生成されるHTMLレポート
39.2 SCAアプライアンスによって生成されるHTMLレポート
40.1 メディアの確認
40.2 USキーボードレイアウト
例の一覧
1.1 テキストをプリントするシェルスクリプト
6.1 Zypper—既知のリポジトリのリスト
6.2 rpm -q -i wget
6.3 パッケージを検索するスクリプト
7.1 タイムライン設定の例
12.1 grub2-mkconfigの使用法
12.2 grub2-mkrescueの使用法
12.3 grub2-script-checkの使用
12.4 grub2-onceの使用法
13.1 アクティブなサービスの一覧表示
13.2 起動に失敗したサービスの一覧表示
13.3 サービスに属するすべてのプロセスの表示
16.1 IPアドレスの表記
16.2 IPアドレスとネットマスクの論理積(AND)
16.3 IPv6アドレスの例
16.4 プレフィクスの長さを指定したIPv6アドレス
16.5 一般的なネットワークインタフェースとスタティックルートの例
16.6 /etc/resolv.conf
16.7 /etc/hosts
16.8 /etc/networks
16.9 /etc/host.conf
16.10 /etc/nsswitch.conf
16.11 pingコマンドの出力
16.12 ネットワークチーミングによる負荷分散の設定
16.13 DHCPネットワークチーミングデバイスの設定
17.1 lpdからのエラーメッセージ
17.2 CUPSネットワークサーバからのブロードキャスト
18.1 レンダリングアルゴリズムを指定する
18.2 エイリアスとファミリ名の置換
18.3 エイリアスとファミリ名の置換
18.4 エイリアスとファミリ名の置換
21.1 udevルールの例
23.1 /etc/crontab内のエントリ
23.2 /etc/crontab:タイムスタンプファイルの削除
23.3 ulimit:~/.bashrc中の設定
25.1 named.confファイルの転送オプション
25.2 基本的な/etc/named.confファイル
25.3 ログを無効にするエントリ
25.4 example.comのゾーンエントリ
25.5 example.netのゾーンエントリ
25.6 /var/lib/named/example.com.zoneファイル
25.7 逆引き
26.1 環境設定ファイル/etc/dhcpd.conf
26.2 環境設定ファイルへの追加
28.1 CD-ROMの共有
28.2 [homes]共有
28.3 smb.confファイルのグローバルセクション
28.4 rpcclientを使用したWindows Server 2012共有スナップショットの要求
31.1 名前ベースのVirtualHostエントリの基本例
31.2 名前ベースのVirtualHostディレクティブ
31.3 IPベースのVirtualHostディレクティブ
31.4 基本的な仮想ホスト設定
31.5 VirtualHost CGIの設定
33.1 squidclientによる要求
33.2 ACLルールの定義
39.1 rootとしてログインしたときのhostinfoの出力

Copyright © 2006– 2018 SUSE LLC and contributors. All rights reserved.

この文書は、GNUフリー文書ライセンスのバージョン1.2または(オプションとして)バージョン1.3の条項に従って、複製、頒布、および/または改変が許可されています。ただし、この著作権表示およびライセンスは変更せずに記載すること。ライセンスバージョン1.2のコピーは、GNUフリー文書ライセンスセクションに含まれています。

SUSEの商標については、http://www.suse.com/company/legal/を参照してください。その他の製品名および会社名は、各社の商標または登録商標です。商標記号(®、™など)は、SUSEおよび関連会社の商標を示します。アスタリスク(*)は、第三者の商標を示します。

本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対に正確であることを保証するものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。

このガイドについて

このガイドは、SUSE® Linux Enterpriseの操作時にプロフェッショナルなネットワーク/システム管理者によって使用されることを目的としています。ここでは、SUSE Linux Enterpriseが、ネットワークで必要とされるサービスが使用可能になるように正しく設定され、最初にインストールしたとおりに適切に機能させることができるようになることを目的にしています。このガイドでは、SUSE Linux Enterpriseとお使いのアプリケーションソフトウェアに互換性があるかどうか、また、ない場合の対処方法、および主要機能がアプリケーションの要件に適合しているかどうかなどの分野については取り上げていません。要件の監査がすべて実施済みであり、かつインストールが要求されていること、またはこのような監査に備えてテストインストールが要求されていることを前提に、詳細を説明していきます。

このガイドでは、次の内容が取り上げられています。

サポートと共通タスク

SUSE Linux Enterpriseには、システムのさまざまな側面をカスタマイズするための幅広いツールが用意されています。この部分では、これらのツールの一部を紹介しています。利用できるさまざまなデバイス技術、可用性の高い構成、および高度な管理機能など、管理者にとって役立つさまざまな機能を紹介します。

システム

このパートを参照して、OSの詳細を学習してください。SUSE Linux Enterpriseは多数のハードウェアアーキテクチャをサポートしているので、この特長を利用すると、独自のアプリケーションをSUSE Linux Enterpriseでの実行に適応させることができます。また、Linuxシステムの仕組みを理解し、独自のカスタムスクリプトやアプリケーションに応用するために役立つ、ブートローダや、ブート手順についても説明しています。

サービス

SUSE Linux Enterpriseは、ネットワークオペレーティングシステムとして設計されています。DNS、DHCP、Web、プロキシ、認証サービスなどの幅広いネットワークサービスを提供します。MS Windowsクライアントおよびサーバなどの異種システム環境にもうまく統合します。

モバイルコンピュータ

ラップトップおよびモバイルデバイス(PDA、携帯電話など)/SUSE Linux Enterprise間の通信には、特別な配慮が必要です。電力の節約、および変化するネットワーク環境への各種デバイスの統合に留意してください。また、必要な機能を提供する背景技術を知ることも大事です。

トラブルシューティング

詳細情報が必要な場合や特定のタスクを実行する場合の、ヘルプおよび追加ドキュメントの検索の概要を示します。また、最も頻繁に発生する問題のリストと、それらを修正する方法の説明もあります。

1 利用可能なマニュアル

注記
注記: オンラインヘルプと最新のアップデート

製品に関するマニュアルは、http://www.suse.com/documentation/からご利用いただけます。最新のアップデートもご利用いただけるほか、マニュアルをさまざまな形式でブラウズおよびダウンロードすることができます。

また、製品マニュアルは通常、/usr/share/doc/manualの下にあるインストール済みシステムから入手できます。

この製品の次のマニュアルを入手できます。

Article “インストールクイックスタート

システム要件を一覧にし、DVDまたはISOイメージからのSUSE Linux Enterprise Serverのインストールをステップごとに順を追って説明します。

Book “導入ガイド

単一または複数のシステムをインストールする方法および展開インフラストラクチャに製品本来の機能を活用する方法を示します。ローカルインストールまたはネットワークインストールサーバの使用から、リモート制御の高度にカスタマイズされた自動リモートインストール技術による大規模展開まで、多様なアプローチから選択できます。

管理ガイド

当初のインストールシステムの保守、監視、およびカスタマイズなど、システム管理タスクについて説明します。

Book “Virtualization Guide

仮想化技術全般について説明し、仮想化統合インタフェースであるlibvirt、および特定のハイパーバイザの詳細情報を紹介します。

Book “ストレージ管理ガイド

SUSE Linux Enterprise Serverサーバでストレージデバイスを管理する方法を説明します。

Book “AutoYaST”

AutoYaSTは、インストールおよび設定データを含むAutoYaSTプロファイルを使用した、無人大規模展開SUSE Linux Enterprise Serverシステム用のシステムです。マニュアルに従って、自動インストールの基本的な手順(準備、インストール、および設定)を実行できます。

Book “Security Guide

システムセキュリティの基本概念を紹介し、ローカルセキュリティ/ネットワークセキュリティの両方の側面を説明します。AppArmorなど製品に付属するセキュリティソフトウェアや、セキュリティ関連イベントの情報を確実に収集する監査システムの使用方法を説明します。

Book “Security and Hardening Guide”

セキュアなSUSE Linux Enterprise Server、およびそのインストールのセキュリティを保護し強化するために必要なその他のポストインストールプロセスのインストールおよび設定について詳しく説明します。セキュリティ関連の選択や決定を行う管理者をサポートします。

Book “System Analysis and Tuning Guide

問題の検出、解決、および最適化に関する管理者ガイド。ツールの監視によってシステムを検査および最適化する方法およびリソースを効率的に管理する方法を見つけることができます。よくある問題と解決、および追加のヘルプとドキュメントリソースの概要も含まれています。

Book “Subscription Management Tool for SLES 12 SP4

登録管理ツール(SUSEカスタマーセンターの代理システムで、リポジトリと登録ターゲットが含まれる)の管理者ガイド。ローカルSMTサーバのインストールと設定、リポジトリのミラーリングと管理、クライアントマシンの管理を行う方法、およびSMTを使用するようにクライアントを設定する方法について説明します。

Book “GNOMEユーザガイド

SUSE Linux Enterprise ServerのGNOMEデスクトップについて紹介します。デスクトップの使用および設定方法と、キータスクの実行方法を説明します。主として、デフォルトのデスクトップとしてGNOMEを効率的に使用したいと考えるエンドユーザ向けです。

2 フィードバック

次のフィードバックチャネルがあります。

バグと機能拡張の要求

ご使用の製品に利用できるサービスとサポートのオプションについては、http://www.suse.com/support/を参照してください。

openSUSEのヘルプはコミュニティによって提供されています。詳細については、https://en.opensuse.org/Portal:Supportを参照してください。

製品コンポーネントのバグを報告するには、https://scc.suse.com/support/requestsにアクセスしてログインし、Create New (新規作成)をクリックします。

ユーザからのコメント

本マニュアルおよびこの製品に含まれているその他のマニュアルについて、皆様のご意見やご要望をお寄せください。オンラインドキュメントの各ページの下にあるユーザコメント機能を使用するか、またはhttp://www.suse.com/documentation/feedback.htmlにアクセスして、コメントを入力してください。

メール

この製品のドキュメントについてのフィードバックは、doc-team@suse.com宛のメールでも送信できます。ドキュメントのタイトル、製品のバージョン、およびドキュメントの発行日を明記してください。エラーの報告または機能拡張の提案では、問題について簡潔に説明し、対応するセクション番号とページ(またはURL)をお知らせください。

3 マニュアルの表記規則

このマニュアルでは、次の通知と表記規則が使用されています。

  • /etc/passwd:ディレクトリ名とファイル名

  • PLACEHOLDER:PLACEHOLDERは、実際の値で置き換えられます

  • PATH:環境変数PATH

  • ls--help:コマンド、オプション、およびパラメータ

  • user:ユーザまたはグループ

  • package name:パッケージの名前

  • Alt, AltF1:使用するキーまたはキーの組み合わせ、キーはキーボード上と同様、大文字で表示される

  • ファイルファイル › 名前を付けて保存: メニュー項目、ボタン

  • x86_64 この説明は、AMD64/Intel 64アーキテクチャにのみ当てはまります。矢印は、テキストブロックの先頭と終わりを示します。

    System z, POWER この説明は、z SystemsおよびPOWERの各アーキテクチャにのみ当てはまります。矢印は、テキストブロックの先頭と終わりを示します。

  • Dancing Penguins (「Penguins」の章、↑他のマニュアル):他のマニュアルの章への参照です。

  • root特権で実行する必要のあるコマンド。多くの場合、これらのコマンドの先頭にsudoコマンドを置いて、特権のないユーザとしてコマンドを実行することもできます。

    root # command
    tux > sudo command
  • 特権のないユーザでも実行できるコマンド。

    tux > command
  • 通知

    警告
    警告: 警告の通知

    続行する前に知っておくべき、無視できない情報。セキュリティ上の問題、データ損失の可能性、ハードウェアの損傷、または物理的な危険について警告します。

    重要
    重要: 重要な通知

    続行する前に知っておくべき重要な情報。

    注記
    注記: メモの通知

    追加情報。たとえば、ソフトウェアバージョンの違いに関する情報です。

    ヒント
    ヒント: ヒントの通知

    ガイドラインや実際的なアドバイスなどの役に立つ情報。

4 本マニュアルの作成について

このマニュアルは、DocBook 5のサブセットであるSUSEDocで作成されています。XMLソースファイルはjing(https://code.google.com/p/jing-trang/を参照)によって検証され、xsltprocによって処理され、Norman Walshによるスタイルシートのカスタマイズ版を使用してXSL-FOに変換されました。最終的なPDFは、Apache Software FoundationのFOPを使用して書式設定されています。このマニュアルの作成に使用したオープンソースツールと環境は、DocBook Authoring and Publishing Suite (DAPS)によって提供されたものです。プロジェクトのホームページはhttps://github.com/openSUSE/dapsにあります。

このマニュアルのXMLソースコードについては、https://github.com/SUSE/doc-sleを参照してください。

パート I 共通のタスク

1 BashとBashスクリプト

今日、多数のユーザが、GNOMEなどのGUI(グラフィカルユーザインターフェース)を介してコンピュータを使用しています。GUIは多くの機能を備えていますが、自動タスクの実行という点では、その用途は限られます。シェルは、GUIに追加すると便利なツールです。この章では、シェル(ここではBash)のいくつかの側面について概説します。

2 sudo

ファイルの変更やスーパユーザのみが許可されているタスクを実行するために、多くのコマンドとシステムユーティリティは、rootとして実行する必要があります。セキュリティ上の理由のため、および危険なコマンドが偶発的に実行されるのを回避するため、通常はrootとして直接ログインしないことをお勧めします。代わりに、通常の特権のないユーザとして、sudoコマンドを使用し、昇格された特権付きでコマンドを実行することをお勧めします。

3 YaSTオンラインアップデート

SUSEはお買い上げの製品に対し、継続的にソフトウェアセキュリティのアップデートを提供します。デフォルトでは、システムを最新の状態に維持するために更新アプレットが使用されます。アップデートアプレットの詳細については、Book “導入ガイド”, Chapter 13 “ソフトウェアをインストールまたは削除する”, Section 13.5 “システムのアップデート”を参照してください。この章では、ソフトウェアパッケージをアップデートする代替ツールとして、YaSTオンラインアップデートを紹介します。

4 YaST

YaSTは、SUSE Linux Enterprise Server用のインストールおよび設定ツールです。グラフィカルインタフェースを備えており、インストール中でもインストール後でもシステムをすばやくカスタマイズできます。YaSTを使用して、ハードウェアのセットアップ、ネットワークやシステムサービスの設定、セキュリティ設定を行うことができます。

5 テキストモードのYaST

このセクションは、システムでXサーバを実行せずに、テキストベースのインストールツールを使用しているシステム管理者や専門家の方を対象にしています。ここでは、YaSTをテキストモードで起動して操作するための基本的な情報を説明しています。

6 コマンドラインツールによるソフトウェアの管理

この章では、ソフトウェア管理の2つのコマンドラインツールとして、ZypperとRPMについて説明します。このコンテキストで使用される述語(たとえば、repositorypatchupdateなど)の定義については、Book “導入ガイド”, Chapter 13 “ソフトウェアをインストールまたは削除する”, Section 13.1 “用語の定義”を参照してください。

7 Snapperを使用したシステムの回復とスナップショット管理

Linuxでファイルシステムのスナップショットを作成し、ロールバックできるようにすることは、過去に要望の多かった機能です。Snapperを、BtrfsファイルシステムまたはシンプロビジョンのLVMボリュームと併用することによって、それに対応できます。

Btrfsは、Linux用の新しい書き込み時コピー方式のファイルシステムで、サブボリューム(各物理パーティション内の1つまたは複数の個別にマウント可能なファイルシステム)のファイルシステムスナップショット(特定時点におけるサブボリュームの状態のコピー)をサポートします。スナップショットは、XFS、Ext4、またはExt3でフォーマットされたシンプロビジョンLVMボリュームでもサポートされています。Snapperを使用してこれらのスナップショットを作成および管理できます。Snapperには、コマンドラインおよびYaSTインタフェースがあります。SUSE Linux Enterprise Serverバージョン 12から、Btrfsスナップショットからブートすることもできるようになりました。詳細については、7.3項 「スナップショットからのブートによるシステムロールバック」を参照してください。

8 VNCによるリモートアクセス

VNC (Virtual Network Computing)では、グラフィカルなデスクトップを使用してリモートコンピュータを制御できます。これは、リモートシェルアクセスとは対照的です。VNCはプラットフォームに依存しないので、VNCを使用すれば、任意のオペレーティングシステムからリモートマシンにアクセスできます。

SUSE Linux Enterprise Serverでは、2種類のVNCセッションをサポートしています。1つはクライアントからのVNC接続が続く限り、存続する一時的セッションで、もう1つは明示的に終了されるまで存続する永続的セッションです。

9 rsyncによるファイルのコピー

現在の通常のユーザは、複数のコンピュータ(家庭用および職場用のマシン、ラップトップ、スマートフォン、またはタブレット)を持っています。このため、複数のデバイス間でファイルとドキュメントを同期させることがますます重要になっています。

1 BashとBashスクリプト

概要

今日、多数のユーザが、GNOMEなどのGUI(グラフィカルユーザインターフェース)を介してコンピュータを使用しています。GUIは多くの機能を備えていますが、自動タスクの実行という点では、その用途は限られます。シェルは、GUIに追加すると便利なツールです。この章では、シェル(ここではBash)のいくつかの側面について概説します。

1.1 シェルとは何か?

従来、シェルとは、Bash(Bourne again Shell)のことでした。この章では、Bashをシェルと呼びます。実際にはシェルはBashの他にもあり(ash、csh、ksh、zshなど)、異なる機能と特性を持っています。他のシェルの詳細については、YaSTで「シェル」を検索してください。

1.1.1 Bash設定ファイルの知識

シェルは、次のようにして呼び出すことができます。

  1. 対話型ログインシェル:  コンピュータへのログイン時に、--loginオプションを使用してBashを呼び出す場合か、SSHを使用してリモートコンピュータへログインする場合に使用します。

  2. 通常の対話型シェル:  xtermやkonsole、gnome-terminalなどのツールの起動時には、通常、この形式を使用します。

  3. 非対話型シェル:  コマンドラインからシェルスクリプトを呼び出す場合に使用します。

使用するシェルのタイプによって、異なる設定ファイルを読み込みます。次のテーブルには、それぞれ、ログインシェル設定ファイルと非ログインシェル設定ファイルが示されています。

表 1.1: ログインシェル用Bash設定ファイル

ファイル

説明

/etc/profile

このファイルは変更しないでください。変更しても、次の更新で変更内容が破棄される可能性があります。

/etc/profile.local

/etc/profileを拡張する場合は、このファイルを使用します。

/etc/profile.d/

特定プログラムのシステム全体にわたる設定ファイルを含みます。

~/.profile

ログインシェル用のユーザ固有の設定をここに挿入します。

ログインシェルは、表1.2「非ログインシェル用Bash設定ファイル」に示す設定ファイルも参照することに注意してください。

表 1.2: 非ログインシェル用Bash設定ファイル

/etc/bash.bashrc

このファイルは変更しないでください。変更しても、次の更新で変更内容が破棄される可能性があります。

/etc/bash.bashrc.local

Bashのシステム全体にわたる変更を挿入する場合のみ、このファイルを使用します。

~/.bashrc

ユーザ固有の設定をここに挿入します。

さらに、Bashでは、次のファイルも使用します。

表 1.3: Bash用特殊ファイル

ファイル

説明

~/.bash_history

入力したすべてのコマンドのリストを含みます。

~/.bash_logout

ログアウト時に実行されます。

~/.alias

よく使用されるコマンドのユーザ定義エイリアス。エイリアスを定義する方法の詳細については、man 1 aliasを参照してください。

1.1.2 ディレクトリの構造

次のテーブルでは、Linuxシステムの最も重要な上位レベルディレクトリについて、短い概要を示します。それらのディレクトリおよび重要なサブディレクトリの詳細については、後続のリストを参照してください。

表 1.4: 標準的なディレクトリツリーの概要

ディレクトリ

目次

/

ルートディレクトリ(ディレクトリツリーの開始場所)。

/bin

システム管理者および通常ユーザの両者が必要とするコマンドなどの必須バイナリファイル。通常、Bashなどのシェルも含みます。

/boot

ブートローダの静的ファイル

/dev

ホスト固有のデバイスのアクセスに必要なファイル

/etc

ホスト固有のシステム設定ファイル

/home

システムにアカウントを持つすべてのユーザのホームディレクトリを格納します。ただし、rootのホームディレクトリは、/homeでなく、/rootにあります。

/lib

必須の共有ライブラリおよびカーネルモジュール

/media

リムーバブルメディアのマウントポイント

/mnt

ファイルシステムを一時的にマウントするためのマウントポイント

/opt

アドオンアプリケーションのソフトウェアパッケージ

/root

スーパーユーザrootのホームディレクトリ。

/sbin

必須のシステムバイナリ

/srv

システムで提供するサービスのデータ

/tmp

一時ファイルを格納するディレクトリ

/usr

読み込み専用データを含む第二階層

/var

ログファイルなどの可変データ

/ウィンドウ

システムにMicrosoft Windows*とLinuxの両方がインストールされる場合のみ利用可能。Windowsデータを含みます。

次のリストでは、さらに詳しい情報を提供し、ディレクトリに含まれるファイルおよびサブディレクトリの例を示します。

/bin

rootと他のユーザの両者が使用できる基本的なシェルコマンドを含みます。これらのコマンドは、lsmkdircpmvrmrmdirなどです。また、/binには、SUSE Linux Enterprise ServerのデフォルトシェルであるBashも含まれます。

/boot

ブートに必要なデータ(ブートローダやカーネルのデータなど)と、その他のデータ(カーネルがユーザモードプログラムの実行を開始する前に使用)が含まれます。

/dev

ハードウェアコンポーネントを記述したデバイスファイルを格納します。

/etc

X Window Systemなどのプログラムの動作を制御するローカル設定ファイルを含みます。/etc/init.dサブディレクトリは、ブートプロセスで実行できるLSB initスクリプトを含みます。

/home/USERNAME

システムにアカウントを持つすべてのユーザの個人データを格納します。このディレクトリ内のファイルは、その所有者またはシステム管理者しか変更できません。デフォルトでは、電子メールのディレクトリとパーソナルデスクトップの設定が、.gconf/.configなどの非表示のファイルおよびディレクトリとして、ここに格納されます。

注記
注記: ネットワーク環境でのホームディレクトリ

ネットワーク環境で作業するユーザのホームディレクトリは、/home以外のファイルシステム内のディレクトリにマップできます。

/lib

システムのブートとルートファイルシステムでのコマンドの実行に必要な必須共有ライブラリを含みます。Windowsで共有ライブラリに相当するものは、DLLファイルです。

/media

CD-ROM、フラッシュディスク、デジタルカメラ(USBを使用する場合)など、リムーバブルメディアのマウントポイントを含みます。/mediaでは、一般にシステムのハードディスク以外のあらゆるタイプのドライブが保持されます。リムーバブルメディアをシステムに挿入または接続し、マウントを完了すると、そのメディアにこのディレクトリからアクセスできます。

/mnt

このディレクトリは一時的にマウントされるファイルシステムのマウントポイントを提供します。rootはここにファイルシステムをマウントできます。

/opt

サードパーティのソフトウェアのインストール用に予約されています。オプションソフトウェアや大型アドオンプログラムのパッケージをここに格納できます。

/root

rootユーザのホームディレクトリ。rootの個人データがここに保存されます。

/run

systemdとさまざまなコンポーネントによって使用されるtmpfsディレクトリ。/var/runは、/runへのシンボリックリンクです。

/sbin

sで示唆されるように、このディレクトリはスーパーユーザ用のユーティリティを格納します。/sbinには、/bin内のバイナリとともにシステムのブート、復元、および回復に不可欠なバイナリを含みます。

/srv

FTPやHTTPなど、システムによって提供されるサービスのデータを格納します。

/tmp

ファイルの一時的保管を必要とするプログラムによって使用されます。

重要
重要: ブート時の/tmpのクリーンアップ

/tmpに保存したデータは、システムのリブート後も残っているかは保証できません。データが残っているかどうかは、たとえば/etc/tmpfiles.d/tmp.confの設定によって異なります。

/usr

/usrは、ユーザとは無関係であり、UNIX system resourcesを意味する略語です。/usr内のデータは静的な読み込み専用データです。このデータは、FHS (Filesystem Hierarchy Standard)に準拠するホスト間で共有できます。このディレクトリは、GNOMEなどのグラフィカルデスクトップをはじめ、すべてのアプリケーションプログラムを含み、ファイルシステム内の第二階層を形成します。/usrには、/usr/bin/usr/sbin/usr/local/usr/share/docなど、多数のサブディレクトリがあります。

/usr/bin

一般ユーザがアクセスできるプログラムを含みます。

/usr/sbin

修復関数など、システム管理者用に予約されたプログラムを含みます。

/usr/local

このディレクトリには、システム管理者がディストリビューションに依存しないローカルな拡張プログラムをインストールできます。

/usr/share/doc

システムのドキュメントファイルおよびリリースノートを格納します。manualサブディレクトリには、このマニュアルのオンラインバージョンが格納されます。複数の言語をインストールする場合は、このディレクトリに各言語のマニュアルを格納できます。

packagesには、システムにインストールされたソフトウェアパッケージに含まれているドキュメントが格納されます。パッケージごとに、サブディレクトリ/usr/share/doc/packages/PACKAGENAMEが作成されます。このサブディレクトリには、多くの場合、パッケージのREADMEファイルが含まれます。例、設定ファイル、または追加スクリプトが含まれる場合もあります。

HOWTOをシステムにインストールした場合は、/usr/share/dochowtoサブディレクトリも含まれます。このサブディレクトリには、Linuxソフトウェアの設定および操作に関する多数のタスクの追加ドキュメントが格納されます。

/var

/usrは静的な読み込み専用データを含みますが、/varは、システム動作時に書き込まれる可変データ(ログファイル、スプールデータなど)のディレクトリです。/var/log/にある重要なログファイルの概要は、表40.1「ログファイル」を参照してください。

1.2 シェルスクリプトの作成

シェルスクリプトは、データの収集、テキスト内のワードやフレーズの検索など、さまざまな有用なタスクの実行に便利な方法です。次の例では、小型のシェルスクリプトでテキストをプリントします。

例 1.1: テキストをプリントするシェルスクリプト
#!/bin/sh 1
# Output the following line: 2
echo "Hello World" 3

1

1行目は、このファイルがスクリプトであることを示すShebang 文字(#!)で始まります。スクリプトは、Shebang文字の後に指定されたインタープリタ(ここでは、/bin/sh)を使用して実行されます。

2

2行目は、ハッシュ記号で始まるコメントです。スクリプトの動作を覚えにくい行には、コメントすることをお勧めします。

3

3番目の行で、組み込みコマンドechoを使用して、対応するテキストを出力します。

このスクリプトの実行には、次の前提条件が必要です。

  1. すべてのスクリプトには(上記の例のように) Shebang行が含まれている必要があります。この行がない場合は、インタプリタを手動で呼び出す必要があります。

  2. スクリプトの保存場所はどこでも構いません。ただし、シェルの検索先ディレクトリを保存場所にすることをお勧めします。シェルのサーチパスは、環境変数PATHで設定されます。一般に、標準ユーザには/usr/binへの書き込みアクセスはありません。このため、スクリプトはユーザのディレクトリ~/bin/に保存することを推奨します。上記の例では、名前はhello.shです。

  3. スクリプトには、実行可能パーミッションが必要です。次のコマンドで、パーミッションを設定してください。

    chmod +x ~/bin/hello.sh

これらの前提条件をすべて満たしたら、次の方法でスクリプトを実行できます。

  1. 絶対パス:  スクリプトは絶対パスで実行できます。この例では、~/bin/hello.shです。

  2. 任意の場所:  PATH環境変数にスクリプトが存在するディレクトリが含まれている場合、スクリプトをhello.shで実行できます。

1.3 コマンドイベントのリダイレクト

各コマンドは、入力または出力用として、3つのチャネルを使用できます。:

  • 標準出力:  デフォルトの出力チャネル。コマンドで何かをプリントする際には標準出力チャネルが使用されます。

  • 標準入力:  コマンドでユーザまたは他のコマンドからの入力を必要とする場合は、このチャネルが使用されます。

  • 標準エラー:  このチャネルは、エラーレポーティングに使用されます。

これらのチャネルをリダイレクトするには、次の方法を使用できます。

Command > File

コマンド出力をファイルに保存します。既存ファイルは削除されます。たとえば、lsコマンドの出力をlisting.txtファイルに書き込みます。

ls > listing.txt
Command >> File

コマンド出力をファイルに追加します。たとえば、lsコマンドの出力をlisting.txtファイルに追加します。

ls >> listing.txt
Command < File

ファイルを読み込み、指定されたコマンドへの入力とします。たとえば、ファイルのコンテンツをreadコマンドで読み込み、変数に入力します。

read a < foo
Command1 | Command2

左側のコマンドの出力を右側のコマンドの入力にします。たとえば、catコマンドは/proc/cpuinfoファイルの内容を出力します。この出力をgrepで使用して、cpuを含む行のみをフィルタします。

cat /proc/cpuinfo | grep cpu

各チャネルには、対応するファイル記述子があります。標準入力には0(ゼロ)、標準出力には1、標準エラーには2が割り当てられています。このファイル記述子を<文字または>文字の前に挿入できます。たとえば、次の行では、fooで始まるファイルを検索しますが、そのファイルを/dev/nullにリダイレクトすることでエラーメッセージを抑制します。

find / -name "foo*" 2>/dev/null

1.4 エイリアスの使用

エイリアスは、1つ以上のコマンドのショートカット定義です。エイリアスの構文は、次のとおりです。

alias NAME=DEFINITION

たとえば、次の行は、エイリアスltを定義しています。このエイリアスは、長いリストを出力し(-lオプション)、そのリストを変更時刻でソートし(-tオプション)、ソート順と逆の順序でプリントします(-rオプション)。

alias lt='ls -ltr'

すべてのエイリアス定義を表示するには、aliasを使用します。unaliasで対応するエイリアス名を指定して、エイリアスを削除します。

1.5 Bashでの変数の使用

シェル変数は、グローバル変数またはローカル変数として使用できます。グローバル変数(つまり、環境変数)は、すべてのシェルでアクセスできます。対照的に、ローカル変数は、現在のシェルでのみアクセスできます。

すべての環境変数を表示するには、printenvコマンドを使用します。変数の値を知る必要がある場合は、変数の名前を引数として挿入します。

printenv PATH

変数はグローバルでもローカルでも、echoで表示できます。

echo $PATH

ローカル変数を設定するには、変数名の後に等号を入れ、その後に値を指定します。

PROJECT="SLED"

等号の前後にスペースを挿入しないでください。スペースを挿入すると、エラーになります。環境変数を設定するには、exportを使用します。

export NAME="tux"

変数を削除するには、unsetを使用します。

unset NAME

次のテーブルに、シェルスクリプトで使用できる共通環境変数を示します。

表 1.5: 便利な環境変数

HOME

現在のユーザのホームディレクトリ

HOST

現在のホスト名

LANG

ツールをローカライズする場合、ツールは、この環境変数からの言語を使用します。英語をCに設定することも可能です。

PATH

シェルのサーチパス。コロンで区切ったディレクトリのリスト

PS1

各コマンドの前にプリントされる通常のプロンプトを指定します。

PS2

複数行コマンドの実行時にプリントされるセカンダリプロンプトを指定します。

PWD

現在の作業ディレクトリ

ユーザ

現在のユーザ

1.5.1 引数変数の使用

たとえば、スクリプトfoo.shは、次のように実行できます。

foo.sh "Tux Penguin" 2000

スクリプトに渡される引数すべてにアクセスするには、位置パラメータが必要です。これらのパラメータは、最初の引数には$1、2つ目の引数には$2という順序で割り当てます。パラメータは最大9つまで使用できます。スクリプト名を取得するには、$0を使用します。

次のスクリプトfoo.shは、1から4までのすべての引数をプリントします。

#!/bin/sh
echo \"$1\" \"$2\" \"$3\" \"$4\"

このスクリプトを既出例の引数を使用して実行すると、次の結果が出力されます。

"Tux Penguin" "2000" "" ""

1.5.2 変数置換の使用

変数置換では、変数のコンテンツに、左側または右側からパターンを適用します。次のリストに、可能な構文形式を示します。

${VAR#pattern}

左側から最も短い一致を削除します。

file=/home/tux/book/book.tar.bz2
echo ${file#*/}
home/tux/book/book.tar.bz2
${VAR##pattern}

左側から最も長い一致を削除します。

file=/home/tux/book/book.tar.bz2
echo ${file##*/}
book.tar.bz2
${VAR%pattern}

右側から最も短い一致を削除します。

file=/home/tux/book/book.tar.bz2
echo ${file%.*}
/home/tux/book/book.tar
${VAR%%pattern}

右側から最も長い一致を削除します。

file=/home/tux/book/book.tar.bz2
echo ${file%%.*}
/home/tux/book/book
${VAR/pattern_1/pattern_2}

VARのコンテンツをPATTERN_1からPATTERN_2に置換します。

file=/home/tux/book/book.tar.bz2
echo ${file/tux/wilber}
/home/wilber/book/book.tar.bz2

1.6 コマンドのグループ化と結合

シェルでは、条件付き実行のため、コマンドを結合し、グループ化することができます。各コマンドが返す終了コードにより、コマンドの成功または失敗が判別されます。終了コードが0(ゼロ)の場合、コマンドは成功しました。それ以外はすべて、コマンド固有のエラーをマークします。

次に、コマンドをグループ化する方法を示します。

Command1 ; Command2

コマンドをシーケンシャルに実行します。終了コードはチェックされません。次の行では、各コマンドの終了コードにかかわらず、catでファイルのコンテンツを表示し、次に、lsでファイルプロパティをプリントします。

cat filelist.txt ; ls -l filelist.txt
Command1 && Command2

左のコマンドが成功した場合、右のコマンドを実行します(論理AND)。次の行では、ファイルのコンテンツを表示し、そのコマンドが成功した場合のみ、ファイルのプロパティをプリントします(このリストの前の項目と比較してください)。

cat filelist.txt && ls -l filelist.txt
Command1 || Command2

左のコマンドが失敗した場合、右のコマンドを実行します(論理OR)次の行では、/home/tux/fooでのディレクトリ作成に失敗した場合のみ、/home/wilber/bar内にディレクトリを作成します。

mkdir /home/tux/foo || mkdir /home/wilber/bar
funcname(){ ... }

シェル関数を作成します。位置パラメータを使用して、関数の引数にアクセスできます。次の行では、短いメッセージをプリントする関数helloを定義します。

hello() { echo "Hello $1"; }

この関数は、次のように呼び出せます。

hello Tux

結果は、次のようにプリントされます。

Hello Tux

1.7 よく使用されるフローコンストラクトの操作

スクリプトのフローを制御するため、シェルでは、whileiffor、およびcaseの各構文を使用します。

1.7.1 if制御コマンド

ifコマンドは、式のチェックに使用されます。たとえば、次のコードは、現在のユーザがTuxであるかどうかをテストします。

if test $USER = "tux"; then
  echo "Hello Tux."
else
  echo "You are not Tux."
fi

テスト式は、複雑にすることも、シンプルにすることも可能です。次の式は、ファイルfoo.txtが存在するかどうかをチェックします。

if test -e /tmp/foo.txt ; then
  echo "Found foo.txt"
fi

test式は、角括弧で短縮することもできます。

if [ -e /tmp/foo.txt ] ; then
  echo "Found foo.txt"
fi

その他の役に立つ式については、http://www.cyberciti.biz/nixcraft/linux/docs/uniqlinuxfeatures/lsst/ch03sec02.htmlを参照してください。

1.7.2 forコマンドによるループの作成

forループを使用すると、エントリのリストにコマンドを実行できます。たとえば、次のコードは、現在のディレクトリ内のPNGファイルの情報をプリントします。

for i in *.png; do
 ls -l $i
done

1.8 詳細情報

Bashに関する重要な情報は、マニュアルページman bashに記載されています。このトピックの詳細については、次のリストを参照してください。

2 sudo

ファイルの変更やスーパユーザのみが許可されているタスクを実行するために、多くのコマンドとシステムユーティリティは、rootとして実行する必要があります。セキュリティ上の理由のため、および危険なコマンドが偶発的に実行されるのを回避するため、通常はrootとして直接ログインしないことをお勧めします。代わりに、通常の特権のないユーザとして、sudoコマンドを使用し、昇格された特権付きでコマンドを実行することをお勧めします。

SUSE Linux Enterprise Serverでは、sudoは、suと同様に機能するようデフォルトで設定されています。ただし、sudoを使用することで、ユーザは、他のユーザの特権を自由に設定し、それらの特権を使用してコマンドを実行できるようになります。このコマンドを使用して、指定の特権を持つ役割を特定のユーザとグループに割り当てることができます。たとえば、usersグループのメンバーが、wilberの特権でコマンドを実行できるようにすることができます。コマンドへのアクセス権は、コマンドオプションの指定を禁止するなどしてさらに制限できます。suでは、PAMを使用した認証で常にrootパスワードを必要としますが、sudoでは、ユーザの資格情報を使用して認証するように設定できます。これにより、セキュリティがより強化されます。rootパスワードを共有する必要がなくなるからです。たとえば、usersグループのメンバーが、wilberとしてfrobnicateコマンドを実行することを許可できますが、その際に、引数の指定を禁止する制限を付けることができます。このコマンドを使用して、指定の機能を持つ役割を特定のユーザとグループに割り当てることができます。

2.1 sudoの基本的な使用方法

sudoは簡単に使用できて、非常に強力なコマンドです。

2.1.1 単一コマンドの実行

標準ユーザとしてログインしている場合、コマンドの前にsudoを追加することで、任意のコマンドをrootとして実行できます。その際、rootパスワードの入力が要求され、認証に成功すると、コマンドがrootとして実行されます。

tux > id -un1
tux
tux > sudo id -un
root's password:2
root
tux > id -un
tux3
tux > sudo id -un
4
root

1

id -unコマンドは、現在のユーザのログイン名を出力します。

2

入力時には、パスワードは表示されません(クリアテキストとしてだけでなく、黒丸としても表示されません)。

3

sudoで始まるコマンドのみが、昇格された特権で実行されます。sudo接頭辞なしで同じコマンドを実行した場合は、再度現在のユーザの特権で実行されます。

4

限られた時間に、rootパスワードを繰り返し入力する必要がなくなります。

ヒント
ヒント: I/Oリダイレクト

I/Oリダイレクトは、多くのユーザが期待している動作と異なります。

tux >  sudo echo s > /proc/sysrq-trigger
bash: /proc/sysrq-trigger: Permission denied
tux >  sudo cat < /proc/1/maps
bash: /proc/1/maps: Permission denied

昇格された特権で実行されるのはecho/catバイナリのみで、リダイレクトは、ユーザのシェルでユーザ特権を使用して実行されます。2.1.2項 「シェルの起動」で説明しているようにシェルを起動することも、ddユーティリティを使用することもできます。

echo s | sudo dd of=/proc/sysrq-trigger
sudo dd if=/proc/1/maps | cat

2.1.2 シェルの起動

すべてのコマンドの前にsudoを追加するのは煩わしい場合があります。シェルはsudo bashコマンドとして指定できますが、組み込まれたメカニズムのいずれかを使用してシェルを起動することをお勧めします。

sudo -s (<command>)

SHELL環境変数で指定したシェル、またはターゲットユーザのデフォルトのシェルを起動します。コマンドを指定した場合は、コマンドが(-cオプション付き)でシェルに渡されます。そうでない場合は、シェルが対話モードで実行されます。

tux:~ > sudo -i
root's password:
root:/home/tux # exit
tux:~ > 
sudo -i (<command>)

-sと同様ですが、シェルをログインシェルとして起動します。つまり、シェルの起動ファイル(.profileなど)は処理され、現在の作業ディレクトリはターゲットユーザのホームディレクトリに設定されます。

tux:~ > sudo -i
root's password:
root:~ # exit
tux:~ > 

2.1.3 環境変数

デフォルトでは、sudoは環境変数を伝達しません。

tux > ENVVAR=test env | grep ENVVAR
ENVVAR=test
tux > ENVVAR=test sudo env | grep ENVVAR
root's password:
1
tux > 

1

空白の出力は、sudoで実行したコマンドのコンテキストにENVVAR環境変数が存在しなかったことを示しています。

この動作は、env_resetオプションで変更できます。表2.1「有用なフラグとオプション」を参照してください。

2.2 sudoの設定

sudoは、さまざまな設定が可能な、柔軟なツールです。

注記
注記: sudoからのロックアウト

誤ってsudoからロックアウトした場合は、su -rootパスワードを使用してルートシェルを取得してください。エラーを修正するには、visudoを実行します。

2.2.1 設定ファイルの編集

sudo向けの主なポリシー設定ファイルは、/etc/sudoersです。ポリシー設定ファイル内のエラーが原因で、システムからロックアウトされてしまう可能性があるため、編集にvisudoを使用することを強くお勧めします。このコマンドは、開いているファイルが同時に変更されるのを防ぎ、構文エラーがないかどうかも変更の保存前に確認します。

その名前が示唆するのとは異なり、EDITOR環境変数を次のように設定して、vi以外のエディタを使用することもできます。

sudo EDITOR=/usr/bin/nano visudo

ただし、/etc/sudoersファイル自体はシステムパッケージで提供されるため、アップデート時に変更内容が失われてしまう可能性があります。そのため、カスタム設定は、/etc/sudoers.d/ディレクトリ内のファイルに対して行うことをお勧めします。そこにあるファイルは自動的にインクルードされるからです。対象のサブディレクトリでファイルを作成または編集するには、次のコマンドを実行します。

sudo visudo -f /etc/sudoers.d/NAME

または、別のエディタ(nanoなど)を使用します。

sudo EDITOR=/usr/bin/nano visudo -f /etc/sudoers.d/NAME
注記
注記: /etc/sudoers.d内の無視されるファイル

/etc/sudoers.dをインクルードするために使用される/etc/sudoers#includedirコマンドでは、~(チルダ)で終わるファイルや.(ドット)を含むファイルが無視されます。

visudoコマンドの詳細については、man 8 visudoを実行してください。

2.2.2 基本的なsudoersの設定構文

sudoersの設定ファイルには、2種類のオプション(文字列とフラグ)があります。文字列には任意の値を含めることができますが、フラグはONかOFFのいずれかのみです。sudoersの設定ファイルの最も重要な構文構造を次に示します。

# Everything on a line after a # gets ignored 1
Defaults !insults # Disable the insults flag 2
Defaults env_keep += "DISPLAY HOME" # Add DISPLAY and HOME to env_keep
tux ALL = NOPASSWD: /usr/bin/frobnicate, PASSWD: /usr/bin/journalctl 3

1

例外が2つあります。#include#includedirは通常のコマンドです。数値を続けた場合は、UIDを指定します。

2

指定のフラグをONに設定するには、!を削除します。

3

詳細については、2.2.3項 「sudoersのルール」を参照してください。

表 2.1: 有用なフラグとオプション

オプション名

説明

targetpw

このフラグは、呼び出し元のユーザが、ターゲットユーザのパスワード(ON)(rootなど)と、呼び出し元のユーザのパスワード(OFF)のいずれを要求されるかを決定します。

Defaults targetpw # Turn targetpw flag ON
rootpw

設定すると、sudoが、ターゲットユーザや呼び出し元のパスワードの代わりにrootパスワードを要求します。デフォルトはOFFです。

Defaults !rootpw # Turn rootpw flag OFF
env_reset

設定すると、sudoが、TERMPATHHOMEMAILSHELLLOGNAMEUSERUSERNAME、 およびSUDO_*が指定された最小限の環境を作成します。また、env_keepに列挙されている変数は、呼び出し元の環境からインポートされます。デフォルトは[ON]です。

Defaults env_reset # Turn env_reset flag ON
env_keep

env_resetフラグがONの場合に保持する環境変数の一覧。

# Set env_keep to contain EDITOR and PROMPT
Defaults env_keep = "EDITOR PROMPT"
Defaults env_keep += "JRE_HOME" # Add JRE_HOME
Defaults env_keep -= "JRE_HOME" # Remove JRE_HOME
env_delete

env_resetフラグがOFFの場合に削除する環境変数の一覧。

# Set env_delete to contain EDITOR and PROMPT
Defaults env_delete = "EDITOR PROMPT"
Defaults env_delete += "JRE_HOME" # Add JRE_HOME
Defaults env_delete -= "JRE_HOME" # Remove JRE_HOME

Defaultsトークンを使用することで、ユーザ、ホスト、およびコマンドのコレクションのエイリアスを作成することもできます。さらに、一連のユーザのみを対象としてオプションを適用することができます。

/etc/sudoers設定ファイルの詳細については、man 5 sudoersを参照してください。

2.2.3 sudoersのルール

sudoersの設定のルールは非常に複雑な場合があるため、このセクションでは、基本的なルールのみを説明します。各ルールは、基本的なスキームに従います([]はオプション部分を示しています)。

#Who      Where         As whom      Tag                What
User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List
sudoersのルールの構文
User_List

1つ以上の(,で区切られた)識別子。ユーザ名、%GROUPNAME形式のグループ、#UID形式のユーザIDを指定します。否定は、!接頭辞で示せます。

Host_List

1つ以上の(,で区切られた)識別子。(完全修飾された)ホスト名またはIPアドレスのいずれかを指定します。否定は、!接頭辞で示せます。通常、Host_ListにはALLを選択します。

NOPASSWD:|PASSWD:

NOPASSWD:の後に、CMDSPECと一致するコマンドを実行すると、パスワードは要求されません。

デフォルトは、PASSWDです。NOPASSWDとPASSWDの両方が同じ行に存在する場合にのみPASSWDを明示的に指定する必要があります。

tux ALL = PASSWD: /usr/bin/foo, NOPASSWD: /usr/bin/bar
Cmnd_List

1つ以上の(,で区切られた)指定子。実行ファイルへのパスの後に、使用可能な引数を指定するか、何も指定しません。

/usr/bin/foo     # Anything allowed
/usr/bin/foo bar # Only "/usr/bin/foo bar" allowed
/usr/bin/foo ""  # No arguments allowed

ALLは、User_ListHost_List、およびCmnd_Listとしても使用できます。

パスワードを入力しなくても、tuxがすべてのコマンドをrootとして実行できるようにするルールは次のとおりです。

tux ALL = NOPASSWD: ALL

tuxsystemctl restart apache2を実行できるようにするルールは次のとおりです。

tux ALL = /usr/bin/systemctl restart apache2

tuxwalladminとして引数なしで実行できるようにするルールは次のとおりです。

tux ALL = (admin) /usr/bin/wall ""
警告
警告: 危険な構造

次のような構造は、

ALL ALL = ALL

Defaults targetpwなしでは使用できません。そうしないと、だれでもrootとしてコマンドを実行できるようになってしまいます。

2.3 一般的な用途

簡単なセットアップやデスクトップ環境では、たいていの場合はデフォルトの設定でも十分ですが、カスタム設定を使用すると便利な場合もあります。

2.3.1 rootパスワードなしのsudoの使用

これは、特殊な制限(ユーザXは、rootとしてのみコマンドYを実行できる)がある場合は不可能なことです。それ以外の場合も、コマンドの実行権限にある程度の区別を付けることが推奨されます。慣例では、wheelグループのメンバーは、すべてのコマンドをrootとしてsudoで実行できます。

  1. wheelグループに自分自身を追加します。

    自分のユーザアカウントがまだwheelグループのメンバーでない場合は、sudo usermod -a -G wheel USERNAMEを実行してログアウトした後、再度ログインして追加します。groups USERNAMEを実行して、変更が成功したことを確認します。

  2. 呼び出し元のユーザのパスワード(デフォルト)を使用して認証します。

    visudo(2.2.1項 「設定ファイルの編集」を参照)を使用して/etc/sudoers.d/userpwファイルを作成し、次の文を追加します。

    Defaults !targetpw
  3. 新しいデフォルトのルールを選択します。

    ユーザにパスワードの再入力を求めるかどうかによって、/etc/sudoersの特定行のコメントを解除し、デフォルトのルールをコメントアウトします。

    ## Uncomment to allow members of group wheel to execute any command
    # %wheel ALL=(ALL) ALL
    
    ## Same thing without a password
    # %wheel ALL=(ALL) NOPASSWD: ALL
  4. デフォルトのルールにより厳しい制約を設けます。

    /etc/sudoersの、すべてを許可するルールをコメントアウトするか、削除します。

    ALL     ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!
    警告
    警告: sudoersの危険なルール

    このステップは忘れないでください。忘れると、「すべての」ユーザが「すべての」コマンドをrootとして実行できるようになってしまいます。

  5. 設定をテストします。

    sudoを、wheelのメンバーとして、またはメンバー以外として実行してみてください。

    tux:~ > groups
    users wheel
    tux:~ > sudo id -un
    tux's password:
    root
    wilber:~ > groups
    users
    wilber:~ > sudo id -un
    wilber is not in the sudoers file.  This incident will be reported.

2.3.2 X.Orgアプリケーションでのsudoの使用

グラフィカルアプリケーションをsudoで起動すると、次のエラーが発生します。

tux > sudo xterm
xterm: Xt error: Can't open display: %s
xterm: DISPLAY is not set

YaSTによって、グラフィカルインタフェースの代わりにncursesインタフェースが選択されます。

sudoで開始したアプリケーションでX.Orgを使用するには、DISPLAY環境変数およびXAUTHORITY環境変数を伝達する必要があります。これらの環境変数を設定するには、/etc/sudoers.d/xorgファイル(2.2.1項 「設定ファイルの編集」を参照)を作成して、次の行を追加します。

Defaults env_keep += "DISPLAY XAUTHORITY"

まだ設定されていない場合は、XAUTHORITY変数を次のように設定します。

export XAUTHORITY=~/.Xauthority

これで、X.Orgアプリケーションを通常どおり実行できます。

sudo yast2

2.4 詳細情報

使用可能なコマンドラインスイッチに関する簡単な概要は、sudo --helpを実行して参照できます。解説およびその他の重要な情報はman 8 sudoマニュアルページ、設定に関する説明はman 5 sudoersマニュアルページで参照できます。

3 YaSTオンラインアップデート

SUSEはお買い上げの製品に対し、継続的にソフトウェアセキュリティのアップデートを提供します。デフォルトでは、システムを最新の状態に維持するために更新アプレットが使用されます。アップデートアプレットの詳細については、Book “導入ガイド”, Chapter 13 “ソフトウェアをインストールまたは削除する”, Section 13.5 “システムのアップデート”を参照してください。この章では、ソフトウェアパッケージをアップデートする代替ツールとして、YaSTオンラインアップデートを紹介します。

SUSE® Linux Enterprise Serverの現在のパッチは、アップデートソフトウェアリポジトリから入手できます。インストール時に製品を登録した場合、アップデートリポジトリはすでに設定されています。SUSE Linux Enterprise Serverを登録していない場合は、YaSTで製品登録を起動して登録できます。または、信頼できるソースから、手動でアップデートリポジトリを追加することもできます。リポジトリを追加または削除するには、YaSTで、ソフトウェア › ソフトウェアリポジトリの順に選択して、リポジトリマネージャを起動します。リポジトリマネージャの詳細については、Book “導入ガイド”, Chapter 13 “ソフトウェアをインストールまたは削除する”, Section 13.4 “ソフトウェアリポジトリおよびサービスの操作”を参照してください。

注記
注記: アップデートカタログのアクセス時のエラー

アップデートカタログにアクセスできない場合、登録の期限が切れている場合があります。通常、SUSE Linux Enterprise Serverには1年または3年の登録期間があり、この期間内はアップデートカタログにアクセスできます。このアクセスは登録期間が切れると拒否されます。

アップデートカタログへのアクセスが拒否される場合は、SUSEカスタマセンターにアクセスして登録を確認することを推奨する警告メッセージが表示されます。SUSEカスタマーセンターには、https://scc.suse.com//でアクセスできます。

SUSEは、各種の関連性レベルを持つアップデートを提供します。

セキュリティアップデート

セキュリティアップデートは、重大なセキュリティハザードを修復するので、必ずインストールする必要があります。

推奨アップデート

コンピュータに損害を与える可能性のある問題を修復します。

オプションアップデート

セキュリティに関連しない問題を修復したり、拡張機能を提供します。

3.1 オンライン更新ダイアログ

オンライン更新ダイアログを開くには、YaSTを起動し、ソフトウェア › オンライン更新の順に選択します。または、yast2 online_updateで、コマンドラインからオンラインアップデートを開始します。

オンラインアップデートウィンドウは、4つのセクションから成り立っています。

YaSTオンラインアップデート
図 3.1: YaSTオンラインアップデート

左側の概要セクションには、SUSE Linux Enterprise Serverの使用可能なパッチが一覧にされます。パッチはセキュリティの関連性によってソートされます(securityrecommended、およびoptional)。概要セクションのビューは、パッチのカテゴリを表示から、以下のオプションの1つを選択することによって変更できます。

Needed Patches(デフォルトビュー)

システムにインストールされたパッケージに適用される、インストールされなかったパッチ。

Unneeded Patches

システムにインストールされていないパッケージに適用されるパッチか、または(該当するセキュリティがすでに別のソースで更新されたので)要件がすでに満たされているパッチ。

すべてのパッチ

SUSE Linux Enterprise Serverで使用可能なすべてのパッチ。

概要セクションの各リストエントリは、記号とパッチ名で構成されています。可能な記号とそれらの意味の概要については、ShiftF1を押してください。SecurityパッチおよびRecommendedパッチで要求されるアクションは、自動的に設定されます。アクションは、自動インストール自動更新、および自動削除です。

アップデートリポジトリ以外のリポジトリから最新のパッケージをインストールする場合、そのパッケージのパッチ要件はそのインストールで満たされる場合があります。この場合、パッチ概要の前にチェックマークが表示されます。パッチは、インストール用にマークするまでリストに表示されます。これによってパッチは実際にはインストールされませんが(パッチはすでに最新であるため)、インストール済みとしてパッチをマークします。

概要セクションでエントリを選択すると、ダイアログの左下隅に短いパッチの説明が表示されます。左上のセクションには、選択されたパッチに含まれているパッケージが一覧されます(パッチは複数のパッケージから成ることがあります)。右上のセクションでエントリをクリックすると、パッチに含まれている各パッケージの詳細が表示されます。

3.2 パッチのインストール

YaSTオンラインアップデートのダイアログでは、すべての利用可能なパッチを一度にインストールしたり、システムに適用したいパッチを手動で選択したりできます。システムに適用済みのパッチを元に戻すこともできます。

デフォルトでは、お使いのシステムで現在使用できる新しいパッチ(ただし、optional以外) はすべて、すでにインストール用にマークされています。受諾または適用をクリックすると、これらのパッチが自動的に適用されます。1つまたは複数のパッチでシステムの再起動が必要な場合、パッチのインストールが開始される前にその旨が通知されます。選択したパッチのインストールを続行し、再起動が必要なすべてのパッチのインストールをスキップしてして残りをインストールするか、パッチの手動選択に戻ることを決定できます。

手順 3.1: YaSTオンラインアップデートによるパッチの適用
  1. YaSTを起動して、ソフトウェア › オンライン更新の順に選択します。

  2. システムで現在使用可能なすべての新しいパッチ(ただし、optional以外)を自動的に適用するには、適用または受諾を押します。

  3. まず、適用したいパッチの選択を変更します。

    1. インタフェースが提供する各フィルタとビューを使用します。詳細については、3.1項 「オンライン更新ダイアログ」を参照してください。

    2. ニーズと好みに従ってパッチを選択または選択解除するには、パッチを右クリックしてコンテキストメニューから各アクションを選択します。

      重要
      重要: セキュリティアップデートは必ず適用する

      十分な理由がない限り、security関係のパッチは選択解除しないでください。これらのパッチは、重大なセキュリティハザードを修復し、システムの悪用を防ぎます。

    3. 大部分のパッチには、複数のパッケージのアップデートが含まれています。単一パッケージに対するアクションを変更する場合は、パッケージビューでパッケージを右クリックしてアクションを選択します。

    4. 選択内容を確認し、選択したパッチを適用するには、適用または受諾をクリックして続行します。

  4. インストールの完了後、完了をクリックして、YaSTのオンライン更新を終了します。これで、システムが最新の状態になりました。

3.3 自動オンラインアップデート

YaSTでは、毎日、毎週、または毎月のスケジュールで自動アップデートを設定することもできます。各モジュールを使用するには、まず、yast2-online-update-configurationパッケージをインストールする必要があります。

デフォルトでは、アップデートは、デルタRPMとしてダウンロードされます。デルタRPMからのRPMパッケージの再構築は、メモリとプロセッサを集中的に使用するので、セットアップまたはハードウェア構成によっては、パフォーマンス上の理由によりデルタRPMの使用を無効にする必要があります。

一部のパッチ(カーネルのアップデートやライセンス契約を必要とするパッケージなど)ではユーザによる操作が必要で、これによって自動アップデート手順が停止します。ユーザによる操作が必要なパッチをスキップするよう設定できます。

手順 3.2: 自動オンラインアップデートの設定
  1. インストール後、YaSTを起動し、ソフトウェア › オンラインアップデートの設定の順に選択します。

    または、コマンドラインから、yast2 online_update_configurationを使用してモジュールを起動します。

  2. 自動オンラインアップデートを有効にします。

  3. 更新間隔として毎日毎週、または毎月を選択します。

  4. ライセンス契約に自動的に同意するには、ライセンスに同意するを有効にします。

  5. 更新手順を完全に自動的に進行させたい場合は、インタラクティブパッチをスキップするを選択します。

    重要
    重要: パッチのスキップ

    介入を必要とするパッケージのスキップを選択した場合は、時折、オンライン更新を手動で実行して、それらのパッチもインストールしてください。さもないと、重要なパッチをインストールできないことがあります。

  6. アップデートパッケージによって推奨されるすべてのパッケージを自動的にインストールするには、推奨パッケージを含むを有効にします。

  7. デルタRPMの使用を無効にするには(パフォーマンス上の理由)、delta rpmを使用するを無効にします。

  8. セキュリティや推奨など、カテゴリ別にパッチをフィルタリングするには、Filter by Categoryを有効にしてリストから適切なカテゴリを追加します。選択したカテゴリのパッチのみがインストールされます。それ以外はスキップされます。

  9. 入力した設定を確認して、OK をクリックします。

自動オンラインアップデートでは、システムは後で自動的には再起動されません。システムの再起動が必要なシステムの更新がある場合は、手動で再起動する必要があります。

4 YaST

YaSTは、SUSE Linux Enterprise Server用のインストールおよび設定ツールです。グラフィカルインタフェースを備えており、インストール中でもインストール後でもシステムをすばやくカスタマイズできます。YaSTを使用して、ハードウェアのセットアップ、ネットワークやシステムサービスの設定、セキュリティ設定を行うことができます。

4.1 高度なキーの組み合わせ

YaSTでは高度なキーの組み合わせを使用できます。

Print Screen

スクリーンショットを作成して保存します。YaSTを特定のデスクトップ環境で実行している場合、使用できないことがあります。

ShiftF4

視覚に障害のあるユーザ向けに最適化されたカラーパレットを有効/無効にします。

ShiftF7

デバッグメッセージのログを有効/無効にします。

ShiftF8

ファイルダイアログを開いて、ログファイルを標準の場所以外に保存します。

CtrlShiftAltD

DebugEventを送信します。YaSTモジュールは特殊なデバッグアクションを実行してこれに応答できます。結果は特定のYaSTモジュールによって異なります。

CtrlShiftAltM

マクロレコーダを開始/停止します。

CtrlShiftAltP

マクロを再生します。

CtrlShiftAltS

スタイルシートエディタを表示します。

CtrlShiftAltT

ウィジェットツリーをログファイルにダンプします。

CtrlShiftAltX

ターミナルウィンドウ(xterm)を開きます。VNCを使用したインストールプロセスで便利です。

CtrlShiftAltY

ウィジェットツリーブラウザを表示します。

5 テキストモードのYaST

このセクションは、システムでXサーバを実行せずに、テキストベースのインストールツールを使用しているシステム管理者や専門家の方を対象にしています。ここでは、YaSTをテキストモードで起動して操作するための基本的な情報を説明しています。

テキストモードのYaSTは、ncursesライブラリを使用して、使いやすい擬似グラフィカルユーザインタフェースを提供します。ncursesライブラリは、デフォルトでインストールされています。YaSTを実行するためのターミナルエミュレータの最小サポートサイズは、80x25文字です。

テキストモードのYaSTのメインウィンドウ
図 5.1: テキストモードのYaSTのメインウィンドウ

YaSTをテキストモードで起動すると、YaSTコントロールセンターが表示されます(図 5.1を参照してください)。このメインウィンドウは、以下の3つの主要領域で構成されています。左側のフレームのカテゴリには、さまざまなモジュールがあります。このフレームはYaSTが起動したときにアクティブになり、白い太線でマークされます。アクティブなカテゴリが選択されています。右側のフレームには、アクティブなカテゴリで使用できるモジュールの概要が表示されます。下方のフレームには、ヘルプおよび終了用ボタンがあります。

YaSTコントロールセンターを起動すると、カテゴリSoftware (ソフトウェア)が自動的に選択されます。カテゴリを変更するには、を使用します。カテゴリからモジュールを選択するには、で右側のフレームをアクティブにして、を使用してモジュールを選択します。矢印キーを押したままにして、使用可能なモジュールのリストをスクロールします。選択したモジュールが選択されます。Enterを押してアクティブなモジュールを起動します。

モジュールのさまざまなボタンまたは選択フィールドで、文字がハイライト表示されています(デフォルトは黄色)。そのまま<Tab>キーでナビゲートするする代わりに、直接ボタンを選択するには、Althighlighted_letterのキーを使用します。AltQを押すか、または終了を選択してEnterを押して、YaSTコントロールセンターを終了します。

ヒント
ヒント: YaSTダイアログの更新

ウィンドウのサイズを変更した場合など、YaSTのダイアログの表示が乱れたり変形したりした場合は、CtrlLを押すとコンテンツを更新し復元できます。

5.1 モジュールでのナビゲーション

以降のYaSTモジュール内のコントロール要素の説明では、ファンクションキーとAltキーの組み合わせがすべて有効で、別のグローバル機能に割り当てられていないことを前提としています。可能性のある例外事項については、5.3項 「キーの組み合わせの制約」を参照してください。

ボタンおよび選択リスト間のナビゲーター

選択リストを含むボタンおよびフレーム間をナビゲートするには、<Tab>キーを使用します。逆の順序でナビゲートするには、Alt<Tab>またはShift<Tab>の組み合わせを使用します。

選択リストでのナビゲーション

選択リストを含むアクティブフレーム内の個々の要素間をナビゲートするには、矢印キー()を使用します。フレーム内の個別エントリがその幅を超える場合は、ShiftまたはShiftを使用して、右または左にスクロールします。代わりにCtrlEまたはCtrlAを使用することもできます。この組み合わせは、コントロールセンターの場合のように、またはを使用すると、アクティブフレームまたは現在の選択リストが変更されてしまう場合に使用できます。

ボタン、ラジオボタン、およびチェックボックス

が付いているボタン(チェックボックス)または()が付いているボタン(ラジオボタン)を選択するには、SpaceキーまたはEnterキーを押します。または、Althighlighted_letterでラジオボタンおよびチェックボックスを直接選択することもできます。この場合、Enterキーによる確認は不要です。<Tab>キーで項目にナビゲートする場合は、Enterキーを押して、選択したアクションを実行するか、対応するメニュー項目をアクティブにします。

ファンクションキー

ファンクションキー(F1 ... F12)を使用すると、さまざまなボタンの機能を素早く利用できます。使用可能なファンクションキーの組み合わせ(FX)は、YaST画面の一番下の行に表示されます。どのファンクションキーが実際にどのボタンにマップされているかは、アクティブになっているYaSTモジュールによります。提供されるボタン(詳細情報追加削除など)は、モジュールごとに異なるからです。F10は、受諾OK次へ、および完了の代わりに使用します。F1を押して、YaSTヘルプにアクセスします。

ncursesモードのナビゲーションツリーの使用

一部のYaSTモジュールでは、ウィンドウの左部分にあるナビゲーションツリーを使用して、設定ダイアログを選択します。矢印キー()を使用して、ツリー内を移動します。Spaceを使用して、ツリー項目を開閉します。ncursesモードでは、ナビゲーションツリーでの選択後、選択したダイアログを表示するにはEnterを押す必要があります。これは意図的な動作であり、これによって、ナビゲーションツリーのブラウズ時に時間のかかる再表示を節約できます。

ソフトウェアインストールモジュールでのソフトウェアの選択

表示されるパッケージの量を制限するには、左側のフィルタを使用します。インストール済みパッケージには、文字iのマークが付いています。パッケージのステータスを変更するには、SpaceキーまたはEnterキーを押します。または、Actions (アクション)メニューを使用して、必要なステータスの変更(インストール、削除、更新、タブー、またはロック)を選択します。

ソフトウェアインストールモジュール
図 5.2: ソフトウェアインストールモジュール

5.2 高度なキーの組み合わせ

テキストモードのYaSTでは一連の高度なキーの組み合わせを使用できます。

ShiftF1

高度なホットキーのリストを表示します。

ShiftF4

配色を変更します。

Ctrl\

アプリケーションを終了します。

CtrlL

画面を更新します。

CtrlD F1

高度なホットキーのリストを表示します。

CtrlD ShiftD

ダイアログをスクリーンショットとしてログファイルにダンプします。

CtrlD ShiftY

YDialogSpyを開いてウィジェット階層を表示します。

5.3 キーの組み合わせの制約

ウィンドウマネージャがグローバルなAltキーの組み合わせを使用していると、YaSTでのAltキーの組み合わせが機能しない場合があります。ShiftAltなどのキーは、端末の設定で使用されている場合もあります。

AltキーのEscキーでの置き換え

AltショートカットはAltの代わりにEscキーでも実行できます。たとえば、EscHは、AltHの代わりとなります。(まずEscを押して、次にHを押します)

CtrlFCtrlBによる前後のナビゲーション

AltShiftの組み合わせがウィンドウマネージャまたは端末に専有されている場合は、CtrlF(進む)とCtrlB(戻る)を代わりに使用できます。

ファンクションキーの制約

ファンクションキー(F1 ... F12)は各種機能にも使用されます。一部のファンクションキーは、端末で使用済みで、YaSTで使用できない場合があります。ただし、Altキーのキーの組み合わせとファンクションキーは、ピュアテキストコンソールでは常に完全に使用できます。

5.4 YaSTコマンドラインオプション

テキストモードのインタフェースのほか、YaSTには、シンプルなコマンドラインインタフェースがあります。YaSTコマンドラインオプションのリストを表示するには、次のように入力します。

yast -h

5.4.1 個別モジュールの起動

時間節約のため、個別のYaSTモジュールを直接起動できます。モジュールを起動するには、次のように入力します。

yast <module_name>

yast -l」または「yast --list」と入力して、システムで使用可能になっているすべてのモジュールのリストを表示します。たとえば、「yast lan」と入力して、ネットワークモジュールを起動します。

5.4.2 コマンドラインからのパッケージのインストール

パッケージ名が既知であり、パッケージが有効なインストールリポジトリに用意されている場合は、コマンドラインオプション-iを使用してパッケージをインストールできます。

yast -i <package_name>

または

yast --install <package_name>

PACKAGE_NAMEには、(gvimなどの)1つの短いパッケージ名を指定するか(この場合、依存関係を確認してインストールされます)、RPMパッケージのフルパスを指定できます(この場合、依存関係を確認せずにインストールされます)。

YaSTから提供される機能を超える機能を持つコマンドラインベースのソフトウェア管理ユーティリティを必要とする場合は、Zypperの使用をご検討ください。このユーティリティは、YaSTパッケージマネージャの基礎でもある同じソフトウェア管理ライブラリを使用します。Zypperの基本的使用法については、6.1項 「Zypperの使用」で説明されています。

5.4.3 YaSTモジュールのコマンドラインパラメータ

スクリプトでYaST機能を使用するため、YaSTでは、個々のモジュールにコマンドラインサポートを提供しています。ただし、すべてのモジュールにコマンドラインサポートがあるわけではありません。モジュールで利用できるオプションを表示するには、次のように入力します。

yast <module_name> help

モジュールにコマンドラインサポートがない場合、モジュールはテキストモードで起動され、次のメッセージが表示されます。

This YaST module does not support the command line interface.

6 コマンドラインツールによるソフトウェアの管理

概要

この章では、ソフトウェア管理の2つのコマンドラインツールとして、ZypperとRPMについて説明します。このコンテキストで使用される述語(たとえば、repositorypatchupdateなど)の定義については、Book “導入ガイド”, Chapter 13 “ソフトウェアをインストールまたは削除する”, Section 13.1 “用語の定義”を参照してください。

6.1 Zypperの使用

Zypperは、パッケージのインストール、更新、削除、およびリポジトリの管理を行うためのコマンドラインパッケージマネージャです。これは特に、リモートソフトウェア管理タスクの実行、またはシェルスクリプトからのソフトウェアの管理で役立ちます。

6.1.1 一般的な使用方法

Zypperの一般的な構文は次のとおりです。

zypper [--global-options] COMMAND  [--command-options] [arguments]

ブラケットで囲まれたコンポーネントは必須ではありません。一般的なオプションおよびすべてのコマンドのリストについては、zypper helpを参照してください。特定のコマンドのヘルプを参照するには、「zypper help COMMAND」と入力します。

Zypperのコマンド

Zypperを実行する最も簡単な方法は、その名前の後にコマンドを入力することです。たとえば、システムに必要なすべてのパッチを適用するには、次のコマンドを使用します。

tux > sudo zypper patch
グローバルオプション

さらに、グローバルオプションをコマンドの直前に入力することによって、1つ以上のグローバルオプションを選択することもできます。

tux > sudo zypper --non-interactive patch

上の例では、オプション--non-interactiveは、確認を一切表示せずにコマンドを実行することを意味します(自動的にデフォルトの回答を適用します)。

コマンド固有のオプション

特定のコマンドに固有のオプションを使用する場合は、コマンドの直後にそのオプションを入力します。

tux > sudo zypper patch --auto-agree-with-licenses

上の例では、--auto-agree-with-licensesを使用して、ライセンスの確認を表示せずに、必要なすべてのパッチをシステムに適用します。その代わりに、自動的にライセンスに同意します。

引数

一部のコマンドでは、1つ以上の引数が必要です。たとえば、コマンドinstallを使用する場合、「インストール」するパッケージを1つまたは複数指定する必要があります。

tux > sudo zypper install mplayer

一部のオプションでは、1つの引数が必要です。次のコマンドでは、すべての既知のパターンが表示されます。

tux > zypper search -t pattern

上記のすべてを結合できます。たとえば、次のコマンドは aspell-deパッケージおよび および aspell-fr パッケージをfactoryリポジトリからインストールしますが、これは冗長です。

tux > sudo zypper -v install --from factory aspell-de aspell-fr

--fromオプションは、指定されたリポジトリからパッケージを要求する際に、すべてのリポジトリを(依存関係の解決のため)有効に保ちます。

ほとんどのZypperコマンドには、指定のコマンドのシミュレーションを行うdry-runオプションがあります。このオプションは、テストの目的で使用できます。

tux > sudo zypper remove --dry-run MozillaFirefox

Zypperは、グローバルオプション--userdata STRINGをサポートします。このオプションを使用して文字列を指定することができます。指定した文字列は、Zypperのログファイルとプラグイン(Btrfsプラグインなど)に書き込まれます。これを使用して、ログファイルでトランザクションにマークを付けたり、トランザクションを特定したりできます。

tux > sudo zypper --userdata STRING patch

6.1.2 Zypperを使ったソフトウェアのインストールと削除

パッケージをインストールまたは削除するには、次のコマンドを使用します。

tux > sudo zypper install PACKAGE_NAME
sudo zypper remove PACKAGE_NAME
警告
警告: 必須システムパッケージは削除しない

必須システムパッケージは削除しないでください。たとえば、 glibczypperkernel などです。これらを削除すると、システムが不安定になったり、まったく動作しなくなったりする可能性があります。

6.1.2.1 インストールまたは削除するパッケージの選択

コマンドzypper installおよびzypper removeでパッケージを指定するには、さまざまな方法があります。

正確なパッケージ名を指定する
tux > sudo zypper install MozillaFirefox
正確なパッケージ名およびバージョン番号を指定する
tux > sudo zypper install MozillaFirefox-52.2
リポジトリエイリアスおよびパッケージ名を指定する
tux > sudo zypper install mozilla:MozillaFirefox

ここでmozillaは、インストールするリポジトリのエイリアスです。

ワイルドカードを使用してパッケージ名を指定する

名前が特定の文字列で始まるか、特定の文字列で終わるパッケージをすべて選択できます。特にパッケージを削除する場合は、ワイルドカードの使用には注意が必要です。次のコマンドでは、名前の先頭にMozが付くすべてのパッケージがインストールされます。

tux > sudo zypper install 'Moz*'
ヒント
ヒント: すべての-debuginfoパッケージを削除

問題をデバッグする際、実行中のプロセスに関する情報を多く得るために、一時的に多数の-debuginfoパッケージをインストールする場合があります。デバッグセッションが終了したら、この環境を消去する必要があります。それには以下を実行します。

tux > sudo zypper remove '*-debuginfo'
機能によって指定する

たとえば、パッケージ名がわからないPerlモジュールをインストールする場合は、機能による指定が便利です。

tux > sudo zypper install firefox
機能、ハードウェアアーキテクチャ、またはバージョンによって指定する

機能とともに、ハードウェアアーキテクチャとバージョンを指定できます。

  • 機能の後にピリオドを付けて、その後に目的のハードウェアアーキテクチャの名前を追加します。たとえば、AMD64/Intel 64アーキテクチャ(Zypperでの名前はx86_64)を指定するには、次のコマンドを使用します。

    tux > sudo zypper install 'firefox.x86_64'
  • バージョンは文字列の最後に追加し、バージョンの前に演算子を付ける必要があります。使用できる演算子は、<(より小さい)、<=(以下)、=(等しい)、>=(以上)、>(より大きい)です。

    tux > sudo zypper install 'firefox>=52.2'
  • 必要なハードウェアアーキテクチャとバージョンを組み合わせて指定することもできます。

    tux > sudo zypper install 'firefox.x86_64>=52.2'
RPMファイルのパスによって指定する

また、パッケージに対するローカルパスまたはリモートパスを指定できます。

tux > sudo zypper install /tmp/install/MozillaFirefox.rpm
tux > sudo zypper install http://download.example.com/MozillaFirefox.rpm

6.1.2.2 パッケージのインストールと削除の結合

パッケージのインストールと削除を同時に行うには、+/-修飾子を使用します。同時に emacs のインストールと、 vim の削除を行うには、次のコマンドを使用します。

tux > sudo zypper install emacs -vim

同時に emacs の削除と、 vim のインストールを行うには、次のコマンドを使用します。

tux > sudo zypper remove emacs +vim

名前の先頭に-が付くパッケージ名がコマンドオプションとして解釈されないようにするには、常に第2引数としてその名前を使用します。これが可能でない場合は、名前の前に--を付けます。

tux > sudo zypper install -emacs +vim       # Wrong
tux > sudo zypper install vim -emacs        # Correct
tux > sudo zypper install -- -emacs +vim    # Correct
tux > sudo zypper remove emacs +vim         # Correct

6.1.2.3 削除されたパッケージの依存関係のクリーンアップ

指定したパッケージの削除後に、不要になったパッケージも自動的に削除されるようにしたい場合は、--clean-depsオプションを使用します。

tux > sudo zypper rm PACKAGE_NAME --clean-deps

6.1.2.4 スクリプトでのZypperの使用

Zypperではデフォルトで、選択したパッケージのインストールまたは削除の前に、あるいは問題が発生した際には、確認が求められます。この動作は、--non-interactiveオプションを使用することで上書きされます。このオプションは、次のように、実際のコマンド(installremovepatch)の前に指定する必要があります。

tux > sudo zypper --non-interactive install PACKAGE_NAME

このオプションは、スクリプトおよびcronジョブでZypperを使用できます。

6.1.2.5 ソースパッケージのインストールまたはダウンロード

パッケージの対応するソースパッケージをインストールするには、次のコマンドを使用します。

tux > zypper source-install PACKAGE_NAME

ソースパッケージをインストールするデフォルトの場所は、rootとして実行する場合は/usr/src/packages/、ユーザとして実行する場合は~/rpmbuildになります。これらの値はローカルのrpm設定で変更できます。

このコマンドにより、指定したパッケージのビルド依存関係もインストールされます。この処理が必要でない場合は、次のようにスイッチ-Dを追加します。

tux > sudo zypper source-install -D PACKAGE_NAME

ビルドの依存関係のみをインストールするには、-dを使用します。

tux > sudo zypper source-install -d PACKAGE_NAME

もちろん、リポジトリリストで有効にしたソースパッケージを含むリポジトリが存在する場合にのみ動作します(ソースパッケージはデフォルトで追加されますが、有効にはなりません)。リポジトリの管理の詳細については、6.1.5項 「Zypperによるリポジトリの管理」を参照してください。

リポジトリで使用可能なすべてのソースパッケージのリストは、次のコマンドで参照できます。

tux > zypper search -t srcpackage

また、すべてのインストール済みパッケージのソースパッケージをローカルディレクトリにダウンロードすることもできます。ソースパッケージをダウンロードするには、以下を使用します。

tux > zypper source-download

デフォルトのダウンロードディレクトリは/var/cache/zypper/source-downloadです。これは、--directoryオプションを使って変更できます。ダウンロードや削除を行わず、不足パッケージや不要パッケージの表示のみを行う場合は、--statusオプションを使用します。不要なソースパッケージを削除するには、--deleteオプションを使用します。削除を無効にするには、--no-deleteオプションを使用します。

6.1.2.6 無効にされたリポジトリからのパッケージのインストール

通常、パッケージのインストールや更新は、有効化されたリポジトリからしかできません。--plus-content TAGオプションを使用すると、リポジトリをリフレッシュし、現在のZypperセッション中のみ一時的に有効にして、終了したら無効にすることができます。

たとえば、追加の-debuginfoパッケージまたは-debugsourceパッケージを提供するリポジトリを有効にするには、--plus-content debugを使用します。このオプションは複数回指定できます。

そうした「デバッグ」リポジトリを一時的に有効にして、特定の-debuginfoパッケージをインストールするには、次のオプションを使用します。

tux > sudo zypper --plus-content debug \
   install "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4"

debuginfoパッケージがないと、build-id文字列が、gdbによって報告されます。

6.1.2.7 ユーティリティ

すべての依存関係が依然として満たされていることを確認し、欠如する依存関係を修復するには、次のコマンドを使用します。

tux > zypper verify

必要とされる依存関係に加えて、一部のパッケージでは他のパッケージが推奨されます。これらの推奨対象パッケージは、実際に使用可能でインストール可能な場合のみインストールされます。推奨側のパッケージがインストールされた後で、(パッケージまたはハードウェアの追加により)推奨対象パッケージが使用可能になった場合は、次のコマンドを使用します。

tux > sudo zypper install-new-recommends

このコマンドは、WebカメラまたはWi-Fiデバイスを接続した後で非常に役に立ちます。このコマンドは、デバイスのドライバと関連ソフトウェアが利用できる場合には、それらをインストールします。ドライバと関連ソフトウェアは、一定のハードウェア依存関係が満たされている場合のみインストールできます。

6.1.3 Zypperによるソフトウェアの更新

Zypperを使用してソフトウェアを更新するには3つの方法があります。パッチをインストールする、パッケージの新しいバージョンをインストールする、または配布全体を更新する方法です。最後の方法は、zypper dist-upgradeで行うことができます。SUSE Linux Enterprise Serverのアップグレードについては、Book “導入ガイド”, Chapter 19 “SUSE Linux Enterpriseのアップグレード”を参照してください。

6.1.3.1 必要なすべてのパッチのインストール

システムに適用される、正式にリリースされたすべてのパッチをインストールするには、次のコマンドを実行します。

tux > sudo zypper patch

コンピュータに設定されているリポジトリから使用可能なすべてのパッチが、インストール環境に関係があるかどうかが確認されます。関係がある場合(およびoptionalまたはfeatureとして分類されていない場合)、パッチはただちにインストールされます。正式な更新リポジトリはSUSE Linux Enterprise Serverのインストールを登録した後でのみ使用可能であることに注意してください。

インストールするパッチにシステムの再起動が必要な変更が含まれる場合、事前に警告が表示されます。

プレーンのzypper patchコマンドでは、サードパーティリポジトリからのパッチは適用されません。サードパーティリポジトリも更新するには、次のようにwith-updateコマンドオプションを使用します。

tux > sudo zypper patch --with update

オプションのパッチもインストールするには、次のコマンドを使用します。

tux > sudo zypper patch --with-optional

Bugzillaの特定の問題に関連するすべてのパッチをインストールするには、次のコマンドを使用します。

tux > sudo zypper patch --bugzilla=NUMBER

特定のCVEデータベースエントリに関連するすべてのパッチをインストールするには、次のコマンドを使用します。

tux > sudo zypper patch --cve=NUMBER

たとえば、CVE番号がCVE-2010-2713のセキュリティパッチをインストールするには、次のコマンドを実行します。

tux > sudo zypper patch --cve=CVE-2010-2713

Zypperおよびパッケージ管理自体に影響するパッチのみをインストールするには、次のコマンドを使用します。

tux > sudo zypper patch --updatestack-only

updatestack-onlyコマンドオプションを使用する場合、ほかのリポジトリも更新しようとしてそれ以外のコマンドオプションを指定すると、そのコマンドオプションは削除されます。

6.1.3.2 パッチのリストの表示

パッチが使用可能かどうかを確認するため、Zypperでは次の情報を参照できます。

必要なパッチの数

必要なパッチ(システムに適用されるパッチであってもまだインストールされていないもの)の数のリストを表示するには、patch-checkを使用します。

tux > zypper patch-check
Loading repository data...
Reading installed packages...
5 patches needed (1 security patch)

このコマンドを--updatestack-onlyオプションと組み合わせて使用すると、Zypperおよびパッケージ管理自体に影響するパッチのみのリストを表示できます。

必要なパッチのリスト

必要なすべてのパッチ(システムに適用されるパッチであってもまだインストールされていないもの)のリストを表示するには、list-patchesを使用します。

tux > zypper list-patches
Loading repository data...
Reading installed packages...

Repository     | Name        | Version | Category | Status  | Summary
---------------+-------------+---------+----------+---------+---------
SLES12-Updates | SUSE-2014-8 | 1       | security | needed  | openssl: Update for OpenSSL
すべてのパッチのリスト

インストール済みかどうか、およびインストール環境に適用されるかどうかに関係なく、SUSE Linux Enterprise Serverで使用可能なすべてのパッチのリストを表示するには、zypper patchesを使用します。

また、特定の問題に関連するパッチを表示およびインストールすることもできます。特定のパッチを表示するには、次のオプションでzypper list-patchesコマンドを使用します。

Bugzillaの問題によって指定する

Bugzillaの問題に関連する、必要なすべてのパッチのリストを表示するには、オプション--bugzillaを使用します。

特定のバグに対応するパッチのリストを表示するには、--bugzilla=NUMBERのようにバグ番号を指定することもできます。Bugzillaの複数の問題に関連するパッチを検索するには、次の例のように、バグ番号の間にカンマを追加します。

tux > zypper list-patches --bugzilla=972197,956917
CVE番号によって指定する

CVE(Common Vulnerabilities and Exposures)データベースのエントリに関連する、必要なすべてのパッチのリストを表示するには、オプション--cveを使用します。

特定のCVEデータベースエントリに対応するパッチのリストを表示するには、--cve=NUMBERのようにCVE番号を指定することもできます。複数のCVEデータベースエントリに関連するパッチを検索するには、次の例のように、CVE番号の間にカンマを追加します。

tux > zypper list-patches --bugzilla=CVE-2016-2315,CVE-2016-2324

必要かどうかに関係なくすべてのパッチのリストを表示するには、追加でオプション--allを使用します。たとえば、CVE番号が割り当てられたすべてのパッチのリストを表示するには、次のコマンドを使用します。

tux > zypper list-patches --all --cve
Issue | No.           | Patch             | Category    | Severity  | Status
------+---------------+-------------------+-------------+-----------+----------
cve   | CVE-2015-0287 | SUSE-SLE-Module.. | recommended | moderate  | needed
cve   | CVE-2014-3566 | SUSE-SLE-SERVER.. | recommended | moderate  | not needed
[...]

6.1.3.3 新規パッケージパージョンのインストール

リポジトリに新しいパッケージのみが存在し、パッチが提供されていない場合は、zypper patchは無効です。インストールされているパッケージをすべて(システムの整合性を維持しながら)新しく入手可能なバージョンでアップデートするには、次を使用します。

tux > sudo zypper update

個別のパッケージをアップデートするには、updateコマンドまたはinstallコマンドのいずれかでパッケージを指定します。

tux > sudo zypper update PACKAGE_NAME
sudo zypper install PACKAGE_NAME

インストール可能なすべての新しいパッケージのリストを、次のコマンドで取得できます。

tux > zypper list-updates

ただし、このコマンドで表示されるのは、次の条件に一致するパッケージのみです。

  • すでにインストール済みのパッケージと同じベンダである

  • すでにインストール済みのパッケージと同等以上の優先度をもつリポジトリによって提供される

  • インストール可能である(すべての依存関係が満たされている)

次のコマンドを使用すると、(インストール可能かどうかに関わらず)すべての新しい使用可能なパッケージのリストを取得できます。

tux > sudo zypper list-updates --all

新しいパッケージをインストールできない理由を見つけるには、上で説明されているように、zypper installコマンドまたはzypper updateコマンドを使用します。

6.1.3.4 孤立パッケージの特定

Zypperからリポジトリを削除する場合や、システムをアップグレードする場合には、いくつかのパッケージが孤立状態になる可能性があります。これらの孤立パッケージは、どのアクティブなリポジトリにも属していません。次のコマンドで、これらのリストを表示できます。

tux > sudo zypper packages --orphaned

このリストを使用して、パッケージが引き続き必要か、それとも削除しても安全かを判断できます。

6.1.4 削除されたファイルを使用しているプロセスとサービスの特定

パッケージにパッチを適用したり、パッケージを更新または削除したりした場合、更新または削除によって削除されたファイルを引き続き使用している実行中のプロセスがシステムに存在することがあります。削除されたファイルを使用しているプロセスのリストを表示するには、zypper psを使用します。プロセスが既知のサービスに属している場合は、サービス名のリストが表示され、そのサービスを容易に再起動できます。デフォルトでは、zypper psは次のような表を表示します。

tux > zypper ps
PID   | PPID | UID | User  | Command      | Service      | Files
------+------+-----+-------+--------------+--------------+-------------------
814   | 1    | 481 | avahi | avahi-daemon | avahi-daemon | /lib64/ld-2.19.s->
      |      |     |       |              |              | /lib64/libdl-2.1->
      |      |     |       |              |              | /lib64/libpthrea->
      |      |     |       |              |              | /lib64/libc-2.19->
[...]
PID: プロセスのID
PPID: 親プロセスのID
UID: プロセスを実行しているユーザのID
Login: プロセスを実行しているユーザのログイン名
Command: プロセスの実行に使用されたコマンド
Service: サービス名(コマンドがシステムサービスに関連付けられている場合のみ)
Files: 削除されたファイルのリスト

次のように指定することで、zypper psの出力フォーマットを制御できます。

zypper ps-s

削除されたファイルを表示しない短い表を作成します。

tux > zypper ps -s
PID   | PPID | UID  | User    | Command      | Service
------+------+------+---------+--------------+--------------
814   | 1    | 481  | avahi   | avahi-daemon | avahi-daemon
817   | 1    | 0    | root    | irqbalance   | irqbalance
1567  | 1    | 0    | root    | sshd         | sshd
1761  | 1    | 0    | root    | master       | postfix
1764  | 1761 | 51   | postfix | pickup       | postfix
1765  | 1761 | 51   | postfix | qmgr         | postfix
2031  | 2027 | 1000 | tux     | bash         |
zypper ps-ss

システムサービスに関連付けられているプロセスのみを表示します。

PID   | PPID | UID  | User    | Command      | Service
------+------+------+---------+--------------+--------------
814   | 1    | 481  | avahi   | avahi-daemon | avahi-daemon
817   | 1    | 0    | root    | irqbalance   | irqbalance
1567  | 1    | 0    | root    | sshd         | sshd
1761  | 1    | 0    | root    | master       | postfix
1764  | 1761 | 51   | postfix | pickup       | postfix
1765  | 1761 | 51   | postfix | qmgr         | postfix
zypper ps-sss

削除されたファイルを使用しているシステムサービスのみを表示します。

avahi-daemon
irqbalance
postfix
sshd
zypper ps--print "systemctl status %s"

再起動が必要な可能性があるサービスのステータス情報を取得するコマンドを表示します。

systemctl status avahi-daemon
systemctl status irqbalance
systemctl status postfix
systemctl status sshd

サービスの処理の詳細については、第13章 「systemdデーモンを参照してください。

6.1.5 Zypperによるリポジトリの管理

Zypperのすべてのインストールまたはパッチのコマンドは、既知のリポジトリのリストに応じて異なります。システムで既知のすべてのリポジトリのリストを表示するには、次のコマンドを使用します。

tux > zypper repos

結果は、次の出力のようになります。

例 6.1: Zypper—既知のリポジトリのリスト
tux > zypper repos
# | Alias        | Name          | Enabled | Refresh
--+--------------+---------------+---------+--------
1 | SLEHA-12-GEO | SLEHA-12-GEO  | Yes     | No
2 | SLEHA-12     | SLEHA-12      | Yes     | No
3 | SLES12       | SLES12        | Yes     | No

各種コマンドのリポジトリを指定するには、エイリアス、URI、またはリポジトリ番号をzypper reposコマンド出力から使用できます。リポジトリの別名は、リポジトリ操作コマンド用の短いリポジトリ名です。ただし、リポジトリリストの変更後に、リポジトリ番号が変わる可能性があります。エイリアスは変更されることはありません。

デフォルトでは、URIやリポジトリの優先度など、詳細情報は表示されません。すべての詳細を表示するには、次のコマンドを使用します。

tux > zypper repos -d

6.1.5.1 リポジトリの追加

リポジトリを追加するには、次を実行します。

tux > sudo zypper addrepo URI ALIAS

URIは、インターネットリポジトリ、ネットワークリソース、ディレクトリ、CDまたはDVDのいずれかです(詳細については、http://en.opensuse.org/openSUSE:Libzypp_URIsを参照してください)。ALIASは、リポジトリの短い固有のIDです。このIDは、固有である必要があること以外は自由に選択できます。すでに使用されているエイリアスを指定した場合、Zypperでは警告が発行されます。

6.1.5.2 リポジトリの更新

zypperは、設定されているリポジトリからパッケージの変更点をフェッチできます。変更点をフェッチするには、次のコマンドを実行します。

tux > sudo zypper refresh
注記
注記: zypperのデフォルトの動作

一部のコマンドではデフォルトでrefreshが自動的に実行されるため、ユーザがこのコマンドを明示的に実行する必要はありません。

refreshコマンドと--plus-contentオプションを使用すると、無効になっているリポジトリ内の変更点も表示できます。

tux > sudo zypper --plus-content refresh

このオプションは、リポジトリ内の変更点をフェッチしますが、無効になっているリポジトリは同じ状態(無効)のままにします。

6.1.5.3 リポジトリの削除

リストからリポジトリを削除するには、コマンドzypper removerepoを使用し、削除するリポジトリのエイリアスまたは番号を指定します。たとえば、例6.1「Zypper—既知のリポジトリのリスト」からSLEHA-12-GEOリポジトリを削除するには、次のコマンドのいずれかを使用します。

tux > sudo zypper removerepo 1
tux > sudo zypper removerepo "SLEHA-12-GEO"

6.1.5.4 リポジトリの変更

zypper modifyrepoによりリポジトリを有効または無効にします。また、このコマンドにより、リポジトリのプロパティ(動作、名前、優先度の更新など)を変更できます。次のコマンドは、updatesという名前のリポジトリを有効にし、自動更新をオンにし、リポジトリの優先度を 20に設定します。

tux > sudo zypper modifyrepo -er -p 20 'updates'

リポジトリを変更する場合、1つのリポジトリだけなく、リポジトリのグループも操作できます。

-a: すべてのリポジトリ
-l: ローカルリポジトリ
-t: リモートリポジトリ
-m タイプ:特定のタイプのリポジトリ(ここで、タイプには、次のいずれかを指定できます: httphttpsftpcddvddirfilecifssmbnfshdiso)

リポジトリエイリアスの名前を変更するには、renamerepoコマンドを使用します。次の例では、エイリアスをMozilla Firefoxからfirefoxに変更しています。

tux > sudo zypper renamerepo 'Mozilla Firefox' firefox

6.1.6 Zypperによるリポジトリおよびパッケージのクエリ

Zypperでは、リポジトリまたはパッケージをクエリするためのさまざまな方法が提供されています。使用可能なすべての製品、パターン、パッケージ、またはパッチのリストを取得するには、次のコマンドを使用します。

tux > zypper products
tux > zypper patterns
tux > zypper packages
tux > zypper patches

特定のパッケージについてすべてのリポジトリをクエリするには、searchを使用します。特定のパッケージに関する情報を取得するには、infoコマンドを使用します。

6.1.6.1 zypper searchの使用法

zypper searchコマンドは、パッケージ名に対して機能し、オプションでパッケージの概要と説明に対しても機能します。/でラップされた文字列は、正規表現として解釈されます。デフォルトでは、検索で大文字と小文字は区別されません。

fireを含むパッケージ名の単純な検索
tux > zypper search "fire"
正確なパッケージMozillaFirefoxの単純な検索
tux > zypper search --match-exact "MozillaFirefox"
パッケージの説明とサマリも検索
tux > zypper search -d fire
まだインストールしていないパッケージのみ表示
tux > zypper search -u fire
文字列firを含み、この後にeが続かないパッケージの表示
tux > zypper se "/fir[^e]/"

6.1.6.2 zypper what-providesの使用法

特定の機能を提供するパッケージを検索するには、コマンドwhat-providesを使用します。たとえば、どのパッケージがPerlモジュールSVN::Coreを提供するか確認したい場合は、次のコマンドを使用します。

tux > zypper what-provides 'perl(SVN::Core)'

what-provides PACKAGE_NAMErpm -q --whatprovides PACKAGE_NAMEに似ていますが、RPMではRPMデータベース(つまり、すべてのインストール済みパッケージのデータベース)のみを問い合わせることができます。それに対してZypperは、インストール済みのパッケージだけでなく、すべてのリポジトリから機能のプロバイダに関する情報を表示します。

6.1.6.3 zypper infoの使用法

単一のパッケージをクエリするには、infoを使用し、引数として正確なパッケージ名を指定します。パッケージに関する詳細情報を表示します。パッケージ名がリポジトリのどのパッケージ名にも一致しない場合は、パッケージ以外に一致するものの詳細情報を出力します。特定のタイプを要求して(-tオプションを使用)、そのタイプが存在しない場合は、使用可能なほかの一致を出力しますが、詳細な情報は出力しません。

ソースパッケージを指定した場合、そのソースパッケージからビルドされたバイナリパッケージを表示します。バイナリパッケージを指定した場合、そのバイナリパッケージをビルドするために使用されたソースパッケージを出力します。

パッケージの要求や推奨も表示するには、--requiresオプションや--recommendsオプションを使用します。

tux > zypper info --requires MozillaFirefox

6.1.7 Zypperの設定

Zypperには、現在、設定ファイルが付属しています。この設定ファイルを使用すれば、Zypperの動作を(システム全体またはユーザ固有のでどちらかで)永続的に変更できます。システム全体に渡って変更する場合は、/etc/zypp/zypper.confを編集します。ユーザ固有に変更する場合は、~/.zypper.confを編集します。~/.zypper.confがまだ存在していない場合は、テンプレートとして/etc/zypp/zypper.confを使用できます。このテンプレートを~/.zypper.confにコピーして、好みに合わせて調整してください。利用できるオプションのヘルプについては、ファイル内のコメントを参照してください。

6.1.8 トラブルシューティング

設定済みのリポジトリからのパッケージへのアクセスに問題がある場合(たとえば、特定のパッケージがリポジトリの1つに存在することを知っていても、Zypperでそのパッケージを見つけられない場合など)は、次のコマンドでリポジトリを更新すると有効なことがあります。

tux > sudo zypper refresh

それも役に立たない場合は、次のコマンドを試してください。

tux > sudo zypper refresh -fdb

このコマンドは、生メタデータの強制ダウンロードを含むデータベースの完全な更新と再構築を強制します。

6.1.9 BtrfsファイルシステムでのZypperロールバック機能

ルートパーティションでBtrfsファイルシステムが使用され、snapperがインストールされている場合に、ファイルシステムに対する変更をコミットして適切なファイルシステムスナップショットを作成すると、Zypperは自動的にsnapperを呼び出します。これらのスナップショットは、Zypperによって行われた変更を元に戻す場合に使用できます。詳細については、第7章 「Snapperを使用したシステムの回復とスナップショット管理を参照してください。

6.1.10 その他の情報

コマンドラインからのソフトウェア管理の詳細については、「zypper help」、「zypper help  COMMAND」と入力するか、zypper(8)のマニュアルページを参照してください。詳しいコマンドリファレンス、最も重要なコマンドの早見表、およびスクリプトやアプリケーションにおけるZypperの詳しい使い方については、http://en.opensuse.org/SDB:Zypper_usageを参照してください。SUSE Linux Enterprise Serverの最新バージョンにおけるソフトウェアの変更点のリストについては、http://en.opensuse.org/openSUSE:Zypper versionsを参照してください。

6.2 RPM—パッケージマネージャ

RPM (RPM Package Manager)がソフトウェアパッケージを管理するのに使用されます。RPMの主要コマンドは、rpmrpmbuildです。ユーザ、システム管理者、およびパッケージの作成者は、強力なRPMデータベースでクエリーを行って、インストールされているソフトウェアに関する情報を取得できます。

基本的にrpmには、ソフトウェアパッケージのインストール、アンインストール、アップデート、RPMデータベースの再構築、RPMベースまたは個別のRPMアーカイブの照会、パッケージの整合性チェック、およびパッケージへの署名の5種類のモードがあります。rpmbuildは、元のソースからインストール可能なパッケージを作成する場合に使用します。

インストール可能なRPMアーカイブは、特殊なバイナリ形式でパックされています。それらのアーカイブは、インストールするプログラムファイルとある種のメタ情報で構成されます。メタ情報は、ソフトウェアパッケージを設定するためにrpmによってインストール時に使用されるか、または文書化の目的でRPMデータベースに格納されています。通常、RPMアーカイブには拡張子.rpmが付けられます。

ヒント
ヒント: ソフトウェア開発パッケージ

多くのパッケージにおいて、ソフトウェア開発に必要なコンポーネント(ライブラリ、ヘッダ、インクルードファイルなど)は、別々のパッケージに入れられています。それらの開発パッケージは、最新のGNOMEパッケージのように、ソフトウェアを自分自身でコンパイルする場合にのみ、必要になります。それらのパッケージは、名前の拡張子-deveで識別できます(alsa-develパッケージ、gimp-develパッケージなど)。

6.2.1 パッケージの信頼性の検証

RPMパッケージにはGPG署名があります。RPMパッケージの署名を検証するには、rpm --checksig  PACKAGE-1.2.3.rpmコマンドを使用して、SUSEまたはその他の信頼できるツールから送信されたパッケージかどうか判別します。これは、インターネットからアップデートパッケージを入手する場合には、特に推奨されます。

オペレーティングシステムの問題を修復する場合、暫定修正(PTF)を実動システムにインストールしなければならない場合があります。SUSEから提供されるパッケージは、特別なPTFキーに照らして署名されています。ただし、SUSE Linux Enterprise 11と異なり、SUSE Linux Enterprise 12システムでは、このキーはデフォルトでインポートされません。キーを手動でインポートするには、次のコマンドを使用します。

tux > sudo rpm --import \
/usr/share/doc/packages/suse-build-key/suse_ptf_key.asc

キーをインポートしたら、PTFパッケージをシステムにインストールできます。

6.2.2 パッケージの管理:インストール、アップデート、およびアンインストール

通常RPMアーカイブのインストールはとても簡単です。「rpm -i PACKAGE.rpm」のように入力します。このコマンドで、パッケージをインストールできます。ただし、依存関係が満たされており、他のパッケージとの競合がない場合に限られます。rpmでは、依存関係の要件を満たすためにインストールしなければならないパッケージがエラーメッセージで要求されます。バックグラウンドで、RPMデータベースは競合が起きないようにします。ある特定のファイルは、1つのパッケージだけにしか属せません。別のオプションを選択すると、rpmにこれらのデフォルト値を無視させることができますが、この処置を行うのは専門知識のある人に限られます。それ以外の人が行うと、システムの整合性を危うくするリスクが発生し、システムアップデート機能が損なわれる可能性があります。

-Uまたは--upgrade-Fまたは--freshenの各オプションは、パッケージをアップデートするのに使用できます(たとえば、rpm -F PACKAGE.rpm)。このコマンドは、古いバージョンのファイルを削除し、新しいファイルをただちにインストールします。2つのバージョン間の違いは、-Uがシステムに存在していなかったパッケージをインストールするのに対して、-Fがインストールされていたパッケージを単にアップデートする点にあります。アップデートする際、rpmは、以下のストラテジーに基づいて設定ファイルを注意深くアップデートします。

  • 設定ファイルがシステム管理者によって変更されていない場合、rpmは新しいバージョンの適切なファイルをインストールします。システム管理者は、何も行う必要はありません。

  • アップデート前にシステム管理者が環境設定ファイルを変更した場合、rpmは拡張子.rpmorigまたは.rpmsave(バックアップファイル)で変更されたファイルを保存し、新しいパッケージからバージョンをインストールします。これは、最初にインストールされたファイルと新しいバージョンが異なる場合にのみ実行されます。異なる場合は、バックアップファイル(.rpmorigまたは.rpmsave)と新たにインストールされたファイルを比較して、新しいファイルに再度、変更を加えます。後ですべての.rpmorig.rpmsaveファイルを削除して、今後のアップデートで問題が起きないようにします。

  • 設定ファイルがすでに存在しており、またnoreplaceラベルが.specファイルで指定されている場合、.rpmnewファイルが作成されます。

アップデートが終了したら、.rpmsaveファイルと.rpmnewファイルは、比較した後、将来のアップデートの妨げにならないように削除する必要があります。ファイルがRPMデータベースで認識されなかった場合、ファイルには拡張子.rpmorigが付けられます。

認識された場合には、.rpmsaveが付けられます。言い換えれば、.rpmorigは、RPM以外の形式からRPMにアップデートした結果として付けられます。.rpmsaveは、古いRPMから新しいRPMにアップデートした結果として付けられます。.rpmnewは、システム管理者が設定ファイルに変更を加えたかどうかについて、何の情報も提供しません。それらのファイルのリストは、/var/adm/rpmconfigcheckにあります。設定ファイルの中には(/etc/httpd/httpd.confなど)、操作が継続できるように上書きされないものがあります。

-Uスイッチは、単に-eオプションでアンインストールして、-iオプションでインストールする操作と同じではありません可能なときは必ず-Uを使用します。

パッケージを削除するには、「rpm -e PACKAGE」と入力します。」と入力します。解決されていない依存関係がない場合にパッケージのみを削除します。他のアプリケーションがTcl/Tkを必要とする限り、Tcl/Tkを削除することは理論的に不可能です。その場合でも、RPMはデータベースに援助を要求します。他の依存関係がない場合でも、また、どのような理由があってもそのような削除が不可能であれば、--rebuilddbオプションを使用してRPMデータベースを再構築するのがよいでしょう。

6.2.3 デルタRPMパッケージ

デルタRPMパッケージには、RPMパッケージの新旧バージョン間の違いが含まれています。デルタRPMを古いRPMに適用すると、まったく新しいRPMになります。デルタRPMは、インストールされているRPMとも互換性があるので、古いRPMのコピーを保管する必要はありません。デルタRPMパッケージは、パッチRPMよりもさらに小さく、パッケージをインターネット上で転送するのに便利です。欠点は、デルタRPMが組み込まれたアップデート操作の場合、そのままのRPMまたはパッチRPMに比べて、CPUサイクルの消費が目立って多くなることです。

prepdeltarpmおよびapplydeltaバイナリは、デルタRPMスイート(deltarpmパッケージ)の一部であり、デルタRPMパッケージの作成と適用に際して役立ちます。次のコマンドを使用して、new.delta.rpmというデルタRPMを作成できます。次のコマンドでは、old.rpmおよびnew.rpmが存在することが前提となります。

tux > sudo makedeltarpm old.rpm new.rpm new.delta.rpm

古いパッケージがすでにインストールされていれば、applydeltarpmを使用して、ファイルシステムから新たにRPMを構築できます。

tux > sudo applydeltarpm new.delta.rpm new.rpm

ファイルシステムにアクセスすることなく、古いRPMから構築するには、-rオプションを使用します。

tux > sudo applydeltarpm -r old.rpm new.delta.rpm new.rpm

技術的な詳細については、/usr/share/doc/packages/deltarpm/READMEを参照してください。

6.2.4 RPMクエリー

-qオプションを使用すると、rpmはクエリを開始し、(-pオプションを追加することにより)RPMアーカイブを検査できるようにして、インストールされたパッケージのRPMデータベースでクエリを行えるようにします。必要な情報の種類を指定する複数のスイッチを使用できます。詳細については、表6.1「最も重要なRPMクエリーのオプション」を参照してください。

表 6.1: 最も重要なRPMクエリーのオプション

-i

パッケージ情報

-l

ファイルリスト

-f FILE

ファイルFILEを含むパッケージでクエリーを行います(FILEにはフルパスを指定する必要があります)。

-s

ステータス情報を含むファイルリスト(-lを暗示指定)

-d

ドキュメントファイルだけをリストします (-lを暗示指定)。

-c

設定ファイルだけをリストします(-lを暗示指定)。

--dump

詳細情報を含むファイルリスト(-l-c、または-d と共に使用します)

--provides

他のパッケージが--requiresで要求できるパッケージの機能をリストします。

--requires, -R

パッケージが要求する機能

--scripts

インストールスクリプト(preinstall、postinstall、uninstall)

たとえば、コマンドrpm -q -i wgetは、例6.2「rpm -q -i wgetに示された情報を表示します。

例 6.2: rpm -q -i wget
Name        : wget
Version     : 1.14
Release     : 17.1
Architecture: x86_64
Install Date: Mon 30 Jan 2017 14:01:29 CET
Group       : Productivity/Networking/Web/Utilities
Size        : 2046483
License     : GPL-3.0+
Signature   : RSA/SHA256, Thu 08 Dec 2016 07:48:44 CET, Key ID 70af9e8139db7c82
Source RPM  : wget-1.14-17.1.src.rpm
Build Date  : Thu 08 Dec 2016 07:48:34 CET
Build Host  : sheep09
Relocations : (not relocatable)
Packager    : https://www.suse.com/
Vendor      : SUSE LLC <https://www.suse.com/>
URL         : http://www.gnu.org/software/wget/
Summary     : A Tool for Mirroring FTP and HTTP Servers
Description :
Wget enables you to retrieve WWW documents or FTP files from a server.
This can be done in script files or via the command line.
Distribution: SUSE Linux Enterprise 12

オプション-fが機能するのは、フルパスで完全なファイル名を指定した場合だけです。必要な数のファイル名を指定します。次に例を示します。

tux > rpm -q -f /bin/rpm /usr/bin/wget
rpm-4.11.2-15.1.x86_64
wget-1.14-17.1.x86_64

ファイル名の一部分しかわからない場合は、例6.3「パッケージを検索するスクリプト」に示すようなシェルスクリプトを使用します。実行するときに、ファイル名の一部を、パラメータとして示されるスクリプトに渡します。

例 6.3: パッケージを検索するスクリプト
#! /bin/sh
for i in $(rpm -q -a -l | grep $1); do
    echo "\"$i\" is in package:"
    rpm -q -f $i
    echo ""
done

rpm -q --changelog PACKAGEコマンドは、特定のパッケージに関する詳細な変更情報を日付順に表示します。

インストールされたRPMデータベースを使うと、確認検査を行うことができます。それらの検査は、-Vまたは--verifyオプションを使用して開始します。このオプションを使うと、rpmは、パッケージ内にあり、インストール以降変更されたことがあるすべてのファイルを表示します。rpmは、次の変更に関するヒントを表示するのに、8文字の記号を使用します。

表 6.2: RPM確認オプション

5

MD5チェックサム

S

ファイルサイズ

L

シンボリックリンク

T

変更時間

D

メジャーデバイス番号とマイナーデバイス番号

U

所有者

G

グループ

M

モード (許可とファイルタイプ)

設定ファイルの場合は、文字cが表示されます。/etc/wgetrc (wgetパッケージ)の変更例を以下に示します。

tux > rpm -V wget
S.5....T c /etc/wgetrc

RPMデータベースのファイルは、/var/lib/rpmに格納されています。パーティション/usrのサイズが 1 GBであれば、このデータベースは、完全なアップデート後、およそ 30 MB占有します。データベースが予期していたよりもはるかに大きい場合は、オプション--rebuilddbでデータベースを再構築するようにします。再構築する前に、古いデータベースのバックアップを作成しておきます。cronスクリプトのcron.dailyは、データベースのコピー(gzip でパックされる)を毎日作成し、/var/adm/backup/rpmdbに格納します。コピー数は/etc/sysconfig/backupにある変数MAX_RPMDB_BACKUPSで制御します(デフォルト:5)。1つのバックアップのサイズは、1GBの/usrに対しておよそ1MBです。

6.2.5 ソースパッケージのインストールとコンパイル

すべてのソースパッケージには、拡張子.src.rpm (ソース RPM)が付けられています。

注記
注記: インストール済みのソースパッケージ

ソースパッケージは、インストールメディアからハードディスクにコピーされ、YaSTを使用して展開できます。ただし、ソースパッケージは、パッケージマネージャでインストール済み([i])というマークは付きません。これは、ソースパッケージがRPMデータベースに入れられないためです。インストールされたオペレーティングシステムソフトウェアだけがRPMデータベースにリストされます。ソースパッケージをインストールする場合、ソースコードだけがシステムに追加されます。

(/etc/rpmrcなどのファイルでカスタム設定を指定していない限り)以下のディレクトリが、/usr/src/packagesの下でrpmrpmbuildから使用可能でなければなりません。

SOURCES

オリジナルのソース(.tar.gzファイルや.tar.gzファイルなど)とディストリビューション固有の調整ファイル(ほとんどの場合.difファイルや.patchファイル)用です。

SPECS

ビルド処理 を制御する、メタMakefileに類似した.specファイル用です。

BUILD

すべてのソースは、このディレクトリでアンパック、パッチ、およびコンパイルされます。

RPMS

完成したバイナリパッケージが格納されます。

SRPMS

ソースRPMが格納されます。

YaSTでソースパッケージをインストールすると、必要なコンポーネントがすべて/usr/src/packagesにインストールされます。 SOURCES内のソースおよび調整ファイルとSPECS内の関連.specファイルです。

警告
警告: システムの整合性

システムコンポーネント(glibcrpmなど)で実験を行わないでください。システムが正しく動作しなくなります。

次の例は、wget.src.rpmパッケージを使用します。ソースパッケージをインストールすると、次のようなファイルが生成されます。

/usr/src/packages/SOURCES/wget-1.11.4.tar.bz2
/usr/src/packages/SOURCES/wgetrc.patch
/usr/src/packages/SPECS/wget.spec

rpmbuild -bX /usr/src/packages/SPECS/wget.specコマンドは、コンパイルを開始します。Xは、ビルド処理のさまざまな段階に対して使用されるワイルドカードです(詳細については、--helpの出力またはRPMのドキュメントを参照してください)。以下に簡単な説明を示します。

-bp

/usr/src/packages/BUILD内のソースを用意します。アンパック、パッチしてください。

-bc

-bpと同じですが、コンパイルを実行します。

-bi

-bpと同じですが、ビルドしたソフトウェアをインストールします。警告:パッケージがBuildRoot機能をサポートしていない場合は、設定ファイルが上書きされることがあります。

-bb

-biと同じですが、バイナリパッケージを作成します。コンパイルに成功すると、バイナリパッケージは、/usr/src/packages/RPMSに作成されるはずです。

-ba

-bbと同じですが、ソース RPMを作成します。コンパイルに成功すると、バイナリは/usr/src/packages/SRPMSに作成されるはずです。

--short-circuit

一部のステップをスキップします。

作成されたバイナリRPMは、rpm -iコマンドまたはrpm -Uコマンドでインストールできます。rpmを使用したインストールは、RPMデータベースに登場します。

specファイルのBuildRootディレクティブは、SUSE Linux Enterprise Server 12以降は非推奨です。この機能がまだ必要な場合は、回避方法として--buildrootオプションを使用してください。背景についての詳細は、https://www.suse.com/support/kb/doc?id=7017104にあるSupprt Database(サポートデータベース)を参照してください。

6.2.6 buildによるRPMパッケージのコンパイル

多くのパッケージにつきものの不都合は、ビルド処理中に不要なファイルが稼働中のシステムに追加されてしまうことです。これを回避するには、パッケージのビルド先の定義済みの環境を作成するbuildを使用します。このchroot環境を確立するには、build スクリプトが完全なパッケージツリーと共に提供されなければなりません。パッケージツリーは、NFS経由で、またはDVDから ハードディスク上で利用できるようにすることができます。build --rpms DIRECTORYで、位置を指定します。rpmと異なり、buildコマンドは、ソースディレクトリで.specファイルを検索します。/media/dvdの下でシステムにマウントされているDVDを使用して(上記の例と同様に)wgetをビルドするには、次のコマンドをrootとして使用します。

root # cd /usr/src/packages/SOURCES/
root # mv ../SPECS/wget.spec .
root # build --rpms /media/dvd/suse/ wget.spec

これで、最小限の環境が/var/tmp/build-rootに確立されます。パッケージは、この環境でビルドされます。処理が完了すると、ビルドされたパッケージは/var/tmp/build-root/usr/src/packages/RPMSに格納されます。

buildスクリプトでは、他のオプションも多数使用できます。たとえば、スクリプトがユーザ独自のRPMを処理するようにするには、ビルド環境の初期化を省略するか、rpmコマンドの実行を上記のビルド段階のいずれかに制限します。build --helpコマンドとman buildコマンドで、詳細な情報が得られます。

6.2.7 RPMアーカイブとRPMデータベース用のツール

Midnight Commander (mc)は、RPMアーカイブの内容を表示し、それらの一部をコピーできます。アーカイブを仮想ファイルシステムとして表し、Midnight Commanderの通常のメニューオプションを使用できます。F3キーを使用してHEADERを表示します。カーソルキーとEnterキーを使ってアーカイブ構造を表示します。F5キーを使用してアーカイブコンポーネントをコピーします。

フル機能のパッケージマネージャをYaSTモジュールとして使用できます詳細については、Book “導入ガイド”, Chapter 13 “ソフトウェアをインストールまたは削除する”を参照してください。

7 Snapperを使用したシステムの回復とスナップショット管理

概要

Linuxでファイルシステムのスナップショットを作成し、ロールバックできるようにすることは、過去に要望の多かった機能です。Snapperを、BtrfsファイルシステムまたはシンプロビジョンのLVMボリュームと併用することによって、それに対応できます。

Btrfsは、Linux用の新しい書き込み時コピー方式のファイルシステムで、サブボリューム(各物理パーティション内の1つまたは複数の個別にマウント可能なファイルシステム)のファイルシステムスナップショット(特定時点におけるサブボリュームの状態のコピー)をサポートします。スナップショットは、XFS、Ext4、またはExt3でフォーマットされたシンプロビジョンLVMボリュームでもサポートされています。Snapperを使用してこれらのスナップショットを作成および管理できます。Snapperには、コマンドラインおよびYaSTインタフェースがあります。SUSE Linux Enterprise Serverバージョン 12から、Btrfsスナップショットからブートすることもできるようになりました。詳細については、7.3項 「スナップショットからのブートによるシステムロールバック」を参照してください。

Snapperを使用して、次のタスクを実行できます。

7.1 デフォルト設定

SUSE Linux Enterprise Server上のSnapperは、システム変更の取り消しおよび回復ツールとして機能するように設定されています。デフォルトでは、SUSE Linux Enterprise Serverのルートパーティション(/)はBtrfsでフォーマットされています。ルートパーティション(/)に十分な容量(約16GB以上)がある場合、スナップショットの作成が自動的に有効になります。デフォルトでは、/以外のパーティション上でスナップショットを作成することはできません。

ヒント
ヒント: インストール済みシステムでのSnapperの有効化

インストール中にSnapperを無効にした場合、後からいつでも有効にできます。そのためには、次のコマンドを実行して、ルートファイルシステムのデフォルトのSnapper設定を作成します。

tux > sudo snapper -c root create-config /

その後、7.1.3.1項 「スナップショットの無効化/有効化」の説明に従って、別のスナップショットタイプを有効にします。

スナップショットには、インストーラの推奨に従ってサブボリュームが設定されたBtrfsルートファイルシステムと、16GB以上のパーティションサイズが必要であることに注意してください。

スナップショットを作成すると、スナップショットとスナップショット元のファイルは、 いずれもファイルシステム内の同じブロックを指します。そのため、最初は、スナップショットが余分にディスク容量を占めることはありません。元のファイルシステムのデータが変更されると、変更されたデータブロックがコピーされ、古いデータブロックはスナップショットのように保持されます。このため、スナップショットは、変更されたデータと同じ容量を占めます。こうして、時間が経過するにつれて、スナップショットの領域は大きくなっていきます。その結果、スナップショットを含むBtrfsファイルシステムからファイルを削除しても、ディスクの空き容量が増えないことがあります。

注記
注記: スナップショットの場所

スナップショットは常に、スナップショット作成元と同じパーティションまたはサブボリュームに保存されます。別のパーティションまたはサブボリュームにスナップショットを保存することはできません。

その結果、スナップショットを含むパーティションは、通常のパーティションよりも大きくする必要があります。具体的な容量は、保持するスナップショット数やデータの変更頻度によって異なります。一般的には、通常のファイルシステムの2倍程度を検討してください。ディスク容量が不足しないようにするために、古いスナップショットは自動的にクリーンアップされます。詳細については、7.1.3.4項 「スナップショットのアーカイブの制御」を参照してください。

7.1.1 スナップショットのタイプ

スナップショット自体は技術的な意味では同じですが、トリガするイベントに基づいて、次の3種類のスナップショットを区別しています。

タイムラインスナップショット

1時間ごとに1つのスナップショットが作成されます。古いスナップショットは自動的に削除されます。デフォルトで、最近10日間、10カ月間、10年間の最初のスナップショットが保持されます。タイムラインスナップショットはデフォルトで無効になっています。

インストールスナップショット

YaSTまたはZypperで1つ以上のパッケージをインストールする場合、常にスナップショットのペアが作成されます。インストール開始前のスナップショット(事前)と、インストール完了後のスナップショット(事後)です。カーネルなどの重要なコンポーネントがインストールされた場合、スナップショットのペアは重要とマークされます(important=yes)。古いスナップショットは自動的に削除されます。デフォルトでは、最新の10個の重要なスナップショット、および最新の10個の通常のスナップショット(管理スナップショットを含む)が保持されます。インストールスナップショットはデフォルトで有効になっています。

管理スナップショット

システムをYaSTで管理する場合、常にスナップショットのペアが作成されます。YaSTモジュール開始時のスナップショット(事前)と、モジュール終了時のスナップショット(事後)です。古いスナップショットは自動的に削除されます。デフォルトでは、最新の10個の重要なスナップショットと最新の10個の通常のスナップショット(インストールスナップショットを含む)が保持されます。管理スナップショットはデフォルトで有効になっています。

7.1.2 スナップショットから除外されるディレクトリ

一部のディレクトリは、さまざまな理由により、スナップショットから除外する必要があります。次のリストは、除外されるすべてのディレクトリを示しています。

/boot/grub2/i386-pc/boot/grub2/x86_64-efi/boot/grub2/powerpc-ieee1275/boot/grub2/s390x-emu

ブートローダ設定のロールバックはサポートされていません。これらのディレクトリは、アーキテクチャ固有です。最初の2つのディレクトリはAMD64/Intel 64マシン上に存在し、その後の2つのディレクトリはそれぞれIBM POWERとIBM z Systems上に存在します。

/home

/homeが独立したパーティションに存在していない場合、ロールバック時にデータが失われのを避けるために除外されます。

/opt/var/opt

サードパーティ製品は通常、/optにインストールされます。ロールバック時にこれらのアプリケーションがアンインストールされるのを避けるために除外されます。

/srv

WebおよびFTPサーバ用のデータが含まれています。ロールバック時にデータが失われるのを避けるために除外されます。

/tmp/var/tmp/var/cache/var/crash

スナップショットから除外される一時ファイルとキャッシュを含むすべてのディレクトリ。

/usr/local

このディレクトリは、ソフトウェアの手動インストール時に使用します。ロールバック時にこれらのインストール済みソフトウェアがアンインストールされるのを避けるために除外されます。

/var/lib/libvirt/images

libvirtで管理される仮想マシンイメージのデフォルトの場所。ロールバック時に仮想マシンイメージが古いバージョンに置き換えられないようにするために除外されます。デフォルトでは、このサブボリュームは、no copy on writeオプションを使用して作成されます。

/var/lib/mailman/var/spool

電子メールまたは電子メールキューを含むディレクトリは、ロールバック後に電子メールが失われるのを避けるために除外されます。

/var/lib/named

DNSサーバ用のゾーンデータが含まれます。ネームサーバがロールバック後に確実に動作できるように、スナップショットから除外されます。

/var/lib/mariadb/var/lib/mysql/var/lib/pgqsl

これらのディレクトリにはデータベースのデータが格納されます。デフォルトでは、このサブボリュームは、no copy on writeオプションを使用して作成されます。

/var/log

ログファイルの場所。壊れたシステムのロールバック後にログファイルを分析できるようにスナップショットから除外されます。

7.1.3 設定のカスタマイズ

SUSE Linux Enterprise Serverには、適切なデフォルト設定が付属していて、ほとんどの使用事例ではこのままで十分です。ただし、スナップショットの自動作成およびスナップショットの維持管理のあらゆる側面をニーズに合わせて設定できます。

7.1.3.1 スナップショットの無効化/有効化

3つのスナップショットの種類(タイムライン、インストール、および管理)はそれぞれ独立して有効化または無効化することができます。

タイムラインスナップショットの有効化/無効化

有効化:  snapper-c root set-config "TIMELINE_CREATE=yes"

無効化:  snapper -c root set-config "TIMELINE_CREATE=no"

タイムラインスナップショットは、ルートパーティションを除きデフォルトで有効になっています。

インストールスナップショットの有効化/無効化

有効化:  snapper-zypp-pluginパッケージをインストールします。

無効化:  snapper-zypp-pluginパッケージをアンインストールします。

インストールスナップショットはデフォルトで有効になっています。

管理スナップショットの有効化/無効化

有効化:  /etc/sysconfig/yast2USE_SNAPPERyes (はい)に設定します。

無効化:  /etc/sysconfig/yast2USE_SNAPPERno (いいえ)に設定します。

管理スナップショットはデフォルトで有効になっています。

7.1.3.2 インストールスナップショットの制御

YaSTまたはZypperでパッケージをインストールする際にスナップショットペアを作成する処理は、snapper-zypp-pluginが扱います。XML環境設定ファイル/etc/snapper/zypp-plugin.confで、スナップショットを作成するタイミングを定義します。デフォルトでは、ファイルは次のようになっています。

 1 <?xml version="1.0" encoding="utf-8"?>
 2 <snapper-zypp-plugin-conf>
 3  <solvables>
 4   <solvable match="w"1 important="true"2>kernel-*3</solvable>
 5   <solvable match="w" important="true">dracut</solvable>
 6   <solvable match="w" important="true">glibc</solvable>
 7   <solvable match="w" important="true">systemd*</solvable>
 8   <solvable match="w" important="true">udev</solvable>
 9   <solvable match="w">*</solvable>4
10  </solvables>
11 </snapper-zypp-plugin-conf>

1

match属性は、パターンがUnixシェルと同様のワイルドカードであるか(w)、それともPython正規表現であるか(re)を定義します。

2

指定されたパターンが一致し、対応するパッケージに重要のマークが付いている場合(カーネルパッケージなど)、そのスナップショットにも重要のマークが付きます。

3

パッケージ名に一致するパターン。特殊文字は、match属性の設定に基づいて、シェル風のワイルドカードまたは正規表現のいずれかとして解釈されます。このパターンは、kernel-で始まるすべてのパッケージ名に一致します。

4

この行は、無条件にすべてのパッケージに一致します。

この設定スナップショットでは、パッケージのインストール時に常にペアが作成されます(9行目)。重要のマークが付いたkernel、dracut、glibc、systemd、またはudevパッケージがインストールされると、そのスナップショットペアにも重要のマークが付きます(4~8行目)。すべてのルールが評価されます。

ルールを無効にするには、削除するか、XMLコメントを使用して無効にします。パッケージがインストールされるたびにスナップショットペアが作成されないようにするには、次のようにします。たとえば、9行目のコメント行のように指定します。

 1 <?xml version="1.0" encoding="utf-8"?>
 2 <snapper-zypp-plugin-conf>
 3  <solvables>
 4   <solvable match="w" important="true">kernel-*</solvable>
 5   <solvable match="w" important="true">dracut</solvable>
 6   <solvable match="w" important="true">glibc</solvable>
 7   <solvable match="w" important="true">systemd*</solvable>
 8   <solvable match="w" important="true">udev</solvable>
 9   <!-- <solvable match="w">*</solvable> -->
10  </solvables>
11 </snapper-zypp-plugin-conf>

7.1.3.3 新規サブボリュームの作成とマウント

/階層下に新規のサブボリュームを作成し、永続的にマウントすることができます。このようなサブボリュームはスナップショットから除外されます。既存のスナップショット内に作成してはいけません。ロールバック後にスナップショットを削除できなくなるためです。

SUSE Linux Enterprise Serverは、/@/サブボリュームが設定されており、このサブボリュームは、/opt/srv/home、その他の永続サブボリュームの独立したルートとしての役割を果たします。作成し、永続的にマウントする新規のサブボリュームは、この初期のルートファイルシステムに作成しなければなりません。

そのように設定するには、次のコマンドを実行します。この例では、新規サブボリューム、/usr/important/dev/sda2から作成されます。

tux > sudo mount /dev/sda2 -o subvol=@ /mnt
tux > sudo btrfs subvolume create /mnt/usr/important
tux > sudo umount /mnt

/etc/fstabの該当エントリは、次のようになります。

/dev/sda2 /usr/important btrfs subvol=@/usr/important 0 0
ヒント
ヒント: コピーオンライト(cow)の無効化

サブボリュームには、仮想化ディスクイメージ、データベースファイル、ログファイルなど、頻繁に変更されるファイルが含まれている場合があります。その場合、ディスクブロックの重複を避けるため、このボリュームのコピーオンライト機能を無効にすることを検討します。そのためには、/etc/fstabnodatacowマウントオプションを使用します。

/dev/sda2 /usr/important btrfs nodatacow,subvol=@/usr/important 0 0

1つのファイルまたはディレクトリに対してコピーオンライトを無効にするには、コマンドchattr +C PATHを使用します。

7.1.3.4 スナップショットのアーカイブの制御

スナップショットはディスク容量を占有します。ディスク容量が不足してシステムが停止しないようにするために、古いスナップショットは自動的に削除されます。デフォルトでは、最大10個の重要なインストールスナップショットと管理スナップショット、および最大10個の標準のインストールスナップショットと管理スナップショットが保持されます。これらのスナップショットがルートファイルシステムのサイズの50%超を占有する場合、追加のスナップショットは削除されます。最低でも、4つの重要なスナップショットと2つの標準スナップショットは常に保持されます。

これらの値の変更方法については、7.4.1項 「既存の設定の管理」を参照してください。

7.1.3.5 シンプロビジョンLVMボリュームでのSnapperの使用

Snapperは、Btrfsファイルシステムのスナップショット作成だけでなく、XFS、Ext4、またはExt3でフォーマットされたシンプロビジョンLVMボリュームのスナップショット作成にも対応しています(通常のLVMボリュームのスナップショットには「対応していません」)。LVMボリュームに関する詳細および設定の手順については、Book “導入ガイド”, Chapter 12 “高度なディスクセットアップ”, Section 12.2 “LVMの設定”を参照してください。

シンプロビジョンLVMボリュームでSnapperを使用するには、そのようにSnapperの設定を作成する必要があります。LVMで、--fstype=lvm(FILESYSTEM)を使用してファイルシステムを指定する必要があります。ext3etx4、またはxfsは、FILESYSTEMの有効な値です。例:

tux > sudo snapper -c lvm create-config --fstype="lvm(xfs)" /thin_lvm

7.4.1項 「既存の設定の管理」で説明したように、必要に応じてこの設定を調整できます。

7.2 Snapperを使用した変更の取り消し

SUSE Linux Enterprise ServerのSnapperは、zypperやYaSTで行った変更を取り消すことができるツールとしてあらかじめ設定されています。このために、Snapperは、zypperおよびYaSTの実行前後にスナップショットのペアを作成します。また、Snapperを使用して、誤って削除または変更したシステムファイルを復元することもできます。このためには、ルートパーティションのタイムラインスナップショットを有効にする必要があります。詳細については、7.1.3.1項 「スナップショットの無効化/有効化」を参照してください。

上記の自動スナップショットは、デフォルトでルートパーティションとそのサブボリュームに対して設定されます。カスタム設定を作成すれば、/homeなど、他のパーティションに対してスナップショット機能を使用できます。

重要
重要: 変更の取り消しとロールバックの比較

スナップショットを操作してデータを復元する場合、Snapperが処理可能なシナリオとして、根本的に異なる次の2つのシナリオがあることを理解することが重要です。

変更の取り消し

次に説明されているように、変更を取り消す際には、2つのスナップショットが比較され、これらの2つのスナップショット間の変更が取り消されます。この方法を使用して、復元する必要があるファイルを明示的に選択できます。

ロールバック

7.3項 「スナップショットからのブートによるシステムロールバック」で説明されているように、ロールバックを実行すると、システムはスナップショットが作成された状態にリセットされます。

変更を取り消す場合は、現在のシステムとスナップショットを比較することもできます。このような比較から「すべての」ファイルを復元すると、ロールバックを実行した場合と同じ結果になります。ただし、ロールバックについては、7.3項 「スナップショットからのブートによるシステムロールバック」で説明されている方法を使用することをお勧めします。この方法はより高速で、ロールバック実行前にシステムを確認できるためです。

警告
警告: データの整合性

スナップショットを作成する際に、データの整合性を確保するメカニズムがありません。スナップショットを作成するのと同時にファイルが書き込まれると(データベースなど)、ファイルが破損したり、ファイルへの書き込みが部分的になったりします。このようなファイルを復元すると、問題が発生することがあります。また、/etc/mtabなどの一部のシステムファイルは復元しないでください。このため、「必ず」、変更されたファイルとその差分をよく確認してください。どうしても元に戻すことが必要なファイルのみ復元してください。

7.2.1 YaSTおよびZypperによる変更の取り消し

インストール時にルートパーティションをBtrfsで設定すると、Snapper(YaSTまたはZypperによる変更のロールバックがあらかじめ設定されている)が自動的にインストールされます。YaSTモジュールまたはZypperトランザクションを開始するたびに、2つのスナップショットが作成されます。モジュール開始前のファイルシステムの状態をキャプチャした事前スナップショットと、モジュール完了後の状態をキャプチャした事後スナップショットです。

YaSTのSnapperモジュールまたはsnapperコマンドラインツールを使用して、事前スナップショットからファイルを復元し、YaST/Zypperによる変更を元に戻すことができます。また、2つのスナップショットを比較して、どのファイルが変更されているか調べることができます。2つのバージョンのファイルの違いを表示することもできます(diff)。

手順 7.1: YaSTのSnapperモジュールによる変更の取り消し
  1. YaSTのその他セクションにあるSnapperモジュールを起動するか、「yast2 snapper」と入力します。

  2. 現在の設定rootになっていることを確認します。 独自のSnapper設定を手動で追加していない限り、常にそのようになっています。

  3. リストから事前スナップショットと事後スナップショットのペアを選択します。YaSTのスナップショットペアもZypperのスナップショットペアも、種類は事前および事後です。YaSTのスナップショットの場合は説明に「zypp(y2base)」と表示され、Zypperのスナップショットの場合は「zypp(zypper)」と表示されます。

  4. 変更点の表示をクリックすると、2つのスナップショット間の内容に差異のあるファイルのリストが表示されます。

  5. ファイルのリストを確認します。事前および事後のファイル間の差異を表示するには、リストからファイルを選択します。

  6. 1つまたは複数のファイルを復元するには、該当するチェックボックスをオンにして、関連するファイルまたはディレクトリを選択します。選択したものを復元をクリックし、はいをクリックして操作を確認します。

    単一のファイルを復元する場合は、ファイル名をクリックして差分を表示します。最初から復元するをクリックし、はいをクリックして選択内容を確認します。

手順 7.2: snapperコマンドによる変更の取り消し
  1. snapper list -t pre-postを実行すると、YaSTおよびZypperのスナップショットリストが表示されます。YaSTのスナップショットの場合は説明に「yast MODULE_NAME」と表示され、Zypperのスナップショットの場合は「zypp(zypper)」と表示されます。

    tux > sudo snapper list -t pre-post
    Pre # | Post # | Pre Date                      | Post Date                     | Description
    ------+--------+-------------------------------+-------------------------------+--------------
    311   | 312    | Tue 06 May 2014 14:05:46 CEST | Tue 06 May 2014 14:05:52 CEST | zypp(y2base)
    340   | 341    | Wed 07 May 2014 16:15:10 CEST | Wed 07 May 2014 16:15:16 CEST | zypp(zypper)
    342   | 343    | Wed 07 May 2014 16:20:38 CEST | Wed 07 May 2014 16:20:42 CEST | zypp(y2base)
    344   | 345    | Wed 07 May 2014 16:21:23 CEST | Wed 07 May 2014 16:21:24 CEST | zypp(zypper)
    346   | 347    | Wed 07 May 2014 16:41:06 CEST | Wed 07 May 2014 16:41:10 CEST | zypp(y2base)
    348   | 349    | Wed 07 May 2014 16:44:50 CEST | Wed 07 May 2014 16:44:53 CEST | zypp(y2base)
    350   | 351    | Wed 07 May 2014 16:46:27 CEST | Wed 07 May 2014 16:46:38 CEST | zypp(y2base)
  2. スナップショットのペア間で変更されたファイルのリストを取得するには、以下を実行します。snapper status PREPOST. 内容が変更されたファイルにはcのマーク、追加されたファイルには+のマーク、削除されたファイルには-のマークが付いています。

    tux > sudo snapper status 350..351
    +..... /usr/share/doc/packages/mikachan-fonts
    +..... /usr/share/doc/packages/mikachan-fonts/COPYING
    +..... /usr/share/doc/packages/mikachan-fonts/dl.html
    c..... /usr/share/fonts/truetype/fonts.dir
    c..... /usr/share/fonts/truetype/fonts.scale
    +..... /usr/share/fonts/truetype/みかちゃん-p.ttf
    +..... /usr/share/fonts/truetype/みかちゃん-pb.ttf
    +..... /usr/share/fonts/truetype/みかちゃん-ps.ttf
    +..... /usr/share/fonts/truetype/みかちゃん.ttf
    c..... /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-x86_64.cache-4
    c..... /var/lib/rpm/Basenames
    c..... /var/lib/rpm/Dirnames
    c..... /var/lib/rpm/Group
    c..... /var/lib/rpm/Installtid
    c..... /var/lib/rpm/Name
    c..... /var/lib/rpm/Packages
    c..... /var/lib/rpm/Providename
    c..... /var/lib/rpm/Requirename
    c..... /var/lib/rpm/Sha1header
    c..... /var/lib/rpm/Sigmd5
  3. 特定のファイルの差異を表示するには、以下を実行します。snapper diff PRE..POST ファイル名ファイル名を指定しない場合は、すべてのファイルの差異が表示されます。

    tux > sudo snapper diff 350..351 /usr/share/fonts/truetype/fonts.scale
    --- /.snapshots/350/snapshot/usr/share/fonts/truetype/fonts.scale       2014-04-23 15:58:57.000000000 +0200
    +++ /.snapshots/351/snapshot/usr/share/fonts/truetype/fonts.scale       2014-05-07 16:46:31.000000000 +0200
    @@ -1,4 +1,4 @@
    -1174
    +1486
     ds=y:ai=0.2:luximr.ttf -b&h-luxi mono-bold-i-normal--0-0-0-0-c-0-iso10646-1
     ds=y:ai=0.2:luximr.ttf -b&h-luxi mono-bold-i-normal--0-0-0-0-c-0-iso8859-1
    [...]
  4. 1つまたは複数のファイルを復元するには、以下を実行します。snapper -v undochange PRE..POST ファイル名ファイル名を指定しない場合は、変更されたすべてのファイルが復元されます。

    tux > sudo snapper -v undochange 350..351
         create:0 modify:13 delete:7
         undoing change...
         deleting /usr/share/doc/packages/mikachan-fonts
         deleting /usr/share/doc/packages/mikachan-fonts/COPYING
         deleting /usr/share/doc/packages/mikachan-fonts/dl.html
         deleting /usr/share/fonts/truetype/みかちゃん-p.ttf
         deleting /usr/share/fonts/truetype/みかちゃん-pb.ttf
         deleting /usr/share/fonts/truetype/みかちゃん-ps.ttf
         deleting /usr/share/fonts/truetype/みかちゃん.ttf
         modifying /usr/share/fonts/truetype/fonts.dir
         modifying /usr/share/fonts/truetype/fonts.scale
         modifying /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-x86_64.cache-4
         modifying /var/lib/rpm/Basenames
         modifying /var/lib/rpm/Dirnames
         modifying /var/lib/rpm/Group
         modifying /var/lib/rpm/Installtid
         modifying /var/lib/rpm/Name
         modifying /var/lib/rpm/Packages
         modifying /var/lib/rpm/Providename
         modifying /var/lib/rpm/Requirename
         modifying /var/lib/rpm/Sha1header
         modifying /var/lib/rpm/Sigmd5
         undoing change done
警告
警告: ユーザ追加の取り消し

ユーザの追加を取り消す場合、Snapperで変更を取り消す方法はお勧めしません。特定のディレクトリはスナップショットから除外されているため、これらのユーザに属するファイルはファイルシステムに残ったままになります。削除済みユーザと同じユーザIDを持つユーザを作成した場合、このユーザはこれらのファイルを継承します。したがって、YaSTのユーザおよびグループ管理ツールを使用して、ユーザを削除することを強くお勧めします。

7.2.2 Snapperを使用したファイルの復元

インストールスナップショットおよび管理スナップショットとは別に、Snapperはタイムラインスナップショットを作成します。このバックアップ用スナップショットを使用して、誤って削除したファイルを復元したり、ファイルの以前のバージョンを復元したりできます。Snapperの差分抽出機能を使用して、特定の時点でどのような変更が加えられたのかを調べることもできます。

ファイルの復元機能は、特に、デフォルトではスナップショットが作成されないサブボリュームまたはパーティションに存在するデータにとって重要です。ホームディレクトリからファイルを復元できるようにするには、たとえば、/home用に、自動的にタイムラインスナップショットを作成する別個のSnapper設定を作成します。手順については、7.4項 「Snapper設定の作成と変更」を参照してください。

警告
警告: ファイルの復元とロールバックの比較

ルートファイルシステムから作成されたスナップショット(Snapperのルート設定で定義されています)を使用して、システムロールバックを実行できます。このようなロールバックを実行する場合にお勧めする方法は、そのスナップショットからブートしてからロールバックを実行する方法です。詳細については、7.3項 「スナップショットからのブートによるシステムロールバック」を参照してください。

次に説明するように、ルートファイルシステムスナップショットからすべてのファイルを復元することによってロールバックを実行することもできます。ただし、これはお勧めできません。たとえば、/etcディレクトリから環境設定ファイルなど単一のファイルを復元できますが、スナップショットからファイルの完全なリストを復元することはできません。

この制限は、ルートファイルシステムから作成されたスナップショットにのみ影響します。

手順 7.3: YaST Snapperモジュールを使用したファイルの復元
  1. YaSTのその他セクションから、または「yast2 snapper」と入力してSnapperモジュールを起します。

  2. スナップショットを選択するための現在の設定を選択します。

  3. ファイルを復元するためのタイムラインスナップショットを選択し変更点の表示を選択します。タイムラインスナップショットは、タイプが単一で、説明の値がtimeline (タイムライン)であるスナップショットです。

  4. ファイル名をクリックしてテキストボックスからファイルを選択します。スナップショットバージョンと現在のシステムとの差分が表示されます。復元対象ファイルを選択するチェックボックスをオンにします。復元するすべてのファイルに対してこれを行います。

  5. 選択したものを復元をクリックし、はいをクリックして操作を確認します。

手順 7.4: snapperコマンドを使用したファイルの復元
  1. 次のコマンドを実行して、特定の設定のタイムラインスナップショットのリストを取得します。

    tux > sudo snapper -c CONFIG list -t single | grep timeline

    CONFIGは、既存のSnapper設定に置き換える必要があります。snapper list-configsを使用してリストを表示します。

  2. 次のコマンドを実行して、指定のスナップショットの変更ファイルのリストを取得します。

    tux > sudo snapper -c CONFIG status SNAPSHOT_ID..0

    SNAPSHOT_IDをファイルの復元元のスナップショットIDで置き換えます。

  3. オプションで、次のコマンドを実行して、現在のファイルバージョンとスナップショットからのバージョンとの差分を一覧にします。

    tux > sudo snapper -c CONFIG diff SNAPSHOT_ID..0 FILE NAME

    <FILE NAME>を指定しない場合は、すべてのファイルの差分が表示されます。

  4. 1つ以上のファイルを復元するには、以下を実行します

    tux > sudo snapper -c CONFIG -v undochange SNAPSHOT_ID..0 FILENAME1 FILENAME2

    ファイル名を指定しない場合は、変更されたすべてのファイルが復元されます。

7.3 スナップショットからのブートによるシステムロールバック

SUSE Linux Enterprise Serverに含まれているGRUB 2バージョンは、Btrfsスナップショットからブートできます。Snapperのロールバック機能と併用することで、誤設定されたシステムを回復できます。デフォルトのSnapper設定(root)で作成されたスナップショットのみがブート可能です。

重要
重要: サポートされる構成

SUSE Linux Enterprise Server 12 SP4の時点では、システムのロールバックは、ルートパーティションのデフォルトのサブボリューム設定が変更されていない場合にのみサポートされます。

スナップショットをブートする場合、スナップショットに含まれているファイルシステムの該当部分が読み込み専用でマウントされます。スナップショットから除外されている他のすべてのファイルシステムと該当部分は読み書き可能でマウントされ、変更できます。

重要
重要: 変更の取り消しとロールバックの比較

スナップショットを操作してデータを復元する場合、Snapperが処理可能なシナリオとして、根本的に異なる次の2つのシナリオがあることを理解することが重要です。

変更の取り消し

7.2項 「Snapperを使用した変更の取り消し」で説明されているように、変更を取り消す場合は、2つのスナップショットが比較され、これらの2つのスナップショット間の変更が元に戻されます。この方法を使用すると、選択したファイルを復元から明示的に除外することもできます。

ロールバック

次に説明する方法でロールバックを実行すると、システムはスナップショットが作成された状態にリセットされます。

ブート可能なスナップショットからロールバックを行うには、次の要件を満たす必要があります。デフォルトインストールを行った場合、システムはそのように設定されます。

ブート可能なスナップショットからのロールバックの要件
  • ルートファイルシステムは、Btrfsである必要があります。LVMボリュームスナップショットからのブートはサポートされていません。

  • ルートファイルシステムは、単一のデバイス、単一のパーティション、および単一のサブボリューム上にある必要があります。/srvなどスナップショットから除外されるディレクトリ(完全なリストについては、7.1.2項 「スナップショットから除外されるディレクトリ」を参照)は、別のパーティション上に存在していても構いません。

  • システムは、インストールされたブートローダを介してブート可能である必要があります。

ブート可能なスナップショットからのロールバックを実行するには、次の手順に従います。

  1. システムをブートします。ブートメニューから、Bootable snapshots(ブート可能なスナップショット)を選択して、ブートするスナップショットを選択します。スナップショットのリストが日別に一覧にされます。最新のスナップショットが先頭に表示されます。

  2. システムにログインします。すべてが予期したとおりに動作しているかどうかを注意深く確認します。スナップショットの一部であるディレクトリに書き込むことはできないので注意してください。他のディレクトリに書き込むデータは、次に行う操作にかかわらず、失われることは「ありません」

  3. ロールバックを実行するかどうかに応じて、次のステップを選択します。

    1. システムが、ロールバックを実行したくない状態になっている場合は、再起動して現在のシステム状態にブートします。その後、別のスナップショットを選択するか、レスキューシステムを開始することができます。

    2. ロールバックを実行するには、次のコマンドを実行し

      tux > sudo snapper rollback

      その後、再起動します。ブート画面で、デフォルトのブートエントリを選択して、復元されたシステムで再起動します。ロールバック前のファイルシステムの状態のスナップショットが作成されます。rootのデフォルトのサブボリュームは、新しい読み書きスナップショットに置き換えられます。詳細については、7.3.1項 「ロールバック後のスナップショット」を参照してください。

      -dオプションを使用してスナップショットの説明を追加すると役に立ちます。次に例を示します。

      New file system root since rollback on DATE TIME
ヒント
ヒント: 特定のインストール状態へのロールバック

スナップショットがインストール時に無効になっていない場合、最初のシステムインストールの最後に初期のブート可能スナップショットが作成されます。このスナップショットをブートすることで、いつでもその状態に戻ることができます。スナップショットは、インストール後、説明で識別できます。

ブート可能スナップショットは、サービスパックや新しいメジャーリリースへのシステムアップグレードの開始時にも作成されます(スナップショットが無効になっていない場合のみ)。

7.3.1 ロールバック後のスナップショット

ロールバックの実行前に、動作中のファイルシステムのスナップショットが作成されます。この説明では、ロールバックで復元されたスナップショットのIDを参照します。

ロールバックで作成されたスナップショットは、Cleanup属性に値numberが付きます。したがって、設定されているスナップショット数に達すると、ロールバックスナップショットは自動的に削除されます。詳細については、7.6項 「スナップショットの自動クリーンアップ」を参照してください。スナップショットに重要なデータが含まれている場合は、スナップショットが削除される前にデータを抽出してください。

7.3.1.1 ロールバックスナップショットの例

たとえば、新規インストール後に、システムで次のスナップショットが使用可能であるとします。

root # snapper --iso list
Type   | # |     | Cleanup | Description           | Userdata
-------+---+ ... +---------+-----------------------+--------------
single | 0 |     |         | current               |
single | 1 |     |         | first root filesystem |
single | 2 |     | number  | after installation    | important=yes

sudo snapper rollbackを実行すると、スナップショット3が作成され、ロールバック実行前のシステムの状態が格納されます。スナップショット4は新しいデフォルトのBtrfsサブボリュームであるため、再起動後にシステムになります。

root # snapper --iso list
Type   | # |     | Cleanup | Description           | Userdata
-------+---+ ... +---------+-----------------------+--------------
single | 0 |     |         | current               |
single | 1 |     | number  | first root filesystem |
single | 2 |     | number  | after installation    | important=yes
single | 3 |     | number  | rollback backup of #1 | important=yes
single | 4 |     |         |                       |

7.3.2 スナップショットブートエントリのアクセスと識別

スナップショットからブートするには、マシンを再起動して、Start Bootloader from a read-only snapshot(読み取り専用スナップショットからBootloaderを始動)を選択します。ブート可能なすべてのスナップショットをリストした画面が開きます。最も新しいスナップショットが先頭に表示され、最も古いものは最後に表示されます。キーおよびキーを使用して移動し、Enterキーを押して、選択したスナップショットを有効にします。ブートメニューからスナップショットを有効にしても、マシンは即座に再起動されません。選択したスナップショットのブートローダが開くだけです。

ブートローダ: スナップショット
図 7.1: ブートローダ: スナップショット

ブートローダの各スナップショットエントリの名前は、命名規則に従っているため、容易に識別できます。

[*]1OS2 (KERNEL3,DATE4TTIME5,DESCRIPTION6)

1

重要なスナップショットとしてとマークが付いている場合、そのエントリには*が付きます。

2

オペレーティングシステムラベル。

4

日付フォーマット(YYYY-MM-DD)。

5

時刻フォーマット(HH:MM)。

6

このフィールドには、スナップショットの説明が入ります。手動で作成されたスナップショットの場合、この説明は--descriptionオプションで作成された文字列、またはカスタム文字列です(ヒント: ブートローダスナップショットエントリのカスタム説明の設定を参照)。自動で作成されたスナップショットの場合、zypp(zypper)yast_sw_singleなど、呼びだされたツールです。長い説明は、ブート画面のサイズに応じて、切り捨てて表示されます。

ヒント
ヒント: ブートローダスナップショットエントリのカスタム説明の設定

スナップショットの説明フィールドのデフォルトの文字列をカスタム文字列に置き換えることができます。この機能は、自動的に作成された説明が不十分な場合や、ユーザが入力した説明が長すぎる場合などに役立ちます。カスタム文字列、STRINGをスナップショット、NUMBERに設定するには、次のコマンドを使用します。

tux > sudo snapper modify --userdata "bootloader=STRING" NUMBER

説明は25文字未満にしてください。このサイズを超える部分はブート画面では一切読めません。

7.3.3 制限

システム全体をスナップショット作成時と同一の状態に復元する、システムの「完全な」ロールバックは不可能です。

7.3.3.1 スナップショットから除外されるディレクトリ

ルートファイルシステムのスナップショットには、すべてのディレクトリが含まれるわけではありません。詳細および理由については、7.1.2項 「スナップショットから除外されるディレクトリ」を参照してください。そのため、一般的にこれらのディレクトリのデータは復元されないため、次の制限が生じます。

ロールバック後、アドオンおよびサードバーティソフトウェアを使用できない場合がある

スナップショットから除外されるサブボリューム(/optなど)にデータをインストールするアプリケーションやアドオンは、アプリケーションデータの他の部分がスナップショットに含まれるサブボリュームにもインストールされている場合、ロールバック後に動作しない場合があります。この問題を解決するには、アプリケーションまたはアドオンを再インストールします。

ファイルアクセスの問題

スナップショットと現在のシステムでファイルのパーミッションまたは所有権、あるいはその両方がアプリケーションによって変更されている場合、そのアプリケーションは該当するファイルにアクセスできない場合があります。ロールバック後、影響を受けるファイルのパーミッションまたは所有権、あるいはその両方をリセットします。

互換性のないデータ形式

サービスまたはアプリケーションがスナップショットと現在のシステムとの間に新しいデータ形式を設定した場合、ロールバック後、そのアプリケーションは影響を受けたデータファイルを読み込めない場合があります。

コードとデータが混在するサブボリューム

/srvのようなサブボリュームには、コードとデータが混在する場合があります。ロールバックの結果、コードが機能しなくなる場合があります。たとえば、PHPのバージョンがダウングレードされ、WebサーバのPHPスクリプトが壊れる場合があります。

ユーザデータ

ロールバックによりシステムからユーザが削除された場合、これらのユーザが、スナップショットから除外されているディレクトリ内で所有していたデータは削除されません。同じユーザIDを持つユーザが作成された場合、そのユーザは該当ファイルを継承します。findのようなツールを使用して、孤立したファイルを検索して削除します。

7.3.3.2 ブートローダのデータはロールバックできない

ブートローダはロールバックできません。これは、ブートローダのすべてのステージが整合している必要があるためです。これは、/bootのロールバックを実行する際には保証できません。

7.4 Snapper設定の作成と変更

Snapperの動作は、各パーティションまたはBtrfsサブボリュームに固有の設定ファイルで定義できます。これらの設定ファイルは、/etc/snapper/configs/に保存されます。

ルートファイルシステムに十分な容量(約12GB)がある場合、ルートファイルシステム(/)のスナップショットはインストール時に自動的に有効になります。対応するデフォルト設定はrootという名前です。これにより、YaSTおよびZypperのスナップショットが作成および管理されます。デフォルト値のリストについては、7.4.1.1項 「設定データ」を参照してください。

注記
注記: スナップショットを有効にするための最小ルートファイルシステム

7.1項 「デフォルト設定」で説明されているように、スナップショットを有効にするには、ルートファイルシステムに追加の空き容量が必要です。この容量は、インストールされているパッケージの量と、スナップショットに含まれるボリュームに加えられた変更の量によって異なります。スナップショットの頻度と、アーカイブされるスナップショットの数も重要です。

インストール時にスナップショットを自動的に有効にするには、最小サイズのルートファイルシステムが必要です。このサイズは約12GBです。この値は今後、基本システムのアーキテクチャとサイズに応じて変わる可能性があります。これは、インストールメディアにあるファイル/control.xmlの次のタグの値に依存します。

<root_base_size>
<btrfs_increase_percentage>

これは、ROOT_BASE_SIZE * (1 + BTRFS_INCREASE_PERCENTAGE/100)という式で計算されます。

この値は最小サイズであることに注意してください。ルートファイルシステム用に、これよりも多くの容量を使用することを検討します。一般的には、スナップショットが有効でない場合に使用するサイズの2倍にします。

Btrfsでフォーマットされたその他のパーティションやBtrfsパーティション上の既存のサブボリュームに対して、独自の設定ファイルを作成できます。以下の例では、/srv/wwwにマウントされたBtrfsフォーマットのパーティションに保存されたWebサーバデータをバックアップするSnapper設定を作成します。

設定が作成された後で、snapper自体またはYaSTのSnapperモジュールを使用して、これらのスナップショットからファイルを復元できます。YaSTの場合は現在の設定を選択する必要があります。snapperの場合は、グローバルスイッチ-cを使用して設定を指定する必要があります(例: snapper -c myconfig list)。

新しいSnapper設定を作成するには、snapper create-configを実行します。

tux > sudo snapper -c www-data1 create-config /srv/www2

1

設定ファイルの名前。

2

スナップショットを作成するパーティションまたはBtrfsサブボリュームのマウントポイント。

このコマンドにより、新しい設定ファイル/etc/snapper/configs/www-dataが作成され、/etc/snapper/config-templates/defaultから取得されたデフォルト値が使用されます。これらのデフォルトの調整方法については、7.4.1項 「既存の設定の管理」を参照してください。

ヒント
ヒント: 設定のデフォルト値

新しい設定ファイルのデフォルト値は/etc/snapper/config-templates/defaultから取得されます。独自のデフォルトセットを使用する場合は、同じディレクトリ内にこのファイルのコピーを作成し、必要に応じて調整してください。作成したファイルを使用するには、create-configコマンドで-tオプションを指定します。

tux > sudo snapper -c www-data create-config -t MY_DEFAULTS /srv/www

7.4.1 既存の設定の管理

snapperは、既存の設定を管理するためのサブコマンドを備えています。これらの設定を一覧、表示、削除、および変更することができます。

設定の一覧

既存の設定をすべて取得するには、snapper list-configsコマンドを使用します。

tux > sudo snapper list-configs
Config | Subvolume
-------+----------
root   | /
usr    | /usr
local  | /local
設定の表示

指定した設定を表示するには、snapper -c CONFIG get-configサブコマンドを使用します。Configは、snapper list-configsで表示される設定名に置き換える必要があります。設定オプションの詳細については、7.4.1.1項 「設定データ」を参照してください。

デフォルト設定を表示するには、次のコマンドを実行します。

tux > sudo snapper -c root get-config
設定の変更

指定した設定のオプションを変更するには、snapper -c CONFIG set-config OPTION=VALUEサブコマンドを使用します。Configは、snapper list-configsで表示される設定名に置き換える必要があります。OPTIONおよびVALUEに指定可能な値は、7.4.1.1項 「設定データ」に一覧にされています。

設定の削除

設定を削除するには、snapper -c CONFIG delete-configサブコマンドを使用します。Configは、snapper list-configsで表示される設定名に置き換える必要があります。

7.4.1.1 設定データ

各設定には、コマンドラインから変更可能なオプションのリストが含まれています。次に、各オプションの詳細を示します。値を変更するには、snapper -c CONFIG set-config "KEY=VALUE"を実行します。

ALLOW_GROUPSALLOW_USERS

通常のユーザにスナップショットを使用するパーミッションを付与します。詳細については、7.4.1.2項 「通常ユーザとしてのSnapperの使用」を参照してください。

デフォルト値は""です。

BACKGROUND_COMPARISON

事前および事後スナップショットを、作成後にバックグラウンドで比較するかどうかを定義します。

デフォルト値はyes (はい)です。

なし_*

同一の事前および事後スナップショットを持つスナップショットペアのクリーンアップアルゴリズムを定義します。詳細については、7.6.3項 「違いがないスナップショットのペアのクリーンアップ」を参照してください。

FSTYPE

パーティションのファイルシステムタイプ。変更しません。

デフォルト値はbtrfsです。

NUMBER_*

インストールおよび管理スナップショットのクリーンアップアルゴリズムを定義します。詳細については、7.6.1項 「番号付きスナップショットのクリーンアップ」を参照してください。

QGROUP / SPACE_LIMIT

クリーンアップアルゴリズムにクォータサポートを追加します。詳細については、7.6.5項 「ディスククォータサポートの追加」を参照してください。

SUBVOLUME

スナップショットを作成するパーティションまたはサブボリュームのマウントポイント。変更しません。

デフォルト値は「/」です。

SYNC_ACL

Snapperが通常ユーザによって使用される場合(7.4.1.2項 「通常ユーザとしてのSnapperの使用」を参照)、ユーザは.snapshotディレクトリにアクセスして、そのディレクトリ内のファイルを読み取ることができる必要があります。SYNC_ACLをyes (はい)に設定した場合、Snapperは自動的に、ALLOW_USERSまたはALLOW_GROUPSエントリからACLを使用してユーザとグループがファイルにアクセスできるようにします。

デフォルト値はno (いいえ)です。

TIMELINE_CREATE

yes (はい)に設定されている場合は、毎時スナップショットが作成されます。有効な値: yes(はい)no(いいえ)

デフォルト値はno (いいえ)です。

TIMELINE_CLEANUP / TIMELINE_LIMIT_*

タイムラインスナップショットのクリーンアップアルゴリズムを定義します。詳細については、7.6.2項 「タイムラインスナップショットのクリーンアップ」を参照してください。

7.4.1.2 通常ユーザとしてのSnapperの使用

デフォルトでは、rootしかSnapperを使用できません。しかし、以下のような場合、特定のグループまたはユーザがスナップショットを作成したり、スナップショットを使って変更を取り消したりできる必要があります。

  • Webサイト管理者が/srv/wwwのスナップショットを作成したい場合

  • ユーザが自身のホームディレクトリのスナップショットを作成したい場合

このような場合、ユーザやグループにパーミッションを与えるSnapper設定を作成できます。対応する.snapshotsディレクトリは、指定されたユーザによって読み込みおよびアクセス可能である必要があります。このための最も簡単な方法は、SYNC_ACLオプションをyes (はい)に設定することです。

手順 7.5: 通常ユーザによるSnapper使用の有効化

次のすべての手順はrootとして実行する必要があります。

  1. ユーザがSnapperを使用するパーティションまたはサブボリュームにSnapper設定がない場合は、作成します。手順については、7.4項 「Snapper設定の作成と変更」を参照してください。例:

    tux > sudo snapper --config web_data create /srv/www
  2. /etc/snapper/configs/CONFIGに設定ファイルを作成します。CONFIGは、前の手順で-c/--configを使用して指定される値です(/etc/snapper/configs/web_dataなど)。必要に応じて設定ファイルを調整します。詳細は7.4.1項 「既存の設定の管理」を参照してください。

  3. ALLOW_USERSALLOW_GROUPS、またはその一方の値を設定し、ユーザやグループにパーミッションを与えます。複数のエントリはSpaceで区切ってください。たとえば、ユーザwww_adminにパーミッションを与えるには、次のように入力します。

    tux > sudo snapper -c web_data set-config "ALLOW_USERS=www_admin" SYNC_ACL="yes"
  4. これで、指定されたユーザやグループが特定のSnapper設定を使用できます。以下のようにlistコマンドを使ってテストできます。

    www_admin:~ > snapper -c web_data list

7.5 スナップショットの手動での作成と管理

Snapperは設定によって自動的にスナップショットを作成および管理するだけのものではありません。コマンドラインツールまたはYaSTモジュールを使用して、手動でスナップショットのペア(事前および事後)や単一のスナップショットを作成することもできます。

Snapperのすべての操作は既存の設定に対して実行されます(詳細は7.4項 「Snapper設定の作成と変更」を参照)。スナップショットを作成するには、対象のパーティションまたはボリュームに対して設定が存在する必要があります。デフォルトで、システム設定(root)が使用されます。独自の設定に対してスナップショットを作成または管理する場合は、明示的にその設定を選択する必要があります。YaSTの現在の設定ドロップダウンボックスを使用するか、コマンドラインで-cを指定します(snapper -c MYCONFIG COMMAND)。

7.5.1 スナップショットのメタデータ

各スナップショットには、スナップショット自体とメタデータが含まれています。スナップショットを作成する場合は、メタデータも指定する必要があります。スナップショットを修正すると、メタデータが変更されます。コンテンツを修正することはできません。既存のスナップショットとそのメタデータを表示するには、snapper listを使用します。

snapper --config home list

設定homeのスナップショットの一覧を示します。デフォルト設定(root)のスナップショットの一覧が示されるようにするには、snapper -c root listまたはsnapper listを使用します。

snapper list -a

すべての既存設定の一覧を示します。

snapper list -t pre-post

デフォルト(root)設定の事前および事後スナップショットの全ペアの一覧を示します。

snapper list -t single

デフォルト(root)設定について、singleタイプの全スナップショットの一覧を示します。

各スナップショットについて、以下のメタデータを利用できます。

  • Type(種類):スナップショットの種類です。詳細は7.5.1.1項 「スナップショットの種類」を参照してください。このデータは変更できません。

  • Number(番号):スナップショットの一意の番号。このデータは変更できません。

  • Pre Number(前番号):対応する事前スナップショットの番号を指定します。事後スナップショットにのみ適用されます。このデータは変更できません。

  • Description(説明):スナップショットの説明です。

  • Userdata (ユーザデータ): カンマ区切りの「キー=値」のリスト形式でカスタムデータを指定できる、拡張用の項目です。(例:reason=testing, project=foo)。このフィールドは、スナップショットに重要のマークを付ける場合(important=yes)や、スナップショットを作成したユーザを一覧にする場合(user=tux)にも使用されます。

  • Cleanup-Algorithm(クリーンアップアルゴリズム):スナップショットのクリーンアップアルゴリズムです。詳細は7.6項 「スナップショットの自動クリーンアップ」を参照してください。

7.5.1.1 スナップショットの種類

Snapperには、事前(pre)、事後(post)、および単一(single)の3種類のスナップショットがあります。これらは物理的には同じものですが、Snapperでは別のものとして扱われます。

pre(事前)

変更のファイルシステムのスナップショットです。各pre(事前)スナップショットには、対応するpost(事後)スナップショットがあります。たとえば、YaST/Zypperの自動スナップショットに対して使用します。

post(事後)

変更のファイルシステムのスナップショットです。各post(事後)スナップショットには、対応するpre(事前)スナップショットがあります。たとえば、YaST/Zypperの自動スナップショットに対して使用します。

single(単一)

スタンドアロンのスナップショットです。たとえば、自動毎時スナップショットに使用します。これは、スナップショットを作成する際のデフォルトの種類です。

7.5.1.2 クリーンアップアルゴリズム

Snapperには、古いスナップショットのクリーンアップアルゴリズムが3種類あります。このアルゴリズムは、日次のcronジョブとして実行されます。保持するさまざまなタイプのスナップショットの数を、Snapper設定で定義することができます(詳細は7.4.1項 「既存の設定の管理」を参照)。

number(番号)

スナップショットが特定の数に達すると、古いスナップショットを削除します。

timeline (タイムライン)

特定の期間が経過した古いスナップショットは削除しますが、毎時、毎日、毎月、および毎年のスナップショットを複数保持します。

empty-pre-post(事前事後の差分なし)

事前と事後のスナップショットに差分がない場合、そのペアを削除します。

7.5.2 スナップショットの作成

スナップショットを作成するには、snapper createを実行するか、YaSTのSnapperモジュールで作成をクリックします。以下は、コマンドラインを使ってスナップショットを作成する場合の例です。YaSTインタフェースを使用している場合、これらの例は簡単に採用できます。

ヒント
ヒント: Snapshot Description

後で識別しやすくするため、わかりやすい説明を指定しておいてください。ユーザデータオプションを使って、さらに情報を指定することもできます。

snapper create --description "Snapshot for week 2 2014"

説明付きのスタンドアロンのスナップショット(種類はsingle)を、デフォルト(root)設定で作成します。クリーンアップアルゴリズムは指定されていないので、自動的にスナップショットが削除されることはありません。

snapper --config home create --description "Cleanup in ~tux"

説明付きのスタンドアロンのスナップショット(種類はsingle)を、カスタム設定homeで作成します。クリーンアップアルゴリズムは指定されていないので、自動的にスナップショットが削除されることはありません。

snapper --config home create --description "Daily data backup" --cleanup-algorithm timeline>

説明付きのスタンドアロンのスナップショット(種類はsingle)を、カスタム設定homeで作成します。設定のタイムライン(timeline)クリーンアップアルゴリズムで指定された条件が満たされると、ファイルが自動的に削除されます。

snapper create --type pre--print-number--description "Before the Apache config cleanup"--userdata "important=yes"

種類がpreのスナップショットを作成し、スナップショット番号を出力します。事前「事後」の状態を保存するために使用されるスナップショットペアを作成するために必要な、最初のコマンドです。スナップショットには重要のマークが付きます。

snapper create --type post--pre-number 30--description "After the Apache config cleanup"--userdata "important=yes"

番号30preスナップショットとペアになるpostスナップショットを作成します。事前事後の状態を保存するために使用されるスナップショットペアを作成するために必要な、2番目のコマンドです。スナップショットには重要のマークが付きます。

snapper create --command COMMAND--description "Before and after COMMAND"

COMMANDの実行前後に自動的にスナップショットを作成します。このオプションを使用できるのは、コマンドラインでsnapperを使用する場合のみです。

7.5.3 スナップショットのメタデータ修正

Snapperでは、スナップショットの説明、クリーンアップアルゴリズム、およびユーザデータを修正できます。それ以外のメタデータは変更できません。以下は、コマンドラインを使ってスナップショットを修正する場合の例です。YaSTインタフェースを使用している場合、これらの例は簡単に採用できます。

コマンドラインでスナップショットを修正するには、スナップショットの番号がわかっている必要があります。snapperlistコマンドを実行すると、すべてのスナップショットとその番号が表示されます。

YaSTのSnapperモジュールでは、すでにすべてのスナップショットのリストが表示されています。リストからスナップショットを選択し、Modifyをクリックします。

snapper modify --cleanup-algorithm "timeline" 10

デフォルト(root)設定のスナップショット10番のメタデータを修正します。クリーンアップアルゴリズムがtimelineに設定されます。

snapper --config home modify --description "daily backup" -cleanup-algorithm "timeline"120

カスタム設定homeのスナップショット120番のメタデータを修正します。新しい説明が設定され、クリーンアップアルゴリズムを無しに設定します。

7.5.4 スナップショットの削除

YaSTのSnapperモジュールを使用してスナップショットを削除するには、リストからスナップショットを選択してDelete (削除)をクリックします。

コマンドラインツールを使ってスナップショットを削除するには、スナップショットの番号が分かっている必要があります。snapper listを実行して番号を調べます。スナップショットを削除するには、snapper delete NUMBERコマンドを実行します。

現在のデフォルトのサブボリュームスナップショットの削除は許可されません。

Snapperでスナップショットを削除すると、空いたスペースはバックグラウンドで実行されているBtrfsプロセスによって要求されます。つまり、空きスペースが見えるように、あるいは使用できるようになるまでに遅れが生じます。スナップショットの削除で空いたスペースをすぐに使用したい場合は、deleteコマンドで--syncオプションを指定します。

ヒント
ヒント: スナップショットペアの削除

preスナップショットを削除する場合は、必ず、対応するpostスナップショットを削除する必要があります(逆も同様です)。

snapper delete 65

デフォルト(root)設定のスナップショット65番を削除します。

snapper -c home delete 89 90

カスタム設定homeのスナップショット89番および90番を削除します。

snapper delete --sync 23

デフォルト設定(root) のスナップショット23を削除し、空いたスペースをすぐに使用できるようにします。

ヒント
ヒント: 参照されていないスナップショットの削除

Btrfsスナップショットが存在するのに、Snapper用のメタデータを含むXMLファイルが欠落している場合があります。この場合、スナップショットがSnapperには見えないため、手動で削除する必要があります。

btrfs subvolume delete /.snapshots/SNAPSHOTNUMBER/snapshot
rm -rf /.snapshots/SNAPSHOTNUMBER
ヒント
ヒント: 古いスナップショットほどディスク容量を使用

ハードディスクの容量を空けるためにスナップショットを削除する場合は、古いスナップショットから削除するようにします。古いスナップショットほど、多くの容量を使用します。

スナップショットは、日次のcronジョブでも自動的に削除されます。詳細については、7.5.1.2項 「クリーンアップアルゴリズム」を参照してください。

7.6 スナップショットの自動クリーンアップ

スナップショットはディスク容量を占有し、時間が経つにつれて、スナップショットが占有するディスク容量が増える可能性があります。ディスク容量が不足しないようにするために、Snapperは、古いスナップショットを自動的に削除するためのアルゴリズムを備えています。これらのアルゴリズムは、タイムラインスナップショットと番号付きスナップショット(管理スナップショットとインストールスナップショットのペア)を区別します。各タイプに対して、保持するスナップショットの数を指定できます。

そのほかに、オプションでディスク容量クォータを指定し、スナップショットが占有可能な最大ディスク容量を定義することもできます。また、事前スナップショットと事後スナップショットのペアに違いがない場合、それらのペアを自動的に削除することもできます。

クリーンアップアルゴリズムは常に1つのSnapper設定にバインドされるため、各設定に対してアルゴリズムを設定する必要があります。特定のスナップショットが自動的に削除されないようにするには、 スナップショットを永続的にするにはどうすればよいですか? を参照してください。

デフォルトのセットアップ(root)は、番号付きスナップショットと、空の事前/事後スナップショットのペアのクリーンアップを実行するように設定されています。クォータサポートが有効になっている場合、スナップショットは、ルートパーティションの使用可能なディスク容量を50%までしか占有できません。タイムラインスナップショットはデフォルトで無効になっているため、タイムラインのクリーンアップアルゴリズムも無効になっています。

7.6.1 番号付きスナップショットのクリーンアップ

番号付きスナップショット(管理スナップショットとインストールスナップショットのペア)のクリーンアップは、Snapper設定の次のパラメータで制御します。

NUMBER_CLEANUP

インストールスナップショットと管理スナップショットのペアのクリーンアップを有効または無効にします。有効にすると、スナップショットのペアは、スナップショットの合計数がNUMBER_LIMITまたはNUMBER_LIMIT_IMPORTANT 、あるいはその両方で指定された数を超え、「かつ」NUMBER_MIN_AGEで指定された保存期間を超えた場合に削除されます。有効な値: yes(はい) (有効)、no(いいえ) (無効)。

デフォルト値はyes (はい)です。

変更または設定を行うコマンドの例:

tux > sudo snapper -c CONFIG set-config "NUMBER_CLEANUP=no"
NUMBER_LIMIT / NUMBER_LIMIT_IMPORTANT

保持する通常のインストール/管理スナップショットのペア、または重要なインストール/管理スナップショットのペア、あるいはその両方の数を定義します。最も新しいスナップショットのみが保持されます。NUMBER_CLEANUP「no(いいえ)」に設定されている場合、無視されます。

デフォルト値は、NUMBER_LIMITでは「2-10」NUMBER_LIMIT_IMPORTANTでは「4-10」です。

変更または設定を行うコマンドの例:

tux > sudo snapper -c CONFIG set-config "NUMBER_LIMIT=10"
重要
重要: 範囲値と定数値の比較

クォータサポートが有効な場合は(7.6.5項 「ディスククォータサポートの追加」を参照)、制限を「最小値-最大値」の範囲として指定する必要があります。たとえば、2-10のように指定します。クォータサポートが無効な場合は、定数値(たとえば10)を指定する必要があります。そうしないと、エラーが発生してクリーンアップに失敗します。

NUMBER_MIN_AGE

スナップショットが自動削除の対象となるまでの最短期間を秒単位で定義します。ここで指定した期間に達していなければ、スナップショットはいくつ存在していても削除されません。

デフォルト値は1800です。

変更または設定を行うコマンドの例:

tux > sudo snapper -c CONFIG set-config "NUMBER_MIN_AGE=864000"
注記
注記: 制限と保存期間

NUMBER_LIMITNUMBER_LIMIT_IMPORTANT、およびNUMBER_MIN_AGEは常に評価されます。スナップショットが削除されるのは、「すべての」条件を満たしている場合のみです。

保存期間に関係なく、NUMBER_LIMIT*で定義された数のスナップショットを常に保持する場合は、NUMBER_MIN_AGE0に設定します。

次の例は、保存期間に関係なく最新の10個の重要なスナップショットと通常のスナップショットを保持するための設定を示しています。

NUMBER_CLEANUP=yes
NUMBER_LIMIT_IMPORTANT=10
NUMBER_LIMIT=10
NUMBER_MIN_AGE=0

一方、一定の保存期間を超えたスナップショットを保持しない場合は、NUMBER_LIMIT*0に設定し、NUMBER_MIN_AGEで保存期間を指定します。

次の例は、10日経っていないスナップショットのみを保持するための設定を示しています。

NUMBER_CLEANUP=yes
NUMBER_LIMIT_IMPORTANT=0
NUMBER_LIMIT=0
NUMBER_MIN_AGE=864000

7.6.2 タイムラインスナップショットのクリーンアップ

タイムラインスナップショットのクリーンアップは、Snapper設定の次のパラメータで制御します。

TIMELINE_CLEANUP

タイムラインスナップショットのクリーンアップを有効または無効にします。有効にすると、スナップショットは、スナップショットの合計数がTIMELINE_LIMIT_* で指定された数を超え、「かつ」TIMELINE_MIN_AGEで指定された保存期間を超える場合に削除されます。有効な値: yes(はい)no(いいえ)

デフォルト値はyes (はい)です。

変更または設定を行うコマンドの例:

tux > sudo snapper -c CONFIG set-config "TIMELINE_CLEANUP=yes"
TIMELINE_LIMIT_DAILYTIMELINE_LIMIT_HOURLYTIMELINE_LIMIT_MONTHLYTIMELINE_LIMIT_WEEKLYTIMELINE_LIMIT_YEARLY

1時間、1日、1週間、1カ月間、および1年間に保持するスナップショット数です。

各エントリのデフォルト値は「10」です。ただし、TIMELINE_LIMIT_WEEKLYは例外であり、デフォルトで「0」に設定されています。

TIMELINE_MIN_AGE

スナップショットが自動削除の対象となるまでの最短期間を秒単位で定義します。

デフォルト値は1800です。

例 7.1: タイムライン設定の例
TIMELINE_CLEANUP="yes"
TIMELINE_CREATE="yes"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_HOURLY="24"
TIMELINE_LIMIT_MONTHLY="12"
TIMELINE_LIMIT_WEEKLY="4"
TIMELINE_LIMIT_YEARLY="2"
TIMELINE_MIN_AGE="1800"

この設定例では、毎時スナップショットが自動的に削除されます。TIMELINE_MIN_AGETIMELINE_LIMIT_*は常に両方が評価されます。この例では、スナップショットが削除対象となるまでの最短保存期間が30分(1800秒)に設定されています。毎時のスナップショットを作成するので、最新のスナップショットだけが保持されることになります。TIMELINE_LIMIT_DAILYをゼロ以外に設定すると、1日の最初のスナップショットが保持されることになります。

保持されるスナップショット
  • 1時間ごと: 最新の24個のスナップショットが保持されます。

  • 1日ごと: 各日の最初に作成されたスナップショットが、直近の7日分保持されます。

  • 1カ月ごと: 各月の最後の日に作成された最初のスナップショットが、直近の12カ月分保持されます。

  • 1週ごと: 各週の最後の日に作成された最初のスナップショットが、直近の4週分保持されます。

  • 1年ごと: 各年の最後の日に作成された最初のスナップショットが、直近の2年分保持されます。

7.6.3 違いがないスナップショットのペアのクリーンアップ

7.1.1項 「スナップショットのタイプ」で説明したように、YaSTモジュールまたはZypperを実行すると、起動時に事前スナップショットが作成され、終了時に事後スナップショットが作成されます。変更を何も加えていない場合、事前スナップショットと事後スナップショットには違いがありません。Snapper設定で次のパラメータを設定することで、そのような空のスナップショットのペアを自動的に削除できます。

EMPTY_PRE_POST_CLEANUP

yes (はい)に設定した場合、違いがない事前および事後スナップショットのペアは削除されます。

デフォルト値はyes (はい)です。

EMPTY_PRE_POST_MIN_AGE

違いがない事前および事後スナップショットのペアが自動削除の対象となるまでの最短期間を秒単位で定義します。

デフォルト値は1800です。

7.6.4 手動で作成されたスナップショットのクリーンアップ

Snapperは、手動で作成されたスナップショットに対するカスタムクリーンアップアルゴリズムを備えていません。ただし、手動で作成されたスナップショットに、numberクリーンアップアルゴリズムまたはtimelineクリーンアップアルゴリズムを割り当てることができます。その場合、スナップショットは、指定されたアルゴリズムのクリーンアップキューに入ります。クリーンアップアルゴリズムは、スナップショットの作成時に指定することも、既存のスナップショットを変更して指定することもできます。

snapper create --description "Test" --cleanup-algorithm number

デフォルト(ルート)設定のスタンドアロンスナップショット(singleタイプ)を作成して、numberクリーンアップアルゴリズムを割り当てます。

snapper modify --cleanup-algorithm "timeline" 25

番号が25のスナップショットを変更して、クリーンアップアルゴリズムtimelineを割り当てます。

7.6.5 ディスククォータサポートの追加

上で説明したnumberクリーンアップアルゴリズムまたはtimelineクリーンアップアルゴリズム、あるいはその両方のほかに、Snapperはクォータもサポートします。スナップショットが占有できる使用可能な容量の割合を定義できます。この割合の値は常に、各Snapper設定で定義されたBtrfsサブボリュームに適用されます。

インストール時にSnapperを有効にした場合、クォータサポートは自動的に有効になっています。後から手動でSnapperを有効にする場合は、snapper setup-quotaを実行することでクォータサポートを有効にできます。そのためには有効な設定が必要です(詳細については、7.4項 「Snapper設定の作成と変更」を参照してください)。

クォータサポートは、Snapper設定の次のパラメータで制御します。

QGROUP

Snapperによって使用されるBtrfsクォータグループです。設定されていない場合は、snapper setup-quotaを実行します。すでに設定されている場合は、man 8 btrfs-qgroupについて十分理解している場合にのみ変更してください。この値はsnapper setup-quotaで設定されます。値を変更しないでください。

SPACE_LIMIT

スナップショットが使用できる容量の制限を、1を100%とする小数で指定します。値の範囲は0~1(0.1 = 10%、0.2 = 20%、...)です。

次の制限とガイドラインが適用されます。

  • クォータは、既存のnumberクリーンアップアルゴリズムまたはtimelineクリーンアップアルゴリズム、あるいはその両方に「追加」する形でのみアクティブ化されます。クリーンアップアルゴリズムがアクティブになっていない場合、クォータ制約は適用されません。

  • クォータサポートが有効な場合、Snapperは必要に応じてクリーンアップを2回実行します。最初の実行では、number スナップショットおよびtimelineスナップショットに対して指定されているルールを適用します。この実行後にクォータを超えた場合にのみ、2回目の実行でクォータ固有のルールが適用されます。

  • クォータサポートが有効になっていて、クォータを超えた場合でも、Snapperは常に、NUMBER_LIMIT*およびTIMELINE_LIMIT*の値で指定された数のスナップショットを保持します。したがって、NUMBER_LIMIT*およびTIMELINE_LIMIT*に対する値の範囲(MIN-MAX)を指定して、クォータを確実に適用できるようにすることをお勧めします。

    たとえば、NUMBER_LIMIT=5-20が設定されている場合、Snapperは、最初のクリーンアップを実行して、標準の番号付きスナップショットの数を20に減らします。これら20個のスナップショットがクォータを超えると、Snapperは、2回目の実行時に、クォータが満たされるまで最も古いスナップショットから順番に削除します。スナップショットが占有する容量にかかわらず、少なくとも5つのスナップショットは常に保持されます。

7.7 よくある質問とその回答

Snapperでは/var/log/tmpなどのディレクトリの変更が表示されませんが、なぜですか?

一部のディレクトリについては、スナップショットから除外することに決定しました。リストと理由については、7.1.2項 「スナップショットから除外されるディレクトリ」を参照してください。スナップショットからパスを除外するため、これらのパス用にサブボリュームを作成しています。

スナップショットはどのくらいのディスク容量を使用しますか? また、どうすればディスク容量を解放できますか?

現時点では、Btrfsツールで、スナップショットが使用するディスク容量を表示できません。ただし、クォータが有効な場合は、「すべての」スナップショットを削除した場合に解放される容量を判断できます。

  1. クォータグループIDを取得します(次の例の1/0)。

    tux > sudo snapper -c root get-config | grep QGROUP
    QGROUP                 | 1/0
  2. サブボリュームクォータを再スキャンします。

    tux > sudo btrfs quota rescan -w /
  3. クォータグループのデータを表示します(次の例の1/0)。

    tux > sudo btrfs qgroup show / | grep "1/0"
    1/0           4.80GiB    108.82MiB

    3番目の列に、すべてのスナップショットを削除した場合に解放される容量(108.82MiB)が表示されます。

スナップショットを含むBtrfsパーティションの容量を空けるには、ファイルではなく、不要なスナップショットを削除する必要があります。古いスナップショットは、最近のスナップショットよりも多くの領域を使用します。詳細については、7.1.3.4項 「スナップショットのアーカイブの制御」を参照してください。

あるサービスパックから別のサービスパックにアップグレードすると、多くのデータが変更される(パッケージのアップデート)ので、スナップショットにより、システムのサブボリュームで多くのディスク容量が使用されます。これらのスナップショットが不要になった場合は、手動で削除することをお勧めします。詳細については、7.5.4項 「スナップショットの削除」を参照してください。

ブートローダからスナップショットをブートできますか?

はい。詳細については、7.3項 「スナップショットからのブートによるシステムロールバック」を参照してください。

スナップショットを永続的にするにはどうすればよいですか?

現在のところ、Snapperでは、スナップショットが手動で削除されるのを防ぐ方法はありません。ただし、スナップショットがクリーンアップアルゴリズムによって自動的に削除されるのを防ぐことはできます。手動で作成されたスナップショット(7.5.2項 「スナップショットの作成」を参照)には、--cleanup-algorithmでクリーンアップアルゴリズムを指定しない限り、クリーンアップアルゴリズムは割り当てられていません。自動的に作成されたスナップショットには、常にnumberアルゴリズムまたはtimelineアルゴリズムが割り当てられています。1つ以上のスナップショットからそのような割り当てを削除するには、次の手順に従います。

  1. 使用可能なすべてのスナップショットの一覧を表示します。

    tux > sudo snapper list -a
  2. 削除されないようにするスナップショットの数を記憶します。

  3. 次のコマンドを実行します。数字のプレースホルダを、記憶した数に置き換えます。

    tux > sudo snapper modify --cleanup-algorithm "" #1 #2 #n
  4. もう一度snapper list -aを実行して、結果を確認します。変更したスナップショットの列Cleanupのエントリが空になります。

Snapperに関する詳細情報はどこで入手できますか?

Snapperのホームページ(http://snapper.io/)を参照してください。

8 VNCによるリモートアクセス

概要

VNC (Virtual Network Computing)では、グラフィカルなデスクトップを使用してリモートコンピュータを制御できます。これは、リモートシェルアクセスとは対照的です。VNCはプラットフォームに依存しないので、VNCを使用すれば、任意のオペレーティングシステムからリモートマシンにアクセスできます。

SUSE Linux Enterprise Serverでは、2種類のVNCセッションをサポートしています。1つはクライアントからのVNC接続が続く限り、存続する一時的セッションで、もう1つは明示的に終了されるまで存続する永続的セッションです。

注記
注記: セッションタイプ

両方のタイプのセッションを1つのコンピュータの異なるポートから同時に提供ができます。ただし、オープンセッションを1つのタイプからもう一方のタイプに変換することはできません。

8.1 vncviewerクライアント

サーバによって提供されるVNCサービスに接続するには、クライアントが必要です。SUSE Linux Enterprise Serverのデフォルトはvncviewerで、これはtigervncパッケージで提供されます。

8.1.1 vncviewer CLIを使用した接続

VNCビューアを起動し、サーバとのセッションを開始するには、次のコマンドを使用します。

tux > vncviewer jupiter.example.com:1

VNCディスプレイ番号の代わりに、2つのコロンを使用してポート番号を指定することもできます。

tux > vncviewer jupiter.example.com::5901
注記
注記: ディスプレイ番号とポート番号

VNCクライアントで実際に指定するディスプレイ番号またはポート番号は、ターゲットマシンでvncserverによって選択されるディスプレイ番号またはポート番号と同じである必要があります。詳細については、8.4項 「永続的VNCセッション」を参照してください。

8.1.2 vncviewer GUIを使用した接続

--listenまたは接続先ホストを指定せずにvncviewerを実行すると、接続の詳細を入力するよう求めるウィンドウが表示されます。8.1.1項 「vncviewer CLIを使用した接続」のようにVNC server (VNCサーバ)フィールドにホストを入力し、接続をクリックします。

vncviewerにより接続の詳細を入力するよう求められる
図 8.1: vncviewer

8.1.3 暗号化されていない接続の通知

VNCプロトコルは、さまざまな種類の暗号化接続をサポートしています。これをパスワード認証と混同しないでください。接続がTLSを使用していない場合、(Connection not encrypted!) (接続が暗号化されていません!)というテキストがVNCビューアのウィンドウタイトルに表示されることがあります。

8.2 Remmina: リモートデスクトップクライアント

Remminaは、最新の機能豊富なリモートデスクトップクライアントです。VNC、SSH、RDP、Spiceなど、複数のアクセス方法をサポートしています。

8.2.1 インストール

Remminaを使用するには、 remmina パッケージがシステムにインストールされているかどうかを確認し、インストールされていない場合はインストールします。Remmina用のVNCプラグインもインストールすることを忘れないでください。

root # zypper in remmina remmina-plugin-vnc

8.2.2 メインウィンドウ

remminaコマンドを入力してRemminaを実行します。

Remminaのメインウィンドウ
図 8.2: Remminaのメインウィンドウ

メインアプリケーションウィンドウには、保存されているリモートセッションのリストが表示されます。ここでは、新しいリモートセッションを追加および保存したり、保存せずに新しいセッションをクイックスタートしたり、以前に保存したセッションを開始したり、Remminaのグローバル設定を行うことができます。

8.2.3 リモートセッションの追加

新しいリモートセッションを追加して保存するには、メインウィンドウの左上にあるAdd new session (新しいセッションの追加)をクリックします。リモートデスクトップ初期設定ウィンドウが開きます。

リモートデスクトップ初期設定
図 8.3: リモートデスクトップ初期設定

新しく追加したリモートセッションプロファイルを指定するフィールドに入力します。最も重要な設定には次のものがあります。

名前

プロファイルの名前。この名前は、メインウィンドウにリストされます。

プロトコル

リモートセッションに接続するときに使用するプロトコル(VNCなど)。

サーバ

リモートサーバのIPアドレスまたはDNSアドレスとディスプレイ番号。

ユーザ名、パスワード

リモート認証に使用する資格情報。認証しない場合は空のままにします。

色数、品質

接続速度と品質に応じて最適なオプションを選択します。

より詳細な設定を入力するには、詳細タブを選択します。

ヒント
ヒント: 暗号の無効化

クライアントとリモートサーバ間の通信が暗号化されていない場合は、Disable encryption (暗号の無効化)を有効にします。そうしないと接続が失敗します。

高度なSSHトンネリングと認証オプションについては、SSHタブを選択してください。

保存をクリックして確定します。新しいプロファイルがメインウィンドウに表示されます。

8.2.4 リモートセッションの開始

以前に保存したセッションを開始するか、または接続の詳細を保存せずにリモートセッションをクイックスタートすることができます。

8.2.4.1 リモートセッションのクイックスタート

接続の詳細を適切に追加および保存することなく、リモートセッションをすばやく開始するには、メインウィンドウの上部にあるドロップダウンボックスとテキストフィールドを使用します。

クイックスタート
図 8.4: クイックスタート

ドロップダウンボックスから通信プロトコル(「VNC」など)を選択して、次にVNCサーバのDNSまたはIPアドレスを入力し、それに続けてコロンとディスプレイ番号を入力して、Enterで確定します。

8.2.4.2 保存されたリモートセッションを開く

特定のリモートセッションを開くには、セッションのリストからダブルクリックします。

8.2.4.3 リモートセッションウィンドウ

リモートセッションは別のウィンドウのタブで開きます。タブごとに1つのセッションをホストします。ウィンドウの左側にあるツールバーは、ウィンドウ/セッションの管理(フルスクリーンモードの切り替え、セッションの表示サイズに合わせたウィンドウのサイズ変更、セッションへの特定のキーストロークの送信、セッションのスクリーンショット撮影、画質の設定など)に役立ちます。

RemminaのSLES 15リモートセッションの表示
図 8.5: RemminaのSLES 15リモートセッションの表示

8.2.5 保存されたセッションの編集、コピー、および削除

保存されたリモートセッションを「編集」するには、Remminaのメインウィンドウでその名前を右クリックし、編集を選択します。関連するフィールドの説明については、8.2.3項 「リモートセッションの追加」を参照してください。

保存されたリモートセッションを「コピー」するには、Remminaのメインウィンドウでその名前を右クリックし、コピーを選択します。リモートデスクトップ初期設定ウィンドウで、プロファイルの名前を変更し、関連するオプションを必要なら調整し、保存をクリックして確定します。

保存されたリモートセッションを「削除」するには、Remminaのメインウィンドウでその名前を右クリックし、削除を選択します。次のダイアログではいをクリックして確定します。

8.2.6 コマンドラインからのリモートセッションの実行

最初にメインのアプリケーションウィンドウを開くことなく、コマンドラインまたはバッチファイルからリモートセッションを開く必要がある場合は、次の構文を使用します。

 tux > remmina -c profile_name.remmina

Remminaのプロファイルファイルは、ホームディレクトリの.local/share/remmina/ディレクトリに保存されます。開きたいセッションに属しているプロファイルファイルを決定するには、Remminaを実行し、メインウィンドウでセッション名をクリックし、下部のウィンドウのステータス行でプロファイルファイルへのパスを読み込みます。

プロファイルファイルへのパスの読み込み
図 8.6: プロファイルファイルへのパスの読み込み

Remminaが実行されていないときに、プロファイルファイルの名前をsle15.remminaなどのより合理的なファイル名に変更することができます。プロファイルファイルをカスタムディレクトリにコピーして、そこからremmina -cコマンドを使用して実行することもできます。

8.3 一時的VNCセッション

一時的セッションは、リモートクライアントによって開始されます。これにより、サーバにグラフィカルなログイン画面が開きます。この画面でセッションを開始するユーザを選択できます。さらに、ログインマネージャでサポートされている場合はデスクトップ環境も選択できます。そのようなVNCセッションへのクライアント接続を終了すると、そのセッション内で開始したアプリケーションもすべて終了します。一時的なVNCセッションは共用できませんが、1つのホストで同時に複数のセッションを実行することは可能です。

手順 8.1: 一時的VNCセッションの有効化
  1. まず、YaST › ネットワークサービス › リモート管理(VNC)の順に選択します。

  2. セッション管理機能無しのリモート管理を許可するをオンにします。

  3. WebブラウザウィンドウでVNCセッションにアクセスする場合は、Web ブラウザを利用したアクセスを有効にするをアクティブにします。

  4. 必要な場合は、ファイアウォールでポートを開くにもチェックマークを付けます (たとえば、ネットワークインタフェースを外部ゾーンに属するように設定する場合)。ネットワークインタフェースが複数ある場合は、ファイアウォールの詳細で、特定のインタフェースにだけファイアウォールポートを開くように制限します。

  5. 次へをクリックすると設定が確定し、

  6. 必要なパッケージの一部をまだ入手できない場合は、足りないパッケージのインストールを承認する必要があります。

    ヒント
    ヒント: ディスプレイマネージャの再起動

    YaSTはディスプレイマネージャの設定を変更します。現在のグラフィカルセッションからログアウトし、ディスプレイマネージャを再起動して変更を有効にする必要があります。

リモート管理
図 8.7: リモート管理

8.3.1 使用可能な設定

SUSE Linux Enterprise Serverのデフォルト設定では、1024x768ピクセルの解像度と16ビットの色数でセッションが提供されます。セッションで使用できるポートは、正規の VNCビューアの場合はポート5901(VNCディスプレイ1に相当)、Webブラウザの場合はポート5801です。

その他の設定は、異なるポートで使用できます。8.3.3項 「一時的VNCセッションを設定する」を参照してください。

VNCディスプレイ番号とXディスプレイ番号は、一時的セッションでは互いに独立しています。VNCディスプレイ番号は、サーバがサポートするすべての設定に手動で割り当てられます(上記の例では1)。VNCセッションは、設定の1つを使用して開始されるたびに、自動的に未使用のXディスプレイ番号を取得します。

デフォルトでは、VNCクライアントとサーバの両方が、インストール後に生成される自己署名SSL証明書を使用してセキュアな通信を試みます。デフォルトの証明書を使用することも、独自の証明書に置き換えることもできます。自己署名証明書を使用する場合は、最初に接続する前にその署名を確認する必要があります。

8.3.2 一時的VNCセッションを開始する

一時的VNCセッションに接続するには、VNCビューアをインストールする必要があります。8.1項 「vncviewerクライアント」も参照してください。

8.3.3 一時的VNCセッションを設定する

デフォルト設定を変更する必要も意志もない場合は、このセクションをスキップできます。

一時的VNCセッションは、systemdソケットxvnc.socketを介して開始されます。このファイルは、デフォルトで、6つの設定ブロックを提供します: VNCビューア用に3ブロック(vnc1からvnc3まで)、Javaアプレット用に3ブロック(vnchttpd1からvnchttpd3まで)。デフォルトでは、vnc1vnchttpd1だけが有効です。

ブート時にVNCサーバソケットをアクティブにするには、次のコマンドを実行します。

sudo systemctl enable xvnc.socket

すぐにソケットを起動するには、次のコマンドを実行します。

sudo systemctl start xvnc.socket

Xvncサーバは、server_argsオプションを介して設定できます。オプションのリストについては、Xvnc --helpを参照してください。

カスタム設定を追加する際には、それらの設定が、同じホスト上の他の設定、他のサービス、または既存の永続的VNCセッションですでに使用中のポートを使用しないことを確認してください。

設定の変更を有効にするには、次のコマンドを入力します:

tux > sudo systemctl reload xvnc.socket
重要
重要: ファイアウォールとVNCポート

手順8.1「一時的VNCセッションの有効化」で説明されているように、リモート管理をアクティブにすると、ファイアウォール内でポート5801および5901が開きます。VNCセッションで使用されるネットワークインタフェースがファイアウォールで保護されている場合、VNCセッションの追加ポートをアクティブにする際には各ポートを手動で開く必要があります。手順については、Book “Security Guide”, Chapter 15 “Masquerading and Firewalls”を参照してください。

8.4 永続的VNCセッション

永続的セッションは、複数のクライアントから同時にアクセスすることが可能です。この機能では、1つのクライアントがフルアクセスをもち、他のすべてのクライアントが表示専用アクセスを持つため、デモ用途に最適です。また、講師が受講生のデスクトップにアクセスする必要があるトレーニングでも使用できます。

ヒント
ヒント: 永続的VNCセッションに接続する

永続的VNCセッションに接続するには、VCNビューアをインストールする必要があります。詳細については、8.1項 「vncviewerクライアント」を参照してください。

永続的VNCセッションには次の2つのタイプがあります。

8.4.1 vncserverを使用して開始されたVNCセッション

このタイプの永続的VNCセッションは、サーバ上で開始されます。セッションとこのセッションで開始されたすべてのアプリケーションは、クライアント接続とは関わりなく、セッションが終了するまで実行されます。永続的セッションへのアクセスは、可能な2タイプのパスワードによって保護されます:

  • フルアクセスを付与する通常のパスワード。または、

  • 非対話的(表示オンリー)アクセスを付与するオプションの表示オンリーパスワード。

1つのセッションに、両方の種類のクライアント接続が一度に複数存在できます。

手順 8.2: vncserverを使用した永続的VNCセッションの開始
  1. シェルを開き、VNCセッションを所有するユーザとしてログインしていることを確認します。

  2. VNCセッションで使用されるネットワークインタフェースがファイアウォールで保護されている場合は、ファイアウォール内でセッションによって使用されるポートを手動で開く必要があります。複数のセッションを開始する場合は、一連のポートを開くことができます。ファイアウォールの設定方法の詳細については、Book “Security Guide”, Chapter 15 “Masquerading and Firewalls”を参照してください。

    vncserverは、ディスプレイ:1にはポート5901、ディスプレイ:2にはポート5902という順序でポートを使用します。永続的セッションの場合、VNCディスプレイとXディスプレイは、通常、同じ番号です。

  3. 1024x769ピクセルの解像度と16ビットの色数でセッションを開始するには、次のコマンドを入力します。

    vncserver -alwaysshared -geometry 1024x768 -depth 16

    vncserverコマンドは、何も指定されない場合、未使用のディスプレイ番号を選択し、その選択内容を出力します。追加オプションについては、man 1 vncserverを参照してください。

初めてvncserverを実行すると、セッションへのフルアクセス用パスワードが要求されます。必要な場合は、セッションへの表示オンリーアクセス用パスワードも入力できます。

ここで指定するパスワードは、同じユーザによって開始される今後のセッションにも使用されます。それらのパスワードは、vncpasswdコマンドで変更できます。

重要
重要: セキュリティ上の考慮事項

必ず、かなりの長さ(8文字以上)の強力なパスワードを使用してください。これらのパスワードは共用しないでください。

VNCセッションを終了するには、通常のローカルXセッションのシャットダウンのように、VNC環境内部で実行中のデスクトップ環境をVCNビューアからシャットダウンします。

セッションを手動で終了したい場合は、VNCサーバでシェルを開き、終了したいVNCセッションを所有するユーザとしてログインしていることを確認します。次のコマンドを実行して、ディスプレイ:1で実行されているセッションを終了します: vncserver -kill :1

8.4.1.1 永続的VNCセッションを設定する

永続的VNCセッションは、$HOME/.vnc/xstartupを編集することによって設定できます。デフォルトでは、このシェルスクリプトは、起動元と同じGUI/ウィンドウマネージャを起動します。SUSE Linux Enterprise Serverでは、これは、GNOMEまたはIceWMのいずれかです。好みのウィンドウマネージャでセッションを開始する場合は、変数WINDOWMANAGERを設定します。

WINDOWMANAGER=gnome vncserver -geometry 1024x768
WINDOWMANAGER=icewm vncserver -geometry 1024x768
注記
注記: ユーザごとに1つの設定

永続的VNCセッションは、ユーザごとの単一設定として設定されます。同じユーザが開始する複数のセッションでは、すべて同じ起動ファイルとパスワードファイルが使用されます。

8.4.2 vncmanagerを使用して開始されたVNCセッション

手順 8.3: 永続的VNCセッションの有効化
  1. まず、YaST › ネットワークサービス › リモート管理(VNC)の順に選択します。

  2. セッション管理機能付きのリモート管理を許可するをアクティブにします。

  3. WebブラウザウィンドウでVNCセッションにアクセスする場合は、Web ブラウザを利用したアクセスを有効にするをアクティブにします。

  4. 必要な場合は、ファイアウォールでポートを開くにもチェックマークを付けます (たとえば、ネットワークインタフェースを外部ゾーンに属するように設定する場合)。ネットワークインタフェースが複数ある場合は、ファイアウォールの詳細で、特定のインタフェースにだけファイアウォールポートを開くように制限します。

  5. 次へをクリックすると設定が確定します。

  6. 必要なパッケージの一部をまだ入手できない場合は、足りないパッケージのインストールを承認する必要があります。

    ヒント
    ヒント: ディスプレイマネージャの再起動

    YaSTはディスプレイマネージャの設定を変更します。現在のグラフィカルセッションからログアウトし、ディスプレイマネージャを再起動して変更を有効にする必要があります。

8.4.2.1 永続的VNCセッションを設定する

手順8.3「永続的VNCセッションの有効化」で説明したVNCセッション管理を有効にすると、通常、vncviewerやRemminaなどの好みのVNCビューアでリモートセッションに接続できます。ログイン画面が表示されます。ログインすると、デスクトップ環境のシステムトレイに「VNC」アイコンが表示されます。アイコンをクリックすると、VNCセッションウィンドウが開きます。表示されない場合、またはデスクトップ環境がシステムトレイのアイコンをサポートしていない場合は、手動でvncmanager-controllerを実行してください。

VNCセッション設定
図 8.8: VNCセッション設定

VNCセッションの動作に影響するいくつかの設定があります。

Non-persistent, private (非永続的、プライベート)

これは一時的セッションに相当します。このセッションは他のユーザに表示されず、セッションを切断すると終了します。詳細については、8.3項 「一時的VNCセッション」を参照してください。

Persistent, visible (永続的、可視)

このセッションは他のユーザに表示され、セッションを切断しても実行され続けます。

セッション名

ここで、永続的セッションの名前を指定して、再接続時に簡単に識別できるようにすることができます。

No password required (パスワード不要)

セッションに、ユーザの資格情報でログインすることなく、自由にアクセス可能です。

Require user login (ユーザログインが必要)

セッションにアクセスするには、有効なユーザ名とパスワードでログインする必要があります。Allowed users (許可されたユーザ)テキストボックスに有効なユーザ名を一覧表示します。

Allow one client at time (同時に1つのクライアントを許可)

複数のユーザによるセッションへの同時参加を無効にします。

Allow multiple clients at time (同時に複数のクライアントを許可)

複数のユーザが永続的セッションに同時に参加できるようにします。リモートプレゼンテーションまたはトレーニングなどに適切です。

OKをクリックして、確定します。

8.4.2.2 永続的VNCセッションへの参加

8.4.2.1項 「永続的VNCセッションを設定する」で説明した永続的VNCセッションを設定した後、VNCビューアでそのセッションに参加することができます。VNCクライアントからサーバに接続すると、新しいセッションを作成するか、既存のセッションに参加するかを選択するよう求めるプロンプトが表示されます。

永続的VNCセッションへの参加
図 8.9: 永続的VNCセッションへの参加

既存のセッションの名前をクリックすると、永続的セッションの設定に応じて、ログインアカウント情報の入力を求められることがあります。

8.5 暗号化されたVNC通信

VNCサーバが正しく設定されている場合、VNCサーバとクライアント間の通信はすべて暗号化されます。セッションの開始時に認証が行われ、実際のデータ転送はその後に開始されます。

一時的VNCセッションか永続的VNCセッションかにかかわらず、セキュリティオプションは、server_args行にある/usr/bin/Xvncコマンドの-securitytypesパラメータを介して設定されます。-securitytypesパラメータでは、認証方法と暗号化の両方を選択します。次のオプションがあります。

認証
None、TLSNone、X509None

認証なし。

VncAuth、TLSVnc、X509Vnc

カスタムパスワードを使用する認証。

Plain、TLSPlain、X509Plain

PAMを使用してユーザのパスワードを検証する認証。

暗号化
None、VncAuth、Plain

暗号化なし。

TLSNone、TLSVnc、TLSPlain

匿名のTLS暗号化。すべてが暗号化されますが、リモートホストの検証は行われません。したがって、受動的攻撃からは保護されますが、中間者攻撃からは保護されません。

X509None、X509Vnc、X509Plain

証明書によるTLS暗号化。自己署名証明書を使用する場合、初回接続時に証明書を検証するよう要求されます。以降の接続では、証明書が変更された場合にのみ警告が表示されます。したがって、初回接続時には中間者攻撃以外のすべての攻撃から保護されます(SSHの一般的な使用方法と同様)。マシン名に一致する認証局によって署名された証明書を使用すると、完全なセキュリティを実現できます(HTTPSの一般的な使用方法と同様)。

ヒント
ヒント: 署名とキーのパス

X509ベースの暗号化では、-X509Certオプションと-X509Keyオプションで、X509証明書とキーのパスを指定する必要があります。

複数のセキュリティタイプをカンマで区切って選択した場合、クライアントとサーバの両方でサポートおよび許可されているセキュリティタイプが使用されます。この方法により、サーバ上で日和見暗号化を設定できます。これは、暗号化をサポートしないVNCクライアントをサポートする必要がある場合に便利です。

暗号化が有効であることがわかっているサーバに接続する場合、クライアント側で、許可されているセキュリティタイプを指定してダウングレード攻撃を防止することもできます(ただし、この場合、vncviewerに「Connection not encrypted! (接続が暗号化されていません)」という警告メッセージが表示されます)。

9 rsyncによるファイルのコピー

概要

現在の通常のユーザは、複数のコンピュータ(家庭用および職場用のマシン、ラップトップ、スマートフォン、またはタブレット)を持っています。このため、複数のデバイス間でファイルとドキュメントを同期させることがますます重要になっています。

警告
警告: データ損失の危険

同期ツールの使用を開始する前に、その特徴や機能を十分に理解しておく必要があります。重要なファイルは必ずバックアップしてください。

9.1 概念の概要

低速なネットワーク接続で大量のデータを同期するために、rsyncは、ファイル内の変更のみを転送して信頼性を高めています。この処理は、テキストファイルのみでなくバイナリファイルも対象となります。ファイル間の差分を検出するために、rsyncはファイルをブロック単位で分割してチェックサムを計算します。

変更の検出には若干の処理能力が要求されます。そのため、両側のマシンにRAMなどのリソースが十分あることを確認してください。

rsyncが特に役立つのは、わずかな変更しかない大量のデータを定期的に転送する必要がある場合です。多くの場合、バックアップの操作がこれに該当します。また、rsyncは、Webサーバのディレクトリツリー全体を格納するステージングサーバをDMZ内のWebサーバにミラーリングする場合にも便利です。

その名前に反して、rsyncは同期ツールではありません。データを一度に一方向にのみコピーするツールです。その逆にはコピーせず、コピーすることもできません。コピー元とコピー先の両方を同期できる双方向ツールが必要な場合は、Csyncを使用してください。

9.2 基本的な構文

rsyncは、次の基本的な構文を持つコマンドラインツールです。

rsync [OPTION] SOURCE [SOURCE]... DEST

アクセスパーミッションと書き込みパーミッションがあれば、ローカルマシンでもリモートマシンでも使用できます。複数のSOURCEエントリを指定できます。SOURCEおよびDESTのプレースホルダには、パス、URL、またはその両方を指定できます。

rsyncで最もよく使われるオプションは次のとおりです。

-v

より詳細なテキストを出力します。

-a

アーカイブモード。ファイルを再帰的にコピーし、タイムスタンプ、ユーザ/グループの所有権、ファイルパーミッション、およびシンボリックリンクを保持します。

-z

転送データを圧縮します。

注記
注記: 末尾のスラッシュの数

rsyncを操作する場合は、特に末尾のスラッシュに注意する必要があります。ディレクトリの後に末尾のスラッシュがある場合、そのスラッシュはディレクトリの「内容」を示します。末尾のスラッシュがない場合は、「ディレクトリそのもの」を表します。

9.3 ファイルとディレクトリのローカルでのコピー

次の説明は、現在のユーザがディレクトリ/var/backupに対する書き込みパーミッションを持っていることを想定しています。1つのファイルをマシン上のディレクトリから別のパスにコピーするには、次のコマンドを使用します。

tux > rsync -avz backup.tar.xz /var/backup/

ファイルbackup.tar.xz/var/backup/にコピーされ、絶対パスは/var/backup/backup.tar.xzになります。

/var/backup/ディレクトリの後に「末尾のスラッシュ」を追加するのを忘れないでください。スラッシュを挿入しない場合、ファイルbackup.tar.xzは、ディレクトリ/var/backup/「中ではなく」、/var/backup (ファイル)にコピーされます。

ディレクトリをコピーする場合も、1つのファイルをコピーする場合と同様です。次の例では、ディレクトリtux/とその内容をディレクトリ/var/backup/にコピーします。

tux > rsync -avz tux /var/backup/

コピーは絶対パス/var/backup/tux/にあります。

9.4 ファイルとディレクトリのリモートでのコピー

両方のマシンにrsyncツールが必要です。リモートディレクトリ間でファイルをコピーするには、IPアドレスまたはドメイン名が必要です。ローカルマシンとリモートマシンの現在のユーザ名が同じ場合、ユーザ名は省略できます。

ファイルfile.tar.xzをローカルホストからリモートホスト192.168.1.1に同じユーザ(ローカルとリモート)でコピーするには、次のコマンドを使用します。

tux > rsync -avz file.tar.xz  tux@192.168.1.1:

好みに応じて、次のコマンドを使用することもできます。処理結果は同じです。

tux > rsync -avz file.tar.xz 192.168.1.1:~
tux > rsync -avz file.tar.xz 192.168.1.1:/home/tux

標準設定では、すべての場合に、リモートユーザのパスフレーズの入力を求めるプロンプトが表示されます。このコマンドは、file.tar.xzをユーザtuxのホームディレクトリ(通常は/home/tux)にコピーします。

ディレクトリをリモートでコピーする場合も、ローカルでコピーする場合と同様です。次の例では、ディレクトリtux/とその内容をホスト192.168.1.1のリモートディレクトリ/var/backup/にコピーします。

tux > rsync -avz tux 192.168.1.1:/var/backup/

ホスト192.168.1.1で書き込みパーミッションを持っていると想定すると、コピーは絶対パス/var/backup/tuxにあります。

9.5 rsyncサーバの設定と使用

rsyncは、デフォルトポート873で着信接続をリスンするデーモン(rsyncd)として実行できます。このデーモンはコピーターゲットを受信できます。

次に、jupiter上に「バックアップ」ターゲットを持つrsyncサーバを作成する方法を説明します。このターゲットを使用してバックアップを保存できます。rsyncサーバを作成するには、以下の手順を実行します。

手順 9.1: rsyncサーバの設定
  1. jupiterで、すべてのバックアップファイルを保存するディレクトリを作成します。この例では、/var/backupを使用します。

    root # mkdir /var/backup
  2. 所有権を指定します。この場合、ディレクトリはグループusersのユーザtuxによって所有されます。

    root # chown tux.users /var/backup
  3. rsyncdデーモンを設定します。

    設定ファイルを、メインファイルと、バックアップターゲットを格納する複数のモジュールに分割します。こうすることで、後で他のターゲットを簡単に追加できます。グローバル値は/etc/rsyncd.d/*.incファイルに保存できます。一方、モジュールは/etc/rsyncd.d/*.confファイルに配置します。

    1. ディレクトリ/etc/rsyncd.d/を作成します。

      root # mkdir /etc/rsyncd.d/
    2. メイン設定ファイル/etc/rsyncd.confに、次の行を追加します。

      # rsyncd.conf main configuration file
      log file = /var/log/rsync.log
      pid file = /var/lock/rsync.lock
      
      &merge /etc/rsyncd.d 1
      &include /etc/rsyncd.d 2

      1

      グローバル値を/etc/rsyncd.d/*.incファイルからメイン設定ファイルにマージします。

      2

      モジュール(またはターゲット)を/etc/rsyncd.d/*.confファイルからロードします。これらのファイルにはグローバル値への参照を含めないでください。

    3. 次の行を使用して、ファイル/etc/rsyncd.d/backup.conf内にモジュール(バックアップターゲット)を作成します。

      # backup.conf: backup module
      [backup] 1
         uid = tux 2
         gid = users 2
         path = /var/backup 3
         auth users = tux  4
         secrets file = /etc/rsyncd.secrets 5
         comment = Our backup target

      1

      「バックアップ」ターゲット。好きな名前を使用できます。ただし、ターゲットには用途に応じた名前を付け、*.confファイルと同じ名前を使用することをお勧めします。

      2

      ファイル転送の実行時に使用されるユーザ名またはグループ名を指定します。

      3

      バックアップを保存するパスを定義します(ステップ 1から)。

      4

      許可されているユーザのカンマ区切りリストを指定します。最も単純な形式では、このモジュールへの接続を許可されているユーザ名が含まれます。この例では、ユーザtuxのみが許可されています。

      5

      ユーザ名とプレーンパスワードが記述された行が含まれるファイルのパスを指定します。

    4. 次の内容で/etc/rsyncd.secretsファイルを作成し、PASSPHRASEを置き換えます。

      # user:passwd
      tux:PASSPHRASE
    5. rootのみがこのファイルを読み込めるようにします。

      root # chmod 0600 /etc/rsyncd.secrets
  4. 次のコマンドを使用して、rsyncdデーモンを起動して有効にします。

    root # systemctl enable rsyncd
    root # systemctl start rsyncd
  5. rsyncサーバにアクセスできるかどうかをテストします。

    tux > rsync jupiter::

    次のような応答が表示されます。

    backup          Our backup target

    異なる場合は、設定ファイル、ファイアウォール設定、およびネットワーク設定を確認してください。

上記の手順でrsyncサーバが作成されたので、このサーバを使用してバックアップを保存できます。この例では、すべての接続を示すログファイルも作成されます。このファイルは/var/log/rsyncd.logに格納されます。これは、転送をデバッグする場合に便利です。

バックアップターゲットの内容を一覧にするには、次のコマンドを使用します。

rsync -avz jupiter::backup

このコマンドを入力すると、サーバのディレクトリ/var/backupにあるファイルがすべて一覧表示されます。このリクエストはログファイル/var/log/rsyncd.logにも記録されます。実際の転送を開始するには、ソースディレクトリを指定します。現在のディレクトリには.を使用してください。たとえば、次のコマンドは、現在のディレクトリをrsyncバックアップサーバにコピーします。

rsync -avz . jupiter::backup

デフォルトでは、rsyncは実行時にファイルとディレクトリを削除しません。削除を有効にするには、追加オプション--deleteを記述する必要があります。新しい方のファイルが削除されないように、代わりにオプション--updateを使用することもできます。競合が発生した場合は、手動で解決する必要があります。

9.6 詳細情報

CSync

双方向ファイル同期ツール。https://www.csync.org/を参照してください。

RSnapshot

増分バックアップを作成します。http://rsnapshot.orgを参照してください。

Unison

CSyncに似たファイル同期ツールですが、グラフィカルインタフェースを備えています。http://www.seas.upenn.edu/~bcpierce/unison/を参照してください。

Rear

障害復旧フレームワーク。SUSE Linux Enterprise High Availability Extensionの『Administration Guide』 (https://www.suse.com/documentation/sle-ha-12/)を参照してください。

パート II Linuxシステムのブート

10 ブートプロセスの概要

Linuxシステムのブートには、さまざまなコンポーネントとタスクが関係しています。マシンのアーキテクチャに依存する、ファームウェアとハードウェアの初期化プロセスの後、ブートローダGRUB 2でカーネルを起動します。この時点以降、ブートプロセスは完全にオペレーティングシステムの制御下に入り、systemdによって処理されます。systemdは、日常的な使用、保守、または緊急時のために設定をブートする一連のターゲットを提供します。

11 UEFI (Unified Extensible Firmware Interface)

UEFI (Unified Extensible Firmware Interface) は、システムハードウェアに付属のファームウェア、システムのすべてのハードウェアコンポーネント、およびオペレーティングシステムの間のインタフェースです。

12 ブートローダGRUB 2

この章では、SUSE® Linux Enterprise Serverで使用されているブートローダGRUB 2の設定方法について説明します。これは、現在GRUB Legacyと呼ばれる従来のGRUBブートローダの後継バージョンです。GRUB 2は、SUSE® Linux Enterprise Serverのバージョン 12以降でデフォルトのブートローダとして使用されています。YaSTモジュールは、最も重要な設定を行うために使用できます。ブート手順は、総じて第10章 「ブートプロセスの概要で説明しています。UEFIマシンでのセキュアブートのサポートの詳細については、第11章 「UEFI (Unified Extensible Firmware Interface)を参照してください。

13 systemdデーモン

プログラムsystemdは、プロセスID 1のプロセスであり、要求された方法でシステムを初期化します。systemdはカーネルによって直接起動され、通常はプロセスを強制終了するシグナル9が使えないようにします。他のすべてのプログラムは、systemdまたは子プロセスのいずれかによって直接起動されます。

10 ブートプロセスの概要

概要

Linuxシステムのブートには、さまざまなコンポーネントとタスクが関係しています。マシンのアーキテクチャに依存する、ファームウェアとハードウェアの初期化プロセスの後、ブートローダGRUB 2でカーネルを起動します。この時点以降、ブートプロセスは完全にオペレーティングシステムの制御下に入り、systemdによって処理されます。systemdは、日常的な使用、保守、または緊急時のために設定をブートする一連のターゲットを提供します。

10.1 用語集

この章ではあいまいに解釈される可能性のある用語を使用します。ここでの使用方法を理解するには、以下の定義を読んでください。

init

一般的にinitという名前が付くのは、次の2つの異なるプロセスです。

  • ルートファイルシステムをマウントするinitramfsプロセス

  • 実際のルートファイルシステムから実行される他のすべてのプロセスを開始するオペレーティングシステムプロセス

両方のケースで、systemdプログラムがこのタスクを担当します。ルートファイルシステムをマウントするには、まずinitramfsから実行されます。成功したら、最初のプロセスとしてルートファイルシステムから再実行されます。これら2つのsystemdプロセスの混同を避けるため、まず「init on initramfs」として最初のプロセスを実行し、「systemd」として2番目のプロセスを実行します。

initrd / initramfs

initrd (最初のRAMディスク)は、カーネルによってロードされ、一時ルートファイルシステムとして/dev/ramからマウントされるルートファイルシステムイメージを含むイメージファイルです。ファイルシステムのマウントには、ファイルシステムドライバが必要です。

カーネル2.6.13以降、initrdは、ファイルシステムドライバのマウントが必要ない、initramfs (最初のRAMファイルシステム)で置き換えられました。SUSE Linux Enterprise Serverは排他的にinitramfsを使用します。ただし、initramfs/boot/initrdとして格納されるため、initrdと呼ばれることが多いです。この章では、initramfsという名前を排他的に使用します。

10.2 Linuxのブートプロセス

Linuxのブートプロセスは、いくつかの段階から成り、それぞれ別のコンポーネントが実行しています。

10.2.1 初期化とブートローダの段階

初期化段階中に、マシンのハードウェアが設定され、デバイスが準備されます。このプロセスはハードウェアアーキテクチャ間で大きく異なります。

SUSE Linux Enterprise Serverは、すべてのアーキテクチャでブートローダGRUB 2を使用します。アーキテクチャおよびファームウェアによって、GRUB 2ブートローダの起動は、 マルチステップのプロセスとなる可能性があります。ブートローダの目的は、カーネルおよび、RAMベースの初期ファイルシステム(initramfs)をロードすることです。GRUB 2についての詳細については、第12章 「ブートローダGRUB 2を参照してください。

10.2.1.1 AArch64およびAMD64/Intel 64での初期化とブートローダ段階

コンピュータの電源をオンにした後、BIOSまたはUEFIが画面とキーボードを初期化し、メインメモリをテストします。この段階まで、コンピュータは大容量ストレージメディアにアクセスしません。続いて、現在の日付、時刻、および最も重要な周辺機器に関する情報が、CMOS値からロードされます。ブートメディアとそのジオメトリが認識されると、システム制御がBIOS/UEFIからブートローダに移ります。

従来のBIOSが備わっているマシンでは、ブートディスクの先頭の 512バイト物理データセクタ(マスタブートレコード、MBR)のコードのみをロードできます。最小のGRUB 2のみがMBRに適合します。その唯一の目的は、MBRと最初のパーティション(MBRパーティションテーブル)の間のギャップから、またはBIOSブートパーティション(GPTパーティションテーブル)からファイルシステムドライバを含むGRUB 2コアイメージをロードすることです。このイメージにはファイルシステムドライバが含まれるため、ルートファイルシステム上にある/bootにアクセスできます。/bootには、カーネルとinitramfsイメージとともに、GRUB 2コアの追加のモジュールも含まれます。このパーティションにアクセスすると、GRUB 2はカーネルをロードし、initramfsはメモリにイメージを作成し、カーネルに制御を移します。

BIOSシステムが、暗号化された/bootパーティションを含む暗号化されたファイルシステムからブートする場合、復号化のパスワードを2度入力する必要があります。最初にGRUB 2によって/bootを復号化した後で、systemd用に暗号化されたボリュームをマウントする必要があります。

UEFIを搭載したマシンでは、従来のBIOSを搭載するマシンよりも、ブートプロセスははるかに簡単です。ファームウェアは、GPTパーティションテーブルを備えたディスクのFATでフォーマットされたシステムパーティションから読み取ることができます。このEFIシステムパーティション(/boot/efiとしてマウントされる実行中のシステム)は、ファームウェアによって直接ロードされ実行される完全に装備されたGRUB 2をホストする十分なスペースを保持します。

BIOS/UEFIがネットワークブートをサポートしている場合は、ブートローダを提供するブートサーバを設定することもできます。その後、システムはPXEを介してブートできます。 BIOS/UEFIはブートローダとして動作します。BIOSは、ブートサーバからブートイメージを取得し、システムを起動します。この作業はローカルハードディスクから完全に独立した処理として行われます。

10.2.1.2 IBM z Systemsでの初期化とブートローダ段階

IBM z Systemsでは、ブートプロセスは、zipl (zイニシャルプログラムロード)と呼ばれるブートローダによって初期化される必要があります。ziplはさまざまなファイルシステムからの読み込みをサポートしますが、SLEデフォルトファイルシステム(Btrfs)またはスナップショットからのブートはサポートしません。したがって、SUSE Linux Enterprise Serverはブート時に完全なBtrfsサポートを保証する2段階のブートプロセスを使用します。

  1. ziplは、ext2でフォーマットされたパーティション/boot/ziplからブートします。このパーティションには、メモリにロードされる最小のカーネルとinitramfsが含まれます。initramfsには、Btrfsドライバ(その他の間)およびブートローダGRUB 2が含まれます。カーネルはinitgrubパラメータで開始され、GRUB 2を開始するように指示されます。

  2. カーネルはルートファイルシステムをマウントするため、/bootにアクセス可能になります。これでGRUB 2がinitramfsから開始されます。GRUB 2は/boot/grub2/grub.cfgからその設定を読み込み、/bootから最後のカーネルとinitramfsをロードします。これで新しいカーネルがKexecを介してロードされます。

10.2.2 カーネルの段階

ブートローダがシステム制御に渡されると、ブートプロセスはすべてのアーキテクチャで同じになります。ブートローダはカーネルとRAMベースの初期ファイルシステム(initramfs)をメモリにロードし、カーネルが引き継ぎます。

カーネルはメモリ管理を設定し、CPUタイプとその機能を検出した後で、ハードウェアを初期化し、initramfsでロードされたメモリから一時ルートファイルシステムをマウントします。

10.2.2.1 initramfsファイル

initramfs(初期RAMファイルシステム)は、カーネルがRAMディスクにロードできる、小さなcpioアーカイブです。/boot/initrdにあります。dracutというツールで作成することもできます。詳細については、man 8 dracutを参照してください。

initramfsは、実際のルートファイルシステムがマウントされる前にプログラムを実行できるようにする最低限のLinux環境を提供します。この最低限のLinux環境は、BIOSまたはUEFIルーチンによってメモリにロードされ、十分なメモリがあること以外に特定のハードウェア要件はありません。initramfsには必ず、initという名前の実行可能ファイルがあります。これは、ブートプロセスの進行に伴い、ルートファイルシステム上の実際のsystemdデーモンを実行します。

ルートファイルシステムをマウントして実際のオペレーティングシステムを起動する前に、カーネルには、ルートファイルシステムが配置されているデバイスにアクセスするための対応ドライバが必要です。こうしたドライバには、特定のハードディスク用の特殊なドライバや、ネットワークファイルシステムにアクセスするためのネットワークドライバが含まれる場合もあります。ルートファイルシステムに必要なモジュールは、initramfs上のinitによってロードされます。モジュールをロードしたら、udevによって必要なデバイスがinitramfsに提供されます。ブートプロセス後半で、ルートファイルシステムが変更された後、デバイスを再生成する必要があります。これは、systemd unit systemd-udev-trigger.serviceで実行されます。

10.2.2.1.1 initramfsの再生成

initramfsには、ドライバが含まれるため、そのドライバのいずれかの新しいバージョンが利用可能になるとすぐにinitramfsをアップデートする必要があります。これは、ドライバアップデートを含むパッケージをインストールするときに自動的に実行されます。YaSTまたはzypperは、initramfsを生成するコマンドの出力を表示することで、これについて通知します。ただし、initramfsを手動で再生成する必要がある場合があります。

ハードウェアの変更によるドライバの追加

ハードウェア(たとえば、ハードディスク)を変更する必要が生じ、ブート時にそのハードウェア用の他のドライバがカーネル内に必須の場合には、initramfsファイルを更新する必要があります。

/etc/dracut.conf.d/01-dist.confを編集し(または存在しない場合は作成し)、次の行を追加します。

force_drivers+="DRIVER1"

DRIVER1はドライバのモジュール名で置き換えます。複数のドライバを追加する必要がある場合は、それぞれをスペースで区切って指定します。

force_drivers+="DRIVER1 DRIVER2"

手順10.1「initramfsの生成」に従って手順を進めます。

RAIDまたはLVMへのシステムディレクトリの移動

スワップファイル、または実行中のシステムの/usrなどのシステムディレクトリをRAIDまたは論理ボリュームに移動するときには常に、ソフトウェアRAIDまたはLVMドライバのサポートを含むinitramfsを作成する必要があります。

これを作成するには、/etc/fstabで各エントリを作成し、新しいエントリ(たとえばmount -aおよび/またはswapon -a)をマウントします。

手順10.1「initramfsの生成」に従って手順を進めます。

ルートファイルシステムを含むLVMグループ/Btrfs RAIDへのディスクの追加

ルートファイルシステムを含む論理ボリュームグループまたはBtrfs RAIDにディスクを追加(または削除)する際には常に、 大きくなったボリュームのサポートを含むinitramfsを作成する必要があります。手順10.1「initramfsの生成」の指示に従います。

手順10.1「initramfsの生成」に従って手順を進めます。

カーネル変数の変更

関連するファイル(/etc/sysctl.confまたは/etc/sysctl.d/*.conf)を編集して、sysctlインタフェースでカーネル変数の値を変更した場合、次にシステムを再起動したときに変更内容が失われます。実行時にsysctl --systemを使用して値をロードしても、変更内容はinitramfsファイルに保存されません。手順10.1「initramfsの生成」の説明に従って手順を進め、アップデートする必要があります。

手順 10.1: initramfsの生成

次の手順のすべてのコマンドをユーザrootとして実行する必要があることに注意してください。

  1. 以下を実行して新しいinitramfsファイルを生成します

    dracut MY_INITRAMFS

    MY_INITRAMFSを選択したファイル名で置き換えます。 新しいinitramfs/boot/MY_INITRAMFSとして作成されます。

    または、dracut -fを実行します。これにより現在使用されている既存のファイルが上書きされます。

  2. (以前のステップでdracut -fを実行した場合は、このステップはスキップします)。以前のステップで作成したinitramfsファイルへのリンクを作成します。

    (cd /boot && ln -sf MY_INITRAMFS initrd)
  3. IBM z Systemsアーキテクチャで、補足的にgrub2-installを実行します。

10.2.3 initramfs上のinit段階

initramfsからカーネルによってマウントされた一時ルートファイルシステムには、(以下のinitramfs上のinitと呼ばれる)実行可能なsystemdが含まれます。10.1項 「用語集」も参照してください。このプログラムは、適切なルートファイルシステムをマウントするために必要なすべてのアクションを実行します。必要なファイルシステムにカーネル機能を提供し、大容量ストレージコントローラ用のデバイスドライバにudevを提供します。

initramfs上のinitの主な目的は、実際のルートファイルシステムのマウントとアクセスの準備をすることです。システム設定に応じて、initramfs上のinitは次のタスクを実行します。

カーネルモジュールのロード

ハードウェア設定によっては、使用するコンピュータのハードウェアコンポーネント(ハードディスクになる最も重要なコンポーネント)にアクセスするために特殊なドライバが必要になる場合があります。最終的なルートファイルシステムにアクセスするには、カーネルが適切なファイルシステムドライバをロードする必要があります。

ブロック特殊ファイルの提供

カーネルはロードされたモジュールに応じて、デバイスイベントを生成します。udevは、これらのイベントを処理し、RAMファイルシステム上で必要なブロック特殊ファイルを/dev内に生成します。これらの特殊ファイルがないと、ファイルシステムや他のデバイスにアクセスできません。

RAIDとLVMのセットアップの管理

RAIDまたはLVMの下でルートファイルシステムを保持するようにシステムを設定した場合、initramfs上のinitはLVMまたはRAIDを設定して、後でルートファイルシステムにアクセスできるようにします。

ネットワーク設定の管理

ネットワークマウントしたルートファイルシステム(NFSを介してマウント)を使用するようにシステムを設定した場合、initは適切なネットワークドライバがロードされ、ドライバがルートファイルシステムにアクセスできるように設定されていることを確認する必要があります。

ファイルシステムがiSCSIやSANなどのネットワークブロックデバイスに常駐している場合は、ストレージサーバへの接続もinitramfs上のinitによって設定されます。SUSE Linux Enterprise Serverは、プライマリターゲットを使用できない場合の、セカンダリiSCSIターゲットからのブートをサポートしています。iSCSIターゲットのブート設定の詳細については、Book “ストレージ管理ガイド”, Chapter 14 “IPネットワークの大容量記憶域 - iSCSI”, Section 14.3.1 “YaSTを使ったiSCSIイニシエータの設定”を参照してください。

注記
注記: マウントできなかった場合の処理

ルートファイルシステムをブート環境内からマウントできなかった場合は、ブートを続行する前にルートファイルシステムを確認して修復しておく必要があります。Ext3ファイルシステムおよびExt4ファイルシステムでは、ファイルシステムチェッカが自動的に起動されます。XFSファイルシステムおよびBtrfsファイルシステムでは修復プロセスが自動化されていないため、ファイルシステムを修復するために使用できるオプションに関する情報が表示されます。ファイルシステムが正常に修復された場合、ブート環境を終了すると、システムはルートファイルシステムのマウントを再試行します。成功した場合、ブートは通常どおり続行されます。

10.2.3.1 インストールプロセスのinitramfs上のinit段階

初期ブート時にインストールプロセスの一環としてinitramfs上のinitが呼び出される場合、そのタスクは上記で説明したタスクと異なります。インストールシステムはinitramfsからsystemdを起動せず、これらのタスクがlinuxrcで実行されることにも注意してください。

インストールメディアの検出

インストールプロセスを開始すると、マシンは、インストールカーネルと、YaSTインストーラを含む特殊なinitをロードします。YaSTインストーラは、RAMファイルシステムで実行され、インストールメディアにアクセスしてオペレーティングシステムをインストールするために、そのメディアの場所に関する情報を必要とします。

ハードウェア認識の開始および適切なカーネルモジュールのロード

10.2.2.1項 「initramfsファイル」で説明しているように、ブートプロセスはほとんどのハードウェア構成で使用できる最小限のドライバセットで開始されます。AArch64、POWER、およびAMD64/Intel 64マシンでは、linuxrcは、ハードウェア構成に適したドライバセットを判断する、初期ハードウェアスキャンプロセスを開始します。IBM z Systemsでは、ドライバのリストおよびそのパラメータは、linuxrcまたはparmfileなどを介して提供される必要があります。

これらのドライバは、システムをブートするために必要なカスタムinitramfsを生成するために使用されます。ブートに必要なくてもコールドプラグには必要なモジュールがある場合は、systemdを使用してロードできます。詳細については、13.6.4項 「カーネルモジュールのロード」を参照してください。

インストールシステムのロード

ハードウェアが適切に認識されると、適切なドライバがロードされます。udevプログラムが特殊なデバイスファイルを作成し、linuxrcは、YaSTインストーラを使用してインストールシステムを起動します。

YaSTの起動

最後に、linuxrcはYaSTを起動し、これによってパッケージのインストールとシステム設定が開始されます。

10.2.4 systemd段階

実際のルートファイルシステムが見つかると、エラーをチェックしてからマウントします。 これが正常に実行されれば、initramfsはクリアされ、ルートファイルシステムでsystemdデーモンが実行されます。systemdはLinuxのシステムおよびサービスマネージャです。PID 1として起動する親プロセスで、ユーザスペースサービスを起動して維持するinitシステムとして機能します。詳細については、第13章 「systemdデーモンを参照してください。

11 UEFI (Unified Extensible Firmware Interface)

UEFI (Unified Extensible Firmware Interface) は、システムハードウェアに付属のファームウェア、システムのすべてのハードウェアコンポーネント、およびオペレーティングシステムの間のインタフェースです。

UEFIは、従来のPC-BIOSに代わって、PCで幅広く利用されるようになっています。例えば、UEFIは64ビットシステムを適切にサポートし、最も重要な機能の1つである安全なブート(セキュアブート、ファームウェアバージョン2.3.1c以降が必要)を提供します。最後に、UEFIを使用すると、すべてのx86プラットフォームで標準のファームウェアが利用可能になります。

さらに、UEFIには以下の利点があります。

  • GUIDパーティションテーブル(GPT)を使う大きなディスク(2 TiB以上)からのブート。

  • CPUに依存しないアーキテクチャおよびドライバ。

  • ネットワーク機能を持つ柔軟なプレOS環境。

  • PC-BIOSライクなエミュレーション経由でレガシーオペレーティングシステムのブートをサポートするCSM(Compatibiity Support Module)。

詳細については、http://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interfaceを参照してください。以降のセクションは、UEFIの一般的な概要を示すものではなく、特定の機能がSUSE Linux Enterprise Serverにどのように実装されているかを示すヒントです。

11.1 セキュアブート

UEFIの世界では、ブートストラッププロセスの保護とは、信頼チェーンの確立を意味します。SUSE Linux Enterprise Serverとの関連では、プラットフォームはこの信頼チェーンのルートであり、マザーボードおよびオンボードファームウェアがプラットフォームとみなされます。別の言い方をすれば、ハードウェアベンダー、およびそのハードウェアベンダーからコンポーネントの製造元やOSベンダーなどにつながる信頼チェーンです。

信頼は公開鍵の暗号で表されます。ハードウェアベンダーは、ファームウェアにいわゆるプラットフォームキー(PK)を設定し、信頼のルートを表します。オペレーティングシステムベンダーなどとの信頼関係は、このプラットフォームキーを使ってキーに署名することによって文書化されます。

最後に、これらの信頼されたキーのいずれかで署名されていない限りファームウェアがコード(OSブートローダも、PCI Expressカードやディスクのフラッシュメモリに保存されたドライバも、ファームウェアのアップデートも)を実行できないようにすることによって、セキュリティが確立されます。

セキュアブートを使用するには、ファームウェアによって信頼されたキーで署名されたOSローダが必要であり、読み込むカーネルが信頼できることを検証するためにOSローダが必要です。

キー交換キー(KEK)をUEFIキーデータベースに追加できます。この方法で、PKのプライベート部分で署名されている限り、他の証明書を使用できます。

11.1.1 SUSE Linux Enterprise Serverへの実装

Microsoftのキー交換キー(KEK)がデフォルトでインストールされます。

注記
注記: GUIDパーティションテーブル(GPT)が必要

セキュアブート機能は、UEFI/x86_64インストール環境ではデフォルトで有効になっています。Enable Secure Boot Support(セキュアブートサポートの有効化)オプションは、ブートローダの設定ダイアログのBoot Code Options(ブートコードオプション)タブにあります。ファームウェアでセキュアブートが有効になっている場合のブート、および無効になっている場合のブートもサポートします。

セキュアブートサポート
図 11.1: セキュアブートサポート

セキュアブート機能を使用するには、マスタブートレコード(MBR)を使用した古いパーティションをGUIDパーティションテーブル(GPT)に置換する必要があります。YaSTは、インストール時にEFIモードを検出すると、GPTパーティションの作成を試みます。UEFIでは、FATフォーマットのEFIシステムパーティション(ESP)上でEFIプログラムが見つかるものと想定されます。

UEFIセキュアブートに対応するには、基本的に、ブートローダがデジタル署名されており、ファームウェアがそのデジタル署名を信頼されたキーとして認識することが必要です。このキーはファームウェアによってあらかじめ信頼されているので、手動での操作は不要です。

これには2つの方法があります。1つは、ハードウェアベンダーにSUSEキーを署名してもらい、SUSEがその署名を使ってブートローダに署名する方法です。もう1つは、MicrosoftのWindows Logo Certificationプログラムを利用してブートローダの認定を受け、MicrosoftにSUSE署名キーを認識してもらう(つまり、MicrosoftのKEKを使って署名してもらう)方法です。これで、SUSEは、UEFI署名サービス(この場合はMicrosoft)によって署名されたローダを入手できます。

UEFIのセキュアブートプロセス
図 11.2: UEFIのセキュアブートプロセス

実装層で、SUSEは、デフォルトでインストールされているshimローダを使用します。法的な問題を回避するスマートなソリューションであり、証明書と署名に関する手順を大きく簡素化します。shimローダの処理は、GRUB 2などのブートローダをロードすることです。次にこのブートローダが、SUSEキーのみで署名されたカーネルをロードします。SUSEは、UEFIセキュアブートが有効化されたSLE11 SP3の新規インストールで、この機能を提供します。

信頼ユーザには2種類あります。

  • 1つ目は、キーを保持するユーザです。プラットフォームキー(PK)によって、ほとんどすべてのことが許可されます。キー交換キー(KEK)では、PKの変更を除き、PKに可能なすべてのことが許可されます。

  • 2つ目は、マシンに物理的にアクセスできる任意のユーザです。物理的にアクセスできるユーザは、マシンを再起動したりUEFIを設定したりできます。

UEFIには、これらのユーザのニーズを満たすため、2種類の変数があります。

  • 1つ目はいわゆる認証された変数で、ブートプロセス(いわゆるブートサービス環境)と実行中のOSの両方からアップデートできます。これは、変数の新しい値が、その変数の古い値が署名されたときと同じキーで署名されている場合にのみ実行できます。また、この変数は、より大きなシリアル番号を持つ値にのみ追加または変更できます。

  • 2つ目は、ブートサービス専用変数と呼ばれるものです。この変数は、ブートプロセス中に動作する任意のコードにアクセスできます。ブートプロセスの終了後、OSが起動する前に、ブートローダはExitBootServicesコールを呼び出す必要があります。その後、これらの変数にはアクセスできなくなり、OSはこれらに触れられません。

さまざまなUEFIキーリストは1つ目のタイプなので、オンラインでの更新、追加、および、キー/ドライバ/ファームウェアの指紋のブラックリスト登録ができます。セキュアブートの実装に役立つのは、2つ目のBoot Service Only Variable (ブートサービス専用変数)です。これは、安全かつオープンソースで使いやすくなっており、GPL v3と互換性があるためです。

SUSEはshim (SUSEとMicrosoftが署名した小型でシンプルなEFIブートローダ)から始まります。

これによってshimのロードおよび実行が可能になります。

shimは、続いて、ロードしようとしているブートローダが信頼されていることを確認します。デフォルトで、shimは、本体に組み込まれている独自のSUSE証明書を使用します。また、shimは、追加のキーを登録してデフォルトのSUSEキーを上書きできます。以下、これらをマシン所有者キー、または省略してMOKと呼びます。

次に、ブートローダはカーネルを検証および起動し、カーネルがモジュールで同じことを実行します。

11.1.2 Machine Owner Key(マシン所有者キー、MOK)

ユーザ(マシンの所有者)がブートプロセスの任意のコンポーネントを置換する場合は、Machine Owner Key(マシン所有者キー、MOK)を使用します。mokutilsツールがコンポーネントの署名およびMOKの管理を支援します。

登録プロセスでは、まずマシンを起動し、shimのロード中に(キーを押すなどして)ブートプロセスを中断します。これによってshimが登録モードに移行するので、ユーザは、デフォルトのSUSEキーをブートパーティションのファイルに含まれるキーに置換できます。ユーザがこの処理を選択すると、shimはそのファイルのハッシュを計算し、結果をBoot Service Only(ブートサービス専用)変数にします。これによってshimは、ブートサービス以外でファイルが変更された場合にその変更を検出でき、ユーザ承認済みのMOKリストの改ざんを回避できます。

これらすべてがブート時に行われ、検証済みのコードのみが実行されます。このため、コンソールにいるユーザのみがマシン所有者のキーセットを使用できます。OSにリモートアクセスするマルウェアやハッカーではあり得ません。ハッカーやマルウェアはファイルの変更しかできず、Boot Service Only(ブートサービス専用)変数に保存されたハッシュを変更できないためです。

いったんロードされshimによって検証されたブートローダは、カーネルを検証する場合はshimにコールバックします(検証コードの複製を避けるため)。shimはMOKと同じリストを使用し、カーネルをロードできるかどうかをブートローダに知らせます。

このようにして、独自のカーネルまたはブートローダをインストールできます。物理的にそこにいることによって新しいキーセットをインストールしそれを認証する必要があるのは、最初の再起動時のみです。MOKは単一のMOKではなくリストなので、shimに複数のベンダーのキーを信頼させることができ、ブートローダからのデュアルブートやマルチブートが可能です。

11.1.3 カスタムカーネルのブート

以下はhttp://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernelにもとづいています。

セキュアブートでは、セルフコンパイルカーネルを使用できます。ただし、独自の証明書を使って署名し、その証明書をファームウェアまたはMOKに知らせる必要があります。

  1. カスタムのX.509キー、および署名に使用される証明書を作成します。

    openssl req -new -x509 -newkey rsa:2048 -keyout key.asc \
      -out cert.pem -nodes -days 666 -subj "/CN=$USER/"

    証明書の作成の詳細については、http://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificateを参照してください。

  2. PKCS#12形式でキーと証明書をパッケージ化します。

    openssl pkcs12 -export -inkey key.asc -in cert.pem \
      -name kernel_cert -out cert.p12
  3. pesignとともに使用するNSSデータベースを生成します。

    certutil -d . -N
  4. PKCS#12に含まれるキーおよび証明書をNSSデータベースにインポートします。

    pk12util -d . -i cert.p12
  5. pesignを使用して、新しい署名でカーネルをblessします。

    pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \
      -o vmlinuz.signed -s
  6. カーネルイメージの署名をリスト表示します。

    pesign -n . -S -i vmlinuz.signed

    その時点で、通常通り/bootにカーネルをインストールできます。カーネルにはカスタム署名があるため、署名に使用された証明書をUEFIファームウェアまたはMOKにインポートする必要があります。

  7. ファームウェアまたはMOKにインポートするため、証明書をDERフォーマットに変換します。

    openssl x509 -in cert.pem -outform der -out cert.der
  8. よりアクセスしやすくするため、証明書をESPにコピーします。

    sudo cp cert.der /boot/efi/
  9. mokutilを使用して自動的にMOKリストを起動します。

      1. 証明書をMOKにインポートします。

        mokutil --root-pw --import cert.der

        --root-pwオプションにより、rootユーザを直接使用できます。

      2. これから登録する証明書のリストを確認します。

        mokutil --list-new
      3. システムを再起動します。shimによってMokManagerが起動されるはずです。rootパスワードを入力して、MOKリストに証明書をインポートすることを確認してください。

      4. 新しくインポートしたキーが登録されたかどうかを確認します。

        mokutil --list-enrolled
      1. また、MOKを手動で起動する場合は以下の手順を実行します。

        再起動

      2. GRUB 2メニューでcキーを押します。

      3. 以下のコマンドをタイプします。

        chainloader $efibootdir/MokManager.efi
        boot
      4. Enroll key from diskを選択します。

      5. cert.derファイルに移動してEnterキーを押します。

      6. 指示に従ってキーを登録します。通常、「0」を押してから「y」を押して確認します。

        また、ファームウェアメニューに、署名データベースに新しいキーを追加する方法が用意されている場合があります。

11.1.4 Inbox以外のドライバの使用

セキュアブートを有効にしたインストールでは、Inbox以外のドライバ(SUSE Linux Enterprise Serverに付属していないドライバ)の追加がサポートされません。SolidDriver/PLDPで使用される署名キーは、デフォルトでは信頼されていません。

セキュアブートを有効にしたインストールでは、サードパーティドライバを2つの方法でインストールできます。いずれの方法でも以下を行います。

  • インストール前にファームウェア/システム管理ツールを使用して、必要なキーをファームウェアデータベースに追加します。このオプションは、使用している特定のハードウェアによって異なります。詳細については、ハードウェアベンダーに問い合わせてください。

  • https://drivers.suse.com/またはハードウェアベンダーから入手したブート可能なドライバISOを使用して、初回ブート時に必要なキーをMOKリストに登録します。

ブート可能なドライバISOを使用してドライバキーをMOKリストに登録するには、次の手順に従います。

  1. 空のCD/DVDメディアに上記のISOイメージを書き込みます。

  2. この新しいCD/DVDメディアを使用してインストールを開始します。その際には、標準のインストールメディア、またはネットワークインストールサーバへのURLを用意しておきます。

    ネットワークインストールを行う場合、ブートコマンドラインでinstall=オプションを使用して、ネットワークインストールソースのURLを入力します。

    光学メディアからインストールする場合、インストーラが最初にドライバキットからブートされた後、製品の最初のインストールディスクを挿入するように要求されます。

  3. アップデートされたドライバを含むinitrdが、インストールに使用されます。

詳細については、https://drivers.suse.com/doc/Usage/Secure_Boot_Certificate.htmlを参照してください。

11.1.5 機能と制限

セキュアブートモードでブートする場合、次の機能が適用されます。

  • UEFIのデフォルトのブートローダがある場所へのインストール。これは、EFIブートエントリを維持または復元するメカニズムです。

  • UEFIを介して再起動する。

  • フォールバック先のレガシーBIOSがない場合、XenハイバーバイザはUEFIを使用してブートする。

  • UEFI IPv6 PXEブートのサポート。

  • UEFIビデオモードのサポート。カーネルはUEFIからビデオモードを取得して、同じパラメータでKMSモードを設定できます。

  • USBデバイスからのUEFIブートがサポートされる。

セキュアブートモードでブートする場合、次の制限が適用されます。

  • セキュアブートを簡単に回避できないようにするため、セキュアブートで実行する場合は一部のカーネル機能が無効になっています。

  • ブートローダ、カーネル、およびカーネルモジュールが署名されている必要があります。

  • KexecおよびKdumpは無効になっています。

  • ハイバネーション(ディスクの休止)は無効になっています。

  • ルートユーザであっても、/dev/kmemおよび/dev/memにアクセスできません。

  • ルートユーザであっても、I/Oポートにアクセスできません。すべてのX11グラフィカルドライバはカーネルドライバを使用する必要があります。

  • sysfs経由でPCI BARにアクセスすることはできません。

  • ACPIのcustom_methodは使用できません。

  • asus-vmiモジュールに対してdebufgsを使用できません。

  • acpi_rsdpパラメータはカーネルに影響を及ぼしません。

11.2 その他の情報

12 ブートローダGRUB 2

概要

この章では、SUSE® Linux Enterprise Serverで使用されているブートローダGRUB 2の設定方法について説明します。これは、現在GRUB Legacyと呼ばれる従来のGRUBブートローダの後継バージョンです。GRUB 2は、SUSE® Linux Enterprise Serverのバージョン 12以降でデフォルトのブートローダとして使用されています。YaSTモジュールは、最も重要な設定を行うために使用できます。ブート手順は、総じて第10章 「ブートプロセスの概要で説明しています。UEFIマシンでのセキュアブートのサポートの詳細については、第11章 「UEFI (Unified Extensible Firmware Interface)を参照してください。

12.1 GRUB LegacyとGRUB 2の主な相違点

  • 設定が異なるファイルに保存されます。

  • より多くのファイルシステム(Btrfsなど)がサポートされています。

  • LVMまたはRAIDデバイスに保存されたファイルを直接読み込めます。

  • テーマによってユーザインタフェースを翻訳および変更できます。

  • ファイルシステムなどの追加機能をサポートするモジュールをロードするためのメカニズムが組み込まれています。

  • 他のカーネルとオペレーティングシステム(Windowsなど)のブートエントリを自動的に検索して生成します。

  • Bashに似た最小限のコンソールが組み込まれています。

12.2 設定ファイルの構造

GRUB 2の設定は、次のファイルに基づいています。

/boot/grub2/grub.cfg

このファイルには、GRUB 2メニュー項目の設定が含まれます。これは、GRUB Legacyで使用されていたmenu.lstに代わるものです。grub.cfggrub2-mkconfig コマンドによって自動的に生成されます。編集しないでください。

/boot/grub2/custom.cfg

このオプションファイルは、ブート時にgrub.cfgによって直接調達され、ブートメニューにカスタム項目を追加するために使用できます。SUSE Linux Enterprise Serverからは、grub-onceを使用する場合も、これらのエントリが解析されます。

/etc/default/grub

このファイルは、GRUB 2のユーザ設定を制御し、通常は背景やテーマなどの追加の環境設定を含みます。

/etc/grub.d/にあるスクリプト

このディレクトリ内のスクリプトは、grub2-mkconfig コマンドの実行時に読み込まれます。スクリプトの命令はメインの設定ファイル/boot/grub/grub.cfgに統合されます。

/etc/sysconfig/bootloader

この設定ファイルは、ブートローダをYaSTで設定するときと、新しいカーネルがインストールされる際に使用されます。perl-bootloaderで評価され、それに従ってブートローダ設定ファイル(GRUB 2の/boot/grub 2/grub.cfgなど)が変更されます。/etc/sysconfig/bootloaderは、GRUB 2固有の設定ファイルではありません。このファイルの値は、SUSE Linux Enterprise Serverにインストールされているすべてのブートローダに適用されます。

/boot/grub2/x86_64-efi/boot/grub2/power-ieee1275/boot/grub2/s390x

これらの設定ファイルにはアーキテクチャ固有のオプションが含まれます。

GRUB 2は、さまざまな方法で制御できます。グラフィカルメニュー(スプラッシュ画面)を使用して、既存の設定からブートエントリを選択できます。設定は、他の設定ファイルからコンパイルされた/boot/grub2/grub.cfgファイルからロードされます(以下を参照)。GRUB 2設定ファイルはすべてシステムファイルとみなされ、編集するにはroot特権が必要です。

注記
注記: 設定の変更の有効化

GRUB 2設定ファイルを手動で編集した後、grub2-mkconfig を実行して変更を有効化する必要があります。ただし、YaSTを使用して設定を変更した場合、grub2-mkconfig は自動的に実行されるため、この作業は必要ありません。

12.2.1 /boot/grub2/grub.cfgファイル

ブートメニューを含むグラフィカルスプラッシュ画面は、GRUB 2の設定ファイル/boot/grub2/grub.cfgに基づいており、このファイルにはメニューを使用してブートできるすべてのパーティションまたはオペレーティングシステムに関する情報が含まれています。

システムをブートするたびに、GRUB 2はファイルシステムから直接メニューファイルをロードします。このため、設定ファイルを変更するたびにGRUB 2を再インストールする必要がありません。grub.cfgは、カーネルをインストールまたは削除すると自動的に再構築されます。

grub.cfgは、grub2-mkconfig によって、/etc/default/grubファイルと、/etc/grub.d/ディレクトリにあるスクリプトからコンパイルされます。そのため、このファイルは手動で編集しないでください。代わりに、関連するソースファイルを編集するか、12.3項 「YaSTによるブートローダの設定」で説明されているようにYaSTブートローダモジュールを使用して設定を変更します。

12.2.2 /etc/default/grubファイル

ここには、メニューを表示するタイミングやブートするデフォルトのOSなど、GRUB 2のより一般的なオプションが含まれます。すべての使用可能なオプションについては、次のコマンドの出力を参照してください。

grep "export GRUB_DEFAULT" -A50 /usr/sbin/grub2-mkconfig | grep GRUB_

定義済みの変数以外にユーザ独自の変数を導入して、後から/etc/grub.dディレクトリにあるスクリプト内でそれらの変数を使用できます。

/etc/default/grubを編集した後は、grub2-mkconfig を実行して、メインの構成ファイルを更新します。

注記
注記: スコープ

このファイルに設定されているオプションはすべて、全ブートエントリに影響する汎用オプションです。XenカーネルまたはXenハイバーバイザに固有のオプションは、GRUB_*_XEN_*設定オプションを介して設定できます。詳細については、以下を参照してください。

GRUB_DEFAULT

デフォルトでブートされるブートメニューエントリを設定します。値は、数値、メニューエントリの完全な名前、またはsavedになります。

GRUB_DEFAULT=2は、3番目(0から数える)のブートメニューエントリをブートします。

GRUB_DEFAULT="2>0"は、3番目の最上位レベルのメニューエントリの1番目にあるサブメニューエントリをブートします。

GRUB_DEFAULT="Example boot menu entry"は、Example boot menu entryというタイトルのメニューエントリをブートします。

GRUB_DEFAULT=savedは、grub2-onceコマンドまたはgrub2-set-defaultコマンドによって指定されたエントリをブートします。grub2-rebootは次回の再起動時にのみ有効なデフォルトブートエントリを設定するのに対し、grub2-set-defaultは変更しない限りデフォルトとして使用されるブートエントリを設定します。grub2-editenv listは、次のブートエントリをリストします。

GRUB_HIDDEN_TIMEOUT

ユーザがキーを押すまで、指定された秒数待機します。この間は、ユーザがキーを押さない限りメニューは表示されません。指定された時間内にキーが押されなかった場合、制御はGRUB_TIMEOUTに渡されます。GRUB_HIDDEN_TIMEOUT=0は、まずShiftキーが押されているかどうかを確認し、押されている場合はブートメニューを表示し、押されていない場合は即座にデフォルトのメニューエントリをブートします。これは、GRUB 2によって識別されるブート可能なOSが1つだけの場合のデフォルトです。

GRUB_HIDDEN_TIMEOUT_QUIET

falseが指定されていて、GRUB_HIDDEN_TIMEOUT機能が有効な場合は、空の画面にカウントダウンタイマが表示されます。

GRUB_TIMEOUT

自動的にデフォルトのブートエントリをブートする前に、ブートメニューを表示する時間(秒数)。キーを押すとタイムアウトはキャンセルされ、GRUB 2はユーザが手動で選択するまで待機します。GRUB_TIMEOUT=-1は、ユーザがブートエントリを手動で選択するまでメニューを表示します。

GRUB_CMDLINE_LINUX

この行のエントリは、標準モードおよび回復モード用のブートエントリの最後に追加されます。この行を使用して、カーネルパラメータをブートエントリに追加します。

GRUB_CMDLINE_LINUX_DEFAULT

GRUB_CMDLINE_LINUXと同じですが、標準モードでのみエントリが追加されます。

GRUB_CMDLINE_LINUX_RECOVERY

GRUB_CMDLINE_LINUXと同じですが、回復モードでのみエントリが追加されます。

GRUB_CMDLINE_LINUX_XEN_REPLACE

このエントリは、すべてのXenブートエントリのGRUB_CMDLINE_LINUXパラメータを完全に置き換えます。

GRUB_CMDLINE_LINUX_XEN_REPLACE_DEFAULT

GRUB_CMDLINE_LINUX_XEN_REPLACEと同じですが、GRUB_CMDLINE_LINUX_DEFAULTのパラメータのみを置き換えます。

GRUB_CMDLINE_XEN

このエントリは、Xenゲストカーネルのカーネルパラメータのみを指定します。基本原則は、GRUB_CMDLINE_LINUXと同じです。

GRUB_CMDLINE_XEN_DEFAULT

GRUB_CMDLINE_XENと同じです。基本原則は、GRUB_CMDLINE_LINUX_DEFAULTと同じです。

GRUB_TERMINAL

入出力端末デバイスを有効化および指定します。console (PC BIOSおよびEFIコンソール)、serial (シリアル端末)、ofconsole (Open Firmwareコンソール)、またはデフォルトのgfxterm (グラフィックモード出力)のいずれかになります。また、必要なオプションを引用符で囲むことで、2つ以上のデバイスを有効にすることもできます(たとえば、GRUB_TERMINAL="console serial")。

GRUB_GFXMODE

gfxtermグラフィカル端末で使用される解像度。使用できるモードはグラフィックカード(VBE)でサポートされているモードのみである点に注意してください。デフォルトは「auto」で、優先解像度の選択を試みます。GRUB 2のコマンドラインで「videoinfo」と入力すると、GRUB 2で使用可能な画面解像度が表示されます。コマンドラインにアクセスするには、GRUB 2ブートメニュー画面が表示されているときにCと入力します。

また、色数を解像度設定に追加することで色数も指定できます(たとえば、GRUB_GFXMODE=1280x1024x24)。

GRUB_BACKGROUND

gfxtermグラフィカル端末の背景イメージを設定します。イメージはブート時にGRUB 2によって読み込み可能なファイルでなければならず、拡張子.png.tga.jpg、または.jpegで終わる必要があります。必要であれば、イメージは画面に合わせて拡大されます。

GRUB_DISABLE_OS_PROBER

このオプションをtrueに設定すると、他のオペレーティングシステムの自動検索は無効になります。/boot/内のカーネルイメージと、/etc/grub.d/内にあるユーザ独意のスクリプトのオプションのみが検出されます。

SUSE_BTRFS_SNAPSHOT_BOOTING

このオプションをtrueに設定すると、GRUB 2をSnapperのスナップショットの状態に直接ブートできます。詳細については、7.3項 「スナップショットからのブートによるシステムロールバック」を参照してください。

すべてのオプションのリストについては、GNU GRUBのマニュアルを参照してください。すべての設定可能なパラメータのリストについては、http://en.opensuse.org/Linuxrcを参照してください。

12.2.3 /etc/grub.d内のスクリプト

このディレクトリ内のスクリプトはgrub2-mkconfig コマンドの実行時に読み込まれ、スクリプトの命令は/boot/grub2/grub.cfgに統合されます。grub.cfg内のメニュー項目の順序は、このディレクトリ内のファイルの実行順序によって決まります。まず、名前が数字で始まるファイルが、最も小さい数字が付いたものから順番に実行されます。00_header10_linuxの前に実行され、10_linuxは40_customの前に実行されます。アルファベットの名前が付いたファイルが存在する場合は、名前が数字で始まるファイルの後に実行されます。grub2-mkconfigの実行中にgrub.cfgへ出力を生成するのは実行可能ファイルのみです。デフォルトでは、/etc/grub.dディレクトリ内のファイルはすべて実行可能ファイルです。

ヒント
ヒント: grub.cfgの永続的なカスタムコンテンツ

grub2-mkconfigを実行するたびに/boot/grub2/grub.cfgが再コンパイルされるため、カスタムコンテンツはすべて失われます。grub2-mkconfigを実行した後に、それらを失うことなく/boot/grub2/grub.cfgに直接行を挿入したい場合は、以下の間に挿入してください:

### BEGIN /etc/grub.d/90_persistent ###

および

### END /etc/grub.d/90_persistent ###

lines. 90_persistentスクリプトにより、このようなコンテンツが確実に保存されます。

最も重要なスクリプトのリストを以下に示します。

00_header

システムファイルの場所、表示設定、テーマ、以前に保存したエントリなどの環境変数を設定します。また、/etc/default/grubに保存されている初期設定をインポートします。通常、このファイルを変更する必要はありません。

10_linux

ルートデバイス上のLinuxカーネルを識別し、関連するメニューエントリを作成します。これには、関連する回復モードオプション(有効な場合)が含まれます。最新のカーネルのみがメインメニューページに表示され、その他のカーネルはサブメニューに含まれます。

30_os-prober

このスクリプトは、OS-proberを使用してLinuxやその他のオペレーティングシステムを検索し、結果をGRUB 2メニューに示します。他の特定のオペレーティングシステム(WindowsやmacOSなど)を識別するためのセクションがあります。

40_custom

このファイルを使用すると、grub.cfgに簡単にカスタムブートエントリを組み込むことができます。最初のexec tail -n +3 $0の部分は変更しないようにしてください。

処理シーケンスは、名前の先頭の数値によって設定され、最も小さい数値が最初に実行されます。スクリプトの名前が同じ数値で始まる場合は、名前全体のアルファベット順で順序が決まります。

ヒント
ヒント: /boot/grub2/custom.cfg

/boot/grub2/custom.cfgを作成してコンテンツを入力すると、ブート時に40_customの直後に自動的に/boot/grub2/grub.cfgに組み込まれます。

12.2.4 BIOSドライブとLinuxドライブのマッピング

GRUB Legacyでは、device.map設定ファイルを使用して、BIOSドライブ番号からLinuxデバイス名を派生させていました。BIOSドライブとLinuxデバイスのマッピングは常に正しく推測できるとは限りません。たとえば、BIOS設定でIDEとSCSIのブートシーケンスが入れ替わると、GRUB Legacyは誤った順序を取得します。

GRUB 2では、grub.cfgの生成時にデバイスID文字列(UUID)またはファイルシステムラベルを使用することで、この問題を回避しています。GRUB 2ユーティリティは一時デバイスマップをオンザフライで作成します。通常、特に単一ディスクのシステムの場合は、この処理で十分です。

ただし、GRUB 2の自動デバイスマッピングメカニズムを無効にする必要がある場合は、カスタムマッピングファイル/boot/grub2/device.mapを作成します。次の例では、マッピングを変更して、DISK 3をブートディスクにしています。パーティション番号は、GRUB Legacyでは0から始まっていましたが、GRUB 2では1から始まる点に注意してください。

(hd1)  /dev/disk-by-id/DISK3 ID
(hd2)  /dev/disk-by-id/DISK1 ID
(hd3)  /dev/disk-by-id/DISK2 ID

12.2.5 ブート手順実行中のメニューエントリの編集

メニューエントリを直接編集できると、誤設定が原因でシステムがブートしなくなった場合に役立ちます。また、システム設定を変更せずに新しい設定をテストする場合にも使用できます。

  1. グラフィカルブートメニューで、編集するエントリを矢印キーで選択します。

  2. Eを押して、テキストベースのエディタを開きます。

  3. 矢印キーを使用して、編集する行へ移動します。

    GRUB 2ブートエディタ
    図 12.1: GRUB 2ブートエディタ

    ここでは2つのオプションがあります。

    1. スペース区切りのパラメータを、linuxまたはlinuxefiで始まる行の終わりに追加して、カーネルパラメータを編集します。すべてのパラメータのリストはhttp://en.opensuse.org/Linuxrcから入手できます。

    2. または、一般オプションを編集して、カーネルバージョンなどを変更します。<Tab>キーを押すと、考えられる完了結果がすべて提示されます。

  4. F10キーを押して変更内容が反映されたシステムをブートするか、Escキーを押して編集内容は破棄し、GRUB 2メニューに戻ります。

この方法で加えた変更は、現在のブートプロセスだけに適用され、永続的に保存されることはありません。

重要
重要: ブート手順実行中のキーボードレイアウト

ブート時は、USキーボードレイアウトだけが使用可能です。詳細については、図40.2「USキーボードレイアウト」を参照してください。

注記
注記: インストールメディアのブートローダ

従来のBIOSが搭載されたシステム上にあるインストールメディアのブートローダは、引き続きGRUB Legacyになります。ブートオプションを追加するには、エントリを選択し、入力を開始します。インストールブートエントリに追加した内容は、インストール済みシステムに永続的に保存されます。

注記
注記: zシステムでのGRUB 2メニューエントリの編集

IBM z Systemsでのカーソルの移動と編集コマンドは異なります。詳細については、12.4項 「z Systemsにおける端末の使用上の相違点」を参照してください。

12.2.6 ブートパスワードの設定

GRUB 2は、オペレーティングシステムのブート前でも、ファイルシステムにアクセスできるようにします。rootパーミッションを持たないユーザは、システムのブート後、アクセス権のないLinuxシステム上のファイルにアクセスできます。この種のアクセスを阻止したり、ユーザによる特定のメニューエントリのブートを防止するために、ブートパスワードを設定できます。

重要
重要: ブート時にパスワードが必要です

設定すると、ブートのたびにブートパスワードが必要になります。つまり、システムは自動的にはブートしません。

ブートパスワードを設定するには、次の手順に従います。または、YaSTを使用してください(パスワードでブートローダを保護する を参照してください)。

  1. grub2-mkpasswd-pbkdf2を使用してパスワードを暗号化します。

    tux >  sudo grub2-mkpasswd-pbkdf2
    Password: ****
    Reenter password: ****
    PBKDF2 hash of your password is grub.pbkdf2.sha512.10000.9CA4611006FE96BC77A...
  2. set superusersコマンドを使用して、結果の文字列をまとめて/etc/grub.d/40_customファイルに貼り付けます。

    set superusers="root"
    password_pbkdf2 root grub.pbkdf2.sha512.10000.9CA4611006FE96BC77A...
  3. grub2-mkconfig を実行して、メインの設定ファイルに変更をインポートします。

再起動後、メニューエントリのブートを試みると、ユーザ名とパスワードの入力が求められます。「root」と入力し、grub2-mkpasswd-pbkdf2コマンドの実行時に入力したパスワードを入力します。資格情報が正しい場合、システムは選択したブートエントリをブートします。

詳細については、https://www.gnu.org/software/grub/manual/grub.html#Securityを参照してください。

12.3 YaSTによるブートローダの設定

SUSE Linux Enterprise Serverシステムでブートローダの汎用オプションを設定する最も簡単な方法は、YaSTモジュールを使用することです。YaSTコントロールセンターで、システム › ブートローダの順に選択します。モジュールにシステムの現在のブートローダ設定が示され、変更を加えられます。

ブートコードオプションタブで、タイプ、場所、および高度なローダ設定に関する設定を表示および変更できます。GRUB 2を標準モードとEFIモードのどちらで使用するかを選択することができます。

ブートコードオプション
図 12.2: ブートコードオプション
重要
重要: EFIシステムではGRUB2-EFIが必須

EFIシステムがある場合は、GRUB2-EFIのみをインストールできます。それ以外をインストールすると、システムはブート不能になります。

重要
重要: ブートローダの再インストール

ブートローダを再インストールするには、必ずYaSTで設定を変更して、その後で元に戻すという操作を実行します。たとえば、GRUB2-EFIを再インストールするには、一度GRUB2を選択して、すぐにGRUB2-EFIに戻します。

元に戻さない場合、ブートローダが完全には再インストールされない可能性があります。

注記
注記: カスタムのブートローダ

リストにないブートローダを使用する場合は、ブートローダはインストールしないでくださいを選択します。このオプションを選択する場合には、あらかじめ、ブートローダのドキュメントをよくお読みください。

12.3.1 ブートローダの場所およびブートコードオプション

ブートローダのデフォルトの場所はパーティション設定によって異なり、マスタブートレコード(MBR)か、/パーティションのブートセクタです。ブートローダの場所を変更するには、次の手順に従います。

手順 12.1: ブートローダの場所の変更
  1. ブートコードオプションタブを選択し、ブートローダの場所で、次のいずれかのオプションを選択します。

    マスタブートレコードからブート

    ディレクトリ/bootが含まれるディスクのMBRにブートローダをインストールします。通常は/にマウントされるディスクになりますが、/bootが異なるディスクの別個のパーティションにマウントされる場合は、そのディスクのMBRが使用されます。

    ルートパーティションからブート

    /パーティションのブートセクタにブートローダがインストールされます。

    カスタムブートパーティション

    このオプションを選択すると、手動でブートローダの場所を指定できます。

  2. OKをクリックして、変更を適用します。

コードオプション
図 12.3: コードオプション

ブートコードオプションタブには、以下の追加のオプションがあります。

ブートパーティション用パーティションテーブルにアクティブフラグを設定

/bootディレクトリPReP パーティションを含むパーティションをアクティブにします。古いBIOSおよび/またはレガシーオペレーティングシステムを使用しているシステムでは、非アクティブなパーティションからのブートに失敗する可能性があるため、このオプションを使用してください。このオプションをアクティブのままにしておくのが安全です。

MBRに汎用ブートコードを書き込む

MBRにカスタムの「非GRUB」コードが含まれている場合、このコードは、このオプションにより、汎用の、オペレーティングシステムに依存しないコードに置き換えられます。このオプションを無効にすると、システムが起動できなくなる可能性があります。

Enable Trusted Boot Support

信頼されたコンピューティング機能(TPM(Trusted Platform Module))をサポートするTrustedGRUB2を開始します。詳細については、https://github.com/Sirrix-AG/TrustedGRUB2を参照してください。

12.3.2 ディスクの順序の変更

コンピュータに複数のハードディスクがある場合、ディスクのブートシーケンスを指定できます。リストの最初のディスクは、MBRからブートする場合にGRUB 2がインストールされる場所です。これは、デフォルトでSUSE Linux Enterprise Serverがインストールされるディスクです。リストの残りは、GRUB 2のデバイスマッパのヒントです(12.2.4項 「BIOSドライブとLinuxドライブのマッピング」を参照)。

警告
警告: ブートできないシステム

デフォルト値は、通常、ほぼすべての展開で有効です。ディスクのブート順序を正しく変更しないと、次回の再起動時にシステムをブートできなくなる可能性があります。たとえば、リスト内の最初のディスクがBIOSのブート順序の一部ではなく、リスト内の他のディスクに空のMBRがある場合などです。

手順 12.2: ディスクの順序の設定
  1. ブートコードオプションタブを開きます。

  2. ディスク順序の編集をクリックします。

  3. 複数のディスクが表示されている場合には、ディスクを選択してから上へまたは下へをクリックして、ディスクの表示順を変更します。

  4. OKを2回クリックして、変更内容を保存します。

12.3.3 詳細オプションの設定

詳細なブートオプションを設定するには、Boot Loader Options (ブートローダオプション)タブを使用します。

12.3.3.1 Boot Loader Options (ブートローダオプション)タブ

ブートローダのオプション:
図 12.4: ブートローダのオプション:
ブートローダのタイムアウト

新しい値を入力するか、マウスで適切な矢印キーをクリックして、タイムアウト(秒)の値を変更します。

その他のOSの検知

選択すると、ブートローダはWindowsや他のLinuxインストールなど、インストール済みの他のシステムを検索します。

ブート時にメニューを隠す

ブートメニューを隠し、デフォルトエントリをブートします。

デフォルトブートエントリの調整

デフォルトのブートセクションリストから目的のエントリを選択します。ブートエントリ名内の>記号は、ブートセクションとそのサブセクションを区切っている点に注意してください。

パスワードでブートローダを保護する

ブートローダとシステムを追加のパスワードで保護します。詳細については、12.2.6項 「ブートパスワードの設定」を参照してください。

12.3.3.2 Kernel Parameters (カーネルパラメータ)タブ

カーネルパラメータ
図 12.5: カーネルパラメータ
コンソールの解像度

コンソールの解像度オプションは、ブートプロセス時のデフォルトの画面解像度を指定します。

カーネルコマンドラインパラメータ

オプションのカーネルパラメータは、デフォルトパラメータの最後に追加されます。使用できるすべてのパラメータのリストについては、http://en.opensuse.org/Linuxrcを参照してください。

グラフィカルコンソールを使用する

オンにすると、テキストモードではなくグラフィカルなスプラッシュスクリーンにブートメニューが表示されます。ブート画面の解像度は、コンソールの解像度リストから設定できます。グラフィカルテーマ定義ファイルは、コンソールのテーマファイル選択機能で指定できます。

シリアルコンソールの使用

コンピュータがシリアルコンソールで制御されている場合は、このオプションを有効にして、どのCOMポートをどの速度で使用するか指定します。info grubまたはhttp://www.gnu.org/software/grub/manual/grub.html#Serial-terminalを参照してください。

12.4 z Systemsにおける端末の使用上の相違点

3215および3270端末では、カーソルの移動方法と、GRUB 2内での編集コマンドの実行方法にいくつかの相違点と制限事項があります。

12.4.1 制限

対話処理

対話処理は大幅に制限されています。多くの場合、入力しても結果は視覚的なフィードバックとして表示されません。カーソルの位置を確認するには、下線(_)を入力します。

注記
注記: 3270の3215との比較

3270端末では、画面の表示と更新は3215端末より優れています。

カーソルの移動

従来の方法でカーソルを移動することはできません。AltMetaCtrl、およびカーソルキーは動作しません。カーソルを移動するには、12.4.2項 「キーの組み合わせ」に一覧にされたキーの組み合わせを使用します。

キャレット

キャレット(^)は制御文字として使用されます。文字として^を入力し他の文字を続けるには、^^、「LETTER」と入力します。

<Enter>

Enterキーは機能しません。代わりに、^Jを使用します。

12.4.2 キーの組み合わせ

共通の代用キー:

^J

決定する(Enter)

^L

中止して、直前の状態に戻る

^I

タブ補完機能(編集およびシェルモード)

メニューモードで使用可能なキー:

^A

最初のエントリ

^E

最後のエントリ

^P

前のエントリ

^N

次のエントリ

^G

前のページ

^C

次のページ

^F

選択したエントリをブートする、またはサブメニューに切り替える(^Jと同じ)

E

選択したエントリを編集する

C

GRUBシェルを起動する

編集モードで使用可能なキー:

^P

前の行に戻る

^N

次の行に進む

^B

1文字戻る

^F

1文字進む

^A

行の先頭に移動する

^E

行の末尾

^H

バックスペース

^D

delete

^K

行を削除する

^Y

ヤンク(コピー)

^O

行を開く

^L

画面を更新する

^X

エントリをブートする

^C

GRUBシェルを起動する

コマンドラインモードで使用可能なキー:

^P

前のコマンド

^N

履歴の次のコマンド

^A

行の先頭に移動する

^E

行の末尾

^B

1文字戻る

^F

1文字進む

^H

バックスペース

^D

delete

^K

行を削除する

^U

行を破棄する

^Y

ヤンク(コピー)

12.5 役立つGRUB 2コマンド

grub2-mkconfig

/etc/default/grubおよび/etc/grub.d/のスクリプトに基づいて、新しい/boot/grub2/grub.cfgを生成します。

例 12.1: grub2-mkconfigの使用法
grub2-mkconfig -o /boot/grub2/grub.cfg
ヒント
ヒント: 構文チェック

パラメータを付けずにgrub2-mkconfigを実行すると、設定がSTDOUTに出力され、そこで設定を確認できます。構文をチェックするには、/boot/grub2/grub.cfgが書き込まれた後にgrub2-script-check を使用します。

重要
重要: grub2-mkconfigはUEFIセキュアブートテーブルを修復できません

UEFIセキュアブートを使用していて、システムがGRUB 2に正常にアクセスできなくなった場合、Shimを再インストールして、UEFIブートテーブルを再生成する必要がある場合があります。次のようにします。

root # shim-install --config-file=/boot/grub2/grub.cfg
grub2-mkrescue

インストールされたGRUB 2設定の、ブート可能なレスキューイメージを作成します。

例 12.2: grub2-mkrescueの使用法
grub2-mkrescue -o save_path/name.iso iso
grub2-script-check

指定したファイルの構文エラーをチェックします。

例 12.3: grub2-script-checkの使用
grub2-script-check /boot/grub2/grub.cfg
grub2-once

次のブート時にのみ使用されるデフォルトブートエントリを設定します。使用可能なブートエントリのリストを取得するには、--listオプションを使用します。

例 12.4: grub2-onceの使用法
grub2-once number_of_the_boot_entry
ヒント
ヒント: grub2-onceのヘルプ

オプションを付けずにプログラムを呼び出すと、使用可能なすべてのオプションのリストを取得できます。

12.6 詳細情報

GRUB 2の詳細情報は、http://www.gnu.org/software/grub/で入手できます。また、grub情報ページも参照してください。http://www.suse.com/supportにあるTechnical Information Search(技術情報検索)で、キーワードGRUB 2を検索して、特別な事項に関する情報を入手することもできます。

13 systemdデーモン

プログラムsystemdは、プロセスID 1のプロセスであり、要求された方法でシステムを初期化します。systemdはカーネルによって直接起動され、通常はプロセスを強制終了するシグナル9が使えないようにします。他のすべてのプログラムは、systemdまたは子プロセスのいずれかによって直接起動されます。

SUSE Linux Enterprise Server 12から、systemdが一般的なSystem V initデーモンに取って代わりました。systemdは、System V initと完全な互換性があります(initスクリプトをサポートしているため)。systemdの主な利点の1つは、サービスを積極的に並行起動することで、ブート時間をかなり速くできることです。systemdは、サービスを必要なときだけ起動します。デーモンは、ブート時に無条件で起動されることはなく、最初に必要になったときに起動されます。systemdでは、カーネルのコントロールグループ(cgroup)もサポートしているほか、システムの状態をスナップショットに保存したり、その状態に復元したりすることもできます。詳細については、http://www.freedesktop.org/wiki/Software/systemd/を参照してください。

13.1 systemdの概念

このセクションでは、systemdの背景にある概念について詳しく説明します。

13.1.1 systemdについて

systemdは、System VおよびLSBのinitスクリプトと互換性のある、Linux向けのシステム/セッションマネージャです。 主な特長は次のとおりです。

  • 積極的な並行機能の提供

  • ソケットやD-Busアクティベーションを使用したサービスの起動

  • デーモンのオンデマンド起動

  • Linux cgroupsを使用したプロセスの追跡

  • システム状態のスナップショットへの保存、およびその状態への復元

  • マウントポイントと自動マウントポイントの保持

  • 精巧なトランザクションの依存関係に基づくサービス制御ロジックの実装

13.1.2 ユニットファイル

ユニット設定ファイルには、サービス、ソケット、デバイス、マウントポイント、自動マウントポイント、スワップファイルやパーティション、起動ターゲット、監視対象のファイルシステムのパス、systemdによって制御および監視されているタイマ、一時的なシステム状態のスナップショット、リソース管理スライス、または外部で作成されたプロセスグループに関する情報が含まれます。ユニットファイルは、systemdの次のファイルの総称です。

  • サービス:  プロセスに関する情報(たとえば、実行中のデーモン)。サービスファイルは.serviceで終わります。

  • ターゲット:  システム起動時のユニットのグループ化に、または同期ポイントとして使用されます。ターゲットファイルは.targetで終わります。

  • ソケット:  ソケットに基づくアクティベーション(inetdなど)でのIPC、ネットワークソケット、ファイルシステムFIFOに関する情報。ソケットファイルは.socketで終わります。

  • パス:  その他のユニットをトリガするために使用されます(たとえば、ファイル変更時のサービスの実行など)。パスファイルは.pathで終わります。

  • タイマ:  タイマ制御された、タイマに基づくアクティベーションに関する情報。タイマファイルは.timerで終わります。

  • マウントポイント:  通常はfstabジェネレータによって自動生成されます。マウントポイントファイルは.mountで終わります。

  • 自動マウントポイント:  ファイルシステムの自動マウントポイントに関する情報。自動マウントポイントファイルは.automountで終わります。

  • スワップ:  スワップデバイスに関する情報またはメモリページング用のファイル。スワップファイルは.swapで終わります。

  • デバイス:  sysfs/udev(7)デバイスツリーに公開されているデバイスユニットに関する情報。デバイスファイルは.deviceで終わります。

  • スコープ/スライス:  プロセスグループのリソースを階層管理する際の概念。スコープ/スライスファイルは.scope/.sliceで終わります。

systemd.unitの詳細については、http://www.freedesktop.org/software/systemd/man/systemd.unit.htmlを参照してください。

13.2 基本的な使用方法

System V initシステムでは、initスクリプト、insservtelinitなどの複数のコマンドを使用してサービスを処理します。systemdでは、サービスに対する主な処理を実行する際、1 つのコマンド(systemctl)で済むようになっているため、サービスをより容易に管理できます。gitzypperのように、コマンドの後ろにサブコマンドを指定して実行します。

systemctl GENERAL OPTIONS SUBCOMMAND SUBCOMMAND OPTIONS

完全なマニュアルについては、man 1 systemctlを参照してください。

ヒント
ヒント: 端末の出力とbashの補完

systemdのコマンドは、出力先が端末である場合(パイプやファイルなどではない場合)、デフォルトではページャに長い出力が送信されます。ページングモードをオフにするには、--no-pagerオプションを使用してください。

systemdでは、bashによる補完もサポートしています。サブコマンドの最初の1文字を入力し、<Tab>を押すと、サブコマンドの残りを自動的に入力することができます。この機能は、bashシェルを利用している場合にのみ使用できるもので、bash-completionパッケージをインストールしておく必要があります。

13.2.1 稼働中のシステムでのサービスの管理

サービスを管理するためのサブコマンドは、 System V initでのサービス管理コマンドと同じ(startstopなど)です。サービス管理コマンドの基本構文は、以下のとおりです。

systemd
systemctl reload|restart|start|status|stop|... MY_SERVICE(S)
System V init
rcMY_SERVICE(S) reload|restart|start|status|stop|...

systemdでは、複数のサービスを一括で管理できます。initスクリプトを次々と実行しなければならないSystem V initとは異なり、次のようにコマンドを実行します。

systemctl start MY_1ST_SERVICE MY_2ND_SERVICE

システムで利用できるすべてのサービスを一覧表示するには、次のように実行します。

systemctl list-unit-files --type=service

次の表に、systemdとSystem V initの最も重要なサービス管理コマンドを示します。

表 13.1: サービス管理コマンド

タスク

systemdコマンド

System V initコマンド

起動: 

start
start

停止: 

stop
stop

再起動:  サービスを停止し、後で起動します。サービスがまだ起動していない場合は、そのサービスを起動します。

restart
restart

条件付きの再起動:  サービスが現在実行中の場合、サービスを再起動します。実行されていないサービスについては、何も行いません。

try-restart
try-restart

再ロード:  サービスに対し、操作を中断せずに設定ファイルを再ロードするように指示します。Apacheに、変更後のhttpd.conf設定ファイルを再ロードさせる、などの使用方法をします。すべてのサービスが再ロードをサポートしているとは限らないことに注意してください。

reload
reload

再ロードまたは再起動:  サービスが再ロードをサポートしていれば再ロードし、サポートしていなければ再起動します。サービスがまだ起動していない場合は、そのサービスを起動します。

reload-or-restart
n/a

条件付きの再ロードまたは再起動:  サービスが再ロードをサポートしていれば再ロードし、サポートしていなければ再起動します(現在実行中の場合)。実行されていないサービスについては、何も行いません。

reload-or-try-restart
n/a

詳細なステータス情報の取得:  サービスのステータスについて、情報を表示します。systemdコマンドでは、説明、実行ファイル、ステータス、cgroupのほか、直近でサービスが出力したメッセージ(13.6.8項 「サービスのデバッグ」を参照)が表示されます。System V initで表示される詳細のレベルは、サービスごとに異なります。

status
status

簡潔なステータス情報の取得:  サービスがアクティブかどうかを示します。

is-active
status

13.2.2 サービスの恒久的な有効化/無効化

上述のサービス管理コマンドでは、現在のセッションに対するサービスを操作できます。systemdでは、サービスを恒久的に有効化/無効化して、必要に応じて自動的に起動したり、常に使用不可にすることもできます。この作業は、YaSTまたはコマンドラインを使用して実行できます。

13.2.2.1 コマンドラインからのサービスの有効化/無効化

次の表に、systemdとSystem V initの有効化/無効化コマンドを示します。

重要
重要: サービスの起動について

コマンドラインからサービスを有効化した場合、そのサービスは自動的には起動されず、次回のシステム起動またはランレベル/ターゲット変更の際に起動されます。有効化した後で、即時にサービスを起動するには、systemctl start MY_SERVICEまたはrc MY_SERVICE startのように、明示的にサービスを起動してください。

表 13.2: サービスの有効化/無効化コマンド

作業

systemdコマンド

System V initコマンド

有効化: 

systemctl enable MY_SERVICE(S)

insserv MY_SERVICE(S)chkconfig -a MY_SERVICE(S)

無効化: 

systemctl disable MY_SERVICE(S).service

insserv -r MY_SERVICE(S)chkconfig -d MY_SERVICE(S)

確認:  サービスが有効になっているかどうかを示します。

systemctl is-enabled MY_SERVICE

chkconfig MY_SERVICE

再有効化:  サービスの再起動と同様に、このコマンドはいったんサービスを無効化した後に有効化します。サービスにデフォルト値を設定して再有効化する場合に利用します。

systemctl reenable MY_SERVICE

該当なし

マスク:  サービスを無効化しても、手動で起動できてしまいます。サービスを完全に無効化するには、マスクを設定する必要があります。 注意してご使用ください。

systemctl mask MY_SERVICE

該当なし

マスク解除:  マスクを設定したサービスは、マスクを解除しないと使用できません。

systemctl unmask MY_SERVICE

該当なし

13.3 システムの起動とターゲットの管理

システムを起動し、シャットダウンするプロセス全体は、systemdによって管理されます。この点から見ると、カーネルは、他のプログラムからの要求に従って、他のすべてのプロセスを管理し、CPU時間とハードウェアアクセスを調整するバックグラウンドプロセスと考えることができます。

13.3.1 ターゲットとランレベルの比較

System V initでは、システムはランレベルと呼ばれる状態でブートしていました。ランレベルはシステムの起動方法および稼働中のシステムで使用可能なサービスを定義します。ランレベルは番号付けされています。よく知られているランレベルは、0 (システムのシャットダウン)、3 (ネットワークを使用するマルチユーザシステム)、および5 (ネットワークとディスプレイマネージャを使用するマルチユーザシステム)です。

systemdでは、ターゲットユニットと呼ばれる仕組みを使用する新しい概念が導入されています。ただし、ランレベルの概念とも、完全な互換性を維持しています。ターゲットユニットには、番号ではなく名前が付けられており、特定の目的を果たします。たとえば、ターゲットlocal-fs.targetswap.targetは、それぞれローカルファイルシステムのマウントと、スワップ領域のマウントを実行します。

ターゲットgraphical.targetは、ネットワーク機能とディスプレイマネージャ機能を使用するマルチユーザシステムで、ランレベル5に相当します。 graphical.targetなどの複合ターゲットは、他のターゲットのサブセットを組み合わせることで、メタターゲットとして機能します。systemdでは、既存のターゲットを組み合わせることで簡単にカスタムターゲットを作成できるため、非常に柔軟な運用が実現されます。

次のリストは、systemdの最も重要なターゲットユニットを示しています。すべてを網羅したリストについては、man 7 systemd.specialを参照してください。

systemdで選択できるターゲットユニット
default.target

デフォルトで起動されるターゲット。実在するターゲットというよりは、別のターゲット(graphic.targetなど)に対するシンボリックリンクであるといえます。YaSTを介して恒久的に変更できます(13.4項 「YaSTを使用したサービスの管理」を参照)。セッション用に変更する場合は、ブートプロンプトで、カーネルパラメータsystemd.unit=MY_TARGET.targetを使用してください。

emergency.target

コンソール上で非常用のシェルを起動します。ブートプロンプトでのみ、systemd.unit=emergency.targetと指定して使用します。

graphical.target

ネットワークとマルチユーザをサポートし、ディスプレイマネージャを使用するシステムを起動します。

halt.target

システムをシャットダウンします。

mail-transfer-agent.target

メールの送受信に必要なすべてのサービスを起動します。

multi-user.target

ネットワークに対応したマルチユーザシステムを起動します。

reboot.target

システムを再起動します。

rescue.target

ネットワークに対応しないシングルユーザシステムを起動します。

System V initランレベルシステムとの互換性を維持するために、systemdでは、runlevelX.targetという名前の特別なターゲットが用意されています。それぞれXの部分がランレベルの番号に対応します。

現在のターゲットを知りたい場合は、systemctl get-defaultコマンドを使用します。

表 13.3: System Vのランレベルとsystemdのターゲットユニット

System Vランレベル

systemdターゲット

用途

0

runlevel0.targethalt.targetpoweroff.target

システムのシャットダウン

1、S

runlevel1.targetrescue.target

シングルユーザモード

2

runlevel2.targetmulti-user.target

リモートネットワークなしのローカルマルチユーザ

3

runlevel3.targetmulti-user.target

ネットワークを使用するフルマルチユーザ

4

runlevel4.target

未使用/ユーザ定義

5

runlevel5.targetgraphical.target

ネットワークとディスプレイマネージャを使用するフルマルチユーザ

6

runlevel6.targetreboot.target

システムの再起動

重要
重要: systemdで/etc/inittabが無視されることについて

System V initシステムのランレベルは、/etc/inittabで設定されています。 systemdでは、この設定が使用されることはありません。独自のブート可能なターゲットを作成する方法については、13.5.3項 「カスタムターゲットの作成」を参照してください。

13.3.1.1 ターゲット変更用のコマンド

次のコマンドを使用して、ターゲットユニットを操作します。

作業

systemdコマンド

System V initコマンド

現在のターゲット/ランレベルの変更

systemctl isolate MY_TARGET.target

telinit X

デフォルトのターゲット/ランレベルへの変更

systemctl default

該当なし

現在のターゲット/ランレベルの取得

systemctl list-units --type=target

systemdでは通常、複数のアクティブターゲットを利用します。そのため、このコマンドは現在アクティブなターゲットをすべて表示します。

who -r

または

runlevel

デフォルトのランレベルの恒久的な変更

サービスマネージャを使用するか、次のコマンドを実行します。

ln -sf /usr/lib/systemd/system/ MY_TARGET.target /etc/systemd/system/default.target

サービスマネージャを使用するか、次の行を変更します。

id: X:initdefault:

(/etc/inittab内にある)

現在のブートプロセスに対するデフォルトランレベルの変更

ブートプロンプトで次のオプションを入力します。

systemd.unit= MY_TARGET.target

ブートプロンプトで必要なランレベルの番号を入力します。

ターゲットやランレベルの依存関係の表示

systemctl show -p "Requires" MY_TARGET.target

systemctl show -p "Wants" MY_TARGET.target

Requiresを指定すると、ハード依存関係(必ず解決する必要がある依存関係)が表示されます。Wantsを指定すると、ソフト依存関係(可能であれば解決される依存関係)が表示されます。

該当なし

13.3.2 システム起動のデバッグ

systemdには、システム起動プロセスを分析できる機能が用意されています。この機能により、全サービスのリストとそのステータスを(/varlog/を解析することなく)確認することができます。systemdでは、起動手順を精査して、サービスの起動にかかっている時間を調べることもできます。

13.3.2.1 サービスの起動の確認

システムのブート後に起動された全サービスのリストを確認するには、systemctlと入力します。次のように、すべてのアクティブなサービスが表示されます (一部省略しています)。特定のサービスの詳細情報が必要な場合は、systemctl status MY_SERVICEを使用してください。

例 13.1: アクティブなサービスの一覧表示
root # systemctl
UNIT                        LOAD   ACTIVE SUB       JOB DESCRIPTION
[...]
iscsi.service               loaded active exited    Login and scanning of iSC+
kmod-static-nodes.service   loaded active exited    Create list of required s+
libvirtd.service            loaded active running   Virtualization daemon
nscd.service                loaded active running   Name Service Cache Daemon
ntpd.service                loaded active running   NTP Server Daemon
polkit.service              loaded active running   Authorization Manager
postfix.service             loaded active running   Postfix Mail Transport Ag+
rc-local.service            loaded active exited    /etc/init.d/boot.local Co+
rsyslog.service             loaded active running   System Logging Service
[...]
LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

161 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

起動に失敗したサービスだけを表示する場合は、--failedオプションを指定してください。

例 13.2: 起動に失敗したサービスの一覧表示
root # systemctl --failed
UNIT                   LOAD   ACTIVE SUB    JOB DESCRIPTION
apache2.service        loaded failed failed     apache
NetworkManager.service loaded failed failed     Network Manager
plymouth-start.service loaded failed failed     Show Plymouth Boot Screen

[...]

13.3.2.2 起動時間のデバッグ

システムの起動時間をデバッグするために、systemdでは、systemd-analyzeコマンドが用意されています。このコマンドでは、全体の起動時間や起動時間順のサービス一覧を表示できるほか、他のサービスの起動時間と対比するために利用できる、SVG画像を生成することもできます。

システムの起動時間の一覧表示
root # systemd-analyze
Startup finished in 2666ms (kernel) + 21961ms (userspace) = 24628ms
サービスの起動時間の一覧表示
root # systemd-analyze blame
  6472ms systemd-modules-load.service
  5833ms remount-rootfs.service
  4597ms network.service
  4254ms systemd-vconsole-setup.service
  4096ms postfix.service
  2998ms xdm.service
  2483ms localnet.service
  2470ms SuSEfirewall2_init.service
  2189ms avahi-daemon.service
  2120ms systemd-logind.service
  1210ms xinetd.service
  1080ms ntp.service
[...]
    75ms fbset.service
    72ms purge-kernels.service
    47ms dev-vda1.swap
    38ms bluez-coldplug.service
    35ms splash_early.service
サービスの起動時間を表す画像
root # systemd-analyze plot > jupiter.example.com-startup.svg

13.3.2.3 起動プロセス全体の確認

上述のコマンドを利用することで、起動したサービスと起動にかかった時間を確認できます。さらに詳しい情報が必要な場合は、ブートプロンプトで次のパラメータを入力することにより、systemdに対して、起動手順全体の冗長ログを記録するように指示できます。

systemd.log_level=debug systemd.log_target=kmsg

systemdが、ログメッセージをカーネルのリングバッファに書き込むようになります。バッファを閲覧するには、dmesgを使用してください。

dmesg -T | less

13.3.3 System Vとの互換性

systemdはSystem Vと互換性があるため、引き続き既存のSystem V initスクリプトを使用できます。ただし、そのままではsystemdでSystem V initスクリプトを使用できない既知の問題が少なくとも1つあります。initスクリプトでsuまたはsudoを使用して別のユーザとしてサービスを起動すると、スクリプトエラーになり、アクセス拒否エラーが生成されます。

suまたはsudoを使用してユーザを変更すると、PAMセッションが開始されます。このセッションは、initスクリプトが完了すると終了します。その結果、initスクリプトで起動されたサービスも終了します。このエラーを回避するには、次の手順に従います。

  1. initスクリプトと同じ名前を持ち、ファイル名拡張子.serviceが付くサービスファイルラッパーを作成します。

    [Unit]
    Description=DESCRIPTION
    After=network.target
    
    [Service]
    User=USER
    Type=forking1
    PIDFile=PATH TO PID FILE1
    ExecStart=PATH TO INIT SCRIPT start
    ExecStop=PATH TO INIT SCRIPT stop
    ExecStopPost=/usr/bin/rm -f PATH TO PID FILE1
    
    [Install]
    WantedBy=multi-user.target2

    大文字で記述されている値はすべて適切な値に置き換えてください。

    1

    オプション: initスクリプトでデーモンを起動する場合にのみ使用してください。

    2

    multi-user.targetは、graphical.targetでブートしたときにinitスクリプトも起動します。ディスプレイマネージャでブートする場合にのみinitスクリプトを起動するときは、ここでgraphical.targetを使用します。

  2. systemctl start APPLICATIONでデーモンを起動します。

13.4 YaSTを使用したサービスの管理

基本的なサービス管理は、YaSTサービスマネージャモジュールで行うこともできます。このモジュールは、サービスの起動、停止、有効化、および無効化をサポートしています。サービスのステータスを表示したり、デフォルトのターゲットを変更することもできます。YaST › システム › サービスマネージャの順に選択して、YaSTモジュールを起動します。

サービスマネージャ
図 13.1: サービスマネージャ
デフォルトのシステムターゲットの変更

システムのブート先になるターゲットを変更するには、デフォルトのシステムターゲットドロップダウンボックスからターゲットを選択します。最もよく使用されているターゲットは、グラフィカルインタフェース(グラフィカルなログイン画面を起動する)とマルチユーザ(コマンドラインモードでシステムを起動する)です。

サービスの起動または停止

テーブルからサービスを選択します。アクティブ列は、現在サービスが実行されているかどうかを示します(アクティブか、アクティブでないかを示します)。ステータスを切り替えるには、起動/停止を選択します。

サービスを起動または停止すると、現在実行されているセッションのステータスが変更されます。再起動時にステータスを変更するには、サービスを有効化または無効化する必要があります。

サービスの有効化または無効化

テーブルからサービスを選択します。有効化列は、現在サービスが有効化されているか、それとも無効化されているかを示します。ステータスを切り替えるには、有効/無効を選択します。

サービスを有効化/無効化することにより、サービスがブート時に起動されるかどうか(有効化)または無効化)を設定できます。この設定は、現在のセッションには影響しません。現在のセッションにおけるサービスのステータスを変更するには、サービスを起動または停止する必要があります。

ステータスメッセージの表示

サービスのステータスメッセージを表示するには、リストからサービスを選択し、詳細の表示を選択します。表示される内容は、コマンドsystemctl -l status MY_SERVICEで生成されたものと同じです。

警告
警告: ランレベルの設定を誤るとシステムに害が及ぶことがある

ランレベルの設定が誤っていると、システムを使用できなくなることがあります。変更を実際に適用する前に、どういう結果が出るかをよく確認してください。

13.5 systemdのカスタマイズ

以降の各項には、systemdのカスタマイズ例が示されています。

警告
警告: カスタマイズの上書きの回避

systemdのカスタマイズは/etc/systemd/で行ってください。/usr/lib/systemd/では、絶対に行わないでください。そうしないと、systemdの次回の更新によって、変更内容が上書きされてしまいます。

13.5.1 サービスファイルのカスタマイズ

systemdサービスファイルは、/usr/lib/systemd/systemにあります。サービスファイルをカスタマイズする場合は、次の手順に従います。

  1. 変更対象のファイルを/usr/lib/systemd/systemから/etc/systemd/systemにコピーします。ファイル名は、元の名前のまま残します。

  2. /etc/systemd/systemのコピーを適宜変更します。

  3. 設定変更の概要を表示するには、systemd-deltaコマンドを使用します。このコマンドを使用すると、他の設定ファイルを上書きする設定ファイルを特定したり、複数の設定ファイルを比較対照することができます。詳細については、systemd-deltaマニュアルページを参照してください。

ファイル名が同じ場合、/etc/systemdにある変更済みファイルが、/usr/lib/systemd/systemにある元のファイルよりも優先的に使用されます。

13.5.2 ドロップインファイルの作成

設定ファイルに何行かを追加したり、設定ファイルのごく一部を変更するには、ドロップインと呼ばれるファイルを使用します。ドロップインファイルを使用すると、ユニットファイルの設定を拡張できます。その際に、ユニットファイル自体は編集も上書きもされません。

たとえば、/usr/lib/systemd/system/FOOBAR.SERVICEにあるFOOBARサービスの1つの値を変更するには、次の手順に従います。

  1. /etc/systemd/system/MY_SERVICE.service.d/というディレクトリを作成します。

    .dサフィックスが付いていることに注意してください。それ以外の点では、このディレクトリは、ドロップインファイルでパッチ適用するサービスと同じ名前になります。

  2. ディレクトリ内に、WHATEVERMODIFICATION.confファイルを作成します。

    このファイルには、変更する値が設定されている行のみを含めます。

  3. ファイルに変更内容を保存します。このファイルは、元のファイルへの拡張として使用されます。

13.5.3 カスタムターゲットの作成

System V init SUSEシステムでは、管理者が独自のランレベル設定を作成できるように、ランレベル4は使用されていません。systemdでは、任意の数のカスタムターゲットを作成できます。ターゲットの作成は、graphical.targetなどの既存のターゲットを改変することから始めることをお勧めします。

  1. 設定ファイル/usr/lib/systemd/system/graphical.target/etc/systemd/system/MY_TARGET.targetにコピーして、必要に応じて修正してください。

  2. 前のステップでコピーした設定ファイルは、すでにターゲットの必須な(ハード)依存関係を構築した状態になっています。希望する(ソフト)依存関係も構築するには、/etc/systemd/system/MY_TARGET.target.wantsディレクトリを作成します。

  3. 希望するサービスごとに、/usr/lib/systemd/systemから/etc/systemd/system/MY_TARGET.target.wantsへのシンボリックリンクを作成します。

  4. ターゲットの設定が完了したら、新しいターゲットを利用できるようにするために、systemdの設定を再ロードします。

    systemctl daemon-reload

13.6 高度な使用方法

次のセクションでは、システム管理者向けの高度なトピックについて説明します。さらに高度なsystemdのドキュメントについては、Lennart Pöttering氏によるsystemdの資料(http://0pointer.de/blog/projects)を参照してください。

13.6.1 一時ディレクトリの消去

systemdによって、定期的に一時ディレクトリを消去できます。前バージョンのシステムの設定は、自動的に移行されアクティブになります。一時ファイルを管理するtmpfiles.dは、/etc/tmpfiles.d/*.conf/run/tmpfiles.d/*.conf、および/usr/lib/tmpfiles.d/*.confファイルから設定を読み取ります。/etc/tmpfiles.d/*.confにある設定は、他の2つのディレクトリにある関連設定より優先します(/usr/lib/tmpfiles.d/*.confには、パッケージの設定ファイルが保存されています)。

設定のフォーマットは、パスごとに1行で、アクション、パス、およびオプションでモード、所有権、経過時間、引数のフィールドが含まれています(アクションによって変わります)。次の例は、X11ロックファイルのリンクを解除します。

Type Path               Mode UID  GID  Age Argument
r    /tmp/.X[0-9]*-lock

tmpfile timerのステータスを取得するには、以下のようにします。

systemctl status systemd-tmpfiles-clean.timer
systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
 Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static)
 Active: active (waiting) since Tue 2014-09-09 15:30:36 CEST; 1 weeks 6 days ago
   Docs: man:tmpfiles.d(5)
         man:systemd-tmpfiles(8)

Sep 09 15:30:36 jupiter systemd[1]: Starting Daily Cleanup of Temporary Directories.
Sep 09 15:30:36 jupiter systemd[1]: Started Daily Cleanup of Temporary Directories.

一時ファイルの処理について詳しくは、man 5 tmpfiles.dを参照してください。

13.6.2 システムログ

13.6.8項 「サービスのデバッグ」には、特定のサービスに対するログメッセージを閲覧する方法が説明されていますが、表示されるログメッセージは、サービスログからのものだけであるとは限りません。systemdが記録したすべてのログメッセージ(ジャーナルと呼ばれる)にアクセスして問い合わせることもできます。最も古いログから始めて、すべてのログメッセージを表示するには、journalctlコマンドを使用します。フィルタの適用や出力形式の変更については、man 1 journalctlを参照してください。

13.6.3 スナップショット

systemdの現在の状態を名前付きのスナップショットに保存し、後でisolateサブコマンドを使用してその状態に戻ることができます。定義した状態にいつでも戻ることができるため、サービスやカスタムターゲットをテストする際に便利です。スナップショットは現在のセッションでのみ使用可能で、システムを再起動すると自動的に削除されます。スナップショットの名前は、.snapshotで終わる必要があります。

スナップショットの作成
systemctl snapshot MY_SNAPSHOT.snapshot
スナップショットの削除
systemctl delete MY_SNAPSHOT.snapshot
スナップショットの表示
systemctl show MY_SNAPSHOT.snapshot
スナップショットの有効化
systemctl isolate MY_SNAPSHOT.snapshot

13.6.4 カーネルモジュールのロード

systemdにより、/etc/modules-load.dにある環境設定ファイルを使用してブート時に自動的にカーネルモジュールをロードできます。このファイルはMODULE.confという名前で、次のような内容です。

# load module MODULE at boot time
MODULE

カーネルモジュールをロードするための設定ファイルがパッケージによってインストールされる場合、そのファイルは/usr/lib/modules-load.dにインストールされます。同じ名前の環境設定ファイルが2つ存在する場合、/etc/modules-load.dにあるファイルが優先されます。

詳細については、modules-load.d(5)のマニュアルページを参照してください。

13.6.5 サービスのロード前にアクションを実行

System Vでは、サービスをロードする前に実行する必要のあるinitアクションは、/etc/init.d/before.local に指定する必要がありました。この手順は、systemdではサポートされません。サービスの起動前にアクションを実行する必要がある場合、以下のようにしてください。

カーネルモジュールのロード

ドロップインファイルを/etc/modules-load.d ディレクトリに作成します(構文は、man modules-load.dを参照)。

ファイルまたはディレクトリの作成、ディレクトリの消去、所有権の変更

ドロップインファイルを/etc/tmpfiles.dに作成します(構文は、man tmpfiles.dを参照)。

その他のタスク

システムサービス(/etc/systemd/system/before.serviceなど)を、次のテンプレートから作成します。

[Unit]
Before=NAME OF THE SERVICE YOU WANT THIS SERVICE TO BE STARTED BEFORE
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=YOUR_COMMAND
# beware, executable is run directly, not through a shell, check the man pages
# systemd.service and systemd.unit for full syntax
[Install]
# target in which to start the service
WantedBy=multi-user.target
#WantedBy=graphical.target

サービスファイルを作成したら、次のコマンドを実行する必要があります(rootユーザとして実行)。

systemctl daemon-reload
systemctl enable before

サービスファイルを変更するたびに、以下を実行する必要があります。

systemctl daemon-reload

13.6.6 カーネルのコントロールグループ(cgroup)

従来のSystem V initシステムでは、特定のプロセスを、その生成元のサービスに対して明確に割り当てられないことがありました。Apacheなどの一部のサービスは、サードパーティのプロセス(CGIやJavaのプロセス)を多数生成し、サードパーティのプロセス自体もさらにプロセスを生成します。サービスに対する明確な割り当ては難しいことがあるだけでなく、場合によっては不可能であることもあります。一部の子プロセスを残して、サービスが正しく終了しないことも考えられます。

systemdでは、各プロセスを独自のcgroupに配置することでこの問題を解決しています。cgroupはプロセスをまとめるためのカーネルの機能で、すべての子プロセスを階層構造のグループとして管理します。systemdでは、各cgroupにそのサービスの名前が付けられています。非特権プロセスではcgroupから離脱できないため、サービスから生成したプロセスがどれなのかをサービス名によって判別できる効果的な仕組みです。

サービスに属するすべてのプロセスを表示するには、systemd-cglsコマンドを使用します。次の例のような結果になります(一部省略しています)。

例 13.3: サービスに属するすべてのプロセスの表示
root # systemd-cgls --no-pager
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 20
├─user.slice
│ └─user-1000.slice
│   ├─session-102.scope
│   │ ├─12426 gdm-session-worker [pam/gdm-password]
│   │ ├─15831 gdm-session-worker [pam/gdm-password]
│   │ ├─15839 gdm-session-worker [pam/gdm-password]
│   │ ├─15858 /usr/lib/gnome-terminal-server

[...]

└─system.slice
  ├─systemd-hostnamed.service
  │ └─17616 /usr/lib/systemd/systemd-hostnamed
  ├─cron.service
  │ └─1689 /usr/sbin/cron -n
  ├─ntpd.service
  │ └─1328 /usr/sbin/ntpd -p /var/run/ntp/ntpd.pid -g -u ntp:ntp -c /etc/ntp.conf
  ├─postfix.service
  │ ├─ 1676 /usr/lib/postfix/master -w
  │ ├─ 1679 qmgr -l -t fifo -u
  │ └─15590 pickup -l -t fifo -u
  ├─sshd.service
  │ └─1436 /usr/sbin/sshd -D

[...]

cgroupの詳細については、Book “System Analysis and Tuning Guide”, Chapter 9 “Kernel Control Groups”を参照してください。

13.6.7 サービスの終了(シグナルの送信)

13.6.6項 「カーネルのコントロールグループ(cgroup)」で説明したとおり、System V initのシステムでは、プロセスをその親サービスプロセスに割り当てることができないことがあります。そのため、サービスとそのすべての子プロセスを終了するのが難しくなります。終了されていない子プロセスは、ゾンビプロセスとして残ってしまいます。

各サービスをcgroupに範囲制約するという、systemdの概念を採用することで、サービスのすべての子プロセスを明確に判別し、それら各プロセスに対してシグナルを送信できます。サービスに対してシグナルを送信する場合は、systemctl killコマンドを使用します。使用可能なシグナルの一覧については、man 7 signalsを参照してください。

サービスに対するSIGTERMの送信

SIGTERMは、送信されるデフォルトのシグナルです。

systemctl kill MY_SERVICE
サービスに対するSIGNALの送信

-sオプションを使用することで、送信するシグナルを指定できます。

systemctl kill -s SIGNAL MY_SERVICE
プロセスの選択

デフォルトでは、killコマンドは、指定したcgroup内のall (すべての)プロセスに対してシグナルを送信します。control (制御)またはmain (メイン)のプロセスに対してだけ送信することもできます。限定されたプロセスに対する送信は、SIGHUPを送信して設定を再ロードさせるような場合に有効です。

systemctl kill -s SIGHUP --kill-who=main MY_SERVICE
警告
警告: D-BUSサービスの停止または再起動はサポートされない

D-Busサービスは、systemdクライアントと、pid 1として実行されるsystemdマネージャ間の通信用のメッセージバスです。dbusはスタンドアロンのデーモンですが、初期化インフラストラクチャの不可欠な要素です。

動作中のシステムでdbusを終了または再起動することは、pid 1の終了または再起動と同様の結果をもたらします。systemdのクライアント/サーバ通信が切断され、systemdのほとんどの機能が使用できなくなります。

したがって、dbusの終了または再起動は推奨されず、サポートもされません。

13.6.8 サービスのデバッグ

デフォルトでは、systemdは過剰に冗長な出力を行いません。サービスの起動が成功した場合は何も出力されず、失敗した場合は短いエラーメッセージが表示されます。サービスの起動や操作をデバッグする場合は、systemctl statusコマンドを使用してください。

systemdは、独自のログ機構(ジャーナル)でシステムメッセージを記録します。これにより、サービスメッセージとステータスメッセージを両方とも表示できます。statusコマンドはtailコマンドに似た動作をするほか、ログメッセージをさまざまな形式で表示することもできます。これにより、強力なデバッグツールとして利用できるようになっています。

サービスの起動失敗の表示

サービスの起動に失敗した場合は、systemctl status MY_SERVICEを実行することで、詳細なエラーメッセージを表示することができます。

root # systemctl start apache2
Job failed. See system journal and 'systemctl status' for details.
root # systemctl status apache2
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
   Active: failed (Result: exit-code) since Mon, 04 Jun 2012 16:52:26 +0200; 29s ago
   Process: 3088 ExecStart=/usr/sbin/start_apache2 -D SYSTEMD -k start (code=exited, status=1/FAILURE)
   CGroup: name=systemd:/system/apache2.service

Jun 04 16:52:26 g144 start_apache2[3088]: httpd2-prefork: Syntax error on line
205 of /etc/apache2/httpd.conf: Syntax error on li...alHost>
直近N件のサービスメッセージ

statusサブコマンドは、デフォルトではサービスが出力した直近の10件のメッセージを表示します。表示するメッセージの件数を変更したい場合は、--lines=Nパラメータを使用して実行してください。

systemctl status ntp
systemctl --lines=20 status ntp
追記モードによるサービスメッセージの表示

サービスメッセージをリアルタイムに表示するには、--followオプションを使用します。このオプションは、tail -fに似た動作をします。

systemctl --follow status ntp
メッセージの出力形式

--output=MODEパラメータを指定すると、サービスメッセージの出力形式を変更できます。最も重要なモードには次のものがあります。

short

デフォルトの形式。ログメッセージを、人間が読みやすいタイムスタンプと併記して表示します。

verbose

すべての項目を表示する完全な出力。

cat

タイムスタンプを併記しない、簡潔な出力。

13.7 詳細情報

systemdの詳細については、次のオンラインリソースを参照してください。

ホームページ

http://www.freedesktop.org/wiki/Software/systemd

systemd (管理者向け)

systemdの著者のうちの1人、Lennart Pöttering氏によるブログに、systemdに関する複数の投稿があります(本章記述時点では13個の投稿)。それらは、次のサイトに記載されています。http://0pointer.de/blog/projects

パート III システム

14 64ビットシステム環境での32ビットと64ビットのアプリケーション

SUSE® Linux Enterprise Server複数の64ビットプラットフォームで利用できます。ただし、付属のすべてのアプリケーションが64ビットプラットフォームに移植されているわけではありません。SUSE Linux Enterprise Serverは、64ビットシステム環境での32ビットアプリケーションの使用をサポートしています。この章では、このサポートを64ビットのSUSE Linux Enterprise Serverプラットフォームで実装する方法について簡潔に説明します。

15 journalctl:systemdジャーナルのクエリ

SUSE Linux Enterprise 12の従来のinitスクリプトがsystemdに置き換えられた際に(第13章 「systemdデーモンを参照)、ジャーナルと呼ばれる専用ログシステムが導入されました。すべてのシステムイベントがジャーナルに書き込まれるようになったため、syslogベースのサービスを実行する必要はありません。

16 ネットワークの基礎

Linuxには、あらゆるタイプのネットワークストラクチャに統合するために必要なネットワークツールと機能が用意されています。ネットワークカードを使用したネットワークアクセスは、YaSTによって設定できます。手動による環境設定も可能です。この章では、基本的メカニズムと関連のネットワーク設定ファイルのみを解説します。

17 プリンタの運用

SUSE® Linux Enterprise Serverは、リモートネットワークプリンタも含め、さまざまな種類のプリンタを使った印刷をサポートしています。プリンタは手動で設定することも、YaSTを使用して設定することもできます。設定の詳細については、Book “導入ガイド”, Chapter 11 “YaSTによるハードウェアコンポーネントの設定”, Section 11.3 “プリンタの設定”を参照してください。プリントジョブの開始、管理には、グラフィカルインタフェースまたはコマンドラインユーティリティの両方を利用できます。 プリンタが正常に動作しない場合は、17.8項 「トラブルシューテ…

18 X Windowシステム

Xウィンドウシステム(X11)は、UNIX系のグラフィカルユーザインタフェースで、事実上の標準となっています。Xはネットワークベースであり、あるホスト上で起動されたアプリケーションを、任意のネットワーク(LANやインターネット)を介して接続されている他のホスト上で表示できるようにします。この章では、X設定の基本情報と、SUSE® Linux Enterprise Serverでのフォント使用の背景情報を提供します。

19 FUSEによるファイルシステムへのアクセス

FUSEは、file system in user spaceの頭字語です。これは、特権のないユーザとしてファイルシステムを設定およびマウントできることを意味します。通常、このタスクを行うためには、rootである必要があります。FUSE自体は、カーネルモジュールです。FUSEは、プラグインと組み合わせることで、ほとんどすべてのファイルシステムにアクセスするように拡張できます(リモートSSH接続、ISOイメージなど)。

20 カーネルモジュールの管理

Linuxはモノリシックカーネルですが、カーネルモジュールを使用して拡張することができます。カーネルモジュールは、オンデマンドでカーネルに挿入したり、カーネルから削除したりできる特別なオブジェクトです。実際面では、カーネルモジュール自体に含まれないドライバやインタフェースを追加および削除できます。Linuxは、カーネルモジュールを管理するためのコマンドをいくつか備えています。

21 udevによる動的カーネルデバイス管理

カーネルは、実行中のシステムのほぼすべてのデバイスを追加または削除できます。デバイス状態の変更(デバイスが接続されているか、または取り外されたか)をユーザスペースに反映させる必要があります。デバイスは、接続後、検出されたら、設定しなければなりません。特定のデバイスのユーザは、このデバイスの認識された状態が変更された場合は通知される必要があります。udevは、/devディレクトリのデバイスノートファイルおよびシンボリックリンクを動的に維持するために必要なインフラストラクチャを提供します。udev規則は、外部ツールをカーネルデバイスイベント処理に接続する方法を提供します。これにより、カーネルデバイ…

22 kGraftを使用したLinuxカーネルのライブパッチ適用

このドキュメントでは、kGraftライブパッチ適用テクノロジの基本原理について説明するとともに、SLE Live Patchingサービスの使用ガイドラインを提供します。

kGraftは、Linuxカーネルを停止することなく、実行時にカーネルのパッチを適用するライブパッチ適用テクノロジです。これにより、ミッションクリティカルなシステムにとって重要なシステムのアップタイム、つまりシステムの可用性が最大化されます。また、このテクノロジによってカーネルの動的なパッチ適用が可能になるため、ユーザは、予定されたダウンタイムまで延期することなく、重要なセキュリティアップデートをインストールできます。

kGraftパッチは、カーネル内の関数全体を置換することを目的としたカーネルモジュールです。kGraftは基本的に、パッチが適用されたコードとカーネルのベースコードを実行時に統合するためのカーネル内インフラストラクチャを提供します。

SLE Live Patchingは、SUSE Linux Enterprise Serverの定期保守に加えて提供されるサービスです。SLE Live Patchingを通じて配信されるkGraftパッチは、SLESの定期保守のアップデートを補足するものです。SLE Live Patchingの展開にも共通の更新スタックおよび手順を使用することができます。

このドキュメントで提供される情報は、AMD64/Intel 64およびPOWERアーキテクチャに関連しています。異なるアーキテクチャを使用する場合は、手順が異なる場合があります。

23 特別なシステム機能

この章では、まず、さまざまなソフトウェアパッケージ、バーチャルコンソール、およびキーボードレイアウトについて説明します。bashcron、およびlogrotateといったソフトウェアコンポーネントについても説明します。これらは、前回のリリースサイクルで変更または強化されたからです。これらのコンポーネントはそれほど重要ではないと思われるかもしれませんが、システムと密接に結びついているものなので、デフォルトの動作を変更することをお勧めします。この章の最後では、言語および国固有設定(I18NおよびL10N)について説明します。

14 64ビットシステム環境での32ビットと64ビットのアプリケーション

SUSE® Linux Enterprise Server複数の64ビットプラットフォームで利用できます。ただし、付属のすべてのアプリケーションが64ビットプラットフォームに移植されているわけではありません。SUSE Linux Enterprise Serverは、64ビットシステム環境での32ビットアプリケーションの使用をサポートしています。この章では、このサポートを64ビットのSUSE Linux Enterprise Serverプラットフォームで実装する方法について簡潔に説明します。

64ビットプラットフォームのPOWER、z Systems、およびAMD64/Intel 64に対応したSUSE Linux Enterprise Server}は、インストール後すぐに既存の32ビットアプリケーションが64ビット環境で動作するように設計されています。対応する32ビットプラットフォームは、POWERではppc、AMD64/Intel 64ではx86になります。このサポートにより、対応する 64ビット移植版が使用可能になるのを待たなくても、使用したい 32ビットアプリケーションを引き続き使用できます。現在のPOWERシステムでは、大部分のアプリケーションが32ビットモードで実行されますが、64ビットアプリケーションを実行することもできます。

注記
注記: 32ビットアプリケーションを構築するためのサポートなし

SUSE Linux Enterprise Serverは32ビットアプリケーションのコンパイルをサポートしていません。32ビットバイナリのランタイムサポートのみを提供しています。

14.1 ランタイムサポート

重要
重要: アプリケーションバージョン間の競合

アプリケーションが32ビットと64ビットの両方の環境で使用可能な場合に、両方のバージョンを同時にインストールすると問題が生じます。そのような場合は、2つのバージョンのどちらかだけをインストールして使用してください。

PAM(プラグ可能認証モジュール)は、このルールの例外です。SUSE Linux Enterprise Serverは、ユーザとアプリケーションを仲介するレイヤとしての認証プロセスでPAMを使用します。また、 32ビットアプリケーションも実行する64ビットオペレーティングシステムでは、常に両バージョンのPAMモジュールをインストールする必要があります。

正しく実行するために、すべてのアプリケーションにはライブラリが必要です。しかし残念ながら、32ビットバージョンと64ビットバージョンのライブラリの名前は同じです。そのため、ライブラリを別の方法で区別する必要があります。

32ビットバージョンとの互換性を維持するために、ライブラリは32ビット環境の場合と同じシステム内の場所に格納されます。libc.so.6の32ビットバージョンは、32ビットと64ビットのどちらの環境でも/lib/libc.so.6の下にあります。

64ビットのすべてのライブラリとオブジェクトファイルは、lib64というディレクトリにあります。通常、/libおよび/usr/libの下にある64ビットのオブジェクトファイルは、/lib64および/usr/lib64の下にあります。つまり、両方のバージョンのファイル名を変更しなくても済むように、32ビットライブラリ用の領域は/libおよび/usr/libの下になっています。

ワードサイズに依存しないデータコンテンツを持つ、32ビットの/libディレクトリ中のサブディレクトリは移動されません。このスキームは、LSB (Linux Standards Base)とFHS (File System Hierarchy Standard)に準拠しています。

14.2 カーネル仕様

AMD 64/Intel 64、POWER、およびz Systems向けの64ビットカーネルには、64ビットと32ビットのカーネルABI (アプリケーションバイナリインタフェース)が用意されています。32ビットのカーネルABIは、該当する32ビットカーネルのABIと同じものです。つまり、32ビットアプリケーションが、32ビットカーネルの場合と同様に64ビットカーネルと通信できるということです。

64ビットカーネルのシステムコールの32ビットエミュレーションでは、システムプログラムで使用されるすべてのAPIをサポートしていません。ただし、このサポートの有無はプラットフォームによって異なります。このため、lspciなどのいくつかのアプリケーションは、正しく機能するよう、64ビットプログラムとして非POWERプラットフォームでコンパイルする必要があります。IBM z Systemsでは、32ビットカーネルABIで利用できないioctlsがあります。

64ビットカーネルでは、このカーネル用に特別にコンパイルされた64ビットカーネルモジュールしかロードできません。したがって、32ビットカーネルモジュールを使用することはできません。

ヒント
ヒント: カーネルロード可能モジュール

一部のアプリケーションには、カーネルでロード可能な個々のモジュールが必要です。64ビットシステム環境でそのような32ビットアプリケーションを使用する予定がある場合は、このアプリケーションおよびSUSEのプロバイダに問い合わせて、このモジュール向けのカーネルでロード可能な64ビットバージョンのモジュールと32ビットコンパイルバージョンのカーネルAPIを入手できるかを確認してください。

15 journalctl:systemdジャーナルのクエリ

SUSE Linux Enterprise 12の従来のinitスクリプトがsystemdに置き換えられた際に(第13章 「systemdデーモンを参照)、ジャーナルと呼ばれる専用ログシステムが導入されました。すべてのシステムイベントがジャーナルに書き込まれるようになったため、syslogベースのサービスを実行する必要はありません。

ジャーナル自体は、systemdによって管理されるシステムサービスです。完全な名前はsystemd-journald.serviceです。カーネル、ユーザプロセス、標準入力、およびシステムサービスエラーから受信したログ情報に基づいて、構造化されたインデックスジャーナルを維持することで、ログデータを収集して保存します。systemd-journaldサービスはデフォルトでオンになっています。

# systemctl status systemd-journald
systemd-journald.service - Journal Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
   Active: active (running) since Mon 2014-05-26 08:36:59 EDT; 3 days ago
     Docs: man:systemd-journald.service(8)
           man:journald.conf(5)
 Main PID: 413 (systemd-journal)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-journald.service
           └─413 /usr/lib/systemd/systemd-journald
[...]

15.1 ジャーナルの永続化

ジャーナルは、デフォルトでは/run/log/journal/にログデータを保存します。/run/ディレクトリは本質的に揮発性であるため、再起動するとログデータは失われます。ログデータを永続化するには、systemd-journaldサービスがそのデータを保存できる、適切な所有権と許可のある/var/log/journal/ディレクトリが存在している必要があります。systemdは自動的にディレクトリを作成します。永続的なログに切り替えるには、次の手順を実行します。

  1. rootとして、/etc/systemd/journald.confを開き編集します。

    # vi /etc/systemd/journald.conf
  2. Storage=を含む行をコメント解除し、次のように変更します。

    [...]
    [Journal]
    Storage=persistent
    #Compress=yes
    [...]
  3. ファイルを保存して、systemd-journaldを再起動します。

    systemctl restart systemd-journald

15.2 journalctlの便利なスイッチ

このセクションでは、デフォルトのjournalctlの動作を拡張する一般的な便利なオプションをいくつか紹介します。スイッチはすべて、journalctlのマニュアルページのman 1 journalctlで説明されています。

ヒント
ヒント: 特定の実行可能ファイルに関連するメッセージ

特定の実行可能ファイルに関連するすべてのジャーナルメッセージを表示するには、実行可能ファイルのフルパスを指定します。

journalctl /usr/lib/systemd/systemd
-f

最新のジャーナルメッセージのみを表示し、新しいログエントリがジャーナルに追加されるとそれらを出力します。

-e

メッセージを出力してジャーナルの最後に移動します。これにより、最新のエントリをページャ内に表示できます。

-r

ジャーナルのメッセージを逆順に出力します。これにより、最新のエントリが最初に一覧にされます。

-k

カーネルメッセージのみを表示します。これは、フィールド照合機能_TRANSPORT=kernelと同等です(15.3.3項 「フィールドに基づくフィルタ」を参照)。

-u

指定したsystemdユニットのメッセージのみを表示します。これは、フィールド照合機能_SYSTEMD_UNIT=UNITと同等です(15.3.3項 「フィールドに基づくフィルタ」を参照)。

# journalctl -u apache2
[...]
Jun 03 10:07:11 pinkiepie systemd[1]: Starting The Apache Webserver...
Jun 03 10:07:12 pinkiepie systemd[1]: Started The Apache Webserver.

15.3 ジャーナル出力のフィルタ

スイッチなしでjournalctlを呼び出すと、最も古いエントリを先頭にジャーナルのすべてのコンテンツが表示されます。出力は、特定のスイッチとフィールドによってフィルタできます。

15.3.1 ブート番号に基づくフィルタ

journalctlは特定のシステムブートに基づいてメッセージをフィルタできます。利用可能なブートを一覧もするには、次を実行します。

# journalctl --list-boots
-1 097ed2cd99124a2391d2cffab1b566f0 Mon 2014-05-26 08:36:56 EDT—Fri 2014-05-30 05:33:44 EDT
 0 156019a44a774a0bb0148a92df4af81b Fri 2014-05-30 05:34:09 EDT—Fri 2014-05-30 06:15:01 EDT

1番目の列にはブートオフセットが一覧にされます。現在のブートの場合は0、直前のブートの場合は-1、その1つ前のブートの場合は-2といった具合になります。2番目の列には、ブートIDが含まれ、特定のブートに限定するためのタイムスタンプが続きます。

現在のブートのすべてのメッセージを表示します。

# journalctl -b

直前のブートのジャーナルメッセージを表示する必要がある場合は、オフセットパラメータを追加します。次の例は、直前のブートメッセージを出力します。

# journalctl -b -1

もう1つの方法は、ブートIDに基づいてブートメッセージを一覧にする方法です。このためには、_BOOT_IDフィールドを使用します。

# journalctl _BOOT_ID=156019a44a774a0bb0148a92df4af81b

15.3.2 時間間隔に基づくフィルタ

開始日または終了日、あるいはその両方を指定して、journalctlの出力をフィルタできます。日付指定は、「2014-06-30 9:17:16」の形式にする必要があります。時間の部分を省略すると、夜中の12:00と想定されます。秒を省略すると、「:00」と想定されます。日付の部分を省略すると、当日と想定されます。数値式ではなく、キーワード「yesterday」、「today」、または「tomorrow」を指定することができます。これらは、当日の前日の夜中の12:00、当日の夜中の12:00、または当日の翌日の夜中の12:00を示します。「now」を指定すると、当日を示します。また、-または+をプレフィクスとして付けて、現在時刻の前後を示す相対時間を指定することもできます。

現在時刻以降の新しいメッセージのみを表示し、出力を継続的に更新します。

# journalctl --since "now" -f

直前の夜12:00から午前3:20までのすべてのメッセージを表示します。

# journalctl --since "today" --until "3:20"

15.3.3 フィールドに基づくフィルタ

特定のフィールドによってジャーナルの出力をフィルタできます。照合するフィールドの構文は、FIELD_NAME=MATCHED_VALUEです(_SYSTEMD_UNIT=httpd.serviceなど)。1つのクエリに複数の照合を指定することで、出力メッセージをさらにフィルタすることができます。デフォルトフィールドのリストについては、man 7 systemd.journal-fieldsを参照してください。

特定のプロセスIDによって生成されたメッセージを表示します。

# journalctl _PID=1039

特定のユーザIDに属するメッセージを表示します。

# journalctl _UID=1000

カーネルリングバッファのメッセージを表示します(dmesgが生成するものと同じ)。

# journalctl _TRANSPORT=kernel

サービスの標準出力またはエラー出力のメッセージを表示します。

# journalctl _TRANSPORT=stdout

指定されたサービスによって生成されたメッセージのみを表示します。

# journalctl _SYSTEMD_UNIT=avahi-daemon.service

2つの異なるフィールドを指定すると、同時に両方の式に一致するエントリのみが表示されます。

# journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=1488

2つの照合が同じフィールドを示している場合は、いずれかの式に一致するすべてのエントリが表示されます。

# journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service

「+」セパレータを使用して、2つの式を論理「OR」で組み合わせることができます。次の例は、プロセスIDが1480のAvahiサービスプロセスのすべてのメッセージと、D-Busサービスのすべてのメッセージを表示します。

# journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=1480 + _SYSTEMD_UNIT=dbus.service

15.4 systemdエラーの調査

このセクションでは、apache2の起動時にsystemdによってレポートされたエラーを検出および修復する方法を示す簡単な例を紹介します。

  1. apache2サービスの起動を試みます。

    # systemctl start apache2
    Job for apache2.service failed. See 'systemctl status apache2' and 'journalctl -xn' for details.
  2. サービスの状態に関する記述を確認します。

    # systemctl status apache2
    apache2.service - The Apache Webserver
       Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
       Active: failed (Result: exit-code) since Tue 2014-06-03 11:08:13 CEST; 7min ago
      Process: 11026 ExecStop=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND \
               -k graceful-stop (code=exited, status=1/FAILURE)

    障害の原因となっているプロセスのIDは、11026です。

  3. プロセスID11026に関連するメッセージの詳細バージョンを表示します。

    # journalctl -o verbose _PID=11026
    [...]
    MESSAGE=AH00526: Syntax error on line 6 of /etc/apache2/default-server.conf:
    [...]
    MESSAGE=Invalid command 'DocumenttRoot', perhaps misspelled or defined by a module
    [...]
  4. /etc/apache2/default-server.conf内のタイプミスを修復し、apache2サービスを起動して、そのステータスを出力します。

    # systemctl start apache2 && systemctl status apache2
    apache2.service - The Apache Webserver
       Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
       Active: active (running) since Tue 2014-06-03 11:26:24 CEST; 4ms ago
      Process: 11026 ExecStop=/usr/sbin/start_apache2 -D SYSTEMD -DFOREGROUND
               -k graceful-stop (code=exited, status=1/FAILURE)
     Main PID: 11263 (httpd2-prefork)
       Status: "Processing requests..."
       CGroup: /system.slice/apache2.service
               ├─11263 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
               ├─11280 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
               ├─11281 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
               ├─11282 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
               ├─11283 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]
               └─11285 /usr/sbin/httpd2-prefork -f /etc/apache2/httpd.conf -D [...]

15.5 Journaldの設定

systemd-journaldサービスの動作を調整するには、/etc/systemd/journald.confを変更します。このセクションでは、基本的なオプションの設定のみを取り上げます。ファイルの詳細な説明については、man 5 journald.confを参照してください。変更を有効にするために、次のコマンドでジャーナルを再起動する必要がある点に注意してください。

# systemctl restart systemd-journald

15.5.1 ジャーナルサイズ制限の変更

ジャーナルログデータを永続的な場所に保存する場合(15.1項 「ジャーナルの永続化」を参照)、ジャーナルログデータは/var/log/journalが存在するファイルシステムの最大10%を使用します。たとえば、/var/log/journalを30GBの/varパーティションに配置すると、ジャーナルは最大3GBのディスク容量を使用します。この制限を変更するには、SystemMaxUseオプションを変更(およびコメント解除)します。

SystemMaxUse=50M

15.5.2 ジャーナルの/dev/ttyXへの転送

ジャーナルを端末デバイスに転送し、好みの端末画面(たとえば、/dev/tty12)でシステムメッセージに関する通知を受信できます。journaldオプションを次のように変更します。

ForwardToConsole=yes
TTYPath=/dev/tty12

15.5.3 ジャーナルのSyslog機能への転送

Journaldは、rsyslogなどの従来のsyslog実装との下位互換性があります。以下が正しいことを確認します。

  • rsyslogがインストールされている。

    # rpm -q rsyslog
    rsyslog-7.4.8-2.16.x86_64
  • rsyslogサービスが有効である。

    # systemctl is-enabled rsyslog
    enabled
  • /etc/systemd/journald.confでsyslogへの転送が有効になっている。

    ForwardToSyslog=yes

15.6 YaSTを使用したsystemdジャーナルのフィルタ

(journalctl構文を処理することなく)systemdジャーナルを簡単にフィルタするには、YaSTのジャーナルモジュールを使用します。sudo zypper in yast2-journalを使用してモジュールをインストールした後、YaSTでSystem (システム) › Systemd Journal (systemdジャーナル)の順に選択して起動します。または、コマンドラインで「sudo yast2 journal」と入力して起動します。

YaST systemdジャーナル
図 15.1: YaST systemdジャーナル

このモジュールでは、ログエントリが表に表示されます。上部にある検索ボックスを使用すると、grepを使用する場合と同様に、特定の文字を含むエントリを検索することができます。日時、ユニット、ファイル、または優先度でエントリをフィルタするには、Change filters (フィルタの変更)をクリックし、個々のオプションを設定します。

16 ネットワークの基礎

概要

Linuxには、あらゆるタイプのネットワークストラクチャに統合するために必要なネットワークツールと機能が用意されています。ネットワークカードを使用したネットワークアクセスは、YaSTによって設定できます。手動による環境設定も可能です。この章では、基本的メカニズムと関連のネットワーク設定ファイルのみを解説します。

Linuxおよび他のUnix系オペレーティングシステムは、TCP/IPプロトコルを使用します。これは1つのネットワークプロトコルではなく、さまざまなサービスを提供する複数のネットワークプロトコルのファミリです。TCP/IPを使用して2台のマシン間でデータをやり取りするために、TCP/IPプロトコルファミリを構成する主要なプロトコルに示した各プロトコルが提供されています。TCP/IPによって結び付けられた複数のネットワークから成る世界規模のネットワークは、インターネットとも呼ばれます。

RFCは、「Request for Comments」の略です。RFCは、さまざまなインターネットプロトコルとそれをオペレーティングシステムとそのアプリケーションに実装する手順を定めています。RFC文書ではインターネットプロトコルのセットアップについて説明しています。RFCの詳細については、http://www.ietf.org/rfc.htmlを参照してください。

TCP/IPプロトコルファミリを構成する主要なプロトコル
TCP

TCP(Transmission Control Protocol): 接続指向型の安全なプロトコルです。転送データは、まず、アプリケーションによってデータストリームとして送信され、オペレーティングシステム.によって適切なフォーマットに変換されます。データは、送信当初のデータストリーム形式で、宛先ホストのアプリケーションに着信します。TCPは転送中に損失したデータや順序が正しくないデータがないか、判定します。データの順序が意味を持つ場合は常にTCP/IPが実装されます。

UDP

UDP(User Datagram Protocol): コネクションレスで安全でないプロトコルです。転送されるデータは、アプリケーションで生成されたパケットの形で送信されます。データが受信側に到着する順序は保証されず、データの損失の可能性があります。UDPはレコード指向のアプリケーションに適しています。TCPよりも遅延時間が小さいことが特徴です。

ICMP

ICMP (Internet Control Message Protocol):これはエンドユーザ向けのプロトコルではありませんが、エラーレポートを発行し、TCP/IPデータ転送にかかわるマシンの動作を制御できる特別な制御プロトコルです。またICMPには特別なエコーモードがあります。エコーモードは、pingで使用されています。

IGMP

IGMP (Internet Group Management Protocol): このプロトコルは、IPマルチキャストを実装した場合のマシンの動作を制御します。

図16.1「TCP/IPの簡易階層モデル」に示したように、データのやり取りはさまざまなレイヤで実行されます。実際のネットワークレイヤは、IP (インターネットプロトコル)によって実現される確実性のないデータ転送です。IPの上で動作するTCP (転送制御プロトコル)によって、ある程度の確実性のあるデータ転送が保証されます。IP層の下層には、Ethernetなどのハードウェア依存プロトコルがあります。

TCP/IPの簡易階層モデル
図 16.1: TCP/IPの簡易階層モデル

図では、各レイヤに対応する例を1つまたは2つ示しています。レイヤは抽象化レベルに従って並べられています。最下位レイヤは最もハードウェアに近い部分です。一方、最上位レイヤは、ハードウェアがまったく見えないほぼ完全な抽象化になります。各レイヤにはそれぞれの固有の機能があります。各レイヤ固有の機能は、上記の主要プロトコルの説明を読めば大体わかります。データリンク層と物理層は、Ethernetなどの使用される物理ネットワークを表します。

ほとんどすべてのハードウェアプロトコルは、パケット単位で動作します。転送されるデータは、パケットにまとめられます(一度に全部を送信できません)。TCP/IPパケットの最大サイズは約64KBです。パケットサイズは通常、かなり小さな値になります。これは、ネットワークハードウェアでサポートされているパケットサイズに制限があるからです。Ethernetの最大パケットサイズは、約1500バイトです。Ethernet上に送出されるTCP/IPパケットは、このサイズに制限されます。転送するデータ量が大きくなると、それだけ多くのパケットがオペレーティングシステムによって送信されます。

すべてのレイヤがそれぞれの機能を果たすためには、各レイヤに対応する情報を各データパケットに追加する必要があります。この情報はパケットのヘッダとして追加されます。各レイヤでは、プロトコルヘッダと呼ばれる小さなデータブロックが、作成されたパケットに付加されます。図16.2「TCP/IPイーサネットパケット」に、Ethernetケーブル上に送出されるTCP/IPデータパケットの例を示します。誤り検出のためのチェックサムは、パケットの先頭ではなく最後に付加されます。これによりネットワークハードウェアの処理が簡素化されます。

TCP/IPイーサネットパケット
図 16.2: TCP/IPイーサネットパケット

アプリケーションがデータをネットワーク経由で送信すると、データは各レイヤを通過します。これらのレイヤは、物理レイヤを除き、すべてLinuxカーネルに実装されています。各レイヤは、隣接する下位レイヤに渡せるようにデータを処理します。最下位レイヤは、最終的にデータを送信する責任を負います。データを受信したときには、この手順全体が逆の順序で実行されます。重なり合ったたまねぎの皮のように、各レイヤで伝送データからプロトコルヘッダが除去されていきます。最後に、トランスポートレイヤが、着信側のアプリケーションがデータを利用できるように処理します。この方法では、1つのレイヤが直接やり取りを行うのは隣接する上下のレイヤのみです。データが伝送される物理的なネットワークは、100MBit/sのFDDIかもしれませんし、56Kbit/sのモデム回線かもしれませんが、アプリケーションがその違いを意識することはありません。同様に、物理ネットワークは、パケットの形式さえ正しければよく、伝送されるデータの種類を意識することはありません。

16.1 IPアドレスとルーティング

ここでは、IPv4ネットワークについてのみ説明しています。IPv4の後継バージョンであるIPv6については、16.2項 「IPv6—次世代インターネット」を参照してください。

16.1.1 IPアドレス

インターネット上のすべてのコンピュータは、固有の32ビットアドレスを持っています。この32ビット(4バイト)は、通常、例16.1「IPアドレスの表記」の2行目に示すような形式で表記されます。

例 16.1: IPアドレスの表記
IP Address (binary):  11000000 10101000 00000000 00010100
IP Address (decimal):      192.     168.       0.      20

10進表記では、4つの各バイトが10進数で表記され、ピリオドで区切られます。IPアドレスは、ホストまたはネットワークインタフェースに割り当てられます。使用できるのは1回のみです。このルールには例外もありますが、次の説明には直接関係していません。

IPアドレスにあるピリオドは、階層構造を表しています。1990年代まで、IPアドレスは、各クラスに固定的に分類されていました。しかし、このシステムがあまりに柔軟性に乏しいことがわかったので、今日、そのような分類は行われていません。現在採用されているのは、クラスレスルーティング(CIDR: classless inter domain routing)です。

16.1.2 ネットマスクとルーティング

ネットマスクは、サブネットのアドレス範囲を定義するために用いられます。2台のホストが同じサブネットに存在する場合、相互に直接アクセスできます。同じサブネットにない場合は、サブネットのすべてのトラフィックを処理するゲートウェイのアドレスが必要です。2つのIPアドレスが同じサブネットワークに属しているかどうかを確認するには、両方のアドレスとネットマスクのANDを求めます。結果が同一であれば、両方のIPアドレスは同じローカルネットワークに属しています。相違があれば、それらのIPアドレス、そしてそれらに対応するインタフェースが連絡するには、ゲートウェイを通過する必要があります。

ネットマスクの役割を理解するには、例16.2「IPアドレスとネットマスクの論理積(AND)」を参照してください。ネットマスクは、そのネットワークにいくつのIPアドレスが属しているかを示す、32ビットの値から成っています。1になっているビットは、IPアドレスのうち、特定のネットワークに属することを示すビットに対応します。0になっているビットは、サブネット内での識別に使われるビットに対応します。これは、1になっているビット数が多いほど、サブネットが小さいことを意味します。ネットマスクは常に連続する1のビットから構成されているので、その数だけでネットマスクを指定することができます。例16.2「IPアドレスとネットマスクの論理積(AND)」の、24ビットからなる第1のネットワークは、192.168.0.0/24と書くこともできます。

例 16.2: IPアドレスとネットマスクの論理積(AND)
IP address (192.168.0.20):  11000000 10101000 00000000 00010100
Netmask   (255.255.255.0):  11111111 11111111 11111111 00000000
---------------------------------------------------------------
Result of the link:         11000000 10101000 00000000 00000000
In the decimal system:           192.     168.       0.       0

IP address (213.95.15.200): 11010101 10111111 00001111 11001000
Netmask    (255.255.255.0): 11111111 11111111 11111111 00000000
---------------------------------------------------------------
Result of the link:         11010101 10111111 00001111 00000000
In the decimal system:           213.      95.      15.       0

また、たとえば同じEthernetケーブルに接続しているすべてのマシンは、普通同じサブネットに属し、直接アクセスできます。サブネットがスイッチまたはブリッジで物理的に分割されていても、これらのホストは直接アクセス可能です。

ローカルサブネットの外部のIPアドレスには、ターゲットネットワーク用のゲートウェイが設定されている場合にのみ、連絡できます。最も一般的には、外部からのすべてのトラフィックを扱うゲートウェイを1台だけ設置します。ただし、異なるサブネット用に、複数のゲートウェイを設定することも可能です。

ゲートウェイを設定すると、外部からのすべてのIPパケットは適切なゲートウェイに送信されます。このゲートウェイは、パケットを複数のホストを経由して転送し、それは最終的に宛先ホストに到着します。ただし、途中でTTL (存続期間)に達した場合は破棄されます。

特殊なアドレス
基本ネットワークアドレス

ネットマスクとネットワーク内の任意のアドレスの論理積をとったもの。例16.2「IPアドレスとネットマスクの論理積(AND)」のANDをとった結果を参照。このアドレスは、どのホストにも割り当てることができません。

ブロードキャストアドレス

これは、このサブネット上のすべてのホストにアクセスする」と言い換えることができます。このアドレスを生成するには、2進数形式のネットマスクを反転させ、基本ネットワークアドレスと論理和をとります。そのため上記の例では、192.168.0.255になります。このアドレスをホストに割り当てることはできません。

ローカルホスト

アドレス127.0.0.1は、各ホストのループバックデバイスに割り当てられます。このアドレスと、IPv4で定義された完全な127.0.0.0/8ループバックネットワークからのすべてのアドレスで、自分のマシンへの接続を設定できます。IPv6では、ループバックアドレスは1つだけです(::1)。

IPアドレスは、世界中で固有でなければならないので、自分勝手にアドレスを選択して使うことはできません。IPベースのプライベートネットワークをセットアップする場合のために、3つのアドレスドメインが用意されています。これらは、外部のインターネットに直接接続することはできません。インターネット上で転送されることがないからです。このようなアドレスドメインは、RFC  1597で、表16.1「プライベートIPアドレスドメイン」に示すとおりに定められています。

表 16.1: プライベートIPアドレスドメイン

ネットワーク/ネットマスク

ドメイン

10.0.0.0/255.0.0.0

10.x.x.x

172.16.0.0/255.240.0.0

172.16.x.x172.31.x.x

192.168.0.0/255.255.0.0

192.168.x.x

16.2 IPv6—次世代インターネット

重要
重要: IBM z Systems: IPv6のサポート

IPv6は、IBM z SystemsハードウェアのCTCネットワーク接続およびIUCVネットワーク接続ではサポートされていません。

ワールドワイドウェブ(WWW)の出現により、ここ15年間でTCP/IP経由で通信を行うコンピュータの数が増大し、インターネットは爆発的に拡大しました。CERN (http://public.web.cern.ch)のTim Berners-Leeが1990年にWWWを発明して以来、インターネットホストは、数千から約1億まで増加しました。

前述のように、IPv4のアドレスはわずか32ビットで構成されています。しかも、多くのIPアドレスが失われています。というのは、ネットワークの編成方法のせいで、使われないIPアドレスが無駄に割り当てられてしまうからです。サブネットで利用できるアドレスの数は、(2のビット数乗 - 2)で与えられます。たとえば、1つのサブネットでは、2、6、または14個のアドレスが使用可能です。たとえば128台のホストをインターネットに接続するには、256個のIPアドレスを持つサブネットが必要ですが、そのうち2つのIPアドレスは、サブネット自体を構成するのに必要なブロードキャストアドレスと基本ネットワークアドレスになるので、実際に使用できるのは254個だけです。

現在のIPv4プロトコルでは、アドレスの不足を避けるために、DHCPとNAT (ネットワークアドレス変換)の2つのメカニズムが使用されています。これらの方法をパブリックアドレスとプライベートアドレスを分離するという慣習と組み合わせて使用することで、確かにアドレス不足の問題を緩和することができます。問題は、セットアップが面倒で保守しにくいその環境設定方法にあります。IPv4ネットワークでホストを設定するには、ホスト自体のIPアドレス、サブネットマスク、ゲートウェイアドレス、そして場合によってはネームサーバアドレスなど、複数のアドレス項目が必要になります。管理者は、これらをすべて自分で設定しなければなりません。これらのアドレスをどこかから取得することはできません。

IPv6では、アドレス不足と複雑な環境設定方法はもはや過去のものです。ここでは、IPv6がもたらした進歩と恩恵について説明し、古いプロトコルから新しいプロトコルへの移行について述べます。

16.2.1 長所

この新しいプロトコルがもたらした最大かつ最もわかりやすい進歩は、利用可能なアドレス空間の飛躍的な増加です。IPv6アドレスは、従来の32ビットではなく、128ビットで構成されています。これにより、2の128乗、つまり、約3.4×1038個のIPアドレスが得られます。

しかしながら、IPv6アドレスがその先行プロトコルと異なるのはアドレス長だけではありません。IPv6アドレスは内部構造も異なっており、それが属するシステムやネットワークに関してより具体的な情報を有しています。詳細については、16.2.2項 「アドレスのタイプと構造」を参照してください。

次に、この新しいプロトコルの他の利点を紹介します。

自動環境設定機能

IPv6を使用すると、ネットワークがプラグアンドプレイ対応になります。つまり、新しくシステムをセットアップすると、手動で環境設定しなくても、(ローカル)ネットワークに統合されます。新しいホストは自動環境設定メカニズムを使用して、ネイバーディスカバリ (ND)と呼ばれるプロトコルにより、近隣のルータから得られる情報を元に自身のアドレスを生成します。この方法は、管理者の介入が不要なだけでなく、アドレス割り当てを1台のサーバで一元的に管理する必要もありません。これもIPv4より優れている点の1つです。IPv4では、自動アドレス割り当てを行うために、DHCPサーバを実行する必要があります。

それでもルータがスイッチに接続されていれば、ルータは、ネットワークのホストに相互に通信する方法を通知するフラグ付きの通知を定期的に送信します。詳細については、RFC 2462、radvd.conf(5)のマニュアルページ、およびRFC 3315を参照してください。

モバイル性

IPv6を使用すると、複数のアドレスを1つのネットワークインタフェースに同時に割り当てることができます。これにより、ユーザは複数のネットワークに簡単にアクセスできます。このことは、携帯電話会社が提供する国際ローミングサービスにたとえられます。携帯電話を海外に持って行った場合、現地会社のサービス提供エリアに入ると自動的に携帯電話はそのサービスにログインし、どこにいても普段と変わりなく同じ番号で電話を受けたりかけたりすることができます。

安全な通信

IPv4では、ネットワークセキュリティは追加機能です。IPv6にはIPSecが中核的機能の1つとして含まれているので、システムが安全なトンネル経由で通信でき、インターネット上での部外者による通信傍受を防止します。

後方互換性

現実的に考えて、インターネット全体を一気にIPv4からIPv6に切り替えるのは不可能です。したがって、両方のプロトコルが、インターネット上だけでなく1つのシステム上でも共存できることが不可欠です。このことは、互換アドレスであること(IPv4アドレスは簡単にIPv6アドレスに変換可能)により、および複数のトンネルを使用することにより、保証されます。参照先 16.2.3項 「IPv4とIPv6の共存」. また、システムはデュアルスタックIPテクニックによって、両方のプロトコルを同時にサポートできるので、2つのプロトコルバージョン間に相互干渉のない、完全に分離された2つのネットワークスタックが作成されます。

マルチキャストによるサービスの詳細なカスタマイズ

IPv4では、いくつかのサービス(SMBなど)が、ローカルネットワークのすべてのホストにパケットをブロードキャストする必要があります。IPv6では、サーバが、マルチキャストによってホストのアドレス指定を行う、つまり、複数のホストを1つのグループの部分としてアドレス指定することで、より細かいアプローチが可能になります。これは、「ブロードキャスト」によるすべてのホストのアドレス指定や、「ユニキャスト」による各ホストの個別のアドレス指定とは異なります。どのホストを対象グループに含めるかは、個々のアプリケーションによって異なります。事前定義のグループには、たとえば、すべてのネームサーバを対象とするグループ(全ネームサーバマルチキャストグループ)やすべてのルータを対象とするグループ(全ルータマルチキャストグループ)があります。

16.2.2 アドレスのタイプと構造

これまでに述べたように、現在のIPプロトコルには、IPアドレス数が急激に不足し始めているということと、ネットワーク設定とルーティングテーブルの管理がより複雑で煩雑な作業になっているという、2つの大きな制限があります。IPv6では、1つ目の問題を、アドレス空間を128ビットに拡張することによって解決しています。2番目の制限は、階層的なアドレス構造を導入し、ネットワークアドレスを割り当てる高度なテクニックとマルチホーミング(1つのデバイスに複数のアドレスを割り当てることによって、複数のネットワークへのアクセスを可能にします)を組み合わせて軽減されます。

IPv6を扱う場合は、次の3種類のアドレスについて知っておくと役に立ちます。

ユニキャスト

このタイプのアドレスは、1つのネットワークインタフェースだけに関連付けられます。このようなアドレスを持つパケットは、1つの宛先にのみ配信されます。したがって、ユニキャストアドレスは、パケットをローカルネットワークまたはインターネット上の個々のホストに転送する場合に使用します。

マルチキャスト

このタイプのアドレスは、ネットワークインタフェースのグループに関連します。このようなアドレスを持つパケットは、そのグループに属するすべての宛先に配信されます。マルチキャストアドレスは、主に、特定のネットワークサービスが、相手を特定のグループに属するホストに絞って通信を行う場合に使用されます。

エニーキャスト

このタイプのアドレスは、インタフェースのグループに関連します。このようなアドレスを持つパケットは、基盤となるルーティングプロトコルの原則に従い、送信側に最も近いグループのメンバに配信されます。エニーキャストアドレスは、特定のネットワーク領域で特定のサービスを提供するサーバについて、ホストが情報を得られるようにするために使用します。同じタイプのすべてのサーバは、エニキャストアドレスが同じになります。ホストがサービスを要求すると、ルーティングプロトコルによって最も近い場所にあるサーバが判断され、そのサーバが応答します。何らかの理由でこのサーバが応答できない場合、プロトコルが自動的に2番目のサーバを選択し、それが失敗した場合は3番目、4番目が選択されます。

IPv6アドレスは、4桁の英数字が入った8つのフィールドで構成され、それぞれのフィールドが16進数表記の16ビットを表します。各フィールドは、コロン(:)で区切られます。各フィールドで先頭の0は省略できますが、数字の間にある0や末尾の0は省略できません。もう1つの規則として、0のバイトが5つ以上連続する場合は、まとめて2つのコロン(::)で表すことができます。ただし、アドレスごとに::は1回しか使用できません。この省略表記の例については、例16.3「IPv6アドレスの例」を参照してください。この3行はすべて同じアドレスを表します。

例 16.3: IPv6アドレスの例
fe80 : 0000 : 0000 : 0000 : 0000 : 10 : 1000 : 1a4
fe80 :    0 :    0 :    0 :    0 : 10 : 1000 : 1a4
fe80 :                           : 10 : 1000 : 1a4

IPv6アドレスの各部の機能は個別に定められています。最初の4バイトはプレフィクスを形成し、アドレスのタイプを指定します。中間部分はアドレスのネットワーク部分ですが、使用しなくてもかまいません。アドレスの最後の4桁はホスト部分です。IPv6でのネットマスクは、アドレスの末尾のスラッシュの後にプレフィクスの長さを指定して定義します。例16.4「プレフィクスの長さを指定したIPv6アドレス」に示すアドレスには、最初の 64ビットがアドレスのネットワーク部分を構成する情報、最後の 64ビットにホスト部分を構成する情報が入っています。言い換えると、64は、ネットマスクに 64個の 1ビット値が左から埋められていることを意味します。IPv4と同様、IPアドレスとネットマスクのANDをとることにより、ホストが同じサブネットにあるかそうでないかを判定します。

例 16.4: プレフィクスの長さを指定したIPv6アドレス
fe80::10:1000:1a4/64

IPv6は、事前に定義された複数タイプのプレフィクスを認識します。一部をIPv6のプレフィクスに示します。

IPv6のプレフィクス
00

IPv4アドレスおよびIPv4 over IPv6互換性アドレス。これらは、IPv4との互換性を保つために使用します。これらを使用した場合でも、IPv6パケットをIPv4パケットに変換できるルータが必要です。いくつかの特殊なアドレス(たとえばループバックデバイスのアドレス)もこのプレフィクスを持ちます。

先頭桁が2または3

集約可能なグローバルユニキャストアドレス。IPv4と同様、インタフェースを割り当てて特定のサブネットの一部を構成することができます。現在、2001::/16 (実稼動品質のアドレス空間)と2002::/16 (6to4アドレス空間)の2つのアドレス空間があります。

fe80::/10

リンクローカルアドレス。このプレフィクスを持つアドレスは、ルーティングしてはなりません。したがって、同じサブネット内からのみ到達可能です。

fec0::/10

サイトローカルアドレス。ルーティングはできますが、それが属する組織のネットワーク内に限られます。要するに、IPv6版のプライベートネットワークアドレス空間です(たとえば、10.x.x.x)。

ff

マルチキャストアドレス。

ユニキャストアドレスは、以下の3つの基本構成要素からなります。

パブリックトポロジ

最初の部分(前述のいずれかのプレフィクスが含まれる部分)は、パブリックインターネット内でパケットをルーティングするために使用します。ここには、インターネットアクセスを提供する企業または団体に関する情報が入っています。

サイトトポロジ

2番目の部分には、パケットの配信先のサブネットに関するルーティング情報が入っています。

インタフェースID

3番目の部分は、パケットの配信先のインタフェースを示します。これを使用して、MACをアドレスの一部に含めることができます。MACは、世界中で重複がない固定の識別子であり、ハードウェアメーカによってデバイスにコーディングされるので、環境設定手順が大幅に簡素化されます。実際には、最初の 64アドレスビットが統合されてEUI-64トークンを構成します。このうち、最後の 48ビットにはMACアドレス、残りの 24ビットにはトークンタイプに関する特別な情報が入ります。これにより、PPPのインタフェースのようにMACを持たないインタフェースにEUI-64トークンを割り当てられるようになります。

IPv6は、この基本構造の上で、以下の5種類のユニキャストアドレスを区別します。

:: (未指定)

このアドレスは、インタフェースが初めて初期化されるとき(すなわち、アドレスが他の方法で判定できないとき)に、ホストがそのソースアドレスとして使用します。

::1 (ループバック)

ループバックデバイスのアドレス。

IPv4互換アドレス

IPv6アドレスが、IPv4アドレスおよび96個の0ビットからなるプレフィクスで作成されます。このタイプの互換アドレスは、IPv4とIPv6のホストが、純粋なIPv4環境で動作している他のホストと通信するためのトンネリング(16.2.3項 「IPv4とIPv6の共存」を参照)として使用されます。

IPv6にマッピングされたIPv4アドレス

このタイプのアドレスは、IPv6表記で純粋なIPv4アドレスを指定します。

ローカルアドレス

ローカルで使用するアドレスのタイプには、以下の2種類があります。

リンクローカル

このタイプのアドレスは、ローカルのサブネットでのみ使用できます。このタイプのソースまたは宛先アドレスを持つパケットをインターネットまたは他のサブネットにルーティングしてはなりません。これらのアドレスは、特別なプレフィクス(fe80::/10)とネットワークカードのインタフェースID、およびゼロバイトからなる中間部分からなります。このタイプのアドレスは、自動環境設定のとき、同じサブネットに属する他のホストと通信するために使用されます。

サイトローカル

このタイプのアドレスを持つパケットは、他のサブネットにはルーティングできますが、それより広いインターネットにはルーティングしてはなりません。つまり、組織自体のネットワークの内側だけで使用するように制限する必要があります。このようなアドレスはイントラネット用に使用され、IPv4によって定義されているプライベートアドレス空間に相当します。これらのアドレスは、特殊なプレフィクス(fec0::/10)とインタフェースID、およびサブネットIDを指定する16ビットのフィールドからなります。ここでも、残りはゼロバイトで埋められます。

IPv6では、各ネットワークインタフェースが複数のIPアドレスを持つことができるというたまったく新しい機能が導入されました。これにより、同じインタフェースで複数のネットワークにアクセスできます。これらのいずれかのネットワークを、MACと既知のプレフィクスを使用して完全に自動設定できるので、IPv6が有効になると、(リンクローカルアドレスを使用して)ローカルネットワーク上のすべてのホストに接続できるようになります。IPアドレスにMACが組み込まれているので、使用されるIPアドレスは世界中で唯一のアドレスになります。アドレスの唯一の可変部分は、ホストが現在動作している実際のネットワークによって、サイトトポロジパブリックトポロジを指定する部分になります。

複数のネットワークに接続するホストの場合、少なくとも2つのアドレスが必要です。1つはホームアドレスです。ホームアドレスには、インタフェースIDだけでなく、それが通常属するホームネットワークの識別子(および対応するプレフィクス)も含まれています。ホームアドレスは静的アドレスなので、通常は変更されません。しかし、モバイルホスト宛てのパケットは、それがホームネットワーク内にあるかどうかにかかわらず、すべてそのホストに配信できます。これは、IPv6で導入されたステートレス自動環境設定ネイバーディスカバリのようなまったく新しい機能によって実現されました。モバイルホストは、ホームアドレスに加え、ローミング先の外部ネットワークに属するアドレスも取得します。これらはケアオブアドレスと呼ばれます。ホームネットワークには、ホストが対象エリア外をローミングしている間、そのホスト宛てのすべてのパケットを転送する機能があります。IPv6環境において、このタスクは、ホームエージェントによって実行されます。ホームエージェントは、ホームアドレスに届くすべてのパケットを取得してトンネルに リレーします。一方、ケアオブアドレスに届いたパケットは、特別迂回することなく、直接モバイルホストに転送されます。

16.2.3 IPv4とIPv6の共存

インターネットに接続されている全ホストをIPv4からIPv6に移行する作業は、段階的に行われます。両方のプロトコルは今後しばらく共存することになります。両方のプロトコルをデュアルスタックで実装すれば、同じシステム上に共存することが保証されます。しかし、それでもなお、IPv6対応のホストがどのようにしてIPv4ホストと通信するか、また多くがIPv4ベースの現行ネットワークでIPv6パケットをどのように伝送するかなど、解決すべき問題が残ります。最善のソリューションは、トンネリングと互換アドレスです(16.2.2項 「アドレスのタイプと構造」を参照)。

ワールドワイドなIPv4ネットワークと隔離されているIPv6ホストは、トンネルを使って通信を行うことができます。IPv6パケットをIPv4パケットにカプセル化すれば、それをIPv4ネットワークに送ることができます。2つのIPv4ホスト間のこのような接続をトンネルと呼びます。そのためには、パケットにIPv6の宛先アドレス(または対応するプレフィクス)とともに、トンネルの受信側にあるリモートホストのIPv4アドレスも含める必要があります。基本的なトンネルは、ホストの管理者間が合意すれば、手動で設定が可能です。これは、静的トンネリングとも呼ばれます。

ただし、静的トンネルの環境設定とメンテナンスは、あまりに手間がかかるので、多くの場合、日常の通信には向きません。そこで、IPv6は、動的トンネリングを実現する3つの異なる方法を提供しています。

6over4

IPv6パケットが自動的にIPv4パケットとしてカプセル化され、マルチキャスト対応のIPv4ネットワークによって送信されます。IPv6は、ネットワーク全体(インターネット)を巨大なLAN (local area network)だと思い込んで動作することになります。これにより、IPv4トンネルの着信側の端を自動的に判定できます。ただし、この方法では、拡張性に欠けることになるだけでなく、IPマルチキャストがインターネット上で広く普及しているとはいえないことが障害にもなります。したがってこの解決方法を採用できるのは、マルチキャストが利用できる小規模な企業内ネットワークだけです。この方式の仕様は、RFC 2529に規定されています。

6to4

この方式では、IPv6アドレスからIPv4アドレスを自動的に生成することで、隔離されたIPv6ホストがIPv4ネットワーク経由で通信できるようにします。しかし、隔離されたIPv6ホストとインターネットの間の通信に関して、多くの問題が報告されています。この方式は、RFC 3056で規定されています。

IPv6トンネルブローカ

この方式は、IPv6ホスト専用のトンネルを提供する特殊なサーバに依存します。この方式は、RFC 3053で規定されています。

16.2.4 IPv6の設定

IPv6を設定するには、通常、個々のワークステーションの設定を変更する必要はありません。IPv6は、デフォルトで有効になっています。インストール済みシステムでIPv6を有効または無効にするには、YaSTのネットワーク設定モジュールを使用します。グローバルオプションタブで、必要に応じてIPv6を有効にするオプションをオン/オフします。次回の再起動時まで一時的に有効にするには、rootとして、「modprobe -i ipv6」と入力します。IPv6モジュールはロード後にアンロードすることはできません。

IPv6の自動環境設定の概念があるため、ネットワークカードには、リンクローカルネットワーク内のアドレスが割り当てられます。通常、ワークステーション上ではルーティングテーブルの管理を実行しません。ワークステーションは、ルータアドバタイズプロトコルを使用して、実装する必要のあるプレフィクスとゲートウェイをネットワークルータに問い合わせます。IPv6ルータは、radvdプログラムを使用して設定できます。このプログラムは、IPv6アドレスに使用するプレフィクスとルータをワークステーションに通知します。または、zebra/quaggaを使用してアドレスとルーティングの両方を自動設定することもできます。

/etc/sysconfig/networkファイルを使用してさまざまなタイプのトンネルをセットアップする方法の詳細については、ifcfg-tunnelのマニュアルページ(man ifcfg-tunnel)を参照してください。

16.2.5 詳細情報

ここでの概要は、IPv6に関する情報を網羅しているわけではありません。IPv6の詳細については、次のオンラインドキュメントや書籍を参照してください。

http://www.ipv6.org/

IPv6のあらゆる情報にここからリンクできます。

http://www.ipv6day.org

独自のIPv6ネットワークを開始するには、すべての情報が必要です。

http://www.ipv6-to-standard.org/

IPv6対応製品のリスト。

http://www.bieringer.de/linux/IPv6/

Linux IPv6-HOWTOと多くの関連トピックへのリンクが用意されています。

RFC2460

IPv6に関する基本的なRFCです。

IPv6 Essentials

Silvia HagenによるIPv6 Essentials (ISBN 0-596-00125-8)は、このトピックに関するあらゆる重要な面を扱っている本です。

16.3 ネームレゾリューション

DNSはIPアドレスに1つまたは複数のホスト名を割り当てるとともに、ホスト名をIPアドレスに割り当てます。Linuxでは、この変換は通常、bindという特別な種類のソフトウェアによって行われます。また、この変換を行うマシンをネームサーバと呼びます。ホスト名は、その名前構成要素がピリオド(.)で区切られた階層システムを構成しています。しかしながら名前の階層構造は、先に述べたIPアドレスの階層構造とは無関係です。

hostname.domainという形式で書かれた完全な名前、たとえば、jupiter.example.comを考えてみましょう。「完全修飾ドメイン名」(FQDN)と呼ばれるフルネームは、ホスト名とドメイン名(example.com)で構成されます。ドメイン名には最上位ドメイン(TLD) (com)が含まれます。

TLDの割り当ては、これまでの経緯もあって、非常に複雑になっています。従来から、米国では、3文字のドメイン名が使用されています。他の国では、ISOで制定された2文字の国コードが標準です。これに加えて、2000年には、特定の活動領域を表す、より長いTLDが導入されました(たとえば、.info.name.museum)。

インターネットの初期( 1990年より前)には、ファイル/etc/hostsに、インターネットで利用されるすべてのマシン名を記述していました。しかし、インターネットに接続されるコンピュータ数の急激な増加により、この方法はすぐに現実的でなくなりました。このため、ホスト名を広く分散して保存するための分散データベースが開発されました。このデータベースは、ネームサーバと同様、インターネット上のすべてのホストに関するデータがいつでも用意されているわけではなく、他のネームサーバに問い合わせを行います。

この階層の最上位には、複数のルートネームサーバがあります。ルートネームサーバは、Network Information Center (NIC)によって運用されており、最上位レベルドメインを管理します。各ルートネームサーバは、特定の最上位ドメインを管理するネームサーバについての情報を持っています。最上位ドメインNICの詳細については、http://www.internic.netを参照してください。

DNSには、ホスト名の解決以外の機能もあります。ネームサーバは、特定のドメイン宛の電子メールをどのホストに転送するかも管理しています(「メールエクスチェンジャ(MX)」)。

マシンがIPアドレスを解決するには、少なくとも1台のネームサーバとそのIPアドレスを知っている必要があります。そのようなネームサーバの指定は、YaSTを使用すれば簡単です。SUSE Linux Enterprise Serverでのネームサーバアクセスの設定については、16.4.1.4項 「ホスト名とDNSの設定」に記載されています。独自のネームサーバの設定については、第25章 「ドメインネームシステムに説明があります。

whoisプロトコルは、DNSと密接な関係があります。このプログラムを使用すると、特定のドメインの登録者情報をすぐに検索できます。

注記
注記: MDNSおよび.localドメイン名

.localトップレベルドメインは、リゾルバではリンクローカルドメインとして処理されます。DNS要求は通常のDNS要求ではなく、マルチキャスト要求として送信されます。ネームサーバ設定で.localドメインをすでに使用している場合は、このオプションを/etc/host.confでオフに変更する必要があります。詳細については、host.confのマニュアルページを参照してください。

インストール中にMDNSをオフにするには、nomdns=1をブートパラメータとして使用してください。

マルチキャストDNSの詳細は、http://www.multicastdns.orgを参照してください。

16.4 YaSTによるネットワーク接続の設定

Linuxでは多くのタイプのネットワーク接続がサポートされています。その多くは、異なるデバイス名と、ファイルシステム内の複数の場所に分散した設定ファイルを使用しています。手動によるネットワーク設定のさまざまな面についての詳細は、16.5項 「ネットワークの手動環境設定」を参照してください。

ネットワークケーブルと接続され、リンクアップしているネットワークインタフェースはすべて自動的に設定されます。インストール済みのシステムには、いつでも付加的なハードウェアを設定することができます。以降のセクションでは、SUSE Linux Enterprise Serverがサポートするすべてのタイプのネットワーク接続について、その設定方法を説明します。

ヒント
ヒント: IBM z Systems: ホットプラグ対応ネットワークカード

IBM z Systemsプラットフォームでは、ホットプラグ可能なネットワークカードがサポートされていますが、DHCPを介したネットワークの自動統合は(PCの場合とは異なり)サポートされていません。検出後はインタフェースを手動で設定してください。

16.4.1 YaSTでのネットワークカードの設定

YaSTでEthernetカードまたはWi-Fi/Bluetoothカードを設定するには、システム ›  ネットワーク設定の順に選択します。モジュールの開始後に、YaSTはネットワーク設定ダイアログを表示します。ダイアログにはグローバルオプション概要ホスト名/DNS、およびルーティングの4つのタブがあります。

グローバルオプションタブでは、ネットワークのセットアップ方法、IPv6、一般的なDHCPオプションの使用など、一般的なネットワークオプションを設定できます。詳細については、16.4.1.1項 「グローバルネットワークオプションの設定」を参照してください。

概要タブには、インストールされたネットワークインタフェースと環境設定に関する情報が含まれています。正しく検出されたネットワークカードの名前が表示されます。このダイアログでは、手動で新しいカードを設定し、それらの設定内容を削除または変更できます。自動検出されなかったカードを手動で設定する場合は、16.4.1.3項 「検出されないネットワークカードの設定」を参照してください。すでに設定済みのカードの設定を変更する場合については、16.4.1.2項 「ネットワークカードの設定の変更」を参照してください。

ホスト名/DNSタブでは、マシンのホスト名を設定し、使用サーバに名前を付けることができます。詳細については、16.4.1.4項 「ホスト名とDNSの設定」を参照してください。

ルーティングタブは、ルーティングの設定で使用します。詳細については、16.4.1.5項 「ルーティングの設定」を参照してください。

ネットワーク設定の実行
図 16.3: ネットワーク設定の実行

16.4.1.1 グローバルネットワークオプションの設定

YaSTのネットワーク設定モジュールのグローバルオプションタブを使用して、NetworkManager、IPv6およびDHCPのクライアントオプションの使用など、重要なグローバルネットワークオプションを設定できます。この設定は、すべてのネットワークインタフェースに適用されます。

注記
注記: Workstation ExtensionでのNetworkManagerの提供

NetworkManagerはWorkstation Extensionで提供されるようになりました。NetworkManagerをインストールするには、Workstation Extensionリポジトリを有効にして、NetworkManagerパッケージを選択します。

ネットワークのセットアップ方法では、ネットワーク接続を管理する方法を選択します。NetworkManagerデスクトップアプレットですべてのインタフェースの接続を管理する場合は、NetworkManagerサービスを選択します。NetworkManagerは、複数の有線ネットワークおよび無線ネットワーク間の切り替えに適しています。デスクトップ環境を実行しない場合、またはコンピュータがXenサーバ(仮想システム)であるか、ネットワーク内でDHCPやDNSなどのネットワークサービスを提供する場合は、Wickedサービスの方法を使用します。NetworkManagerを使用する場合は、nm-appletを使用して、ネットワークオプションを設定する必要があります。ネットワーク設定モジュールのタブである概要ホスト名/DNS、およびルーティングは無効になります。NetworkManagerの詳細については、SUSE Linux Enterprise Desktopのマニュアルを参照してください。

IPv6プロトコル設定で、IPv6プロトコルを使用するかどうかを選択します。IPv4とともにIPv6を使用できます。デフォルトでは、IPv6は有効です。ただし、IPv6プロトコルを使用しないネットワークでは、IPv6プロトコルを無効にした方が応答時間がより短くなる場合があります。IPv6を無効にするには、IPv6を有効にするを無効にします。IPv6が無効な場合、カーネルはIPv6モジュールを自動的にロードしません。この設定は、再起動後に適用されます。

DHCPクライアントオプションでは、DHCPクライアントのオプションを設定します。DHCPクライアントIDは、単一ネットワーク上の各DHCPクライアントで異なる必要があります。空白のままにした場合は、デフォルトでネットワークインタフェースのハードウェアアドレスになります。ただし、同じネットワークインタフェース、したがって同じハードウェアアドレスを使用して複数の仮想マシンを実行している場合は、ここで自由形式の固有識別子を指定します。

送信するホスト名では、DHCPクライアントがDHCPサーバにメッセージを送信するときに、ホスト名オプションフィールドで使用される文字列を指定します。一部のDHCPサーバでは、このホスト名(ダイナミックDNS)に応じて、ネームサーバゾーン(順レコードおよび逆レコード)を更新します。また一部のDHCPサーバでは、クライアントからのDHCPメッセージで、送信するホスト名オプションフィールドに特定の文字列が含まれていることが必要です。現在のホスト名(/etc/HOSTNAMEで定義されたホスト名)を送信する場合は、自動のままにします。ホスト名を送信しない場合は、このオプションフィールドを空のままにします。

DHCPからの情報に従ったデフォルトのルートを変更しない場合は、DHCPで既定のルートを変更するをオフにします。

16.4.1.2 ネットワークカードの設定の変更

ネットワークカードの設定を変更するには、YaSTのネットワーク設定 › 概要で検出されたカードのリストから目的のカードを選択し、編集をクリックします。ネットワークカードの設定ダイアログが表示されます。このダイアログの一般アドレス、およびハードウェアタブを使用してカードの設定を変更します。

16.4.1.2.1 IPアドレスの設定

Network Card Setupダイアログのアドレスタブで、ネットワークカードのIPアドレス、またはそのIPアドレスの決定方法を設定できます。IPv4およびIPv6の両アドレスがサポートされます。ネットワークカードは、IPアドレスなし(ボンドデバイスで有用)の場合や、静的に割り当てられたIPアドレス(IPv4またはIPv6)、あるいはDHCPまたはZeroconfのいずれかまたは両方を経由して割り当てられる動的アドレスを持つ場合もあります。

Dynamic Addressを使用する場合は、DHCP Version 4 Only(IPv4の場合)、DHCP Version 6 Only(IPv6の場合)、またはDHCP Both Version 4 and 6のいずれを使用するかを選択します。

可能であれば、インストール時に利用可能なリンクを持つ最初のネットワークカードがDHCPによる自動アドレス設定を使用するように自動的に設定されます。

注記
注記: IBM z SystemsとDHCP

IBM z Systemsプラットフォームでは、DHCPベースのアドレス設定はMACアドレスを持つネットワークカードの場合にのみサポートされます。これに該当するのは、OSAカードおよびOSA Expressカードだけです。

DSL回線を使用していてISP(Internet Service Provider)からスタティックIPが割り当てられていない場合も、DHCPを使用する必要があります。DHCPを使用することを選択する場合は、YaSTネットワークカード設定モジュールのネットワーク設定ダイアログにあるグローバルオプションタブのDHCPクライアントオプションで詳細を設定します。さまざまなホストが同じインタフェースを介して通信するようにバーチャルホストがセットアップされている場合は、各ホストの識別にDHCPクライアントIDが必要になります。

DHCPは、クライアント設定には適していますが、サーバ設定には適していません。静的なIPアドレスを設定するには、以下の手順に従ってください。

  1. YaSTネットワークカード設定モジュールの概要タブの検出されたカードのリストから目的のカードを選択し、編集をクリックします。

  2. アドレスタブで、Statically Assigned IP Addressを選択します。

  3. IPアドレスを入力します。IPv4およびIPv6の両アドレスを使用できます。サブネットマスクにネットワークマスクを入力します。IPv6アドレスが使用されている場合は、フォーマット/64のプレフィクス長に対するサブネットマスクを使用します。

    オプションで、このアドレスの完全修飾ホスト名を入力できます。このホスト名は、/etc/hosts設定ファイルに書き込まれます。

  4. 次へをクリックします。

  5. 環境設定を有効にするには、OKをクリックします。

注記
注記: インタフェースのアクティブ化とリンク検出

ネットワークインタフェースのアクティブ化中に、wickedはキャリアを確認して、リンクが検出された場合にのみIP設定を適用します。リンク状態に関係なく設定を適用する必要がある場合(たとえば、特定のアドレスをリスンしているサービスをテストする場合など)、変数LINK_REQUIRED=no/etc/sysconfig/network/ifcfgにあるインタフェースの設定ファイルに追加することで、リンク検出をスキップできます。

また、変数LINK_READY_WAIT=5を使用して、リンクを待機するタイムアウトを秒単位で指定できます。

設定ファイルifcfg-*の詳細については、16.5.2.5項 「/etc/sysconfig/network/ifcfg-*およびman 5 ifcfgを参照してください。

静的アドレスを使用する場合、ネームサーバとデフォルトゲートウェイは、自動的には設定されません。ネームサーバを設定するには、16.4.1.4項 「ホスト名とDNSの設定」に従って手順を進めます。ゲートウェイを設定するには、16.4.1.5項 「ルーティングの設定」に従って手順を進めます。

16.4.1.2.2 複数のアドレスの設定

1台のネットワークデバイスに、複数のIPアドレスを割り当てることができます。

注記
注記: エイリアスは互換機能

これらのエイリアスまたはラベルはそれぞれIPv4でのみ動作し、IPv6では、無視されます。iproute2ネットワークインタフェースを使用する場合、1つ以上のアドレスを持つことができます。

YaSTを使用してネットワークカードに追加のアドレスを設定するには、次の手順に従います。

  1. YaSTのネットワーク設定モジュールの概要タブの検出されたカードのリストから目的のカードを選択し、編集をクリックします。

  2. アドレス › 追加アドレスタブで、追加をクリックします。

  3. IPアドレスラベルIPアドレス、およびネットマスクに適切な値を入力します。エイリアス名にはインタフェース名を含めないでください。

  4. 設定内容を有効にするために、設定を確認します。

16.4.1.2.3 デバイス名およびUdevルールの変更

ネットワークカードのデバイス名が使用されている場合、ネットワークカードのデバイス名を変更できます。また、ハードウェア(MAC)アドレスまたはバスIDを介してudevによりネットワークカードを識別するかどうかを選択できます。大型のサーバでは、カードのホットスワッピングを容易にするために後者のオプションが適しています。YaSTを使ってこうしたオプションを設定するには、次の手順に従います。

  1. YaSTのネットワーク設定モジュールの概要タブの検出されたカードのリストから目的のカードを選択し、編集をクリックします。

  2. ハードウェアタブを開きます。現在のデバイス名がUdevルールに表示されます。変更をクリックします。

  3. udevでMACアドレスまたはバスIDによりカードを識別するかどうかを選択します。カードの現在のMACアドレスおよびバスIDがダイアログに表示されます。

  4. デバイス名を変更するには、Change Device Nameオプションをオンにし、名前を編集します。

  5. 設定内容を有効にするために、設定を確認します。

16.4.1.2.4 ネットワークカードカーネルドライバの変更

一部のネットワークカードには、複数のカーネルドライバを使用できます。カードがすでに設定されている場合は、YaSTで利用可能で適切なドライバのリストから、使用するカーネルドライバを選択できます。また、カーネルドライバのオプションを指定することもできます。YaSTを使ってこうしたオプションを設定するには、次の手順に従います。

  1. YaSTのネットワーク設定モジュールの概要タブの検出されたカードのリストから目的のカードを選択し、編集をクリックします。

  2. ハードウェアタブを開きます。

  3. モジュール名で、使用するカーネルドライバを選択します。選択したドライバのオプションを、オプションに「= =VALUE」の形式で入力します。他にもオプションを使用する場合は、スペースで区切る必要があります。

  4. 設定内容を有効にするために、設定を確認します。

16.4.1.2.5 ネットワークデバイスの有効化

wickedを使った方法を使用している場合、デバイスをブート時、ケーブル接続時、カード検出時、または手動で起動するように設定したり、起動しないように設定したりすることができます。デバイスの起動方法を変更するには、次の手順に従います。

  1. YaSTで、システム › ネットワーク設定で検出されたカードの一覧からカードを選択し、編集をクリックします。

  2. 一般タブのデバイスの起動から、適切な項目を選択します。

    システムブート中にデバイスを起動するには、ブート時を選択します。ケーブル接続時では、インタフェースで物理接続が存在するかどうかが監視されます。ホットプラグ時を選択した場合、インタフェースは利用可能になったときに設定されます。これは、ブート時オプションに似ていますが、インタフェースがブート時に存在しない場合にエラーが発生しない点のみが異なります。ifupでインタフェースを手動で制御する場合は、手動を選択します。デバイスを起動しない場合は、起動しないを選択します。NFSrootオンは、ブート時に似ていますが、インタフェースはsystemctl stop networkコマンドを使用してシャットダウンしません。また、ネットワークサービスは、wickedがアクティブになっている場合は、wickedサービスも処理します。このオプションは、NFSまたはiSCSIのルートファイルシステムを使用する場合に選択します。

  3. 設定内容を有効にするために、設定を確認します。

ヒント
ヒント: ルートファイルシステムとしてのNFS

ルートパーティションがネットワーク経由でNFS共有としてマウントされている(ディスクレス)システムでは、NFS共有にアクセス可能なネットワークデバイスの設定を慎重に行う必要があります。

システムの停止、システムの再起動時のデフォルトの処理順序は、ネットワーク接続を切断してから、ルートパーティションをアンマウントするという順序になります。NFSルートの場合、この順序では問題が発生します。NFS共有とのネットワーク接続が先に無効にされているため、ルートパーティションを正常にアンマウントできないためです。システムが該当するネットワークデバイスを無効にしないようにするには、[network device configuration(ネットワークデバイスの設定)]タブ(16.4.1.2.5項 「ネットワークデバイスの有効化」を参照)を開いて、デバイスの起動ペインのNFSrootオンを選択します。

16.4.1.2.6 最大転送単位サイズの設定

インタフェースの最大転送単位(MTU)を設定できます。MTUでは、最大許容パケットサイズ(バイト)を参照します。MTUが大きいと、帯域幅の効率が高くなります。ただし、パケットが大きくなると、低速なインタフェースの処理がしばらく阻止され、以降のパケットの遅延が増加する場合があります。

  1. YaSTで、システム › ネットワーク設定で検出されたカードの一覧からカードを選択し、編集をクリックします。

  2. 一般タブのMTUを設定リストから、適切な項目を選択します。

  3. 設定内容を有効にするために、設定を確認します。

16.4.1.2.7 PCIe多機能デバイス

LAN、iSCSI、およびFCoEをサポートする多機能デバイスがサポートされています。YaST FCoEクライアント(yast2 fcoe-client)は、追加の列にプライベートフラグを表示して、ユーザがFCoE用のデバイスを選択できるようにします。YaSTネットワークモジュール(yast2 lan)は、ネットワーク設定のストレージ専用デバイスを除外します。

FCoEの詳細については、Book “ストレージ管理ガイド”, Chapter 15 “Fibre Channel Storage over Ethernet Networks: FCoE”, Section 15.3 “YaSTを使用したFCoEサービスの管理”を参照してください。

16.4.1.2.8 IPoIB (IP-over-InfiniBand)用のインフィニバンドの設定
  1. YaSTで、システム ›  ネットワーク設定でインフィニバンドデバイスを選択し、編集をクリックします。

  2. 一般タブのIP-over-InfiniBand(IPoIB)モードで接続済み(デフォルト)またはデータグラムを選択します。

  3. 設定内容を有効にするために、設定を確認します。

インフィニバンドの詳細については、/usr/src/linux/Documentation/infiniband/ipoib.txtを参照してください。

16.4.1.2.9 ファイアウォールの設定

Book “Security Guide”, Chapter 15 “Masquerading and Firewalls”, Section 15.4.1 “Configuring the Firewall with YaST”で説明しているような詳細なファイアウォール設定を行わずに、デバイスに基本的なファイアウォールを設定することができます。次の手順に従います。

  1. YaSTで、システム ›  ネットワーク設定 モジュールを開きます。概要タブで、検出されたカードの一覧からカードを選択し、編集をクリックします。

  2. ネットワーク設定ダイアログの一般タブを表示します。

  3. インタフェースを割り当てるファイアウォールゾーンを指定します。次のオプションを指定できます。

    Firewall Disabled

    このオプションは、ファイアウォールが無効であり、ファイアウォールが動作しない場合にのみ利用可能です。コンピュータが、外部ファイアウォールにより保護されている、より規模の大きいネットワークに接続している場合にのみ、このオプションを使用してください。

    自動割り当てゾーン

    このオプションは、ファイアウォールが有効になっている場合のみ、利用できます。ファイアウォールが実行中であり、インタフェースがファイアウォールゾーンに自動的に割り当てられます。こうしたインタフェースには、anyキーワードを含むゾーンまたは外部ゾーンが使用されます。

    内部ゾーン(未保護)

    ファイアウォールを実行しますが、このインタフェースを保護するルールは使いません。コンピュータが、外部ファイアウォールにより保護されている、より規模の大きいネットワークに接続している場合に、このオプションを使用してください。また、マシンに追加ネットワークインタフェースが存在する場合、内部ネットワークに接続するインタフェースで使用できます。

    非武装地帯(DMZ)

    非武装地帯ゾーンは、内部ネットワークと(悪意のある)インターネットとの中間にあたるゾーンです。このゾーンに割り当てられたホストは、内部ネットワークおよびインターネットからアクセスされますが、ホストから内部ネットワークにアクセスすることはできません。

    外部ゾーン

    このインタフェースでファイアウォールを実行し、(危険な可能性のある)他のネットワークトラフィックからインタフェースを保護します。これがデフォルトのオプションです。

  4. 設定内容を有効にするために、設定を確認します。

16.4.1.3 検出されないネットワークカードの設定

ネットワークカードが正しく検出されなかった場合、そのカードは検出されたカードのリストに含まれません。システムにそのカード用のドライバが間違いなく含まれている場合は、そのようなカードを手動で設定することができます。特殊なネットワークデバイスタイプ(ブリッジ、ボンド、TUN、TAPなど)も設定できます。未検出のネットワークカードまたは特殊なデバイスを設定するには、次の手順に従います。

  1. YaSTのシステム › ネットワーク設定 ›  概要ダイアログで追加をクリックします。

  2. ハードウェアダイアログで、使用可能なオプションからインタフェースのデバイスの型環境設定名を設定します。ネットワークカードが、PCMCIAデバイスかUSBデバイスの場合、それぞれのチェックボックスを選択して、次へをクリックしダイアログを終了します。それ以外の方法では、必要に応じて、カードとそのオプションで使用されるカーネルのモジュール名を定義できます。

    Ethtoolオプションでは、インタフェースのifupにより使用されるethtoolオプションを設定できます。使用可能なオプションの詳細については、ethtoolのマニュアルページを参照してください。

    オプション文字列が-で始まる場合(たとえば-K INTERFACE_NAME rx on)、文字列内の2番目の単語が現在のインタフェースの名前に置換されます。それ以外の場合(たとえばautoneg off speed 10)、ifup-s INTERFACE_NAMEを先頭に追加します。

  3. 次へをクリックします。

  4. 一般アドレス、およびハードウェアタブで、インタフェースのIPアドレス、デバイス起動方法、ファイアウォールゾーンなどの必要なオプションを設定します。環境設定オプションの詳細については、16.4.1.2項 「ネットワークカードの設定の変更」を参照してください。

  5. インタフェースのデバイスタイプとして、ワイヤレスを選択した場合は、次のダイアログでワイヤレス接続の設定を行います。

  6. 新しいネットワーク設定を有効にするために、設定を確認します。

16.4.1.4 ホスト名とDNSの設定

Ethernetカードがすでに利用できる状態で、インストール時にネットワーク設定を変更しなかった場合、コンピュータのホスト名が自動的に生成され、DHCPが有効になります。また、ホストがネットワークに参加するために必要なネームサービス情報も自動的に生成されます。ネットワークアドレス設定にDHCPを使用している場合は、ドメインネームサーバのリストは自動的に記入されます。静的設定を利用する場合は、これらの項目を手動で設定してください。

コンピュータ名を変更し、ネームサーバの検索リストを修正するには、以下の手順に従ってください。

  1. YaSTのシステム › モジュールのネットワーク設定 ホスト名/DNSタブに移動します。

  2. ホスト名にホスト名を入力し、必要に応じてドメイン名にドメイン名を入力します。マシンがメールサーバである場合、ドメインは特に重要です。ホスト名はグローバルであり、すべての設定ネットワークインタフェースに適用されることに注意してください。

    IPアドレスを取得するためにDHCPを使用している場合、DHCPによりコンピュータのホスト名が自動的に設定されます。異なるネットワークに接続する場合は、異なるホスト名が割り当てられることがあり、ランタイムにホスト名が変更されるとグラフィックデスクトップが混同される可能性があるので、この機能を無効にする必要があります。DHCPを使用したIPアドレスの取得を無効にするには、DHCPでホスト名を変更するをオフにします。

    ホスト名をループバックIPに割り当てるでは、ホスト名を/etc/hosts内の127.0.0.2 (ループバック) IPアドレスに関連付けます。アクティブネットワークが存在しないときでも常に解決可能なホスト名を必要とする場合に有用なオプションです。

  3. DNS環境設定の変更では、DNS設定(ネームサーバ、検索リスト、/etc/resolv.confファイルのコンテンツ)を変更する方法を選択します。

    既定のポリシーを使用するオプションを選択した場合、(DHCPクライアントまたはNetworkManagerから)動的に取得されたデータと、(YaSTまたは設定ファイルで)静的に定義されたデータをマージするnetconfigスクリプトにより設定が処理されます。通常は、このデフォルトポリシーで十分です。

    手動でのみオプションを選択した場合、netconfigでは/etc/resolv.confファイルを変更できません。ただし、このファイルは手動で編集できます。

    Custom Policyオプションを選択した場合、マージポリシーを定義するCustom Policy Rule文字列を指定する必要があります。この文字列は、設定の有効なソースとみなされるインタフェース名のカンマで区切られたリストから構成されます。完全なインタフェース名以外に、複数のインタフェースに一致する基本的なワイルドカードを使用することもできます。たとえばeth* ppp?は、先頭がethであり、以降にppp0-ppp9を含むすべてのインタフェースが対象になります。/etc/sysconfig/network/configファイルで定義された静的な設定を適用する方法を示す次の2つの特別なポリシー値が存在します。

    STATIC

    静的な設定は、動的な設定とマージされる必要があります。

    STATIC_FALLBACK

    静的な設定は、動的設定が利用できない場合のみ使用されます。

    詳細については、netconfig(8)のマニュアルページ(man 8 netconfig)を参照してください。

  4. ネームサーバおよびドメイン検索リストに入力します。ネームサーバは、ホスト名ではなく、192.168.1.116などのIPアドレスにより指定する必要があります。ドメイン検索タブで指定した名前は、ドメインが指定されていないホスト名の解決のために使用されるドメイン名です。複数のドメイン検索を使用する場合は、カンマまたは空白でドメインを区切ります。

  5. 設定内容を有効にするために、設定を確認します。

コマンドラインからYaSTを使用してホスト名を編集することもできます。YaSTによる変更はすぐに有効になります(/etc/HOSTNAMEファイルを手動で編集する場合はすぐに有効にはなりません)。ホスト名を変更するには、次のコマンドを実行します。

yast dns edit hostname=HOSTNAME

ネームサーバを変更するには、次のコマンドを実行します。

yast dns edit nameserver1=192.168.1.116
yast dns edit nameserver2=192.168.1.117
yast dns edit nameserver3=192.168.1.118

16.4.1.5 ルーティングの設定

コンピュータを他のコンピュータやネットワークと通信させるには、ネットワークトラフィックが正しい経路を通過するように、ルーティング情報を設定する必要があります。DHCPを使用している場合、この情報は自動的に設定されます。静的アドレスを使用する場合は、このデータを手作業で追加する必要があります。

  1. YaSTで、ネットワーク設定 › ルーティングの順に移動します。

  2. デフォルトゲートウェイのIPアドレス(IPv4および必要に応じてIPv6)を入力します。デフォルトゲートウェイは、可能性のあるすべての宛先に一致しますが、必要なアドレスに一致するルーティングテーブルエントリが存在する場合は、デフォルトゲートウェイ経由のデフォルトルートの代わりにそのエントリが使用されます。

  3. ルーティングテーブルには、さらに追加エントリを入力できます。宛先のネットワークIPアドレス、ゲートウェイのIPアドレス、およびネットマスクを入力します。定義されたネットワークにトラフィックがルーティングされるデバイスを選択します(マイナス記号はデバイスを表わします)。このいずれかの値を省略する場合は、マイナス記号(-)を使用します。デフォルトゲートウェイをテーブルに入力するには、宛先フィールドをdefaultのままにします。

    注記
    注記: ルートの優先度付け

    追加のデフォルトルートが使用されている場合、より高い優先度を持つルートを決定するためのメトリックオプションを指定できます。メトリックオプションを指定するには、オプション- metric NUMBERを入力します。最も高いメトリックを持つルートがデフォルトとして使用されます。ネットワークデバイスが切断している場合は、そのルートが削除され、次のルートが使用されます。ただし、現在のカーネルは静的なルーティングでメトリックを使用せず、multipathdなどのルーティングデーモンのみがメトリックを使用します。

  4. システムがルータの場合、必要に応じて、ネットワーク設定IPv4転送およびIPv6転送を有効にします。

  5. 設定内容を有効にするために、設定を確認します。

16.4.2 IBM z Systems: ネットワークデバイスの設定

SUSE Linux Enterprise Server for IBM z Systemsは、さまざまな種類のネットワークインタフェースをサポートしています。これらのインタフェースは、YaSTを使って設定することができます。

16.4.2.1 qeth-hsiデバイス

qeth-hsi(Hipersocket)インタフェースをインストール済みのシステムに追加するには、YaSTでシステム › ネットワークの設定モジュールを起動します。READデバイスアドレスとして使用するため、Hipersocketとマークされたデバイスの1つを選択して、編集をクリックします。読み込みチャネル、書き込みチャネル、および制御チャネルのデバイス番号を入力します(デバイス番号形式の例: 0.0.0800)。[次へ]をクリックします。ネットワークアドレスの設定ダイアログで、新しいインタフェースのIPアドレスとネットマスクを指定し、次へOKをクリックしてネットワークの設定を終了します。

16.4.2.2 qeth-ethernetデバイス

qeth-ethernet(IBM OSA Expressイーサネットカード)インタフェースをインストール済みのシステムに追加するには、YaSTでシステム › ネットワークの設定モジュールを起動します。READデバイスアドレスとして使用するため、IBM OSA Expressイーサネットカードとマークされたデバイスの1つを選択して編集をクリックします。読み込みチャネル、書き込みチャネル、および制御チャネルのデバイス番号を入力します(デバイス番号形式の例: 0.0.0700)。必要なポート名、ポート番号(該当する場合)、および追加オプション(『Linux for IBM z Systems: Device Drivers, Features, and Commands』リファレンスマニュアル、http://www.ibm.com/developerworks/linux/linux390/documentation_suse.htmlを参照)、IPアドレス、および適切なネットマスクを入力します。次へOKをクリックして、ネットワークの設定を終了します。

16.4.2.3 ctcデバイス

ctc(IBMパラレルCTCアダプタ)インタフェースをインストール済みのシステムに追加するには、YaSTでシステム › ネットワークの設定モジュールを起動します。READデバイスアドレスとして使用するIBMパラレルCTCアダプタというマークの付いたデバイスの1つを選択して、設定をクリックします。お使いのデバイスに合わせてデバイス設定を選択します(通常は、互換モード)。自分のIPアドレスとリモートのIPアドレスを指定します。必要に応じて、詳細 › 詳細設定の順に選択してMTUサイズを調整します。次へOKをクリックして、ネットワークの設定を終了します。

警告
警告: CTCは、サポートされなくなりました

このインタフェースを使用することはお勧めしません。SUSE Linux Enterprise Serverの今後のバージョンでは、このインタフェースはサポートされません。

16.4.2.4 lcsデバイス

lcs(IBM OSA-2アダプタ)インタフェースをインストール済みのシステムに追加するには、YaSTでシステム › ネットワークの設定モジュールを起動します。IBM OSA-2アダプタというマークの付いたデバイスの1つの選択して、設定をクリックします。必要なポート番号や他のオプション(『Linux for IBM z Systems: Device Drivers, Features, and Commands』リファレンスマニュアル、http://www.ibm.com/developerworks/linux/linux390/documentation_suse.htmlを参照)、IPアドレス、および適切なネットマスクを入力します。次へOKをクリックして、ネットワークの設定を終了します。

16.4.2.5 IUCVデバイス

iucv(IUCV)インタフェースをインストール済みのシステムに追加するには、YaSTでシステム › ネットワークの設定モジュールを起動します。IUCVとマークされたデバイスを選択し、編集をクリックします。IUCVパートナーの名前を入力するように要求されます(ピア)。パートナー名(大文字と小文字が区別されます)を入力して、次へをクリックします。自分のIPアドレスと、パートナーのリモートIPアドレスの両方を指定します。必要な場合は、Set MTUサイズを一般タブで設定します。次へOKをクリックして、ネットワークの設定を終了します。

警告
警告: IUCVはサポートされなくなりました

このインタフェースを使用することはお勧めしません。SUSE Linux Enterprise Serverの今後のバージョンでは、このインタフェースはサポートされません。

16.5 ネットワークの手動環境設定

ネットワークソフトウェアの手動環境設定は、最後の手段です。設定には可能な限りYaSTを使用してください。しかし、ここで説明するネットワーク環境設定の背景知識がYaSTでの設定作業に役立つことがあります。

16.5.1 wickedネットワーク環境設定

wickedと呼ばれるツールとライブラリは、ネットワーク環境設定用の新しいフレームワークを提供します。

従来のネットワークインタフェース管理の課題の1つは、ネットワーク管理のさまざまな層が1つのスクリプト、または最大2つの異なるスクリプトにごちゃ混ぜになってしまうことです。これらのスクリプトは、あまりはっきりしない形で互いに作用し合います。このため、予期しない問題や、不明瞭な制約、慣習などが発生します。異なるシナリオに対応するために特別なハックを使った層がいくつもあると、保守負担が増加します。現状では、dhcpcdなどのデーモンによって実装されるアドレス設定プロトコルが使用されていますが、他のインフラストラクチャとの相互作用は十分ではありません。そこで、インタフェースを永続的に識別できるようにするため、多くのudevサポートを必要とするインタフェース命名スキームが導入されたものの、これは洗練されているとはいいがたい手段です。

wickedというアイデアが生まれたのは、この問題をさまざまな方法で分解するためです。どの方法もまったく新しいものではありませんが、異なるプロジェクトから得たアイデアをまとめようとする試みから、総合的により優れた解決策が生まれることが期待できます。

アプローチの1つは、クライアント/サーバモデルを使用することです。これにより、wickedは、アドレス設定のような作業について、フレームワーク全体と効果的に統合された標準化機能を定義できます。たとえば、特定のアドレス設定を使用して、管理者は、DHCPまたはIPv4 zeroconfを介してインタフェースを設定するように要求することができます。この場合、アドレス設定サービスは、単にそのサーバからリースを取得し、要求されたアドレスとルートをインストールするwickedサーバプロセスに渡すだけです。

問題を分解するもう1つのアプローチは、階層化を強制的に導入することです。すべてのタイプのネットワークインタフェースに対して、ネットワークインタフェースのデバイス層(VLAN、ブリッジ、ボンド、または準仮想化されたデバイス)を設定するdbusサービスを定義できます。アドレス設定といった共通の機能は、こうしたデバイス固有のサービスの上に階層化した結合サービスによって実装します。これにより、サービスを個別に実装する必要がなくなります。

wickedフレームワークは、そのタイプに応じてネットワークインタフェースにアタッチされるさまざまなdbusサービスを使用して、これら2つの側面を実装します。ここでは、wickedにおける現在のオブジェクト階層をおおまかに説明します。

各ネットワークインタフェースは、/org/opensuse/Network/Interfacesの子オブジェクトを介して表されます。子オブジェクトの名前は、そのifindexで指定されます。たとえば、ループバックインタフェースは通常、ifindex 1を取り、/org/opensuse/Network/Interfaces/1です。登録されている最初のEthernetインタフェースは、/org/opensuse/Network/Interfaces/2です。

各ネットワークインタフェースにはクラスが関連付けられており、そのクラスを使用して、サポートするdbusインタフェースが選択されます。デフォルトでは、各ネットワークインタフェースは、クラスnetifに属し、wickeddはこのクラスと互換性のあるすべてのインタフェースを自動的にアタッチします。現在の実装では、これには次のインタフェースが含まれます。

org.opensuse.Network.Interface

リンクアップとリンクダウンの取得、MTUの割り当てなどの、一般的なネットワークインタフェース機能。

org.opensuse.Network.Addrconf.ipv4.dhcp , org.opensuse.Network.Addrconf.ipv6.dhcp, org.opensuse.Network.Addrconf.ipv4.auto

DHCP、IPv4 zeroconfなどのアドレス設定サービス。

これ以外に、ネットワークインタフェースで特別な設定メカニズムが必要な場合や、ネットワークインタフェースがこのようなメカニズムを備えている場合もあります。たとえば、Ethernetデバイスの場合、リンク速度、チェックサム計算のオフロードなどを制御できる必要があります。これを実現するために、Ethernetデバイスには、netifのサブクラスである、netif-ethernetという独自のクラスがあります。このため、Ethernetインタフェースに割り当てられたdbusインタフェースには、上記に一覧にされているすべてのサービス、およびnetif-ethernetクラスに属するオブジェクトでのみ使用可能なサービスであるorg.opensuse.Network.Ethernetが含まれています。

同様に、ブリッジ、VLAN、ボンド、インフィニバンドなどのインタフェースタイプのクラスも存在します。

Ethernetデバイスの上に位置し、実際には仮想ネットワークインタフェースであるVLANなど、最初に作成する必要があるインタフェースとはどのように相互作用すればよいのでしょうか。このような場合、wickedは、org.opensuse.Network.VLAN.Factoryなどのファクトリインタフェースを定義します。このようなファクトリインタフェースは、要求されたタイプのインタフェースを作成できる単一の機能を提供します。これらのファクトリインタフェースは、/org/opensuse/Network/Interfacesリストノードにアタッチされます。

16.5.1.1 wickedアーキテクチャと機能

wickedサービスは、図16.4「wickedアーキテクチャ」に示されている複数の要素で構成されます。

wickedアーキテクチャ
図 16.4: wickedアーキテクチャ

wickedは、現在次の要素をサポートしています。

  • SUSEスタイルの/etc/sysconfig/networkファイルを解析する環境設定ファイルバックエンド。

  • ネットワークインタフェース設定をXMLで表す内部環境設定バックエンド。

  • 通常のネットワークインタフェース(EthernetまたはInfiniBandなど)、VLAN、ブリッジ、ボンド、tun、tap、dummy、macvlan、macvtap、hsi、qeth、iucv、およびワイヤレス(現在はwpa-psk/eapネットワークに限定)デバイスの起動と停止。

  • 内蔵DHCPv4クライアントおよび内蔵DHCPv6クライアント。

  • nannyデーモン(デフォルトで有効)によって、デバイスが使用可能になると設定済みインタフェースが自動的に起動され(インタフェースのホットプラグ)、リンク(キャリア)が検出されるとIP設定が設定されます。詳細については、16.5.1.3項 「nanny」を参照してください。

  • wickedは、systemdに統合されているDBusサービスのグループとして実装されました。したがって、通常のsystemctlコマンドがwickedに適用されます。

16.5.1.2 wickedの使用

SUSE Linux Enterpriseでは、デフォルトでwickedが稼働しています。現在何が有効になっているか、稼働しているかどうかを確認するには、以下を呼び出します。

openSUSE Leapでは、wickedがデスクトップまたはサーバハードウェアでデフォルトで稼働しています。モバイルハードウェアでは、NetworkManagerがデフォルトで稼働しています。現在何が有効になっているか、稼働しているかどうかを確認するには、以下を呼び出します。

systemctl status network

wickedが有効になっている場合、以下の行に表示されます。

wicked.service - wicked managed network interfaces
    Loaded: loaded (/usr/lib/systemd/system/wicked.service; enabled)
    ...

wicked以外が稼働している場合(NetworkManagerなど)で、wickedに切り替えたい場合、稼働中のサービスを停止してからwickedを有効にします。

systemctl is-active network && \
systemctl stop      network
systemctl enable --force wicked

これにより、wickedサービスが有効になり、wicked.serviceエイリアスリンクに対してnetwork.serviceが作成され、次回ブート時にネットワークを起動します。

サーバプロセスを起動します。

systemctl start wickedd

wickedd(メインサーバ)と関連サプリカントが起動されます。

/usr/lib/wicked/bin/wickedd-auto4 --systemd --foreground
/usr/lib/wicked/bin/wickedd-dhcp4 --systemd --foreground
/usr/lib/wicked/bin/wickedd-dhcp6 --systemd --foreground
/usr/sbin/wickedd --systemd --foreground
/usr/sbin/wickedd-nanny --systemd --foreground

次にネットワークを起動します

systemctl start wicked

または、network.serviceエイリアスを使用します。

systemctl start network

これらのコマンドは、デフォルト、または/etc/wicked/client.xmlで定義されるシステム設定ソースを使用しています。

デバッグを有効にするには、次の例のように、/etc/sysconfig/network/configWICKED_DEBUGを設定します。

WICKED_DEBUG="all"

または、いくつかを省略して、以下のようにします。

WICKED_DEBUG="all,-dbus,-objectmodel,-xpath,-xml"

クライアントユーティリティを使用して、すべてのインタフェース、またはIFNAMEで指定したインタフェースに関するインタフェース情報を表示します。

wicked show all
wicked show IFNAME

XML出力の場合は、以下を実行します。

wicked show-xml all
wicked show-xml IFNAME

1つのインタフェースを起動します。

wicked ifup eth0
wicked ifup wlan0
...

設定ソースが指定されていないため、wickedクライアントは、/etc/wicked/client.xmlで定義されている設定のデフォルトソースを確認します。

  1. firmware: iBFT (iSCSI Boot Firmware Table)

  2. compat: ifcfgファイル—互換性のため実装

特定のインタフェースに対してwickedがこれらのソースから取得した設定がすべて適用されます。ファームウェア、次にcompatの順に重要です。これは将来変わる場合があります。

詳細については、wickedのマニュアルページを参照してください。

16.5.1.3 nanny

nannyは、イベントドリブンおよびポリシードリブンのデーモンで、デバイスのホットプラグなど、非同期や非要求のシナリオを担当します。nannyデーモンは、遅延したデバイスや、一時的に停止したデバイスの始動、再始動に役立ちます。nannyは、デバイスやリンクの変更を監視し、現行ポリシーセットで定義されている新規デバイスを統合します。Nannyは、指定されているタイムアウト制約によりifupがすでに終了していたとしても、引き続き設定されます。

nannyデーモンは、デフォルトで、システム上有効になっています。/etc/wicked/common.xml環境設定ファイルで有効に設定されています。

<config>
  ...
  <use-nanny>true</use-nanny>
</config>

この設定によって、ifupおよびifreloadは、有効な設定を持つポリシーをnannyデーモンに適用します。nannyはwickeddを設定して、ホットプラグがサポートされます。nannyデーモンは、バックグラウンドでイベントや変更の発生まで待機します(新規デバイスやキャリアの追加など)。

16.5.1.4 複数のインタフェースの起動

ボンドおよびブリッジの場合、1つのファイル(ifcfg-bondX)にデバイストポロジ全体を定義し、それをまとめて起動します。これにより、wickedは、最上位のインタフェース名(ブリッジまたはボンドの)が指定されれば、設定全体を起動できます。

wicked ifup br0

このコマンドは、ブリッジとその依存関係を適切な順序で自動的に設定するため、依存関係(ポートなど)を別途リストする必要がありません。

1つのコマンドで複数のインタフェースを起動するには、以下のようにします。

wicked ifup bond0 br0 br1 br2

また、すべてのインタフェースを起動するには、以下のようにします。

wicked ifup all

16.5.1.5 Wickedによるトンネルの使用

Wickedでトンネルを使用する必要がある場合は、TUNNEL_DEVICEを使用します。これにより、オプションデバイス名を指定して、トンネルをデバイスにバインドできます。トンネル化パケットは、このデバイス経由でのみルーティングされます。

詳細については、man 5 ifcfg-tunnelを参照してください。

16.5.1.6 増分変更の処理

wickedでは、再設定のためにインタフェースを実際に停止する必要はありません(カーネルによって要求される場合を除く)。たとえば、静的に設定されたネットワークインタフェースに別のIPアドレスまたはルートを追加するには、インタフェース定義にIPアドレスを追加して、もう一度ifup操作を実行します。サーバは変更された設定のみを更新しようとします。これは、デバイスMTUやMACアドレスなどのリンクレベルのオプションに適用されるほか、(静的設定からDHCPに切り替える場合などは)アドレス、ルート、さらにはアドレス設定モードなどのネットワークレベルの設定にも適用されます。

もちろん、ブリッジやボンドなど複数の実デバイスを組み合わせる仮想インタフェースでは、処理は複雑になります。ボンドデバイスの場合、デバイスの稼働中に特定のパラメータを変更することはできません。これを行うと、エラーが発生します。

ただし、この状態でも、ボンドまたはブリッジの子デバイスを追加または削除したり、ボンドのプライマリインタフェースを選択したりする操作は有効です。

16.5.1.7 Wicked拡張機能: アドレス設定

wickedは、シェルスクリプトによって拡張可能な設計になっています。これらの拡張機能は、config.xmlファイルで定義できます。

現状では、複数のクラスの拡張機能がサポートされています。

  • リンク設定: クライアントによって提供される環境設定に従ってデバイスのリンク層を設定し、それを再び終了するスクリプトです。

  • アドレス設定: デバイスのアドレス設定を管理するスクリプトです。通常、アドレス設定およびDHCPは、wicked自体で管理されますが、拡張機能によって実装できます。

  • ファイアウォール拡張機能: これらのスクリプトでファイアウォールルールを適用できます。

通常、拡張機能には、開始および終了コマンド、オプションのpid file、およびスクリプトに渡される一連の環境変数があります。

これがどのように機能するかを説明するために、etc/server.xmlで定義されているファイアウォール拡張機能を取り上げます。

<dbus-service interface="org.opensuse.Network.Firewall">
 <action name="firewallUp"   command="/etc/wicked/extensions/firewall up"/>
 <action name="firewallDown" command="/etc/wicked/extensions/firewall down"/>

 <!-- default environment for all calls to this extension script -->
 <putenv name="WICKED_OBJECT_PATH" value="$object-path"/>
 <putenv name="WICKED_INTERFACE_NAME" value="$property:name"/>
 <putenv name="WICKED_INTERFACE_INDEX" value="$property:index"/>
</dbus-service>

拡張機能は、 <dbus-service> タグに付加され、このインタフェースのアクションを実行するコマンドを定義します。さらに、宣言によって、アクションに渡される環境変数を定義および初期化できます。

16.5.1.8 Wicked拡張機能: 環境設定ファイル

スクリプトを使用して環境設定ファイルの処理を拡張することもできます。たとえば、DNSのリースの更新は、最終的には、server.xmlで動作が設定されたextensions/resolverスクリプトで処理されます。

<system-updater name="resolver">
 <action name="backup" command="/etc/wicked/extensions/resolver backup"/>
 <action name="restore" command="/etc/wicked/extensions/resolver restore"/>
 <action name="install" command="/etc/wicked/extensions/resolver install"/>
 <action name="remove" command="/etc/wicked/extensions/resolver remove"/>
</system-updater>

更新内容がwickeddに届くと、システムアップデータルーチンがリースを解析して、適切なコマンド(backupinstallなど)をリゾルバスクリプトで呼び出します。これにより、/sbin/netconfigを使用してDNSを設定するか、フォールバックとして手動で/etc/resolv.confを作成してDNSを設定します。

16.5.2 環境設定ファイル

ここでは、ネットワークの環境設定ファイルの概要を紹介し、その目的と使用される形式について説明します。

16.5.2.1 /etc/wicked/common.xml

/etc/wicked/common.xmlファイルには、すべてのアプリケーションが使用する共通定義が含まれます。このディレクトリにある他の設定ファイルにより読み込まれ、インクルードされます。このファイルを使用して、すべてのwickedコンポーネントのデバッグを有効にすることはできますが、その場合はファイル/etc/wicked/local.xmlを使用することをお勧めします。保守アップデートを適用すると、/etc/wicked/common.xmlが上書きされて、変更内容が失われる可能性があります。デフォルトインストールでは、/etc/wicked/common.xml/etc/wicked/local.xmlがインクルードされるので、通常は/etc/wicked/common.xmlを変更する必要はありません。

<use-nanny>falseに設定してnannyを無効にする場合は、wickedd.serviceを再起動してから、次のコマンドを実行してすべての構成とポリシーを適用します。

wicked ifup all
注記
注記: 環境設定ファイル

wickeddwicked、またはnannyの各プログラムは、それぞれの固有の設定ファイルが存在しない場合に、/etc/wicked/common.xmlの読み込みを試みます。

16.5.2.2 /etc/wicked/server.xml

ファイル/etc/wicked/server.xmlは、起動時にwickeddサーバプロセスによって読み込まれます。このファイルには、/etc/wicked/common.xmlの拡張機能が保存されます。さらに、リゾルバの処理およびaddrconfサプリカント(DHCPなど)からの情報の受信を設定します。

このファイルに必要な変更は、/etc/wicked/server.xmlにインクルードされる、別ファイルの/etc/wicked/server-local.xmlに追加することをお勧めします。別ファイルを使用することによって、保守更新中に変更内容が上書きされることはなくなります。

16.5.2.3 /etc/wicked/client.xml

/etc/wicked/client.xmlは、wickedコマンドによって使用されます。このファイルでは、ibftにより管理されるデバイスを検出するときに使用されるスクリプトの場所を指定し、ネットワークインタフェース設定の場所を設定します。

このファイルに必要な変更は、/etc/wicked/server.xmlにインクルードされる、別ファイルの/etc/wicked/client-local.xmlに追加することをお勧めします。別ファイルを使用することによって、保守更新中に変更内容が上書きされることはなくなります。

16.5.2.4 /etc/wicked/nanny.xml

/etc/wicked/nanny.xmlは、リンク層の種類を設定します。設定に独自の変更を加えた場合は、保守更新時に変更内容が失われることがないよう、別ファイルの/etc/wicked/nanny-local.xmlにそれらの設定を追加しておくことをお勧めします。

16.5.2.5 /etc/sysconfig/network/ifcfg-*

これらのファイルには、ネットワークインタフェースの従来の環境設定が含まれています。SUSE Linux Enterprise 11では、iBFTファームウェア以外でサポートされるフォーマットはこれだけでした。

注記
注記: wickedおよびifcfg-*ファイル

wickedは、compat:プレフィクスを指定した場合にのみ、これらのファイルを読み取ります。/etc/wicked/client.xmlにあるSUSE Linux Enterprise Serverのデフォルト設定に応じて、wickedは、/etc/wicked/ifconfig内のXML設定ファイルの前にこれらのファイルを読み込もうとします。

--ifconfigスイッチは、多くの場合テストでのみ指定します。指定した場合、/etc/wicked/ifconfigに定義されたデフォルトの環境設定ソースは適用されません。

ifcfg-*ファイルには、起動モードやIPアドレスなどの情報が含まれています。指定可能なパラメータについては、ifupのマニュアルページを参照してください。また、一般的設定を1つのインタフェースだけに使用する場合は、dhcpおよびwirelessファイルのほとんどの変数をifcfg-*ファイルで使用できます。ただし、/etc/sysconfig/network/configの変数の大半はグローバル変数であり、ifcfgファイル内で上書きすることはできません。たとえば、NETCONFIG_*は、グローバル変数です。

macvlanおよびmacvtabインタフェースの設定方法については、ifcfg-macvlanおよびifcfg-macvtapのマニュアルページを参照してください。たとえば、macvlanインタフェースでは、ifcfg-macvlan0を次のように設定します。

STARTMODE='auto'
MACVLAN_DEVICE='eth0'
#MACVLAN_MODE='vepa'
#LLADDR=02:03:04:05:06:aa

ifcfg.templateについては、16.5.2.6項 「/etc/sysconfig/network/config/etc/sysconfig/network/dhcp、および/etc/sysconfig/network/wirelessを参照してください。

System z IBM z Systemsは、USBをサポートしていません。インタフェースファイル名とネットワークエイリアスには、qethのような、z Systems固有の要素が含まれます。

16.5.2.6 /etc/sysconfig/network/config/etc/sysconfig/network/dhcp、および/etc/sysconfig/network/wireless

configファイルには、ifupifdown、およびifstatusの動作に関する汎用的な設定が記述されています。また、dhcpにはDHCPの設定が、wirelessには無線LANカードの設定が記述されています。3つの環境設定ファイル内の変数にはコメントが付きます。/etc/sysconfig/network/configの一部の変数は、ifcfg-*ファイルでも使用できます。このファイルでは、それらの変数がより高い優先順位で処理されます。/etc/sysconfig/network/ifcfg.templateファイルは、インタフェースごとに指定できる変数を一覧表示します。ただし、/etc/sysconfig/network/configの変数の大半はグローバル変数であり、ifcfgファイル内で上書きすることはできません。たとえば、NETWORKMANAGERNETCONFIG_*は、グローバル変数です。

注記
注記: DHCPv6の使用

SUSE Linux Enterprise 11では、IPv6 Router Advertisements (RA)が適切に設定されていないネットワークでもDHCPv6は動作しました。SUSE Linux Enterprise 12から、DHCPv6が正常に動作するには、ネットワーク上の少なくとも1つのルータが、ネットワークがDHCPv6で管理されていることを示すRAを送出することが求められるようになりました。

ルータを正しく設定できないネットワーク用に、ユーザはifcfgオプションを使用して、DHCLIENT6_MODE='managed'ifcfgファイルに指定することによって、この動作を無効にできます。インストールシステムでbootパラメータを使用することによっても、この回避策を有効にできます。

ifcfg=eth0=dhcp6,DHCLIENT6_MODE=managed

16.5.2.7 /etc/sysconfig/network/routes/etc/sysconfig/network/ifroute-*

TCP/IPパケットのスタティックルーティングは、/etc/sysconfig/network/routesおよび/etc/sysconfig/network/ifroute-*ファイルによって決定されます。ホストへのルート、ゲートウェイ経由のホストへのルート、およびネットワークへのルートなど、さまざまなシステムタスクが必要とするすべてのスタティックルートは、/etc/sysconfig/network/routesファイルに指定できます。個別のルーティングが必要な各インタフェースに対して、付加環境設定ファイル/etc/sysconfig/network/ifroute-*を定義します。ワイルドカード(*)はインタフェース名で読み替えてください。経路の環境設定ファイルのエントリは次のようになります。

# Destination     Gateway           Netmask            Interface  Options

第1列は、経路の宛先です。この列には、ネットワークまたはホストのIPアドレスが入ります。到達可能なネームサーバの場合は、完全に修飾されたネットワークまたはホスト名が入ります。ネットワークは、IPv4ルートでは10.10.0.0/16、IPv6ルートではfc00::/7のように、CIDR表記(関連付けられたルーティングプレフィクス長付きのアドレス)で記述する必要があります。キーワードのdefaultは、そのルートがゲートウェイと同じアドレスファミリ内のデフォルトゲートウェイであることを示しています。ゲートウェイのないデバイスの場合は、明示的な宛先0.0.0.0/0または::/0を使用します。

第2列は、デフォルトゲートウェイ、すなわちホストまたはネットワークにアクセスする際に経由するゲートウェイです。

第3列は非推奨になりました。これは、宛先のIPv4ネットマスクを示すために使用されていました。デフォルトルートであるIPv6ルートの場合、または第1列でプレフィクス長を使用する場合(CIDR表記)は、ここにダッシュ記号(-)を入力します。

第4列は、インタフェースの名前です。ダッシュ記号(-)を使用して空のままにすると、/etc/sysconfig/network/routesで意図しない動作を引き起こす場合があります。詳細については、routesのマニュアルページを参照してください。

第5列(オプション)では、特殊なオプションを指定することができます。詳細については、routesのマニュアルページを参照してください。

例 16.5: 一般的なネットワークインタフェースとスタティックルートの例
# --- IPv4 routes in CIDR prefix notation:
# Destination     [Gateway]         -                  Interface
127.0.0.0/8       -                 -                  lo
204.127.235.0/24  -                 -                  eth0
default           204.127.235.41    -                  eth0
207.68.156.51/32  207.68.145.45     -                  eth1
192.168.0.0/16    207.68.156.51     -                  eth1

# --- IPv4 routes in deprecated netmask notation"
# Destination     [Dummy/Gateway]   Netmask            Interface
#
127.0.0.0         0.0.0.0           255.255.255.0      lo
204.127.235.0     0.0.0.0           255.255.255.0      eth0
default           204.127.235.41    0.0.0.0            eth0
207.68.156.51     207.68.145.45     255.255.255.255    eth1
192.168.0.0       207.68.156.51     255.255.0.0        eth1

# --- IPv6 routes are always using CIDR notation:
# Destination     [Gateway]                -           Interface
2001:DB8:100::/64 -                        -           eth0
2001:DB8:100::/32 fe80::216:3eff:fe6d:c042 -           eth0

16.5.2.8 /etc/resolv.conf

/etc/resolv.confには、ホストが属するドメインが指定されています(キーワードsearch)。searchオプションでは、最大256文字で最大6つのドメインを指定できます。完全修飾でない名前を解決する場合は、searchの各エントリを付加して完全修飾名の生成が試みられます。nameserverオプションでは、1行に1つずつ、最大3つのネームサーバを指定できます。コメントの先頭には、ハッシュマークまたはセミコロン記号(#または;)を付加します。例については、例16.6「/etc/resolv.confを参照してください。

ただし、/etc/resolv.confは、手動では編集しないでください。このファイルは、netconfigスクリプトで生成されます。YaSTを使用せずに静的DNS設定を定義するには、/etc/sysconfig/network/configファイルの該当する変数を手動で編集します。

NETCONFIG_DNS_STATIC_SEARCHLIST

ホスト名の検索に使用されるDNSドメイン名のリスト

NETCONFIG_DNS_STATIC_SERVERS

ホスト名の検索に使用されるネームサーバのIPアドレスのリスト

NETCONFIG_DNS_FORWARDER

設定する必要のあるDNSフォワーダの名前。たとえば、bindまたはresolver

NETCONFIG_DNS_RESOLVER_OPTIONS

/etc/resolv.confに記述される任意のオプション。例:

debug attempts:1 timeout:10

詳細については、resolv.confのマニュアルページを参照してください。

NETCONFIG_DNS_RESOLVER_SORTLIST

最大10項目のリスト。例:

130.155.160.0/255.255.240.0 130.155.0.0

詳細については、resolv.confのマニュアルページを参照してください。

netconfigでDNS環境設定を無効にするには、NETCONFIG_DNS_POLICY=''を設定します。netconfigの詳細については、netconfig(8)のマニュアルページ(man 8 netconfig)を参照してください。

例 16.6: /etc/resolv.conf
# Our domain
search example.com
#
# We use dns.example.com (192.168.1.116) as nameserver
nameserver 192.168.1.116

16.5.2.9 /sbin/netconfig

netconfigは、追加のネットワーク環境設定を管理するモジュール式ツールです。このツールは、事前定義されたポリシーに従って、DHCPまたはPPPなどの自動設定メカニズムにより提供される設定と、静的に定義された設定をマージします。要求された変更は、netconfigモジュールの呼び出しによって適用されます。このモジュールは、環境設定ファイルの変更と、サービスまたは同様のアクションの再起動を行います。

netconfigは、3つの主要なアクションを認識します。netconfig modifyコマンドとnetconfig removeコマンドは、 DHCPやPPPなどのデーモンによって使用され、netconfigの設定値を提供したり、削除します。ユーザが使用できるのは、netconfig updateコマンドだけです。

modify

netconfig modifyコマンドは、現在のインタフェースとサービス固有の動的設定を変更し、ネットワーク設定を更新します。netconfigは、標準入力からか、または--lease-file FILENAMEオプションで指定されたファイルから設定を読み込み、システムのリブートまたは次の変更/削除アクションまで、それらの設定を内部的に保存します。同じインタフェースとサービスの組み合わせに関する既存設定は、上書きされます。インタフェースは、-i INTERFACE_NAMEパラメータで指定されます。サービスは、-s SERVICE_NAMEパラメータで指定されます。

remove

netconfig removeコマンドは、特定のインタフェースとコマンドの組み合わせに対する変更アクションによる動的設定を削除し、ネットワーク設定を更新します。インタフェースは、-i INTERFACE_NAMEパラメータで指定されます。サービスは、-s SERVICE_NAMEパラメータで指定されます。

update

netconfig updateコマンドは、現在の設定で、ネットワーク設定を更新します。これは、ポリシーや静的環境設定が変更された場合に便利です。指定したサービスのみ(dnsnis、またはntp