目次にジャンプ
documentation.suse.com / 管理ガイド
SUSE Linux Enterprise Server 15 SP6

管理ガイド

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

発行日: 2024 年 12 月 12 日
図の一覧
例の一覧

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バージョンの見出しの横にあるReport an issue (問題を報告する)アイコンをクリックしてください。これにより、Bugzillaで適切な製品とカテゴリが事前に選択され、現在のセクションへのリンクが追加されます。バグレポートの入力を直ちに開始できます。

Bugzillaアカウントが必要です。

ドキュメントの編集に貢献

このドキュメントに貢献するには、このドキュメントのHTMLバージョンの見出しの横にあるEdit source document (ソースドキュメントの編集)アイコンをクリックしてください。GitHubのソースコードに移動し、そこからプルリクエストをオープンできます。

GitHubアカウントが必要です。

注記
注記: Edit source document (ソースドキュメントの編集)は英語でのみ利用可能

Edit source document (ソースドキュメントの編集)アイコンは、各ドキュメントの英語版でのみ使用できます。その他の言語では、代わりにReport an issue (問題を報告する)アイコンを使用してください。

このドキュメントに使用されるドキュメント環境に関する詳細については、リポジトリのREADMEを参照してください。

メール

ドキュメントに関するエラーの報告やフィードバックは<>宛に送信していただいてもかまいません。ドキュメントのタイトル、製品のバージョン、およびドキュメントの発行日を記載してください。また、関連するセクション番号とタイトル(またはURL)、問題の簡潔な説明も記載してください。

3 マニュアルの表記規則

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

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

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

  • PATH: 環境変数

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

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

  • package_name: ソフトウェアパッケージの名前

  • AltAltF1: 押すキーまたはキーの組み合わせ。キーはキーボードのように大文字で表示されます。

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

  • 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について説明します。このコンテキストで使用される用語(repositorypatchupdateなど)の定義については、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の環境設定ファイル

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

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

  2. 通常の対話型シェル.  xtermやkonsole、gnome-terminalなどのコマンドラインインタフェース(CLI)ツールの起動時には、通常、この形式を使用します。

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

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

ヒント
ヒント

Bashは、実行されているシェルのタイプに応じて特定の順序で設定ファイルを検索します。詳細については、Bashのマニュアルページ(man 1 bash)を参照してください。見出しINVOCATIONを検索します。

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

ファイル

説明

/etc/profile

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

/etc/profile.local

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

/etc/profile.d/

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

~/.profile

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

ログインシェルは、表1.2「非ログインシェル用Bash設定ファイル」に示す設定ファイルも参照します。

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

/etc/bash.bashrc

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

/etc/bash.bashrc.local

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

~/.bashrc

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

また、Bashは複数のファイルを使用します。

表 1.3: Bash用特殊ファイル

ファイル

説明

~/.bash_history

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

~/.bash_logout

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

~/.alias

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

非ログインシェル

