このガイドでは、当初のインストールシステムの保守、監視、およびカスタマイズなど、システム管理タスクについて説明します。
- 序文
- I 共通のタスク
- II Linuxシステムのブート
- III システム
- IV ハードウェア設定
- V サービス
- VI トラブルシューティング
- A サンプルネットワーク
- B GNU licenses
- 4.1 テキストモードのYaSTのメインウィンドウ
- 4.2 ソフトウェアインストールモジュール
- 6.1 YaSTのユーザとグループの管理
- 7.1 YaSTオンラインアップデート
- 7.2 撤回されたパッチと履歴の表示
- 7.3 YaSTオンライン更新設定
- 8.1 ソフトウェアマネージャの競合管理
- 8.2 ソフトウェアリポジトリの追加
- 8.3 GNOMEのデスクトップに表示されたアップデート通知
- 8.4 — ビュー
- 10.1 ブートローダ: スナップショット
- 14.1 vncviewer
- 14.2 Remminaのメインウィンドウ
- 14.3 リモートデスクトップ初期設定
- 14.4 クイックスタート
- 14.5 Remminaのリモートセッションの表示
- 14.6 プロファイルファイルへのパスの読み込み
- 14.7 リモート管理
- 14.8 VNCセッション設定
- 14.9 永続的VNCセッションへの参加
- 17.1 セキュアブートサポート
- 17.2 UEFIのセキュアブートプロセス
- 18.1 GRUB 2ブートエディタ
- 18.2 ブートコードオプション
- 18.3 ブートローダオプション
- 18.4 カーネルパラメータ
- 19.1 サービスマネージャ
- 21.1 YaST systemdジャーナル
- 23.1 TCP/IPの簡易階層モデル
- 23.2 TCP/IPイーサネットパケット
- 23.3 ネットワーク設定の実行
- 23.4
wicked
アーキテクチャ - 27.1 YaSTソフトウェアマネージャ: マルチバージョン表示
- 31.1 GNOMEネットワーク接続のダイアログ
- 31.2 NetworkManagerの
firewalld
ゾーン - 37.1 YaSTサービスマネージャ
- 38.1 [NTP設定]ウィンドウ
- 38.2 タイムサーバの追加
- 39.1 DNSサーバのインストール: フォワーダの設定
- 39.2 DNSサーバのインストール: DNSゾーン
- 39.3 DNSサーバのインストール: 完了ウィザード
- 39.4 DNSサーバ: ログの記録
- 39.5 DNSサーバ: ゾーンエディタ(基本)
- 39.6 DNSサーバ: ゾーンエディタ(NSレコード)
- 39.7 DNSサーバ: ゾーンエディタ(MXレコード)
- 39.8 DNSサーバ: ゾーンエディタ(SOA)
- 39.9 プライマリゾーンのレコードを追加
- 39.10 逆引きゾーンの追加
- 39.11 逆引きレコードの追加
- 40.1 DHCPサーバ: カードの選択
- 40.2 DHCPサーバ: グローバル設定
- 40.3 DHCPサーバ: ダイナミックDHCP
- 40.4 DHCPサーバ: 起動
- 40.5 DHCPサーバ: ホスト管理
- 40.6 DHCPサーバ: chroot jailと宣言
- 40.7 DHCPサーバ: 宣言タイプの選択
- 40.8 DHCPサーバ: サブネットの設定
- 40.9 DHCPサーバ: TSIGの設定
- 40.10 DHCPサーバ: ダイナミックDNS用のインタフェースの設定
- 40.11 DHCPサーバ: ネットワークインタフェースとファイアウォール
- 42.1 HTTPサーバウィザード: デフォルトホスト
- 42.2 HTTPサーバウィザード: 概要
- 42.3 HTTPサーバの設定: 待ち受けポートとアドレス
- 42.4 HTTPサーバの設定: サーバモジュール
- 43.1 FTPサーバの設定 - 起動
- 47.1 SCAツールによって生成されるHTMLレポート
- 47.2 SCAアプライアンスによって生成されるHTMLレポート
- 1.1 ログインシェル用Bash設定ファイル
- 1.2 非ログインシェル用Bash設定ファイル
- 1.3 Bash用特殊ファイル
- 1.4 標準的なディレクトリツリーの概要
- 1.5 便利な環境変数
- 9.1 基本的なRPMクエリオプション
- 9.2 RPM確認オプション
- 19.1 サービス管理コマンド
- 19.2 サービスの有効化/無効化コマンド
- 19.3 System Vのランレベルと
systemd
のターゲットユニット - 23.1 プライベートIPアドレスドメイン
- 23.2 /etc/host.confファイルのパラメータ
- 23.3 /etc/nsswitch.confで利用できるデータベース
- 23.4 NSS「データベース」の環境設定オプション
- 23.5 ボンディングとチームの機能比較
- 25.1 fontconfigルールからのPFLの作成
- 25.2 順序を変更したFontconfigルールからのPFL生成結果
- 25.3 FontconfigルールからのPFL生成結果
- 30.1
ulimit
: ユーザのためのリソースの設定 - 45.1 sfcbdの管理用コマンド
- 46.1 マニュアルページ - カテゴリと説明
- 47.1 TARアーカイブの機能とファイル名の比較
- 48.1 ログファイル
- 48.2
/proc
ファイルシステムによるシステム情報 - 48.3
/sys
ファイルシステムによるシステム情報
- 1.1 テキストをプリントするシェルスクリプト
- 2.1 ユーザ固有の設定ファイルの作成
- 2.2 項目のグループ化によるカスタム設定の作成
- 2.3 エイリアスの適用による設定の簡潔化
- 9.1 Zypper - 既知のリポジトリのリスト
- 9.2
rpm -q -i wget
- 9.3 パッケージを検索するスクリプト
- 10.1 タイムライン設定の例
- 18.1 grub2-mkconfigの使用法
- 18.2 grub2-mkrescueの使用法
- 18.3 grub2-script-checkの使用
- 18.4 grub2-onceの使用法
- 19.1 アクティブなサービスの一覧表示
- 19.2 起動に失敗したサービスの一覧表示
- 19.3 サービスに属するすべてのプロセスの表示
- 22.1
java
コマンドのalternativesシステム - 23.1 IPアドレスの表記
- 23.2 IPアドレスとネットマスクの論理積(AND)
- 23.3 IPv6アドレスの例
- 23.4 プレフィクスの長さを指定したIPv6アドレス
- 23.5 一般的なネットワークインタフェースとスタティックルートの例
- 23.6
/var/run/netconfig/resolv.conf
- 23.7
/etc/hosts
- 23.8
/etc/networks
- 23.9
/etc/host.conf
- 23.10
/etc/nsswitch.conf
- 23.11 pingコマンドの出力
- 23.12 ネットワークチーミングによる負荷分散の設定
- 23.13 DHCPネットワークチーミングデバイスの設定
- 24.1
lpd
からのエラーメッセージ - 24.2 CUPSネットワークサーバからのブロードキャスト
- 25.1 レンダリングアルゴリズムを指定する
- 25.2 エイリアスとファミリ名の置換
- 25.3 エイリアスとファミリ名の置換
- 25.4 エイリアスとファミリ名の置換
- 29.1
udev
ルール例 - 30.1 /etc/crontab内のエントリ
- 30.2 /etc/crontab: タイムスタンプファイルの削除
- 30.3
ulimit
:~/.bashrc
中の設定 - 39.1 named.confファイルの転送オプション
- 39.2 基本的な/etc/named.confファイル
- 39.3 ログを無効にするエントリ
- 39.4 example.comのゾーンエントリ
- 39.5 example.netのゾーンエントリ
- 39.6 /var/lib/named/example.com.zoneファイル
- 39.7 逆引き
- 40.1 環境設定ファイル/etc/dhcpd.conf
- 40.2 環境設定ファイルへの追加
- 42.1 名前ベースの
VirtualHost
エントリの基本例 - 42.2 名前ベースの
VirtualHost
ディレクティブ - 42.3 IPベースの
VirtualHost
ディレクティブ - 42.4 基本的な
VirtualHost
設定 - 42.5 VirtualHost CGIの設定
- 44.1
squidclient
による要求 - 44.2 ACLルールの定義
- 47.1
root
としてログインしたときのhostinfo
の出力
Copyright © 2006–2024 SUSE LLC and contributors. All rights reserved.
この文書は、GNUフリー文書ライセンスのバージョン1.2または(オプションとして)バージョン1.3の条項に従って、複製、頒布、および/または改変が許可されています。ただし、この著作権表示およびライセンスは変更せずに記載すること。ライセンスバージョン1.2のコピーは、「GNUフリー文書ライセンス」セクションに含まれています。
SUSEの商標については、https://www.suse.com/company/legal/を参照してください。サードパーティ各社とその製品の商標は、所有者であるそれぞれの会社に所属します。商標記号(®、™など)は、SUSEおよびその関連会社の商標を示します。アスタリスク(*)は、第三者の商標を示します。
本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは絶対に正確であることを保証するものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。
序文 #
1 利用可能なマニュアル #
- オンラインマニュアル
オンラインマニュアルはhttps://documentation.suse.comにあります。さまざまな形式のマニュアルをブラウズまたはダウンロードできます。
注記: 最新のアップデート最新のアップデートは、通常、英語版マニュアルで入手できます。
- SUSE Knowledgebase
問題が発生した場合は、https://www.suse.com/support/kb/でオンラインで入手できる技術情報文書(TID)を確認してください。SUSE Knowledgebaseを検索して、お客様のニーズに応じた既知のソリューションを見つけます。
- リリースノート
リリースノートはhttps://www.suse.com/releasenotes/を参照してください。
- ご使用のシステムで
オフラインで使用するために、リリースノートはシステム上の
/usr/share/doc/release-notes
でも入手できます。個々のパッケージのマニュアルは、/usr/share/doc/packages
で入手できます。「マニュアルページ」には、多くのコマンドについても説明されています。説明を表示するには、
man
コマンドに確認したいコマンドの名前を付加して実行してください。システムにman
コマンドがインストールされていない場合は、sudo zypper install man
コマンドでインストールします。
2 ドキュメントの改善 #
このドキュメントに対するフィードバックや貢献を歓迎します。フィードバックを提供するための次のチャネルが利用可能です。
- サービス要求およびサポート
ご使用の製品に利用できるサービスとサポートのオプションについては、https://www.suse.com/support/を参照してください。
サービス要求を提出するには、SUSE Customer Centerに登録済みのSUSEサブスクリプションが必要です。https://scc.suse.com/support/requestsに移動して、ログインし、 をクリックします。
- バグレポート
https://bugzilla.suse.com/から入手できるドキュメントを使用して、問題を報告してください。
このプロセスを容易にするには、このドキュメントのHTMLバージョンの見出しの横にある
アイコンをクリックしてください。これにより、Bugzillaで適切な製品とカテゴリが事前に選択され、現在のセクションへのリンクが追加されます。バグレポートの入力を直ちに開始できます。Bugzillaアカウントが必要です。
- ドキュメントの編集に貢献
このドキュメントに貢献するには、このドキュメントのHTMLバージョンの見出しの横にある
アイコンをクリックしてください。GitHubのソースコードに移動し、そこからプルリクエストをオープンできます。GitHubアカウントが必要です。
注記:は英語でのみ利用可能このドキュメントに使用されるドキュメント環境に関する詳細については、リポジトリのREADMEを参照してください。
- メール
ドキュメントに関するエラーの報告やフィードバックは<doc-team@suse.com>宛に送信していただいてもかまいません。ドキュメントのタイトル、製品のバージョン、およびドキュメントの発行日を記載してください。また、関連するセクション番号とタイトル(またはURL)、問題の簡潔な説明も記載してください。
3 マニュアルの表記規則 #
このマニュアルでは、次の通知と表記規則が使用されています。
/etc/passwd
: ディレクトリ名とファイル名PLACEHOLDER: PLACEHOLDERは、実際の値で置き換えられます。
PATH
: 環境変数ls
、--help
: コマンド、オプションおよびパラメータuser
: ユーザまたはグループの名前package_name: ソフトウェアパッケージの名前
Alt、Alt–F1: 押すキーまたはキーの組み合わせ。キーはキーボードのように大文字で表示されます。
AMD/Intel この説明は、AMD64/Intel 64アーキテクチャにのみ当てはまります。矢印は、テキストブロックの先頭と終わりを示します。
IBM Z, POWER この説明は、
IBM Z
およびPOWER
アーキテクチャにのみ当てはまります。矢印は、テキストブロックの先頭と終わりを示します。Chapter 1, 「Example chapter」: このガイドの別の章への相互参照。
root
特権で実行する必要のあるコマンド。これらのコマンドの先頭にsudo
コマンドを置いて、特権のないユーザとしてコマンドを実行することもできます。#
command
>
sudo
command
特権のないユーザでも実行できるコマンド:
>
command
コマンドは、行末のバックスラッシュ文字(
\
)で2行または複数行に分割できます。バックスラッシュは、コマンドの呼び出しが行末以降も続くことをシェルに知らせます。>
echo
a b \ c dコマンド(プロンプトで始まる)と、シェルによって返される各出力の両方を示すコード ブロック:
>
command
output通知
警告: 警告の通知続行する前に知っておくべき、無視できない情報。セキュリティ上の問題、データ損失の可能性、ハードウェアの損傷、または物理的な危険について警告します。
重要: 重要な通知続行する前に知っておくべき重要な情報です。
注記: メモの通知追加情報。たとえば、ソフトウェアバージョンの違いに関する情報です。
ヒント: ヒントの通知ガイドラインや実際的なアドバイスなどの役に立つ情報です。
コンパクトな通知
追加情報。たとえば、ソフトウェアバージョンの違いに関する情報です。
ガイドラインや実際的なアドバイスなどの役に立つ情報です。
4 サポート #
SUSE Linux Enterprise Serverのサポートステートメントと、技術プレビューに関する一般情報を以下に示します。製品ライフサイクルの詳細については、https://www.suse.com/lifecycleを参照してください。
サポート資格をお持ちの場合、https://documentation.suse.com/sles-15/html/SLES-all/cha-adm-support.htmlを参照して、サポートチケットの情報を収集する方法の詳細を確認してください。
4.1 SUSE Linux Enterprise Serverのサポートステートメント #
サポートを受けるには、SUSEの適切な購読が必要です。利用可能な特定のサポートサービスを確認するには、https://www.suse.com/support/にアクセスして製品を選択してください。
サポートレベルは次のように定義されます。
- L1
問題の判別。互換性情報、使用サポート、継続的な保守、情報収集、および利用可能なドキュメントを使用した基本的なトラブルシューティングを提供するように設計されたテクニカルサポートを意味します。
- L2
問題の切り分け。データの分析、お客様の問題の再現、問題領域の特定、レベル1で解決できない問題の解決、またはレベル3の準備を行うように設計されたテクニカルサポートを意味します。
- L3
問題解決。レベル2サポートで特定された製品の欠陥を解決するようにエンジニアリングに依頼して問題を解決するように設計されたテクニカルサポートを意味します。
契約されているお客様およびパートナーの場合、SUSE Linux Enterprise Serverでは、次のものを除くすべてのパッケージに対してL3サポートを提供します。
技術プレビュー。
サウンド、グラフィック、フォント、およびアートワーク。
追加の顧客契約が必要なパッケージ。
モジュール「Workstation Extension」の一部として出荷される一部のパッケージは、L2サポートのみです。
名前が-develで終わるパッケージ(ヘッダファイルや開発者用のリソースを含む)に対しては、メインのパッケージとともにサポートが提供されます。
SUSEは、元のパッケージの使用のみをサポートします。つまり、変更も、再コンパイルもされないパッケージをサポートします。
4.2 技術プレビュー #
技術プレビューとは、今後のイノベーションを垣間見ていただくための、SUSEによって提供されるパッケージ、スタック、または機能を意味します。技術プレビューは、ご利用中の環境で新しい技術をテストする機会を参考までに提供する目的で収録されています。私たちはフィードバックを歓迎しています。技術プレビューをテストする場合は、SUSEの担当者に連絡して、経験や使用例をお知らせください。ご入力いただいた内容は今後の開発のために役立たせていただきます。
技術プレビューには、次の制限があります。
技術プレビューはまだ開発中です。したがって、機能が不完全であったり、不安定であったり、運用環境での使用には適していなかったりする場合があります。
技術プレビューにはサポートが提供されません。
技術プレビューは、特定のハードウェアアーキテクチャでしか利用できないことがあります。
技術プレビューの詳細および機能は、変更される場合があります。その結果、技術プレビューのその後のリリースへのアップグレードは不可能になり、再インストールが必要な場合があります。
SUSEで、プレビューがお客様や市場のニーズを満たしていない、またはエンタープライズ標準に準拠していないことを発見する場合があります。技術プレビューは製品から予告なく削除される可能性があります。SUSEでは、このようなテクノロジーのサポートされるバージョンを将来的に提供できない場合があります。
ご使用の製品に付属している技術プレビューの概要については、https://www.suse.com/releasenotesにあるリリースノートを参照してください。
パート I 共通のタスク #
- 1 BashとBashスクリプト
今日、多数のユーザが、GNOMEなどのGUI(グラフィカルユーザインタフェース)を介してコンピュータを使用しています。GUIは多くの機能を提供していますが、自動タスクを実行する際には用途は限定されています。シェルはGUIを適切に補完するものです。この章では、シェル(ここではBashシェル)のいくつかの側面について概要を説明します。
- 2
sudo
の基本 特定のコマンドを実行するには、root特権が必要です。ただし、セキュリティ上の理由のため、また間違いを避けるため、
root
としてログインすることは推奨されません。より安全な方法は、通常のユーザとしてログインしてから、sudo
を使用して昇格された特権でコマンドを実行することです。- 3 YaSTの使用
YaSTは、すべての必須インストールおよびシステム設定タスクにグラフィカルインタフェースを提供するSUSE Linux Enterprise Serverツールです。パッケージの更新、プリンタの設定、ファイアウォール設定の変更、FTPサーバの設定、ハードディスクのパーティション作成が必要な場合、YaSTを使用して実行できます。Rubyで記述されたYaSTは、モジュールを介して新しい機能を追加できる拡張可能なアーキテクチャを備えています。
- 4 テキストモードのYaST
ncursesベースの疑似グラフィカルYaSTインタフェースは、主にシステム管理者がXサーバを使用せずにシステムを管理できるように設計されています。このインタフェースには、従来のGUIと比較していくつかの利点があります。キーボードを使用してncursesインタフェースをナビゲートすることができ、事実上すべてのインタフェース要素に対するキーボードショートカットがあります。ncursesインタフェースは、リソースが少なく、中程度のハードウェアでも高速に実行されます。SSH接続を介してncursesベースのバージョンのYaSTを実行することができるため、リモートシステムを管理できます。YaSTを実行…
- 5 YaSTによる言語および国の設定の変更
この章では、言語および国を設定する方法について説明します。言語は、システム全体でグローバルに、特定のユーザまたはデスクトップで個別に、または単一のアプリケーションで一時的に変更できます。また、第二言語を設定し、日付と国の設定を調整できます。
- 6 YaSTによるユーザの管理
インストール時にシステム用のローカルユーザを作成できました。YaSTの
モジュールを使用して、ユーザの追加や既存ユーザの編集が可能です。また、ネットワークサーバでユーザを認証するようにシステムを設定できます。- 7 YaSTオンラインアップデート
SUSEはお買い上げの製品に対し、継続的にソフトウェアセキュリティのアップデートを提供します。デフォルトでは、システムを最新の状態に維持するために更新アプレットが使用されます。アップデートアプレットの詳細については、8.5項 「GNOMEパッケージアップデータ」を参照してください。この章では、ソフトウェアパッケージをアップデートする代替ツールとして、YaSTオンラインアップデートを紹介します。
- 8 ソフトウェアをインストールまたは削除する
YaSTのソフトウェア管理モジュールを使用すると、ソフトウェアパッケージを検索したり、インストールしたり削除したりできます。パッケージをインストールするとき、YaSTは、すべての依存関係を自動的に解決します。インストールメディアにないパッケージをインストールするには、ソフトウェアリポジトリとYaSTを追加して管理できます。アップデートアプレットを使用してソフトウェアアップデートを管理することによって、システムを最新に保つこともできます。
- 9 コマンドラインツールによるソフトウェアの管理
この章では、ソフトウェア管理の2つのコマンドラインツールとして、ZypperとRPMについて説明します。このコンテキストで使用される用語(
repository
、patch
、update
など)の定義については、8.1項 「用語の定義」を参照してください。- 10 Snapperを使用したシステムの回復とスナップショット管理
Snapperにより、ファイルシステムスナップショットを作成および管理できます。ファイルシステムスナップショットは特定の時点でのファイルシステムの状態のコピーを保持できます。Snapperの標準セットアップは、システムの変更のロールバックを許可するように設計されています。ただし、これを使用して、ユーザデータのオンディスクバックアップを作成することもできます。この機能のベースとして、SnapperはBtrfsファイルシステム、またはXFSあるいはExt4ファイルシステムでシンプロビジョニングされたLVMボリュームを使用します。
- 11 KLPによるライブカーネルパッチ
このドキュメントでは、KLP (カーネルライブパッチ)適用テクノロジーの基本原理について説明するとともに、SLE Live Patchingサービスの使用ガイドラインを提供します。
- 12 ユーザ空間ライブパッチ
この章では、ユーザスペースのライブパッチの基本原理と使用方法について説明します。
- 13 トランザクション更新
トランザクション更新は、ルートファイルシステムが読み込み専用のときにSLESを更新するためにSUSE Linux Enterprise Serverで利用できます。トランザクション更新はアトミックであり(すべての更新が成功した場合にのみすべての更新が適用されます)、ロールバックをサポートします。システムが再起動されるまで変更は有効にならないため、実行中のシステムには影響しません。再起動は中断を伴うので、管理者は、再起動の方が実行中のサービスを妨害するよりもコストがかかるかどうかを判断する必要があります。再起動でコストがかかりすぎる場合は、トランザクション更新を使用しないでください。
トランザクションの更新は、
transactional-update
スクリプトによって、毎日実行されます。スクリプトは使用可能な更新をチェックします。更新がある場合は、ルートファイルシステムの新しいスナップショットをバックグラウンドで作成し、リリースチャネルから更新をフェッチします。新しいスナップショットが更新された後で、アクティブとマークされ、システムの次の再起動後に新しいデフォルトのルートファイルシステムになります。transactional-update
が自動的に実行するように設定されている場合(これはデフォルトの動作です)、システムも再起動します。更新を実行する時刻と再起動の保守時間枠の両方が設定可能です。ルートファイルシステムのスナップショットの一部であるパッケージのみを更新できます。パッケージにスナップショットの一部ではないファイルが含まれている場合、更新は失敗するか、システムが破損する可能性があります。
ライセンスを受諾する必要があるRPMは更新できません。
- 14 VNCによるリモートグラフィカルセッション
仮想ネットワークコンピューティング (VNC)では、グラフィカルデスクトップを介してリモートコンピュータにアクセスしたり、リモートグラフィカルアプリケーションを実行したりできます。VNCはプラットフォームに依存しないので、VNCを使用すれば、任意のオペレーティングシステムからリモートマシンにアクセスできます。この章では、デスクトップクライアントvncviewerおよびRemminaを使用してVNCサーバに接続する方法、およびVNCサーバを操作する方法について説明します。
SUSE Linux Enterprise Serverでは、2種類のVNCセッションをサポートしています。1つはクライアントからのVNC接続が続く間「存続する」一時的セッションで、もう1つは明示的に終了されるまで「存続する」永続的セッションです。
VNCサーバでは両方のタイプのセッションを異なるポートで同時に提供できます。ただし、オープンセッションを1つのタイプからもう一方のタイプに変換することはできません。
- 15 rsyncによるファイルのコピー
現在の通常のユーザは、複数のコンピュータ(家庭用および職場用のマシン、ラップトップ、スマートフォン、またはタブレット)を持っています。このため、複数のデバイス間でファイルとドキュメントを同期させることがますます重要になっています。
1 BashとBashスクリプト #
今日、多数のユーザが、GNOMEなどのGUI(グラフィカルユーザインタフェース)を介してコンピュータを使用しています。GUIは多くの機能を提供していますが、自動タスクを実行する際には用途は限定されています。シェルはGUIを適切に補完するものです。この章では、シェル(ここではBashシェル)のいくつかの側面について概要を説明します。
1.1 「シェル」とは何か? #
従来、Linuxシェルとは、Bash(Bourne again Shell)のことでした。この章では、Bashを「シェル」と呼びます。シェルはBashの他にもあり(ash、csh、ksh、zshなど)、異なる機能と特性を持っています。他のシェルの詳細については、YaSTで「シェル」を検索してください。
1.1.1 Bashの環境設定ファイル #
シェルは、次のようにして呼び出すことができます。
対話型ログインシェル. コンピュータへのログイン時に、
--login
オプションを使用してBashを呼び出す場合か、SSHを使用してリモートコンピュータへログインする場合に使用します。「通常の」対話型シェル. xtermやkonsole、gnome-terminalなどのコマンドラインインタフェース(CLI)ツールの起動時には、通常、この形式を使用します。
非対話型シェル. コマンドラインからシェルスクリプトを呼び出す場合に呼び出されます。
シェルによって読み込まれる設定ファイルは異なります。次のテーブルには、それぞれ、ログインシェル設定ファイルと非ログインシェル設定ファイルが示されています。
Bashは、実行されているシェルのタイプに応じて特定の順序で設定ファイルを検索します。詳細については、Bashのマニュアルページ(man 1 bash
)を参照してください。見出しINVOCATION
を検索します。
ファイル |
説明 |
---|---|
|
このファイルは変更しないでください。変更しても、次の更新で変更内容が破棄される可能性があります。 |
|
|
|
特定プログラムのシステム全体にわたる設定ファイルを含みます。 |
|
ログインシェル用のユーザ固有の設定をここに挿入します。 |
ログインシェルは、表1.2「非ログインシェル用Bash設定ファイル」に示す設定ファイルも参照します。
|
このファイルは変更しないでください。変更しても、次の更新で変更内容が破棄される可能性があります。 |
|
Bashのシステム全体にわたる変更を挿入する場合のみ、このファイルを使用します。 |
|
ユーザ固有の設定をここに挿入します。 |
また、Bashは複数のファイルを使用します。
ファイル |
説明 |
---|---|
|
入力したすべてのコマンドのリストを含みます。 |
|
ログアウト時に実行されます。 |
|
よく使用されるコマンドのユーザ定義エイリアス。エイリアスの定義の詳細については、 |
非ログインシェル#
ユーザがシステムにログインするのをブロックする特殊なシェル(/bin/false
と/sbin/nologin
)があります。ユーザがシステムにログインしようとすると、両方ともサイレントに失敗します。これはシステムユーザのセキュリティ対策として意図されたものですが、最新のLinuxオペレーティングシステムには、PAMやAppArmorなど、システムアクセスを制御するためのより効果的なツールがあります。
SUSE Linux Enterprise Serverのデフォルトでは、/bin/bash
が人間のユーザに割り当てられ、/bin/false
または/sbin/nologin
がシステムユーザに割り当てられます。歴史的な理由のため、nobody
ユーザは/bin/bash
を使用します。これは、システムユーザのデフォルトとして使用されていた最小限の特権を持つユーザであるためです。ただし、nobody
を使用することにより得られたわずかなセキュリティも、複数のシステムユーザが使用すると失われます。これを/sbin/nologin
に変更できるはずです。それをテストする最も早い方法は、変更を行い、サービスやアプリケーションを中断させていないかどうかを確認することです。
次のコマンドを使用して、/etc/passwd
で、すべてのユーザ、システム、および人間のユーザに割り当てられているシェルを一覧にします。出力は、システムのサービスおよびユーザによって異なります。
>
sort -t: -k 7 /etc/passwd | awk -F: '{print $1"\t" $7}' | column -t
tux /bin/bash
nobody /bin/bash
root /bin/bash
avahi /bin/false
chrony /bin/false
dhcpd /bin/false
dnsmasq /bin/false
ftpsecure /bin/false
lightdm /bin/false
mysql /bin/false
postfix /bin/false
rtkit /bin/false
sshd /bin/false
tftp /bin/false
unbound /bin/false
bin /sbin/nologin
daemon /sbin/nologin
ftp /sbin/nologin
lp /sbin/nologin
mail /sbin/nologin
man /sbin/nologin
nscd /sbin/nologin
polkitd /sbin/nologin
pulse /sbin/nologin
qemu /sbin/nologin
radvd /sbin/nologin
rpc /sbin/nologin
statd /sbin/nologin
svn /sbin/nologin
systemd-coredump /sbin/nologin
systemd-network /sbin/nologin
systemd-timesync /sbin/nologin
usbmux /sbin/nologin
vnc /sbin/nologin
wwwrun /sbin/nologin
messagebus /usr/bin/false
scard /usr/sbin/nologin
1.1.2 ディレクトリ構造 #
次のテーブルでは、Linuxシステムの最も重要な上位レベルディレクトリについて、短い概要を示します。それらのディレクトリおよび重要なサブディレクトリの詳細については、後続のリストを参照してください。
ディレクトリ |
目次 |
---|---|
|
ルートディレクトリ(ディレクトリツリーの開始場所)。 |
|
システム管理者および通常ユーザの両者が必要とするコマンドなどの必須バイナリファイル。通常、Bashなどのシェルも含みます。 |
|
ブートローダの静的ファイル |
|
ホスト固有のデバイスのアクセスに必要なファイル |
|
ホスト固有のシステム設定ファイル |
|
システムにアカウントを持つすべてのユーザのホームディレクトリを格納します。ただし、 |
|
必須の共有ライブラリおよびカーネルモジュール |
|
リムーバブルメディアのマウントポイント |
|
ファイルシステムを一時的にマウントするためのマウントポイント |
|
アドオンアプリケーションのソフトウェアパッケージ |
|
スーパーユーザ |
|
必須のシステムバイナリ |
|
システムで提供するサービスのデータ |
|
一時ファイルを格納するディレクトリ |
|
読み込み専用データを含む第二階層 |
|
ログファイルなどの可変データ |
|
システムにMicrosoft Windows*とLinuxの両方がインストールされる場合のみ利用可能。Windowsデータを含みます。 |
次のリストでは、さらに詳しい情報を提供し、ディレクトリに含まれるファイルおよびサブディレクトリの例を示します。
/bin
root
と他のユーザの両者が使用できる基本的なシェルコマンドを含みます。これらのコマンドには、ls
、mkdir
、cp
、mv
、rm
、およびrmdir
が含まれます。また、/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/doc
にhowto
サブディレクトリも含まれます。このサブディレクトリには、Linuxソフトウェアの設定および操作に関する多数のタスクの追加ドキュメントが格納されます。/var
/usr
は静的な読み込み専用データを含みますが、/var
は、システム動作時に書き込まれる可変データ(ログファイル、スプールデータなど)のディレクトリです。/var/log/
にある重要なログファイルの概要は、表48.1「ログファイル」を参照してください。
1.2 シェルスクリプトの作成 #
シェルスクリプトは、データの収集、テキスト内のワードやフレーズの検索など、さまざまな有用なタスクの実行に便利な方法です。次の例では、小型のシェルスクリプトでテキストをプリントします。
#!/bin/sh 1 # Output the following line: 2 echo "Hello World" 3
最初の行は、このファイルがスクリプトであることを示すShebang文字( | |
2行目は、ハッシュ記号で始まるコメントです。意図を理解しにくい行にはコメントすることをお勧めします。適切にコメントすると、行の目的および機能を覚えることができます。また、他の読み手もスクリプトをより良く理解できます。コメントは開発コミュニティにおいてグッドプラクティスとみなされます。 | |
3番目の行で、組み込みコマンド |
このスクリプトを実行するには、その前にいくつかの前提条件があります。
すべてのスクリプトには(上記の例のように) Shebang行が含まれている必要があります。この行がない場合は、インタプリタを手動で呼び出す必要があります。
スクリプトの保存場所はどこでも構いません。ただし、シェルの検索先ディレクトリを保存場所にすることをお勧めします。シェルのサーチパスは、環境変数
PATH
で設定されます。標準ユーザには/usr/bin
への書き込みアクセスはありません。このため、スクリプトはユーザのディレクトリ~/bin/
に保存することを推奨します。上記の例では、名前はhello.sh
です。スクリプトには、実行可能パーミッションが必要です。次のコマンドで、パーミッションを設定してください。
>
chmod +x ~/bin/hello.sh
これらの前提条件をすべて満たしたら、次の方法でスクリプトを実行できます。
絶対パス. スクリプトは絶対パスで実行できます。この例では、
~/bin/hello.sh
です。任意の場所.
PATH
環境変数にスクリプトが存在するディレクトリが含まれている場合、スクリプトをhello.sh
で実行できます。
1.3 コマンドイベントのリダイレクト #
各コマンドは、入力または出力用として、3つのチャネルを使用できます。:
標準出力. デフォルトの出力チャネル。コマンドで何かをプリントする際には標準出力チャネルが使用されます。
標準入力. コマンドでユーザまたは他のコマンドからの入力を必要とする場合は、このチャネルが使用されます。
標準エラー. このチャネルは、エラーレポーティングに使用されます。
これらのチャネルをリダイレクトするには、次の方法を使用できます。
Command > File
コマンド出力をファイルに保存します。既存ファイルは削除されます。たとえば、
ls
コマンドの出力をlisting.txt
ファイルに書き込みます。>
ls > listing.txtCommand >> File
コマンド出力をファイルに追加します。たとえば、
ls
コマンドの出力をlisting.txt
ファイルに追加します。>
ls >> listing.txtCommand < File
ファイルを読み込み、指定されたコマンドへの入力とします。たとえば、ファイルのコンテンツを
read
コマンドで読み込み、変数に入力します。>
read a < fooCommand1 | 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.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.txtCommand1 && Command2
左のコマンドが成功した場合、右のコマンドを実行します(論理AND)。次の行では、ファイルのコンテンツを表示し、そのコマンドが成功した場合のみ、ファイルのプロパティをプリントします(このリストの前の項目と比較してください)。
>
cat filelist.txt && ls -l filelist.txtCommand1 || Command2
左のコマンドが失敗した場合、右のコマンドを実行します(論理OR)次の行では、
/home/tux/foo
でのディレクトリ作成に失敗した場合のみ、/home/wilber/bar
内にディレクトリを作成します。>
mkdir /home/tux/foo || mkdir /home/wilber/barfuncname(){ ... }
シェル関数を作成します。位置パラメータを使用して、関数の引数にアクセスできます。次の行では、短いメッセージをプリントする関数
hello
を定義します。>
hello() { echo "Hello $1"; }この関数は、次のように呼び出せます。
>
hello Tux結果は、次のようにプリントされます。
Hello Tux
1.7 よく使用されるフローコンストラクトの操作 #
スクリプトのフローを制御するために、シェルには、while
、if
、for
、および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
その他の役に立つ式については、https://bash.cyberciti.biz/guide/If..else..fiを参照してください。
1.7.2 for
コマンドによるループの作成 #
for
ループを使用すると、エントリのリストにコマンドを実行できます。たとえば、次のコードは、現在のディレクトリ内のPNGファイルの特定の情報をプリントします。
for i in *.png; do ls -l $i done
1.8 詳細情報 #
Bashに関する重要な情報は、マニュアルページman
bash
に記載されています。このトピックの詳細については、次のリストを参照してください。
https://tldp.org/LDP/Bash-Beginners-Guide/html/index.html—Bash Guide for Beginners
https://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html—BASH Programming - Introduction HOW-TO
https://tldp.org/LDP/abs/html/index.html—Advanced Bash-Scripting Guide
https://www.grymoire.com/Unix/Sh.html—Sh - the Bourne Shell
2 sudo
の基本 #
特定のコマンドを実行するには、root特権が必要です。ただし、セキュリティ上の理由のため、また間違いを避けるため、root
としてログインすることは推奨されません。より安全な方法は、通常のユーザとしてログインしてから、sudo
を使用して昇格された特権でコマンドを実行することです。
SUSE Linux Enterprise Serverでは、sudo
はsu
と同様に機能するように設定されています。ただし、sudo
には、ユーザが他のユーザの特権でコマンドを実行できるようにする柔軟なメカニズムがあります。このコマンドを使用して、指定の特権を持つ役割を特定のユーザとグループに割り当てることができます。たとえば、users
グループのメンバーが、wilber
ユーザの特権でコマンドを実行できるようにすることができます。コマンドへのアクセスは、コマンドオプションを禁止することにより、さらに制限できます。suでは、PAMを使用した認証で常にroot
パスワードを必要としますが、sudo
では、ユーザの資格情報を使用して認証するように設定できます。すなわち、ユーザはroot
パスワードを共有する必要がなく、セキュリティが向上します。
2.1 sudo
の基本的な使用方法 #
次の章では、sudo
の基本的な使用方法の概要について説明します。
2.1.1 単一コマンドの実行 #
標準ユーザは、コマンドの前にsudo
を追加することで、任意のコマンドをroot
として実行できます。これにより、rootパスワードを入力するように求められます。正常に認証されたら、root
としてコマンドが実行されます。
>
id -un
1 tux>
sudo
id -un
root's password:2 root>
id -un
tux3>
sudo
id -un
4 root
| |
入力時には、パスワードは表示されません(クリアテキストとしてだけでなく、マスク文字としても表示されません)。 | |
| |
昇格された特権は特定の期間保持されるため、再び |
sudo
の使用時に、I/Oリダイレクトは機能しません。
>
sudo
echo s > /proc/sysrq-trigger bash: /proc/sysrq-trigger: Permission denied>
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 -s root's password:root:/home/tux #
exittux:~ >
sudo -i (<command>)
-s
と同様ですが、シェルはログインシェルとして起動します。これは、シェルの起動ファイル(.profile
など)が処理され、現在の作業ディレクトリがターゲットユーザのホームディレクトリに設定されることを意味します。tux:~ >
sudo -i root's password:root:~ #
exittux:~ >
2.2 sudo
の構成 #
sudo
は、設定可能なオプションの幅広い範囲を提供します。
誤ってsudo
からロックアウトした場合は、su
-
とroot
パスワードを使用してルートシェルを起動してください。エラーを修正するには、visudo
を実行します。
以下で紹介するルールの例はデモンストレーションのみを目的としています。これらのルール例を利用して、sudo
設定ファイルの一般的な構文を理解してください。実際の環境では、このルール例をそのまま使用しないでください。環境の複雑さを反映していないからです。
2.2.1 sudo
の設定でのベストプラクティス #
まず、sudo
設定を維持するための基本ルールについて説明します。
sudo
の設定ファイルの編集には必ずvisudo
を使用するsudo
の設定の変更では、どの場合もvisudo
コマンドを使用する必要があります。visudo
は、sudo
設定ファイルを編集することができ、基本的な構文チェックを実行して、設定がそのまま機能できるようにする、オーダーメイドツールです。sudo
の設定に不備があると、ユーザが自身のシステムからロックアウトされることがあります。- 必ず
/etc/sudoers.d/
にカスタム設定を作成する カスタム設定は、
sudo
によって取得できるように、/etc/sudoers.d/
に置く必要があります。カスタム設定ファイルに記述した設定は、/etc/sudoers
のデフォルト設定よりも優先されます。- 設定が読み取られる順序にいつでも注意する
カスタム設定が確実に正しい順序で読み取られるように数字のプレフィクスを付加します。先頭に0を付加してファイルの読み取り順序を指定します。これにより、たとえば
01_myfirstconfig
は10_myotherconfig
よりも前に解析されます。順番に読み取られる複数のディレクティブを設定したファイルで、これらの各ディレクティブに記述された情報が互いに矛盾していると、最後に読み込まれたディレクティブが適用されます。- 必ずわかりやすいファイル名を使用する
設定ファイルの機能がわかるようなファイル名を使用します。
sudo
のセットアップで想定している動作を追跡する際に、この措置が効果的です。
2.2.2 ユーザ固有の設定ファイルの作成 #
通常のユーザ(tux
)が、root
パスワードではなく自身のパスワードを使用して、useradd
コマンドを使用できるように、sudo
の設定ファイルを作成します。
新しいユーザ固有のディレクティブを保持するカスタム設定ファイルを作成します。そのためには、システム管理者(
root
)としてvisudo
を起動します。番号付けと説明的な名前の両方を使用します。#
visudo -f /etc/sudoers.d/02_usermanagement
この
sudo
設定を適用する環境全体でtux
が/usr/sbin/useradd
バイナリを実行できるようにするルールを作成します。tux1 ALL2 = /usr/sbin/useradd3
ユーザまたはグループを指定します。ユーザは、名前または
#UID
で一覧にし、グループは、%GROUPNAME
で一覧にします。複数の項目はコンマで区切ります。エントリを無効にするには!
を使用します。ホストを1つまたはコンマで区切って複数指定します。完全修飾ホスト名またはIPアドレスを使用します。すべてのホストにこの設定をグローバルに適用するには
ALL
を追記します。適用しない場合は!
を使用します。実行可能ファイルを1つまたはコンマで区切って複数指定します。各ファイルの指定では次のルールに留意します。
/usr/sbin/useradd
追加オプションを追記しない場合は、実行可能なすべての
useradd
コマンドを実行できます。/usr/sbin/useradd -c
明示的にオプションを指定すると、そのオプションのみが適用されます。上記で指定したユーザは、これ以外のオプションを利用できません。
/usr/sbin/useradd ""
オプションを指定せずに
useradd
の呼び出しのみができるようにします。
上記の例では、すべてのオプションおよびサブコマンドを許可したり、セキュリティ上の理由からいくつかに制限したりできますが、ユーザがオプションを指定できないようにすることは、このコンテキストでは意味がありません。
ユーザが
root
パスワードの代わりに、自分のパスワードを使用できるようにするには、次の行を追加します。Defaults:tux !targetpw
このフラグがアクティブな場合、目的のユーザ(
root
)のパスワードの入力が求められます。SUSE Linux Enterprise Serverシステムでは、このフラグがデフォルトで有効になっています。!
を使用してこのフラグを無効にすると、ユーザはroot
パスワードの代わりに自分のパスワードの入力を求められます。設定を保存し、エディタを終了して、2番目のシェルを開き、
sudo
が新しい設定に従うかどうかをテストします。
2.2.3 項目のグループ化によるカスタム設定の作成 #
指定したユーザのグループがroot
パスワードを必要とせずにuseradd
コマンドを実行できるように、例2.1「ユーザ固有の設定ファイルの作成」の設定を変更します。また、このグループで使用できるコマンドのリストにusermod
とuserdel
を追加します。
この設定例を変更するには、
visudo
を使用してシステム管理者として設定を開きます。#
visudo /etc/sudoers.d/02_usermanagement
コンマ区切りで記述した複数のユーザをルールに追加します。
tux, wilber ALL = /usr/sbin/useradd
ここで記述したユーザが複数のコマンドを実行できるようにするには、それらのコマンドをコンマ区切りで指定します。
tux, wilber ALL = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
ここで記述したユーザが
root
パスワードの代わりに、自分のパスワードを使用できるようにするには、次の行を追加します。Defaults:tux, wilber !targetpw
このフラグがアクティブな場合、ここで記述したユーザは目的のユーザ(
root
)のパスワードの入力が求められます。SUSE Linux Enterprise Serverシステムでは、このフラグがデフォルトで有効になっています。!
を使用してこのフラグを無効にすると、ここで記述したユーザはroot
パスワードの代わりに自分のパスワードの入力を求められます。設定を保存し、エディタを終了して、2番目のシェルを開き、
sudo
が新しい設定に従うかどうかをテストします。
2.2.4 エイリアスの適用による設定の簡潔化 #
エイリアスを使用して、例2.2「項目のグループ化によるカスタム設定の作成」のカスタム設定の簡素化を進めます。項目をグループ化することはある程度役立ちますが、ユーザ、コマンド、およびホストのグローバルエイリアスを使用することが、クリーンで無駄のないsudo
設定を保つための最も効率的な方法です。
リストの代わりにエイリアスやグループを使用する方が、セットアップの変更に対処する上ではるかに良い方法です。グループからユーザが離れる場合は、独立したカスタム設定ファイルをすべて調べるのではなく、エイリアス宣言ファイル内のグローバルUser_Alias
宣言からそのユーザを削除するだけですみます。他のタイプのエイリアス(Host_Alias
、Cmnd_Alias
、およびRunas_Alias
)についても、同じ手順が適用されます。
グローバルエイリアス定義を保持する新しいファイルを作成します。
#
visudo /etc/sudoers.d/01_aliases
次の行を追加して、
TEAMLEADERS
エイリアスを作成します。User_Alias TEAMLEADERS = tux, wilber
次の行を追加して、
USERMANAGEMENT
エイリアスを作成します。Cmnd_Alias USERMANAGEMENT = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
変更を保存し、
visudo
を終了します。システム管理者として
visudo
を起動して、設定ファイル例を次のように編集します。#
visudo -f /etc/sudoers.d/02_usermanagement
前のルールを削除し、上記で定義したエイリアスを使用する次のルールに置き換えます。
TEAMLEADERS ALL = USERMANAGEMENT
User_Alias
で定義されたすべてのユーザがroot
パスワードの代わりに、自分のパスワードを使用できるようにするには、次の行を追加します。Defaults:TEAMLEADERS !targetpw
設定を保存し、エディタを終了して、2番目のシェルを開き、
sudo
が新しい設定に従うかどうかをテストします。
2.2.5 基本的なsudoersの設定構文 #
sudoersの設定ファイルには、2種類のオプション(文字列とフラグ)があります。文字列には任意の値を含めることができますが、フラグはONかOFFのいずれかのみです。sudoersの設定ファイルの最も重要な構文構造は次のとおりです。
# Everything on a line after # is 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
例外が2つあります。 | |
| |
2.2.6項 「基本的なsudoersのルール」を参照してください。 |
targetpw
このフラグは、呼び出し元のユーザが、ターゲットユーザのパスワード(ON)(
root
など)と、呼び出し元のユーザのパスワード(OFF)のいずれを要求されるかを決定します。Defaults targetpw # Turn targetpw flag ON
rootpw
設定すると、
sudo
は、root
パスワードを要求します。デフォルトはOFFです。Defaults !rootpw # Turn rootpw flag OFF
env_reset
設定すると、
sudo
はTERM
、PATH
、HOME
、MAIL
、SHELL
、LOGNAME
、USER
、USERNAME
、および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
トークンを使用することで、ユーザ、ホスト、およびコマンドのコレクションのエイリアスを作成することもできます。さらに、一連のユーザのみを対象としてオプションを適用することができます。
sudoers設定ファイルの詳細については、man 5
sudoers
を参照してください。
2.2.6 基本的なsudoersのルール #
各ルールは、次のスキームに従います([]
はオプション部分を示しています)。
#Who Where As whom Tag What User_List Host_List = [(User_List)] [NOPASSWD:|PASSWD:] Cmnd_List
User_List
1つ以上の(コンマで区切られた)識別子。ユーザ名、
%GROUPNAME
形式のグループ、または#UID
形式のユーザIDを指定します。否定は!
プレフィクスで指定できます。Host_List
1つ以上の(コンマで区切られた)識別子。(完全修飾された)ホスト名またはIPアドレスのいずれかを指定します。否定は
!
プレフィクスで指定できます。通常、Host_List
にはALL
を選択します。NOPASSWD:|PASSWD:
NOPASSWD:
の後に記述した、Cmd_List
と一致するコマンドを実行する場合は、パスワードが要求されません。PASSWD
はデフォルトです。PASSWD
とNOPASSWD
の両方が同じ行に存在する場合にのみ指定する必要があります。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_List
、Host_List
、およびCmnd_List
として使用できます。
パスワードを入力しなくても、tux
がすべてのコマンドをrootとして実行できるようにするルールは次のとおりです。
tux ALL = NOPASSWD: ALL
tux
がsystemctl restart
apache2
を実行できるようにするルールは次のとおりです。
tux ALL = /usr/bin/systemctl restart apache2
tux
がwall
をadmin
として引数なしで実行できるようにするルールは次のとおりです。
tux ALL = (admin) /usr/bin/wall ""
Defaults targetpw
なしで、ALL ALL =
ALL
のようなルールを使用「しないでください」。そうしないと、だれでもroot
としてコマンドを実行できるようになります。
sudoers
ファイルでグループ名を指定する場合は、レルムの代わりにNetBIOSドメイン名を使用するようにしてください。次に例を示します。
%DOMAIN\\GROUP_NAME ALL = (ALL) ALL
winbinddを使用する場合、この形式は、smb.conf
ファイルのwinbind separator
オプションによっても異なることに注意してください。デフォルトでは、\
です。たとえば、+
に変更された場合、sudoers
ファイルのアカウント形式はDOMAIN+GROUP_NAME
である必要があります。
2.3 X.Orgアプリケーションでのsudo
の使用 #
グラフィカルアプリケーションをsudo
で起動すると、通常、次のエラーが発生します。
>
sudo
xterm xterm: Xt error: Can't open display: %s xterm: DISPLAY is not set
簡単な回避策は、xhostを使用して、ルートユーザがローカルユーザのXセッションに一時的にアクセスできるようにすることです。これは、次のコマンドを使用して実行されます。
xhost si:localuser:root
次のコマンドは許可されたアクセスを削除します。
xhost -si:localuser:root
ルート特権でグラフィカルアプリケーションを実行すると、セキュリティに影響を与えます。例外としてのみグラフィカルアプリケーションのルートアクセスを有効にすることをお勧めします。グラフィカルアプリケーションが閉じられたらすぐに、許可されたルートアクセスを取り消すことも推奨されます。
2.4 詳細情報 #
sudo --help
コマンドは、使用可能なコマンドラインオプションの簡単な概要を提供し、man sudoers
コマンドは、sudoers
とその設定に関する詳細情報を提供します。
3 YaSTの使用 #
YaSTは、すべての必須インストールおよびシステム設定タスクにグラフィカルインタフェースを提供するSUSE Linux Enterprise Serverツールです。パッケージの更新、プリンタの設定、ファイアウォール設定の変更、FTPサーバの設定、ハードディスクのパーティション作成が必要な場合、YaSTを使用して実行できます。Rubyで記述されたYaSTは、モジュールを介して新しい機能を追加できる拡張可能なアーキテクチャを備えています。
YaSTに関する追加情報については、https://yast.opensuse.org/にあるプロジェクトの公式Webサイトを参照してください。
3.1 YaSTインタフェースの概要 #
YaSTには2つのグラフィカルインタフェースがあります。1つはKDEやGNOMEなどのグラフィカルデスクトップ環境で使用するためのもので、もう1つはXサーバを使用しないシステムで使用するためのncursesベースの疑似グラフィカルインタフェースです(第4章 「テキストモードのYaST」を参照してください)。
YaSTのグラフィカルバージョンでは、YaSTのすべてのモジュールはカテゴリ別にグループ化されており、ナビゲーションサイドバーによって、目的のカテゴリのモジュールに素早くアクセスできます。上部の検索フィールドでは、名前でモジュールを検索することができます。特定のモジュールを検索するには、検索フィールドにその名前を入力します。入力すると、入力した文字列に一致するモジュールが表示されます。
ncursesベースのYaSTとGUIバージョンのYaSTでは、インストールされるモジュールのリストが異なる場合があります。YaSTモジュールを起動する前に、使用しているYaSTのバージョンに合わせてインストールされていることを確認してください。
3.2 便利なキーの組み合わせ #
YaSTのグラフィカルバージョンはキーボードショートカットをサポートしています
- Print Screen
スクリーンショットを作成して保存します。特定のデスクトップ環境では機能しない場合があります。
- Shift–F4
視覚障がいのあるユーザ向けに最適化されたカラーパレットを有効および無効にします。
- Shift–F7
デバッグメッセージのログを有効/無効にします。
- Shift–F8
ファイルダイアログを開いて、ログファイルをユーザ定義の場所に保存します。
- Ctrl–Shift–Alt–D
DebugEventを送信します。YaSTモジュールは特殊なデバッグアクションを実行してこれに応答できます。結果は特定のYaSTモジュールによって異なります。
- Ctrl–Shift–Alt–M
マクロレコーダを開始および停止します。
- Ctrl–Shift–Alt–P
マクロを再生します。
- Ctrl–Shift–Alt–S
スタイルシートエディタを表示します。
- Ctrl–Shift–Alt–T
ウィジェットツリーをログファイルにダンプします。
- Ctrl–Shift–Alt–X
ターミナルウィンドウ(xterm)を開きます。VNCを使用したインストールプロセスで便利です。
- Ctrl–Shift–Alt–Y
ウィジェットツリーブラウザを表示します。
4 テキストモードのYaST #
ncursesベースの疑似グラフィカルYaSTインタフェースは、主にシステム管理者がXサーバを使用せずにシステムを管理できるように設計されています。このインタフェースには、従来のGUIと比較していくつかの利点があります。キーボードを使用してncursesインタフェースをナビゲートすることができ、事実上すべてのインタフェース要素に対するキーボードショートカットがあります。ncursesインタフェースは、リソースが少なく、中程度のハードウェアでも高速に実行されます。SSH接続を介してncursesベースのバージョンのYaSTを実行することができるため、リモートシステムを管理できます。YaSTを実行するためのターミナルエミュレータの最小サポートサイズは、80x25文字であることに注意してください。
ncursesベースのバージョンのYaSTを起動するには、端末を開いて、sudo yast2
コマンドを実行します。<Tab>または矢印キーを使用して、メニュー項目、フィールド、ボタンなどのインタフェース要素間をナビゲートします。YaSTのすべてのメニュー項目およびボタンには、適切なファンクションキーまたはキーボードショートカットを使用してアクセスできます。たとえば、F9を押して現在の操作をキャンセルし、F10キーを使用して変更を受け入れることができます。YaSTのncursesベースのインタフェースの各メニュー項目およびボタンには、そのラベルにハイライトされた文字があります。この文字は、インタフェース要素に割り当てられたキーボードショートカットの一部です。たとえば、文字Q
は ボタンでハイライトされます。これは、Alt–Alt+Qを押してボタンを有効にできることを意味します。
ウィンドウのサイズを変更した場合など、YaSTのダイアログの表示が乱れたり変形したりした場合は、Ctrl–Lを押すとコンテンツを更新し復元できます。
4.2 高度なキーの組み合わせ #
ncursesベースのバージョンのYaSTは、高度なキーの組み合わせを提供します。
- Shift–F1
高度なホットキーを一覧表示します。
- Shift–F4
配色を変更します。
- Ctrl–Q
アプリケーションを終了します。
- Ctrl–L
画面を更新します。
- Ctrl–DF1
高度なホットキーを一覧表示します。
- Ctrl–DShift–D
ダイアログをスクリーンショットとしてログファイルにダンプします。
- Ctrl–DShift–Y
YDialogSpyを開いてウィジェット階層を表示します。
4.3 キーの組み合わせの制約 #
ウィンドウマネージャがグローバルなAltキーの組み合わせを使用していると、YaSTでのAltキーの組み合わせが機能しない場合があります。ShiftやAltなどのキーは、端末の設定で使用されている場合もあります。
- Escの代わりにAltを使用
AltショートカットはAltの代わりにEscキーでも実行できます。たとえば、Esc–Hは、Alt–Hの代わりとなります。(まずEscを押して、「次に」Hを押します)
- Ctrl–FとCtrl–Bによる前後のナビゲーション
AltとShiftの組み合わせがウィンドウマネージャまたは端末に専有されている場合は、Ctrl–F(進む)とCtrl–B(戻る)の組み合わせを代わりに使用できます。
- ファンクションキーの制約
ファンクションキー(F1 ... F12)は各種機能にも使用されます。特定のファンクションキーは、端末に専有され、YaSTで使用できない場合があります。ただし、Altキーのキーの組み合わせとファンクションキーは、ピュアテキストコンソールでは常に完全に使用できます。
4.4 YaSTコマンドラインオプション #
テキストモードのインタフェースのほか、YaSTには、シンプルなコマンドラインインタフェースがあります。YaSTコマンドオプションのリストを取得するには、次のコマンドを使用します。
>
sudo
yast -h
4.4.1 コマンドラインからのパッケージのインストール #
パッケージ名が既知であり、パッケージが有効なインストールリポジトリに用意されている場合は、コマンドラインオプション-i
を使用してパッケージをインストールできます。
>
sudo
yast -i package_name
あるいは、
>
sudo
yast --install -i package_name
package_nameには、(gvimなどの)1つの短いパッケージ名を指定するか(この場合、依存関係を確認してインストールされます)、RPMパッケージのフルパスを指定できます(この場合、依存関係を確認せずにインストールされます)。
YaSTではコマンドラインからソフトウェアを管理するための基本的な機能を提供しますが、高度なパッケージ管理タスクにはZypperを使用することを検討してください。Zypperの使用に関する詳細については、9.1項 「Zypperの使用」を参照してください。
4.4.2 個々のモジュールの使用 #
時間を節約するために、次のコマンドを使用して個々のYaSTモジュールを起動することができます。
>
sudo
yast module_name
yast
-l
またはyast --list
を使用してシステムで使用可能なすべてのモジュールのリストを表示します。
4.4.3 YaSTモジュールのコマンドラインパラメータ #
スクリプトでYaST機能をA使用するため、YaSTでは、個々のモジュールにコマンドラインサポートを提供しています。ただし、すべてのモジュールにコマンドラインサポートがあるわけではありません。モジュールの使用可能なオプションを表示するには、次のコマンドを使用します。
>
sudo
yast module_name help
モジュールにコマンドラインサポートがない場合、モジュールはテキストモードで起動され、次のメッセージが表示されます。
This YaST module does not support the command line interface.
以下のセクションでは、コマンドラインサポートがあるすべてのYaSTモジュールと、それらのすべてのコマンドおよび利用可能なオプションについて簡単に説明します。
4.4.3.1 一般的なYaSTモジュールコマンド #
すべてのYaSTモジュールは、以下のコマンドをサポートしています。
- help
モジュールのサポートされているすべてのコマンドを、その説明と共に一覧表示します。
>
sudo
yast lan help- longhelp
help
と同じですが、すべてのコマンドのオプションの詳細なリストとその説明が追加されています。>
sudo
yast lan longhelp- xmlhelp
longhelp
と同じですが、出力はXML文書として構成され、ファイルにリダイレクトされます。>
sudo
yast lan xmlhelp xmlfile=/tmp/yast_lan.xml- interactive
「対話的」モードにします。これにより、
sudo yast
で事前に修正せずにモジュールのコマンドを実行できます。対話的モードを終了するには、exit
を使用します。
4.4.3.2 yast add-on #
指定されたパスから新しいアドオン製品を追加します。
>
sudo
yast add-on http://server.name/directory/Lang-AddOn-CD1/
次のプロトコルを使用して、ソースパスを指定できます:。 http:// ftp:// nfs:// disk:// cd:// または dvd://。
4.4.3.3 yast audit-laf #
Linux監査フレームワークを表示および設定します。詳細については、Book “Security and Hardening Guide”を参照してください。yast audit-laf
は次のコマンドを受け付けます。
- set
オプションを設定します。
>
sudo
yast audit-laf set log_file=/tmp/audit.logすべてのオプションのリストについては、
yast audit-laf set help
を実行してください。- show
オプションの設定を表示します。
>
sudo
yast audit-laf show diskspace space_left: 75 space_left_action: SYSLOG admin_space_left: 50 admin_space_left_action: SUSPEND action_mail_acct: root disk_full_action: SUSPEND disk_error_action: SUSPENDすべてのオプションのリストについては、
yast audit-laf show help
を実行してください。
4.4.3.4 yast dhcp-server #
DHCPサーバを管理し、その設定を行います。yast
dhcp-server
は次のコマンドを受け付けます。
- 無効
DHCPサーバサービスを無効にします。
- enable
DHCPサーバサービスを有効にします。
- ホスト
個々のホストの設定を行います。
- interface
リスンするネットワークインタフェースを指定します。
>
sudo
yast dhcp-server interface current Selected Interfaces: eth0 Other Interfaces: bond0, pbu, eth1すべてのオプションのリストについては、
yast dhcp-server interface help
を実行してください。- options
グローバルDHCPオプションを管理します。すべてのオプションのリストについては、
yast dhcp-server options help
を実行してください。- status
DHCPサービスのステータスを出力します。
- サブネット
DHCPサブネットオプションを管理します。すべてのオプションのリストについては、
yast dhcp-server subnet help
を実行してください。
4.4.3.5 yast dns-server #
DNSサーバの設定を管理します。yast dns-server
は次のコマンドを受け付けます。
- acls
アクセス制御リストの設定を表示します。
>
sudo
yast dns-server acls show ACLs: ----- Name Type Value ---------------------------- any Predefined localips Predefined localnets Predefined none Predefined- dnsrecord
ゾーンリソースレコードを設定します。
>
sudo
yast dnsrecord add zone=example.org query=office.example.org type=NS value=ns3すべてのオプションのリストについては、
yast dns-server dnsrecord help
を実行してください。- forwarders
DNSフォワーダを設定します。
>
sudo
yast dns-server forwarders add ip=10.0.0.100>
sudo
yast dns-server forwarders show [...] Forwarder IP ------------ 10.0.0.100すべてのオプションのリストについては、
yast dns-server forwarders help
を実行してください。- host
「A」とそれに関連する「PTR」レコードを一度に処理します。
>
sudo
yast dns-server host show zone=example.orgすべてのオプションのリストについては、
yast dns-server host help
を実行してください。- ログ
ログ設定を行います。
>
sudo
yast dns-server logging set updates=no transfers=yesすべてのオプションのリストについては、
yast dns-server logging help
を実行してください。- mailserver
ゾーンメールサーバを設定します。
>
sudo
yast dns-server mailserver add zone=example.org mx=mx1 priority=100すべてのオプションのリストについては、
yast dns-server mailserver help
を実行してください。- nameserver
ゾーンネームサーバを設定します。
>
sudo
yast dns-server nameserver add zone=example.com ns=ns1すべてのオプションのリストについては、
yast dns-server nameserver help
を実行してください。- soa
権威の開始点(SOA)レコードを設定します。
>
sudo
yast dns-server soa set zone=example.org serial=2006081623 ttl=2D3H20Sすべてのオプションのリストについては、
yast dns-server soa help
を実行してください。- 起動
DNSサーバサービスを管理します。
>
sudo
yast dns-server startup atbootすべてのオプションのリストについては、
yast dns-server startup help
を実行してください。- transport
ゾーン転送ルールを設定します。すべてのオプションのリストについては、
yast dns-server transport help
を実行してください。- zones
DNSゾーンを管理します。
>
sudo
yast dns-server zones add name=example.org zonetype=masterすべてのオプションのリストについては、
yast dns-server zones help
を実行してください。
4.4.3.6 yast disk #
すべてのディスクまたはパーティションに関する情報を出力します。唯一サポートされているコマンドはlist
であり、その後に次のいずれかのオプションが続きます。
- disks
システム内のすべての設定されているディスクを一覧表示します。
>
sudo
yast disk list disks Device | Size | FS Type | Mount Point | Label | Model ---------+------------+---------+-------------+-------+------------- /dev/sda | 119.24 GiB | | | | SSD 840 /dev/sdb | 60.84 GiB | | | | WD1003FBYX-0- パーティション
システム内のすべてのパーティションを一覧表示します。
>
sudo
yast disk list partitions Device | Size | FS Type | Mount Point | Label | Model ---------------+------------+---------+-------------+-------+------ /dev/sda1 | 1.00 GiB | Ext2 | /boot | | /dev/sdb1 | 1.00 GiB | Swap | swap | | /dev/sdc1 | 698.64 GiB | XFS | /mnt/extra | | /dev/vg00/home | 580.50 GiB | Ext3 | /home | | /dev/vg00/root | 100.00 GiB | Ext3 | / | | [...]
4.4.3.7 yast ftp-server #
FTPサーバ設定を行います。yast ftp-server
は次のオプションを受け付けます。
- SSL、TLS
SSLおよびTLSを介して安全な接続を制御します。SSLオプションは、
vsftpd
のみに対して有効です。>
sudo
yast ftp-server SSL enable>
sudo
yast ftp-server TLS disable- アクセス
アクセス許可を設定します。
>
sudo
yast ftp-server access authen_onlyすべてのオプションのリストについては、
yast ftp-server access help
を実行してください。- anon_access
匿名ユーザのアクセス許可を設定します。
>
sudo
yast ftp-server anon_access can_uploadすべてのオプションのリストについては、
yast ftp-server anon_access help
を実行してください。- anon_dir
匿名ユーザのディレクトリを指定します。ディレクトリはサーバ上にあらかじめ存在している必要があります。
>
sudo
yast ftp-server anon_dir set_anon_dir=/srv/ftpすべてのオプションのリストについては、
yast ftp-server anon_dir help
を実行してください。- chroot
change root(ルート変更)環境(chroot)を制御します。
>
sudo
yast ftp-server chroot enable>
sudo
yast ftp-server chroot disable- idle-time
FTPサーバが現在の接続を終了するまでの最大アイドル時間を分単位で設定します。
>
sudo
yast ftp-server idle-time set_idle_time=15- ログ
ログメッセージをログファイルに保存するかどうかを判断します。
>
sudo
yast ftp-server logging enable>
sudo
yast ftp-server logging disable- max_clients
同時に接続されるクライアントの最大数を指定します。
>
sudo
yast ftp-server max_clients set_max_clients=1500- max_clients_ip
IPを介して同時に接続されるクライアントの最大数を指定します。
>
sudo
yast ftp-server max_clients_ip set_max_clients=20- max_rate_anon
匿名クライアントに許可される最大データ転送速度(KB/秒)を指定します。
>
sudo
yast ftp-server max_rate_anon set_max_rate=10000- max_rate_authen
ローカルに認証されたユーザに許可される最大データ転送速度(KB/秒)を指定します。
>
sudo
yast ftp-server max_rate_authen set_max_rate=10000- port_range
パッシブ接続応答のポート範囲を指定します。
>
sudo
yast ftp-server port_range set_min_port=20000 set_max_port=30000すべてのオプションのリストについては、
yast ftp-server port_range help
を実行してください。- show
FTPサーバ設定を表示します。
- startup
FTPの起動方法を制御します。
>
sudo
yast ftp-server startup atbootすべてのオプションのリストについては、
yast ftp-server startup help
を実行してください。- umask
authenticated:anonymous
ユーザのファイルumaskを指定します。>
sudo
yast ftp-server umask set_umask=177:077- welcome_message
FTPサーバに接続された際に表示するテキストを指定します。
>
sudo
yast ftp-server welcome_message set_message="hello everybody"
4.4.3.8 yast http-server #
HTTPサーバ(Apache2)を設定します。yast http-server
は次のコマンドを受け付けます。
- configure
HTTPサーバのホスト設定を行います。
>
sudo
yast http-server configure host=main servername=www.example.com \ serveradmin=admin@example.comすべてのオプションのリストについては、
yast http-server configure help
を実行してください。
- hosts
仮想ホストを設定します。
>
sudo
yast http-server hosts create servername=www.example.com \ serveradmin=admin@example.com documentroot=/var/wwwすべてのオプションのリストについては、
yast http-server hosts help
を実行してください。
- listen
HTTPサーバがリスンするポートとネットワークアドレスを指定します。
>
sudo
yast http-server listen add=81>
sudo
yast http-server listen list Listen Statements: ================== :80 :81>
sudo
yast http-server delete=80すべてのオプションのリストについては、
yast http-server listen help
を実行してください。
- mode
ウィザードモードを有効または無効にします。
>
sudo
yast http-server mode wizard=on
- modules
Apache2サーバモジュールを制御します。
>
sudo
yast http-server modules enable=php5,rewrite>
sudo
yast http-server modules disable=ssl>
sudo
http-server modules list [...] Enabled rewrite Disabled ssl Enabled php5 [...]
4.4.3.9 yast kdump #
kdump
を設定します。kdump
の詳細については、Book “System Analysis and Tuning Guide”, Chapter 20 “Kexec and Kdump”, Section 20.7 “Basic Kdump configuration”を参照してください。yast kdump
は次のコマンドを受け付けます。
- copykernel
カーネルをダンプディレクトリにコピーします。
- customkernel
カスタムカーネルの名前のkernel_string部分を指定します。この命名規則は
/boot/vmlinu[zx]-kernel_string[.gz]
です。>
sudo
yast kdump customkernel kernel=kdumpすべてのオプションのリストについては、
yast kdump customkernel help
を実行してください。- dumpformat
ダンプカーネルイメージの(圧縮)形式を指定します。使用可能な形式は、「none」、「ELF」、「compressed」または「lzo」です。
>
sudo
yast kdump dumpformat dump_format=ELF- dumplevel
ダンプレベル番号を0~31の範囲で指定します。
>
sudo
yast kdump dumplevel dump_level=24- dumptarget
ダンプイメージの保存先を指定します。
>
sudo
kdump dumptarget target=ssh server=name_server port=22 \ dir=/var/log/dump user=user_nameすべてのオプションのリストについては、
yast kdump dumptarget help
を実行してください。- immediatereboot
Kdumpカーネルにコアを保存した直後に、システムを再起動するかどうかを制御します。
>
sudo
yast kdump immediatereboot enable>
sudo
yast kdump immediatereboot disable- keepolddumps
保持する古いダンプイメージの数を指定します。ダンプイメージをすべて保持するには、ゼロを指定します。
>
sudo
yast kdump keepolddumps no=5- kernelcommandline
kdumpカーネルに渡す必要があるコマンドラインを指定します。
>
sudo
yast kdump kernelcommandline command="ro root=LABEL=/"- kernelcommandlineappend
デフォルトのコマンドライン文字列に追加する必要があるコマンドラインを指定します。
>
sudo
yast kdump kernelcommandlineappend command="ro root=LABEL=/"- notificationcc
通知メッセージのコピーを送信するための電子メールアドレスを指定します。
>
sudo
yast kdump notificationcc email="user1@example.com user2@example.com"- notificationto
通知メッセージを送信するための電子メールアドレスを指定します。
>
sudo
yast kdump notificationto email="user1@example.com user2@example.com"- show
kdump
設定を表示します。>
sudo
yast kdump show Kdump is disabled Dump Level: 31 Dump Format: compressed Dump Target Settings target: file file directory: /var/crash Kdump immediate reboots: Enabled Numbers of old dumps: 5- smtppass
通知メッセージの送信に使用されるプレーンテキストのSMTPパスワードを含むファイルを指定します。
>
sudo
yast kdump smtppass pass=/path/to/file- smtpserver
通知メッセージの送信に使用されるSMTPサーバのホスト名を指定します。
>
sudo
yast kdump smtpserver server=smtp.server.com- smtpuser
通知メッセージの送信に使用されるSMTPユーザ名を指定します。
>
sudo
yast kdump smtpuser user=smtp_user- 起動
起動オプションを有効または無効にします。
>
sudo
yast kdump startup enable alloc_mem=128,256>
sudo
yast kdump startup disable
4.4.3.10 yast keyboard #
仮想コンソールのシステムキーボードを設定します。GNOMEやKDEなどのグラフィカルデスクトップ環境のキーボード設定には影響しません。yast keyboard
は次のコマンドを受け付けます。
- リスト
使用可能なすべてのキーボードレイアウトを一覧表示します。
- set
新しいキーボードレイアウト設定を有効にします。
>
sudo
yast keyboard set layout=czech- 概要
現在のキーボードの設定を表示します。
4.4.3.11 yast lan #
ネットワークカードを設定します。yast lan
は次のコマンドを受け付けます。
- 追加
新しいネットワークカードを設定します。
>
sudo
yast lan add name=vlan50 ethdevice=eth0 bootproto=dhcpすべてのオプションのリストについては、
yast lan add help
を実行してください。- delete
既存のネットワークカードを削除します。
>
sudo
yast lan delete id=0- 編集
既存のネットワークカードの設定を変更します。
>
sudo
yast lan edit id=0 bootproto=dhcp- リスト
ネットワークカードの設定の概要を表示します。
>
sudo
yast lan list id name, bootproto 0 Ethernet Card 0, NONE 1 Network Bridge, DHCP
4.4.3.12 yast language #
システム言語を設定します。yast language
は次のコマンドを受け付けます。
- リスト
使用可能なすべての言語を一覧表示します。
- set
メインのシステム言語と第2言語を指定します。
>
sudo
yast language set lang=cs_CZ languages=en_US,es_ES no_packages
4.4.3.13 yast mail #
メールシステムの設定を表示します。
>
sudo
yast mail summary
4.4.3.14 yast nfs #
NFSクライアントを制御します。yast nfs
は次のコマンドを受け付けます。
- 追加
新しいNFSマウントを追加します。
>
sudo
yast nfs add spec=remote_host:/path/to/nfs/share file=/local/mount/pointすべてのオプションのリストについては、
yast nfs add help
を実行してください。- delete
既存のNFSマウントを削除します。
>
sudo
yast nfs delete spec=remote_host:/path/to/nfs/share file=/local/mount/pointすべてのオプションのリストについては、
yast nfs delete help
を実行してください。- 編集
既存のNFSマウントを変更します。
>
sudo
yast nfs edit spec=remote_host:/path/to/nfs/share \ file=/local/mount/point type=nfs4すべてのオプションのリストについては、
yast nfs edit help
を実行してください。- リスト
既存のNFSマウントを一覧表示します。
>
sudo
yast nfs list Server Remote File System Mount Point Options ---------------------------------------------------------------- nfs.example.com /mnt /nfs/mnt nfs nfs.example.com /home/tux/nfs_share /nfs/tux nfs
4.4.3.15 yast nfs-server #
NFSサーバを設定します。yast nfs-server
は次のコマンドを受け付けます。
- 追加
エクスポートするディレクトリを追加します。
>
sudo
yast nfs-server add mountpoint=/nfs/export hosts=*.allowed_hosts.comすべてのオプションのリストについては、
yast nfs-server add help
を実行してください。- delete
NFSエクスポートからディレクトリを削除します。
>
sudo
yast nfs-server delete mountpoint=/nfs/export- set
NFSサーバの追加パラメータを指定します。
>
sudo
yast nfs-server set enablev4=yes security=yesすべてのオプションのリストについては、
yast nfs-server set help
を実行してください。- start
NFSサーバサービスを起動します。
>
sudo
yast nfs-server start- stop
NFSサーバサービスを停止します。
>
sudo
yast nfs-server stop- 概要
NFSサーバ設定の概要を表示します。
>
sudo
yast nfs-server summary NFS server is enabled NFS Exports * /mnt * /home NFSv4 support is enabled. The NFSv4 domain for idmapping is localdomain. NFS Security using GSS is enabled.
4.4.3.16 yast nis #
NISクライアントを設定します。yast nis
は次のコマンドを受け付けます。
- 構成
NISクライアントのグローバル設定を変更します。
>
sudo
yast nis configure server=nis.example.com broadcast=yesすべてのオプションのリストについては、
yast nis configure help
を実行してください。- 無効
NISクライアントを無効にします。
>
sudo
yast nis disable- enable
マシンをNISクライアントとして有効にします。
>
sudo
yast nis enable server=nis.example.com broadcast=yes automounter=yesすべてのオプションのリストについては、
yast nis enable help
を実行してください。- 検索
特定のドメインで使用可能なNISサーバを表示します。
>
sudo
yast nis find domain=nisdomain.com- 概要
NISクライアントの設定の概要を表示します。
4.4.3.17 yast nis-server #
NISサーバを設定します。yast nis-server
は次のコマンドを受け付けます。
- master (マスタ)
NISマスタサーバを設定します。
>
sudo
yast nis-server master domain=nisdomain.com yppasswd=yesすべてのオプションのリストについては、
yast nis-server master help
を実行してください。- slave (スレーブ)
NISワーカサーバを設定します。
>
sudo
yast nis-server slave domain=nisdomain.com master_ip=10.100.51.65すべてのオプションのリストについては、
yast nis-server slave help
を実行してください。- stop
NISサーバを停止します。
>
sudo
yast nis-server stop- 概要
NISサーバの設定の概要を表示します。
>
sudo
yast nis-server summary
4.4.3.18 yast proxy #
プロキシ設定を行います。yast proxy
は次のコマンドを受け付けます。
- 認証
プロキシの認証オプションを指定します。
>
sudo
yast proxy authentication username=tux password=secretすべてのオプションのリストについては、
yast proxy authentication help
を実行してください。- enable、disable
プロキシ設定を有効または無効にします。
- set
現在のプロキシ設定を変更します。
>
sudo
yast proxy set https=proxy.example.comすべてのオプションのリストについては、
yast proxy set help
を実行してください。- 概要
プロキシ設定を表示します。
4.4.3.19 yast rdp #
リモートデスクトップの設定を制御します。yast rdp
は次のコマンドを受け付けます。
- allow
サーバのデスクトップへのリモートアクセスを許可します。
>
sudo
yast rdp allow set=yes- リスト
リモートデスクトップ設定の概要を表示します。
4.4.3.20 yast samba-client #
Sambaクライアントの設定を行います。yast samba-client
は次のコマンドを受け付けます。
- 構成
Sambaのグローバル設定を変更します。
>
sudo
yast samba-client configure workgroup=FAMILY- isdomainmember
マシンがドメインのメンバーであるかどうかを確認します。
>
sudo
yast samba-client isdomainmember domain=SMB_DOMAIN- joindomain
マシンをドメインのメンバーにします。
>
sudo
yast samba-client joindomain domain=SMB_DOMAIN user=username password=pwd- winbind
Winbindサービス(
winbindd
デーモン)を有効または無効にします。>
sudo
yast samba-client winbind enable>
sudo
yast samba-client winbind disable
4.4.3.21 yast samba-server #
Sambaサーバ設定を行います。yast samba-server
は次のコマンドを受け付けます。
- backend
ユーザ情報を格納するバックエンドを指定します。
>
sudo
yast samba-server backend smbpasswdすべてのオプションのリストについては、
yast samba-server backend help
を実行してください。- 構成
Sambaサーバのグローバル設定を行います。
>
sudo
yast samba-server configure workgroup=FAMILY description='Home server'すべてのオプションのリストについては、
yast samba-server configure help
を実行してください。- リスト
使用できる共有のリストを表示します。
>
sudo
yast samba-server list Status Type Name ============================== Disabled Disk profiles Enabled Disk print$ Enabled Disk homes Disabled Disk groups Enabled Disk movies Enabled Printer printers- role
Sambaサーバの役割を指定します。
>
sudo
yast samba-server role standaloneすべてのオプションのリストについては、
yast samba-server role help
を実行してください。- service
Sambaサービス(
smb
とnmb
)を有効または無効にします。>
sudo
yast samba-server service enable>
sudo
yast samba-server service disable- share
単一のSamba共有を操作します。
>
sudo
yast samba-server share name=movies browseable=yes guest_ok=yesすべてのオプションのリストについては、
yast samba-server share help
を実行してください。
4.4.3.22 yast security #
ホストのセキュリティレベルを制御します。yast security
は次のコマンドを受け付けます。
- level
ホストのセキュリティレベルを指定します。
>
sudo
yast security level serverすべてのオプションのリストについては、
yast security level help
を実行してください。- set
特定のオプションの値を設定します。
>
sudo
yast security set passwd=sha512 crack=yesすべてのオプションのリストについては、
yast security set help
を実行してください。- summary
現在のセキュリティ設定の概要を表示します。
sudo
yast security summary
4.4.3.23 yast sound #
サウンドカードの設定を行います。yast sound
は次のコマンドを受け付けます。
- 追加
新しいサウンドカードを設定します。パラメータを指定しない場合、最初に検出されたカードが追加されます。
>
sudo
yast sound add card=0 volume=75すべてのオプションのリストについては、
yast sound add help
を実行してください。- channels
サウンドカードの使用可能なボリュームチャネルを一覧表示します。
>
sudo
yast sound channels card=0 Master 75 PCM 100- modules
使用可能なすべてのサウンドカーネルモジュールを一覧表示します。
>
sudo
yast sound modules snd-atiixp ATI IXP AC97 controller (snd-atiixp) snd-atiixp-modem ATI IXP MC97 controller (snd-atiixp-modem) snd-virtuoso Asus Virtuoso driver (snd-virtuoso) [...]- playtest
サウンドカードでテストサウンドを再生します。
>
sudo
yast sound playtest card=0- remove
設定されたサウンドカードを削除します。
>
sudo
yast sound remove card=0>
sudo
yast sound remove all- set
サウンドカードの新しい値を指定します。
>
sudo
yast sound set card=0 volume=80- show
サウンドカードに関する詳細情報を表示します。
>
sudo
yast sound show card=0 Parameters of card 'ThinkPad X240' (using module snd-hda-intel): align_buffer_size Force buffer and period sizes to be multiple of 128 bytes. bdl_pos_adj BDL position adjustment offset. beep_mode Select HDA Beep registration mode (0=off, 1=on) (default=1). Default Value: 0 enable_msi Enable Message Signaled Interrupt (MSI) [...]- summary
システム上のすべてのサウンドカードの設定概要を出力します。
>
sudo
yast sound summary- volume
サウンドカードの音量レベルを指定します。
sudo
yast sound volume card=0 play
4.4.3.24 yast sysconfig #
/etc/sysconfig
のファイル内の変数を制御します。yast sysconfig
は次のコマンドを受け付けます。
- クリア
空の値を変数に設定します。
>
sudo
yast sysconfig clear=POSTFIX_LISTENヒント: 複数ファイルの変数変数が複数のファイルで使用可能な場合は、VARIABLE_NAME$FILE_NAME構文を使用します。
>
sudo
yast sysconfig clear=CONFIG_TYPE$/etc/sysconfig/mail- 詳細
変数に関する詳細情報を表示します。
>
sudo
yast sysconfig details variable=POSTFIX_LISTEN Description: Value: File: /etc/sysconfig/postfix Possible Values: Any value Default Value: Configuration Script: postfix Description: Comma separated list of IP's NOTE: If not set, LISTEN on all interfaces- リスト
変更された変数の概要を表示します。
all
を使用して、すべての変数とその値を一覧表示します。>
sudo
yast sysconfig list all AOU_AUTO_AGREE_WITH_LICENSES="false" AOU_ENABLE_CRONJOB="true" AOU_INCLUDE_RECOMMENDS="false" [...]- set
変数の値を設定します。
>
sudo
yast sysconfig set DISPLAYMANAGER=gdmヒント: 複数ファイルの変数変数が複数のファイルで使用可能な場合は、VARIABLE_NAME$FILE_NAME構文を使用します。
>
sudo
yast sysconfig set CONFIG_TYPE$/etc/sysconfig/mail=advanced
4.4.3.25 yast tftp-server #
TFTPサーバを設定します。yast tftp-server
は次のコマンドを受け付けます。
- ディレクトリ
TFTPサーバのディレクトリを指定します。
>
sudo
yast tftp-server directory path=/srv/tftp>
sudo
yast tftp-server directory list Directory Path: /srv/tftp- status
TFTPサーバサービスのステータスを制御します。
>
sudo
yast tftp-server status disable>
sudo
yast tftp-server status show Service Status: false>
sudo
yast tftp-server status enable
4.4.3.26 yast timezone #
タイムゾーンを設定します。yast timezone
は次のコマンドを受け付けます。
- リスト
使用可能なすべてのタイムゾーンを地域別にグループ化して一覧表示します。
>
sudo
yast timezone list Region: Africa Africa/Abidjan (Abidjan) Africa/Accra (Accra) Africa/Addis_Ababa (Addis Ababa) [...]- set
タイムゾーン設定の新しい値を指定します。
>
sudo
yast timezone set timezone=Europe/Prague hwclock=local- 概要
タイムゾーンの設定の概要を表示します。
>
sudo
yast timezone summary Current Time Zone: Europe/Prague Hardware Clock Set To: Local time Current Time and Date: Mon 12. March 2018, 11:36:21 CET
4.4.3.27 yast users #
ユーザアカウントを管理します。yast users
は次のコマンドを受け付けます。
- 追加
新しいユーザを追加します。
>
sudo
yast users add username=user1 password=secret home=/home/user1すべてのオプションのリストについては、
yast users add help
を実行してください。- delete
既存のユーザアカウントを削除します。
>
sudo
yast users delete username=user1 delete_homeすべてのオプションのリストについては、
yast users delete help
を実行してください。- 編集
既存のユーザアカウントを変更します。
>
sudo
yast users edit username=user1 password=new_secretすべてのオプションのリストについては、
yast users edit help
を実行してください。- リスト
ユーザタイプによってフィルタされた既存のユーザを一覧表示します。
>
sudo
yast users list systemすべてのオプションのリストについては、
yast users list help
を実行してください。- show
ユーザに関する詳細を表示します。
>
sudo
yast users show username=wwwrun Full Name: WWW daemon apache List of Groups: www Default Group: wwwrun Home Directory: /var/lib/wwwrun Login Shell: /sbin/nologin Login Name: wwwrun UID: 456すべてのオプションのリストについては、
yast users show help
を実行してください。
5 YaSTによる言語および国の設定の変更 #
この章では、言語および国を設定する方法について説明します。言語は、システム全体でグローバルに、特定のユーザまたはデスクトップで個別に、または単一のアプリケーションで一時的に変更できます。また、第二言語を設定し、日付と国の設定を調整できます。
別の国または多言語環境で作業している場合、その状況に応じてシステムを設定する必要があります。SUSE® Linux Enterprise Serverは、複数のlocales
を並行して扱うことができます。ロケールは、ユーザインタフェースに反映される言語と国を定義するパラメータのセットです。
主要言語はインストール時に選択され、それに応じてキーボードとタイムゾーンの設定が調整されます。ただし、追加言語をインストールしたり、インストールした言語のどれをデフォルトにするか決定することができます。
それらのタスクでは、5.1項 「システム言語の変更」に説明があるYaSTの言語モジュールを使用します。第一言語以外でアプリケーションまたはデスクトップを起動する必要がある場合は、二次言語をインストールしてオプションのローカライズを適用します。
YaSTタイムゾーンモジュールを使用すると、国やタイムゾーンの設定を適宜調整できます。タイムゾーンモジュールでは、タイムサーバとシステムクロックを同期することもできます。詳細については、5.2項 「国および時間の設定の変更」を参照してください。
5.1 システム言語の変更 #
デスクトップを使用する方法や、システム全体を別の言語に切り替えるかデスクトップ環境のみを切り替えるかの指定などに応じて、いくつかのオプションがあります。
- システム言語をグローバルに変更する
5.1.1項 「YaSTでシステムの言語を変更する」および5.1.2項 「デフォルトシステム言語を切り替える」の説明に従って、YaSTで別のローカライズパッケージをインストールし、そのデフォルト言語を設定します。変更は次回ログイン後に有効になります。システム全体で変更を反映するには、システムを再起動するか、またはすべての実行サービス、アプリケーション、およびプログラムを終了して再起動します。
- デスクトップの言語だけを変更する
以下の説明に従ってYaSTを使用してデスクトップ環境に目的の言語パッケージをインストール済みであれば、デスクトップのコントロールセンターを使用してデスクトップの言語を切り替えることができます。Xサーバの再起動後、デスクトップ全体に新たに選択した言語が反映されます。デスクトップフレームワークに属さないアプリケーションでは、この変更が適用されず、YaSTで設定した言語で引き続き表示されることがあります。
- 1つのアプリケーションの言語だけを一時的に切り替える
1つのアプリケーションのみを、YaSTでインストール済みの別の言語で実行することもできます。そのためには、言語コードを指定して、コマンドラインからそのアプリケーションを起動します(5.1.3項 「標準のXアプリケーションとGNOMEアプリケーションでの言語切り替え」参照)。
5.1.1 YaSTでシステムの言語を変更する #
YaSTは、次の2つの異なる言語カテゴリをサポートしています。
YaSTに設定された第一言語は、YaSTおよびデスクトップ環境を含んだ、システム全体に適用されます。この言語は、別の言語を手動で指定しない限り、利用可能な場合に常に使用されます。
第二言語をインストールして、システムを多言語にします。第二言語としてインストールされている言語は、必要に応じて手動で選択できます。たとえば、一定の言語でワープロを行うため、その言語でアプリケーションを起動する場合は、第二言語を使用します。
追加の言語をインストールする前に、インストール後にそれらの中からデフォルトのシステム言語(第一言語)とするものを決めておく必要があります。
YaSTの言語モジュールにアクセスするには、YaSTを起動し、sudo yast2 language &
を実行して、 ダイアログを直接起動することもできます。
追加言語をインストールするときに、YaSTを使用してroot
ユーザにいくつかのロケールを設定できます。ステップ 4を参照してください。/etc/sysconfig/language
ファイルのロケール変数(LC_*
)をroot
に対してどのように設定するかは、 オプションで指定します。それらを通常ユーザ用と同じロケールに設定するか、言語の変更によってまったく影響されないようにするか、または変数RC_LC_CTYPE
だけを通常ユーザ用と同じ値に設定することができます。RC_LC_CTYPE
変数は、言語固有の関数呼び出しのローカライゼーションを設定します。
YaSTの言語モジュールで言語を追加するには、
でインストールする言語を選択します。言語をデフォルト言語にするには、その言語を
として設定します。さらに、新しい第一言語に合わせてキーボードを変更し、必要に応じてタイムゾーンを調整します。
ヒント: 詳細設定高度なキーボード設定を指定するには、YaSTで第32章 「システムのキーボードレイアウト設定」および5.2項 「国および時間の設定の変更」を参照してください。
› の順に選択します。高度なタイムゾーン設定を指定するには、YaSTで › の順に選択します。詳細については、root
ユーザに固有の言語設定を変更するには、 をクリックします。root
に を使用するかどうかを決めます。
ロケールが利用可能な第一言語のリストに含まれていない場合は、
で、そのロケールを指定してください。ただし、特定のロケールが不完全になる場合があります。
これで、システムが多言語になります。ただし、第一言語以外の言語でアプリケーションを起動するには、該当する言語を5.1.3項 「標準のXアプリケーションとGNOMEアプリケーションでの言語切り替え」の説明どおりに明示的に設定する必要があります。
5.1.2 デフォルトシステム言語を切り替える #
デフォルトのシステム言語をグローバルに切り替えるには、次の手順に従います。
YaSTの言語モジュールを起動します。
- 重要: 以前のシステム言語の削除
別の第一言語に切り替えると、以前の第一言語用にローカライズされたソフトウェアパッケージがシステムから削除されます。デフォルトシステム言語を切り替えても、以前の第一言語は追加言語として保持するには、該当するチェックボックスをオンにすることで、以前の第一言語を
として追加できます。 キーボードとタイムゾーンのオプションを適宜調整します。
YaSTによって変更内容が適用された後、現在のXセッションを再起動して(たとえば、いったんログアウトして再度ログインします)、YaSTとデスクトップアプリケーションに新しい言語設定が反映されるようにします。
5.1.3 標準のXアプリケーションとGNOMEアプリケーションでの言語切り替え #
YaSTで各言語をインストールした後、1つのアプリケーションのみを他のアプリケーションとは別の言語で実行できます。
次のコマンドで、アプリケーションをコマンドラインから起動します。
LANG=LANGUAGE application
たとえば、f-spotをドイツ語で起動するには、LANG=de_DE f-spot
を実行します。他の言語については、適切な言語コードを使用します。利用可能なすべての言語コードのリストは、locale
-av
コマンドで取得します。
5.2 国および時間の設定の変更 #
YaSTの日付と時刻モジュールを使用して、システムの日付、時計、およびタイムゾーンの情報を作業地域に合わせて調整します。YaSTのモジュールにアクセスするには、YaSTを起動してsudo yast2 timezone &
を実行して、 ダイアログを直接起動することもできます。
まず、
などの一般的な地域を選択します。作業地と一致する国(たとえば、 )を選択します。ワークステーションで実行されるオペレーティングシステムに応じて、ハードウェアクロックの設定を調整します。
マシン上でMicrosoft Windows*などの別のオペレーティングシステムを実行している場合、システムでは、UTCではなく、ローカルタイムを使用している可能性があります。この場合は、
をオフにします。コンピュータでLinuxだけを実行する場合は、ハードウェアクロックをUTCに設定し、標準時間から夏時間への切り換えを自動的に実行させます。
標準時間からサマータイムへの転換(およびその逆)は、ハードウェアロック(CMOSクロック)がUTCに設定されている場合にのみ、自動的に行われます。この処理は、NTPとの時間の自動同期機能を使用している場合にも実行されます。これは、ハードウェアとシステムクロックの時間差が15分未満であれば、時間の自動同期が機能するからです。
誤ったシステム時間は、深刻な問題の原因になる場合があります(バックアップの失敗、メールメッセージの削除、リモートファイルシステムでの障害の発生など)。ハードウェアのクロックを「常に」UTCに設定することを強くお勧めします。
日付と時刻を手動で変更できるほか、NTPサーバにマシンが永続的に同期できるようにするか、ハードウェアの時刻を調整する目的でのみ同期するかを選択できます。
YaSTのタイムゾーンモジュールで、
をクリックして日付と時刻を設定します。変更内容を確認します。
日付と時刻を変更するには、
をクリックします。まだ入力されていない場合は、NTPサーバのアドレスを入力します。
38.1項 「YaSTでのNTPクライアントの設定」を参照してください。
ボタンをクリックすると、[高度なNTP設定]を開くことができます。詳細については、変更内容を確認します。
6 YaSTによるユーザの管理 #
インストール時にシステム用のローカルユーザを作成できました。YaSTの
モジュールを使用して、ユーザの追加や既存ユーザの編集が可能です。また、ネットワークサーバでユーザを認証するようにシステムを設定できます。6.1 [ユーザとグループの管理]ダイアログ #
ユーザまたはグループを管理するには、YaSTを起動し、sudo
yast2 users &
を実行することにより、 ダイアログを直接起動します。
各ユーザには、システム全体で使用できるユーザID (UID)が割り当てられます。マシンにログインできるユーザ以外にも、内部での使用のみが目的のさまざまな「システムユーザ」が存在します。各ユーザは、1つ以上のグループに割り当てられます。システムユーザと同様に、内部用途のシステムグループも存在します。
メインウィンドウには、表示および変更するために選択するユーザのセット(ローカルユーザ、ネットワークユーザ、システムユーザ)に応じて、いくつかのタブが表示されます。タブでは、次のタスクを実行できます。
- ユーザアカウントの管理
6.2項 「ユーザアカウントの管理」の説明に従って、ユーザアカウントを作成、変更、削除、または一時的に無効にします。6.3項 「ユーザアカウントの追加オプション」では、パスワードポリシーの強制、暗号化したホームディレクトリの使用、ディスククオータの管理などの高度なオプションについて説明しています。
タブから、- デフォルト設定の変更
6.4項 「ローカルユーザのデフォルト設定の変更」では、デフォルトのグループ割り当て、またはホームディレクトリのデフォルトパスおよびアクセス許可を変更する方法を説明します。
タブで定義された設定に応じて、ローカルユーザアカウントが作成されます。- グループへのユーザの割り当て
6.5項 「グループへのユーザの割り当て」では、個別ユーザのグループの割り当てを変更する方法を説明します。
- グループを管理する
6.6項 「グループを管理する」を参照してください。
タブから、既存のグループの追加、変更、または削除を行うことができます。この方法については、- ユーザ認証方法を変更する
コンピュータがNISやLDAPなどのユーザ認証方法を提供するネットワークに接続されている場合は、6.7項 「ユーザ認証方法を変更する」を参照してください。
タブで、認証方法を選択できます。詳細については、
ユーザとグループの管理用に、このダイアログでは同様の機能が提供されます。ダイアログ上部にある適切なタブを選択することにより、ユーザとグループの管理ビューを簡単に切り替えることができます。
[フィルタ]オプションで、変更するユーザまたはグループのセットを定義できます。
または タブで、 をクリックすると、ユーザまたはグループを表示および編集できます。該当する場合、 や などの特定のカテゴリに応じて一覧表示されます。 › で、カスタムフィルタをセットアップおよび使用できます。選択したフィルタに応じて、このダイアログから次のオプションおよび機能がすべて利用できるとは限りません。
6.2 ユーザアカウントの管理 #
YaSTでは、ユーザアカウントの作成、変更、削除、または一時的な無効化が可能です。熟練したユーザか管理者でない限り、ユーザアカウントを変更しないでください。
ファイル所有権はユーザ名ではなくユーザIDにバインドされます。ユーザIDの変更後、この変更に合わせてユーザのホームディレクトリのファイルが自動的に調整されます。ただし、ユーザは、IDの変更後、ファイルシステム内の他の場所で作成したファイルのファイル所有権を失います(それらのファイルの所有権が手動で変更されない限り)。
次の手順は、デフォルトのユーザアカウントの設定方法を示しています。さらに詳細なオプションについては、6.3項 「ユーザアカウントの追加オプション」を参照してください。
YaSTの
ダイアログを開き、 タブをクリックします。既存のユーザに対するオプションを変更するには、エントリを選択し、
をクリックします。新しいユーザアカウントを作成するには、
をクリックします。(ログインで使用される)
および など、最初のタブで適切なユーザデータを入力します。このデータは、新しいユーザを作成するために十分なものです。 をクリックすると、システムによって自動的にユーザIDを割り当てられ、他の値はすべてデフォルトに設定されます。このユーザのメールボックスにシステム通知が配信されるようにする場合は、
を有効にします。これによってroot
のメールエイリアスが作成され、このユーザは最初にroot
としてログインしなくてもシステムメールが読めるようになります。システムサービスにより送信されたメールは、ローカルメールボックス
/var/spool/mail/
USERNAMEに保存されます(USERNAMEは選択されたユーザのログイン名)。電子メールを読むには、mail
コマンドを使用できます。ユーザIDまたはユーザのホームディレクトリへのパスなど、さらに詳細な情報を調整するには、
タブを使用します。既存のユーザのホームディレクトリを再配置する必要がある場合は、新しいホームディレクトリへのパスを入力し、
により現在のホームディレクトリの内容を移動します。ホームディレクトリを再配置する必要がない場合は、既存データが存在しなくても新しいホームディレクトリが作成されます。パスワードを定期的に変更することをユーザに強制するか、他のパスワードオプションを設定するには、6.3.2項 「パスワードポリシーの強制」を参照してください。
に切り替え、オプションを調整します。詳細については、すべてのオプションが希望どおりに設定されたら、
をクリックします。また、
ダイアログを閉じずにすべての変更を保存するには、 › の順にクリックします。
root
アカウントの名前を変更しないでください
技術的にはroot
アカウントの名前を変更することは可能ですが、特定のアプリケーション、スクリプト、またはサードパーティ製品は、root
というユーザの存在に依存する場合があります。このような設定は常に個々の環境を対象としていますが、必要な調整はベンダの更新によって上書きされる可能性があるため、これは1回限りの設定ではなく、継続的なタスクとなります。これは、サードパーティアプリケーションを含む複雑なセットアップの場合に特に当てはまり、root
アカウントの名前変更がサポートされているかどうかを関係するすべてのベンダに確認する必要があります。
root
アカウントの名前変更による影響は予測できないため、SUSEでは、root
アカウントの名前変更はサポートしていません。
通常、root
アカウントの名前を変更するのは、このアカウントを隠したり、予測できないようにしたりするためです。ただし、/etc/passwd
は通常のユーザに644
の許可を要求するため、システムのどのユーザもユーザID 0のログイン名を取得できます。root
アカウントをセキュリティで保護するためのより良い方法については、Book “Security and Hardening Guide”, Chapter 14 “User management”, Section 14.5 “Restricting root
logins”とBook “Security and Hardening Guide”, Chapter 14 “User management”, Section 14.5.3 “Restricting SSH logins”を参照してください。
ネットワーク内でのIDに(ローカル)ユーザIDを一致させると便利です。たとえば、ラップトップの新しい(ローカル)ユーザは、ネットワーク環境に統合する際に同じユーザIDを割り当てる必要があります。これにより、ユーザが「オフライン」で作成するファイルのファイル所有権は、直接ネットワーク上で作成した場合のファイル所有権と同じになります。
YaSTの
ダイアログを開き、 タブをクリックします。ユーザアカウントを削除しないで一時的に無効にするには、リストからユーザを選択し、
をクリックします。 を有効にします。ユーザは、アカウントを再び有効にするまで、マシンにログインできません。ユーザアカウントを削除するには、リストからユーザを選択して、
をクリックします。ユーザのホームディレクトリを削除するか、またはこのデータを保持するかを選択します。
6.3 ユーザアカウントの追加オプション #
SUSE® Linux Enterprise Serverには、デフォルトユーザアカウントの設定のほか、さまざまなオプションも用意されています。たとえば、パスワードポリシーの強制、暗号化したホームディレクトリの使用、ユーザとグループのディスククオータの定義のためのオプションがあります。
6.3.1 自動ログインおよびパスワードレスログイン #
GNOMEデスクトップ環境を使用している場合、特定のユーザには「自動ログイン」を設定し、すべてのユーザに「パスワードなしのログイン」を設定できます。自動ログインでは、ユーザがブート時にデスクトップ環境に自動的にログインします。この機能は、一度に1人のユーザについてのみ有効にできます。パスワードなしのログインでは、どのユーザも、ログインマネージャにユーザ名を入力するだけでシステムにログインできます。
複数のユーザがアクセスできるマシンで自動ログインまたはパスワードレスログインを有効にすることはセキュリティ上のリスクを伴います。どのユーザでもシステムおよびデータにアクセスでき、認証の必要もありません。システムに機密情報などの重要なデータを保管している場合は、この機能は使用しないでください。
自動ログインまたはパスワードなしのログインを有効にするには、
› の順に選択し、YaSTの でこれらの機能にアクセスします。6.3.2 パスワードポリシーの強制 #
複数のユーザが使用するシステムでは、最低限のパスワードセキュリティポリシーを強制することをお勧めします。ユーザに定期的にパスワードを変更させたり、推測しにくいような複雑なパスワードを使用させることができます。ローカルユーザの場合は、次の手順に従います。
YaSTの
ダイアログを開き、 タブを選択します。ユーザを選択し、
をクリックします。次回のログインでパスワードを変更するようにユーザに強制するには、
を有効にします。パスワードのローテーションを強制するには、
および を設定します。期限切れになる前にパスワードを変更するようにユーザに通知するには、
に日数を設定します。パスワードが期限切れになった後ユーザがログインできる期間を制限するには、
の値を変更します。また、アカウント全体の特定の有効期限を指定できます。
をYYYY-MM-DD形式で入力します。これはパスワード関連の設定ではなく、アカウント自体に適用されます。オプションおよびデフォルト値の詳細については、
をクリックしてください。変更内容を反映するには、
をクリックします。
6.3.3 クォータの管理 #
システム容量が通知なく枯渇することのないように、システム管理者はユーザまたはグループに対するクオータを設定できます。クオータは、1つ以上のファイルシステムに対して定義されるもので、これにより使用可能なディスク容量および作成可能なiノード(インデックスノード)の数を制限できます。iノードは、通常のファイル、ディレクトリ、または他のファイルシステムオブジェクトに関する基本的な情報を保存するファイルシステム上のデータ構造です。また、ファイル名とコンテンツを除いて、ファイルシステムオブジェクト(ユーザおよびグループの所有権、読み取り、書き込み、または実行のパーミッションなど)のすべての属性を保存します。
SUSE Linux Enterprise Serverでは、soft
クォータおよびhard
クォータを使用できます。さらに、ユーザまたはグループが特定量まで一時的にクオータを超過できる猶予間隔を定義できます。
- ソフトクォータ
限界に近づいたときにユーザに通知する警告レベルを定義します。管理者は、パーティションのデータのクリーンアップと削減を行うようにユーザに促す場合があります。通常、ソフトクォータの限界値は、ハードクォータの限界値よりも低くなります。
- ハードクォータ
書き込み要求が拒否される限界を定義します。ハードクォータに達すると、それ以上データを格納することができなくなり、アプリケーションがクラッシュする可能性が高くなります。
- Grace period (猶予期間)
ソフトクォータに達してから警告の発行までの時間を定義します。通常、1時間、数時間など小さな値を設定します。
特定のユーザおよびグループにクオータを設定するには、YaSTのエキスパートパーティショナで、対応するパーティションのクォータサポートを有効にしておく必要があります。
Btrfsパーティションのクォータの処理は異なります。詳細については、Book “ストレージ管理ガイド”, Chapter 1 “Linuxファイルシステムの概要”, Section 1.2.5 “サブボリュームに対するBtrfsクォータのサポート”を参照してください。
YaSTで
› の順に選択し、 をクリックして続行します。quota
パッケージがまだインストールされていない場合は、 のクリックで各メッセージを確認することにより、クオータパッケージがインストールされます。変更を確認し、
を終了します。次のコマンドを入力して、
quotaon
サービスが実行されていることを確認してください。>
sudo
systemctl status quotaon.serviceサービスは、
active
としてマークされている必要があります。そうでない場合は、systemctl start quotaon.service
コマンドを使用して開始する必要があります。
これで、特定のユーザまたはグループに対するソフトクオータまたはハードクオータを定義し、猶予間隔を指定できます。
YaSTの
で、クオータの設定対象とするユーザまたはグループを選択し、 をクリックします。さらに、ユーザまたはグループがこのパーティションで持つことができるiノードの数を制限できます。
で、 および を入力します。サイズまたはiノードに対して指定されたソフト制限をユーザまたはグループが既に超過している場合にのみ猶予間隔を定義できます。このソフト制限を超過していない場合、時間に関連するテキストボックスは有効になりません。ユーザまたはグループが上記の制限セットを超過できる期間を指定します。
入力した設定を確認して、
をクリックします。また、
ダイアログを閉じずにすべての変更を保存するには、 › の順にクリックします。
SUSE Linux Enterprise Serverには、repquota
やwarnquota
などのコマンドラインツールも付属しています。システム管理者はこれらのツールを使用してディスク使用量を制限したり、所定のクオータを超過しているユーザに電子メール通知を送信したりすることができます。管理者はまた、quota_nld
を使用することにより、超過したクオータに関するカーネルメッセージをD-BUSに転送できます。詳細については、repquota
、warnquota
、およびquota_nld
のマニュアルページを参照してください。
6.4 ローカルユーザのデフォルト設定の変更 #
新しくローカルユーザを作成する際には、いくつかのデフォルト設定がYaSTで使用されます。これらには、たとえば、ユーザが属するグループ、ユーザのホームディレクトリのアクセスパーミッションなどが含まれます。これらのデフォルト設定値は、必要に応じて変更することができます。
YaSTの
ダイアログを開き、 タブを選択します。新しいユーザが自動的に属するグループを変更するには、
から別のグループを選択します。新しいユーザのホームディレクトリのデフォルトパスとして
/home/USERNAME
を使用しない場合は、 を変更します。新たに作成したホームディレクトリのデフォルトのパーミッションモードを変更するには、Book “Security and Hardening Guide”, Chapter 19 “Access control lists in Linux”および
のumask値を調整します。umaskの詳細については、umask
のマニュアルページを参照してください。それぞれのオプションの詳細については、
をクリックしてください。変更内容を反映するには、
をクリックします。
6.5 グループへのユーザの割り当て #
6.4項 「ローカルユーザのデフォルト設定の変更」を参照してください。
ダイアログの タブからアクセス可能なデフォルト設定に従って、さまざまなグループにローカルユーザが割り当てられます。次に、個別ユーザのグループ割り当てを変更する方法を説明します。新しいユーザに対するデフォルトのグループの割り当てを変更する必要がある場合については、YaSTの
ダイアログを開き、 タブをクリックします。ユーザ、およびユーザが属するグループが一覧にされます。ユーザが属するプライマリグループを変更するには、
をクリックし、リストからグループを選択します。追加のセカンダリグループをユーザに割り当てるには、
のリストで対応するチェックボックスをオンにします。また、
ダイアログを閉じずにすべての変更を保存するには、 › の順にクリックします。
6.6 グループを管理する #
YaSTでは、グループの追加、変更、または削除も容易に実行できます。
YaSTの
ダイアログを開き、 タブをクリックします。新しいグループを追加するには、
をクリックします。既存のグループを変更するには、グループを選択して
をクリックします。次のダイアログで、データを入力または変更します。右のリストでは、グループのメンバーになることができる利用可能なすべてのユーザおよびシステムユーザの概要が表示されます。
新しいグループに既存のユーザを追加するには、選択可能な
のリストで、該当するボックスをオンにして選択します。既存のユーザをグループから削除するには、このボックスをオフにします。また、
ダイアログを閉じずにすべての変更を保存するには、 › の順にクリックします。
グループを削除するには、すべてのグループメンバーを削除する必要があります。グループを削除するには、リストからグループを選択し、
をクリックします。 をクリックして、管理ダイアログを閉じ、変更内容を保存します。また、 ダイアログを閉じずにすべての変更を保存するには、 › の順にクリックします。6.7 ユーザ認証方法を変更する #
マシンがネットワークに接続されている場合は認証方法を変更できます。次のオプションを指定できます。
- NIS
ユーザはネットワーク上のすべてのシステムに対し、1台のNISサーバ上で集中的に管理されます。詳細については、Book “Security and Hardening Guide”, Chapter 3 “Using NIS”を参照してください。
- SSSD
システムセキュリティサービスデーモン(SSSD)は、ユーザデータをローカルにキャッシュすることにより、実際のディレクトリサービスが(一時的に)アクセス不能な場合でもユーザがデータを利用できるようにします。詳細については、Book “Security and Hardening Guide”, Chapter 4 “Setting up authentication clients using YaST”, Section 4.2 “SSSD”を参照してください。
- Samba
SMB認証は、通常、LinuxとWindowsが混在するネットワークで使用されます。詳細については、Book “ストレージ管理ガイド”, Chapter 20 “Samba”を参照してください。
認証方法を変更するには、以下の手順に従ってください。
YaSTの
ダイアログを開きます。認証方法を変更するには、
をクリックし、変更する認証方法を選択します。これにより、YaSTのクライアント設定モジュールに直接切り替わります。適切なクライアントの設定について詳細は、次のセクションを参照してください。NIS: Book “Security and Hardening Guide”, Chapter 3 “Using NIS”, Section 3.2 “Configuring NIS clients”
LDAP: Book “Security and Hardening Guide”, Chapter 4 “Setting up authentication clients using YaST”, Section 4.1 “Configuring an authentication client with YaST”
Samba: Book “ストレージ管理ガイド”, Chapter 20 “Samba”, Section 20.5.1 “YaSTによるSambaクライアントの設定”
SSSD: Book “Security and Hardening Guide”, Chapter 4 “Setting up authentication clients using YaST”, Section 4.2 “SSSD”
この設定を確認した後、
の概要に戻ります。
6.8 デフォルトのシステムユーザ #
デフォルトでは、SUSE Linux Enterprise Serverに削除できないユーザ名が作成されます。これらのユーザは通常、Linux Standard Baseで定義されます。次のリストに、一般的なユーザ名とその目的を示します。
bin
,daemon
レガシアプリケーションとの互換性を維持するために用意されているレガシユーザ。新しいアプリケーションではこのユーザ名を使用しないでください。
gdm
グラフィカルログインを提供したり、ローカル表示とリモート表示を管理したりするために、GNOMEディスプレイマネージャ(GDM)によって使用されています。
lp
CUPS (Common Unix Printing System)用にプリンタデーモンによって使用されています。
mail
sendmail
やpostfix
などの、ユーザ用に予約されたメーラープログラム。man
manページへのアクセスに使用されています。
messagebus
プロセス間通信用のソフトウェアバスであるD-Bus (デスクトップバス)へのアクセスに使用されています。デーモンは
dbus-daemon
です。nobody
ファイルを所有せず権限付きグループに属していないユーザ。Linux Standard Baseは、デーモンごとに別個のユーザアカウントを設定することを推奨しているため、現在ではあまり使用されていません。
nscd
ネームサービスキャッシュデーモンによって使用されています。このデーモンは、NISとLDAPのパフォーマンスを向上させる参照サービスです。デーモンは
nscd
です。polkitd
PolicyKit認可フレームワークによって使用されています。このフレームワークは、権限のないプロセスの認可要求を処理します。デーモンは
polkitd
です。postfix
Postfixメーラーによって使用されています。
pulse
Pulseaudioサウンドサーバによって使用されています。
root
適切なすべての権限を付与するシステム管理者が使用しています。
rpc
RPCポートマッパーである
rpcbind
コマンドによって使用されています。rtkit
リアルタイムスケジューリングモード用のD-Busシステムサービスを提供するrtkitパッケージによって使用されています。
salt
Saltが提供しているパラレルリモート実行用のユーザ。デーモンの名前は
salt-master
です。scard
スマートカードとそのリーダーとの通信を行うユーザ。デーモンの名前は
pcscd
です。srvGeoClue
位置情報を提供するためにGeoClue D-Busサービスによって使用されています。
sshd
セキュアでないネットワーク上で暗号化されたセキュアな通信を確保するためにSecure Shellデーモン(SSH)によって使用されています。
statd
ネットワークステータスモニタ(NSM)プロトコルによって使用されています。再起動通知をリッスンするために
rpc.statd
デーモンで実装されます。systemd-coredump
コアダンプを取得、保存、および処理するために
/usr/lib/systemd/systemd-coredump
コマンドによって使用されています。systemd-timesync
リモートのネットワークタイムプロトコル(NTP)サーバとローカルシステムクロックを同期させるために
/usr/lib/systemd/systemd-timesyncd
コマンドによって使用されています。
6.9 デフォルトのシステムグループ #
デフォルトで、SLEはシステムサービスで使用される複数のユーザグループを作成します。次のリストは、必須および一般的なオプショングループの例を示しています。
root
すべての特権を持つ管理グループ。
bin
レガシアプリケーションとの互換性を維持するために用意されています。新しいアプリケーションでは、このグループを使用しないでください。
daemon
以前は、デーモンのシステムへのアクセスを制限するために使用されていました。現在は、デーモンが互いに分離するように独自のUID/GIDで実行される必要があります。
audio
オーディオデバイスの特権。
gdm
GNOMEディスプレイマネージャの特権。
chrony
時間同期サービスの特権。
kvm
QEMUマシンエミュレータツールキットの特権。
libvirt
仮想スタックの特権。
lp
プリンタ運用の特権。
mail
メールサービスの特権。
man
マニュアルページと
man
コマンドに固有の特権。sshd
SSH通信プロトコルデーモンの特権。
7 YaSTオンラインアップデート #
SUSEはお買い上げの製品に対し、継続的にソフトウェアセキュリティのアップデートを提供します。デフォルトでは、システムを最新の状態に維持するために更新アプレットが使用されます。アップデートアプレットの詳細については、8.5項 「GNOMEパッケージアップデータ」を参照してください。この章では、ソフトウェアパッケージをアップデートする代替ツールとして、YaSTオンラインアップデートを紹介します。
SUSE® Linux Enterprise Serverの現在のパッチは、アップデートソフトウェアリポジトリから入手できます。インストール時に製品を登録した場合、アップデートリポジトリはすでに設定されています。SUSE Linux Enterprise Serverを登録していない場合は、YaSTで を起動して登録できます。または、信頼できるソースから、手動でアップデートリポジトリを追加することもできます。リポジトリを追加または削除するには、YaSTで、 › の順に選択して、リポジトリマネージャを起動します。リポジトリマネージャの詳細については、8.4項 「ソフトウェアリポジトリおよびサービスの管理」を参照してください。
アップデートカタログにアクセスできない場合、登録の期限が切れている場合があります。通常、SUSE Linux Enterprise Serverには1年または3年の登録期間があり、この期間内はアップデートカタログにアクセスできます。このアクセスは登録期間が切れると拒否されます。
アップデートカタログへのアクセスが拒否される場合は、SUSE Customer Centerにアクセスして登録を確認することを推奨する警告メッセージが表示されます。SUSEカスタマーセンターには、https://scc.suse.com//でアクセスできます。
デフォルトでは、SUSE Linux Enterprise Serverのファイアウォールは着信接続のみをブロックします。お使いのシステムが発信トラフィックをブロックする別のファイアウォールの背後にある場合は、更新を受信するために、ポート80と443でhttps://scc.suse.com/
とhttps://updates.suse.com
への接続を許可していることを確認してください。
SUSEは、各種の関連性レベルを持つアップデートを提供します。
- セキュリティアップデート
セキュリティアップデートは、重大なセキュリティハザードを修復するので、必ずインストールする必要があります。
- 推奨アップデート
コンピュータに損害を与える可能性のある問題を修復します。
- オプションアップデート
セキュリティに関連しない問題を修復したり、拡張機能を提供します。
7.1 オンライン更新ダイアログ #
yast2 online_update
を実行して、このモジュールを開始することもできます。
ウィンドウは、4つのセクションから成り立っています。
左側のSUSE Linux Enterprise Serverの使用可能なパッチが一覧にされます。パッチはセキュリティ重要度順にソートされています: security
、recommended
、およびoptional
。 セクションのビューは、 から、以下のオプションの1つを選択することによって変更できます。
- (デフォルトビュー)
システムにインストールされたパッケージに適用される、インストールされなかったパッチ。
システムにインストールされていないパッケージに適用されるパッチか、または(該当するセキュリティがすでに別のソースで更新されたので)要件がすでに満たされているパッチ。
SUSE Linux Enterprise Serverで使用可能なすべてのパッチ。
Shift–F1を押してください。Security
パッチおよびRecommended
パッチで要求されるアクションは、自動的に設定されます。アクションは、 、 、および です。
アップデートリポジトリ以外のリポジトリから最新のパッケージをインストールする場合、そのパッケージのパッチ要件はそのインストールで満たされる場合があります。この場合、パッチ概要の前にチェックマークが表示されます。パッチは、インストール用にマークするまでリストに表示されます。これによってパッチはインストールされませんが(パッチはすでに最新であるため)、インストール済みとしてパッチをマークします。
セクションでエントリを選択すると、ダイアログの左下隅に短い が表示されます。左上のセクションには、選択されたパッチに含まれているパッケージが一覧されます(パッチは複数のパッケージから成ることがあります)。右上のセクションでエントリをクリックすると、パッチに含まれている各パッケージの詳細が表示されます。
7.2 パッチのインストール #
YaSTオンラインアップデートのダイアログでは、すべての利用可能なパッチを一度にインストールしたり、システムに適用したいパッチを手動で選択したりできます。システムに適用済みのパッチを元に戻すこともできます。
デフォルトでは、お使いのシステムで現在使用できる新しいパッチ(ただし、optional
以外) はすべて、すでにインストール用にマークされています。 または をクリックすると、これらのパッチが自動的に適用されます。1つまたは複数のパッチでシステムの再起動が必要な場合、パッチのインストールが開始される前にその旨が通知されます。選択したパッチのインストールを続行し、再起動が必要なすべてのパッチのインストールをスキップしてして残りをインストールするか、パッチの手動選択に戻ることを決定できます。
YaSTを起動して、
› の順に選択します。システムで現在使用可能なすべての新しいパッチ(ただし、
optional
以外)を自動的に適用するには、 または をクリックします。まず、適用したいパッチの選択を変更します。
インタフェースが提供する各フィルタとビューを使用します。詳細については、7.1項 「オンライン更新ダイアログ」を参照してください。
ニーズと好みに従ってパッチを選択または選択解除するには、パッチを右クリックしてコンテキストメニューから各アクションを選択します。
重要: セキュリティアップデートは必ず適用する十分な理由がない限り、
security
関係のパッチは選択解除しないでください。これらのパッチは、重大なセキュリティハザードを修復し、システムの悪用を防ぎます。大部分のパッチには、複数のパッケージのアップデートが含まれています。単一パッケージに対するアクションを変更するには、パッケージビューでパッケージを右クリックしてアクションを選択します。
選択内容を確認し、選択したパッチを適用するには、
または をクリックして続行します。
インストールの完了後、
をクリックして、YaSTの を終了します。これで、システムは最新の状態になりました。
7.3 撤回されたパッチの表示 #
バグが発生するリスクを最小限に抑えるために、保守アップデートは慎重にテストされます。パッチにバグが含まれていることが判明した場合、パッチは自動的に撤回されます。バグのあるパッチを元に戻すために(バージョン番号が高い)新しいアップデートが発行され、再度インストールされないようにブロックされます。撤回されたパッチおよびその履歴は
タブで確認できます。7.4 自動オンラインアップデート #
YaSTを使用して、毎日、毎週、または毎月のスケジュールで自動アップデートを設定できます。yast2-online-update-configuration
パッケージをインストールします。
デフォルトでは、アップデートは、デルタRPMとしてダウンロードされます。デルタRPMからのRPMパッケージの再構築は、メモリとプロセッサを集中的に使用するので、セットアップまたはハードウェア構成によっては、パフォーマンス上の理由によりデルタRPMの使用を無効にする必要があります。
特定のパッチ(カーネルのアップデートやライセンス契約を必要とするパッケージなど)ではユーザによる操作が必要で、これによって自動アップデート手順が停止します。ユーザによる操作が必要なパッチをスキップするよう設定できます。
YaST
モジュールの タブを使用して、バグレポートやCVE掲示への参照を含む、使用可能なパッチ、インストール済みのパッチを確認できます。インストール後、YaSTを起動し、yast2-online-update-configurationがインストールされていない場合、インストールするように求められます。
› の順に選択します。 › の順に選択します。図 7.3: YaSTオンライン更新設定 #または、コマンドラインから、
yast2 online_update_configuration
を使用してモジュールを起動します。更新間隔として
、 、または を選択します。パッチで重要なサービスを再起動する際などに、管理者の注意が必要な場合があります。たとえば、すべてのコンテナの再起動が必要なDocker Open Source Engineのアップデートの場合などです。これらのパッチをインストールする前に、ユーザはその結果について知らされ、パッチのインストールの確認を求められます。このようなパッチは「対話操作が必要な修正」と呼ばれます。
パッチを自動的にインストールする場合は、対話操作が必要な修正のインストールを了承しているとみなされます。インストールする前にこれらのパッチを確認する場合は、
を選択します。この場合、自動的なパッチ適用中に対話操作が必要な修正は飛ばされます。手動オンラインアップデートを定期的に行って、対話操作が必要な修正がインストールを待機しているかどうかを確認します。ライセンス契約を自動的に受諾するには、
を有効にします。アップデートパッケージによって推奨されるすべてのパッケージを自動的にインストールするには、
を有効にします。デルタRPMの使用を無効にするには(パフォーマンス上の理由)、
を無効にします。セキュリティや推奨など、カテゴリ別にパッチをフィルタリングするには、
を有効にしてリストから適切なカテゴリを追加します。選択したカテゴリのパッチのみがインストールされます。自動的に アップデートのみを有効にして、その他すべてを手動で確認することをお勧めします。パッチの適用は通常は信頼できますが、セキュリティ以外のパッチをテストし、問題がある場合はロールバックすることもできます。では、パッケージ管理および、YaST機能とモジュール用のパッチを提供します。
パッチでは、重要なアップデートとバグ修正を提供します。
パッチは、オプションのバグ修正と拡張です。
は新しいパッケージです。
はその他に相当します。
は使用されていません。
自動オンラインアップデートでは、システムは後で自動的には再起動されません。システムの再起動が必要なシステムの更新がある場合は、手動で再起動する必要があります。
8 ソフトウェアをインストールまたは削除する #
YaSTのソフトウェア管理モジュールを使用すると、ソフトウェアパッケージを検索したり、インストールしたり削除したりできます。パッケージをインストールするとき、YaSTは、すべての依存関係を自動的に解決します。インストールメディアにないパッケージをインストールするには、ソフトウェアリポジトリとYaSTを追加して管理できます。アップデートアプレットを使用してソフトウェアアップデートを管理することによって、システムを最新に保つこともできます。
YaSTソフトウェアマネージャを使用すると、システム上でソフトウェアソースを管理できます。このYaSTモジュールには2つのバージョン(X Window用のグラフィックバージョンとコマンドラインで使用するテキストベースバージョン)があります。以下ではグラフィックバージョンについて説明します。テキストベースのYaSTについては第4章 「テキストモードのYaST」を参照してください。
パッケージのインストール、更新、または削除を行う場合、ソフトウェアマネージャでの変更は、
または で確認後にだけ適用されます。YaSTでは、すべてのアクションを記録したリストが保持されているので、変更内容をシステムに適用する前に、それらを確認し、必要に応じて変更できます。8.1 用語の定義 #
SUSE Linux Enterprise Serverでのソフトウェアのインストールと削除に精通するには、次の用語を理解しておく必要があります。
- リポジトリ
パッケージとそのパッケージに関する追加情報(パッケージメタデータ)を保存しているローカルディレクトリまたはリモートディレクトリ。
- (リポジトリの)エイリアス/リポジトリ名
リポジトリの短い名前(Zypperでは
Alias
と呼び、YaSTでは と呼びます)。これは、リポジトリを追加するときにユーザが選択できますが、固有の名前とする必要があります。- リポジトリ記述ファイル
各リポジトリは、リポジトリのコンテンツ(パッケージ名、バージョンなど)を説明したファイルを提供します。これらのリポジトリ記述ファイルは、YaSTで使用するローカルキャッシュにダウンロードされます。
- 製品
SUSE® Linux Enterprise Serverなどの製品全体を指します。
- パターン
パターンは、特定の用途専用に設計されたパッケージのインストール可能なグループです。たとえば、
Laptop
パターンには、モバイルコンピューティング環境で必要なすべてのパッケージが含まれています。パターンは、パッケージ依存関係を定義し(必須パッケージや推奨パッケージなど)、インストール用としてマークされたパッケージが事前選択されている状態で提供されます。これによって、特定の用途に必要な最も重要なパッケージが、パターンのインストール後にシステムで使用可能になります。パターン内のパッケージは、必要に応じて手動で選択または選択解除できます。- Package
パッケージは、
rpm
形式の圧縮ファイルであり、特定のプログラムのファイルを含んでいます。- パッチ
パッチは、1つ以上のパッケージから成り、デルタRPMで適用できます。また、まだインストールされていないパッケージへの依存関係を導入することもあります。
- 解決可能
製品、パターン、パッケージ、またはパッチに関する一般的な用語。最も一般に使用される解決可能なタイプは、パッケージまたはパッチです。
- デルタRPM
デルタRPMは、パッケージに定義された2つのバージョンどうしのバイナリ差分のみで構成されているので、ダウンロードサイズが最小限ですみます。インストールの前に、RPMのフルパッケージがローカルコンピュータ上で再構築されます。
- パッケージの依存関係
一定のパッケージは、共有ライブラリなどの他のパッケージに依存しています。言い換えれば、パッケージの中には、他のパッケージを
require
としているものがあります。このようなパッケージは、必須パッケージがないとインストールできません。満たす必要のある依存関係(パッケージ要件)に加えて、特定のパッケージは、他のパッケージをrecommend
にします。これらの推奨されているパッケージは、利用できる場合にのみインストールされます。利用できない場合は無視されますが、それらを推奨パッケージとしているパッケージはインストールできます。
8.2 インストール済みシステムの登録 #
インストール時に登録を飛ばした場合やシステムの再登録が必要な場合、いつでもシステム登録を行えます。その際には、YaSTモジュール[製品の登録]を使用するか、コマンドラインツールSUSEConnect
を使用します。
8.2.1 YaSTでの登録 #
システムを登録するには、YaSTを起動して
に切り替え、 を選択します。デフォルトでは、SUSE Customer Centerにシステムを登録します。組織でローカル登録サーバが提供されている場合は、自動検出されたサーバのリストからいずれかのサーバを選択できます。または、手動でURLを指定してください。
8.2.2 SUSEConnectを使用した登録 #
コマンドラインから登録するには、次のコマンドを使用します。
>
sudo
SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS
REGISTRATION_CODEは、SUSE Linux Enterprise Serverと一緒に受け取った登録コードで置き換えます。EMAIL_ADDRESSは、各自または各自の組織が登録の管理に使用しているSUSEアカウントに関連付けられたEメールアドレスで置き換えます。
ローカル登録サーバで登録するには、次のようにサーバへのURLも入力します。
>
sudo
SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS --url "URL"
8.3 YaSTソフトウェアマネージャの使用 #
› の順に選択して、 からソフトウェアマネージャを起動します。
8.3.1 ソフトウェアの検索 #
YaSTソフトウェアマネージャでは、現在有効になっているすべてのリポジトリからパッケージやパターンをインストールできます。このソフトウェアマネージャは、検索対象のソフトウェアの検出を容易にするさまざまな表示とフィルタを提供します。
ビューは、ウィンドウのデフォルト表示です。ビューを変更するには、 をクリックし、以下のいずれかのエントリをドロップダウンボックスで選択します。選択した表示が新しいタブで開きます。システム上のインストールに使用できるすべてのパターンを一覧します。
グループ別にソートしたすべてのパッケージを一覧します(
、 、 など)。新しいシステム言語の追加に必要なすべてのパッケージを抽出するフィルタ。
リポジトリ別にパッケージを抽出するフィルタ。複数のリポジトリを選択するには、Ctrlキーを押しながらリポジトリ名をクリックします。「擬似リポジトリ」 を選択すると、現在インストールされているすべてのパッケージが一覧されます。
特定のモジュールまたは拡張機能に属するパッケージを表示します。エントリ(たとえば、
Basesystem
またはHigh Availability
)を選択して、このモジュールまたは拡張機能に属するパッケージのリストを表示します。特定の基準に従って、パッケージを検索できます。検索する用語を入力し、Enterを押します。 で場所を指定し、 を変更することにより、検索を絞り込みます。たとえば、パッケージ名は知らないが、検索するアプリケーションの名前だけは知っている場合は、検索プロセスにパッケージの を含めるようにします。
インストール、更新、または削除するパッケージをすでに選択している場合は、このビューに、Shift–F1を押します。
をクリックするとシステムに適用される変更が表示されます。このビューで特定の状態にあるパッケージをフィルタするには、各チェックボックスを選択または選択解除します。ステータスフラグの詳細を表示するには
アクティブリポジトリに属さないすべてのパッケージを一覧するには、
› › の順に選択し、次に、 › の順に選択します。たとえば、リポジトリを削除した後で、そのリポジトリから取得したパッケージがインストールされたまま残っていないことを確認する場合に、このオプションが役立ちます。オンライン検索機能を使用すると、すべての登録済み/未登録モジュールおよび拡張機能にわたってパッケージを検索できます。
オンラインでソフトウェアパッケージを検索するには、次の手順に従ってください。
Enterを押すか、 をクリックします。YaSTはSUSE Customer Centerに接続し、各パッケージのモジュールまたは拡張機能を含む結果をテーブルに示します。詳細を確認するには、パッケージを選択します。
を入力し、対応するテーブル行をクリックして、
を行い、インストール用の1つ以上のパッケージを選択します。または、テーブル行をダブルクリックすることもできます。パッケージが未登録のモジュールまたは拡張機能に属する場合は、YaSTが登録するかどうか確認します。
8.3.2 パッケージまたはパターンのインストールと削除 #
一定のパッケージは、共有ライブラリなどの他のパッケージに依存しています。いくつかのパッケージは、システム上で他のパッケージと共存できません。これらの依存関係や競合の解決が可能な場合は、YaSTによって自動的に解決されます。選択によって、自動的に解決できない依存関係の競合が発生した場合は、8.3.4項 「パッケージの依存関係」の説明に従って、競合を手動で解決する必要があります。
パッケージを削除する場合、デフォルトでは、選択したパッケージのみが削除されます。指定したパッケージの削除に伴って不要になる他のすべてのパッケージもYaSTで削除できるようにするには、メインメニューで
› の順に選択します。パッケージを検索します(8.3.1項 「ソフトウェアの検索」参照)。
検出されたパッケージは、右側のペインに一覧されます。パッケージをインストールまたは削除するには、パッケージを右クリックして、Shift–F1を押してヘルプを表示します。
または を選択します。該当するオプションがない場合は、パッケージ名の先頭に表示された記号で示されているパッケージステータスを確認し、ヒント: 一覧表示されたすべてのパッケージにアクションを適用する方法右ペインに一覧表示されたすべてのパッケージにアクションを適用するには、メインメニューに移動し、
› の順に選択してアクションを選択します。パターンをインストールするには、パターン名を右クリックして、
を選択します。パターンを削除することはできません。代わりに、削除したいパターンのパッケージを選択し、それらを削除用にマークします。
さらにパッケージを選択するには、上記の手順を繰り返します。
変更を適用する前に、
› の順にクリックすると、変更内容をレビューまたは変更できます。デフォルトでは、ステータスを変更するすべてのパッケージが一覧にされます。パッケージの状態を元に戻すには、パッケージを右クリックし、次のエントリの1つを選択します。つまり、パッケージの削除または更新が予定されている場合は
を選択し、パッケージのインストールが予定されている場合は を選択します。すべての変更を破棄し、ソフトウェアマネージャを終了するには、 と をクリックします。完了したら、
をクリックして、変更を適用します。YaSTが追加の依存関係を検出すると、インストール、更新または削除する関連パッケージのリストが表示されます。
をクリックして、それらを受け入れます。選択されているすべてのパッケージのインストール、更新、または削除が完了すると、YaSTソフトウェアマネージャが自動的に終了します。
現時点では、YaSTソフトウェアマネージャを使用してソースパッケージをインストールすることはできません。このためには、コマンドラインツールzypper
を使用します。詳細については、9.1.3.5項 「ソースパッケージのインストールまたはダウンロード」を参照してください。
8.3.3 パッケージの更新 #
個々のパッケージを更新する代わりに、インストールされているすべてのパッケージまたは特定リポジトリのすべてのパッケージを更新することもできます。パッケージの大量更新時には、一般に、次の側面を考慮します:
パッケージを提供するリポジトリの優先順位、
パッケージのアーキテクチャ(たとえば、AMD64/Intel 64)、
パッケージのバージョン番号、
パッケージのベンダ。
更新の候補を選択する上でどの側面が最も重要であるかは、選択する個々の更新オプションに依存します。
インストール済みのすべてのパッケージを最新バージョンに更新するには、メインメニューから、
› › の順に選択します。一定のポリシーを使用して、使用できる更新候補がないかどうか、すべてのリポジトリがチェックされます。このポリシーでは、まずYaSTによる検索範囲を、インストール済みのパッケージと同じアーキテクチャおよびベンダのパッケージに限定します。検索でパッケージが見つかると、以下のプロセスに従って、見つかったパッケージから「最良の」更新候補が選択されます。ただし、同じベンダの同類のパッケージが見つからない場合は、同じアーキテクチャのすべてのパッケージに検索が拡大されます。それでも同類のパッケージが見つからない場合は、すべてのパッケージが対象となり、次の基準に従って、「最良の」更新候補が選択されます。
リポジトリの優先度: 最高の優先度をもつリポジトリからのパッケージを優先します。
この基準で複数のパッケージが選択された場合は、アーキテクチャが「最良」であるパッケージが選択されます。(最良のアーキテクチャとは、インストール済みパッケージのアーキテクチャと同一のアーキテクチャです)。
選択したパッケージのバージョンがインストール済みパッケージのバージョン番号より高い場合は、インストール済みパッケージが選択した更新候補で更新および置換されます。
このオプションでは、インストール済みパッケージのアーキテクチャとベンダを変更しないようにしていますが、特定の条件下では、それらは許容されます。
注記: 強制的に更新する代わりに、
› › の順に選択すると、適用される基準は同じですが、検出された候補パッケージは無条件でインストールされます。したがって、このオプションを選択すると、特定のパッケージがダウングレードする場合があります。大量更新用パッケージを特定のリポジトリからのパッケージにするには:
8.3.1項 「ソフトウェアの検索」の説明に従って、更新に使用するリポジトリを選択します。
ウィンドウの右側で、
をクリックします。この設定は、パッケージを入れ替えるときにパッケージベンダを変更することをYaSTに対して明示的に許可します。これを回避するには、
をクリックします。このキャンセルは、 ボタンをクリックする前にしかできません。
変更を適用する前に、
› の順にクリックすると、変更内容をレビューまたは変更できます。デフォルトでは、ステータスを変更するすべてのパッケージが一覧されます。すべてのオプションを好みどおりに設定したら、
で変更内容を確認して大量更新を開始します。
8.3.4 パッケージの依存関係 #
ほとんどのパッケージは、他のパッケージに依存しています。たとえば、共有ライブラリを使用するパッケージは、そのライブラリを提供するパッケージに依存します。共存できない特定のパッケージは、競合を引き起こします。たとえば、メール転送エージェント(sendmailまたはpostfix)は、1つしかインストールできません。ソフトウェアのインストールまたは削除時には、ソフトウェアマネージャが未解決のままの依存関係や競合が残っていないことを確認してシステムの整合性を確保します。
依存関係や競合の解決に1つのソリューションしかない場合は、その依存関係や競合は自動的に解決されます。複数のソリューションがあると必ず、手動で解決する必要のある競合が発生します。競合の解決にベンダやアーキテクチャの変更が必要な場合も、手動で解決する必要があります。
をクリックして、ソフトウェアマネージャで変更を適用すると、自動リゾルバでトリガされたすべてのアクションの概要が表示され、確認を要求されます。依存関係は、デフォルトで、自動的にチェックされます。パッケージのステータスを変更するたびに(たとえば、パッケージをインストールまたは削除用にマークする)、チェックが実行されます。これは、一般的には便利ですが、依存関係の競合を手動で解決する際にはわずらわしくなることがあります。この機能を無効にするには、メインメニューに移動して
› の選択を無効にします。依存関係の確認は、 › の順に選択して手動で実行します。整合性の確認は、 をクリックして選択を確定すると、必ず実行されます。パッケージの依存関係をレビューするには、パッケージを右クリックし、
を選択します。依存関係を示すマップが開きます。すでにインストールされているパッケージは、緑の枠内に表示されます。競合の処理に精通していない限り、パッケージの競合を処理する場合は、YaSTによる指示に従うようにします。そうしないと、競合を解決できないことがあります。行った変更はいずれも他の競合をトリガする可能性があり、結局、競合の数は確実に増加することに留意してください。このようになった場合は、
でソフトウェアマネージャをキャンセルし、すべての変更を で破棄して、やり直します。8.3.5 推奨パッケージの取り扱い #
パッケージには、プログラムの実行に必須の、強い依存関係(特定のライブラリなど)だけでなく、新しい機能や変換の追加など、弱い依存関係もあります。このような弱い依存関係を推奨パッケージと呼びます。
新しいパッケージをインストールする場合、推奨されるパッケージはデフォルトでインストールされます。既存のパッケージを更新する場合、不足している推奨事項は自動的にインストールされません。これを変更するには、/etc/sysconfig/yast2
でPKGMGR_RECOMMENDED="yes"
を設定します。インストール済みのパッケージに関する推奨パッケージが欠落している場合、それらすべてをインストールするには、 › を開始し、 › を選択します。
新規パッケージのインストール時の推奨パッケージのインストールを無効にするには、YaST Software Managerで、--no-recommends.
オプションを使用します。
8.4 ソフトウェアリポジトリおよびサービスの管理 #
サードパーティソフトウェアをインストールするには、ソフトウェアリポジトリをシステムに追加します。デフォルトでは、システムを登録すると、SUSE Linux Enterprise Server-DVD 15 SP6や一致するアップデートリポジトリなどの製品リポジトリが自動的に設定されます。登録の詳細については、Book “展開ガイド”, Chapter 9 “インストール手順”, Section 9.7 “登録”またはBook “アップグレードガイド”, Chapter 4 “オフラインでのアップグレード”, Section 4.8 “システムの登録”を参照してください。最初に選択した製品によっては、変換、辞書などを含んだ追加リポジトリも設定できます。
リポジトリを管理するには、YaSTを起動し、
› の順に選択します。 ダイアログが開きます。ここで、ダイアログの右隅にある を に変更することによって、 の購読を管理することもできます。このコンテキストではサービスは、1つまたは複数のソフトウェアを提供できる (RIS) です。この種のサービスは管理者またはベンダから動的に変更できます。各リポジトリは、リポジトリコンテンツ(パッケージ名、バージョンなど)を説明したファイルを提供します。YaSTは、これらのリポジトリ説明ファイルをローカルキャッシュにダウンロードします。ソフトウェアリポジトリには、その整合性確認のため、リポジトリメンテナのGPGキーで署名することができます。新しいリポジトリを追加するたびに、YaSTでリポジトリのキーをインポートできます。
外部ソフトウェアのリポジトリをリポジトリリストに追加する場合は、その前に、リポジトリを信頼できるかどうか確認してください。SUSEは、サードパーティのソフトウェアリポジトリからインストールされたソフトウェアによって発生するどのような問題についても、責任を負いません。
8.4.1 ソフトウェアリポジトリの追加 #
DVD/CD、USBフラッシュドライブ、ローカルディレクトリ、ISOイメージ、またはネットワークソースからリポジトリを追加できます。
YaSTの
ダイアログでリポジトリを追加するには、次の手順に従います。ダイアログに表示されているオプションのいずれかを選択します。
図 8.2: ソフトウェアリポジトリの追加 #ネットワークをスキャンして、SLP経由でサービスをアナウンスしているインストールサーバを検索するには、
を選択して をクリックします。リムーバブルメディアからリポジトリを追加するには、該当するオプションを選択して、メディアを挿入するか、またはUSBデバイスをコンピュータに接続します。
をクリックして、インストールを開始します。大半のリポジトリでは、該当のオプションを選択して
をクリックすると、メディアへのパス(またはURL)を指定するように求められます。 の指定は任意です。何も指定しない場合は、製品名またはURLがリポジトリ名として使用されます。
追加したリポジトリによっては、リポジトリのGPGキーのインポートを求められたり、ライセンスへの合意を求められたりします。
確認すると、メタデータがダウンロードされ、解析されます。これにより、
のリストにリポジトリが追加されます。必要に応じて、8.4.2項 「リポジトリプロパティの管理」の説明に従い、リポジトリの を調整します。
リポジトリを正常に追加できると、ソフトウェアマネージャが起動し、そのリポジトリからパッケージをインストールできるようになります。詳細については、第8章 「ソフトウェアをインストールまたは削除する」を参照してください。
8.4.2 リポジトリプロパティの管理 #
の の概要では、次のリポジトリプロパティを変更できます。
- Status
リポジトリのステータスは、
または のどちらかです。有効なリポジトリからのパッケージだけをインストールできます。一時的にリポジトリを無効にするには を無効にします。リポジトリ名をダブルクリックして、その状態を切り替えることもできます。リポジトリを完全に削除するには、 をクリックします。- 更新
リポジトリを更新すると、そのコンテンツの説明(パッケージ名、バージョンなど)は、YaSTで使用されるローカルキャッシュにダウンロードされます。これは、CDやDVDなどの静的リポジトリでは1回で十分ですが、内容が頻繁に変更されるリポジトリでは頻繁な更新が必要です。リポジトリのキャッシュを最新の状態に保つ最も簡単な方法は、
の選択です。手動更新を行うには、 をクリックして、オプションの1つを選択します。インストールの前に、リモートリポジトリからのパッケージをダウンロードします。これらのパッケージは、デフォルトでは、インストールが正常に完了すると削除されます。
を有効にすると、ダウンロードしたパッケージが削除されません。ダウンロードの場所は、/etc/zypp/zypp.conf
に設定されます。これは、デフォルトでは、/var/cache/zypp/packages
です。リポジトリの
は、1
~200
の値です。ここで、1
は最高の優先度、200
は最低の優先度です。YaSTで追加した新しいリポジトリの優先度は、デフォルトで99
です。特定のリポジトリに関して優先度値が何であってもよい場合は、値を0
に設定しても、そのリポジトリにデフォルト優先度(99
)を適用できます。パッケージが2つ以上のリポジトリにある場合は、優先度の最も高いリポジトリが優先して使用されます。これは、ローカルリポジトリ(たとえば、DVD)に高い優先度を与えることによって、インターネットから不必要にパッケージをダウンロードしないようにする場合に有用です。重要: 優先度とバージョンの比較優先度の最も高いリポジトリが、常に、優先されます。したがって、更新リポジトリには必ず最高の優先度が割り当てられるようにします。そのようにしないと、次のオンラインアップデートまで更新されない古いバージョンがインストールされる可能性があります。
- 名前とURL
リポジトリ名またはリポジトリのURLを変更するには、それをシングルクリックでリストから選択し、次に、
をクリックします。
8.4.3 リポジトリキーの管理 #
ソフトウェアリポジトリには、その整合性確認のため、リポジトリメンテナのGPGキーで署名することができます。新しいリポジトリを追加するたびに、そのキーをYaSTでインポートできます。そのキーを他の任意のGPGキーのように検証し、キーが変更されていないことを確認してください。キーの変更を見つけた場合は、リポジトリに何らかの問題がある可能性があります。キーの変更の原因を突き止めるまで、リポジトリをインストールソースとして無効にしてください。
インポートしたすべてのキーを管理するには、
ダイアログで をクリックします。マウスでエントリを選択して、ウィンドウ下部にキーのプロパティを表示します。 、 、または をクリックすることで、該当する操作をキーに対して実行します。8.5 GNOMEパッケージアップデータ #
SUSEはお買い上げの製品に対し、継続的にソフトウェアセキュリティパッチおよびアップデートを提供します。デスクトップで利用可能なツールを使用して、またはYaSTオンラインアップデートモジュールを実行することにより、インストールできます。このセクションでは、 を使用してGNOMEデスクトップからシステムをアップデートする方法について説明します。
YaSTオンラインアップデートモジュールとは異なり、GNOME
は、アップデートリポジトリからパッチのインストールを提供するだけでなく、すでにインストールされているパッケージの新しいバージョンも提供します(パッチ修正のセキュリティの問題または誤動作、機能およびバージョン番号は通常、変わりません。新しいバージョンのパッケージによりバージョン番号が増え、機能が追加されるか主な変更が導入されます。)新しいパッチまたはパッケージのアップデートが利用可能な場合は常に、GNOMEでは、通知領域またはロック画面で通知が表示されます。
の通知設定を行うには、GNOMEで を起動し、 › の順に選択します。
パッチおよびアップデートをインストールするには、通知メッセージをクリックします。これにより、GNOMEで
が開きます。または、package U
と入力し、 を選択して、 からアップデータを開きます。アップデートは次の4つのカテゴリに分類されます。
- セキュリティアップデート(パッチ)
セキュリティアップデートは、重大なセキュリティハザードを修復するので、必ずインストールする必要があります。
- 推奨されるアップデート(パッチ)
コンピュータに損害を与える可能性のある問題を修復します。これらのアップデートをインストールすることを強くお勧めします。
- オプションのアップデート(パッチ)
セキュリティに関連しない問題を修復したり、拡張機能を提供します。
- その他のアップデート
インストールされるパッケージの新しいバージョン。
すべての使用可能なアップデートはインストール用に事前に選択されています。すべてのアップデートをインストールしない場合は、まず、不要なアップデートを選択解除します。すべてのセキュリティアップデートおよび推奨されるアップデートは必ずインストールすることを強くお勧めします。
アップデートに関する詳細情報を取得するには、そのタイトルと
をクリックします。情報はパッケージリストの下のボックスに表示されます。一部のアップデートでは、マシンを再起動するか、ログアウトする必要がある場合があります。インストール後に表示される、手順に関するメッセージを確認します。
8.6 を使用したパッケージの更新 #
GNOME
に加えて、GNOMEでは次の機能を持つ を提供します。PackageKitを介してRPMとして配布されたソフトウェアをインストール、更新、削除する
Flatpakとして配布されたソフトウェアをインストール、更新、削除する
GNOMEシェル拡張機能(https://extensions.gnome.org)をインストール、更新、削除する
「Linux Vendor Firmware Service」(LVFS、https://fwupd.org)を使用してハードウェアデバイスのファームウェアを更新する
では、ソフトウェアのスクリーンショット、レーティング、およびレビューも提供しています。
SUSE Linux Enterprise Serverで提供される他のツールと次のような違いがあります。
には、YaSTまたはZypperとは異なり、RPMとしてパッケージされたソフトウェアをインストールする場合、
はAppStreamメタデータを提供するソフトウェアに制限されます。これには、ほとんどのデスクトップアプリケーションが含まれます。GNOME
は実行中のシステム内のパッケージをアップデートし(それぞれのアプリケーションを再起動する必要があります)、 はアップデートをダウンロードし、再起動後に適用します。
9 コマンドラインツールによるソフトウェアの管理 #
この章では、ソフトウェア管理の2つのコマンドラインツールとして、ZypperとRPMについて説明します。このコンテキストで使用される用語(repository
、patch
、update
など)の定義については、8.1項 「用語の定義」を参照してください。
9.1 Zypperの使用 #
Zypperは、パッケージのインストール、更新、および削除を行うためのコマンドラインパッケージマネージャです。リポジトリの管理も行います。これは特に、リモートソフトウェア管理タスクの実行、またはシェルスクリプトからのソフトウェアの管理で役立ちます。
9.1.1 一般的な使用方法 #
Zypperの一般的な構文は次のとおりです。
zypper[--global-options]
COMMAND[--command-options]
[arguments]
ブラケットで囲まれたコンポーネントは必須ではありません。一般的なオプションおよびすべてのコマンドのリストについては、zypper
help
を参照してください。特定のコマンドのヘルプを参照するには、「zypper help
COMMAND」と入力します。
- Zypperのコマンド
Zypperを実行する最も簡単な方法は、その名前の後にコマンドを入力することです。たとえば、システムに必要なすべてのパッチを適用するには、次のコマンドを使用します。
>
sudo
zypper patch- グローバルオプション
さらに、グローバルオプションをコマンドの直前に入力することによって、1つ以上のグローバルオプションを選択することもできます。
>
sudo
zypper --non-interactive patch上の例では、オプション
--non-interactive
は、確認を一切表示せずにコマンドを実行することを意味します(自動的にデフォルトの回答を適用します)。- コマンド固有のオプション
特定のコマンドに固有のオプションを使用する場合は、コマンドの直後にそのオプションを入力します。
>
sudo
zypper patch --auto-agree-with-licenses上の例では、
--auto-agree-with-licenses
を使用して、ライセンスの確認を表示せずに、必要なすべてのパッチをシステムに適用します。その代わりに、自動的にライセンスに同意します。- 引数
一部のコマンドでは、1つ以上の引数が必要です。たとえば、コマンド
install
を使用する場合、「インストール」するパッケージを1つまたは複数指定する必要があります。>
sudo
zypper install mplayer一部のオプションでは、1つの引数が必要です。次のコマンドでは、すべての既知のパターンが表示されます。
>
zypper search -t pattern
上記のすべてを結合できます。たとえば、次のコマンドは、冗長モードで、factory
リポジトリからmcとvimパッケージをインストールします。
>
sudo
zypper -v install --from factory mc vim
--from
オプションは、指定されたリポジトリからパッケージを要求する際に、すべてのリポジトリを(依存関係の解決のため)有効に保ちます。--repo
は、--from
のエイリアスで、いずれかのものを使用できます。
ほとんどのZypperコマンドには、指定のコマンドのシミュレーションを行うdry-run
オプションがあります。このオプションは、テストの目的で使用できます。
>
sudo
zypper remove --dry-run MozillaFirefox
Zypperは、グローバルオプション--userdata
STRING
をサポートします。このオプションを使用して文字列を指定することができます。指定した文字列は、Zypperのログファイルとプラグイン(Btrfsプラグインなど)に書き込まれます。これを使用して、ログファイルでトランザクションにマークを付けたり、トランザクションを特定したりできます。
>
sudo
zypper --userdata STRING patch
9.1.2 Zypperサブコマンドの使用 #
Zypperサブコマンドは、zypper_execdir
設定オプションで指定されたディレクトリに保存される実行可能ファイルです。デフォルトでは/usr/lib/zypper/commands
です。サブコマンドがそこで見つからない場合、Zypperはその$PATHの残りの部分を自動的に検索します。これにより、独自のローカル拡張機能を作成し、ユーザスペースに保存することができます。
Zypperシェルでのサブコマンドの実行、グローバルZypperオプションの使用はサポートされていません。
使用可能なサブコマンドの一覧表示:
>
zypper help subcommand
[...]
Available zypper subcommands in '/usr/lib/zypper/commands'
appstream-cache
lifecycle
migration
search-packages
Zypper subcommands available from elsewhere on your $PATH
log Zypper logfile reader
(/usr/sbin/zypper-log)
サブコマンドのヘルプ画面の表示
>
zypper help appstream-cache
9.1.3 Zypperを使ったソフトウェアのインストールと削除 #
パッケージをインストールまたは削除するには、次のコマンドを使用します。
>
sudo
zypper install PACKAGE_NAME>
sudo
zypper remove PACKAGE_NAME
glibc、zypper、kernelなどの必須システムパッケージは削除しないでください。これらを削除すると、システムが不安定になったり、まったく動作しなくなったりする可能性があります。
9.1.3.1 インストールまたは削除するパッケージの選択 #
コマンドzypper install
およびzypper remove
でパッケージを指定するには、さまざまな方法があります。
- 正確なパッケージ名を指定する
>
sudo
zypper install MozillaFirefox- 正確なパッケージ名とバージョン番号を指定する
>
sudo
zypper install MozillaFirefox-52.2- リポジトリエイリアスとパッケージ名を指定する
>
sudo
zypper install mozilla:MozillaFirefoxここで
mozilla
は、インストールするリポジトリのエイリアスです。- ワイルドカードを使用してパッケージ名を指定する
名前が特定の文字列で始まるか、特定の文字列で終わるパッケージをすべて選択できます。特にパッケージを削除する場合は、ワイルドカードの使用には注意が必要です。次のコマンドでは、名前の先頭に「Moz」が付くすべてのパッケージがインストールされます。
>
sudo
zypper install 'Moz*'ヒント: すべての-debuginfo
パッケージを削除問題をデバッグする際、実行中のプロセスに関する情報を多く得るために、一時的に多数の
-debuginfo
パッケージをインストールする場合があります。デバッグセッションが終了したら、この環境を消去する必要があります。それには以下を実行します。>
sudo
zypper remove '*-debuginfo'- 機能によって指定する
たとえば、名前がわからないパッケージをインストールする場合は、機能による指定が便利です。次のコマンドは、パッケージMozillaFirefoxをインストールします。
>
sudo
zypper install firefox- 機能、ハードウェアアーキテクチャ、またはバージョンによって指定する
機能とともに、ハードウェアアーキテクチャとバージョンを指定できます。
機能の後にピリオドを付けて、その後に目的のハードウェアアーキテクチャの名前を追加します。たとえば、AMD/Intel 64アーキテクチャ(Zypperでの名前は
x86_64
_64)を指定するには、次のコマンドを使用します。>
sudo
zypper install 'firefox.x86_64'バージョンは文字列の最後に追加し、バージョンの前に演算子を付ける必要があります。使用できる演算子は、
<
(より小さい)、<=
(以下)、=
(等しい)、>=
(以上)、>
(より大きい)です。>
sudo
zypper install 'firefox>=74.2'必要なハードウェアアーキテクチャとバージョンを組み合わせて指定することもできます。
>
sudo
zypper install 'firefox.x86_64>=74.2'
- RPMファイルのパスによって指定する
また、パッケージに対するローカルパスまたはリモートパスを指定できます。
>
sudo
zypper install /tmp/install/MozillaFirefox.rpm>
sudo
zypper install http://download.example.com/MozillaFirefox.rpm
9.1.3.2 パッケージのインストールと削除の結合 #
パッケージのインストールと削除を同時に行うには、+/-
修飾子を使用します。emacsをインストールし、同時にvimを削除するには、次のコマンドを使用します。
>
sudo
zypper install emacs -vim
emacsを削除し、同時にvimをインストールするには、次のコマンドを使用します。
>
sudo
zypper remove emacs +vim
名前の先頭に-
が付くパッケージ名がコマンドオプションとして解釈されないようにするには、常に第2引数としてその名前を使用します。これが可能でない場合は、名前の前に--
を付けます。
>
sudo
zypper install -emacs +vim # Wrong>
sudo
zypper install vim -emacs # Correct>
sudo
zypper install -- -emacs +vim # Correct>
sudo
zypper remove emacs +vim # Correct
9.1.3.3 削除されたパッケージの依存関係のクリーンアップ #
指定したパッケージの削除後に、不要になったパッケージも自動的に削除されるようにしたい場合は、--clean-deps
オプションを使用します。
>
sudo
zypper rm --clean-deps PACKAGE_NAME
9.1.3.4 スクリプトでのZypperの使用 #
Zypperではデフォルトで、選択したパッケージのインストールまたは削除の前に、あるいは問題が発生した際には、確認が求められます。この動作は、--non-interactive
オプションを使用することで上書きされます。このオプションは、次のように、実際のコマンド(install
、remove
、patch
)の前に指定する必要があります。
>
sudo
zypper--non-interactive
install PACKAGE_NAME
このオプションは、スクリプトおよびcronジョブでZypperを使用できます。
9.1.3.5 ソースパッケージのインストールまたはダウンロード #
パッケージの対応するソースパッケージをインストールするには、次のコマンドを使用します。
>
zypper source-install PACKAGE_NAME
ソースパッケージをインストールするデフォルトの場所は、root
として実行する場合は/usr/src/packages/
、ユーザとして実行する場合は~/rpmbuild
になります。これらの値はローカルのrpm
設定で変更できます。
このコマンドにより、指定したパッケージのビルド依存関係もインストールされます。この処理が必要でない場合は、次のようにスイッチ-D
を追加します。
>
sudo
zypper source-install -D PACKAGE_NAME
ビルドの依存関係のみをインストールするには、-d
を使用します。
>
sudo
zypper source-install -d PACKAGE_NAME
もちろん、リポジトリリストで有効にしたソースパッケージを含むリポジトリが存在する場合にのみ動作します(ソースパッケージはデフォルトで追加されますが、有効にはなりません)。リポジトリの管理の詳細については、9.1.6項 「Zypperによるリポジトリの管理」を参照してください。
リポジトリで使用可能なすべてのソースパッケージのリストは、次のコマンドで参照できます。
>
zypper search -t srcpackage
また、すべてのインストール済みパッケージのソースパッケージをローカルディレクトリにダウンロードすることもできます。ソースパッケージをダウンロードするには、以下を使用します。
>
zypper source-download
デフォルトのダウンロードディレクトリは/var/cache/zypper/source-download
です。これは、--directory
オプションを使って変更できます。ダウンロードや削除を行わず、不足パッケージや不要パッケージの表示のみを行う場合は、--status
オプションを使用します。不要なソースパッケージを削除するには、--delete
オプションを使用します。削除を無効にするには、--no-delete
オプションを使用します。
9.1.3.6 無効にされたリポジトリからのパッケージのインストール #
通常、パッケージのインストールや更新は、有効化されたリポジトリからしかできません。--plus-content
TAG
オプションを使用すると、リポジトリをリフレッシュし、現在のZypperセッション中のみ一時的に有効にして、終了したら無効にすることができます。
たとえば、追加の-debuginfo
パッケージまたは-debugsource
パッケージを提供するリポジトリを有効にするには、--plus-content debug
を使用します。このオプションは複数回指定できます。
そうした「デバッグ」リポジトリを一時的に有効にして、特定の-debuginfo
パッケージをインストールするには、次のオプションを使用します。
>
sudo
zypper --plus-content debug \ install "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4"
debuginfoパッケージがないと、build-id
文字列が、gdb
によって報告されます。
SUSE Linux Enterprise Serverインストールメディアのリポジトリは引き続き設定されていますが、インストールが正常に完了すると無効になります。--plus-content
オプションを使用して、オンラインリポジトリの代わりにインストールメディアからパッケージをインストールできます。zypper
を呼び出す前に、DVDをコンピュータのドライブに挿入するなどして、メディアが使用可能であることを確認してください。
9.1.3.7 ユーティリティ #
すべての依存関係が依然として満たされていることを確認し、欠如する依存関係を修復するには、次のコマンドを使用します。
>
zypper verify
必要とされる依存関係に加えて、一部のパッケージでは他のパッケージが「推奨されます」。これらの推奨対象パッケージは、実際に使用可能でインストール可能な場合のみインストールされます。推奨側のパッケージがインストールされた後で、(パッケージまたはハードウェアの追加により)推奨対象パッケージが使用可能になった場合は、次のコマンドを使用します。
>
sudo
zypper install-new-recommends
このコマンドは、WebカメラまたはWi-Fiデバイスを接続した後で非常に役に立ちます。このコマンドは、デバイスのドライバと関連ソフトウェアが利用できる場合には、それらをインストールします。ドライバと関連ソフトウェアは、一定のハードウェア依存関係が満たされている場合のみインストールできます。
9.1.4 Zypperによるソフトウェアの更新 #
Zypperを使用してソフトウェアを更新するには3つの方法があります。パッチをインストールする、パッケージの新しいバージョンをインストールする、または配布全体を更新する方法です。最後の方法は、zypper
dist-upgrade
で行うことができます。SUSE Linux Enterprise Serverのアップグレードについては、Book “アップグレードガイド”, Chapter 2 “アップグレードパスと方法”を参照してください。
9.1.4.1 必要なすべてのパッチのインストール #
SUSE Linux Enterprise Serverへの「パッチ適用」は、インストールされたパッケージの新しいバージョンをインストールする最も信頼できる方法です。これにより、正しいバージョンを持つ必要なすべてのパッケージがインストールされ、「競合している」とみなされるパッケージバージョンが確実に除外されます。
システムに適用される、正式にリリースされたすべてのパッチをインストールするには、次のコマンドを実行します。
>
sudo
zypper patch
コンピュータに設定されているリポジトリから使用可能なすべてのパッチが、インストール環境に関係があるかどうかが確認されます。関係がある場合(およびoptional
またはfeature
として分類されていない場合)、パッチはただちにインストールされます。zypper patch
が成功すると、例外を確認しない限り、脆弱なバージョンパッケージがインストールされないことが保証されます。正式な更新リポジトリはSUSE Linux Enterprise Serverのインストールを登録した後でのみ使用可能であることに注意してください。
インストールするパッチにシステムの再起動が必要な変更が含まれる場合、事前に警告が表示されます。
プレーンのzypper patch
コマンドでは、サードパーティリポジトリからのパッチは適用されません。サードパーティリポジトリも更新するには、次のようにwith-update
コマンドオプションを使用します。
>
sudo
zypper patch --with-update
オプションのパッチもインストールするには、次のコマンドを使用します。
>
sudo
zypper patch --with-optional
Bugzillaの特定の問題に関連するすべてのパッチをインストールするには、次のコマンドを使用します。
>
sudo
zypper patch --bugzilla=NUMBER
特定のCVEデータベースエントリに関連するすべてのパッチをインストールするには、次のコマンドを使用します。
>
sudo
zypper patch --cve=NUMBER
たとえば、番号がCVE-2010-2713
CVE-のセキュリティパッチをインストールするには、次のコマンドを実行します。
>
sudo
zypper patch --cve=CVE-2010-2713
Zypperおよびパッケージ管理自体に影響するパッチのみをインストールするには、次のコマンドを使用します。
>
sudo
zypper patch --updatestack-only
updatestack-only
コマンドオプションを使用する場合、ほかのリポジトリも更新しようとしてそれ以外のコマンドオプションを指定すると、そのコマンドオプションは削除されます。
9.1.4.2 パッチのリストの表示 #
パッチが使用可能かどうかを確認するため、Zypperでは次の情報を参照できます。
- 必要なパッチの数
必要なパッチ(システムに適用されるパッチであってもまだインストールされていないもの)の数のリストを表示するには、
patch-check
を使用します。>
zypper patch-check Loading repository data... Reading installed packages... 5 patches needed (1 security patch)このコマンドを
--updatestack-only
オプションと組み合わせて使用すると、Zypperおよびパッケージ管理自体に影響するパッチのみのリストを表示できます。- 必要なパッチのリスト
必要なすべてのパッチ(システムに適用されるパッチであってもまだインストールされていないもの)のリストを表示するには、
zypper list-patches
を使用します。- すべてのパッチのリスト
インストール済みかどうか、およびインストール環境に適用されるかどうかに関係なく、SUSE Linux Enterprise Serverで使用可能なすべてのパッチのリストを表示するには、
zypper patches
を使用します。
また、特定の問題に関連するパッチを表示およびインストールすることもできます。特定のパッチを表示するには、次のオプションでzypper
list-patches
コマンドを使用します。
- Bugzillaの問題によって指定する
Bugzillaの問題に関連する、必要なすべてのパッチのリストを表示するには、オプション
--bugzilla
を使用します。特定のバグに対応するパッチのリストを表示するには、
--bugzilla=NUMBER
のようにバグ番号を指定することもできます。Bugzillaの複数の問題に関連するパッチを検索するには、次の例のように、バグ番号の間にカンマを追加します。>
zypper list-patches --bugzilla=972197,956917- CVE番号によって指定する
CVE (Common Vulnerabilities and Exposures)データベースのエントリに関連する、必要なすべてのパッチのリストを表示するには、オプション
--cve
を使用します。特定のCVEデータベースエントリに対応するパッチのリストを表示するには、
--cve=NUMBER
のようにCVE番号を指定することもできます。複数のCVEデータベースエントリに関連するパッチを検索するには、次の例のように、CVE番号の間にカンマを追加します。>
zypper list-patches --cve=CVE-2016-2315,CVE-2016-2324- 撤回されたパッチを一覧表示する
SUSE Linux Enterprise 15のコードストリームでは、一部のパッチが自動的に撤回されます。アップデートに新しいバグが含まれるリスクがあるため、保守アップデートは慎重にテストされます。アップデートにバグが含まれていることが判明した場合、バグのあるアップデートを元に戻すために(バージョン番号が高い)新しいアップデートが発行され、バグのあるアップデートが再度インストールされないようにブロックされます。撤回されたパッチを
zypper
で一覧表示できます。>
zypper lp --all |grep retracted
SLE-Module-Basesystem15-SP3-Updates | SUSE-SLE-Module-Basesystem-15-SP3-2021-1965 | recommended | important | --- | retracted | Recommended update for multipath-tools SLE-Module-Basesystem15-SP3-Updates | SUSE-SLE-Module-Basesystem-15-SP3-2021-2689 | security | important | --- | retracted | Security update for cpio SLE-Module-Basesystem15-SP3-Updates | SUSE-SLE-Module-Basesystem-15-SP3-2021-3655 | security | important | reboot | retracted | Security update for the Linux Kernel撤回された(または任意の)パッチに関する詳細情報を参照してください。
>
zypper patch-info SUSE-SLE-Product-SLES-15-2021-2689
Loading repository data... Reading installed packages... Information for patch SUSE-SLE-Product-SLES-15-2021-2689: --------------------------------------------------------- Repository : SLE-Product-SLES15-LTSS-Updates Name : SUSE-SLE-Product-SLES-15-2021-2689 Version : 1 Arch : noarch Vendor : maint-coord@suse.de Status : retracted Category : security Severity : important Created On : Mon 16 Aug 2021 03:44:00 AM PDT Interactive : --- Summary : Security update for cpio Description : This update for cpio fixes the following issues: It was possible to trigger Remote code execution due to a integer overflow (CVE-2021-38185, bsc#1189206) UPDATE: This update was buggy and could lead to hangs, so it has been retracted. There will be a follow up update. [...]- 競合するパッケージのパッチ
Information for patch openSUSE-SLE-15.3-2022-333: ------------------------------------------------- Repository : Update repository with updates from SUSE Linux Enterprise 15 Name : openSUSE-SLE-15.3-2022-333 Version : 1 Arch : noarch Vendor : maint-coord@suse.de Status : needed Category : security Severity : important Created On : Fri Feb 4 09:30:32 2022 Interactive : reboot Summary : Security update for xen Description : This update for xen fixes the following issues: - CVE-2022-23033: Fixed guest_physmap_remove_page not removing the p2m mappings. (XSA-393) (bsc#1194576) - CVE-2022-23034: Fixed possible DoS by a PV guest Xen while unmapping a grant. (XSA-394) (bsc#1194581) - CVE-2022-23035: Fixed insufficient cleanup of passed-through device IRQs. (XSA-395) (bsc#1194588) Provides : patch:openSUSE-SLE-15.3-2022-333 = 1 Conflicts : [22] xen.src < 4.14.3_06-150300.3.18.2 xen.noarch < 4.14.3_06-150300.3.18.2 xen.x86_64 < 4.14.3_06-150300.3.18.2 xen-devel.x86_64 < 4.14.3_06-150300.3.18.2 xen-devel.noarch < 4.14.3_06-150300.3.18.2 [...]
上記のパッチは、影響を受けるバージョンまたは脆弱なバージョンの22パッケージと競合します。これらの影響を受けるパッケージまたは脆弱なパッケージのいずれかがインストールされると、競合が発生し、パッチは「必要」に応じて分類されます。
zypper patch
は、利用可能なすべてのパッチをインストールしようとします。問題が発生した場合は、問題が報告され、すべてのアップデートがインストールされるわけではないことが通知されます。この競合は、影響を受けるパッケージまたは脆弱なパッケージを更新するか、それらを削除することで解決できます。SUSEアップデートリポジトリには固定パッケージも付属しているため、アップデートは競合を解決するための標準的な方法です。依存関係の問題やパッケージのロックなどにより、パッケージを更新できない場合は、ユーザの承認後に削除されます。
必要かどうかに関係なくすべてのパッチのリストを表示するには、追加でオプション--all
を使用します。たとえば、CVE番号が割り当てられたすべてのパッチのリストを表示するには、次のコマンドを使用します。
>
zypper list-patches --all --cve
Issue | No. | Patch | Category | Severity | Status
------+---------------+-------------------+-------------+-----------+----------
cve | CVE-2019-0287 | SUSE-SLE-Module.. | recommended | moderate | needed
cve | CVE-2019-3566 | SUSE-SLE-SERVER.. | recommended | moderate | not needed
[...]
9.1.4.3 新規パッケージパージョンのインストール #
リポジトリに新しいパッケージのみが存在し、パッチが提供されていない場合は、zypper patch
は無効です。インストールされているパッケージをすべて新しく入手可能なバージョンで更新するには、次のコマンドを使用します。
>
sudo
zypper update
zypper update
は問題のあるパッケージを無視します。たとえば、パッケージがロックされている場合、zypper update
は、より新しいバージョンのパッケージが利用可能であってもそのパッケージを省略します。逆に、パッケージが脆弱であるとみなされた場合、zypper patch
は競合を報告します。
個別のパッケージをアップデートするには、updateコマンドまたはinstallコマンドのいずれかでパッケージを指定します。
>
sudo
zypper update PACKAGE_NAME>
sudo
zypper install PACKAGE_NAME
インストール可能なすべての新しいパッケージのリストを、次のコマンドで取得できます。
>
zypper list-updates
ただし、このコマンドで表示されるのは、次の条件に一致するパッケージのみです。
すでにインストール済みのパッケージと同じベンダである
すでにインストール済みのパッケージと同等以上の優先度をもつリポジトリによって提供される
インストール可能である(すべての依存関係が満たされている)
次のコマンドを使用すると、(インストール可能かどうかに関わらず)すべての新しい使用可能なパッケージのリストを取得できます。
>
sudo
zypper list-updates --all
新しいパッケージをインストールできない理由を見つけるには、上で説明されているように、zypper
install
コマンドまたはzypper update
コマンドを使用します。
9.1.4.4 孤立パッケージの特定 #
Zypperからリポジトリを削除する場合や、システムをアップグレードする場合には、いくつかのパッケージが「孤立」状態になる可能性があります。これらの孤立パッケージは、どのアクティブなリポジトリにも属していません。次のコマンドで、これらのリストを表示できます。
>
sudo
zypper packages --orphaned
このリストを使用して、パッケージが引き続き必要か、それとも削除しても安全かを判断できます。
9.1.5 削除されたファイルを使用しているプロセスとサービスの特定 #
パッケージにパッチを適用したり、パッケージを更新または削除したりした場合、更新または削除によって削除されたファイルを引き続き使用している実行中のプロセスがシステムに存在することがあります。削除されたファイルを使用しているプロセスのリストを表示するには、zypper ps
を使用します。プロセスが既知のサービスに属している場合は、サービス名のリストが表示され、そのサービスを容易に再起動できます。デフォルトでは、zypper
ps
は次のような表を表示します。
>
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 |
UID: プロセスを実行しているユーザのログイン名 |
Command: プロセスを実行するために使用されるコマンド |
Service: サービス名(コマンドがシステムサービスに関連付けられている場合にのみ) |
Files: 削除されたファイルのリスト |
次のように指定することで、zypper ps
の出力フォーマットを制御できます。
zypper ps
-s
削除されたファイルを表示しない短い表を作成します。
>
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
サービスの処理の詳細については、第19章 「systemd
デーモン」を参照してください。
9.1.6 Zypperによるリポジトリの管理 #
Zypperのすべてのインストールまたはパッチのコマンドは、既知のリポジトリのリストに応じて異なります。システムで既知のすべてのリポジトリのリストを表示するには、次のコマンドを使用します。
>
zypper repos
結果は、次の出力のようになります。
>
zypper repos
# | Alias | Name | Enabled | Refresh
--+--------------+---------------+---------+--------
1 | SLEHA-15-GEO | SLEHA-15-GEO | Yes | No
2 | SLEHA-15 | SLEHA-15 | Yes | No
3 | SLES15 | SLES15 | Yes | No
各種コマンドのリポジトリを指定するには、エイリアス、URI、またはリポジトリ番号をzypper repos
コマンド出力から使用できます。リポジトリの別名は、リポジトリ操作コマンド用の短いリポジトリ名です。ただし、リポジトリリストの変更後に、リポジトリ番号が変わる可能性があります。エイリアスは変更されることはありません。
デフォルトでは、URIやリポジトリの優先度など、詳細情報は表示されません。すべての詳細を表示するには、次のコマンドを使用します。
>
zypper repos -d
9.1.6.1 リポジトリの追加 #
リポジトリを追加するには、次を実行します。
>
sudo
zypper addrepo URI ALIAS
URIは、インターネットリポジトリ、ネットワークリソース、ディレクトリ、CDまたはDVDのいずれかです(詳細については、https://en.opensuse.org/openSUSE:Libzypp_URIsを参照してください)。ALIASは、リポジトリの短い固有のIDです。このIDは、固有である必要があること以外は自由に選択できます。すでに使用されているエイリアスを指定した場合、Zypperでは警告が発行されます。
9.1.6.2 リポジトリの更新 #
zypper
は、設定されているリポジトリからパッケージの変更点をフェッチできます。変更点をフェッチするには、次のコマンドを実行します。
>
sudo
zypper refresh
zypper
のデフォルトの動作
一部のコマンドではデフォルトでrefresh
が自動的に実行されるため、ユーザがこのコマンドを明示的に実行する必要はありません。
refresh
コマンドと--plus-content
オプションを使用すると、無効になっているリポジトリ内の変更点も表示できます。
>
sudo
zypper --plus-content refresh
このオプションは、リポジトリ内の変更点をフェッチしますが、無効になっているリポジトリは同じ状態(無効)のままにします。
9.1.6.3 リポジトリの削除 #
リストからリポジトリを削除するには、コマンドzypper
removerepo
を使用し、削除するリポジトリのエイリアスまたは番号を指定します。たとえば、SLEHA-12-GEO
から例9.1「Zypper - 既知のリポジトリのリスト」リポジトリを削除するには、次のコマンドのいずれかを使用します。
>
sudo
zypper removerepo 1>
sudo
zypper removerepo "SLEHA-12-GEO"
9.1.6.4 リポジトリの変更 #
zypper modifyrepo
によりリポジトリを有効または無効にします。また、このコマンドにより、リポジトリのプロパティ(動作、名前、優先度の更新など)を変更できます。次のコマンドは、updates
という名前のリポジトリを有効にし、自動更新をオンにし、リポジトリの優先度を20に設定します。
>
sudo
zypper modifyrepo -er -p 20 'updates'
リポジトリを変更する場合、1つのリポジトリだけなく、リポジトリのグループも操作できます。
-a : すべてのリポジトリ |
-l : ローカルリポジトリ |
-t : リモートリポジトリ |
-m TYPE : 特定のタイプのリポジトリ(ここで、TYPEには、次のいずれかを指定できます: http 、https 、ftp 、cd 、dvd 、dir 、file 、cifs 、smb 、nfs 、hd 、iso ) |
リポジトリエイリアスの名前を変更するには、renamerepo
コマンドを使用します。次の例では、エイリアスをMozilla
Firefox
からfirefox
に変更しています。
>
sudo
zypper renamerepo 'Mozilla Firefox' firefox
9.1.7 Zypperによるリポジトリおよびパッケージのクエリ #
Zypperでは、リポジトリまたはパッケージをクエリするためのさまざまな方法が提供されています。使用可能なすべての製品、パターン、パッケージ、またはパッチのリストを取得するには、次のコマンドを使用します。
>
zypper products>
zypper patterns>
zypper packages>
zypper patches
特定のパッケージについてすべてのリポジトリをクエリするには、search
を使用します。特定のパッケージに関する情報を取得するには、info
コマンドを使用します。
9.1.7.1 ソフトウェアの検索 #
zypper search
コマンドは、パッケージ名に対して機能し、オプションでパッケージの概要と説明に対しても機能します。/
でラップされた文字列は、正規表現として解釈されます。デフォルトでは、検索で大文字と小文字は区別されません。
fire
を含むパッケージ名の単純な検索>
zypper search "fire"- 正確なパッケージ
MozillaFirefox
の単純な検索 >
zypper search --match-exact "MozillaFirefox"- パッケージの説明とサマリも検索
>
zypper search -d fire- まだインストールしていないパッケージのみ表示
>
zypper search -u fire- 文字列
fir
を含み、この後にe
が続かないパッケージの表示 >
zypper se "/fir[^e]/"
9.1.7.2 すべてのSLEモジュール間のパッケージの検索 #
現在有効なSLEモジュールの内部または外部の両方のパッケージを検索するには、search-packages
サブコマンドを使用します。このコマンドは、SUSEカスタマーセンターに連絡し、次のように一致するパッケージのすべてのモジュールを検索します。
>
zypper search-packages package1 package2
zypper search-packages
では、次のオプションを提供します。
検索文字列の完全一致を検索:
-x
,--match-exact
モジュール別に結果をグループ化(デフォルト: パッケージ別にグループ化):
-g,
--group-by-module
パッケージに関する詳細を表示:
-d
,--details
検索結果をXMLで表示:
--xmlout
9.1.7.3 特定の機能の検索 #
特定の機能を提供するパッケージを検索するには、コマンドwhat-provides
を使用します。たとえば、どのパッケージがPerlモジュールSVN::Core
を提供するか確認したい場合は、次のコマンドを使用します。
>
zypper what-provides 'perl(SVN::Core)'
what-provides
PACKAGE_NAME
はrpm -q --whatprovides
PACKAGE_NAMEに似ていますが、RPMではRPMデータベース(つまり、すべてのインストール済みパッケージのデータベース)のみを問い合わせることができます。それに対してZypperは、インストール済みのパッケージだけでなく、すべてのリポジトリから機能のプロバイダに関する情報を表示します。
9.1.7.4 パッケージ情報の表示 #
単一のパッケージをクエリするには、info
を使用し、引数として正確なパッケージ名を指定します。パッケージに関する詳細情報を表示します。パッケージ名がリポジトリのどのパッケージ名にも一致しない場合は、パッケージ以外に一致するものの詳細情報を出力します。特定のタイプを要求して(-t
オプションを使用)、そのタイプが存在しない場合は、使用可能なほかの一致を出力しますが、詳細な情報は出力しません。
ソースパッケージを指定した場合、そのソースパッケージからビルドされたバイナリパッケージを表示します。バイナリパッケージを指定した場合、そのバイナリパッケージをビルドするために使用されたソースパッケージを出力します。
パッケージの要求や推奨も表示するには、--requires
オプションや--recommends
オプションを使用します。
>
zypper info --requires MozillaFirefox
9.1.8 ライフサイクル情報の表示 #
SUSE製品は一般的に10年間サポートされています。多くの場合、3年間のサポートを追加するSUSEの拡張サポート提供を利用して、この標準的なライフサイクルを延長することができます。製品によっては、正確なサポートライフサイクルをhttps://www.suse.com/lifecycleで見つけることができます。
製品とサポートされているパッケージのライフサイクルを確認するには、以下のようにzypper lifecycle
コマンドを使用します。
#
zypper lifecycle
Product end of support Codestream: SUSE Linux Enterprise Server 15 2028-07-31 Product: SUSE Linux Enterprise Server 15 SP3 n/a* Module end of support Basesystem Module n/a* Desktop Applications Module n/a* Server Applications Module n/a* Package end of support if different from product: autofs Now, installed 5.1.3-7.3.1, update available 5.1.3-7.6.1
9.1.9 Zypperの設定 #
Zypperには、現在、設定ファイルが付属しています。この設定ファイルを使用すれば、Zypperの動作を(システム全体またはユーザ固有のでどちらかで)永続的に変更できます。システム全体に渡って変更する場合は、/etc/zypp/zypper.conf
を編集します。ユーザ固有に変更する場合は、~/.zypper.conf
を編集します。~/.zypper.conf
がまだ存在していない場合は、テンプレートとして/etc/zypp/zypper.conf
を使用できます。このテンプレートを~/.zypper.conf
にコピーして、好みに合わせて調整してください。利用できるオプションのヘルプについては、ファイル内のコメントを参照してください。
9.1.10 トラブルシューティング #
設定済みのリポジトリからのパッケージへのアクセスに問題がある場合(たとえば、特定のパッケージがリポジトリの1つに存在することを知っていても、Zypperでそのパッケージを見つけられない場合など)は、次のコマンドでリポジトリを更新すると有効なことがあります。
>
sudo
zypper refresh
それも役に立たない場合は、次のコマンドを試してください。
>
sudo
zypper refresh -fdb
このコマンドは、生メタデータの強制ダウンロードを含むデータベースの完全な更新と再構築を強制します。
9.1.11 BtrfsファイルシステムでのZypperロールバック機能 #
ルートパーティションでBtrfsファイルシステムが使用され、snapper
がインストールされている場合に、ファイルシステムに対する変更をコミットして適切なファイルシステムスナップショットを作成すると、Zypperは自動的にsnapper
を呼び出します。これらのスナップショットは、Zypperによって行われた変更を元に戻す場合に使用できます。詳細については、第10章 「Snapperを使用したシステムの回復とスナップショット管理」を参照してください。
9.1.12 詳細情報 #
コマンドラインからのソフトウェア管理の詳細については、「zypper help
」、「zypper help
COMMAND」と入力するか、zypper(8)
のマニュアルページを参照してください。詳しいコマンドリファレンス、最も重要なコマンドのcheat sheets
、およびスクリプトやアプリケーションにおけるZypperの詳しい使い方については、https://en.opensuse.org/SDB:Zypper_usageを参照してください。SUSE Linux Enterprise Serverの最新バージョンにおけるソフトウェアの変更点のリストについては、https://en.opensuse.org/openSUSE:Zypper_versionsを参照してください。
9.2 RPM - パッケージマネージャ #
RPM (RPM Package Manager)がソフトウェアパッケージを管理するのに使用されます。その主なコマンドはrpm
とrpmbuild
です。ユーザ、システム管理者、およびパッケージの作成者は、強力なRPMデータベースでクエリーを行って、インストールされているソフトウェアに関する情報を取得できます。
rpm
には、ソフトウェアパッケージのインストール、アンインストール、アップデート、RPMデータベースの再構築、RPMベースまたは個別のRPMアーカイブの照会、パッケージの整合性チェック、およびパッケージへの署名の5種類のモードがあります。rpmbuild
は、元のソースからインストール可能なパッケージを作成する場合に使用します。
インストール可能なRPMアーカイブは、特殊なバイナリ形式でパックされています。それらのアーカイブは、インストールするプログラムファイルとある種のメタ情報で構成されます。メタ情報は、ソフトウェアパッケージを設定するためにrpm
によってインストール時に使用されるか、または文書化の目的でRPMデータベースに格納されています。通常、アーカイブには拡張子.rpm
が付けられます。
多くのパッケージにおいて、ソフトウェア開発に必要なコンポーネント(ライブラリ、ヘッダ、インクルードファイルなど)は、別々のパッケージに入れられています。それらの開発パッケージは、最新のGNOMEパッケージのように、ソフトウェアを自分自身でコンパイルする場合にのみ、必要になります。それらのパッケージは、名前の拡張子-devel
で識別できます(alsa-devel
パッケージやgimp-devel
パッケージなど)。
9.2.1 パッケージの信頼性の検証 #
RPMパッケージにはGPG署名があります。RPMパッケージの署名を検証するには、rpm --checksig
PACKAGE-1.2.3.rpmコマンドを使用して、SUSEまたはその他の信頼できるツールから送信されたパッケージかどうか判別します。これは、インターネットからアップデートパッケージを入手する場合には、特に推奨されます。
オペレーティングシステムの問題を修復する場合、暫定修正(PTF)を実動システムにインストールしなければならない場合があります。SUSEから提供されるパッケージは、特別なPTFキーに照らして署名されています。ただし、SUSE Linux Enterprise 11と異なり、SUSE Linux Enterprise 12システムでは、このキーはデフォルトでインポートされません。キーを手動でインポートするには、次のコマンドを使用します。
>
sudo
rpm --import \ /usr/share/doc/packages/suse-build-key/suse_ptf_key.asc
キーをインポートしたら、PTFパッケージをシステムにインストールできます。
9.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データベースを再構築するのがよいでしょう。
9.2.3 デルタRPMパッケージ #
デルタRPMパッケージには、RPMパッケージの新旧バージョン間の違いが含まれています。デルタRPMを古いRPMに適用すると、まったく新しいRPMになります。デルタRPMは、インストールされているRPMとも互換性があるので、古いRPMのコピーを保管する必要はありません。デルタRPMパッケージは、パッチRPMよりもさらに小さく、パッケージをインターネット上で転送するのに便利です。欠点は、デルタRPMが組み込まれたアップデート操作の場合、そのままのRPMまたはパッチRPMに比べて、CPUサイクルの消費が目立って多くなることです。
makedeltarpm
およびapplydelta
バイナリは、デルタRPMスイート(deltarpm
パッケージ)の一部であり、デルタRPMパッケージの作成と適用に際して役立ちます。次のコマンドを使用して、new.delta.rpm
というデルタRPMを作成できます。次のコマンドでは、old.rpm
およびnew.rpm
が存在することが前提となります。
>
sudo
makedeltarpm old.rpm new.rpm new.delta.rpm
古いパッケージがすでにインストールされていれば、applydeltarpm
を使用して、ファイルシステムから新たにRPMを構築できます。
>
sudo
applydeltarpm new.delta.rpm new.rpm
ファイルシステムにアクセスすることなく、古いRPMから構築するには、-r
オプションを使用します。
>
sudo
applydeltarpm -r old.rpm new.delta.rpm new.rpm
テクニカル詳細については、/usr/share/doc/packages/deltarpm/README
を参照してください。
9.2.4 RPM クエリー #
-q
オプションを使用すると、rpm
はクエリを開始し、(-p
オプションを追加することにより)RPMアーカイブを検査できるようにして、インストールされたパッケージのRPMデータベースでクエリを行えるようにします。必要な情報の種類を指定する複数のスイッチを使用できます。表9.1「基本的なRPMクエリオプション」を参照してください。
|
パッケージ情報 |
|
ファイルリスト |
|
ファイルFILEを含むパッケージでクエリーを行います(FILEにはフルパスを指定する必要があります)。 |
|
ステータス情報を含むファイルリスト( |
|
ドキュメントファイルだけをリストします ( |
|
設定ファイルだけをリストします( |
|
詳細情報を含むファイルリスト( |
|
他のパッケージが |
|
パッケージが要求する機能 |
|
インストールスクリプト(preinstall、postinstall、uninstall) |
たとえば、コマンドrpm -q -i wget
は、例9.2「rpm -q -i wget
」に示された情報を表示します。
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 15
オプション-f
が機能するのは、フルパスで完全なファイル名を指定した場合だけです。必要な数のファイル名を指定します。例:
>
rpm -q -f /bin/rpm /usr/bin/wget
rpm-4.14.1-lp151.13.10.x86_64
wget-1.19.5-lp151.4.1.x86_64
ファイル名の一部分しかわからない場合は、例9.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文字の記号を使用して、次の変更に関するいくつかのヒントを提供します。
|
MD5チェックサム |
|
ファイルサイズ |
|
シンボリックリンク |
|
変更時間 |
|
メジャーデバイス番号とマイナーデバイス番号 |
|
所有者 |
|
グループ |
|
モード (許可とファイルタイプ) |
設定ファイルの場合は、文字c
が表示されます。/etc/wgetrc
(wget
パッケージ)の変更例を以下に示します。
>
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つのバックアップのサイズは、1 GBの/usr
に対しておよそ1 MBです。
9.2.5 ソースパッケージのインストールとコンパイル #
すべてのソースパッケージには、拡張子.src.rpm
(ソースRPM)が付けられています。
ソースパッケージは、インストールメディアからハードディスクにコピーされ、YaSTを使用して展開できます。ただし、ソースパッケージは、パッケージマネージャでインストール済み([i]
)というマークは付きません。これは、ソースパッケージがRPMデータベースに入れられないためです。インストールされたオペレーティングシステムソフトウェアだけがRPMデータベースにリストされます。ソースパッケージを「インストールする」場合、ソースコードだけがシステムに追加されます。
/usr/src/packages
のrpm
とrpmbuild
では、以下のディレクトリが使用できる必要があります(/etc/rpmrc
のようなファイルでカスタム設定を指定している場合を除く)。
SOURCES
元のソース(
.tar.bz2
または.tar.gz
ファイルなど)およびディストリビューション固有の調整(ほとんど.diff
または.patch
ファイル)用です。SPECS
「ビルド」処理を制御する、メタMakefileに類似した
.spec
ファイル用です。BUILD
すべてのソースは、このディレクトリでアンパック、パッチ、およびコンパイルされます。
RPMS
完成したバイナリパッケージが格納されます。
SRPMS
ソースRPMが格納されます。
YaSTを使ってソースパッケージをインストールすると、必要なすべてのコンポーネントが/usr/src/packages
にインストールされます。ソースと調整はSOURCES
、関連する.spec
ファイルはSPECS
に格納されます。
システムコンポーネント(glibc
、rpm
など)で実験を行わないでください。システムが正しく動作しなくなります。
次の例は、wget.src.rpm
パッケージを使用します。ソースパッケージをインストールすると、次のようなファイルが生成されます。
/usr/src/packages/SOURCES/wget-1.19.5.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
-i
コマンドまたはrpm
-U
コマンドでインストールできます。rpm
を使用したインストールは、RPMデータベースに登場します。
specファイルのBuildRoot
ディレクティブは非推奨です。この機能がまだ必要な場合は、回避方法として--buildroot
オプションを使用してください。
9.2.6 buildによるRPMパッケージのコンパイル #
多くのパッケージにつきものの不都合は、ビルド処理中に不要なファイルが稼働中のシステムに追加されてしまうことです。これを回避するには、パッケージのビルド先の定義済みの環境を作成するbuild
を使用します。このchroot環境を確立するには、build
スクリプトが完全なパッケージツリーと共に提供されなければなりません。パッケージツリーは、NFS経由で、またはDVDから ハードディスク上で利用できるようにすることができます。build --rpms
DIRECTORYで、位置を指定します。rpm
と異なり、build
コマンドは、ソースディレクトリで.spec
ファイルを検索します。/media/dvd
の下でシステムにマウントされているDVDを使用して(上記の例と同様に)wget
をビルドするには、次のコマンドをroot
として使用します。
#
cd /usr/src/packages/SOURCES/#
mv ../SPECS/wget.spec .#
build --rpms /media/dvd/suse/ wget.spec
これで、最小限の環境が/var/tmp/build-root
に確立されます。パッケージは、この環境でビルドされます。処理が完了すると、ビルドされたパッケージは/var/tmp/build-root/usr/src/packages/RPMS
に格納されます。
build
スクリプトでは、他のオプションも多数使用できます。たとえば、スクリプトがユーザ独自のRPMを処理するようにするには、ビルド環境の初期化を省略するか、rpm
コマンドの実行を上記のビルド段階のいずれかに制限します。追加情報には、build
--help
を使用するか、build
のマニュアルページを参照してアクセスしてください。
9.2.7 RPMアーカイブとRPMデータベース用のツール #
Midnight Commander (mc
)は、RPMアーカイブの内容を表示し、それらの一部をコピーできます。アーカイブを仮想ファイルシステムとして表し、Midnight Commanderの通常のメニューオプションを使用できます。F3キーを使用してHEADER
を表示します。カーソルキーとEnterキーを使ってアーカイブ構造を表示します。F5キーを使用してアーカイブコンポーネントをコピーします。
フル機能のパッケージマネージャをYaSTモジュールとして使用できます詳細については、第8章 「ソフトウェアをインストールまたは削除する」を参照してください。
10 Snapperを使用したシステムの回復とスナップショット管理 #
Snapperにより、ファイルシステムスナップショットを作成および管理できます。ファイルシステムスナップショットは特定の時点でのファイルシステムの状態のコピーを保持できます。Snapperの標準セットアップは、システムの変更のロールバックを許可するように設計されています。ただし、これを使用して、ユーザデータのオンディスクバックアップを作成することもできます。この機能のベースとして、SnapperはBtrfsファイルシステム、またはXFSあるいはExt4ファイルシステムでシンプロビジョニングされたLVMボリュームを使用します。
SnapperにはコマンドラインインタフェースとYaSTインタフェースがあります。Snapperでは、次のタイプのファイルシステムでファイルシステムスナップショットを作成および管理できます。
Btrfs。サブボリュームのファイルシステムスナップショットをネイティブにサポートするLinux用のコピーオンライトファイルシステム。(サブボリュームは物理パーティション内で別個にマウント可能なファイルシステムです。)
Btrfs
スナップショットから起動することもできます。詳細については、10.3項 「スナップショットからのブートによるシステムロールバック」を参照してください。XFSまたはExt4でフォーマットされたシンプロビジョニングLVMボリューム。
Snapperを使用して、次のタスクを実行できます。
zypper
やYaSTで行ったシステムの変更を元に戻す。詳細については10.2項 「Snapperを使用した変更の取り消し」を参照してください。古いスナップショットからファイルを復元する。詳細については10.2.2項 「Snapperを使用したファイルの復元」を参照してください。
スナップショットからブートすることによってシステムをロールバックする。詳細については10.3項 「スナップショットからのブートによるシステムロールバック」を参照してください。
実行中のシステム内で、スナップショットを手動で作成および管理する。詳細については10.6項 「スナップショットの手動での作成と管理」を参照してください。
10.1 デフォルト設定 #
SUSE Linux Enterprise Server上のSnapperは、システム変更の「取り消しおよび回復ツール」として設定されています。デフォルトでは、SUSE Linux Enterprise Serverのルートパーティション(/
)はBtrfs
でフォーマットされています。ルートパーティション(/
)に十分な容量(約16 GB以上)がある場合、スナップショットの作成が自動的に有効になります。デフォルトでは、スナップショットは/
以外のパーティションでは無効になっています。
インストール中にSnapperを無効にした場合、後からいつでも有効にできます。そのためには、次のコマンドを実行して、ルートファイルシステムのデフォルトのSnapper設定を作成します。
>
sudo
snapper -c root create-config /
その後、10.1.4.1項 「スナップショットの有効化/無効化」の説明に従って、別のスナップショットタイプを有効にします。
Btrfsルートファイルシステムでは、スナップショットには、インストーラが提案するように設定されたサブボリュームと、少なくとも16 GBのパーティションサイズを持つファイルシステムが必要です。
スナップショットを作成すると、スナップショットとスナップショット元のファイルは、 いずれもファイルシステム内の同じブロックを指します。そのため、最初は、スナップショットが余分にディスク容量を占めることはありません。元のファイルシステムのデータが変更されると、変更されたデータブロックがコピーされ、古いデータブロックはスナップショットのように保持されます。このため、スナップショットは、変更されたデータと同じ容量を占めます。こうして、時間が経過するにつれて、スナップショットの領域は大きくなっていきます。その結果、スナップショットを含むBtrfs
ファイルシステムからファイルを削除しても、ディスクの空き容量が増えないことがあります。
スナップショットは常に、スナップショット作成元と同じパーティションまたはサブボリュームに保存されます。別のパーティションまたはサブボリュームにスナップショットを保存することはできません。
結果として、スナップショットを含むパーティションは、スナップショットを含まないパーティションよりも大きくする必要があります。具体的な容量は、保持するスナップショット数やデータの変更頻度によって大きく異なります。経験則として、パーティションには通常の2倍の容量を割り当てます。ディスク容量が不足しないようにするために、古いスナップショットは自動的にクリーンアップされます。詳細については、10.1.4.4項 「スナップショットのアーカイブの制御」を参照してください。
10.1.1 デフォルト設定 #
- 16 GBより大きいディスク
環境設定ファイル:
/etc/snapper/configs/root
USE_SNAPPER=yes
TIMELINE_CREATE=no
- 16 GB未満のディスク
設定ファイル: 作成されない
USE_SNAPPER=no
TIMELINE_CREATE=yes
10.1.2 スナップショットのタイプ #
スナップショット自体は技術的な意味では同じですが、トリガするイベントに基づいて、次の3種類のスナップショットを区別しています。
- タイムラインスナップショット
1時間ごとに1つのスナップショットが作成されます。古いスナップショットは自動的に削除されます。デフォルトで、最近10日間、10カ月間、10年間の最初のスナップショットが保持されます。YaST OSのインストール方法(デフォルト)を使用すると、ルートファイルシステムを除いてタイムラインスナップショットが有効になります。
- インストールスナップショット
YaSTまたはZypperで1つ以上のパッケージをインストールする場合、常にスナップショットのペアが作成されます。インストール開始前のスナップショット(「事前」)と、インストール完了後のスナップショット(「事後」)です。カーネルなどの重要なコンポーネントがインストールされた場合、スナップショットのペアは重要とマークされます(
important=yes
)。古いスナップショットは自動的に削除されます。デフォルトでは、最新の10個の重要なスナップショット、および最新の10個の「通常」のスナップショット(管理スナップショットを含む)が保持されます。インストールスナップショットはデフォルトで有効になっています。- 管理スナップショット
システムをYaSTで管理する場合、常にスナップショットのペアが作成されます。YaSTモジュール開始時のスナップショット(「事前」)と、モジュール終了時のスナップショット(「事後」)です。古いスナップショットは自動的に削除されます。デフォルトでは、最新の10個の重要なスナップショットと最新の10個の「通常」のスナップショット(インストールスナップショットを含む)が保持されます。管理スナップショットはデフォルトで有効になっています。
10.1.3 スナップショットから除外されるディレクトリ #
特定のディレクトリは、さまざまな理由により、スナップショットから除外する必要があります。次のリストは、除外されるすべてのディレクトリを示しています。
/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上に存在します。
/home
/home
が独立したパーティションに存在していない場合、ロールバック時のデータ損失を避けるために除外されます。/opt
サードパーティ製品は通常、
/opt
にインストールされます。ロールバック時にこれらのアプリケーションがアンインストールされるのを避けるために除外されます。/srv
WebおよびFTPサーバ用のデータが含まれています。ロールバック時にデータが失われるのを避けるために除外されます。
/tmp
スナップショットから除外される一時ファイルとキャッシュを含むすべてのディレクトリ。
/usr/local
このディレクトリは、ソフトウェアの手動インストール時に使用します。ロールバック時にこれらのインストール済みソフトウェアがアンインストールされるのを避けるために除外されます。
/var
このディレクトリには、ログ、一時キャッシュ、
/var/opt
のサードパーティ製品など、多くのバリアブルファイルが含まれており、仮想マシンのイメージとデータベースのデフォルトの場所です。したがって、このサブボリュームはスナップショットからすべてのこのバリアブルデータを除外するように作成され、コピーオンライトが無効になっています。
10.1.4 設定のカスタマイズ #
SUSE Linux Enterprise Serverには、適切なデフォルト設定が付属していて、ほとんどの使用事例ではこのままで十分です。ただし、スナップショットの自動作成およびスナップショットの維持管理のあらゆる側面をニーズに合わせて設定できます。
10.1.4.1 スナップショットの有効化/無効化 #
3つのスナップショットの種類(タイムライン、インストール、および管理)はそれぞれ独立して有効化または無効化することができます。
- タイムラインスナップショットの有効化/無効化
有効化.
snapper -c root set-config "TIMELINE_CREATE=yes"
無効化.
snapper -c root set-config "TIMELINE_CREATE=no"
YaST OSのインストール方法(デフォルト)を使用すると、ルートファイルシステムを除いてタイムラインスナップショットが有効になります。
- インストールスナップショットの有効化/無効化
有効化: パッケージ
snapper-zypp-plugin
無効化.
snapper-zypp-plugin
パッケージをアンインストールします。インストールスナップショットはデフォルトで有効になっています。
- 管理スナップショットの有効化/無効化
有効化:
/etc/sysconfig/yast2
でUSE_SNAPPER
をyes
に設定します。無効化.
/etc/sysconfig/yast2
でUSE_SNAPPER
をno
に設定します。管理スナップショットはデフォルトで有効になっています。
10.1.4.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>
match属性は、パターンがUnixシェルと同様のワイルドカードであるか( | |
指定されたパターンが一致し、対応するパッケージに重要のマークが付いている場合(カーネルパッケージなど)、そのスナップショットにも重要のマークが付きます。 | |
パッケージ名に一致するパターン。特殊文字は、 | |
この行は、無条件にすべてのパッケージに一致します。 |
この設定スナップショットでは、パッケージのインストール時に常にペアが作成されます(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>
10.1.4.3 新規サブボリュームの作成とマウント #
/
階層下に新規のサブボリュームを作成し、永続的にマウントすることができます。このようなサブボリュームはスナップショットから除外されます。既存のスナップショット内に作成してはいけません。ロールバック後にスナップショットを削除できなくなるためです。
SUSE Linux Enterprise Serverは、/@/
サブボリュームが設定されており、このサブボリュームは、/opt
、/srv
、/home
、その他の永続サブボリュームの独立したルートとしての役割を果たします。作成し、永続的にマウントする新規のサブボリュームは、この初期のルートファイルシステムに作成しなければなりません。
そのように設定するには、次のコマンドを実行します。この例では、新規サブボリューム、/usr/important
は/dev/sda2
から作成されます。
>
sudo
mount /dev/sda2 -o subvol=@ /mnt>
sudo
btrfs subvolume create /mnt/usr/important>
sudo
umount /mnt
/etc/fstab
の該当エントリは、次のようになります。
/dev/sda2 /usr/important btrfs subvol=@/usr/important 0 0
サブボリュームには、仮想化ディスクイメージ、データベースファイル、ログファイルなど、頻繁に変更されるファイルが含まれている場合があります。その場合、ディスクブロックの重複を避けるため、このボリュームのコピーオンライト機能を無効にすることを検討します。そのためには、/etc/fstab
でnodatacow
マウントオプションを使用します。
/dev/sda2 /usr/important btrfs nodatacow,subvol=@/usr/important 0 0
1つのファイルまたはディレクトリに対してコピーオンライトを無効にするには、コマンドchattr +C
PATH
を使用します。
10.1.4.4 スナップショットのアーカイブの制御 #
スナップショットはディスク容量を占有します。ディスク容量が不足してシステムが停止しないようにするために、古いスナップショットは自動的に削除されます。デフォルトでは、最大10個の重要なインストールスナップショットと管理スナップショット、および最大10個の標準のインストールスナップショットと管理スナップショットが保持されます。これらのスナップショットがルートファイルシステムのサイズの50%超を占有する場合、追加のスナップショットは削除されます。最低でも、4つの重要なスナップショットと2つの標準スナップショットは常に保持されます。
これらの値の変更方法については、10.5.1項 「既存の設定の管理」を参照してください。
10.1.4.5 シンプロビジョニングされたLVMボリュームでのSnapperの使用 #
Snapperは、Btrfs
ファイルシステムのスナップショット作成だけでなく、XFS、Ext4、またはExt3でフォーマットされたシンプロビジョニングLVMボリュームのスナップショット作成にも対応しています(通常のLVMボリュームのスナップショットには対応していません)。LVMボリュームに関する詳細および設定の手順については、Book “展開ガイド”, Chapter 11 “を参照してください。
”, Section 11.3 “LVMの設定”
シンプロビジョニングLVMボリュームでSnapperを使用するには、そのようにSnapperの設定を作成する必要があります。LVMで、--fstype=lvm(FILESYSTEM)
を使用してファイルシステムを指定する必要があります。ext3
、etx4
またはxfs
は、FILESYSTEMの有効な値です。例:
>
sudo
snapper -c lvm create-config --fstype="lvm(xfs)" /thin_lvm
10.5.1項 「既存の設定の管理」で説明したように、必要に応じてこの設定を調整できます。
10.2 Snapperを使用した変更の取り消し #
SUSE Linux Enterprise ServerのSnapperは、zypper
やYaSTで行った変更を取り消すことができるツールとしてあらかじめ設定されています。このために、Snapperはzypper
およびYaSTの各実行前後にスナップショットのペアを作成するように設定されています。また、Snapperを使用して、誤って削除または変更したシステムファイルを復元することもできます。このためには、ルートパーティションのタイムラインスナップショットを有効にする必要があります。詳細については、10.1.4.1項 「スナップショットの有効化/無効化」を参照してください。
上記の自動スナップショットは、デフォルトでルートパーティションとそのサブボリュームに対して設定されます。カスタム設定を作成すれば、/home
など、他のパーティションに対してスナップショット機能を使用できます。
スナップショットを操作してデータを復元する場合、Snapperが処理可能なシナリオとして、根本的に異なる次の2つのシナリオがあることを理解することが重要です。
- 変更の取り消し
次に説明されているように、変更を取り消す際には、2つのスナップショットが比較され、これらの2つのスナップショット間の変更が取り消されます。この方法を使用して、復元する必要があるファイルを明示的に選択できます。
- ロールバック
10.3項 「スナップショットからのブートによるシステムロールバック」で説明されているように、ロールバックを実行すると、システムはスナップショットが作成された状態にリセットされます。
変更を取り消す場合は、現在のシステムとスナップショットを比較することもできます。このような比較から「すべての」ファイルを復元すると、ロールバックを実行した場合と同じ結果になります。ただし、ロールバックについては、10.3項 「スナップショットからのブートによるシステムロールバック」で説明されている方法を使用することをお勧めします。この方法はより高速で、ロールバック実行前にシステムを確認できるためです。
スナップショットを作成する際に、データの整合性を確保するメカニズムがありません。スナップショットを作成するのと同時にファイルが書き込まれると(データベースなど)、ファイルが破損したり、ファイルへの書き込みが部分的になったりします。このようなファイルを復元すると、問題が発生することがあります。また、/etc/mtab
などの特定のシステムファイルは復元しないでください。このため、「必ず」、変更されたファイルとその差分をよく確認してください。どうしても元に戻すことが必要なファイルのみ復元してください。
10.2.1 YaSTおよびZypperによる変更の取り消し #
インストール時にルートパーティションをBtrfs
で設定すると、Snapper(YaSTまたはZypperによる変更のロールバックがあらかじめ設定されている)が自動的にインストールされます。YaSTモジュールまたはZypperトランザクションを開始するたびに、2つのスナップショットが作成されます。モジュール開始前のファイルシステムの状態をキャプチャした「事前スナップショット」と、モジュール完了後の状態をキャプチャした「事後スナップショット」です。
YaSTのモジュールまたはsnapper
snapperコマンドラインツールを使用して、「事前スナップショット」からファイルを復元し、YaST/Zypperによる変更を元に戻すことができます。また、2つのスナップショットを比較して、どのファイルが変更されているか調べることができます。2つのバージョンのファイルの違いを表示することもできます(diff)。
YaSTの
セクションにある モジュールを起動するか、「yast2 snapper
」と入力します。リストから事前スナップショットと事後スナップショットのペアを選択します。YaSTのスナップショットペアもZypperのスナップショットペアも、種類は
です。YaSTのスナップショットの場合は に「zypp(y2base)
」と表示され、Zypperのスナップショットの場合は「zypp(zypper)
」と表示されます。ファイルのリストを確認します。事前および事後のファイル間の「差異」を表示するには、リストからファイルを選択します。
1つまたは複数のファイルを復元するには、該当するチェックボックスをオンにして、関連するファイルまたはディレクトリを選択します。
をクリックし、 をクリックして操作を確認します。単一のファイルを復元する場合は、ファイル名をクリックして差分を表示します。
をクリックし、 をクリックして選択内容を確認します。
snapper
コマンドによる変更の取り消し #snapper list -t pre-post
を実行して、YaSTおよびZypperのスナップショットのリストを取得します。YaSTのスナップショットの場合は に「yast MODULE_NAME
」と表示され、Zypperのスナップショットの場合は「zypp(zypper)
」と表示されます。>
sudo
snapper list -t pre-post Pre # | Post # | Pre Date | Post Date | Description ------+--------+-------------------------------+-------------------------------+-------------- 311 | 312 | Tue 06 May 2018 14:05:46 CEST | Tue 06 May 2018 14:05:52 CEST | zypp(y2base) 340 | 341 | Wed 07 May 2018 16:15:10 CEST | Wed 07 May 2018 16:15:16 CEST | zypp(zypper) 342 | 343 | Wed 07 May 2018 16:20:38 CEST | Wed 07 May 2018 16:20:42 CEST | zypp(y2base) 344 | 345 | Wed 07 May 2018 16:21:23 CEST | Wed 07 May 2018 16:21:24 CEST | zypp(zypper) 346 | 347 | Wed 07 May 2018 16:41:06 CEST | Wed 07 May 2018 16:41:10 CEST | zypp(y2base) 348 | 349 | Wed 07 May 2018 16:44:50 CEST | Wed 07 May 2018 16:44:53 CEST | zypp(y2base) 350 | 351 | Wed 07 May 2018 16:46:27 CEST | Wed 07 May 2018 16:46:38 CEST | zypp(y2base)スナップショットのペア間で変更されたファイルのリストを取得するには、以下を実行します。
snapper status
PREPOSTをクリックします。内容が変更されたファイルには のマーク、追加されたファイルには のマーク、削除されたファイルには のマークが付いています。>
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特定のファイルの差異を表示するには、以下を実行します。
snapper diff
PRE..POST FILENAME。FILENAMEを指定しない場合は、すべてのファイルの差異が表示されます。>
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 [...]1つまたは複数のファイルを復元するには、以下を実行します。
snapper -v undochange
PRE..POST FILENAMES。FILENAMESを指定しない場合は、変更されたすべてのファイルが復元されます。>
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の
ツールを使用して、ユーザを削除することを強くお勧めします。10.2.2 Snapperを使用したファイルの復元 #
インストールスナップショットおよび管理スナップショットとは別に、Snapperはタイムラインスナップショットを作成します。このバックアップ用スナップショットを使用して、誤って削除したファイルを復元したり、ファイルの以前のバージョンを復元したりできます。Snapperの差分抽出機能を使用して、特定の時点でどのような変更が加えられたのかを調べることもできます。
ファイルの復元機能は、特に、デフォルトではスナップショットが作成されないサブボリュームまたはパーティションに存在するデータにとって重要です。ホームディレクトリからファイルを復元できるようにするには、たとえば、/home
用に、自動的にタイムラインスナップショットを作成する別個のSnapper設定を作成します。手順については、10.5項 「Snapper設定の作成と変更」を参照してください。
ルートファイルシステムから作成されたスナップショット(Snapperのルート設定で定義されています)を使用して、システムロールバックを実行できます。このようなロールバックを実行する場合にお勧めする方法は、そのスナップショットからブートしてからロールバックを実行する方法です。詳細については10.3項 「スナップショットからのブートによるシステムロールバック」を参照してください。
次に説明するように、ルートファイルシステムスナップショットからすべてのファイルを復元することによってロールバックを実行することもできます。ただし、これはお勧めできません。たとえば、/etc
ディレクトリから環境設定ファイルなど単一のファイルを復元できますが、スナップショットからファイルの完全なリストを復元することはできません。
この制限は、ルートファイルシステムから作成されたスナップショットにのみ影響します。
YaSTの
セクションから、または「yast2 snapper
」と入力して モジュールを起動します。スナップショットを選択するための
を選択します。ファイルを復元するためのタイムラインスナップショットを選択し
を選択します。タイムラインスナップショットは、タイプが で、説明の値が であるスナップショットです。ファイル名をクリックしてテキストボックスからファイルを選択します。スナップショットバージョンと現在のシステムとの差分が表示されます。復元対象ファイルを選択するチェックボックスをオンにします。復元するすべてのファイルに対してこれを行います。
snapper
コマンドを使用したファイルの復元 #次のコマンドを実行して、特定の設定のタイムラインスナップショットのリストを取得します。
>
sudo
snapper -c CONFIG list -t single | grep timelineCONFIGは、既存のSnapper設定に置き換える必要があります。
snapper list-configs
を使用してリストを表示します。次のコマンドを実行して、指定のスナップショットの変更ファイルのリストを取得します。
>
sudo
snapper -c CONFIG status SNAPSHOT_ID..0SNAPSHOT_IDをファイルの復元元のスナップショットIDで置き換えます。
オプションで、次のコマンドを実行して、現在のファイルバージョンとスナップショットからのバージョンとの差分を一覧にします。
>
sudo
snapper -c CONFIG diff SNAPSHOT_ID..0 FILE NAME<FILE NAME>を指定しない場合は、すべてのファイルの差分が表示されます。
1つ以上のファイルを復元するには、以下を実行します
>
sudo
snapper -c CONFIG -v undochange SNAPSHOT_ID..0 FILENAME1 FILENAME2ファイル名を指定しない場合は、変更されたすべてのファイルが復元されます。
10.3 スナップショットからのブートによるシステムロールバック #
SUSE Linux Enterprise Serverに含まれているGRUB 2バージョンは、Btrfsスナップショットからブートできます。Snapperのロールバック機能と併用することで、誤設定されたシステムを回復できます。デフォルトのSnapper設定(root
)で作成されたスナップショットのみがブート可能です。
SUSE Linux Enterprise Server 15 SP6の時点では、システムのロールバックは、ルートパーティションのデフォルトのサブボリューム設定が変更されていない場合にのみサポートされます。
スナップショットをブートする場合、スナップショットに含まれているファイルシステムの該当部分が読み込み専用でマウントされます。スナップショットから除外されている他のすべてのファイルシステムと該当部分は読み書き可能でマウントされ、変更できます。
スナップショットを操作してデータを復元する場合、Snapperが処理可能なシナリオとして、根本的に異なる次の2つのシナリオがあることを理解することが重要です。
- 変更の取り消し
10.2項 「Snapperを使用した変更の取り消し」で説明されているように、変更を取り消す場合は、2つのスナップショットが比較され、これらの2つのスナップショット間の変更が元に戻されます。この方法を使用すると、選択したファイルを復元から明示的に除外することもできます。
- ロールバック
次に説明する方法でロールバックを実行すると、システムはスナップショットが作成された状態にリセットされます。
ブート可能なスナップショットからロールバックを行うには、次の要件を満たす必要があります。デフォルトインストールを行った場合、システムはそのように設定されます。
ルートファイルシステムは、Btrfsである必要があります。LVMボリュームスナップショットからのブートはサポートされていません。
ルートファイルシステムは、単一のデバイス上にある必要があります。確認するには、
sudo /sbin/btrfs filesystem show
を実行します。Total devices 1
と報告される必要があります。1
台を超えるデバイスが表示されている場合、セットアップはサポートされません。注記: ロールバックから除外されるディレクトリ/srv
などスナップショットから除外されるディレクトリ(完全なリストについては、10.1.3項 「スナップショットから除外されるディレクトリ」を参照)は、別のデバイス上に存在していても構いません。システムは、インストールされたブートローダを介してブート可能である必要があります。
サブボリューム
/
の内容のみがロールバックされます。他のサブボリュームを含めることはできません。
ブート可能なスナップショットからのロールバックを実行するには、次の手順に従います。
システムをブートします。ブートメニューから、
を選択して、ブートするスナップショットを選択します。スナップショットのリストが日別に一覧にされます。最新のスナップショットが先頭に表示されます。システムにログインします。すべてが予期したとおりに動作しているかどうかを注意深く確認します。スナップショットの一部であるディレクトリに書き込むことはできないので注意してください。他のディレクトリに書き込むデータは、次に行う操作にかかわらず、失われることは「ありません」。
ロールバックを実行するかどうかに応じて、次のステップを選択します。
システムが、ロールバックを実行したくない状態になっている場合は、再起動して現在のシステム状態にブートします。その後、別のスナップショットを選択するか、レスキューシステムを開始することができます。
ロールバックを実行するには、次のコマンドを実行し
>
sudo
snapper rollbackその後、再起動します。ブート画面で、デフォルトのブートエントリを選択して、復元されたシステムで再起動します。ロールバック前のファイルシステムの状態のスナップショットが作成されます。rootのデフォルトのサブボリュームは、新しい読み書きスナップショットに置き換えられます。詳細については、10.3.1項 「ロールバック後のスナップショット」を参照してください。
-d
オプションを使用してスナップショットの説明を追加すると役に立ちます。例:New file system root since rollback on DATE TIME
スナップショットがインストール時に無効になっていない場合、最初のシステムインストールの最後に初期のブート可能スナップショットが作成されます。このスナップショットをブートすることで、いつでもその状態に戻ることができます。スナップショットは、after installation
という記述で識別できます。
ブート可能スナップショットは、サービスパックや新しいメジャーリリースへのシステムアップグレードの開始時にも作成されます(スナップショットが無効になっていない場合のみ)。
10.3.1 ロールバック後のスナップショット #
ロールバックの実行前に、動作中のファイルシステムのスナップショットが作成されます。この説明では、ロールバックで復元されたスナップショットのIDを参照します。
ロールバックで作成されたスナップショットは、Cleanup
属性に値number
が付きます。したがって、設定されているスナップショット数に達すると、ロールバックスナップショットは自動的に削除されます。詳細については、10.7項 「スナップショットの自動クリーンアップ」を参照してください。スナップショットに重要なデータが含まれている場合は、スナップショットが削除される前にデータを抽出してください。
10.3.1.1 ロールバックスナップショットの例 #
たとえば、新規インストール後に、システムで次のスナップショットが使用可能であるとします。
#
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サブボリュームであるため、再起動後にシステムになります。
#
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 | | | |
10.3.2 スナップショットブートエントリのアクセスと識別 #
スナップショットからブートするには、マシンを再起動して、↓キーおよび↑キーを使用して移動し、Enterキーを押して、選択したスナップショットを有効にします。ブートメニューからスナップショットを有効にしても、マシンは即座に再起動されません。選択したスナップショットのブートローダが開くだけです。
を選択します。ブート可能なすべてのスナップショットをリストした画面が開きます。最も新しいスナップショットが先頭に表示され、最も古いものは最後に表示されます。詳細については、https://www.suse.com/support/kb/doc/?id=000020602を参照してください。
ブートローダの各スナップショットエントリの名前は、命名規則に従っているため、容易に識別できます。
[*]1OS2 (KERNEL3,DATE4TTIME5,DESCRIPTION6)
スナップショットに | |
オペレーティングシステムラベル。 | |
日付フォーマット( | |
時刻フォーマット( | |
このフィールドには、スナップショットの説明が入ります。手動で作成されたスナップショットの場合、この説明は |
スナップショットの説明フィールドのデフォルトの文字列をカスタム文字列に置き換えることができます。この機能は、自動的に作成された説明が不十分な場合や、ユーザが入力した説明が長すぎる場合などに役立ちます。カスタム文字列、STRINGをスナップショット、NUMBERに設定するには、次のコマンドを使用します。
>
sudo
snapper modify --userdata "bootloader=STRING" NUMBER
説明は25文字未満にしてください。このサイズを超える部分はブート画面では一切読めません。
10.3.3 制限 #
システム全体をスナップショット作成時と同一の状態に復元する、システムの「完全な」ロールバックは不可能です。
10.3.3.1 スナップショットから除外されるディレクトリ #
ルートファイルシステムのスナップショットには、すべてのディレクトリが含まれるわけではありません。詳細および理由については、10.1.3項 「スナップショットから除外されるディレクトリ」を参照してください。そのため、一般的にこれらのディレクトリのデータは復元されないため、次の制限が生じます。
- ロールバック後、アドオンおよびサードパーティソフトウェアを使用できない場合がある
スナップショットから除外されるサブボリューム(
/opt
など)にデータをインストールするアプリケーションやアドオンは、アプリケーションデータの他の部分がスナップショットに含まれるサブボリュームにもインストールされている場合、ロールバック後に動作しない場合があります。この問題を解決するには、アプリケーションまたはアドオンを再インストールします。- ファイルアクセスの問題
スナップショットと現在のシステムでファイルのパーミッションまたは所有権、あるいはその両方がアプリケーションによって変更されている場合、そのアプリケーションは該当するファイルにアクセスできない場合があります。ロールバック後、影響を受けるファイルのパーミッションまたは所有権、あるいはその両方をリセットします。
- 互換性のないデータ形式
サービスまたはアプリケーションがスナップショットと現在のシステムとの間に新しいデータ形式を設定した場合、ロールバック後、そのアプリケーションは影響を受けたデータファイルを読み込めない場合があります。
- コードとデータが混在するサブボリューム
/srv
のようなサブボリュームには、コードとデータが混在する場合があります。ロールバックの結果、コードが機能しなくなる場合があります。たとえば、PHPのバージョンがダウングレードされ、WebサーバのPHPスクリプトが壊れる場合があります。- ユーザデータ量
ロールバックによりシステムからユーザが削除された場合、これらのユーザが、スナップショットから除外されているディレクトリ内で所有していたデータは削除されません。同じユーザIDを持つユーザが作成された場合、そのユーザは該当ファイルを継承します。
find
のようなツールを使用して、孤立したファイルを検索して削除します。
10.3.3.2 ブートローダのデータはロールバックできない #
ブートローダはロールバックできません。これは、ブートローダのすべての「ステージ」が整合している必要があるためです。これは、/boot
のロールバックを実行する際には保証できません。
10.4 ユーザホームディレクトリでのSnapperの有効化 #
いくつかのユースケースをサポートする、ユーザの/home
ディレクトリのスナップショットを有効にできます。
個々のユーザは独自のスナップショットおよびロールバックを管理できます。
システムユーザ、たとえば、設定ファイル、ドキュメントなどのコピーを追跡したいデータベース、システム、およびネットワーク管理者。
SambaはホームディレクトリおよびBtrfsバックエンドと共有します。
各ユーザのディレクトリは/home
のBtrfsサブボリュームです。これを手動で設定できます(10.4.3項 「ホームディレクトリでのスナップショットの手動有効化」を参照)。ただし、pam_snapper
を使用する方がより便利です。pam_snapper
パッケージでは、pam_snapper.so
モジュールおよびヘルパースクリプトがインストールされ、ユーザの作成およびSnapper設定が自動化されます。
pam_snapper
では、useradd
コマンド、プラグ可能認証モジュール(PAM)、およびSnapperとの統合が提供されます。デフォルトでは、ユーザログイン時およびログアウト時にスナップショットが作成され、特定のユーザは延長された期間にログインしたままであるため、タイムベースのスナップショットも作成されます。通常のSnapperコマンドと設定ファイルを使用して、デフォルトを変更できます。
10.4.1 pam_snapperのインストールとユーザの作成 #
最も簡単な方法は、Btrfsでフォーマットされた新しい/home
ディレクトリで既存のユーザなしで開始する方法です。両方のノードに pam_snapper
:
#
zypper in pam_snapper
/etc/pam.d/common-session
に次の行を追加します。
session optional pam_snapper.so
/usr/lib/pam_snapper/pam_snapper_useradd.sh
スクリプトを使用して、新しいユーザとホームディレクトリを作成します。デフォルトで、スクリプトはドライランを実行します。スクリプトを編集し、DRYRUN=1
をDRYRUN=0
に変更します。これで、新しいユーザを作成できます。
#
/usr/lib/pam_snapper/pam_snapper_useradd.sh \
username group passwd=password
Create subvolume '/home/username'
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
/etc/skel
からのファイルは最初のログイン時にユーザのホームディレクトリにコピーされます。ユーザの設定がSnapper設定を一覧表示して作成されていることを確認します。
#
snapper list --all
Config: home_username, subvolume: /home/username
Type | # | Pre # | Date | User | Cleanup | Description | Userdata
-------+---+-------+------+------+---------+-------------+---------
single | 0 | | | root | | current |
時間が経過するにつれて、この出力にはスナップショットのリストが取り込まれ、ユーザは標準のSnapperコマンドを管理できます。
10.4.2 ユーザを削除する #
/usr/lib/pam_snapper/pam_snapper_userdel.sh
スクリプトを使用してユーザを削除します。デフォルトでは、ドライランを実行し、それを編集して、DRYRUN=1
をDRYRUN=0
に変更します。ユーザ、ユーザのホームサブボリューム、Snapper設定が削除され、すべてのスナップショットが削除されます。
#
/usr/lib/pam_snapper/pam_snapper_userdel.sh username
10.4.3 ホームディレクトリでのスナップショットの手動有効化 #
Snapperを使用してユーザのホームディレクトリを手動で設定するためのステップがあります。/home
は、Btrfsでフォーマットされる必要があり、ユーザはまだ作成されていません。
#
btrfs subvol create /home/username#
snapper -c home_username create-config /home/username#
sed -i -e "s/ALLOW_USERS=\"\"/ALLOW_USERS=\"username\"/g" \ /etc/snapper/configs/home_username#
yast users add username=username home=/home/username password=password#
chown username.group /home/username#
chmod 755 /home/username/.snapshots
10.5 Snapper設定の作成と変更 #
Snapperの動作は、各パーティションまたはBtrfs
サブボリュームに固有の設定ファイルで定義できます。これらの設定ファイルは、/etc/snapper/configs/
に保存されます。
ルートファイルシステムに十分な容量(約12GB)がある場合、ルートファイルシステム(/
)のスナップショットはインストール時に自動的に有効になります。対応するデフォルト設定はroot
という名前です。これにより、YaSTおよびZypperのスナップショットが作成および管理されます。デフォルト値のリストについては、10.5.1.1項 「環境設定データ」を参照してください。
10.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の モジュールを使用して、これらのスナップショットからファイルを復元できます。YaSTの場合は を選択する必要があります。snapper
の場合は、グローバルスイッチ-c
を使用して設定を指定する必要があります(例: snapper -c myconfig
list
)。
新しいSnapper設定を作成するには、snapper
create-config
を実行します。
>
sudo
snapper -c www-data1 create-config /srv/www2
このコマンドにより、新しい設定ファイル/etc/snapper/configs/www-data
が作成され、/etc/snapper/config-templates/default
から取得されたデフォルト値が使用されます。これらのデフォルトの調整方法については、10.5.1項 「既存の設定の管理」を参照してください。
新しい設定ファイルのデフォルト値は/etc/snapper/config-templates/default
から取得されます。独自のデフォルトセットを使用する場合は、同じディレクトリ内にこのファイルのコピーを作成し、必要に応じて調整してください。作成したファイルを使用するには、create-configコマンドで-t
オプションを指定します。
>
sudo
snapper -c www-data create-config -t MY_DEFAULTS /srv/www
10.5.1 既存の設定の管理 #
snapper
コマンドは、既存の設定を管理するためのサブコマンドを備えています。これらの設定を一覧、表示、削除、および変更することができます。
- 設定の一覧表示
既存の設定をすべて取得するには、
snapper list-configs
サブコマンドを使用します。>
sudo
snapper list-configs Config | Subvolume -------+---------- root | / usr | /usr local | /local- 設定の表示
指定した設定を表示するには、
snapper -c CONFIG get-config
サブコマンドを使用します。CONFIGをsnapper list-configs
で示される設定名のいずれかに置き換えます。環境設定オプションの詳細については、10.5.1.1項 「環境設定データ」を参照してください。デフォルトの設定を表示するには、次のコマンドを実行します。
>
sudo
snapper -c root get-config- 設定の変更
指定した設定のオプションを変更するには、
snapper -c CONFIG set-config OPTION=VALUE
サブコマンドを使用します。CONFIGをsnapper list-configs
で示される設定名のいずれかに置き換えます。OPTIONおよびVALUEに指定可能な値は、10.5.1.1項 「環境設定データ」に一覧にされています。- 設定の削除
設定を削除するには、
snapper -c CONFIG delete-config
サブコマンドを使用します。CONFIGをsnapper list-configs
で示される設定名のいずれかに置き換えます。
10.5.1.1 環境設定データ #
各設定には、コマンドラインから変更可能なオプションのリストが含まれています。次に、各オプションの詳細を示します。値を変更するには、snapper -c CONFIG
set-config
"KEY=VALUE"
を実行します。
ALLOW_GROUPS
、ALLOW_USERS
通常のユーザにスナップショットを使用するパーミッションを付与します。詳細については、10.5.1.2項 「通常ユーザとしてのSnapperの使用」を参照してください。
デフォルトの設定は
""
です。BACKGROUND_COMPARISON
事前および事後スナップショットを、作成後にバックグラウンドで比較するかどうかを定義します。
デフォルトの設定は
"yes"
です。EMPTY_*
同一の事前および事後スナップショットを持つスナップショットペアのクリーンアップアルゴリズムを定義します。詳細については10.7.3項 「違いがないスナップショットのペアのクリーンアップ」を参照してください。
FSTYPE
パーティションのファイルシステムタイプ。変更しません。
デフォルトの設定は
"btrfs"
です。NUMBER_*
インストールおよび管理スナップショットのクリーンアップアルゴリズムを定義します。詳細については10.7.1項 「番号付きスナップショットのクリーンアップ」を参照してください。
QGROUP
/SPACE_LIMIT
クリーンアップアルゴリズムにクォータサポートを追加します。詳細については10.7.5項 「ディスククォータサポートの追加」を参照してください。
SUBVOLUME
スナップショットを作成するパーティションまたはサブボリュームのマウントポイント。変更しません。
デフォルトの設定は
"/"
です。SYNC_ACL
Snapperが通常ユーザによって使用される場合(10.5.1.2項 「通常ユーザとしてのSnapperの使用」を参照)、ユーザは
.snapshot
ディレクトリにアクセスして、そのディレクトリ内のファイルを読み取ることができる必要があります。SYNC_ACLをyes
に設定した場合、Snapperは自動的に、ALLOW_USERSまたはALLOW_GROUPSエントリからACLを使用してユーザとグループがファイルにアクセスできるようにします。デフォルトの設定は
"no"
です。TIMELINE_CREATE
yes
(はい)に設定されている場合は、毎時スナップショットが作成されます。有効値:yes
,no
。デフォルトの設定は
"no"
です。TIMELINE_CLEANUP
/TIMELINE_LIMIT_*
タイムラインスナップショットのクリーンアップアルゴリズムを定義します。詳細については10.7.2項 「タイムラインスナップショットのクリーンアップ」を参照してください。
10.5.1.2 通常ユーザとしてのSnapperの使用 #
デフォルトでは、root
しかSnapperを使用できません。しかし、以下のような場合、特定のグループまたはユーザがスナップショットを作成したり、スナップショットを使って変更を取り消したりできる必要があります。
Webサイト管理者が
/srv/www
のスナップショットを作成したい場合ユーザが自身のホームディレクトリのスナップショットを作成したい場合
このような目的のために、ユーザまたは/およびグループに許可を付与するSnapper設定を作成できます。対応する.snapshots
ディレクトリは、指定されたユーザによって読み込みおよびアクセス可能である必要があります。このための最も簡単な方法は、SYNC_ACLオプションをyes
(はい)に設定することです。
次のすべての手順はroot
として実行する必要があります。
Snapper設定がまだ存在しない場合は、ユーザがSnapperを使用できるようにする必要のあるパーティションまたはサブボリュームに対してSnapper設定を作成します。手順については、10.5項 「Snapper設定の作成と変更」を参照してください。例:
>
sudo
snapper --config web_data create /srv/www/etc/snapper/configs/CONFIG
に設定ファイルを作成します。CONFIGは、前の手順で-c/--config
を使用して指定される値です(/etc/snapper/configs/web_data
など)。必要に応じて調整します。詳細については、10.5.1項 「既存の設定の管理」を参照してください。ALLOW_USERS
とALLOW_GROUPS
、またはその一方の値を設定し、ユーザやグループにパーミッションを与えます。複数のエントリはSpaceで区切ってください。たとえば、ユーザwww_admin
にパーミッションを与えるには、次のように入力します。>
sudo
snapper -c web_data set-config "ALLOW_USERS=www_admin" SYNC_ACL="yes"これで、指定されたユーザやグループが特定のSnapper設定を使用できます。以下のように
list
コマンドを使ってテストできます。www_admin:~ >
snapper -c web_data list
10.6 スナップショットの手動での作成と管理 #
Snapperは設定によって自動的にスナップショットを作成および管理するだけのものではありません。コマンドラインツールまたはYaSTモジュールを使用して、手動でスナップショットのペア(「事前および事後」)や単一のスナップショットを作成することもできます。
Snapperのすべての操作は既存の設定に対して実行されます(詳細は10.5項 「Snapper設定の作成と変更」を参照)。スナップショットを作成するには、対象のパーティションまたはボリュームに対して設定が存在する必要があります。デフォルトで、システム設定(root
)が使用されます。独自の設定に対してスナップショットを作成または管理するには、明示的にその設定を選択する必要があります。YaSTの ドロップダウンボックスを使用するか、コマンドラインで-c
を指定します(snapper -c MYCONFIG
COMMAND
)。
10.6.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(種類):スナップショットの種類です。詳細は10.6.1.1項 「スナップショットの種類」を参照してください。このデータは変更できません。
Number(番号):スナップショットの一意の番号。このデータは変更できません。
Pre Number(前番号):対応する事前スナップショットの番号を指定します。事後スナップショットにのみ適用されます。このデータは変更できません。
Description(説明):スナップショットの説明です。
Userdata (ユーザデータ): カンマ区切りの「キー=値」のリスト形式でカスタムデータを指定できる、拡張用の項目です。(例:
reason=testing, project=foo
)。このフィールドは、スナップショットに重要のマークを付ける場合(important=yes
)や、スナップショットを作成したユーザを一覧にする場合(user=tux)にも使用されます。Cleanup-Algorithm(クリーンアップアルゴリズム):スナップショットのクリーンアップアルゴリズムです。詳細は10.7項 「スナップショットの自動クリーンアップ」を参照してください。
10.6.1.1 スナップショットの種類 #
Snapperには、事前(pre)、事後(post)、および単一(single)の3種類のスナップショットがあります。これらは物理的には同じものですが、Snapperでは別のものとして扱われます。
pre
変更前のファイルシステムのスナップショットです。各
pre
スナップショットはpost
スナップショットに対応しています。たとえば、これはYaST/Zypperの自動スナップショットに使用されます。post
変更後のファイルシステムのスナップショットです。各
post
スナップショットはpre
スナップショットに対応しています。たとえば、これはYaST/Zypperの自動スナップショットに使用されます。single
スタンドアロンのスナップショットです。たとえば、これは1時間ごとの自動スナップショットに使用されます。これは、スナップショットを作成する際のデフォルトの種類です。
10.6.1.2 クリーンアップアルゴリズム #
Snapperには、古いスナップショットのクリーンアップアルゴリズムが3種類あります。このアルゴリズムは、日次のcron
ジョブとして実行されます。保持するさまざまなタイプのスナップショットの数を、Snapper設定で定義することができます(詳細は10.5.1項 「既存の設定の管理」を参照)。
- number(番号)
スナップショットが特定の数に達すると、古いスナップショットを削除します。
- timeline (タイムライン)
特定の期間が経過した古いスナップショットは削除しますが、毎時、毎日、毎月、および毎年のスナップショットを複数保持します。
- empty-pre-post(事前事後の差分なし)
事前と事後のスナップショットに差分がない場合、そのペアを削除します。
10.6.2 スナップショットの作成 #
スナップショットを作成するには、snapper create
を実行するか、YaSTモジュール の をクリックします。以下は、コマンドラインを使ってスナップショットを作成する場合の例です。Snapper用のYaSTインタフェースはここでは明示的に説明されていませんが、等価な機能を提供しています。
後で識別しやすくするため、わかりやすい説明を指定しておいてください。オプション--userdata
を介して追加情報を指定することもできます。
snapper create --from 17 --description "with package2"
既存のスナップショットからスタンドアロンスナップショット(シングルタイプ)を作成します。これは、
snapper list
からのスナップショットの番号で指定されます。(これはSnapperバージョン0.8.4以降に適用されます。)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"
番号
30
のpre
スナップショットとペアになるpost
スナップショットを作成します。「事前」と「事後」の状態を保存するために使用されるスナップショットペアを作成するために必要な、2番目のコマンドです。スナップショットには重要のマークが付きます。snapper create --command COMMAND --description "Before and after COMMAND"
COMMANDの実行前後に自動的にスナップショットを作成します。このオプションを使用できるのは、コマンドラインでsnapperを使用する場合のみです。
10.6.3 スナップショットのメタデータ修正 #
Snapperでは、スナップショットの説明、クリーンアップアルゴリズム、およびユーザデータを修正できます。それ以外のメタデータは変更できません。以下は、コマンドラインを使ってスナップショットを修正する場合の例です。YaSTインタフェースを使用している場合、これらの例は簡単に採用できます。
コマンドラインでスナップショットを修正するには、スナップショットの番号がわかっている必要があります。snapper list
を実行すると、すべてのスナップショットとその番号が表示されます。
YaSTの
モジュールでは、すでにすべてのスナップショットのリストが表示されています。リストからスナップショットを選択し、 をクリックします。snapper modify --cleanup-algorithm "timeline"
10デフォルト(
root
)設定のスナップショット10番のメタデータを修正します。クリーンアップアルゴリズムがtimeline
に設定されます。snapper --config home modify --description "daily backup" -cleanup-algorithm "timeline" 120
カスタム設定
home
のスナップショット120番のメタデータを修正します。新しい説明が設定され、クリーンアップアルゴリズムを無しに設定します。
10.6.4 スナップショットの削除 #
YaSTの
モジュールを使用してスナップショットを削除するには、リストからスナップショットを選択して をクリックします。
コマンドラインツールを使ってスナップショットを削除するには、スナップショットの番号が分かっている必要があります。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ジョブでも自動的に削除されます。詳細については、10.6.1.2項 「クリーンアップアルゴリズム」を参照してください。
10.7 スナップショットの自動クリーンアップ #
スナップショットはディスク容量を占有し、時間が経つにつれて、スナップショットが占有するディスク容量が増える可能性があります。ディスク容量が不足しないようにするために、Snapperは、古いスナップショットを自動的に削除するためのアルゴリズムを備えています。これらのアルゴリズムは、タイムラインスナップショットと番号付きスナップショット(管理スナップショットとインストールスナップショットのペア)を区別します。各タイプに対して、保持するスナップショットの数を指定できます。
そのほかに、オプションでディスク容量クォータを指定し、スナップショットが占有可能な最大ディスク容量を定義することもできます。また、事前スナップショットと事後スナップショットのペアに違いがない場合、それらのペアを自動的に削除することもできます。
クリーンアップアルゴリズムは常に1つのSnapper設定にバインドされるため、各設定に対してアルゴリズムを設定する必要があります。特定のスナップショットが自動的に削除されないようにするには、 スナップショットを削除から保護することができますか? を参照してください。
デフォルトのセットアップ(root
)は、番号付きスナップショットと、空の事前/事後スナップショットのペアのクリーンアップを実行するように設定されています。クォータサポートが有効になっている場合、スナップショットは、ルートパーティションの使用可能なディスク容量を50%までしか占有できません。タイムラインスナップショットはデフォルトで無効になっているため、タイムラインのクリーンアップアルゴリズムも無効になっています。
10.7.1 番号付きスナップショットのクリーンアップ #
番号付きスナップショット(管理スナップショットとインストールスナップショットのペア)のクリーンアップは、Snapper設定の次のパラメータで制御します。
NUMBER_CLEANUP
インストールスナップショットと管理スナップショットのペアのクリーンアップを有効または無効にします。有効にすると、スナップショットのペアは、スナップショットの合計数が
NUMBER_LIMIT
/NUMBER_LIMIT_IMPORTANT
で指定された数を超え、「かつ」NUMBER_MIN_AGE
で指定された保存期間を超える場合に削除されます。有効な値:yes
(はい) (有効)、no
(いいえ) (無効)。デフォルトの設定は
"yes"
です。変更または設定を行うコマンドの例:
>
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"
です。クリーニングアルゴリズムにより、スナップショットとファイルシステムの容量を考慮せずに、指定された最大値を超えるスナップショットは削除されます。また、このアルゴリズムにより、スナップショットとファイルシステムの制限に達するまで、最小値を超えるスナップショットも削除されます。変更または設定を行うコマンドの例:
>
sudo
snapper -c CONFIG set-config "NUMBER_LIMIT=10"重要: 範囲値と定数値の比較クォータサポートが有効な場合は(10.7.5項 「ディスククォータサポートの追加」を参照)、制限を「最小値-最大値」の範囲として指定する必要があります。たとえば、
2-10
のように指定します。クォータサポートが無効な場合は、定数値(たとえば10
)を指定する必要があります。そうしないと、エラーが発生してクリーンアップに失敗します。NUMBER_MIN_AGE
スナップショットが自動削除の対象となるまでの最短期間を秒単位で定義します。ここで指定した期間に達していなければ、スナップショットはいくつ存在していても削除されません。
デフォルトの設定は
"1800"
です。変更または設定を行うコマンドの例:
>
sudo
snapper -c CONFIG set-config "NUMBER_MIN_AGE=864000"
NUMBER_LIMIT
、NUMBER_LIMIT_IMPORTANT
、およびNUMBER_MIN_AGE
は常に評価されます。スナップショットが削除されるのは、「すべての」条件を満たしている場合のみです。
保存期間に関係なく、NUMBER_LIMIT*
で定義された数のスナップショットを常に保持する場合は、NUMBER_MIN_AGE
を0
に設定します。
次の例は、保存期間に関係なく最新の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
10.7.2 タイムラインスナップショットのクリーンアップ #
タイムラインスナップショットのクリーンアップは、Snapper設定の次のパラメータで制御します。
TIMELINE_CLEANUP
タイムラインスナップショットのクリーンアップを有効または無効にします。有効にすると、スナップショットは、スナップショットの合計数が
TIMELINE_LIMIT_*
で指定された数を超え、「かつ」TIMELINE_MIN_AGE
で指定された保存期間を超える場合に削除されます。有効値:yes
,no
。デフォルトの設定は
"yes"
です。変更または設定を行うコマンドの例:
>
sudo
snapper -c CONFIG set-config "TIMELINE_CLEANUP=yes"TIMELINE_LIMIT_DAILY
,TIMELINE_LIMIT_HOURLY
,TIMELINE_LIMIT_MONTHLY
,TIMELINE_LIMIT_WEEKLY
,TIMELINE_LIMIT_YEARLY
1時間、1日、1週間、1カ月間、および1年間に保持するスナップショット数です。
各エントリのデフォルト値は「
"10"
」です。ただし、TIMELINE_LIMIT_WEEKLY
は例外であり、デフォルトで「"0"
」に設定されています。TIMELINE_MIN_AGE
スナップショットが自動削除の対象となるまでの最短期間を秒単位で定義します。
デフォルトの設定は
"1800"
です。
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_AGE
とTIMELINE_LIMIT_*
は、常に両方、評価されます。この例では、スナップショットが削除対象となるまでの最短保存期間が30分(1800秒)に設定されています。毎時のスナップショットを作成するので、最新のスナップショットだけが保持されることになります。TIMELINE_LIMIT_DAILY
をゼロ以外に設定すると、1日の最初のスナップショットが保持されることになります。
1時間ごと: 最新の24個のスナップショットが保持されます。
1日ごと: 各日の最初に作成されたスナップショットが、直近の7日分保持されます。
1カ月ごと: 各月の最後の日に作成された最初のスナップショットが、直近の12カ月分保持されます。
1週ごと: 各週の最後の日に作成された最初のスナップショットが、直近の4週分保持されます。
1年ごと: 各年の最後の日に作成された最初のスナップショットが、直近の2年分保持されます。
10.7.3 違いがないスナップショットのペアのクリーンアップ #
10.1.2項 「スナップショットのタイプ」で説明したように、YaSTモジュールまたはZypperを実行すると、起動時に事前スナップショットが作成され、終了時に事後スナップショットが作成されます。変更を何も加えていない場合、事前スナップショットと事後スナップショットには違いがありません。Snapper設定で次のパラメータを設定することで、そのような「空の」スナップショットのペアを自動的に削除できます。
EMPTY_PRE_POST_CLEANUP
yes
に設定した場合、違いがない事前および事後スナップショットのペアは削除されます。デフォルトの設定は
"yes"
です。EMPTY_PRE_POST_MIN_AGE
違いがない事前および事後スナップショットのペアが自動削除の対象となるまでの最短期間を秒単位で定義します。
デフォルトの設定は
"1800"
です。
10.7.4 手動で作成されたスナップショットのクリーンアップ #
Snapperは、手動で作成されたスナップショットに対するカスタムクリーンアップアルゴリズムを備えていません。ただし、手動で作成されたスナップショットに、numberクリーンアップアルゴリズムまたはtimelineクリーンアップアルゴリズムを割り当てることができます。その場合、スナップショットは、指定されたアルゴリズムの「クリーンアップキュー」に入ります。クリーンアップアルゴリズムは、スナップショットの作成時に指定することも、既存のスナップショットを変更して指定することもできます。
snapper create --description "Test" --cleanup-algorithm number
デフォルト(ルート)設定のスタンドアロンスナップショット(singleタイプ)を作成して、
number
クリーンアップアルゴリズムを割り当てます。snapper modify --cleanup-algorithm "timeline" 25
番号が25のスナップショットを変更して、クリーンアップアルゴリズム
timeline
を割り当てます。
10.7.5 ディスククォータサポートの追加 #
上で説明したnumberクリーンアップアルゴリズムまたはtimelineクリーンアップアルゴリズム、あるいはその両方のほかに、Snapperはクォータもサポートします。スナップショットが占有できる使用可能な容量の割合を定義できます。この割合の値は常に、各Snapper設定で定義されたBtrfsサブボリュームに適用されます。
Btrfsクォータはユーザにではなく、サブボリュームに適用されます。Btrfsクォータを使用するだけでなく、ディスクスペースクォータをユーザやグループに適用することもできます(たとえば、quota
コマンドを使用)。
インストール時にSnapperを有効にした場合、クォータサポートは自動的に有効になっています。後から手動でSnapperを有効にする場合は、snapper
setup-quota
を実行することでクォータサポートを有効にできます。そのためには有効な設定が必要です(詳細については、10.5項 「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つのスナップショットは常に保持されます。
10.8 スナップショットが使用する排他的なディスク容量の表示 #
スナップショットはデータを共有してストレージ容量を効率的に使用できるため、du
やdf
などの通常のコマンドを使用しても、使用済みディスク容量は正確に測定されません。クォータを有効にしてBtrfsのディスク容量を解放する場合は、共有領域ではなく、各スナップショットで使用されている排他的なディスク容量を把握する必要があります。Snapper 0.6以降では、各スナップショットの使用済みディスク容量がUsed Space
列に報告されます。
#
snapper --iso list
# | Type | Pre # | Date | User | Used Space | Cleanup | Description | Userdata
----+--------+-------+---------------------+------+------------+---------+-----------------------+--------------
0 | single | | | root | | | current |
1* | single | | 2019-07-22 13:08:38 | root | 16.00 KiB | | first root filesystem |
2 | single | | 2019-07-22 14:21:05 | root | 14.23 MiB | number | after installation | important=yes
3 | pre | | 2019-07-22 14:26:03 | root | 144.00 KiB | number | zypp(zypper) | important=no
4 | post | 3 | 2019-07-22 14:26:04 | root | 112.00 KiB | number | | important=no
5 | pre | | 2019-07-23 08:19:36 | root | 128.00 KiB | number | zypp(zypper) | important=no
6 | post | 5 | 2019-07-23 08:19:43 | root | 80.00 KiB | number | | important=no
7 | pre | | 2019-07-23 08:20:50 | root | 256.00 KiB | number | yast sw_single |
8 | pre | | 2019-07-23 08:23:22 | root | 112.00 KiB | number | zypp(ruby.ruby2.5) | important=no
9 | post | 8 | 2019-07-23 08:23:35 | root | 64.00 KiB | number | | important=no
10 | post | 7 | 2019-07-23 08:24:05 | root | 16.00 KiB | number | |
btrfs
コマンドは、スナップショットが使用するスペースの別のビューを提供します。
#
btrfs qgroup show -p /
qgroupid rfer excl parent
-------- ---- ---- ------
0/5 16.00KiB 16.00KiB ---
[...]
0/272 3.09GiB 14.23MiB 1/0
0/273 3.11GiB 144.00KiB 1/0
0/274 3.11GiB 112.00KiB 1/0
0/275 3.11GiB 128.00KiB 1/0
0/276 3.11GiB 80.00KiB 1/0
0/277 3.11GiB 256.00KiB 1/0
0/278 3.11GiB 112.00KiB 1/0
0/279 3.12GiB 64.00KiB 1/0
0/280 3.12GiB 16.00KiB 1/0
1/0 3.33GiB 222.95MiB ---
qgroupid
列には、各サブボリュームの識別番号が表示され、qgroupレベルとIDの組み合わせが割り当てられます。
rfer
列には、サブボリュームに参照されるデータ合計数が表示されます。
excl
列には、各サブボリュームの排他的なデータが表示されます。
parent
列には、サブボリュームの親qgroupが表示されます。
最後の項目、1/0
、は親qgroupの合計が表示されます。上記の例では、サブボリュームのすべてが削除される場合、222.95MiBが解放されます。次のコマンドを実行して、各サブボリュームに関連するスナップショットが確認されます。
#
btrfs subvolume list -st /
ID gen top level path
-- --- --------- ----
267 298 266 @/.snapshots/1/snapshot
272 159 266 @/.snapshots/2/snapshot
273 170 266 @/.snapshots/3/snapshot
274 171 266 @/.snapshots/4/snapshot
275 287 266 @/.snapshots/5/snapshot
276 288 266 @/.snapshots/6/snapshot
277 292 266 @/.snapshots/7/snapshot
278 296 266 @/.snapshots/8/snapshot
279 297 266 @/.snapshots/9/snapshot
280 298 266 @/.snapshots/10/snapshot
あるサービスパックから別のサービスパックにアップグレードすると、スナップショットがシステムサブボリュームの多くのディスク領域を占有することになります。これらのスナップショットが不要になった場合は、手動で削除することをお勧めします。詳細については10.6.4項 「スナップショットの削除」を参照してください。
10.9 ホットスポットに関する一般的な質問とその回答 (FAQ) #
- 問:
Snapperが
/var/log
、/tmp
などのディレクトリの変更を表示しないのはなぜですか? 特定のディレクトリについては、スナップショットから除外することに決定しました。リストと理由については、10.1.3項 「スナップショットから除外されるディレクトリ」を参照してください。スナップショットからパスを除外するため、これらのパス用にサブボリュームを作成しています。
- 問: ブートローダからスナップショットをブートできますか?
はい。詳細については、10.3項 「スナップショットからのブートによるシステムロールバック」を参照してください。
- 問: スナップショットを削除から保護することができますか?
現在のところ、Snapperでは、スナップショットが手動で削除されるのを防ぐ方法はありません。ただし、スナップショットがクリーンアップアルゴリズムによって自動的に削除されるのを防ぐことはできます。手動で作成されたスナップショット(10.6.2項 「スナップショットの作成」を参照)には、
--cleanup-algorithm
でクリーンアップアルゴリズムを指定しない限り、クリーンアップアルゴリズムは割り当てられていません。自動的に作成されたスナップショットには、常にnumber
アルゴリズムまたはtimeline
アルゴリズムが割り当てられています。1つ以上のスナップショットからそのような割り当てを削除するには、次の手順に従います。使用可能なすべてのスナップショットの一覧を表示します。
>
sudo
snapper list -a削除されないようにするスナップショットの数を記憶します。
次のコマンドを実行します。数字のプレースホルダを、記憶した数に置き換えます。
>
sudo
snapper modify --cleanup-algorithm "" #1 #2 #nもう一度
snapper list -a
を実行して、結果を確認します。変更したスナップショットの列Cleanup
のエントリが空になります。
- 問: Snapperに関する詳細情報はどこで入手できますか?
Snapperのホームページ(http://snapper.io/)を参照してください。
11 KLPによるライブカーネルパッチ #
このドキュメントでは、KLP (カーネルライブパッチ)適用テクノロジーの基本原理について説明するとともに、SLE Live Patchingサービスの使用ガイドラインを提供します。
KLPでは、再起動せずにLinuxカーネルに最新のセキュリティアップデートを適用できます。これにより、ミッションクリティカルなシステムにとって特に重要なシステムのアップタイムと可用性が最大化されます。
このドキュメントで提供される情報は、AMD64/Intel 64、POWER、およびIBM Zアーキテクチャに関連しています。
11.1 カーネルライブパッチの利点 #
KLPにはいくつかの利点があります。
多数のサーバを自動的に最新状態に保つことは、組織が特定のコンプライアンス認定を取得または維持するために不可欠です。KLPは、コストのかかる保守ウィンドウの必要性を削減しながら、コンプライアンスの達成に役立ちます。
サービスレベル契約を締結している企業は、特定のレベルのシステムアクセシビリティとアップタイムを保証する必要があります。ライブパッチにより、ダウンタイムを発生させることなくシステムにパッチを適用できます。
KLPは標準のシステムアップデートメカニズムの一部であるため、専門的なトレーニングや複雑な保守ルーチンの導入の必要はありません。
11.2 カーネルライブパッチの概要 #
カーネルライブパッチは、メインのカーネルパッケージとは別のコードが変更されたパッケージとして提供されます。ライブパッチは累積的であるため、最新のパッチには、カーネルパッケージの以前のものからのすべての修正が含まれています。各カーネルライブパッケージは発行された正確なカーネルリビジョンに関連付けられています。ライブパッチパッケージバージョン番号は修正が追加されるたびに増加します。
カーネルパッチ適用ステータスを確認するには、klp -v
patches
コマンドを使用します。uname
コマンドの出力は、パッチ適用済みカーネルでは変化しません。
ライブパッチには重要な修正のみが含まれ、再起動が必要な通常のカーネルアップデートに置き換わるものではありません。ライブパッチは、適切なカーネルアップデートおよび再起動が実行されるまでカーネルを保護する一時的な手段と考えてください。
次の図は、ライブパッチとカーネルアップデートの全体的な関係を示しています。現在アクティブなライブパッチによって対処されるCVEと不具合レポートのリストは、klp -v
patches
コマンドを使用して表示できます。
ライブパッチとともに複数のバージョンのカーネルパッケージをインストールすることができます。これらのパッケージは競合しません。実行中のカーネル用にライブパッチとともにアップデートされたカーネルパッケージをインストールできます。この場合、システムを再起動するように求められる場合があります。SLE Live Patchingサブスクリプションを持つユーザは、実行中のカーネルのライブパッチアップデートがある限り、テクニカルサポートを受ける資格があります(11.5.1項 「ライブパッチの有効期限を確認する」を参照)。
KLPを有効にすると、すべてのカーネルアップデートにライブパッチパッケージが付属します。このライブパッチには修正は含まれておらず、対応するカーネルの将来のライブパッチのシードとなります。これらの空のシードパッチはinitial patches
と呼ばれます。
11.2.1 カーネルライブパッチのスコープ #
SLE Live Patchingのスコープには、SUSE Common Vulnerability Scoring System (CVSS、SUSE CVSSはCVSS v3.0システムに基づいています)レベル7以上の脆弱性の修正と、システムの安定性やデータ破損に関するバグ修正が含まれます。ただし、指定されたカテゴリに該当するすべての修正のライブパッチを作成することは技術的に不可能な場合があります。したがって、SUSEではカーネルライブパッチの作成が技術的な理由で不可能な状況で修正をスキップする権利を留保します。現在、対象となる修正の95%以上がライブパッチとしてリリースされています。CVSS (SUSE CVSSレーティングのベース)の詳細については、「Common Vulnerability Scoring System SIG」を参照してください。
11.2.2 カーネルライブパッチの制限 #
KLPには、関数の置き換えと、相互に依存する関数セットの置き換えの適切な処理が含まれます。これは、古いコードへの呼び出しを別のメモリ位置にある更新されたコードにリダイレクトすることによって行われます。データ構造の変更は、データがそのまま残り、拡張したり再解釈できないため、状況をより複雑にします。データ構造の間接的な変更を許可する技術はありますが、特定の修正はライブパッチに変換できません。この状況では、システムの再起動が、修正を適用する唯一の方法です。
11.3 YaSTを使用したカーネルライブパッチの有効化 #
KLPをシステムで有効にするには、アクティブなSLESおよびSLE Live Patchingサブスクリプションが必要です。SUSE Customer Centerにアクセスし、サブスクリプションのステータスを確認し、SLE Live Patchingサブスクリプションの登録コードを取得してください。
カーネルライブパッチをシステムで有効にするには、次の手順に従います。
yast2 registration
コマンドを実行して、 をクリックします。入手可能な拡張機能のリストで
を選択し、 をクリックします。ライセンス条項を確認し、
をクリックします。SLE Live Patchingの登録コードを入力し、
をクリックします。Live Patching
とSLE Live Patching Lifecycle Data
パターンが、依存関係を満たすための追加のパッケージとともにインストール用に自動的に選択されるはずです。
11.4 コマンドラインからのカーネルライブパッチの有効化 #
カーネルライブパッチを有効にするには、アクティブなSLESおよびSLES Live Patchingサブスクリプションが必要です。SUSE Customer Centerにアクセスし、サブスクリプションのステータスを確認し、SLES Live Patchingサブスクリプションの登録コードを取得してください。
sudo SUSEConnect --list-extensions
を実行します。SLES Live Patchingの正確なアクティベーションコマンドに注意します。コマンド出力の例(省略形):$ SUSEConnect --list-extensions ... SUSE Linux Enterprise Live Patching 15 SP6 x86_64 Activate with: SUSEConnect -p sle-module-live-patching/15.6/x86_64 \ -r ADDITIONAL REGCODE
取得したコマンドに続いて
-r LIVE_PATCHING_REGISTRATION_CODE
を使用してSLES Live Patchingを有効にします。例:SUSEConnect -p sle-module-live-patching/15.6/x86_64 \ -r LIVE_PATCHING_REGISTRATION_CODE
zypper install -t pattern lp_sles
コマンドを使用して必要なパッケージと依存関係をインストールします。
この時点で、システムはすでにライブパッチが適用されています。
プロセスがバックグラウンドでどのように機能するかを次に示します: ライブパッチを適用できるカーネルがインストールされていること、およびソフトウェアチャネルにそのカーネルのライブパッチがあることをパッケージインストールシステムが検出すると、システムはインストール用のライブパッチを選択します。カーネルはパッケージインストールの一部としてライブパッチ修復を受信します。製品インストールが完了する前でも、カーネルにライブパッチが適用されます。
11.5 カーネルライブパッチの適用 #
カーネルライブパッチは、定期的なシステムアップデートの一部としてインストールされます。ただし、認識すべきいくつかのことがあります。
kernel-livepatch-*パッケージが実行中のカーネル用にインストールされている場合、カーネルにライブパッチが適用されます。コマンド
zypper se --details kernel-livepatch-*
を使用して、システムにインストールされているカーネルライブパッチパッケージを確認できます。kernel-defaultパッケージがインストールされる場合、アップデートマネージャはシステムを再起動するように求めます。このメッセージが表示されないようにするには、パッチ適用操作からカーネルアップデートを除外できます。これは、Zypperを使用してパッケージロックを追加することで実行できます。SUSE Managerはチャネルコンテンツをフィルタすることもできます(Live Patching with SUSE Manager (SUSE Managerによるライブパッチ適用)を参照)。
klp status
コマンドを使用してパッチ適用ステータスを確認できます。インストール済みのパッチを調べるには、klp -v patches
コマンドを実行します。システムに複数のカーネルパッケージがインストールされている可能性がありますが、任意の時点で実行されるのはそれらの1つのみであることに注意してください。同様に、複数のライブパッチパッケージがインストールされる場合がありますが、カーネルにロードされるライブパッチは1つのみです。
アクティブなライブパッチは、
initrd
に含まれています。これは、予期しない再起動が発生した場合に、ライブパッチ修正が適用された状態でシステムが起動するため、再びパッチを適用する必要がないことを意味します。
11.5.1 ライブパッチの有効期限を確認する #
lifecycle-data-sle-module-live-patchingがインストールされていることを確認し、zypper lifecycle
コマンドを実行します。出力のPackage end of support if
different from product
セクションにライブパッチの有効期限が表示されるはずです。
すべてのライブパッチは基盤となるカーネルパッケージのリリースから1年間、アップデートを受け取ります。「Maintained kernels, patch updates and lifecycle」ページでは、製品の拡張機能をインストールすることなく、実行中のカーネルバージョンに基づいて有効期限を確認できます。
11.6 カーネルライブパッチの問題のトラブルシューティング #
11.6.1 手動によるパッチのダウングレード #
最新のライブパッチに問題がある場合は、現在インストールされているライブパッチを以前のバージョンにダウングレードできます。システムで問題が発生する前に、パッチのダウングレードを実行することをお勧めします。システムログにカーネル警告またはカーネルエラートレースが含まれているシステムは、パッチのダウングレード手順に適していない場合があることに注意してください。システムがパッチダウングレードの要件を満たしているかどうか不明な場合は、SUSEテクニカルサポートに連絡してください。
klp -v patches
コマンドを使用して実行中のライブパッチを特定します。RPM:
で開始される行に現在実行中のパッチが表示されます。例:RPM: kernel-livepatch-6_4_0-150600_9-default-1-150600.2.36.x86_64
前の例の
6_4_0-150600_9-default
は、実行中のカーネルの正確なバージョンを示しています。コマンド
zypper search -s kernel-livepatch-RUNNING_KERNEL_VERSION-default
を使用して、以前のバージョンのパッチを検索します。このコマンドは、使用可能なパッケージバージョンのリストを返します。新しいライブパッチパッケージがリリースされるたびに、バージョン番号が1つずつ増加することに注意してください。現在のリリースより1つ前のバージョン番号を選択してください。zypper in --oldpackage kernel-livepatch-RUNNING_KERNEL_VERSION-default=DESIRED_VERSION
コマンドを使用して、目的のバージョンをインストールします。
12 ユーザ空間ライブパッチ #
この章では、ユーザスペースのライブパッチの基本原理と使用方法について説明します。
12.1 ユーザ空間ライブパッチについて #
ユーザ空間ライブパッチ(ULP)とは、実行中のプロセスで使用されるライブラリに、中断することなくパッチを適用するプロセスのことです。ライブパッチとしてセキュリティ修正が利用できるようになるたびに、ライブパッチを適用した後にプロセスを再起動することなくカスタマサービスが保護されます。
ライブパッチ操作は、libpulp
の一部であるulp
ツールを使用して実行されます。libpulp
は、libpulp.so
ライブラリと、ulp
バイナリで構成されるフレームワークで、ライブラリをライブパッチ可能にし、ライブパッチを適用します。
標準ユーザまたは特権を持つユーザのいずれかとしてsudo
メカニズムを使用してulp
コマンドを実行できます。両者の違いは、sudo
を使用してulp
を実行すると、root
によって実行されているプロセスまたはパッチプロセスの情報を表示できることです。
12.1.1 前提条件 #
ULPを機能させるには、2つの要件を満たす必要があります。
次を実行してシステムにULPをインストールしている。
>
sudo
zypper in libpulp0 libpulp-tools目的のライブパッチサポートを含むアプリケーションを
libpulp.so.0
ライブラリをプリロードすることによって起動する必要がある。詳しくは12.1.3項 「libpulp
の使用」を参照してください。
12.1.2 サポートされているライブラリ #
現在は、glibc
およびopenssl
(openssl1_1
)のみがサポートされています。追加のパッケージは、ライブパッチ用に準備できてから使用できるようになります。glibc
およびopenssl
のライブパッチを受け取るには、glibc-livepatchesとopenssl-livepatchesパッケージの両方をインストールしてください。
>
zypper install glibc-livepatches openssl-livepatches
12.1.3 libpulp
の使用 #
アプリケーションでライブパッチを有効にするには、アプリケーション起動時にlibpulp.so.0
ライブラリをプリロードする必要があります。
>
LD_PRELOAD=/usr/lib64/libpulp.so.0 APPLICATION_CMD
12.1.3.1 ライブラリがライブパッチ可能かどうかの確認 #
ライブラリがライブパッチ可能かどうかを確認するには、次のコマンドを使用します。
>
ulp livepatchable PATH_TO_LIBRARY
12.1.3.2 .so
ファイルがライブパッチコンテナかどうかの確認 #
共有オブジェクト(.so
)は、ULPパッチ記述が埋め込まれている場合にはライブパッチコンテナです。次のコマンドを使用して確認できます。
>
readelf -S SHARED_OBJECT | grep .ulp
共有オブジェクトに.ulp
セクションと.ulp.rev
セクションの両方があることを出力が示している場合、ライブパッチコンテナです。
12.1.3.3 ライブパッチの適用 #
ライブパッチは、次のような、ulp trigger
コマンドを使用して適用されます。
>
ulp trigger -p PID LIVEPATCH.so
PID
を、パッチを適用するライブラリを使用する実行中のプロセスのプロセスIDで置き換え、LIVEPATCH.so
を実際のライブパッチファイルで置き換えます。このコマンドは、次のステータスメッセージのいずれかを返します。
- SUCCESS
ライブパッチ操作は成功しました。
- SKIPPED
パッチは、プロセスでロードされたどのライブラリ用にも設計されていなかったためスキップされました。
- ERROR
エラーが発生しました。
libpulp
内部メッセージバッファを調べることにより、より多くの情報を取得できます。詳細については、12.1.3.6項 「内部メッセージキューの表示」を参照してください。
ワイルドカードを使用して複数のライブパッチを適用することもできます。次に例を示します。
>
ulp trigger '*.so'
このコマンドは、現在のフォルダ内のすべてのパッチをlibpulp
ライブラリがロードされているすべてのプロセスに適用しようとします。パッチは、プロセスに不適である場合、自動的にスキップされます。最後に、適用に成功したパッチ数および適用されたプロセス数がツールに表示されます。
12.1.3.4 ライブパッチを元に戻す #
ulp trigger
コマンドを使用してライブパッチを元に戻します。ライブパッチを元に戻すには、2つの方法があります。--revert
スイッチを使用し、ライブパッチコンテナを渡すことで、ライブパッチを元に戻すことができます。
>
ulp trigger -p PID --revert LIVEPATCH.so
または、特定のライブラリに関連付けられているすべてのパッチを削除することもできます。次に例を示します。
>
ulp trigger -p PID --revert-all=LIBRARY
この例では、LIBRARYは、libcrypto.so.1.1
などの実際のライブラリを表します。
後者の方法は、元のライブパッチのソースコードを利用できない場合に便利です。または、特定の古いパッチを削除し、新しいパッチを適用するが、同時にターゲットアプリケーションがセキュアコードの実行を継続する場合です。次に例を示します。
>
ulp trigger -p PID --revert-all=libcrypto.so.1.1 new_livepatch2.so
12.1.3.5 適用パッチの表示 #
次を実行することによって、ライブパッチが適用されているアプリケーションを確認できます。
>
ulp patches
ライブパッチ可能なライブラリ、プログラムにロードされているパッチ、およびパッチが対処しているバグが出力に示されます。
PID: 10636, name: test Livepatchable libraries: in /lib64/libc.so.6: livepatch: libc_livepatch1.so bug labels: jsc#SLE-0000 in /usr/lib64/libpulp.so.0:
ライブパッチによってパッチされている機能を確認することも可能です。
>
ulp dump LIVEPATCH.so
12.1.3.6 内部メッセージキューの表示 #
libpulp.so
からのログメッセージは、ライブラリ内のバッファに格納され、ユーザが要求しない限り表示されません。これらのメッセージを表示するには、次を実行します。
>
ulp messages -p PID
12.2 詳細情報 #
libpulp
に関する詳細については、プロジェクトのGit
repositoryを参照してください。
13 トランザクション更新 #
トランザクション更新は、ルートファイルシステムが読み込み専用のときにSLESを更新するためにSUSE Linux Enterprise Serverで利用できます。トランザクション更新はアトミックであり(すべての更新が成功した場合にのみすべての更新が適用されます)、ロールバックをサポートします。システムが再起動されるまで変更は有効にならないため、実行中のシステムには影響しません。再起動は中断を伴うので、管理者は、再起動の方が実行中のサービスを妨害するよりもコストがかかるかどうかを判断する必要があります。再起動でコストがかかりすぎる場合は、トランザクション更新を使用しないでください。
トランザクションの更新は、transactional-update
スクリプトによって、毎日実行されます。スクリプトは使用可能な更新をチェックします。更新がある場合は、ルートファイルシステムの新しいスナップショットをバックグラウンドで作成し、リリースチャネルから更新をフェッチします。新しいスナップショットが更新された後で、アクティブとマークされ、システムの次の再起動後に新しいデフォルトのルートファイルシステムになります。transactional-update
が自動的に実行するように設定されている場合(これはデフォルトの動作です)、システムも再起動します。更新を実行する時刻と再起動の保守時間枠の両方が設定可能です。
ルートファイルシステムのスナップショットの一部であるパッケージのみを更新できます。パッケージにスナップショットの一部ではないファイルが含まれている場合、更新は失敗するか、システムが破損する可能性があります。
ライセンスを受諾する必要があるRPMは更新できません。
13.1 制限 #
現在、トランザクション更新の機能には一定の制限があります。次のパッケージはtransactional-update
コマンドでは動作しません。
nginxのデフォルトの
index.html
ページは使用できない場合がありますtomcat-webapps および tomcat-admin-webapps
phpMyAdmin
sca-appliance-*
mpi-selector
emacsはEmacsゲームを除いて機能します
bind および bind-chrootenv
docbook*
sblim-sfcb*
texlive*
iso_ent
openjade
opensp
pcp
plymouth
postgresql-server-10
pulseaudio-gdm-hooks
smartmontools
システムインストーラのアップデータコンポーネントは、トランザクションの更新をサポートしていないため、読み込み専用ファイルシステムでは動作しません。
その他の考慮事項:
システムを更新してから、マシンを再起動するまでの時間を最小限に抑えることをお勧めします。
1つの更新のみを一度に適用できます。更新後、および次の更新が適用される前に必ず再起動してください。
update-alternatives
は、トランザクション更新後、マシンが再起動されるまで、実行しないでください。トランザクション更新後、再起動後まで新しいシステムユーザまたはシステムグループを作成しないでください。通常のユーザおよびグループを作成することは許容されます (UID > 1000、GID > 1000)。
YaSTはまだトランザクション更新を認識していません。YaSTモジュールで追加のパッケージをインストールする必要がある場合、これは機能しません。
/etc
の設定ファイルを変更する通常のシステム動作は機能します。php7-fastcgiの場合、
/srv/www/cgi-bin/php
を示すシンボリックリンク/usr/bin/php-cgi
を手動で作成する必要があります。ntpは、古いSLESバージョンのレガシモジュールの一部です。ntpは新しいSUSE Linux Enterprise Serverインストールでサポートされておらず、chronyに置き換えられました。ntpを引き続き使用する場合は、トランザクション更新で正しく機能させるために、新規インストールが必要です。
sblim-sfcb: エコシステム全体がトランザクション更新と互換性がありません。
btrfsmaintenanceパッケージの
btrfs-defrag
は、読み込み専用ルートファイルシステムでは機能しません。btrfs-balance
の場合、/etc/sysconfig/btrfsmaintenance
の変数BTRFS_BALANCE_MOUNTPOINTS
を/
から/.snapshots
に変更する必要があります。btrfs-scrub
の場合、/etc/sysconfig/btrfsmaintenance
の変数BTRFS_SCRUB_MOUNTPOINTS
を/
から/.snapshots
に変更する必要があります。
13.2 transactional-update有効化 #
システムのインストール時にトランザクショナルサーバモジュールを有効にし、トランザクショナルサーバシステム役割を選択する必要があります。実行しているシステムで後でトランザクショナルサーバモジュールからパッケージをインストールすることはサポートされておらず、システムが破損する可能性があります。
ルートパーティションのサブボリュームレイアウトを変更すること、またはルートパーティションのサブディレクトリまたはサブボリュームをそれぞれのパーティション(/home
、/var
、/srv
、および/opt
を除く)に配置することはサポートされておらず、システムが破損する可能性があります。
13.3 自動更新の管理 #
自動更新は、1日1回実行するsystemd.timer
によって制御されます。これは、すべての更新に適用され、マシンが再起動する必要があることをrebootmgrd
に知らせます。更新が実行される時刻を調整できます。systemd.timer(5)を参照してください。rebootmgrd
がシステムを再起動するときのメンテナンス期間を調整するには、rebootmgrd(8)を参照してください。
次のコマンドで自動トランザクション更新を無効にできます。
#
systemctl --now disable transactional-update.timer
13.4 transactional-update
コマンド #
transactional-update
コマンドでは、更新のアトミックなインストールまたは削除が可能です。すべてが正常にインストールされている場合にのみ更新が適用されます。transactional-update
は、更新が適用される前にシステムのスナップショットを作成し、このスナップショットを復元できます。再起動後にのみ、すべての変更がアクティブになります。
--continue
--continue
オプションは、再起動せずに既存のスナップショットに複数の変更を行うためのものです。デフォルトの
transactional-update
動作は、現在のルートファイルシステムから新しいスナップショット作成することです。新しいパッケージのインストールなど、何かを忘れた場合は、再起動して以前の変更を適用し、transactional-update
を再度実行して忘れたパッケージをインストールしてから再起動する必要があります。再起動せずに、スナップショットにさらに変更を追加するためにtransactional-update
コマンドを複数回実行できません。これは、以前のスナップショットからの変更を含まない独立したスナップショットが作成されるためです。--continue
オプションを使用して、再起動せずに必要なだけ変更を行います。別個のスナップショットが毎回作成され、各スナップショットには、以前のスナップショットで作成されたすべての変更、および新しい変更が含まれます。このプロセスを必要な回数だけ繰り返します。最終スナップショットに必要なものがすべて含まれている場合は、システムを再起動すると、最終スナップショットが新しいルートファイルシステムになります。--continue
オプションのもう1つの便利な機能は、既存のスナップショットを新しいスナップショットのベースとして選択できることです。次の例では、transactional-update
を実行して、スナップショット13に基づいてスナップショットに新しいパッケージをインストールしてから、もう一度実行して別のパッケージをインストールする方法を示しています。#
transactional-update pkg install package_1
#
transactional-update --continue 13 pkg install package_2
--continue [num]
オプションはsnapper create --from
を呼び出します。10.6.2項 「スナップショットの作成」を参照してください。cleanup
現在のルートファイルシステムがアクティブなルートファイルシステムと同一である場合(再起動後、
transactional-update
が更新を含む新しいスナップショットを作成する前)、クリーンアップアルゴリズムのないすべての古いスナップショットはクリーンアップアルゴリズムセットを取得します。これにより、古いスナップショットがSnapperによって確実に削除されます。(snapper(8)のクリーンアップアルゴリズムに関するセクションを参照してください。)これにより、/var/lib/overlay
内の参照されていない(つまり未使用の)/etc
オーバーレイディレクトリもすべて削除されます。#
transactional-update cleanup
pkg in/install
zypper install
コマンドを使用して、使用可能なチャネルから個々のパッケージをインストールします。このコマンドは、Program Temporary Fix (PTF) RPMファイルをインストールするために使用することもできます。#
transactional-update pkg install package_name
あるいは、
#
transactional-update pkg install rpm1 rpm2
pkg rm/remove
zypper remove
コマンドを使用してアクティブなスナップショットから個々のパッケージを削除します。このコマンドは、PTF RPMファイルを削除するために使用することもできます。#
transactional-update pkg remove package_name
pkg up/update
zypper update
コマンドを使用してアクティブなスナップショットから個々のパッケージを更新します。ベースファイルシステムのスナップショットの一部であるパッケージのみを更新できます。#
transactional-update pkg update package_name
up/update
使用可能な新しい更新がある場合、新しいスナップショットが作成され、
zypper up/update
がスナップショットを更新します。#
transactional-update up
dup
使用可能な新しい更新がある場合、新しいスナップショットが作成され、
zypper dup –no-allow-vendor-change
がスナップショットを更新します。スナップショットは後で有効にされ、再起動後に新しいルートファイルシステムになります。#
transactional-update dup
patch
使用可能な新しい更新がある場合、新しいスナップショットが作成され、
zypper patch
がスナップショットを更新します。#
transactional-update patch
rollback
これはデフォルトのサブボリュームを設定します。読み書き可能なファイルシステムを備えたシステムでは、
snapper rollback
が呼び出されます。読み込み専用ファイルシステムで引数を指定しない場合、現在のシステムは新しいデフォルトのルートファイルシステムに設定されます。数値を指定する場合、スナップショットがデフォルトのルートファイルシステムとして使用されます。読み込み専用ファイルシステムでは、追加のスナップショットは作成されません。#
transactional-update rollback snapshot_number
grub.cfg
これは、新しいGRUB2設定を作成します。カーネルパラメータの追加など、ブート設定の調整が必要になる場合があります。/etc/default/grubを編集し、
transactional-update grub.cfg
を実行してから再起動し、変更を有効にします。すぐに再起動する必要があります。そうしないと、新しいGRUB2設定が次のtransactional-update
の実行によってデフォルトで上書きされます。#
transactional-update grub.cfg
reboot
このパラメータは、アクションが完了した後に再起動をトリガします。
#
transactional-update dup reboot
--help
これにより、オプションとサブコマンドを含むヘルプ画面が印刷されます。
#
transactional-update --help
13.5 トラブルシューティング #
アップグレードが失敗する場合は、supportconfig
を実行して、ログデータを収集します。/var/log/transactional-update.log
を含む結果のファイルをSUSEサポートに提供します。
14 VNCによるリモートグラフィカルセッション #
仮想ネットワークコンピューティング (VNC)では、グラフィカルデスクトップを介してリモートコンピュータにアクセスしたり、リモートグラフィカルアプリケーションを実行したりできます。VNCはプラットフォームに依存しないので、VNCを使用すれば、任意のオペレーティングシステムからリモートマシンにアクセスできます。この章では、デスクトップクライアントvncviewerおよびRemminaを使用してVNCサーバに接続する方法、およびVNCサーバを操作する方法について説明します。
SUSE Linux Enterprise Serverでは、2種類のVNCセッションをサポートしています。1つはクライアントからのVNC接続が続く間「存続する」一時的セッションで、もう1つは明示的に終了されるまで「存続する」永続的セッションです。
VNCサーバでは両方のタイプのセッションを異なるポートで同時に提供できます。ただし、オープンセッションを1つのタイプからもう一方のタイプに変換することはできません。
14.1 vncviewer
クライアント #
サーバによって提供されるVNCサービスに接続するには、クライアントが必要です。SUSE Linux Enterprise Serverのデフォルトはvncviewer
で、これはtigervnc
パッケージで提供されます。
14.1.1 vncviewer CLIを使用した接続 #
VNCビューアを起動し、サーバとのセッションを開始するには、次のコマンドを使用します。
>
vncviewer jupiter.example.com:1
VNCディスプレイ番号の代わりに、2つのコロンを使用してポート番号を指定することもできます。
>
vncviewer jupiter.example.com::5901
VNCクライアントで実際に指定するディスプレイ番号またはポート番号は、ターゲットマシンでVNCサーバの設定時に選択するディスプレイ番号またはポート番号と同じである必要があります。詳細については、14.4項 「永続的VNCサーバセッションを設定する」を参照してください。
14.1.2 vncviewer GUIを使用した接続 #
--listen
または接続先ホストを指定せずにvncviewer
を実行すると、接続の詳細を入力するよう求めるウィンドウが表示されます。14.1.1項 「vncviewer CLIを使用した接続」のように フィールドにホストを入力し、 をクリックします。
14.1.3 暗号化されていない接続の通知 #
VNCプロトコルは、さまざまな種類の暗号化接続をサポートしています。これをパスワード認証と混同しないでください。接続がTLSを使用していない場合、「(Connection not encrypted!) (接続が暗号化されていません!)」というテキストがVNCビューアのウィンドウタイトルに表示されることがあります。
14.2 Remmina: リモートデスクトップクライアント #
Remminaは、最新の機能豊富なリモートデスクトップクライアントです。VNC、SSH、RDP、Spiceなど、複数のアクセス方法をサポートしています。
14.2.1 インストール #
Remminaを使用するには、システムにremminaパッケージがインストールされているかどうか確認し、インストールされていない場合はインストールします。Remmina用のVNCプラグインもインストールすることを忘れないでください。
#
zypper in remmina remmina-plugin-vnc
14.2.2 メインウィンドウ #
remmina
コマンドを入力してRemminaを実行します。
メインアプリケーションウィンドウには、保存されているリモートセッションのリストが表示されます。ここでは、新しいリモートセッションを追加および保存したり、保存せずに新しいセッションをクイックスタートしたり、以前に保存したセッションを開始したり、Remminaのグローバル設定を行うことができます。
14.2.3 リモートセッションの追加 #
新しいリモートセッションを追加して保存するには、メインウィンドウの左上にあるをクリックします。 ウィンドウが開きます。
新しく追加したリモートセッションプロファイルを指定するフィールドに入力します。最も重要な設定には次のものがあります。
- 名前
プロファイルの名前。この名前は、メインウィンドウにリストされます。
- プロトコル
リモートセッションに接続するときに使用するプロトコル(VNCなど)。
- または8単位
リモートサーバのIPアドレスまたはDNSアドレスとディスプレイ番号。
- ユーザ名、パスワード
リモート認証に使用する資格情報。認証しない場合は空のままにします。
- 色数、品質
接続速度と品質に応じて最適なオプションを選択します。
より詳細な設定を入力するには、
タブを選択します。クライアントとリモートサーバ間の通信が暗号化されていない場合は、
を有効にします。そうしないと接続が失敗します。高度なSSHトンネリングと認証オプションについては、
タブを選択してください。[保存]
新しいプロファイルがメインウィンドウに表示されます。14.2.4 リモートセッションの開始 #
以前に保存したセッションを開始するか、または接続の詳細を保存せずにリモートセッションをクイックスタートすることができます。
14.2.4.1 リモートセッションのクイックスタート #
接続の詳細を追加および保存することなく、リモートセッションをすばやく開始するには、メインウィンドウの上部にあるドロップダウンボックスとテキストボックスを使用します。
ドロップダウンリストから通信プロトコル(「VNC」など)を選択して、次にVNCサーバのDNSまたはIPアドレスを入力し、それに続けてコロンとディスプレイ番号を入力して、Enterで確定します。
14.2.4.2 保存されたリモートセッションを開く #
特定のリモートセッションを開くには、セッションのリストからダブルクリックします。
14.2.4.3 リモートセッションウィンドウ #
リモートセッションは別のウィンドウのタブで開きます。タブごとに1つのセッションをホストします。ウィンドウの左側にあるツールバーは、ウィンドウ/セッションの管理に役立ちます。たとえば、全画面モードの切り替え、セッションの表示サイズに合わせたウィンドウのサイズ変更、特定のキー入力のセッションへの送信、セッションのスクリーンショットの撮影、画質の設定などが可能です。
14.2.5 保存されたセッションの編集、コピー、および削除 #
保存されたリモートセッションを編集するには、Remminaのメインウィンドウでその名前を右クリックし、 を選択します。関連するフィールドの説明については、14.2.3項 「リモートセッションの追加」を参照してください。
保存されたリモートセッションをコピーするには、Remminaのメインウィンドウでその名前を右クリックし、 を選択します。 ウィンドウで、プロファイルの名前を変更し、関連するオプションを必要なら調整し、 をクリックして確定します。
保存されたリモートセッションを削除するには、Remminaのメインウィンドウでその名前を右クリックし、 を選択します。次のダイアログで をクリックして確定します。
14.2.6 コマンドラインからのリモートセッションの実行 #
最初にメインのアプリケーションウィンドウを開くことなく、コマンドラインまたはバッチファイルからリモートセッションを開く必要がある場合は、次の構文を使用します。
>
remmina -c profile_name.remmina
Remminaのプロファイルファイルは、ホームディレクトリの.local/share/remmina/
ディレクトリに保存されます。開きたいセッションに属しているプロファイルファイルを決定するには、Remminaを実行し、メインウィンドウでセッション名をクリックし、下部のウィンドウのステータス行でプロファイルファイルへのパスを読み込みます。
が実行されていないときに、プロファイルファイルの名前をsle15.remmina
.remminaなどのより合理的なファイル名に変更することができます。プロファイルファイルをカスタムディレクトリにコピーして、そこからremmina -c
コマンドを使用して実行することもできます。
14.3 VNCサーバでのワンタイムセッションの設定 #
一時的セッションは、リモートクライアントによって開始されます。これにより、サーバにグラフィカルなログイン画面が開きます。この画面でセッションを開始するユーザを選択できます。さらに、ログインマネージャでサポートされている場合はデスクトップ環境も選択できます。そのようなVNCセッションへのクライアント接続をキャンセルすると、そのセッション内で開始したアプリケーションもすべて終了します。一時的なVNCセッションは共用できませんが、1つのホストで同時に複数のセッションを実行することは可能です。
まず、
› › の順に選択します。WebブラウザウィンドウでVNCセッションにアクセスする場合は、
をアクティブにします。必要な場合は、
にもチェックマークを付けます (たとえば、ネットワークインタフェースを外部ゾーンに属するように設定する場合)。ネットワークインタフェースが複数ある場合は、 で、特定のインタフェースにだけファイアウォールポートを開くように制限します。必要なパッケージの一部をまだ入手できない場合は、足りないパッケージのインストールを承認する必要があります。
ヒント: ディスプレイマネージャの再起動YaSTはディスプレイマネージャの設定を変更します。現在のグラフィカルセッションからログアウトし、ディスプレイマネージャを再起動して変更を有効にする必要があります。
14.3.1 使用可能な設定 #
SUSE Linux Enterprise Serverのデフォルト設定では、1024x768ピクセルの解像度と16ビットの色数でセッションが提供されます。セッションで使用できるポートは、「正規の」VNCビューアの場合はポート5901
(VNCディスプレイ1
に相当)、Webブラウザの場合はポート5801
です。
その他の設定は、異なるポートで使用できます。14.3.3項 「一時的VNCセッションを設定する」を参照してください。
VNCディスプレイ番号とXディスプレイ番号は、一時的セッションでは互いに独立しています。VNCディスプレイ番号は、サーバがサポートするすべての設定に手動で割り当てられます(上記の例では1)。VNCセッションは、設定の1つを使用して開始されるたびに、自動的に未使用のXディスプレイ番号を取得します。
デフォルトでは、VNCクライアントとサーバの両方が、インストール後に生成される自己署名SSL証明書を使用してセキュアな通信を試みます。デフォルトの証明書を使用することも、独自の証明書に置き換えることもできます。自己署名証明書を使用する際、初回の接続前に、VNCビューアおよびWebブラウザの両方で署名を確認する必要があります。
特定のVNCクライアントは、デフォルトの自己署名証明書を使用した安全な接続の確立を拒否します。たとえば、VinagreクライアントはGnuTLSグローバル信頼ストアに対して証明書を検証し、証明書が自己署名されている場合は失敗します。このような場合は、x509
以外の暗号化方法を使用するか、VNCサーバ用に適切に署名された証明書を生成して、クライアントのシステム信頼ストアにインポートします。
14.3.2 一時的VNCセッションを開始する #
一時的VNCセッションに接続するには、VNCビューアをインストールする必要があります。14.1項 「vncviewer
クライアント」も参照してください。または、JavaScriptを有効にしたWebブラウザで、URLとして「http://jupiter.example.com:5801
」を入力することにより、VNCセッションを表示できます。
14.3.3 一時的VNCセッションを設定する #
デフォルト設定を変更する必要も意志もない場合は、このセクションをスキップできます。
一時的VNCセッションは、systemd
ソケットxvnc.socket
を介して開始されます。このファイルは、デフォルトで、6つの設定ブロックを提供します: VNCビューア用に3ブロック(vnc1
からvnc3
まで)、JavaScriptクライアント用に3ブロック(vnchttpd1
からvnchttpd3
まで)。デフォルトでは、vnc1
とvnchttpd1
のみがアクティブになっています。
ブート時にVNCサーバソケットをアクティブにするには、次のコマンドを実行します。
>
sudo
systemctl enable xvnc.socket
すぐにソケットを起動するには、次のコマンドを実行します。
>
sudo
systemctl start xvnc.socket
Xvnc
サーバは、server_args
オプションを介して設定できます。オプションのリストについては、Xvnc --help
を参照してください。
カスタム設定を追加する際には、それらの設定が、同じホスト上の他の設定、他のサービス、または既存の永続的VNCセッションですでに使用中のポートを使用しないことを確認してください。
設定の変更を有効にするには、次のコマンドを入力します:。
>
sudo
systemctl reload xvnc.socket
手順14.1「一時的VNCセッションの有効化」で説明されているように、リモート管理をアクティブにすると、ファイアウォール内でポート5801
および5901
が開きます。VNCセッションで使用されるネットワークインタフェースがファイアウォールで保護されている場合、VNCセッションの追加ポートをアクティブにする際には各ポートを手動で開く必要があります。手順については、Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”を参照してください。
14.4 永続的VNCサーバセッションを設定する #
永続的セッションは、複数のクライアントから同時にアクセスすることが可能です。この機能では、1つのクライアントがフルアクセスをもち、他のすべてのクライアントが表示専用アクセスを持つため、デモ用途に最適です。また、講師が受講生のデスクトップにアクセスする必要があるトレーニングセッションでも使用できます。
永続的VNCセッションに接続するには、VCNビューアをインストールする必要があります。詳細については、14.1項 「vncviewer
クライアント」を参照してください。または、JavaScriptを有効にしたWebブラウザで、URLとして「http://jupiter.example.com:5801
」を入力することにより、VNCセッションを表示できます。
14.4.1 vncmanager
を使用して開始されたVNCセッション #
まず、
› › の順に選択します。WebブラウザウィンドウでVNCセッションにアクセスする場合は、
をアクティブにします。必要な場合は、
にもチェックマークを付けます (たとえば、ネットワークインタフェースを外部ゾーンに属するように設定する場合)。ネットワークインタフェースが複数ある場合は、 で、特定のインタフェースにだけファイアウォールポートを開くように制限します。必要なパッケージの一部をまだ入手できない場合は、足りないパッケージのインストールを承認する必要があります。
ヒント: ディスプレイマネージャの再起動YaSTはディスプレイマネージャの設定を変更します。現在のグラフィカルセッションからログアウトし、ディスプレイマネージャを再起動して変更を有効にする必要があります。
14.4.1.1 永続的VNCセッションを設定する #
手順14.2「永続的VNCセッションの有効化」で説明したVNCセッション管理を有効にすると、通常、vncviewer
やRemminaなどの好みのVNCビューアでリモートセッションに接続できます。ログインすると、デスクトップ環境のシステムトレイに「VNC」アイコンが表示されます。アイコンをクリックすると、 ウィンドウが開きます。デスクトップ環境がシステムトレイのアイコンをサポートしていない場合は、vncmanager-controller
を手動で実行します。
VNCセッションの動作に影響するいくつかの設定があります。
これは一時的セッションに相当します。このセッションは他のユーザに表示されず、セッションを切断すると終了します。詳細については、14.3項 「VNCサーバでのワンタイムセッションの設定」を参照してください。
このセッションは他のユーザに表示され、セッションを切断しても実行され続けます。
永続的セッションの名前を指定して、再接続時に簡単に識別できるようにすることができます。
セッションに、ユーザの資格情報でログインすることなく、自由にアクセス可能です。
セッションにアクセスするには、有効なユーザ名とパスワードでログインする必要があります。
テキストボックスに有効なユーザ名を一覧表示します。同時に複数のユーザがセッションに参加しないようにします。
複数のユーザが永続的セッションに同時に参加できるようにします。リモートプレゼンテーションやトレーニングセッションに便利です。
をクリックして、確定します。
14.4.1.2 永続的VNCセッションへの参加 #
14.4.1.1項 「永続的VNCセッションを設定する」で説明した永続的VNCセッションを設定した後、VNCビューアでそのセッションに参加することができます。VNCクライアントからサーバに接続すると、新しいセッションを作成するか、既存のセッションに参加するかを選択するよう求めるプロンプトが表示されます。
既存のセッションの名前をクリックすると、永続的セッションの設定に応じて、ログインアカウント情報の入力を求められることがあります。
14.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の一般的な使用方法と同様)。
ヒント特定のVNCクライアントは、デフォルトの自己署名証明書を使用した安全な接続の確立を拒否します。たとえば、VinagreクライアントはGnuTLSグローバル信頼ストアに対して証明書を検証し、証明書が自己署名されている場合は失敗します。このような場合は、
x509
以外の暗号化方法を使用するか、VNCサーバ用に適切に署名された証明書を生成して、クライアントのシステム信頼ストアにインポートします。ヒント: 署名とキーのパスX509ベースの暗号化では、
-X509Cert
オプションと-X509Key
オプションで、X509証明書とキーのパスを指定する必要があります。
複数のセキュリティタイプをカンマで区切って選択した場合、クライアントとサーバの両方でサポートおよび許可されているセキュリティタイプが使用されます。この方法により、サーバ上で日和見暗号化を設定できます。これは、暗号化をサポートしないVNCクライアントをサポートする必要がある場合に便利です。
暗号化が有効であることがわかっているサーバに接続する場合、クライアント側で、許可されているセキュリティタイプを指定してダウングレード攻撃を防止することもできます(ただし、この場合、vncviewerではConnection not encrypted!
というメッセージで警告します)。
14.6 Waylandとの互換性 #
リモート管理(VNC)機能はX11を利用しており、Waylandが有効になっている場合は画面が空白になる可能性があります。ディスプレイマネージャは、WaylandではなくX11を使用するように設定する必要があります。gdmの場合、/etc/gdm/custom.conf
を編集します。[daemon]
セクションで、WaylandEnable=false
を設定ファイルに追加します。ログインするとき、ユーザは、X11互換セッションも選択する必要があります。GNOMEのWaylandオプションを削除する場合は、gnome-session-waylandパッケージを削除してロックしてください。
15 rsyncによるファイルのコピー #
現在の通常のユーザは、複数のコンピュータ(家庭用および職場用のマシン、ラップトップ、スマートフォン、またはタブレット)を持っています。このため、複数のデバイス間でファイルとドキュメントを同期させることがますます重要になっています。
同期ツールの使用を開始する前に、その特徴や機能を十分に理解しておく必要があります。重要なファイルは必ずバックアップしてください。
15.1 概念の概要 #
低速なネットワーク接続で大量のデータを同期するために、rsyncは、ファイル内の変更のみを転送して信頼性を高めています。この処理は、テキストファイルのみでなくバイナリファイルも対象となります。ファイル間の差分を検出するために、rsyncはファイルをブロック単位で分割してチェックサムを計算します。
変更の検出には特定の処理能力が要求されます。そのため、両側のマシンにRAMなどのリソースが十分あることを確認してください。
rsyncが特に役立つのは、わずかな変更しかない大量のデータを定期的に転送する必要がある場合です。多くの場合、バックアップの操作がこれに該当します。また、rsyncは、Webサーバのディレクトリツリー全体を格納するステージングサーバをDMZ内のWebサーバにミラーリングする場合にも便利です。
その名前に反して、rsyncは同期ツールではありません。データを一度に一方向にのみコピーするツールです。その逆にはコピーせず、コピーすることもできません。コピー元とコピー先の両方を同期できる双方向ツールが必要な場合は、Csyncを使用してください。
15.2 基本的な構文 #
rsyncは、次の基本的な構文を持つコマンドラインツールです。
rsync [OPTION] SOURCE [SOURCE]... DEST
アクセスパーミッションと書き込みパーミッションがあれば、ローカルマシンでもリモートマシンでも使用できます。複数のSOURCEエントリを指定できます。SOURCEおよびDESTのプレースホルダには、パス、URL、またはその両方を指定できます。
rsyncで最もよく使われるオプションは次のとおりです。
-v
より詳細なテキストを出力します。
-a
アーカイブモード。ファイルを再帰的にコピーし、タイムスタンプ、ユーザ/グループの所有権、ファイルパーミッション、およびシンボリックリンクを保持します。
-z
転送データを圧縮します。
rsyncを操作する場合は、特に末尾のスラッシュに注意する必要があります。ディレクトリの後に末尾のスラッシュがある場合、そのスラッシュはディレクトリの「内容」を示します。末尾のスラッシュがない場合は、「ディレクトリそのもの」を表します。
15.3 ファイルとディレクトリのローカルでのコピー #
次の説明は、現在のユーザがディレクトリ/var/backup
に対する書き込みパーミッションを持っていることを想定しています。1つのファイルをマシン上のディレクトリから別のパスにコピーするには、次のコマンドを使用します。
>
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/
にコピーします。
>
rsync
-avz tux /var/backup/
コピーは絶対パス/var/backup/tux/
にあります。
15.4 ファイルとディレクトリのリモートでのコピー #
両方のマシンにrsyncツールが必要です。リモートディレクトリ間でファイルをコピーするには、IPアドレスまたはドメイン名が必要です。ローカルマシンとリモートマシンの現在のユーザ名が同じ場合、ユーザ名は省略できます。
ファイルfile.tar.xz
をローカルホストからリモートホスト192.168.1.1
に同じユーザ(ローカルとリモート)でコピーするには、次のコマンドを使用します。
>
rsync
-avz file.tar.xz tux@192.168.1.1:
好みに応じて、次のコマンドを使用することもできます。処理結果は同じです。
>
rsync
-avz file.tar.xz 192.168.1.1:~>
rsync
-avz file.tar.xz 192.168.1.1:/home/tux
標準設定では、すべての場合に、リモートユーザのパスフレーズの入力を求めるプロンプトが表示されます。このコマンドは、file.tar.xz
をユーザtux
のホームディレクトリ(通常は/home/tux
)にコピーします。
ディレクトリをリモートでコピーする場合も、ローカルでコピーする場合と同様です。次の例では、ディレクトリtux/
とその内容をホスト192.168.1.1
のリモートディレクトリ/var/backup/
にコピーします。
>
rsync
-avz tux 192.168.1.1:/var/backup/
ホスト192.168.1.1
で書き込みパーミッションを持っていると想定すると、コピーは絶対パス/var/backup/tux
にあります。
15.5 rsyncサーバの設定と使用 #
rsyncは、デフォルトポート873で着信接続をリスンするデーモン(rsyncd
)として実行できます。このデーモンは「コピーターゲット」を受信できます。
次に、jupiter
上に「バックアップ」ターゲットを持つrsyncサーバを作成する方法を説明します。このターゲットを使用してバックアップを保存できます。rsyncサーバを作成するには、以下の手順を実行します。
jupiterで、すべてのバックアップファイルを保存するディレクトリを作成します。この例では、
/var/backup
を使用します。#
mkdir
/var/backup所有権を指定します。この場合、ディレクトリはグループ
users
のユーザtux
によって所有されます。#
chown
tux.users /var/backuprsyncdデーモンを設定します。
設定ファイルを、メインファイルと、バックアップターゲットを格納する特定の「モジュール」に分割します。こうすることで、後で他のターゲットを簡単に追加できます。グローバル値は
/etc/rsyncd.d/*.inc
ファイルに保存できます。一方、モジュールは/etc/rsyncd.d/*.conf
ファイルに配置します。ディレクトリ
/etc/rsyncd.d/
を作成します。#
mkdir
/etc/rsyncd.d/メイン設定ファイル
/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
次の行を使用して、ファイル
/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
次の内容で
/etc/rsyncd.secrets
ファイルを作成し、PASSPHRASEを置き換えます。# user:passwd tux:PASSPHRASE
root
のみがこのファイルを読み込めるようにします。#
chmod
0600 /etc/rsyncd.secrets
次のコマンドを使用して、rsyncdデーモンを起動して有効にします。
#
systemctl
enable rsyncd#
systemctl
start rsyncdrsyncサーバにアクセスできるかどうかをテストします。
>
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
を使用することもできます。競合が発生した場合は、手動で解決する必要があります。
15.6 詳細情報 #
- Csync
双方向ファイル同期ツール。https://csync.org/を参照してください。
- RSnapshot
増分バックアップを作成します。https://rsnapshot.orgを参照してください。
- Unison
CSyncに似たファイル同期ツールですが、グラフィカルインタフェースを備えています。https://www.seas.upenn.edu/~bcpierce/unison/を参照してください。
- Rear
ディザスタリカバリフレームワーク。Administration Guide of the SUSE Linux Enterprise High Availability, chapter Disaster Recovery with Rear (Relax-and-Recover)を参照してください。
パート II Linuxシステムのブート #
- 16 ブートプロセスの概要
Linuxシステムのブートには、さまざまなコンポーネントとタスクが関係しています。マシンのアーキテクチャに依存する、ファームウェアとハードウェアの初期化プロセスの後、ブートローダGRUB 2でカーネルを起動します。この時点以降、ブートプロセスはオペレーティングシステムの制御下に入り、
systemd
によって処理されます。systemd
は、日常的な使用、保守、または緊急時のために設定をブートする一連の「ターゲット」を提供します。- 17 UEFI (Unified Extensible Firmware Interface)
UEFI (Unified Extensible Firmware Interface) は、システムハードウェアに付属のファームウェア、システムのすべてのハードウェアコンポーネント、およびオペレーティングシステムの間のインタフェースです。
- 18 ブートローダGRUB 2
この章では、SUSE® Linux Enterprise Serverで使用されているブートローダGRUB 2の設定方法について説明します。これは、現在「GRUB Legacy」と呼ばれる従来のGRUBブートローダの後継バージョンです。GRUB 2は、SUSE® Linux Enterprise Serverのバージョン 12以降でデフォルトのブートローダとして使用されています。YaSTモジュールは、最も重要な設定を行うために使用できます。ブート手順は、総じて第16章 「ブートプロセスの概要」で説明しています。UEFIマシンでのセキュアブートのサポートの詳細については、第17章 「UEFI (Unified Extensible Firmware Interface)」を参照してください。
- 19
systemd
デーモン systemd
は、システムを初期化します。このプロセスのIDは1です。systemd
はカーネルによって直接起動され、通常はプロセスを強制終了するシグナル9が使えないようにします。他のすべてのプログラムは、systemd
または子プロセスのいずれかによって直接起動されます。systemd
は、System V initデーモンの後継であり、(initスクリプトのサポートにより)System V initと完全に互換性があります。
16 ブートプロセスの概要 #
Linuxシステムのブートには、さまざまなコンポーネントとタスクが関係しています。マシンのアーキテクチャに依存する、ファームウェアとハードウェアの初期化プロセスの後、ブートローダGRUB 2でカーネルを起動します。この時点以降、ブートプロセスはオペレーティングシステムの制御下に入り、systemd
によって処理されます。systemd
は、日常的な使用、保守、または緊急時のために設定をブートする一連の「ターゲット」を提供します。
16.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
という名前を排他的に使用します。
16.2 Linuxのブートプロセス #
Linuxのブートプロセスは、いくつかの段階から成り、それぞれ別のコンポーネントが実行しています。
16.2.1 初期化とブートローダの段階 #
初期化段階中に、マシンのハードウェアが設定され、デバイスが準備されます。このプロセスはハードウェアアーキテクチャによって異なります。
SUSE Linux Enterprise Serverは、すべてのアーキテクチャでブートローダGRUB 2を使用します。アーキテクチャおよびファームウェアによって、GRUB 2ブートローダの起動は、 マルチステップのプロセスとなる可能性があります。ブートローダの目的は、カーネルおよび、RAMベースの初期ファイルシステム(initramfs)をロードすることです。GRUB 2についての詳細については、第18章 「ブートローダGRUB 2」を参照してください。
16.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はブートローダとして動作します。ブートサーバからブートイメージを取得し、ローカルのハードディスクとは無関係にシステムを起動します。
16.2.1.2 IBM Zでの初期化とブートローダ段階 #
IBM Zでは、ブートプロセスは、zipl
(zイニシャルプログラムロード)と呼ばれるブートローダによって初期化される必要があります。zipl
は複数のファイルシステムからの読み込みをサポートしますが、SLEデフォルトファイルシステム(Btrfs)またはスナップショットからのブートはサポートしません。したがって、SUSE Linux Enterprise Serverはブート時に完全なBtrfsサポートを保証する2段階のブートプロセスを使用します。
zipl
は、Ext2、Ext3、Ext4、またはXFSファイルシステムでフォーマットできるパーティション/boot/zipl
からブートします。このパーティションには、メモリにロードされる最小のカーネルとinitramfsが含まれます。initramfsには、Btrfsドライバ(その他の間)およびブートローダGRUB 2が含まれます。カーネルはinitgrub
パラメータで開始され、GRUB 2を開始するように指示されます。カーネルはルートファイルシステムをマウントするため、
/boot
にアクセス可能になります。これでGRUB 2がinitramfsから開始されます。/boot/grub2/grub.cfg
から設定を読み込み、/boot
から最終的なカーネルとinitramfsをロードします。これで新しいカーネルがKexecを介してロードされます。
16.2.2 カーネルの段階 #
ブートローダがシステム制御に渡されると、ブートプロセスはすべてのアーキテクチャで同じになります。ブートローダはカーネルとRAMベースの初期ファイルシステム(initramfs
)をメモリにロードし、カーネルが引き継ぎます。
カーネルはメモリ管理を設定し、CPUタイプとその機能を検出した後で、ハードウェアを初期化し、initramfs
でロードされたメモリから一時ルートファイルシステムをマウントします。
16.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
で実行されます。
16.2.2.1.1 initramfsの再生成 #
initramfs
には、ドライバが含まれるため、そのドライバのいずれかの新しいバージョンが利用可能になるとすぐにinitramfsをアップデートする必要があります。これは、ドライバアップデートを含むパッケージをインストールするときに自動的に実行されます。YaSTまたはzypperは、initramfs
を生成するコマンドの出力を表示することで、これについて通知します。ただし、initramfs
を手動で再生成する必要がある特定の状況があります。
- ハードウェアの変更によるドライバの追加
ハードウェア(たとえば、ハードディスク)を変更する必要が生じ、ブート時にそのハードウェア用の他のドライバがカーネル内に必須の場合には、
initramfs
ファイルを更新する必要があります。/etc/dracut.conf.d/10-DRIVER.conf
を開くか作成し、次の行を追加します(先頭の空白に注意):force_drivers+=" DRIVER1 "
DRIVER1はドライバのモジュール名で置き換えます。複数のドライバを追加する必要がある場合は、それぞれをスペースで区切って指定します。
force_drivers+=" DRIVER1 DRIVER2 "
手順16.1「initramfsの生成」に従って手順を進めます。
- RAIDまたはLVMへのシステムディレクトリの移動
スワップファイル、または実行中のシステムの
/usr
などのシステムディレクトリをRAIDまたは論理ボリュームに移動するときには常に、ソフトウェアRAIDまたはLVMドライバのサポートを含むinitramfs
を作成する必要があります。これを行うには、
/etc/fstab
にそれぞれのエントリを作成し、新しいエントリをマウントします(たとえば、mount -a
および/またはswapon -a
を使用)。手順16.1「initramfsの生成」に従って手順を進めます。
- ルートファイルシステムを含むLVMグループまたはBtrfs RAIDへのディスクの追加
ルートファイルシステムを含む論理ボリュームグループまたはBtrfs RAIDにディスクを追加(または削除)する際には常に、 大きくなったボリュームのサポートを含む
initramfs
を作成する必要があります。手順16.1「initramfsの生成」の指示に従います。手順16.1「initramfsの生成」に従って手順を進めます。
- カーネル変数の変更
関連するファイル(
/etc/sysctl.conf
または/etc/sysctl.d/*.conf
)を編集して、sysctl
インタフェースでカーネル変数の値を変更した場合、次にシステムを再起動したときに変更内容が失われます。実行時にsysctl --system
を使用して値をロードしても、変更内容はinitramfs
ファイルに保存されません。手順16.1「initramfsの生成」の説明に従って手順を進め、アップデートする必要があります。
次の手順のすべてのコマンドをroot
ユーザとして実行する必要があります。
/boot
ディレクトリを入力します。#
cd /bootdracut
を使用して新しいinitramfs
ファイルを生成し、MY_INITRAMFSを任意のファイル名に置き換えます。#
dracut MY_INITRAMFSまたは、
dracut -f
FILENAMEを実行して、既存のinitファイルを置き換えます。(以前のステップで
dracut -f
を実行した場合は、このステップはスキップします)。以前のステップで作成したinitramfs
ファイルからinitrd
へのシンボリックリンクを作成します。#
ln -sf MY_INITRAMFSinitrd
IBM Zアーキテクチャで、
grub2-install
を補足的に実行します。
16.2.3 initramfs上のinit段階 #
initramfs
からカーネルによってマウントされた一時ルートファイルシステムには、(以下のinitramfs
上のinit
と呼ばれる)実行可能なsystemd
が含まれます。16.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 15 “IPネットワークの大容量記憶域: iSCSI”, Section 15.3.1 “YaSTを使ったiSCSIイニシエータの設定”を参照してください。
ルートファイルシステムをブート環境内からマウントできなかった場合は、ブートを続行する前にルートファイルシステムを確認して修復しておく必要があります。Ext3ファイルシステムおよびExt4ファイルシステムでは、ファイルシステムチェッカが自動的に起動されます。XFSファイルシステムおよびBtrfsファイルシステムでは修復プロセスが自動化されていないため、ファイルシステムを修復するために使用できるオプションに関する情報が表示されます。ファイルシステムが正常に修復された場合、ブート環境を終了すると、システムはルートファイルシステムのマウントを再試行します。成功した場合、ブートは通常どおり続行されます。
16.2.3.1 インストールプロセスのinitramfs上のinit段階 #
初期ブート時にインストールプロセスの一環としてinitramfs
上のinit
が呼び出される場合、そのタスクは上記で説明したタスクと異なります。インストールシステムはinitramfs
からsystemd
を起動せず、これらのタスクはlinuxrc
で実行されます。
- インストールメディアの検出
インストールプロセスを開始すると、マシンは、インストールカーネルと、YaSTインストーラを含む特殊な
init
をロードします。YaSTインストーラは、RAMファイルシステムで実行され、インストールメディアにアクセスしてオペレーティングシステムをインストールするために、そのメディアの場所に関する情報を必要とします。- ハードウェア認識の開始および適切なカーネルモジュールのロード
16.2.2.1項 「
initramfs
ファイル」で説明しているように、ブートプロセスはほとんどのハードウェア構成で使用できる最小限のドライバセットで開始されます。AArch64、POWER、およびAMD64/Intel 64マシンでは、linuxrc
は、ハードウェア構成に適したドライバセットを判断する、初期ハードウェアスキャンプロセスを開始します。IBM Zでは、ドライバのリストおよびそのパラメータは、linuxrcまたはparmfileなどを介して提供される必要があります。これらのドライバは、システムをブートするために必要なカスタム
initramfs
を生成するために使用されます。ブートに必要なくてもコールドプラグには必要なモジュールがある場合は、systemd
を使用してロードできます。詳細については、19.6.4項 「カーネルモジュールのロード」を参照してください。- インストールシステムのロード
ハードウェアが適切に認識されると、適切なドライバがロードされます。
udev
プログラムが特殊なデバイスファイルを作成し、linuxrc
は、YaSTインストーラを使用してインストールシステムを起動します。- YaSTの起動
最後に、
linuxrc
はYaSTを起動し、これによってパッケージのインストールとシステム設定が開始されます。
16.2.4 systemd段階 #
「実際の」ルートファイルシステムが見つかると、エラーをチェックしてからマウントします。これが正常に実行されれば、initramfs
はクリアされ、ルートファイルシステムでsystemd
デーモンが実行されます。systemd
はLinuxのシステムおよびサービスマネージャです。PID 1として起動する親プロセスで、ユーザスペースサービスを起動して維持するinitシステムとして機能します。詳細については第19章 「systemd
デーモン」を参照してください。
17 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)。
詳細については、https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interfaceを参照してください。以降のセクションは、UEFIの一般的な概要を示すものではなく、特定の機能がSUSE Linux Enterprise Serverにどのように実装されているかを示すヒントです。
17.1 セキュアブート #
UEFIの世界では、ブートストラッププロセスの保護とは、信頼チェーンの確立を意味します。SUSE Linux Enterprise Serverとの関連では、「プラットフォーム」はこの信頼チェーンのルートであり、マザーボードおよびオンボードファームウェアが「プラットフォーム」とみなされます。別の言い方をすれば、ハードウェアベンダー、およびそのハードウェアベンダーからコンポーネントの製造元やOSベンダーなどにつながる信頼チェーンです。
信頼は公開鍵の暗号で表されます。ハードウェアベンダーは、ファームウェアにいわゆるプラットフォームキー(PK)を設定し、信頼のルートを表します。オペレーティングシステムベンダーなどとの信頼関係は、このプラットフォームキーを使ってキーに署名することによって文書化されます。
最後に、これらの「信頼された」キーのいずれかで署名されていない限りファームウェアがコード(OSブートローダも、特定のPCI Expressカードやディスクのフラッシュメモリに保存されたドライバも、ファームウェアのアップデートも)を実行できないようにすることによって、セキュリティが確立されます。
セキュアブートを使用するには、ファームウェアによって信頼されたキーで署名されたOSローダが必要であり、読み込むカーネルが信頼できることを検証するためにOSローダが必要です。
キー交換キー(KEK)をUEFIキーデータベースに追加できます。この方法で、PKのプライベート部分で署名されている場合、他の証明書を使用できます。
17.1.1 SUSE Linux Enterprise Serverへの実装 #
Microsoftのキー交換キー(KEK)がデフォルトでインストールされます。
セキュアブート機能は、UEFI/x86_64インストール環境ではデフォルトで有効になっています。
オプションは、 ダイアログの タブにあります。ファームウェアでセキュアブートが有効になっている場合のブート、および無効になっている場合のブートもサポートします。セキュアブート機能を使用するには、マスタブートレコード(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)によって署名されたローダを入手できます。
実装層で、SUSEは、デフォルトでインストールされているshim
ローダを使用します。法的な問題を回避するスマートなソリューションであり、証明書と署名に関する手順を大きく簡素化します。shim
ローダの処理は、GRUB 2などのブートローダをロードすることです。次にこのブートローダが、SUSEキーのみで署名されたカーネルをロードします。
信頼ユーザには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と呼びます。
次に、ブートローダはカーネルを検証および起動し、カーネルがモジュールで同じことを実行します。
17.1.2 Machine Owner Key(マシン所有者キー、MOK) #
ブートプロセスの一部である特定のカーネル、ドライバ、または他のコンポーネントを置き換えるには、マシン所有者キー(MOK)を使用する必要があります。mokutil
ツールはMOKを管理するのに役立ちます。
mokutil
を使用してMOK登録要求を作成できます。要求は、MokNew
と呼ばれるUEFIランタイム(RT)変数に保存されます。次のブート時に、shim
ブートローダはMokNew
を検出して、MokManager
をロードします。これにより、いくつかのオプションが表示されます。 および オプションを使用して、MokListにキーを追加できます。 オプションを使用して、MokNew
変数からキーをコピーします。
ディスクからのキーの登録は、通常、shimがgrub2
のロードに失敗し、MokManagerのロードにフォールバックする場合に実行されます。MokNew
はまだ存在しないため、UEFIパーティションでキーを検索するオプションがあります。
17.1.3 カスタムカーネルのブート #
以下はhttps://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernelにもとづいています。
セキュアブートでは、セルフコンパイルカーネルを使用できます。ただし、独自の証明書を使って署名し、その証明書をファームウェアまたはMOKに知らせる必要があります。
カスタムのX.509キー、および署名に使用される証明書を作成します。
openssl req -new -x509 -newkey rsa:2048 -keyout key.asc \ -out cert.pem -nodes -days 666 -subj "/CN=$USER/"
証明書の作成の詳細については、https://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificateを参照してください。
PKCS#12形式でキーと証明書をパッケージ化します。
>
openssl pkcs12 -export -inkey key.asc -in cert.pem \ -name kernel_cert -out cert.p12pesign
とともに使用するNSSデータベースを生成します。>
certutil -d . -NPKCS#12に含まれるキーおよび証明書をNSSデータベースにインポートします。
>
pk12util -d . -i cert.p12pesign
を使用して、新しい署名でカーネルを「bless」します。>
pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \ -o vmlinuz.signed -sカーネルイメージの署名をリスト表示します。
>
pesign -n . -S -i vmlinuz.signedその時点で、通常通り
/boot
にカーネルをインストールできます。カーネルにはカスタム署名があるため、署名に使用された証明書をUEFIファームウェアまたはMOKにインポートする必要があります。ファームウェアまたはMOKにインポートするため、証明書をDERフォーマットに変換します。
>
openssl x509 -in cert.pem -outform der -out cert.derよりアクセスしやすくするため、証明書をESPにコピーします。
>
sudo
cp cert.der /boot/efi/mokutil
を使用して自動的にMOKリストを起動します。証明書をMOKにインポートします。
>
mokutil --root-pw --import cert.der--root-pw
オプションにより、root
ユーザを直接使用できます。これから登録する証明書のリストを確認します。
>
mokutil --list-newシステムを再起動します。
shim
によってMokManagerが起動されるはずです。root
パスワードを入力して、MOKリストに証明書をインポートすることを確認してください。新しくインポートしたキーが登録されたかどうかを確認します。
>
mokutil --list-enrolled
また、MOKを手動で起動するには以下の手順を実行します。
再起動
GRUB 2メニューで
c
キーを押します。タイプ:
chainloader $efibootdir/MokManager.efi boot
cert.der
ファイルに移動してEnterキーを押します。指示に従ってキーを登録します。通常、「0」を押してから「y」を押して確認します。
また、ファームウェアメニューに、署名データベースに新しいキーを追加する方法が用意されている場合があります。
17.1.4 Inbox以外のドライバの使用 #
セキュアブートを有効にしたインストールでは、Inbox以外のドライバ(SUSE Linux Enterprise Serverに付属していないドライバ)の追加がサポートされません。SolidDriver/PLDPで使用される署名キーは、デフォルトでは信頼されていません。
セキュアブートを有効にしたインストールでは、サードパーティドライバを2つの方法でインストールできます。いずれの方法でも以下を行います。
インストール前にファームウェア/システム管理ツールを使用して、必要なキーをファームウェアデータベースに追加します。このオプションは、使用している特定のハードウェアによって異なります。詳細については、ハードウェアベンダーに問い合わせてください。
https://drivers.suse.com/またはハードウェアベンダーから入手したブート可能なドライバISOを使用して、初回ブート時に必要なキーをMOKリストに登録します。
ブート可能なドライバISOを使用してドライバキーをMOKリストに登録するには、次の手順に従います。
空のCD/DVDメディアに上記のISOイメージを書き込みます。
この新しいCD/DVDメディアを使用してインストールを開始します。その際には、標準のインストールメディア、またはネットワークインストールサーバへのURLを用意しておきます。
ネットワークインストールを行う場合、ブートコマンドラインで
install=
オプションを使用して、ネットワークインストールソースのURLを入力します。光学メディアからインストールする場合、インストーラが最初にドライバキットからブートされた後、製品の最初のインストールディスクを挿入するように要求されます。
アップデートされたドライバを含むinitrdが、インストールに使用されます。
詳細については、https://drivers.suse.com/doc/Usage/Secure_Boot_Certificate.htmlを参照してください。
17.1.5 機能と制限 #
セキュアブートモードでブートする場合、次の機能が適用されます。
UEFIのデフォルトのブートローダがある場所へのインストール。これは、EFIブートエントリを維持または復元するメカニズムです。
UEFIを介して再起動する。
フォールバック先のレガシーBIOSがない場合、XenハイバーバイザはUEFIを使用してブートする。
UEFI IPv6 PXEブートのサポート。
UEFIビデオモードのサポート。カーネルはUEFIからビデオモードを取得して、同じパラメータでKMSモードを設定できます。
USBデバイスからのUEFIブートがサポートされる。
SUSE Linux Enterprise Server 15 SP3以降、KexecとKdumpは、セキュアブートモードでサポートされています。
セキュアブートモードでブートする場合、次の制限が適用されます。
セキュアブートを簡単に回避できないようにするため、セキュアブートで実行する場合は特定のカーネル機能が無効になっています。
ブートローダ、カーネル、およびカーネルモジュールが署名されている必要があります。
ハイバネーション(ディスクの休止)は無効になっています。
ルートユーザであっても、
/dev/kmem
および/dev/mem
にアクセスできません。ルートユーザであっても、I/Oポートにアクセスできません。すべてのX11グラフィカルドライバはカーネルドライバを使用する必要があります。
sysfs経由でPCI BARにアクセスすることはできません。
ACPIの
custom_method
は使用できません。asus-vmiモジュールに対してdebufgsを使用できません。
acpi_rsdp
パラメータはカーネルに影響を及ぼしません。
17.2 詳細情報 #
https://uefi.org —UEFIのホームページです。現在のUEFI仕様が掲載されています。
Olaf Kirch氏およびVojtěch Pavlík氏によるブログ記事(上の章の内容はこれらの記事に基づいています)。
https://en.opensuse.org/openSUSE:UEFI —UEFIとopenSUSEに関するページです。