ユーザがシステムにログインするのをブロックする特殊なシェル(/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システムの最も重要な上位レベルディレクトリについて、短い概要を示します。それらのディレクトリおよび重要なサブディレクトリの詳細については、後続のリストを参照してください。

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

ディレクトリ

目次

/

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

/bin

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

/boot

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

/dev

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

/etc

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

/home

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

/lib

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

/media

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

/mnt

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

/opt

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

/root

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

/sbin

必須のシステムバイナリ

/srv

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

/tmp

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

/usr

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

/var

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

/windows

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

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

/bin

rootと他のユーザの両者が使用できる基本的なシェルコマンドを含みます。これらのコマンドには、lsmkdircpmvrm、および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/dochowtoサブディレクトリも含まれます。このサブディレクトリには、Linuxソフトウェアの設定および操作に関する多数のタスクの追加ドキュメントが格納されます。

/var

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

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

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

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

1

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

2

2行目は、ハッシュ記号で始まるコメントです。意図を理解しにくい行にはコメントすることをお勧めします。適切にコメントすると、行の目的および機能を覚えることができます。また、他の読み手もスクリプトをより良く理解できます。コメントは開発コミュニティにおいてグッドプラクティスとみなされます。

3

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

このスクリプトを実行するには、その前にいくつかの前提条件があります。

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

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

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

    > chmod +x ~/bin/hello.sh

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

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

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

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

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

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

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

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

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

Command > File

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

> ls > listing.txt
Command >> File

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

> ls >> listing.txt
Command < File

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

> read a < foo
Command1 | Command2

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

> cat /proc/cpuinfo | grep cpu

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

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

1.4 エイリアスの使用

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

alias NAME=DEFINITION

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

> alias lt='ls -ltr'

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

1.5 Bashでの変数の使用

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

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

> printenv PATH

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

> echo $PATH

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

> PROJECT="SLED"

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

> export NAME="tux"

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

> unset NAME

次の表には、シェルスクリプトで使用できる一般的な環境変数が含まれています。

表 1.5: 便利な環境変数

HOME

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

HOST

現在のホスト名

LANG

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

PATH

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

PS1

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

PS2

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

PWD

現在の作業ディレクトリ

USER

現在のユーザ

1.5.1 引数変数の使用

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

> foo.sh "Tux Penguin" 2000

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

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

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

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

"Tux Penguin" "2000" "" ""

1.5.2 変数置換の使用

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

${VAR#pattern}

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

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

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

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

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

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

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

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

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

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

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

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

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

Command1 ; Command2

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

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

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

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

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

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

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

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

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

> hello Tux

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

Hello Tux

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

スクリプトのフローを制御するために、シェルには、whileiffor、およびcaseコンストラクトがあります。

1.7.1 if制御コマンド

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

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

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

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

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

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

その他の役に立つ式については、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に記載されています。このトピックの詳細については、次のリストを参照してください。

2 sudoの基本

特定のコマンドを実行するには、root特権が必要です。ただし、セキュリティ上の理由のため、また間違いを避けるため、rootとしてログインすることは推奨されません。より安全な方法は、通常のユーザとしてログインしてから、sudoを使用して昇格された特権でコマンドを実行することです。

SUSE Linux Enterprise Serverでは、sudosuと同様に機能するように設定されています。ただし、sudoには、ユーザが他のユーザの特権でコマンドを実行できるようにする柔軟なメカニズムがあります。このコマンドを使用して、指定の特権を持つ役割を特定のユーザとグループに割り当てることができます。たとえば、usersグループのメンバーが、wilberユーザの特権でコマンドを実行できるようにすることができます。コマンドへのアクセスは、コマンドオプションを禁止することにより、さらに制限できます。suでは、PAMを使用した認証で常にrootパスワードを必要としますが、sudoでは、ユーザの資格情報を使用して認証するように設定できます。すなわち、ユーザはrootパスワードを共有する必要がなく、セキュリティが向上します。

2.1 sudoの基本的な使用方法

次の章では、sudoの基本的な使用方法の概要について説明します。

2.1.1 単一コマンドの実行

標準ユーザは、コマンドの前にsudoを追加することで、任意のコマンドをrootとして実行できます。これにより、rootパスワードを入力するように求められます。正常に認証されたら、rootとしてコマンドが実行されます。

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

1

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

2

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

3

sudoで始まるコマンドのみが、昇格された特権で実行されます。

4

昇格された特権は特定の期間保持されるため、再びrootパスワードを入力する必要はありません。

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

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 # exit
tux:~ > 
sudo -i (<command>)

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

tux:~ > sudo -i
root's password:
root:~ # exit
tux:~ > 
ヒント
ヒント: 環境変数

デフォルトでは、sudoは環境変数を伝達しません。この動作は、env_resetオプションを使用して変更できます(有用なフラグとオプションを参照してください)。

2.2 sudoの構成

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_myfirstconfig10_myotherconfigよりも前に解析されます。順番に読み取られる複数のディレクティブを設定したファイルで、これらの各ディレクティブに記述された情報が互いに矛盾していると、最後に読み込まれたディレクティブが適用されます。

必ずわかりやすいファイル名を使用する

設定ファイルの機能がわかるようなファイル名を使用します。sudoのセットアップで想定している動作を追跡する際に、この措置が効果的です。

2.2.2 ユーザ固有の設定ファイルの作成

通常のユーザ(tux)が、rootパスワードではなく自身のパスワードを使用して、useraddコマンドを使用できるように、sudoの設定ファイルを作成します。

例 2.1: ユーザ固有の設定ファイルの作成
  1. 新しいユーザ固有のディレクティブを保持するカスタム設定ファイルを作成します。そのためには、システム管理者(root)としてvisudoを起動します。番号付けと説明的な名前の両方を使用します。

      # visudo -f /etc/sudoers.d/02_usermanagement
  2. このsudo設定を適用する環境全体でtux/usr/sbin/useraddバイナリを実行できるようにするルールを作成します。

      tux1 ALL2 = /usr/sbin/useradd3

    1

    ユーザまたはグループを指定します。ユーザは、名前または#UIDで一覧にし、グループは、%GROUPNAMEで一覧にします。複数の項目はコンマで区切ります。エントリを無効にするには!を使用します。

    2

    ホストを1つまたはコンマで区切って複数指定します。完全修飾ホスト名またはIPアドレスを使用します。すべてのホストにこの設定をグローバルに適用するにはALLを追記します。適用しない場合は!を使用します。

    3

    実行可能ファイルを1つまたはコンマで区切って複数指定します。各ファイルの指定では次のルールに留意します。

    /usr/sbin/useradd

    追加オプションを追記しない場合は、実行可能なすべてのuseraddコマンドを実行できます。

    /usr/sbin/useradd -c

    明示的にオプションを指定すると、そのオプションのみが適用されます。上記で指定したユーザは、これ以外のオプションを利用できません。

    /usr/sbin/useradd ""

    オプションを指定せずにuseraddの呼び出しのみができるようにします。

    上記の例では、すべてのオプションおよびサブコマンドを許可したり、セキュリティ上の理由からいくつかに制限したりできますが、ユーザがオプションを指定できないようにすることは、このコンテキストでは意味がありません。

  3. ユーザがrootパスワードの代わりに、自分のパスワードを使用できるようにするには、次の行を追加します。

    Defaults:tux !targetpw

    このフラグがアクティブな場合、目的のユーザ(root)のパスワードの入力が求められます。SUSE Linux Enterprise Serverシステムでは、このフラグがデフォルトで有効になっています。!を使用してこのフラグを無効にすると、ユーザはrootパスワードの代わりに自分のパスワードの入力を求められます。

  4. 設定を保存し、エディタを終了して、2番目のシェルを開き、sudoが新しい設定に従うかどうかをテストします。

2.2.3 項目のグループ化によるカスタム設定の作成

指定したユーザのグループがrootパスワードを必要とせずにuseraddコマンドを実行できるように、例2.1「ユーザ固有の設定ファイルの作成」の設定を変更します。また、このグループで使用できるコマンドのリストにusermoduserdelを追加します。

例 2.2: 項目のグループ化によるカスタム設定の作成
  1. この設定例を変更するには、visudoを使用してシステム管理者として設定を開きます。

    # visudo /etc/sudoers.d/02_usermanagement
  2. コンマ区切りで記述した複数のユーザをルールに追加します。

    tux, wilber ALL = /usr/sbin/useradd
  3. ここで記述したユーザが複数のコマンドを実行できるようにするには、それらのコマンドをコンマ区切りで指定します。

    tux, wilber ALL = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
  4. ここで記述したユーザがrootパスワードの代わりに、自分のパスワードを使用できるようにするには、次の行を追加します。

    Defaults:tux, wilber !targetpw

    このフラグがアクティブな場合、ここで記述したユーザは目的のユーザ(root)のパスワードの入力が求められます。SUSE Linux Enterprise Serverシステムでは、このフラグがデフォルトで有効になっています。!を使用してこのフラグを無効にすると、ここで記述したユーザはrootパスワードの代わりに自分のパスワードの入力を求められます。

  5. 設定を保存し、エディタを終了して、2番目のシェルを開き、sudoが新しい設定に従うかどうかをテストします。

2.2.4 エイリアスの適用による設定の簡潔化

エイリアスを使用して、例2.2「項目のグループ化によるカスタム設定の作成」のカスタム設定の簡素化を進めます。項目をグループ化することはある程度役立ちますが、ユーザ、コマンド、およびホストのグローバルエイリアスを使用することが、クリーンで無駄のないsudo設定を保つための最も効率的な方法です。

リストの代わりにエイリアスやグループを使用する方が、セットアップの変更に対処する上ではるかに良い方法です。グループからユーザが離れる場合は、独立したカスタム設定ファイルをすべて調べるのではなく、エイリアス宣言ファイル内のグローバルUser_Alias宣言からそのユーザを削除するだけですみます。他のタイプのエイリアス(Host_AliasCmnd_Alias、およびRunas_Alias)についても、同じ手順が適用されます。

例 2.3: エイリアスの適用による設定の簡潔化
  1. グローバルエイリアス定義を保持する新しいファイルを作成します。

    # visudo /etc/sudoers.d/01_aliases
  2. 次の行を追加して、TEAMLEADERSエイリアスを作成します。

    User_Alias    TEAMLEADERS = tux, wilber
  3. 次の行を追加して、USERMANAGEMENTエイリアスを作成します。

    Cmnd_Alias    USERMANAGEMENT = /usr/sbin/useradd, /usr/sbin/usermod, /usr/sbin/userdel
  4. 変更を保存し、visudoを終了します。

  5. システム管理者としてvisudoを起動して、設定ファイル例を次のように編集します。

    # visudo -f /etc/sudoers.d/02_usermanagement
  6. 前のルールを削除し、上記で定義したエイリアスを使用する次のルールに置き換えます。

    TEAMLEADERS ALL = USERMANAGEMENT
  7. User_Aliasで定義されたすべてのユーザがrootパスワードの代わりに、自分のパスワードを使用できるようにするには、次の行を追加します。

    Defaults:TEAMLEADERS !targetpw
  8. 設定を保存し、エディタを終了して、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

1

例外が2つあります。#include#includedirは通常のコマンドです。

2

!文字を削除して、目的のフラグをONに設定します。

3

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

設定すると、sudoTERMPATHHOMEMAILSHELLLOGNAMEUSERUSERNAME、および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
sudoersルールの構文
User_List

1つ以上の(コンマで区切られた)識別子。ユーザ名、%GROUPNAME形式のグループ、または#UID形式のユーザIDを指定します。否定は!プレフィクスで指定できます。

Host_List

1つ以上の(コンマで区切られた)識別子。(完全修飾された)ホスト名またはIPアドレスのいずれかを指定します。否定は!プレフィクスで指定できます。通常、Host_ListにはALLを選択します。

NOPASSWD:|PASSWD:

NOPASSWD:の後に記述した、Cmd_Listと一致するコマンドを実行する場合は、パスワードが要求されません。

PASSWDはデフォルトです。PASSWDNOPASSWDの両方が同じ行に存在する場合にのみ指定する必要があります。

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

1つまたは複数の(コンマで区切られた)指定子。実行可能ファイルへのパスの後に、オプションで使用可能な引数を指定します。

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

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

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

tux ALL = NOPASSWD: ALL

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

tux ALL = /usr/bin/systemctl restart apache2

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

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

Defaults targetpwなしで、ALL ALL = ALLのようなルールを使用「しないでください」。そうしないと、だれでもrootとしてコマンドを実行できるようになります。

重要
重要: Winbindとsudo

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のすべてのモジュールはカテゴリ別にグループ化されており、ナビゲーションサイドバーによって、目的のカテゴリのモジュールに素早くアクセスできます。上部の検索フィールドでは、名前でモジュールを検索することができます。特定のモジュールを検索するには、検索フィールドにその名前を入力します。入力すると、入力した文字列に一致するモジュールが表示されます。

重要
重要: インストールされるYaSTモジュールのリスト

ncursesベースのYaSTとGUIバージョンのYaSTでは、インストールされるモジュールのリストが異なる場合があります。YaSTモジュールを起動する前に、使用しているYaSTのバージョンに合わせてインストールされていることを確認してください。

3.2 便利なキーの組み合わせ

YaSTのグラフィカルバージョンはキーボードショートカットをサポートしています

Print Screen

スクリーンショットを作成して保存します。特定のデスクトップ環境では機能しない場合があります。

ShiftF4

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

ShiftF7

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

ShiftF8

ファイルダイアログを開いて、ログファイルをユーザ定義の場所に保存します。

CtrlShiftAltD

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

CtrlShiftAltM

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

CtrlShiftAltP

マクロを再生します。

CtrlShiftAltS

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

CtrlShiftAltT

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

CtrlShiftAltX

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

CtrlShiftAltY

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

4 テキストモードのYaST

ncursesベースの疑似グラフィカルYaSTインタフェースは、主にシステム管理者がXサーバを使用せずにシステムを管理できるように設計されています。このインタフェースには、従来のGUIと比較していくつかの利点があります。キーボードを使用してncursesインタフェースをナビゲートすることができ、事実上すべてのインタフェース要素に対するキーボードショートカットがあります。ncursesインタフェースは、リソースが少なく、中程度のハードウェアでも高速に実行されます。SSH接続を介してncursesベースのバージョンのYaSTを実行することができるため、リモートシステムを管理できます。YaSTを実行するためのターミナルエミュレータの最小サポートサイズは、80x25文字であることに注意してください。

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

ncursesベースのバージョンのYaSTを起動するには、端末を開いて、sudo yast2コマンドを実行します。<Tab>または矢印キーを使用して、メニュー項目、フィールド、ボタンなどのインタフェース要素間をナビゲートします。YaSTのすべてのメニュー項目およびボタンには、適切なファンクションキーまたはキーボードショートカットを使用してアクセスできます。たとえば、F9を押して現在の操作をキャンセルし、F10キーを使用して変更を受け入れることができます。YaSTのncursesベースのインタフェースの各メニュー項目およびボタンには、そのラベルにハイライトされた文字があります。この文字は、インタフェース要素に割り当てられたキーボードショートカットの一部です。たとえば、文字Q終了ボタンでハイライトされます。これは、AltAlt+Qを押してボタンを有効にできることを意味します。

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

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

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

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

ボタンと選択リスト間の移動

選択リストを含むボタンおよびフレーム間を移動するには、<Tab>を使用します。反対方向に移動するには、Alt<Tab>またはShift<Tab>の組み合わせを使用します。

選択リストでのナビゲート

選択リストを含むアクティブフレーム内の個々の要素間を移動するには、矢印キー()を使用します。個々のエントリがフレームの幅よりも長い場合は、ShiftキーまたはShiftキーを使用して水平にスクロールします。矢印キーで選択範囲が別のフレームに移動する場合は、代わりにCtrlEまたはCtrlAを使用してください。

ボタン、ラジオボタン、チェックボックスの操作

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

特殊キー

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

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

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

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

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

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

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

ncursesベースのバージョンのYaSTは、高度なキーの組み合わせを提供します。

ShiftF1

高度なホットキーを一覧表示します。

ShiftF4

配色を変更します。

CtrlQ

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

CtrlL

画面を更新します。

CtrlDF1

高度なホットキーを一覧表示します。

CtrlDShiftD

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

CtrlDShiftY

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

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

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

Escの代わりにAltを使用

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

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

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

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

ファンクションキー(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

ダンプカーネルイメージの(圧縮)形式を指定します。使用可能な形式は、noneELFcompressedまたは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サービス(smbnmb)を有効または無効にします。

> 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

現在のセキュリティ設定の概要を表示します。

sudoyast 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

サウンドカードの音量レベルを指定します。

sudoyast 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 &を実行して、言語ダイアログを直接起動することもできます。

Image
手順 5.1: 追加言語をインストールする

追加言語をインストールするときに、YaSTを使用してrootユーザにいくつかのロケールを設定できます。ステップ 4を参照してください。/etc/sysconfig/languageファイルのロケール変数(LC_*)をrootに対してどのように設定するかは、rootユーザのロケール設定オプションで指定します。それらを通常ユーザ用と同じロケールに設定するか、言語の変更によってまったく影響されないようにするか、または変数RC_LC_CTYPEだけを通常ユーザ用と同じ値に設定することができます。RC_LC_CTYPE変数は、言語固有の関数呼び出しのローカライゼーションを設定します。

  1. YaSTの言語モジュールで言語を追加するには、第二言語でインストールする言語を選択します。

  2. 言語をデフォルト言語にするには、その言語を第一言語として設定します。

  3. さらに、新しい第一言語に合わせてキーボードを変更し、必要に応じてタイムゾーンを調整します。

    ヒント
    ヒント: 詳細設定

    高度なキーボード設定を指定するには、YaSTでハードウェア › システムキーボード配列の順に選択します。高度なタイムゾーン設定を指定するには、YaSTでシステム › 日付と時刻の順に選択します。詳細については、第32章 「システムのキーボードレイアウト設定および5.2項 「国および時間の設定の変更」を参照してください。

  4. rootユーザに固有の言語設定を変更するには、詳細情報をクリックします。

    1. rootユーザのロケール設定を目的の値に設定します。詳細については、ヘルプをクリックします。

    2. rootUTF-8 エンコーディングを使用を使用するかどうかを決めます。

  5. ロケールが利用可能な第一言語のリストに含まれていない場合は、詳細なロケール設定で、そのロケールを指定してください。ただし、特定のロケールが不完全になる場合があります。

  6. OKをクリックして、ダイアログで行った変更を確認します。第二言語を選択していれば、その追加言語にローカライズされたソフトウェアパッケージがYaSTによってインストールされます。

これで、システムが多言語になります。ただし、第一言語以外の言語でアプリケーションを起動するには、該当する言語を5.1.3項 「標準のXアプリケーションとGNOMEアプリケーションでの言語切り替え」の説明どおりに明示的に設定する必要があります。

5.1.2 デフォルトシステム言語を切り替える

デフォルトのシステム言語をグローバルに切り替えるには、次の手順に従います。

  1. YaSTの言語モジュールを起動します。

  2. 第一言語で新しいシステム言語を選択します。

    重要
    重要: 以前のシステム言語の削除

    別の第一言語に切り替えると、以前の第一言語用にローカライズされたソフトウェアパッケージがシステムから削除されます。デフォルトシステム言語を切り替えても、以前の第一言語は追加言語として保持するには、該当するチェックボックスをオンにすることで、以前の第一言語を第二言語として追加できます。

  3. キーボードとタイムゾーンのオプションを適宜調整します。

  4. OKをクリックして、変更を確認します。

  5. 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 &を実行して、時計とタイムゾーンダイアログを直接起動することもできます。

Image

まず、ヨーロッパなどの一般的な地域を選択します。作業地と一致する国(たとえば、ドイツ)を選択します。

ワークステーションで実行されるオペレーティングシステムに応じて、ハードウェアクロックの設定を調整します。

  • マシン上でMicrosoft Windows*などの別のオペレーティングシステムを実行している場合、システムでは、UTCではなく、ローカルタイムを使用している可能性があります。この場合は、ハードウェアの時刻をUTCに設定するをオフにします。

  • コンピュータでLinuxだけを実行する場合は、ハードウェアクロックをUTCに設定し、標準時間から夏時間への切り換えを自動的に実行させます。

重要
重要: UTCへのハードウェアクロックの設定

標準時間からサマータイムへの転換(およびその逆)は、ハードウェアロック(CMOSクロック)がUTCに設定されている場合にのみ、自動的に行われます。この処理は、NTPとの時間の自動同期機能を使用している場合にも実行されます。これは、ハードウェアとシステムクロックの時間差が15分未満であれば、時間の自動同期が機能するからです。

誤ったシステム時間は、深刻な問題の原因になる場合があります(バックアップの失敗、メールメッセージの削除、リモートファイルシステムでの障害の発生など)。ハードウェアのクロックを「常に」UTCに設定することを強くお勧めします。

日付と時刻を手動で変更できるほか、NTPサーバにマシンが永続的に同期できるようにするか、ハードウェアの時刻を調整する目的でのみ同期するかを選択できます。

手順 5.2: 日付と時刻を手動で調整する
  1. YaSTのタイムゾーンモジュールで、Other Settings (その他の設定)をクリックして日付と時刻を設定します。

  2. 手動を選択し、日時の値を入力します。

  3. 変更内容を確認します。

手順 5.3: NTPサーバにより日付と時刻を設定する
  1. 日付と時刻を変更するには、Other Settings (その他の設定)をクリックします。

  2. NTPサーバと同期を選択します。

  3. まだ入力されていない場合は、NTPサーバのアドレスを入力します。

    Image
  4. 設定ボタンをクリックすると、[高度なNTP設定]を開くことができます。詳細については、38.1項 「YaSTでのNTPクライアントの設定」を参照してください。

  5. 変更内容を確認します。

6 YaSTによるユーザの管理

インストール時にシステム用のローカルユーザを作成できました。YaSTのユーザとグループの管理モジュールを使用して、ユーザの追加や既存ユーザの編集が可能です。また、ネットワークサーバでユーザを認証するようにシステムを設定できます。

6.1 [ユーザとグループの管理]ダイアログ

ユーザまたはグループを管理するには、YaSTを起動し、セキュリティとユーザ › ユーザとグループの管理の順にクリックします。また、コマンドラインからsudo yast2 users &を実行することにより、ユーザとグループの管理ダイアログを直接起動します。

YaSTのユーザとグループの管理
図 6.1: YaSTのユーザとグループの管理

各ユーザには、システム全体で使用できるユーザID (UID)が割り当てられます。マシンにログインできるユーザ以外にも、内部での使用のみが目的のさまざまな「システムユーザ」が存在します。各ユーザは、1つ以上のグループに割り当てられます。システムユーザと同様に、内部用途のシステムグループも存在します。

メインウィンドウには、表示および変更するために選択するユーザのセット(ローカルユーザ、ネットワークユーザ、システムユーザ)に応じて、いくつかのタブが表示されます。タブでは、次のタスクを実行できます。

ユーザアカウントの管理

ユーザタブから、6.2項 「ユーザアカウントの管理」の説明に従って、ユーザアカウントを作成、変更、削除、または一時的に無効にします。6.3項 「ユーザアカウントの追加オプション」では、パスワードポリシーの強制、暗号化したホームディレクトリの使用、ディスククオータの管理などの高度なオプションについて説明しています。

デフォルト設定の変更

新しいユーザのデフォルト設定タブで定義された設定に応じて、ローカルユーザアカウントが作成されます。6.4項 「ローカルユーザのデフォルト設定の変更」では、デフォルトのグループ割り当て、またはホームディレクトリのデフォルトパスおよびアクセス許可を変更する方法を説明します。

グループへのユーザの割り当て

6.5項 「グループへのユーザの割り当て」では、個別ユーザのグループの割り当てを変更する方法を説明します。

グループを管理する

グループタブから、既存のグループの追加、変更、または削除を行うことができます。この方法については、6.6項 「グループを管理する」を参照してください。

ユーザ認証方法を変更する

コンピュータがNISやLDAPなどのユーザ認証方法を提供するネットワークに接続されている場合は、認証設定タブで、認証方法を選択できます。詳細については、6.7項 「ユーザ認証方法を変更する」を参照してください。

ユーザとグループの管理用に、このダイアログでは同様の機能が提供されます。ダイアログ上部にある適切なタブを選択することにより、ユーザとグループの管理ビューを簡単に切り替えることができます。

[フィルタ]オプションで、変更するユーザまたはグループのセットを定義できます。ユーザまたはグループタブで、フィルタの設定をクリックすると、ユーザまたはグループを表示および編集できます。該当する場合、ローカルユーザLDAPユーザなどの特定のカテゴリに応じて一覧表示されます。フィルタの設定 › フィルタのカスタマイズで、カスタムフィルタをセットアップおよび使用できます。

選択したフィルタに応じて、このダイアログから次のオプションおよび機能がすべて利用できるとは限りません。

6.2 ユーザアカウントの管理

YaSTでは、ユーザアカウントの作成、変更、削除、または一時的な無効化が可能です。熟練したユーザか管理者でない限り、ユーザアカウントを変更しないでください。

注記
注記: 既存ユーザのユーザIDを変更する

ファイル所有権はユーザ名ではなくユーザIDにバインドされます。ユーザIDの変更後、この変更に合わせてユーザのホームディレクトリのファイルが自動的に調整されます。ただし、ユーザは、IDの変更後、ファイルシステム内の他の場所で作成したファイルのファイル所有権を失います(それらのファイルの所有権が手動で変更されない限り)。

次の手順は、デフォルトのユーザアカウントの設定方法を示しています。さらに詳細なオプションについては、6.3項 「ユーザアカウントの追加オプション」を参照してください。

手順 6.1: ユーザアカウントを追加または変更する
  1. YaSTのユーザとグループの管理ダイアログを開き、ユーザタブをクリックします。

  2. フィルタを設定では、管理するユーザセットを定義します。このダイアログには、システムのユーザ、およびユーザが属するグループが一覧にされます。

  3. 既存のユーザに対するオプションを変更するには、エントリを選択し、編集をクリックします。

    新しいユーザアカウントを作成するには、追加をクリックします。

  4. (ログインで使用される)ユーザ名およびパスワードなど、最初のタブで適切なユーザデータを入力します。このデータは、新しいユーザを作成するために十分なものです。OKをクリックすると、システムによって自動的にユーザIDを割り当てられ、他の値はすべてデフォルトに設定されます。

  5. このユーザのメールボックスにシステム通知が配信されるようにする場合は、システムメールの受信を有効にします。これによってrootのメールエイリアスが作成され、このユーザは最初にrootとしてログインしなくてもシステムメールが読めるようになります。

    システムサービスにより送信されたメールは、ローカルメールボックス/var/spool/mail/USERNAMEに保存されます(USERNAMEは選択されたユーザのログイン名)。電子メールを読むには、mailコマンドを使用できます。

  6. ユーザIDまたはユーザのホームディレクトリへのパスなど、さらに詳細な情報を調整するには、詳細タブを使用します。

    既存のユーザのホームディレクトリを再配置する必要がある場合は、新しいホームディレクトリへのパスを入力し、新しい場所に移動により現在のホームディレクトリの内容を移動します。ホームディレクトリを再配置する必要がない場合は、既存データが存在しなくても新しいホームディレクトリが作成されます。

  7. パスワードを定期的に変更することをユーザに強制するか、他のパスワードオプションを設定するには、パスワードの設定に切り替え、オプションを調整します。詳細については、6.3.2項 「パスワードポリシーの強制」を参照してください。

  8. すべてのオプションが希望どおりに設定されたら、OKをクリックします。

  9. OKをクリックして、管理ダイアログを閉じ、変更内容を保存します。新たに追加されたユーザは、作成済みのログイン名とパスワードを使用してシステムにログインできるようになります。

    また、ユーザとグループの管理ダイアログを閉じずにすべての変更を保存するには、熟練者向けオプション › 変更を今すぐ書き込むの順にクリックします。

警告
警告: 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を一致させると便利です。たとえば、ラップトップの新しい(ローカル)ユーザは、ネットワーク環境に統合する際に同じユーザIDを割り当てる必要があります。これにより、ユーザがオフラインで作成するファイルのファイル所有権は、直接ネットワーク上で作成した場合のファイル所有権と同じになります。

手順 6.2: ユーザアカウントを無効化または削除する
  1. YaSTのユーザとグループの管理ダイアログを開き、ユーザタブをクリックします。

  2. ユーザアカウントを削除しないで一時的に無効にするには、リストからユーザを選択し、編集をクリックします。ユーザログインを禁止するを有効にします。ユーザは、アカウントを再び有効にするまで、マシンにログインできません。

  3. ユーザアカウントを削除するには、リストからユーザを選択して、削除をクリックします。ユーザのホームディレクトリを削除するか、またはこのデータを保持するかを選択します。

6.3 ユーザアカウントの追加オプション

SUSE® Linux Enterprise Serverには、デフォルトユーザアカウントの設定のほか、さまざまなオプションも用意されています。たとえば、パスワードポリシーの強制、暗号化したホームディレクトリの使用、ユーザとグループのディスククオータの定義のためのオプションがあります。

6.3.1 自動ログインおよびパスワードレスログイン

GNOMEデスクトップ環境を使用している場合、特定のユーザには「自動ログイン」を設定し、すべてのユーザに「パスワードなしのログイン」を設定できます。自動ログインでは、ユーザがブート時にデスクトップ環境に自動的にログインします。この機能は、一度に1人のユーザについてのみ有効にできます。パスワードなしのログインでは、どのユーザも、ログインマネージャにユーザ名を入力するだけでシステムにログインできます。

警告
警告: セキュリティリスク

複数のユーザがアクセスできるマシンで自動ログインまたはパスワードレスログインを有効にすることはセキュリティ上のリスクを伴います。どのユーザでもシステムおよびデータにアクセスでき、認証の必要もありません。システムに機密情報などの重要なデータを保管している場合は、この機能は使用しないでください。

自動ログインまたはパスワードなしのログインを有効にするには、熟練者向けオプション › ログイン設定の順に選択し、YaSTのユーザとグループの管理でこれらの機能にアクセスします。

6.3.2 パスワードポリシーの強制

複数のユーザが使用するシステムでは、最低限のパスワードセキュリティポリシーを強制することをお勧めします。ユーザに定期的にパスワードを変更させたり、推測しにくいような複雑なパスワードを使用させることができます。ローカルユーザの場合は、次の手順に従います。

手順 6.3: パスワードを設定する
  1. YaSTのユーザとグループの管理ダイアログを開き、ユーザタブを選択します。

  2. ユーザを選択し、編集をクリックします。

  3. パスワードの設定タブに切り替えます。ユーザの最後のパスワード変更がタブに表示されています。

  4. 次回のログインでパスワードを変更するようにユーザに強制するには、次のログイン時にパスワード変更を強制するを有効にします。

  5. パスワードのローテーションを強制するには、同じパスワードを使用できる最長日数および同じパスワードを使用する最短日数を設定します。

  6. 期限切れになる前にパスワードを変更するようにユーザに通知するには、パスワード失効予告日数に日数を設定します。

  7. パスワードが期限切れになった後ユーザがログインできる期間を制限するには、パスワードの有効期限切れログインを使用できる日数の値を変更します。

  8. また、アカウント全体の特定の有効期限を指定できます。有効期限YYYY-MM-DD形式で入力します。これはパスワード関連の設定ではなく、アカウント自体に適用されます。

  9. オプションおよびデフォルト値の詳細については、ヘルプをクリックしてください。

  10. 変更内容を反映するには、OKをクリックします。

6.3.3 クォータの管理

システム容量が通知なく枯渇することのないように、システム管理者はユーザまたはグループに対するクオータを設定できます。クオータは、1つ以上のファイルシステムに対して定義されるもので、これにより使用可能なディスク容量および作成可能なiノード(インデックスノード)の数を制限できます。iノードは、通常のファイル、ディレクトリ、または他のファイルシステムオブジェクトに関する基本的な情報を保存するファイルシステム上のデータ構造です。また、ファイル名とコンテンツを除いて、ファイルシステムオブジェクト(ユーザおよびグループの所有権、読み取り、書き込み、または実行のパーミッションなど)のすべての属性を保存します。

SUSE Linux Enterprise Serverでは、softクォータおよびhardクォータを使用できます。さらに、ユーザまたはグループが特定量まで一時的にクオータを超過できる猶予間隔を定義できます。

ソフトクォータ

限界に近づいたときにユーザに通知する警告レベルを定義します。管理者は、パーティションのデータのクリーンアップと削減を行うようにユーザに促す場合があります。通常、ソフトクォータの限界値は、ハードクォータの限界値よりも低くなります。

ハードクォータ

書き込み要求が拒否される限界を定義します。ハードクォータに達すると、それ以上データを格納することができなくなり、アプリケーションがクラッシュする可能性が高くなります。

Grace period (猶予期間)

ソフトクォータに達してから警告の発行までの時間を定義します。通常、1時間、数時間など小さな値を設定します。

手順 6.4: パーティションのクォータサポートの有効化

特定のユーザおよびグループにクオータを設定するには、YaSTのエキスパートパーティショナで、対応するパーティションのクォータサポートを有効にしておく必要があります。

注記
注記: Btrfsパーティションのクォータ

Btrfsパーティションのクォータの処理は異なります。詳細については、Book “ストレージ管理ガイド”, Chapter 1 “Linuxファイルシステムの概要”, Section 1.2.5 “サブボリュームに対するBtrfsクォータのサポート”を参照してください。

  1. YaSTでシステム › ディスクの分割の順に選択し、はいをクリックして続行します。

  2. エキスパートパーティショナで、クオータを有効にするパーティションを選択して、編集をクリックします。

  3. Fstabオプションをクリックし、Enable Quota Supportを有効にします。quotaパッケージがまだインストールされていない場合は、はいのクリックで各メッセージを確認することにより、クオータパッケージがインストールされます。

  4. 変更を確認し、エキスパートパーティショナを終了します。

  5. 次のコマンドを入力して、quotaonサービスが実行されていることを確認してください。

    > sudo systemctl status quotaon.service

    サービスは、activeとしてマークされている必要があります。そうでない場合は、systemctl start quotaon.serviceコマンドを使用して開始する必要があります。

手順 6.5: ユーザまたはグループのクォータを設定する

これで、特定のユーザまたはグループに対するソフトクオータまたはハードクオータを定義し、猶予間隔を指定できます。

  1. YaSTのユーザとグループの管理で、クオータの設定対象とするユーザまたはグループを選択し、編集をクリックします。

  2. プラグインタブで、ユーザクォータの管理のエントリを選択してから、起動をクリックしてクォータの設定ダイアログを開きます。

  3. ファイルシステムから、クオータを適用するパーティションを選択します。

    Image
  4. サイズ制限では、ディスクスペースの容量を制限します。ユーザまたはグループがこのパーティションで持つことができる1KBブロックの数を入力します。Soft Limitおよびハード制限の値を指定します。

  5. さらに、ユーザまたはグループがこのパーティションで持つことができるiノードの数を制限できます。iノード制限で、Soft Limitおよびハード制限を入力します。

  6. サイズまたはiノードに対して指定されたソフト制限をユーザまたはグループが既に超過している場合にのみ猶予間隔を定義できます。このソフト制限を超過していない場合、時間に関連するテキストボックスは有効になりません。ユーザまたはグループが上記の制限セットを超過できる期間を指定します。

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

  8. OKをクリックして、管理ダイアログを閉じ、変更内容を保存します。

    また、ユーザとグループの管理ダイアログを閉じずにすべての変更を保存するには、熟練者向けオプション › 変更を今すぐ書き込むの順にクリックします。

SUSE Linux Enterprise Serverには、repquotawarnquotaなどのコマンドラインツールも付属しています。システム管理者はこれらのツールを使用してディスク使用量を制限したり、所定のクオータを超過しているユーザに電子メール通知を送信したりすることができます。管理者はまた、quota_nldを使用することにより、超過したクオータに関するカーネルメッセージをD-BUSに転送できます。詳細については、repquotawarnquota、およびquota_nldのマニュアルページを参照してください。

6.4 ローカルユーザのデフォルト設定の変更

新しくローカルユーザを作成する際には、いくつかのデフォルト設定がYaSTで使用されます。これらには、たとえば、ユーザが属するグループ、ユーザのホームディレクトリのアクセスパーミッションなどが含まれます。これらのデフォルト設定値は、必要に応じて変更することができます。

  1. YaSTのユーザとグループの管理ダイアログを開き、Defaults for New Users (新規ユーザのデフォルト)タブを選択します。

  2. 新しいユーザが自動的に属するグループを変更するには、既定のグループから別のグループを選択します。

  3. 新しいユーザのホームディレクトリのデフォルトパスとして/home/USERNAMEを使用しない場合は、ホームディレクトリのパスプレフィクスを変更します。

  4. 新たに作成したホームディレクトリのデフォルトのパーミッションモードを変更するには、ホームディレクトリ用のUmaskのumask値を調整します。umaskの詳細については、Book “Security and Hardening Guide”, Chapter 19 “Access control lists in Linux”およびumaskのマニュアルページを参照してください。

  5. それぞれのオプションの詳細については、ヘルプをクリックしてください。

  6. 変更内容を反映するには、OKをクリックします。

6.5 グループへのユーザの割り当て

ユーザとグループの管理ダイアログの新しいユーザのデフォルト設定タブからアクセス可能なデフォルト設定に従って、さまざまなグループにローカルユーザが割り当てられます。次に、個別ユーザのグループ割り当てを変更する方法を説明します。新しいユーザに対するデフォルトのグループの割り当てを変更する必要がある場合については、6.4項 「ローカルユーザのデフォルト設定の変更」を参照してください。

手順 6.6: ユーザのグループ割り当てを変更する
  1. YaSTのユーザとグループの管理ダイアログを開き、ユーザタブをクリックします。ユーザ、およびユーザが属するグループが一覧にされます。

  2. 編集をクリックし、詳細タブに切り替えます。

  3. ユーザが属するプライマリグループを変更するには、既定のグループをクリックし、リストからグループを選択します。

  4. 追加のセカンダリグループをユーザに割り当てるには、追加のグループのリストで対応するチェックボックスをオンにします。

  5. OKをクリックして、変更を適用します。

  6. OKをクリックして、管理ダイアログを閉じ、変更内容を保存します。

    また、ユーザとグループの管理ダイアログを閉じずにすべての変更を保存するには、熟練者向けオプション › 変更を今すぐ書き込むの順にクリックします。

6.6 グループを管理する

YaSTでは、グループの追加、変更、または削除も容易に実行できます。

手順 6.7: グループを作成および変更する
  1. YaSTのユーザとグループの管理ダイアログを開き、グループタブをクリックします。

  2. フィルタを設定では、管理するグループセットを定義します。ダイアログに、システム内のグループが一覧にされます。

  3. 新しいグループを追加するには、追加をクリックします。

  4. 既存のグループを変更するには、グループを選択して編集をクリックします。

  5. 次のダイアログで、データを入力または変更します。右のリストでは、グループのメンバーになることができる利用可能なすべてのユーザおよびシステムユーザの概要が表示されます。

    Image
  6. 新しいグループに既存のユーザを追加するには、選択可能なグループのメンバーのリストで、該当するボックスをオンにして選択します。既存のユーザをグループから削除するには、このボックスをオフにします。

  7. OKをクリックして、変更を適用します。

  8. OKをクリックして、管理ダイアログを閉じ、変更内容を保存します。

    また、ユーザとグループの管理ダイアログを閉じずにすべての変更を保存するには、熟練者向けオプション › 変更を今すぐ書き込むの順にクリックします。

グループを削除するには、すべてのグループメンバーを削除する必要があります。グループを削除するには、リストからグループを選択し、削除をクリックします。OKをクリックして、管理ダイアログを閉じ、変更内容を保存します。また、ユーザとグループの管理ダイアログを閉じずにすべての変更を保存するには、熟練者向けオプション › 変更を今すぐ書き込むの順にクリックします。

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”を参照してください。

認証方法を変更するには、以下の手順に従ってください。

  1. YaSTのユーザとグループの管理ダイアログを開きます。

  2. Authentication Settingsタブをクリックすると、利用可能な認証方法と現在の設定の概要が表示されます。

  3. 認証方法を変更するには、設定をクリックし、変更する認証方法を選択します。これにより、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”

  4. この設定を確認した後、ユーザとグループの管理の概要に戻ります。

  5. OKをクリックして、管理ダイアログを閉じます。

6.8 デフォルトのシステムユーザ

デフォルトでは、SUSE Linux Enterprise Serverに削除できないユーザ名が作成されます。これらのユーザは通常、Linux Standard Baseで定義されます。次のリストに、一般的なユーザ名とその目的を示します。

デフォルトでインストールされる一般的なユーザ名
bin, daemon

レガシアプリケーションとの互換性を維持するために用意されているレガシユーザ。新しいアプリケーションではこのユーザ名を使用しないでください。

gdm

グラフィカルログインを提供したり、ローカル表示とリモート表示を管理したりするために、GNOMEディスプレイマネージャ(GDM)によって使用されています。

lp

CUPS (Common Unix Printing System)用にプリンタデーモンによって使用されています。

mail

sendmailpostfixなどの、ユーザ用に予約されたメーラープログラム。

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 オンライン更新ダイアログ

オンライン更新ダイアログを開くには、YaSTを起動し、ソフトウェア › オンライン更新の順に選択します。コマンドラインでyast2 online_updateを実行して、このモジュールを開始することもできます。

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

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

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

必要な修正(デフォルトビュー)

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

必要のない修正

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

すべてのパッチ

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

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

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

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

7.2 パッチのインストール

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

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

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

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

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

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

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

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

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

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

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

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

7.3 撤回されたパッチの表示

バグが発生するリスクを最小限に抑えるために、保守アップデートは慎重にテストされます。パッチにバグが含まれていることが判明した場合、パッチは自動的に撤回されます。バグのあるパッチを元に戻すために(バージョン番号が高い)新しいアップデートが発行され、再度インストールされないようにブロックされます。撤回されたパッチおよびその履歴はパッケージの分類タブで確認できます。

撤回されたパッチと履歴の表示
図 7.2: 撤回されたパッチと履歴の表示

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

YaSTを使用して、毎日、毎週、または毎月のスケジュールで自動アップデートを設定できます。yast2-online-update-configurationパッケージをインストールします。

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

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

YaST ソフトウェアモジュールのパッチタブを使用して、バグレポートやCVE掲示への参照を含む、使用可能なパッチ、インストール済みのパッチを確認できます。

手順 7.2: 自動オンラインアップデートの設定
  1. インストール後、YaSTを起動し、ソフトウェア › オンライン更新の順に選択します。環境設定 › オンライン更新の順に選択します。yast2-online-update-configurationがインストールされていない場合、インストールするように求められます。

    YaSTオンライン更新設定
    図 7.3: YaSTオンライン更新設定

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

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

  3. パッチで重要なサービスを再起動する際などに、管理者の注意が必要な場合があります。たとえば、すべてのコンテナの再起動が必要なDocker Open Source Engineのアップデートの場合などです。これらのパッチをインストールする前に、ユーザはその結果について知らされ、パッチのインストールの確認を求められます。このようなパッチは対話操作が必要な修正と呼ばれます。

    パッチを自動的にインストールする場合は、対話操作が必要な修正のインストールを了承しているとみなされます。インストールする前にこれらのパッチを確認する場合は、対話操作が必要な修正を飛ばすを選択します。この場合、自動的なパッチ適用中に対話操作が必要な修正は飛ばされます。手動オンラインアップデートを定期的に行って、対話操作が必要な修正がインストールを待機しているかどうかを確認します。

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

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

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

  7. セキュリティや推奨など、カテゴリ別にパッチをフィルタリングするには、分類によるフィルタを有効にしてリストから適切なカテゴリを追加します。選択したカテゴリのパッチのみがインストールされます。自動的にセキュリティアップデートのみを有効にして、その他すべてを手動で確認することをお勧めします。パッチの適用は通常は信頼できますが、セキュリティ以外のパッチをテストし、問題がある場合はロールバックすることもできます。

    • パッケージマネージャとYaSTでは、パッケージ管理および、YaST機能とモジュール用のパッチを提供します。

    • セキュリティパッチでは、重要なアップデートとバグ修正を提供します。

    • 推奨パッチは、オプションのバグ修正と拡張です。

    • オプションは新しいパッケージです。

    • その他はその他に相当します。

    • ドキュメントは使用されていません。

  8. OKをクリックして設定を確認します。

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

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ソフトウェアマネージャの使用

ソフトウェア › ソフトウェアマネージャの順に選択して、YaSTコントロールセンターからソフトウェアマネージャを起動します。

YaST software manager screen

8.3.2 パッケージまたはパターンのインストールと削除

一定のパッケージは、共有ライブラリなどの他のパッケージに依存しています。いくつかのパッケージは、システム上で他のパッケージと共存できません。これらの依存関係や競合の解決が可能な場合は、YaSTによって自動的に解決されます。選択によって、自動的に解決できない依存関係の競合が発生した場合は、8.3.4項 「パッケージの依存関係」の説明に従って、競合を手動で解決する必要があります。

注記
注記: パッケージの削除

パッケージを削除する場合、デフォルトでは、選択したパッケージのみが削除されます。指定したパッケージの削除に伴って不要になる他のすべてのパッケージもYaSTで削除できるようにするには、メインメニューでオプション › パッケージの削除時にクリーンアップするの順に選択します。

  1. パッケージを検索します(8.3.1項 「ソフトウェアの検索」参照)。

  2. 検出されたパッケージは、右側のペインに一覧されます。パッケージをインストールまたは削除するには、パッケージを右クリックして、インストールまたは削除を選択します。該当するオプションがない場合は、パッケージ名の先頭に表示された記号で示されているパッケージステータスを確認し、ShiftF1を押してヘルプを表示します。

    ヒント
    ヒント: 一覧表示されたすべてのパッケージにアクションを適用する方法

    右ペインに一覧表示されたすべてのパッケージにアクションを適用するには、メインメニューに移動し、パッケージ › このリスト内のすべての順に選択してアクションを選択します。

  3. パターンをインストールするには、パターン名を右クリックして、インストールを選択します。

  4. パターンを削除することはできません。代わりに、削除したいパターンのパッケージを選択し、それらを削除用にマークします。

  5. さらにパッケージを選択するには、上記の手順を繰り返します。

  6. 変更を適用する前に、表示 › インストールの概要 の順にクリックすると、変更内容をレビューまたは変更できます。デフォルトでは、ステータスを変更するすべてのパッケージが一覧にされます。

  7. パッケージの状態を元に戻すには、パッケージを右クリックし、次のエントリの1つを選択します。つまり、パッケージの削除または更新が予定されている場合は保持を選択し、パッケージのインストールが予定されている場合はインストールしないを選択します。すべての変更を破棄し、ソフトウェアマネージャを終了するには、キャンセル中止をクリックします。

  8. 完了したら、受諾をクリックして、変更を適用します。

  9. YaSTが追加の依存関係を検出すると、インストール、更新または削除する関連パッケージのリストが表示されます。続行をクリックして、それらを受け入れます。

    選択されているすべてのパッケージのインストール、更新、または削除が完了すると、YaSTソフトウェアマネージャが自動的に終了します。

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

現時点では、YaSTソフトウェアマネージャを使用してソースパッケージをインストールすることはできません。このためには、コマンドラインツールzypperを使用します。詳細については、9.1.3.5項 「ソースパッケージのインストールまたはダウンロード」を参照してください。

8.3.3 パッケージの更新

個々のパッケージを更新する代わりに、インストールされているすべてのパッケージまたは特定リポジトリのすべてのパッケージを更新することもできます。パッケージの大量更新時には、一般に、次の側面を考慮します:

  • パッケージを提供するリポジトリの優先順位、

  • パッケージのアーキテクチャ(たとえば、AMD64/Intel 64)、

  • パッケージのバージョン番号、

  • パッケージのベンダ。

更新の候補を選択する上でどの側面が最も重要であるかは、選択する個々の更新オプションに依存します。

  1. インストール済みのすべてのパッケージを最新バージョンに更新するには、メインメニューから、パッケージ › すべてのパッケージ › 新しいバージョンがあれば更新するの順に選択します。

    一定のポリシーを使用して、使用できる更新候補がないかどうか、すべてのリポジトリがチェックされます。このポリシーでは、まずYaSTによる検索範囲を、インストール済みのパッケージと同じアーキテクチャおよびベンダのパッケージに限定します。検索でパッケージが見つかると、以下のプロセスに従って、見つかったパッケージから最良の更新候補が選択されます。ただし、同じベンダの同類のパッケージが見つからない場合は、同じアーキテクチャのすべてのパッケージに検索が拡大されます。それでも同類のパッケージが見つからない場合は、すべてのパッケージが対象となり、次の基準に従って、最良の更新候補が選択されます。

    1. リポジトリの優先度: 最高の優先度をもつリポジトリからのパッケージを優先します。

    2. この基準で複数のパッケージが選択された場合は、アーキテクチャが最良であるパッケージが選択されます。(最良のアーキテクチャとは、インストール済みパッケージのアーキテクチャと同一のアーキテクチャです)。

    選択したパッケージのバージョンがインストール済みパッケージのバージョン番号より高い場合は、インストール済みパッケージが選択した更新候補で更新および置換されます。

    このオプションでは、インストール済みパッケージのアーキテクチャとベンダを変更しないようにしていますが、特定の条件下では、それらは許容されます。

    注記
    注記: 強制的に更新する

    代わりに、パッケージ › すべてのパッケージ › 強制的に更新するの順に選択すると、適用される基準は同じですが、検出された候補パッケージは無条件でインストールされます。したがって、このオプションを選択すると、特定のパッケージがダウングレードする場合があります。

  2. 大量更新用パッケージを特定のリポジトリからのパッケージにするには:

    1. 8.3.1項 「ソフトウェアの検索」の説明に従って、更新に使用するリポジトリを選択します。

    2. ウィンドウの右側で、システムパッケージをこのリポジトリ内のバージョンに切り替えるをクリックします。この設定は、パッケージを入れ替えるときにパッケージベンダを変更することをYaSTに対して明示的に許可します。

      了解で続行すると、すべてのインストール済みパッケージが、このリポジトリ(使用可能な場合)からのパッケージで置換されます。これによって、ベンダとアーキテクチャが変更され、特定のパッケージがダウングレードすることがあります。

    3. これを回避するには、システムパッケージをこのリポジトリ内のバージョンに切り替えることをキャンセルするをクリックします。このキャンセルは、了解ボタンをクリックする前にしかできません。

  3. 変更を適用する前に、表示 › インストールの概要 の順にクリックすると、変更内容をレビューまたは変更できます。デフォルトでは、ステータスを変更するすべてのパッケージが一覧されます。

  4. すべてのオプションを好みどおりに設定したら、受諾で変更内容を確認して大量更新を開始します。

8.3.4 パッケージの依存関係

ほとんどのパッケージは、他のパッケージに依存しています。たとえば、共有ライブラリを使用するパッケージは、そのライブラリを提供するパッケージに依存します。共存できない特定のパッケージは、競合を引き起こします。たとえば、メール転送エージェント(sendmailまたはpostfix)は、1つしかインストールできません。ソフトウェアのインストールまたは削除時には、ソフトウェアマネージャが未解決のままの依存関係や競合が残っていないことを確認してシステムの整合性を確保します。

依存関係や競合の解決に1つのソリューションしかない場合は、その依存関係や競合は自動的に解決されます。複数のソリューションがあると必ず、手動で解決する必要のある競合が発生します。競合の解決にベンダやアーキテクチャの変更が必要な場合も、手動で解決する必要があります。受諾をクリックして、ソフトウェアマネージャで変更を適用すると、自動リゾルバでトリガされたすべてのアクションの概要が表示され、確認を要求されます。

依存関係は、デフォルトで、自動的にチェックされます。パッケージのステータスを変更するたびに(たとえば、パッケージをインストールまたは削除用にマークする)、チェックが実行されます。これは、一般的には便利ですが、依存関係の競合を手動で解決する際にはわずらわしくなることがあります。この機能を無効にするには、メインメニューに移動して依存関係 › 自動確認の選択を無効にします。依存関係の確認は、依存関係 › 今すぐ確認の順に選択して手動で実行します。整合性の確認は、受諾をクリックして選択を確定すると、必ず実行されます。

パッケージの依存関係をレビューするには、パッケージを右クリックし、解決器の情報表示を選択します。依存関係を示すマップが開きます。すでにインストールされているパッケージは、緑の枠内に表示されます。

注記
注記: パッケージ競合の手動解決

競合の処理に精通していない限り、パッケージの競合を処理する場合は、YaSTによる指示に従うようにします。そうしないと、競合を解決できないことがあります。行った変更はいずれも他の競合をトリガする可能性があり、結局、競合の数は確実に増加することに留意してください。このようになった場合は、キャンセルでソフトウェアマネージャをキャンセルし、すべての変更を中止で破棄して、やり直します。

ソフトウェアマネージャの競合管理
図 8.1: ソフトウェアマネージャの競合管理

8.3.5 推奨パッケージの取り扱い

パッケージには、プログラムの実行に必須の、強い依存関係(特定のライブラリなど)だけでなく、新しい機能や変換の追加など、弱い依存関係もあります。このような弱い依存関係を推奨パッケージと呼びます。

新しいパッケージをインストールする場合、推奨されるパッケージはデフォルトでインストールされます。既存のパッケージを更新する場合、不足している推奨事項は自動的にインストールされません。これを変更するには、/etc/sysconfig/yast2PKGMGR_RECOMMENDED="yes"を設定します。インストール済みのパッケージに関する推奨パッケージが欠落している場合、それらすべてをインストールするには、YaST › Software Managerを開始し、エクストラ › Install All Matching Recommended Packages(該当する推奨パッケージをすべてインストールする)を選択します。

新規パッケージのインストール時の推奨パッケージのインストールを無効にするには、YaST Software Managerで、依存関係 › Install Recommended Packages(推奨パッケージのインストール)を無効にします。Zypperコマンドラインツールを使用してパッケージをインストールしている場合、--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つまたは複数のソフトウェアを提供できるRepository Index Service (RIS) です。この種のサービスは管理者またはベンダから動的に変更できます。

各リポジトリは、リポジトリコンテンツ(パッケージ名、バージョンなど)を説明したファイルを提供します。YaSTは、これらのリポジトリ説明ファイルをローカルキャッシュにダウンロードします。ソフトウェアリポジトリには、その整合性確認のため、リポジトリメンテナのGPGキーで署名することができます。新しいリポジトリを追加するたびに、YaSTでリポジトリのキーをインポートできます。

警告
警告: 外部ソフトウェアソースの信用

外部ソフトウェアのリポジトリをリポジトリリストに追加する場合は、その前に、リポジトリを信頼できるかどうか確認してください。SUSEは、サードパーティのソフトウェアリポジトリからインストールされたソフトウェアによって発生するどのような問題についても、責任を負いません。

8.4.1 ソフトウェアリポジトリの追加

DVD/CD、USBフラッシュドライブ、ローカルディレクトリ、ISOイメージ、またはネットワークソースからリポジトリを追加できます。

YaSTの設定されたソフトウェアリポジトリダイアログでリポジトリを追加するには、次の手順に従います。

  1. Add (追加)をクリックします。

  2. ダイアログに表示されているオプションのいずれかを選択します。

    ソフトウェアリポジトリの追加
    図 8.2: ソフトウェアリポジトリの追加
    • ネットワークをスキャンして、SLP経由でサービスをアナウンスしているインストールサーバを検索するには、Scan Using SLP (SLPを使用してスキャン)を選択して次へをクリックします。

    • リムーバブルメディアからリポジトリを追加するには、該当するオプションを選択して、メディアを挿入するか、またはUSBデバイスをコンピュータに接続します。次へをクリックして、インストールを開始します。

    • 大半のリポジトリでは、該当のオプションを選択して次へをクリックすると、メディアへのパス(またはURL)を指定するように求められます。Repository Name (リポジトリ名)の指定は任意です。何も指定しない場合は、製品名またはURLがリポジトリ名として使用されます。

    リポジトリの説明をダウンロードはデフォルトで有効になっています。このオプションを有効にしていない場合は、後で必要になったときにYaSTによって自動的にダウンロードされます。

  3. 追加したリポジトリによっては、リポジトリのGPGキーのインポートを求められたり、ライセンスへの合意を求められたりします。

    確認すると、メタデータがダウンロードされ、解析されます。これにより、Configured Repositories (設定されたリポジトリ)のリストにリポジトリが追加されます。

  4. 必要に応じて、8.4.2項 「リポジトリプロパティの管理」の説明に従い、リポジトリのプロパティを調整します。

  5. OKをクリックして変更内容を確認し、設定ダイアログを閉じます。

  6. リポジトリを正常に追加できると、ソフトウェアマネージャが起動し、そのリポジトリからパッケージをインストールできるようになります。詳細については、第8章 「ソフトウェアをインストールまたは削除するを参照してください。

8.4.2 リポジトリプロパティの管理

ソフトウェアリポジトリ設定されたソフトウェアリポジトリの概要では、次のリポジトリプロパティを変更できます。

Status

リポジトリのステータスは、有効または無効のどちらかです。有効なリポジトリからのパッケージだけをインストールできます。一時的にリポジトリを無効にするにはEnable (有効化)を無効にします。リポジトリ名をダブルクリックして、その状態を切り替えることもできます。リポジトリを完全に削除するには、削除をクリックします。

更新

リポジトリを更新すると、そのコンテンツの説明(パッケージ名、バージョンなど)は、YaSTで使用されるローカルキャッシュにダウンロードされます。これは、CDやDVDなどの静的リポジトリでは1回で十分ですが、内容が頻繁に変更されるリポジトリでは頻繁な更新が必要です。リポジトリのキャッシュを最新の状態に保つ最も簡単な方法は、自動的に更新するの選択です。手動更新を行うには、更新をクリックして、オプションの1つを選択します。

ダウンロードしたパッケージを維持します

インストールの前に、リモートリポジトリからのパッケージをダウンロードします。これらのパッケージは、デフォルトでは、インストールが正常に完了すると削除されます。ダウンロードしたパッケージを維持しますを有効にすると、ダウンロードしたパッケージが削除されません。ダウンロードの場所は、/etc/zypp/zypp.confに設定されます。これは、デフォルトでは、/var/cache/zypp/packagesです。

優先度

リポジトリの優先度は、1200の値です。ここで、1は最高の優先度、200は最低の優先度です。YaSTで追加した新しいリポジトリの優先度は、デフォルトで99です。特定のリポジトリに関して優先度値が何であってもよい場合は、値を0に設定しても、そのリポジトリにデフォルト優先度(99)を適用できます。パッケージが2つ以上のリポジトリにある場合は、優先度の最も高いリポジトリが優先して使用されます。これは、ローカルリポジトリ(たとえば、DVD)に高い優先度を与えることによって、インターネットから不必要にパッケージをダウンロードしないようにする場合に有用です。

重要
重要: 優先度とバージョンの比較

優先度の最も高いリポジトリが、常に、優先されます。したがって、更新リポジトリには必ず最高の優先度が割り当てられるようにします。そのようにしないと、次のオンラインアップデートまで更新されない古いバージョンがインストールされる可能性があります。

名前とURL

リポジトリ名またはリポジトリのURLを変更するには、それをシングルクリックでリストから選択し、次に、編集をクリックします。

8.4.3 リポジトリキーの管理

ソフトウェアリポジトリには、その整合性確認のため、リポジトリメンテナのGPGキーで署名することができます。新しいリポジトリを追加するたびに、そのキーをYaSTでインポートできます。そのキーを他の任意のGPGキーのように検証し、キーが変更されていないことを確認してください。キーの変更を見つけた場合は、リポジトリに何らかの問題がある可能性があります。キーの変更の原因を突き止めるまで、リポジトリをインストールソースとして無効にしてください。

インポートしたすべてのキーを管理するには、設定されたソフトウェアリポジトリダイアログでGPG鍵をクリックします。マウスでエントリを選択して、ウィンドウ下部にキーのプロパティを表示します。追加編集、または削除をクリックすることで、該当する操作をキーに対して実行します。

8.5 GNOMEパッケージアップデータ

SUSEはお買い上げの製品に対し、継続的にソフトウェアセキュリティパッチおよびアップデートを提供します。デスクトップで利用可能なツールを使用して、またはYaSTオンラインアップデートモジュールを実行することにより、インストールできます。このセクションでは、パッケージアップデータを使用してGNOMEデスクトップからシステムをアップデートする方法について説明します。

YaSTオンラインアップデートモジュールとは異なり、GNOMEパッケージアップデータは、アップデートリポジトリからパッチのインストールを提供するだけでなく、すでにインストールされているパッケージの新しいバージョンも提供します(パッチ修正のセキュリティの問題または誤動作、機能およびバージョン番号は通常、変わりません。新しいバージョンのパッケージによりバージョン番号が増え、機能が追加されるか主な変更が導入されます。)

新しいパッチまたはパッケージのアップデートが利用可能な場合は常に、GNOMEでは、通知領域またはロック画面で通知が表示されます。

GNOMEのデスクトップに表示されたアップデート通知
図 8.3: GNOMEのデスクトップに表示されたアップデート通知

パッケージアップデータの通知設定を行うには、GNOMEで設定を起動し、通知 › パッケージアップデータの順に選択します。

手順 8.2: GNOMEパッケージアップデータを使用したパッチおよびアップデートのインストール
  1. パッチおよびアップデートをインストールするには、通知メッセージをクリックします。これにより、GNOMEでパッケージアップデータが開きます。または、package Uと入力し、パッケージアップデータを選択して、アクティビティからアップデータを開きます。

    Image
  2. アップデートは次の4つのカテゴリに分類されます。

    セキュリティアップデート(パッチ)

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

    推奨されるアップデート(パッチ)

    コンピュータに損害を与える可能性のある問題を修復します。これらのアップデートをインストールすることを強くお勧めします。

    オプションのアップデート(パッチ)

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

    その他のアップデート

    インストールされるパッケージの新しいバージョン。

    すべての使用可能なアップデートはインストール用に事前に選択されています。すべてのアップデートをインストールしない場合は、まず、不要なアップデートを選択解除します。すべてのセキュリティアップデートおよび推奨されるアップデートは必ずインストールすることを強くお勧めします。

    アップデートに関する詳細情報を取得するには、そのタイトルと詳細をクリックします。情報はパッケージリストの下のボックスに表示されます。

  3. 更新をインストールするをクリックしてインストールを開始します。

  4. 一部のアップデートでは、マシンを再起動するか、ログアウトする必要がある場合があります。インストール後に表示される、手順に関するメッセージを確認します。

8.6 GNOMEソフトウェアを使用したパッケージの更新

GNOMEパッケージアップデータに加えて、GNOMEでは次の機能を持つGNOMEソフトウェアを提供します。

  • PackageKitを介してRPMとして配布されたソフトウェアをインストール、更新、削除する

  • Flatpakとして配布されたソフトウェアをインストール、更新、削除する

  • GNOMEシェル拡張機能(https://extensions.gnome.org)をインストール、更新、削除する

  • 「Linux Vendor Firmware Service」(LVFS、https://fwupd.org)を使用してハードウェアデバイスのファームウェアを更新する

GNOMEソフトウェアでは、ソフトウェアのスクリーンショット、レーティング、およびレビューも提供しています。

GNOMEソフトウェア—更新ビュー
図 8.4: GNOMEソフトウェア更新ビュー

GNOMEソフトウェアには、SUSE Linux Enterprise Serverで提供される他のツールと次のような違いがあります。

  • YaSTまたはZypperとは異なり、RPMとしてパッケージされたソフトウェアをインストールする場合、GNOMEソフトウェアはAppStreamメタデータを提供するソフトウェアに制限されます。これには、ほとんどのデスクトップアプリケーションが含まれます。

  • GNOMEパッケージアップデータは実行中のシステム内のパッケージをアップデートし(それぞれのアプリケーションを再起動する必要があります)、GNOMEソフトウェアはアップデートをダウンロードし、再起動後に適用します。

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

この章では、ソフトウェア管理の2つのコマンドラインツールとして、ZypperとRPMについて説明します。このコンテキストで使用される用語(repositorypatchupdateなど)の定義については、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リポジトリからmcvimパッケージをインストールします。

> 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
警告
警告: 必須システムパッケージは削除しないでください

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

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オプションを使用することで上書きされます。このオプションは、次のように、実際のコマンド(installremovepatch)の前に指定する必要があります。

> 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-2713CVE-のセキュリティパッチをインストールするには、次のコマンドを実行します。

> 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

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

例 9.1: Zypper - 既知のリポジトリのリスト
> 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には、次のいずれかを指定できます: httphttpsftpcddvddirfilecifssmbnfshdiso)

リポジトリエイリアスの名前を変更するには、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.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_NAMErpm -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)がソフトウェアパッケージを管理するのに使用されます。その主なコマンドはrpmrpmbuildです。ユーザ、システム管理者、およびパッケージの作成者は、強力な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クエリオプション」を参照してください。

表 9.1: 基本的なRPMクエリオプション

-i

パッケージ情報

-l

ファイルリスト

-f FILE

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

-s

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

-d

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

-c

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

--dump

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

--provides

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

--requires-R

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

--scripts

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

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

例 9.2: rpm -q -i wget
Name        : wget
Version     : 1.14
Release     : 17.1
Architecture: x86_64
Install Date: Mon 30 Jan 2017 14:01:29 CET
Group       : Productivity/Networking/Web/Utilities
Size        : 2046483
License     : GPL-3.0+
Signature   : RSA/SHA256, Thu 08 Dec 2016 07:48:44 CET, Key ID 70af9e8139db7c82
Source RPM  : wget-1.14-17.1.src.rpm
Build Date  : Thu 08 Dec 2016 07:48:34 CET
Build Host  : sheep09
Relocations : (not relocatable)
Packager    : https://www.suse.com/
Vendor      : SUSE LLC <https://www.suse.com/>
URL         : http://www.gnu.org/software/wget/
Summary     : A Tool for Mirroring FTP and HTTP Servers
Description :
Wget enables you to retrieve WWW documents or FTP files from a server.
This can be done in script files or via the command line.
Distribution: SUSE Linux Enterprise 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「パッケージを検索するスクリプト」に示すようなシェルスクリプトを使用します。実行するときに、ファイル名の一部を、パラメータとして示されるスクリプトに渡します。

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

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

表 9.2: RPM確認オプション

5

MD5チェックサム

S

ファイルサイズ

L

シンボリックリンク

T

変更時間

D

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

U

所有者

G

グループ

M

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

設定ファイルの場合は、文字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/packagesrpmrpmbuildでは、以下のディレクトリが使用できる必要があります(/etc/rpmrcのようなファイルでカスタム設定を指定している場合を除く)。

SOURCES

元のソース(.tar.bz2または.tar.gzファイルなど)およびディストリビューション固有の調整(ほとんど.diffまたは.patchファイル)用です。

SPECS

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

BUILD

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

RPMS

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

SRPMS

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

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

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

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

次の例は、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を使用して、次のタスクを実行できます。

10.1 デフォルト設定

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

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

インストール中に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/yast2USE_SNAPPERyesに設定します。

無効化.  /etc/sysconfig/yast2USE_SNAPPERnoに設定します。

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

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>

1

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

2

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

3

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

4

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

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

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

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

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
ヒント
ヒント: コピーオンライト(cow)の無効化

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

/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)を使用してファイルシステムを指定する必要があります。ext3etx4または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のモジュールまたはsnappersnapperコマンドラインツールを使用して、事前スナップショットからファイルを復元し、YaST/Zypperによる変更を元に戻すことができます。また、2つのスナップショットを比較して、どのファイルが変更されているか調べることができます。2つのバージョンのファイルの違いを表示することもできます(diff)。

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

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

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

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

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

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

    Image

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

手順 10.2: snapperコマンドによる変更の取り消し
  1. 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)
  2. スナップショットのペア間で変更されたファイルのリストを取得するには、以下を実行します。snapper status PREPOSTをクリックします。内容が変更されたファイルにはcのマーク、追加されたファイルには+のマーク、削除されたファイルには-のマークが付いています。

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

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

    > 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ディレクトリから環境設定ファイルなど単一のファイルを復元できますが、スナップショットからファイルの完全なリストを復元することはできません。

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

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

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

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

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

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

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

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

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

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

    > sudo snapper -c CONFIG status SNAPSHOT_ID..0

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

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

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

    <FILE NAME>を指定しない場合は、すべてのファイルの差分が表示されます。

  4. 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項 「スナップショットから除外されるディレクトリ」を参照)は、別のデバイス上に存在していても構いません。

  • システムは、インストールされたブートローダを介してブート可能である必要があります。

  • サブボリューム/の内容のみがロールバックされます。他のサブボリュームを含めることはできません。

ブート可能なスナップショットからのロールバックを実行するには、次の手順に従います。

  1. システムをブートします。ブートメニューから、Bootable snapshots(ブート可能なスナップショット)を選択して、ブートするスナップショットを選択します。スナップショットのリストが日別に一覧にされます。最新のスナップショットが先頭に表示されます。

  2. システムにログインします。すべてが予期したとおりに動作しているかどうかを注意深く確認します。スナップショットの一部であるディレクトリに書き込むことはできないので注意してください。他のディレクトリに書き込むデータは、次に行う操作にかかわらず、失われることは「ありません」

  3. ロールバックを実行するかどうかに応じて、次のステップを選択します。

    1. システムが、ロールバックを実行したくない状態になっている場合は、再起動して現在のシステム状態にブートします。その後、別のスナップショットを選択するか、レスキューシステムを開始することができます。

    2. ロールバックを実行するには、次のコマンドを実行し

      > 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 スナップショットブートエントリのアクセスと識別

スナップショットからブートするには、マシンを再起動して、Start Bootloader from a read-only snapshot(読み取り専用スナップショットからBootloaderを始動)を選択します。ブート可能なすべてのスナップショットをリストした画面が開きます。最も新しいスナップショットが先頭に表示され、最も古いものは最後に表示されます。キーおよびキーを使用して移動し、Enterキーを押して、選択したスナップショットを有効にします。ブートメニューからスナップショットを有効にしても、マシンは即座に再起動されません。選択したスナップショットのブートローダが開くだけです。

ブートローダ: スナップショット
図 10.1: ブートローダ: スナップショット
警告
警告: 現在、UEFIを使用してBtrfsスナップショットからXenをブートすると失敗します

詳細については、https://www.suse.com/support/kb/doc/?id=000020602を参照してください。

ブートローダの各スナップショットエントリの名前は、命名規則に従っているため、容易に識別できます。

[*]1OS2 (KERNEL3,DATE4TTIME5,DESCRIPTION6)

1

スナップショットにimportantとマークが付いている場合、そのエントリには*が付きます。

2

オペレーティングシステムラベル。

4

日付フォーマット(YYYY-MM-DD)。

5

時刻フォーマット(HH:MM)。

6

このフィールドには、スナップショットの説明が入ります。手動で作成されたスナップショットの場合、この説明は--descriptionオプションで作成された文字列、またはカスタム文字列です(ヒント: ブートローダスナップショットエントリのカスタム説明の設定を参照)。自動で作成されたスナップショットの場合、zypp(zypper)yast_sw_singleなど、呼びだされたツールです。長い説明は、ブート画面のサイズに応じて、切り捨てて表示されます。

ヒント
ヒント: ブートローダスナップショットエントリのカスタム説明の設定

スナップショットの説明フィールドのデフォルトの文字列をカスタム文字列に置き換えることができます。この機能は、自動的に作成された説明が不十分な場合や、ユーザが入力した説明が長すぎる場合などに役立ちます。カスタム文字列、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=1DRYRUN=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=1DRYRUN=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のSnapperモジュールを使用して、これらのスナップショットからファイルを復元できます。YaSTの場合は現在の設定を選択する必要があります。snapperの場合は、グローバルスイッチ-cを使用して設定を指定する必要があります(例: snapper -c myconfig list)。

新しいSnapper設定を作成するには、snapper create-configを実行します。

> sudo snapper -c www-data1 create-config /srv/www2

1

設定ファイルの名前。

2

スナップショットを作成するパーティションまたはBtrfsサブボリュームのマウントポイント。

このコマンドにより、新しい設定ファイル/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サブコマンドを使用します。CONFIGsnapper list-configsで示される設定名のいずれかに置き換えます。環境設定オプションの詳細については、10.5.1.1項 「環境設定データ」を参照してください。

デフォルトの設定を表示するには、次のコマンドを実行します。

> sudo snapper -c root get-config
設定の変更

指定した設定のオプションを変更するには、snapper -c CONFIG set-config OPTION=VALUEサブコマンドを使用します。CONFIGsnapper list-configsで示される設定名のいずれかに置き換えます。OPTIONおよびVALUEに指定可能な値は、10.5.1.1項 「環境設定データ」に一覧にされています。

設定の削除

設定を削除するには、snapper -c CONFIG delete-configサブコマンドを使用します。CONFIGsnapper list-configsで示される設定名のいずれかに置き換えます。

10.5.1.1 環境設定データ

各設定には、コマンドラインから変更可能なオプションのリストが含まれています。次に、各オプションの詳細を示します。値を変更するには、snapper -c CONFIG set-config "KEY=VALUE"を実行します。

ALLOW_GROUPSALLOW_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 (はい)に設定することです。

手順 10.5: 通常ユーザによるSnapper使用の有効化

次のすべての手順はrootとして実行する必要があります。

  1. Snapper設定がまだ存在しない場合は、ユーザがSnapperを使用できるようにする必要のあるパーティションまたはサブボリュームに対してSnapper設定を作成します。手順については、10.5項 「Snapper設定の作成と変更」を参照してください。例:

    > sudo snapper --config web_data create /srv/www
  2. /etc/snapper/configs/CONFIGに設定ファイルを作成します。CONFIGは、前の手順で-c/--configを使用して指定される値です(/etc/snapper/configs/web_dataなど)。必要に応じて調整します。詳細については、10.5.1項 「既存の設定の管理」を参照してください。

  3. ALLOW_USERSALLOW_GROUPS、またはその一方の値を設定し、ユーザやグループにパーミッションを与えます。複数のエントリはSpaceで区切ってください。たとえば、ユーザwww_adminにパーミッションを与えるには、次のように入力します。

    > sudo snapper -c web_data set-config "ALLOW_USERS=www_admin" SYNC_ACL="yes"
  4. これで、指定されたユーザやグループが特定の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作成をクリックします。以下は、コマンドラインを使ってスナップショットを作成する場合の例です。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"

番号30preスナップショットとペアになるpostスナップショットを作成します。事前事後の状態を保存するために使用されるスナップショットペアを作成するために必要な、2番目のコマンドです。スナップショットには重要のマークが付きます。

snapper create --command COMMAND --description "Before and after COMMAND"

COMMANDの実行前後に自動的にスナップショットを作成します。このオプションを使用できるのは、コマンドラインでsnapperを使用する場合のみです。

10.6.3 スナップショットのメタデータ修正

Snapperでは、スナップショットの説明、クリーンアップアルゴリズム、およびユーザデータを修正できます。それ以外のメタデータは変更できません。以下は、コマンドラインを使ってスナップショットを修正する場合の例です。YaSTインタフェースを使用している場合、これらの例は簡単に採用できます。

コマンドラインでスナップショットを修正するには、スナップショットの番号がわかっている必要があります。snapper listを実行すると、すべてのスナップショットとその番号が表示されます。

YaSTのSnapperモジュールでは、すでにすべてのスナップショットのリストが表示されています。リストからスナップショットを選択し、Modifyをクリックします。

snapper modify --cleanup-algorithm "timeline" 10

デフォルト(root)設定のスナップショット10番のメタデータを修正します。クリーンアップアルゴリズムがtimelineに設定されます。

snapper --config home modify --description "daily backup" -cleanup-algorithm "timeline" 120

カスタム設定homeのスナップショット120番のメタデータを修正します。新しい説明が設定され、クリーンアップアルゴリズムを無しに設定します。

10.6.4 スナップショットの削除

YaSTのSnapperモジュールを使用してスナップショットを削除するには、リストからスナップショットを選択してDelete (削除)をクリックします。

コマンドラインツールを使ってスナップショットを削除するには、スナップショットの番号が分かっている必要があります。snapper listを実行して番号を調べます。スナップショットを削除するには、snapper delete NUMBERコマンドを実行します。

現在のデフォルトのサブボリュームスナップショットの削除は許可されません。

Snapperでスナップショットを削除すると、空いたスペースはバックグラウンドで実行されているBtrfsプロセスによって要求されます。つまり、空きスペースが見えるように、あるいは使用できるようになるまでに遅れが生じます。スナップショットの削除で空いたスペースをすぐに使用したい場合は、deleteコマンドで--syncオプションを指定します。

ヒント
ヒント: スナップショットペアの削除

preスナップショットを削除する場合は、必ず、対応するpostスナップショットを削除する必要があります(逆も同様です)。

snapper delete 65

デフォルト(root)設定のスナップショット65番を削除します。

snapper -c home delete 89 90

homeという名前のカスタム設定のスナップショット89番および90番を削除します。

snapper delete --sync 23

デフォルト設定(root)のスナップショット23を削除し、空いたスペースをすぐに使用できるようにします。

ヒント
ヒント: 参照されていないスナップショットの削除

Btrfsスナップショットが存在するのに、Snapper用のメタデータを含むXMLファイルが欠落している場合があります。この場合、スナップショットがSnapperには見えないため、手動で削除する必要があります。

btrfs subvolume delete /.snapshots/SNAPSHOTNUMBER/snapshot
rm -rf /.snapshots/SNAPSHOTNUMBER
ヒント
ヒント: 古いスナップショットほどディスク容量を使用

ハードディスクの容量を空けるためにスナップショットを削除する場合は、古いスナップショットから削除するようにします。古いスナップショットほど、多くの容量を使用します。

スナップショットは、日次のcronジョブでも自動的に削除されます。詳細については、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_LIMITNUMBER_LIMIT_IMPORTANT、およびNUMBER_MIN_AGEは常に評価されます。スナップショットが削除されるのは、「すべての」条件を満たしている場合のみです。

保存期間に関係なく、NUMBER_LIMIT*で定義された数のスナップショットを常に保持する場合は、NUMBER_MIN_AGE0に設定します。

次の例は、保存期間に関係なく最新の10個の重要なスナップショットと通常のスナップショットを保持するための設定を示しています。

NUMBER_CLEANUP=yes
NUMBER_LIMIT_IMPORTANT=10
NUMBER_LIMIT=10
NUMBER_MIN_AGE=0

特定の保存期間を超えてスナップショットを保持したくない場合は、NUMBER_LIMIT*0に設定して、NUMBER_MIN_AGEで保存期間を指定します。

次の例は、10日経っていないスナップショットのみを保持するための設定を示しています。

NUMBER_CLEANUP=yes
NUMBER_LIMIT_IMPORTANT=0
NUMBER_LIMIT=0
NUMBER_MIN_AGE=864000

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"です。

例 10.1: タイムライン設定の例
TIMELINE_CLEANUP="yes"
TIMELINE_CREATE="yes"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_HOURLY="24"
TIMELINE_LIMIT_MONTHLY="12"
TIMELINE_LIMIT_WEEKLY="4"
TIMELINE_LIMIT_YEARLY="2"
TIMELINE_MIN_AGE="1800"

この設定例では、毎時スナップショットが自動的に削除されます。TIMELINE_MIN_AGETIMELINE_LIMIT_*は、常に両方、評価されます。この例では、スナップショットが削除対象となるまでの最短保存期間が30分(1800秒)に設定されています。毎時のスナップショットを作成するので、最新のスナップショットだけが保持されることになります。TIMELINE_LIMIT_DAILYをゼロ以外に設定すると、1日の最初のスナップショットが保持されることになります。

保持されるスナップショット
  • 1時間ごと: 最新の24個のスナップショットが保持されます。

  • 1日ごと: 各日の最初に作成されたスナップショットが、直近の7日分保持されます。

  • 1カ月ごと: 各月の最後の日に作成された最初のスナップショットが、直近の12カ月分保持されます。

  • 1週ごと: 各週の最後の日に作成された最初のスナップショットが、直近の4週分保持されます。

  • 1年ごと: 各年の最後の日に作成された最初のスナップショットが、直近の2年分保持されます。

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 スナップショットが使用する排他的なディスク容量の表示

スナップショットはデータを共有してストレージ容量を効率的に使用できるため、dudfなどの通常のコマンドを使用しても、使用済みディスク容量は正確に測定されません。クォータを有効にして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つ以上のスナップショットからそのような割り当てを削除するには、次の手順に従います。

  1. 使用可能なすべてのスナップショットの一覧を表示します。

    > sudo snapper list -a
  2. 削除されないようにするスナップショットの数を記憶します。

  3. 次のコマンドを実行します。数字のプレースホルダを、記憶した数に置き換えます。

    > sudo snapper modify --cleanup-algorithm "" #1 #2 #n
  4. もう一度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コマンドを使用して表示できます。

Image

ライブパッチとともに複数のバージョンのカーネルパッケージをインストールすることができます。これらのパッケージは競合しません。実行中のカーネル用にライブパッチとともにアップデートされたカーネルパッケージをインストールできます。この場合、システムを再起動するように求められる場合があります。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サブスクリプションの登録コードを取得してください。

カーネルライブパッチをシステムで有効にするには、次の手順に従います。

  1. yast2 registrationコマンドを実行して、拡張機能の選択をクリックします。

  2. 入手可能な拡張機能のリストでSUSE Linux Enterprise Live Patching 15を選択し、次へをクリックします。

  3. ライセンス条項を確認し、次へをクリックします。

  4. SLE Live Patchingの登録コードを入力し、次へをクリックします。

  5. Installation Summary (インストールの概要)と選択されているPatterns (パターン)を確認します。Live PatchingSLE Live Patching Lifecycle Dataパターンが、依存関係を満たすための追加のパッケージとともにインストール用に自動的に選択されるはずです。

  6. Accept (承諾)をクリックしてインストールを完了します。これにより、システムに基本のカーネルライブパッチコンポーネント、初期ライブパッチ、および必要な依存関係がインストールされます。

11.4 コマンドラインからのカーネルライブパッチの有効化

カーネルライブパッチを有効にするには、アクティブなSLESおよびSLES Live Patchingサブスクリプションが必要です。SUSE Customer Centerにアクセスし、サブスクリプションのステータスを確認し、SLES Live Patchingサブスクリプションの登録コードを取得してください。

  1. 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
  2. 取得したコマンドに続いて-r LIVE_PATCHING_REGISTRATION_CODEを使用してSLES Live Patchingを有効にします。例:

    SUSEConnect -p sle-module-live-patching/15.6/x86_64 \
      -r LIVE_PATCHING_REGISTRATION_CODE
  3. 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テクニカルサポートに連絡してください。

手順 11.1: 手動によるパッチのダウングレード
  1. 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は、実行中のカーネルの正確なバージョンを示しています。

  2. コマンドzypper search -s kernel-livepatch-RUNNING_KERNEL_VERSION-defaultを使用して、以前のバージョンのパッチを検索します。このコマンドは、使用可能なパッケージバージョンのリストを返します。新しいライブパッチパッケージがリリースされるたびに、バージョン番号が1つずつ増加することに注意してください。現在のリリースより1つ前のバージョン番号を選択してください。

  3. 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-livepatchesopenssl-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を使用した接続」のようにVNC server (VNCサーバ)フィールドにホストを入力し、接続をクリックします。

vncviewerにより接続の詳細を入力するよう求められる
図 14.1: vncviewer

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: Remminaのメインウィンドウ

メインアプリケーションウィンドウには、保存されているリモートセッションのリストが表示されます。ここでは、新しいリモートセッションを追加および保存したり、保存せずに新しいセッションをクイックスタートしたり、以前に保存したセッションを開始したり、Remminaのグローバル設定を行うことができます。

14.2.3 リモートセッションの追加

新しいリモートセッションを追加して保存するには、メインウィンドウの左上にあるAdd new sessionをクリックします。リモートデスクトップ初期設定ウィンドウが開きます。

リモートデスクトップ初期設定
図 14.3: リモートデスクトップ初期設定

新しく追加したリモートセッションプロファイルを指定するフィールドに入力します。最も重要な設定には次のものがあります。

名前

プロファイルの名前。この名前は、メインウィンドウにリストされます。

プロトコル

リモートセッションに接続するときに使用するプロトコル(VNCなど)。

または8単位

リモートサーバのIPアドレスまたはDNSアドレスとディスプレイ番号。

ユーザ名、パスワード

リモート認証に使用する資格情報。認証しない場合は空のままにします。

色数、品質

接続速度と品質に応じて最適なオプションを選択します。

より詳細な設定を入力するには、詳細タブを選択します。

ヒント
ヒント: 暗号の無効化

クライアントとリモートサーバ間の通信が暗号化されていない場合は、Disable encryption (暗号の無効化)を有効にします。そうしないと接続が失敗します。

高度なSSHトンネリングと認証オプションについては、SSHタブを選択してください。

[保存]をクリックして確定します。新しいプロファイルがメインウィンドウに表示されます。

14.2.4 リモートセッションの開始

以前に保存したセッションを開始するか、または接続の詳細を保存せずにリモートセッションをクイックスタートすることができます。

14.2.4.1 リモートセッションのクイックスタート

接続の詳細を追加および保存することなく、リモートセッションをすばやく開始するには、メインウィンドウの上部にあるドロップダウンボックスとテキストボックスを使用します。

クイックスタート
図 14.4: クイックスタート

ドロップダウンリストから通信プロトコル(VNCなど)を選択して、次にVNCサーバのDNSまたはIPアドレスを入力し、それに続けてコロンとディスプレイ番号を入力して、Enterで確定します。

14.2.4.2 保存されたリモートセッションを開く

特定のリモートセッションを開くには、セッションのリストからダブルクリックします。

14.2.4.3 リモートセッションウィンドウ

リモートセッションは別のウィンドウのタブで開きます。タブごとに1つのセッションをホストします。ウィンドウの左側にあるツールバーは、ウィンドウ/セッションの管理に役立ちます。たとえば、全画面モードの切り替え、セッションの表示サイズに合わせたウィンドウのサイズ変更、特定のキー入力のセッションへの送信、セッションのスクリーンショットの撮影、画質の設定などが可能です。

Remminaのリモートセッションの表示
図 14.5: Remminaのリモートセッションの表示

14.2.5 保存されたセッションの編集、コピー、および削除

保存されたリモートセッションを編集するには、Remminaのメインウィンドウでその名前を右クリックし、編集を選択します。関連するフィールドの説明については、14.2.3項 「リモートセッションの追加」を参照してください。

保存されたリモートセッションをコピーするには、Remminaのメインウィンドウでその名前を右クリックし、コピーを選択します。リモートデスクトップ初期設定ウィンドウで、プロファイルの名前を変更し、関連するオプションを必要なら調整し、保存をクリックして確定します。

保存されたリモートセッションを削除するには、Remminaのメインウィンドウでその名前を右クリックし、削除を選択します。次のダイアログではいをクリックして確定します。

14.2.6 コマンドラインからのリモートセッションの実行

最初にメインのアプリケーションウィンドウを開くことなく、コマンドラインまたはバッチファイルからリモートセッションを開く必要がある場合は、次の構文を使用します。

 > remmina -c profile_name.remmina

Remminaのプロファイルファイルは、ホームディレクトリの.local/share/remmina/ディレクトリに保存されます。開きたいセッションに属しているプロファイルファイルを決定するには、Remminaを実行し、メインウィンドウでセッション名をクリックし、下部のウィンドウのステータス行でプロファイルファイルへのパスを読み込みます。

プロファイルファイルへのパスの読み込み
図 14.6: プロファイルファイルへのパスの読み込み

が実行されていないときに、プロファイルファイルの名前をsle15.remmina.remminaなどのより合理的なファイル名に変更することができます。プロファイルファイルをカスタムディレクトリにコピーして、そこからremmina -cコマンドを使用して実行することもできます。

14.3 VNCサーバでのワンタイムセッションの設定

一時的セッションは、リモートクライアントによって開始されます。これにより、サーバにグラフィカルなログイン画面が開きます。この画面でセッションを開始するユーザを選択できます。さらに、ログインマネージャでサポートされている場合はデスクトップ環境も選択できます。そのようなVNCセッションへのクライアント接続をキャンセルすると、そのセッション内で開始したアプリケーションもすべて終了します。一時的なVNCセッションは共用できませんが、1つのホストで同時に複数のセッションを実行することは可能です。

手順 14.1: 一時的VNCセッションの有効化
  1. まず、YaST › ネットワークサービス › リモート管理(VNC)の順に選択します。

  2. セッション管理機能無しのリモート管理を許可するをオンにします。

  3. WebブラウザウィンドウでVNCセッションにアクセスする場合は、Web ブラウザを利用したアクセスを有効にするをアクティブにします。

  4. 必要な場合は、ファイアウォールでポートを開くにもチェックマークを付けます (たとえば、ネットワークインタフェースを外部ゾーンに属するように設定する場合)。ネットワークインタフェースが複数ある場合は、ファイアウォールの詳細で、特定のインタフェースにだけファイアウォールポートを開くように制限します。

  5. 次へをクリックすると設定が確定し、

  6. 必要なパッケージの一部をまだ入手できない場合は、足りないパッケージのインストールを承認する必要があります。

    ヒント
    ヒント: ディスプレイマネージャの再起動

    YaSTはディスプレイマネージャの設定を変更します。現在のグラフィカルセッションからログアウトし、ディスプレイマネージャを再起動して変更を有効にする必要があります。

リモート管理
図 14.7: リモート管理

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まで)。デフォルトでは、vnc1vnchttpd1のみがアクティブになっています。

ブート時にVNCサーバソケットをアクティブにするには、次のコマンドを実行します。

> sudo  systemctl enable xvnc.socket

すぐにソケットを起動するには、次のコマンドを実行します。

> sudo  systemctl start xvnc.socket

Xvncサーバは、server_argsオプションを介して設定できます。オプションのリストについては、Xvnc --helpを参照してください。

カスタム設定を追加する際には、それらの設定が、同じホスト上の他の設定、他のサービス、または既存の永続的VNCセッションですでに使用中のポートを使用しないことを確認してください。

設定の変更を有効にするには、次のコマンドを入力します:。

> sudo systemctl reload xvnc.socket
重要
重要: ファイアウォールとVNCポート

手順14.1「一時的VNCセッションの有効化」で説明されているように、リモート管理をアクティブにすると、ファイアウォール内でポート5801および5901が開きます。VNCセッションで使用されるネットワークインタフェースがファイアウォールで保護されている場合、VNCセッションの追加ポートをアクティブにする際には各ポートを手動で開く必要があります。手順については、Book “Security and Hardening Guide”, Chapter 23 “Masquerading and firewalls”を参照してください。

14.4 永続的VNCサーバセッションを設定する

永続的セッションは、複数のクライアントから同時にアクセスすることが可能です。この機能では、1つのクライアントがフルアクセスをもち、他のすべてのクライアントが表示専用アクセスを持つため、デモ用途に最適です。また、講師が受講生のデスクトップにアクセスする必要があるトレーニングセッションでも使用できます。

ヒント
ヒント: 永続的VNCセッションに接続する

永続的VNCセッションに接続するには、VCNビューアをインストールする必要があります。詳細については、14.1項 「vncviewerクライアント」を参照してください。または、JavaScriptを有効にしたWebブラウザで、URLとして「http://jupiter.example.com:5801」を入力することにより、VNCセッションを表示できます。

14.4.1 vncmanagerを使用して開始されたVNCセッション

手順 14.2: 永続的VNCセッションの有効化
  1. まず、YaST › ネットワークサービス › リモート管理(VNC)の順に選択します。

  2. セッション管理機能付きのリモート管理を許可するをアクティブにします。

  3. WebブラウザウィンドウでVNCセッションにアクセスする場合は、Web ブラウザを利用したアクセスを有効にするをアクティブにします。

  4. 必要な場合は、ファイアウォールでポートを開くにもチェックマークを付けます (たとえば、ネットワークインタフェースを外部ゾーンに属するように設定する場合)。ネットワークインタフェースが複数ある場合は、ファイアウォールの詳細で、特定のインタフェースにだけファイアウォールポートを開くように制限します。

  5. 次へをクリックすると設定が確定し、

  6. 必要なパッケージの一部をまだ入手できない場合は、足りないパッケージのインストールを承認する必要があります。

    ヒント
    ヒント: ディスプレイマネージャの再起動

    YaSTはディスプレイマネージャの設定を変更します。現在のグラフィカルセッションからログアウトし、ディスプレイマネージャを再起動して変更を有効にする必要があります。

14.4.1.1 永続的VNCセッションを設定する

手順14.2「永続的VNCセッションの有効化」で説明したVNCセッション管理を有効にすると、通常、vncviewerやRemminaなどの好みのVNCビューアでリモートセッションに接続できます。ログインすると、デスクトップ環境のシステムトレイにVNCアイコンが表示されます。アイコンをクリックすると、VNCセッションウィンドウが開きます。デスクトップ環境がシステムトレイのアイコンをサポートしていない場合は、vncmanager-controllerを手動で実行します。

VNCセッション設定
図 14.8: VNCセッション設定

VNCセッションの動作に影響するいくつかの設定があります。

Non-persistent, private (非永続的、プライベート)

これは一時的セッションに相当します。このセッションは他のユーザに表示されず、セッションを切断すると終了します。詳細については、14.3項 「VNCサーバでのワンタイムセッションの設定」を参照してください。

Persistent, visible (永続的、可視)

このセッションは他のユーザに表示され、セッションを切断しても実行され続けます。

セッション名

永続的セッションの名前を指定して、再接続時に簡単に識別できるようにすることができます。

No password required (パスワード不要)

セッションに、ユーザの資格情報でログインすることなく、自由にアクセス可能です。

Require user login (ユーザログインが必要)

セッションにアクセスするには、有効なユーザ名とパスワードでログインする必要があります。Allowed users (許可されたユーザ)テキストボックスに有効なユーザ名を一覧表示します。

Allow one client at time (同時に1つのクライアントを許可)

同時に複数のユーザがセッションに参加しないようにします。

Allow multiple clients at time (同時に複数のクライアントを許可)

複数のユーザが永続的セッションに同時に参加できるようにします。リモートプレゼンテーションやトレーニングセッションに便利です。

OKをクリックして、確定します。

14.4.1.2 永続的VNCセッションへの参加

14.4.1.1項 「永続的VNCセッションを設定する」で説明した永続的VNCセッションを設定した後、VNCビューアでそのセッションに参加することができます。VNCクライアントからサーバに接続すると、新しいセッションを作成するか、既存のセッションに参加するかを選択するよう求めるプロンプトが表示されます。

永続的VNCセッションへの参加
図 14.9: 永続的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サーバを作成するには、以下の手順を実行します。

手順 15.1: rsyncサーバの設定
  1. jupiterで、すべてのバックアップファイルを保存するディレクトリを作成します。この例では、/var/backupを使用します。

    # mkdir /var/backup
  2. 所有権を指定します。この場合、ディレクトリはグループusersのユーザtuxによって所有されます。

    # chown tux.users /var/backup
  3. rsyncdデーモンを設定します。

    設定ファイルを、メインファイルと、バックアップターゲットを格納する特定のモジュールに分割します。こうすることで、後で他のターゲットを簡単に追加できます。グローバル値は/etc/rsyncd.d/*.incファイルに保存できます。一方、モジュールは/etc/rsyncd.d/*.confファイルに配置します。

    1. ディレクトリ/etc/rsyncd.d/を作成します。

      # mkdir /etc/rsyncd.d/
    2. メイン設定ファイル/etc/rsyncd.confに、次の行を追加します。

      # rsyncd.conf main configuration file
      log file = /var/log/rsync.log
      pid file = /var/lock/rsync.lock
      
      &merge /etc/rsyncd.d 1
      &include /etc/rsyncd.d 2

      1

      グローバル値を/etc/rsyncd.d/*.incファイルからメイン設定ファイルにマージします。

      2

      モジュール(またはターゲット)を/etc/rsyncd.d/*.confファイルからロードします。これらのファイルにはグローバル値への参照を含めないでください。

    3. 次の行を使用して、ファイル/etc/rsyncd.d/backup.conf内にモジュール(バックアップターゲット)を作成します。

      # backup.conf: backup module
      [backup] 1
         uid = tux 2
         gid = users 2
         path = /var/backup 3
         auth users = tux  4
         secrets file = /etc/rsyncd.secrets 5
         comment = Our backup target

      1

      「バックアップ」ターゲット。好きな名前を使用できます。ただし、ターゲットには用途に応じた名前を付け、*.confファイルと同じ名前を使用することをお勧めします。

      2

      ファイル転送の実行時に使用されるユーザ名またはグループ名を指定します。

      3

      バックアップを保存するパスを定義します(ステップ 1から)。

      4

      許可されているユーザのカンマ区切りリストを指定します。最も単純な形式では、このモジュールへの接続を許可されているユーザ名が含まれます。この例では、ユーザtuxのみが許可されています。

      5

      ユーザ名とプレーンパスワードが記述された行が含まれるファイルのパスを指定します。

    4. 次の内容で/etc/rsyncd.secretsファイルを作成し、PASSPHRASEを置き換えます。

      # user:passwd
      tux:PASSPHRASE
    5. rootのみがこのファイルを読み込めるようにします。

      # chmod 0600 /etc/rsyncd.secrets
  4. 次のコマンドを使用して、rsyncdデーモンを起動して有効にします。

    # systemctl enable rsyncd
    # systemctl start rsyncd
  5. rsyncサーバにアクセスできるかどうかをテストします。

    > 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段階のブートプロセスを使用します。

  1. ziplは、Ext2、Ext3、Ext4、またはXFSファイルシステムでフォーマットできるパーティション/boot/ziplからブートします。このパーティションには、メモリにロードされる最小のカーネルとinitramfsが含まれます。initramfsには、Btrfsドライバ(その他の間)およびブートローダGRUB 2が含まれます。カーネルはinitgrubパラメータで開始され、GRUB 2を開始するように指示されます。

  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の生成」の説明に従って手順を進め、アップデートする必要があります。

手順 16.1: initramfsの生成
重要
重要

次の手順のすべてのコマンドをrootユーザとして実行する必要があります。

  1. /bootディレクトリを入力します。

    # cd /boot
  2. dracutを使用して新しいinitramfsファイルを生成し、MY_INITRAMFSを任意のファイル名に置き換えます。

    # dracut MY_INITRAMFS

    または、dracut -f FILENAMEを実行して、既存のinitファイルを置き換えます。

  3. (以前のステップでdracut -fを実行した場合は、このステップはスキップします)。以前のステップで作成したinitramfsファイルからinitrdへのシンボリックリンクを作成します。

    #  ln -sf MY_INITRAMFS initrd
  4. 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)がデフォルトでインストールされます。

注記
注記: GUIDパーティションテーブル(GPT)が必要

セキュアブート機能は、UEFI/x86_64インストール環境ではデフォルトで有効になっています。Enable Secure Boot Support(セキュアブートサポートの有効化)オプションは、ブートローダの設定ダイアログのBoot Code Options(ブートコードオプション)タブにあります。ファームウェアでセキュアブートが有効になっている場合のブート、および無効になっている場合のブートもサポートします。

セキュアブートサポート
図 17.1: セキュアブートサポート

セキュアブート機能を使用するには、マスタブートレコード(MBR)を使用した古いパーティションをGUIDパーティションテーブル(GPT)に置換する必要があります。YaSTは、インストール時にEFIモードを検出すると、GPTパーティションの作成を試みます。UEFIでは、FATフォーマットのEFIシステムパーティション(ESP)上でEFIプログラムが見つかるものと想定されます。

UEFIセキュアブートに対応するには、ブートローダがデジタル署名されており、ファームウェアがそのデジタル署名を信頼されたキーとして認識することが必要です。このキーはファームウェアによってあらかじめ信頼されているので、手動での操作は不要です。

これには2つの方法があります。1つは、ハードウェアベンダーにSUSEキーを署名してもらい、SUSEがその署名を使ってブートローダに署名する方法です。もう1つは、MicrosoftのWindows Logo Certificationプログラムを利用してブートローダの認定を受け、MicrosoftにSUSE署名キーを認識してもらう(つまり、MicrosoftのKEKを使って署名してもらう)方法です。これで、SUSEは、UEFI署名サービス(この場合はMicrosoft)によって署名されたローダを入手できます。

UEFIのセキュアブートプロセス
図 17.2: UEFIのセキュアブートプロセス

実装層で、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をロードします。これにより、いくつかのオプションが表示されます。Enroll key from disk (ディスクからキーを登録)および Enroll hash from disk (ディスクからハッシュを登録)オプションを使用して、MokListにキーを追加できます。Enroll MOK (MOKを登録)オプションを使用して、MokNew変数からキーをコピーします。

ディスクからのキーの登録は、通常、shimがgrub2のロードに失敗し、MokManagerのロードにフォールバックする場合に実行されます。MokNewはまだ存在しないため、UEFIパーティションでキーを検索するオプションがあります。

17.1.3 カスタムカーネルのブート

以下はhttps://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernelにもとづいています。

セキュアブートでは、セルフコンパイルカーネルを使用できます。ただし、独自の証明書を使って署名し、その証明書をファームウェアまたはMOKに知らせる必要があります。

  1. カスタムのX.509キー、および署名に使用される証明書を作成します。

    openssl req -new -x509 -newkey rsa:2048 -keyout key.asc \
      -out cert.pem -nodes -days 666 -subj "/CN=$USER/"

    証明書の作成の詳細については、https://en.opensuse.org/openSUSE:UEFI_Image_File_Sign_Tools#Create_Your_Own_Certificateを参照してください。

  2. PKCS#12形式でキーと証明書をパッケージ化します。

    > openssl pkcs12 -export -inkey key.asc -in cert.pem \
      -name kernel_cert -out cert.p12
  3. pesignとともに使用するNSSデータベースを生成します。

    > certutil -d . -N
  4. PKCS#12に含まれるキーおよび証明書をNSSデータベースにインポートします。

    > pk12util -d . -i cert.p12
  5. pesignを使用して、新しい署名でカーネルをblessします。

    > pesign -n . -c kernel_cert -i arch/x86/boot/bzImage \
      -o vmlinuz.signed -s
  6. カーネルイメージの署名をリスト表示します。

    > pesign -n . -S -i vmlinuz.signed

    その時点で、通常通り/bootにカーネルをインストールできます。カーネルにはカスタム署名があるため、署名に使用された証明書をUEFIファームウェアまたはMOKにインポートする必要があります。

  7. ファームウェアまたはMOKにインポートするため、証明書をDERフォーマットに変換します。

    > openssl x509 -in cert.pem -outform der -out cert.der
  8. よりアクセスしやすくするため、証明書をESPにコピーします。

    > sudo cp cert.der /boot/efi/
  9. mokutilを使用して自動的にMOKリストを起動します。

      1. 証明書をMOKにインポートします。

        > mokutil --root-pw --import cert.der

        --root-pwオプションにより、rootユーザを直接使用できます。

      2. これから登録する証明書のリストを確認します。

        > mokutil --list-new
      3. システムを再起動します。shimによってMokManagerが起動されるはずです。rootパスワードを入力して、MOKリストに証明書をインポートすることを確認してください。

      4. 新しくインポートしたキーが登録されたかどうかを確認します。

        > mokutil --list-enrolled
      1. また、MOKを手動で起動するには以下の手順を実行します。

        再起動

      2. GRUB 2メニューでcキーを押します。

      3. タイプ:

        chainloader $efibootdir/MokManager.efi
        boot
      4. Enroll key from diskを選択します。

      5. cert.derファイルに移動してEnterキーを押します。

      6. 指示に従ってキーを登録します。通常、0を押してからyを押して確認します。

        また、ファームウェアメニューに、署名データベースに新しいキーを追加する方法が用意されている場合があります。

17.1.4 Inbox以外のドライバの使用

セキュアブートを有効にしたインストールでは、Inbox以外のドライバ(SUSE Linux Enterprise Serverに付属していないドライバ)の追加がサポートされません。SolidDriver/PLDPで使用される署名キーは、デフォルトでは信頼されていません。

セキュアブートを有効にしたインストールでは、サードパーティドライバを2つの方法でインストールできます。いずれの方法でも以下を行います。

  • インストール前にファームウェア/システム管理ツールを使用して、必要なキーをファームウェアデータベースに追加します。このオプションは、使用している特定のハードウェアによって異なります。詳細については、ハードウェアベンダーに問い合わせてください。

  • https://drivers.suse.com/またはハードウェアベンダーから入手したブート可能なドライバISOを使用して、初回ブート時に必要なキーをMOKリストに登録します。

ブート可能なドライバISOを使用してドライバキーをMOKリストに登録するには、次の手順に従います。

  1. 空のCD/DVDメディアに上記のISOイメージを書き込みます。

  2. この新しいCD/DVDメディアを使用してインストールを開始します。その際には、標準のインストールメディア、またはネットワークインストールサーバへのURLを用意しておきます。

    ネットワークインストールを行う場合、ブートコマンドラインでinstall=オプションを使用して、ネットワークインストールソースのURLを入力します。

    光学メディアからインストールする場合、インストーラが最初にドライバキットからブートされた後、製品の最初のインストールディスクを挿入するように要求されます。

  3. アップデートされたドライバを含むinitrdが、インストールに使用されます。

詳細については、https://drivers.suse.com/doc/Usage/Secure_Boot_Certificate.htmlを参照してください。

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 詳細情報

18 ブートローダGRUB 2