ArchWiki - 利用者の投稿記録 [ja]

Ccache

2025-06-02T19:40:52Z

Libnumafly: 概要部: 働きに関する表現の変更

{{Lowercase title}}
[[Category:パッケージ開発]]
[[en:Ccache]]
[[pt:Ccache]]
[[zh-hans:Ccache]]
{{Related articles start}}
{{Related|Makepkg}}
{{Related|Distcc}}
{{Related articles end}}
{{Ic|ccache}} は、コンパイルされたバイナリをディスクに保存し、同じコードの最終的な再コンパイルを高速化するためにそれらを提供するコンパイララッパーです。 {{Ic|ccache}} が挟まることで初めてプログラムをコンパイルするのに数秒長くかかる場合がありますが、次回から以前に保存されたバイナリを参照するだけなので、その後のコンパイルははるかに高速になります。 {{ic|ccache}} は [[GCC]] および [[Clang]] と互換性があります。

== インストール ==

{{pkg|ccache}} パッケージを[[pacman|インストール]]してください。

== 設定 ==

設定ファイルを使うことでデフォルトの挙動を上書きできます。設定の優先順位は以下の通りです (優先順位の高いものから並べています):
# 環境変数
# ユーザー個別の設定ファイル ({{ic|$HOME/.ccache/ccache.conf}})
# 全ユーザー共通の設定ファイル ({{ic|/etc/ccache.conf}})

詳細は、{{man|1|ccache}} を参照してください。

=== makepkg で ccache を有効にする ===
makepkg の使用時に ccache を有効にするには {{ic|/etc/makepkg.conf}} を編集して下さい。{{Ic|BUILDENV}} の中の ccache の前のエクスクラメーションマークを除去すれば有効になります。例:
{{hc|1=/etc/makepkg.conf|
2=BUILDENV=(!distcc color '''ccache''' check !sign)}}

=== コマンドラインで有効にする ===

パッケージを作成するのではなく、コマンドラインからコードをコンパイルするとき、{{Ic|ccache}} を使うことでコンパイル速度を向上させることができます。

そのためには、各コンパイルコマンドの前に {{Ic|ccache}} を付けます。

$ ccache cc hello_world.c

または、コンパイラへのパスの前に ''ccache'' のバイナリを含むように {{Ic|$PATH}} を変更します：

$ export PATH="/usr/lib/ccache/bin/:$PATH"

この行を定期的に使用するために[[環境変数]]として設定することをお勧めします。

{{Note|このようなエクスポートは、この PATH で呼び出された場合に ''makepkg'' でも必然的に ''ccache'' を有効にします。}}

=== colorgcc で有効にする ===
colorgcc もコンパイララッパーなので、正しい順番でラッパーが呼ばれるように注意する必要があります。

export PATH="/usr/lib/colorgcc/bin/:$PATH" # As per usual colorgcc installation, leave unchanged (don't add ccache)
export CCACHE_PATH="/usr/bin" # Tell ccache to only use compilers here

そして本当のコンパイラの代わりに ccache を呼び出すように colorgcc を設定してください。{{ic|/etc/colorgcc/colorgccrc}} を編集し {{ic|/usr/bin}} のパスを {{ic|/usr/lib/ccache/bin}} にある全てのコンパイラに対応するように {{ic|/usr/lib/ccache/bin}} のパスに変更します:
{{hc|/etc/colorgcc/colorgccrc|g++: /usr/lib/ccache/bin/g++
gcc: /usr/lib/ccache/bin/gcc
c++: /usr/lib/ccache/bin/g++
cc: /usr/lib/ccache/bin/cc
g77:/usr/bin/g77
f77:/usr/bin/g77
gcj:/usr/bin/gcj}}

新しいバージョンの ''ccache'' では、{{ic|GCC_COLORS}} が設定されている場合、GCC については常に色を有効にします。Clang についてはデフォルトで色が有効です。出力が TTY でない場合、''ccache'' はコンパイラに色を生成させ、キャッシュに保存しますが、出力からは色を取り除きます。[https://github.com/ccache/ccache/issues/224 -fdiagnostics-color] の統一に関するいくつかの問題が残っています。

== その他 ==

=== Sloppiness ===

''ccache'' はデフォルトで、誤検知と、一部のプロジェクトでは実際の検知の両方を最小限に抑える非常に保守的な比較を使用します。一部の比較は役に立たないとみなされるため、変更できます。

$ ccache --set-config=sloppiness=locale,time_macros

これは、''ccache'' に {{ic|__FILE__}} および時間関連のマクロを無視するように指示します。これらのマクロは通常、キャッシュを無効にし、[[再現性のあるビルド]]では有害であると考えられます。ロケールの違いも無視されます。''ccache'' がこれを考慮するのは、主に診断メッセージの言語を決定するためです。

{{ic|CCACHE_SLOPPINESS}} [[環境変数]]をエクスポートして、既存の sloppiness 設定をオーバーライドできます。

また、''ccache'' は、デフォルトで各ビルドに使用されている現在のディレクトリをキャッシュします。これは、呼び出されるたびに新しいランダムな一時ディレクトリを使用するビルドパイプラインのキャッシュミスを意味します。''ccache'' マニュアルの [https://ccache.dev/manual/latest.html#_compiling_in_Difference_directories Compiling in different directories] セクションを参照してください。

=== キャッシュディレクトリを変更する ===

デフォルトの {{ic|~/.ccache}} ディレクトリから、[[SSD]] や [[fstab#tmpfs|RAM ディスク]]などの高速にアクセス可能な場所にキャッシュディレクトリを移動することができます。

キャッシュの位置を変更するには (現在のシェルでのみ有効):
$ export CCACHE_DIR=/ramdisk/ccache

あるいは永続的に位置を変更するには:

{{hc|1=/home/''user''/.ccache/ccache.conf|
2=cache_dir = /ramdisk/ccache}}

=== 最大キャッシュ容量の設定 ===

デフォルトでは5ギガバイトとなっていますが、多くしたり少なくしたりすることができます:

$ ccache --set-config=max_size=2.0G

=== 環境変数でキャッシュを無効化 ===

現在のシェルでのみ CCache を無効化したい場合、以下を設定:
$ export CCACHE_DISABLE=1

=== CLI ===

ccache のコマンドラインユーティリティを使うことで以下の操作ができます。

統計を表示する:
$ ccache -s

キャッシュを完全に削除する:
$ ccache -C

=== makechrootpkg ===

makechrootpkg で ccache を使うこともできます。makechrootpkg の {{ic|-d}} オプションを使うことで通常の環境から chroot にキャッシュディレクトリをバインドすることが可能です:
$ mkdir /path/of/chroot/ccache
$ makechrootpkg -d /path/to/cache/:/ccache -r /path/of/chroot -- CCACHE_DIR=/ccache
上記で説明しているように chroot でも ccache が使われるように設定してください。

== 注意点 ==

''ccache'' は'''完全に同一の'''ソースをコンパイルする際に'''のみ'''効果的です（より正確には、プリプロセスされたソースに対してです）。

Gentoo Linux コミュニティでは、ソースベースのディストリビューションであるため、''ccache'' はプラセボ効果やコンパイル失敗（望ましくない残留オブジェクトによる）などで悪名高いです。Gentoo では、コンパイル失敗を報告する前に ''ccache'' をオフにすることが要求されます。[[Gentoo:Handbook:Parts/Working/Features#Caching compilation objects]] および Diego Pettenò（元 Gentoo 開発者）による "Debunking ccache myths" と題されたブログ投稿 [https://flameeyes.blog/2008/06/21/debunking-ccache-myths/ the blog post] を参照してください。

== 参照 ==

*[http://ccache.samba.org/manual.html ccache マニュアル]

{{TranslationStatus|Ccache|2024-05-08|795404}}

Systemd

2024-11-17T08:50:34Z

Libnumafly: /* ソフトリブート */ 抜け字を修正

{{Lowercase title}}
[[Category:Init]]
[[de:Systemd]]
[[en:Systemd]]
[[es:Systemd]]
[[fa:Systemd]]
[[fi:Systemd]]
[[fr:Systemd]]
[[pt:Systemd]]
[[ru:Systemd]]
[[zh-hans:Systemd]]
{{Related articles start}}
{{Related|systemd/ユーザー}}
{{Related|systemd/タイマー}}
{{Related|systemd/ジャーナル}}
{{Related|systemd FAQ}}
{{Related|init}}
{{Related|デーモン#デーモン一覧}}
{{Related|udev}}
{{Related|パフォーマンスの向上/ブートプロセス}}
{{Related|ユーザーにシャットダウンを許可}}
{{Related articles end}}

[https://freedesktop.org/wiki/Software/systemd プロジェクトウェブページ] より:

:'''systemd''' は Linux 環境の基本構成スイートであり、SysV や LSB init スクリプトと互換性のある、Linux 用のシステム・サービスマネージャです。'''systemd''' はサービスの起動を積極的に並行化します。また、ソケットや [[D-Bus]] のアクティベーションを使用してサービスを起動し、必要なデーモンの開始を行うことができ、Linux の [[cgroups]] によるプロセス管理ができます。システム状態のスナップショット作成と復元、(自動) マウントポイントの管理、煩雑な依存関係に基づいたサービスのコントロールを処理します。''systemd'' は sysvinit の代替として SysV や LSB init スクリプトをサポートしています。init としての機能以外にも、ログデーモンやホストネーム・時刻・ロケールなどシステムの基本設定を制御するユーティリティ、ログイン中のユーザーから実行中のコンテナや仮想マシン、システムアカウントまで管理する機能、ネットワーク設定や時刻同期あるいは名前解決などを管理するシンプルなデーモンも含まれています。

歴史的には、systemd が "サービス" と呼ぶものは [[Wikipedia:ja:デーモン (ソフトウェア)|デーモン]] と呼ばれていました:"バックグラウンド" プロセスとして (ターミナルやユーザーインターフェイスなしで) 実行され、一般的にイベントの発生を待ち、サービスを提供するプログラムです。ウェブサーバーがページを配信するリクエストを待ったり、ssh サーバーがログインしようとする人を待ったりするのが良い例です。これらは完全な機能を持つアプリケーションですが、デーモンも存在します。デーモンは、ログファイルにメッセージを書き込んだり (例:{{ic|syslog}}、{{ic|metalog}})、システムの時刻を正確に保つ (例:[[Network Time Protocol daemon|ntpd]]) といったタスクを実行します。詳しくは {{man|7|daemon}} を参照してください。

{{Note|1=systemd が Arch に採用された理由については、[https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 フォーラムへのこの投稿]をご覧ください。}}

== systemctl の基本的な使い方 ==

''systemd'' を管理したり内部情報を見るために使うメインのコマンドが ''systemctl'' です。システムの状態を確かめたりシステムやサービスを管理するために使うのは使い方の一部です。詳しくは {{man|1|systemctl}} を見て下さい。

{{Tip|
* ''systemctl'' コマンドに {{ic|-H ''user''@''host''}} を渡すと、リモートの ''systemd'' と対話できます。これは [[Secure Shell|SSH]] を利用してリモートの ''systemd'' インスタンスに接続します。
* [[Plasma]] を使っている場合 {{Pkg|systemdgenie}} をインストールすることで ''systemctl'' のグラフィカルフロントエンドを使えます。モジュールをインストールすると ''System'' の下に設定が追加されます。}}

=== ユニットを使う ===

ユニットには、例えば、サービス (''.service'') やマウントポイント (''.mount'')、デバイス (''.device'')、ソケット (''.socket'') などがあります。

''systemctl'' を使うとき、例えば {{ic|sshd.socket}} のように、一般的には拡張子 (suffix) を含むユニットファイルの完全な名前を指定する必要があります。しかし、以下のような場合には省略形が存在します:

* 拡張子が指定されない場合、systemctl は ''.service'' とみなします。例えば {{ic|netctl}} と {{ic|netctl.service}} は同じように扱われます。
* マウントポイントは自動的に対応する ''.mount'' ユニットとして扱われます。例えば、{{ic|/home}} を指定することは {{ic|home.mount}} の指定と同じです。
* マウントポイントと同じく、デバイスも自動的に対応する ''.device'' ユニットとして扱われます。従って、{{ic|/dev/sda2}} の指定は {{ic|dev-sda2.device}} と同じです。

詳細は {{man|5|systemd.unit}} を見てください。

{{Note|ユニットによっては名前に {{ic|@}} 記号が含まれていることがあります (例: {{ic|name@''string''.service}}): これは、そのサービスが''テンプレート''ユニットの [http://0pointer.de/blog/projects/instances.html インスタンス] であることを意味しており、テンプレートユニットのファイル名には {{ic|''string''}} の部分が含まれていません (例: {{ic|name@.service}})。{{ic|''string''}} は ''instance identifier'' と呼ばれ、''systemctl'' コマンドでテンプレートユニットを実行するときに指定する引数と似ています: ユニットファイルの中の {{ic|%i}} が置き換えられます。

正確に言うと、{{ic|name@.suffix}} テンプレートユニットのインスタンスを作成する''前に''、''systemd'' は {{ic|name@string.suffix}} というファイル名のユニットが存在しないか確認します。ただし名前の"衝突"が発生するのは極めて稀で、{{ic|@}} 記号を含むユニットファイルは大抵テンプレートです。そういう決まりです。また、テンプレートユニットが instance identifier を付けられずに呼ばれたときは、{{ic|%i}} が置き換えられないため実行失敗になります ({{ic|cat}} のような特定の ''systemctl'' コマンドを除く)。}}

以下の表のコマンドは、''systemctl'' の暗黙のデフォルトである {{ic|--system}} から、'''system unit''' を操作するものです。代わりに、'''ユーザー単位''' で操作するには、root 権限なしで [[systemctl --user]] を使ってください。全てのユーザーに対してユーザーユニットを有効・無効にするには [[systemd/ユーザー#基本設定]] も見て下さい。

{{Tip|
* 以下のコマンドのほとんどは複数のユニットを指定することが可能です、詳しくは {{man|1|systemctl}} を参照。
* {{ic|--now}} スイッチは {{ic|enable}}, {{ic|disable}}, {{ic|mask}} と一緒に使うことで、それぞれ起動、停止、マスクをリブート後ではなく即座に行うことができます。
* パッケージには様々な目的のユニットが入っています。パッケージをインストールしたら、{{ic|pacman -Qql ''package'' <nowiki>|</nowiki> grep -Fe .service -e .socket}} でサービスを確認することができます。
}}

{| class="wikitable"
! アクション || コマンド || 注意
|-
! colspan="3" | システム状態の分析
|-
| '''システムステータスを表示する''' || {{ic|systemctl status}} ||
|-
| '''実行中のユニット''' リスト || {{ic|systemctl}} or {{ic|systemctl list-units}} ||
|-
| '''失敗したユニット''' 一覧 || {{ic|systemctl --failed}} ||
|-
| '''インストールされているユニット''' 一覧1 || {{ic|systemctl list-unit-files}} ||
|-
| '''PID のプロセスステータス''' を表示 || {{ic|systemctl status ''pid''}} || [[cgroups|cgroup slice]], メモリと上位プロセス
|-
! colspan="3" | ユニットの状態を確認する
|-
| ユニットに関連付けられている '''マニュアルページを表示する''' || {{ic|systemctl help ''unit''}} || ユニットでサポートされています
|-
| ユニットの '''ステータス''' || {{ic|systemctl status ''unit''}} || 実行されているかどうかを含む
|-
| ユニットが有効かどうかを '''チェック''' する || {{ic|systemctl is-enabled ''unit''}} ||
|-
! colspan="3" | 本体の起動、再起動、再読み込み
|-
| ユニットを即座に '''スタート''' する || {{ic|systemctl start ''unit''}} as root ||
|-
| ユニットを即座に '''ストップ''' する || {{ic|systemctl stop ''unit''}} as root ||
|-
| ユニットを '''再起動''' する || {{ic|systemctl restart ''unit''}} as root ||
|-
| ユニットとその設定を '''再読み込み''' する || {{ic|systemctl reload ''unit''}} as root ||
|-
| '''systemd マネージャーの再読み込み''' 設定2 || {{ic|systemctl daemon-reload}} as root || ユニットスキャン
|-
! colspan="3" | ユニットの有効化
|-
| ブート時に自動的に起動するユニットを '''有効''' にする || {{ic|systemctl enable ''unit''}} as root ||
|-
| 起動時に自動起動するユニットを '''有効''' にして、すぐに '''起動''' する || {{ic|systemctl enable --now ''unit''}} as root ||
|-
|ユニットの自動起動を '''無効'''にする || {{ic|systemctl disable ''unit''}} as root ||
|-
| ユニット3を ''再有効化'' する || {{ic|systemctl reenable ''unit''}} as root || つまり、無効化して新たに有効化する
|-
! colspan="3" | ユニットのマスキング
|-
|ユニットを '''マスク''' して起動を禁止する4 || {{ic|systemctl mask ''unit''}} as root ||
|-
| ユニットの '''マスクを解除''' する || {{ic|systemctl unmask ''unit''}} as root ||
|}

# 利用可能なユニットファイルがあるディレクトリは {{man|5|systemd.unit|UNIT FILE LOAD PATH}} を参照してください。
# これは変更されたユニットに設定の再読み込みを要求しません (アクション '''Reload''' を参照して下さい)。
# 例えば、最後に有効化してからその {{ic|[Install]}} セクションが変更された場合。
# 手動でも依存関係としても、マスクは危険です。既存のマスクされたユニットをチェックします。{{bc|1=$ systemctl list-unit-files --state=masked}}

=== 電源管理 ===

非特権ユーザーでの電源管理には、[[polkit]] が必要です。ローカルの ''systemd-logind'' ユーザーセッションで、他のセッションがアクティブでない場合、以下のコマンドは root 権限がなくても動作します。そうでない場合(例えば、他のユーザーが tty にログインしているなど)、''systemd'' は自動的に root パスワードを要求します。

{| class="wikitable"
! アクション || コマンド
|-
| システムをシャットダウンして再起動する || {{ic|systemctl reboot}}
|-
| システムをシャットダウンして電源を切る || {{ic|systemctl poweroff}}
|-
| システムを一時停止する || {{ic|systemctl suspend}}
|-
| システムをハイバネーションにする || {{ic|systemctl hibernate}}
|-
| システムをハイブリッドスリープ状態にする (または suspend-to-both) にする || {{ic|systemctl hybrid-sleep}}
|-
| まずシステムをサスペンドし、設定された時間の経過後にウェイクアップしてシステムを休止状態にする || {{ic|systemctl suspend-then-hibernate}}
|-
|}

==== ソフトリブート ====

ソフトリブートは、カーネルを介さないユーザ空間のみの特別なリブート操作です。{{man|8|systemd-soft-reboot.service}} によって実装されており、{{ic|systemctl Soft-reboot}} によって呼び出すことができます。[[kexec]] と同様、ファームウェアの再初期化をスキップしますが、さらにシステムはカーネルの初期化と [[initramfs]] を通過せず、ロックされていない [[dm-crypt]] デバイスは接続されたままになります。

{{ic|/run/nextroot/}} に有効なルートファイルシステム階層が含まれている場合 (例: 別のディストリビューションまたは別のスナップショットのルートマウント)、''ソフトリブート'' によりシステムルートがそこに切り替わり、カーネルによって管理される状態 ([[ネットワーク設定]] など) を失うことなく、別のインストールに切り替えることが出来ます。

{{Tip|{{ic|/run/nextroot/}} は、必ずしもマウントポイントである必要はなく、物理デバイスによってバックアップされているわけでもありません。たとえば、{{ic|/run/}} tmpfs に常駐できます。''systemd'' は、''ソフトリブート'' 時に {{ic|/run/nextroot/}} を自動的にマウントポイントに変更します。}}

{{Note|カーネルと initramfs を含むパッケージの更新後は、{{ic|systemctl Soft-reboot}} を呼び出さないでください。}}

== ユニットファイル ==

systemd のユニットファイル ({{man|5|systemd.unit}}) の構文は [[デスクトップエントリ|XDG の Desktop Entry Specification である .desktop ファイル]] から影響を受けています。そして ''.desktop'' は [[Wikipedia:ja:INIファイル|Microsoft Windows の .ini ファイル]] からインスパイアされています。ユニットファイルは複数の場所に配置されます (配置場所のリストを確認するには {{ic|1=systemctl show --property=UnitPath}} を実行してください)が、主な場所は (優先度が低い方から説明すると):

* {{ic|/usr/lib/systemd/system/}}: インストールしたパッケージに含まれているユニット
* {{ic|/etc/systemd/system/}}: システムの管理者がインストールしたユニット

{{Note|
*[[systemd/ユーザー|ユーザーモード]]で ''systemd'' を動作させたときにロードされるパスは完全に異なります。
*systemd ユニットの名前に使うことができるのは ASCII 英数字とアンダーバー、ピリオドだけです。他の文字列は C スタイルの "\x2d" エスケープに置き換えるか、事前に定義された方法 ('@' や '-') を使う必要があります。詳しくは {{man|5|systemd.unit}} や {{man|1|systemd-escape}} を見て下さい。
}}

例としてパッケージによりインストールされたユニットや {{man|5|systemd.service|EXAMPLES}} を参照してください。

{{Tip|{{ic|#}} で始まるコメントはユニットファイルでも使うことができますが、行頭でのみ有効です。''systemd'' のパラメータの後で行末のコメントを使わないでください。ユニットの有効化が失敗する原因となります。}}

=== 依存関係を解決する ===

systemd ではユニットファイルを適切に書くことで依存関係を解決します。一番典型的なケースは、ユニット {{ic|A}} が走る前に、ユニット {{ic|A}} がユニット {{ic|B}} を必要としている場合です。この場合、{{ic|A}} の {{ic|[Unit]}} セクションに {{ic|1=Requires=B}} と {{ic|1=After=B}} を加えます。依存が必然ではない場合、代わりに {{ic|1=Wants=B}} と {{ic|1=After=B}} を加えます。{{ic|1=Wants=}} と {{ic|1=Requires=}} は {{ic|1=After=}} を含まないことに注意してください、もし {{ic|1=After=}} を明記しなかったときは、2つのユニットは並行して実行されます。

基本的に、依存関係は[[#ターゲット|ターゲット]]ではなくサービスに記述します。例えば、{{ic|network.target}} はネットワークインターフェースを設定する全てのサービスによって使われるので、カスタムユニットを起動させる順番は {{ic|network.target}} が起動し終わってからにする必要があります。

=== サービスタイプ ===

カスタムサービスファイルを書くときにどのスタートアップタイプを使うべきか考える必要があります。タイプは {{ic|[Service]}} セクションの {{ic|1=Type=}} パラメータで設定します。

* {{ic|1=Type=simple}} (デフォルト): ''systemd'' はプロセスを起動した時点でサービスが立ち上がったとみなします。プロセスをフォークすることはできません。ソケットアクティベーション以外で他のサービスが必要な場合に、このタイプを使ってはいけません。
* {{ic|1=Type=forking}}: 起動したプロセスが一旦フォークし、親プロセス側が終了したときに、 ''systemd'' はサービスが立ち上がったとみなします。このタイプでなくてもかまわないとき以外は、古典的なデーモンにはこのタイプを使って下さい。また {{ic|1=PIDFile=}} を指定することで ''systemd'' はメインプロセスの情報を追い続けます。
* {{ic|1=Type=oneshot}}: シングルジョブを行い終了するスクリプト用のタイプです。また {{ic|1=RemainAfterExit=yes}} を設定することで ''systemd'' はプロセスが終了した後もサービスがアクティブだとみなします。
* {{ic|1=Type=notify}}: {{ic|1=Type=simple}} と同じですが、利用可能になったときにデーモンが ''systemd'' に信号を送るように条件がつけられます。この通知のリファレンス実装は ''libsystemd-daemon.so'' によって提供されています。
* {{ic|1=Type=dbus}}: 指定の {{ic|BusName}} が DBus のシステムバスに乗ったときに使うことができるサービス。
* {{ic|1=Type=idle}}: ただし、サービスバイナリの実行は全てのジョブが処理されるまで待たされます。それ以外の挙動は {{ic|1=Type=simple}} と非常に似ています。

{{ic|Type}} の値のより詳しい説明は {{man|5|systemd.service|OPTIONS}} を見て下さい。

=== ユニットファイルの編集 ===

pacman との競合を避けるために、パッケージに含まれるユニットファイルは直接編集しないでください。パッケージに入っているユニットファイルを元のファイルに触れずに編集する安全な方法は2つあります: 新しいユニットファイルで[[#ユニットファイルを置換する|完全に置き換える]]か、[[#ドロップインファイル|ドロップインファイル]]を作成して既存のユニットファイルに上書きして適用させるかです。どちらの方法でも、変更を加えた後はユニットをリロードする必要があります。{{ic|systemctl edit}} でユニットを編集するか (自動でユニットがリロードされます) または次のコマンドで全てのユニットをリロードしてください:

# systemctl daemon-reload

{{Tip|
* {{ic|systemd-delta}} を使うことでどのファイルが上書きされ、どこが変更されたのか調べることができます。
* ユニットファイルや関連するドロップインファイルの中身を見るには {{ic|systemctl cat ''unit''}} を使います。
}}

==== ユニットファイルを置換する ====

ユニットファイル {{ic|/usr/lib/systemd/system/''unit''}} を置き換えたいときは、{{ic|/etc/systemd/system/''unit''}} ファイルを作成してユニットを [[#ユニットを使う|再有効化]] することでシンボリックリンクをアップデートします。

もしくは、次を実行:

# systemctl edit --full ''unit''

このコマンドはテキストエディタで {{ic|/etc/systemd/system/''unit''}} を開いて (ファイルが存在しない場合はインストールされているユニットがコピーされます)、編集を終えた時に自動的にユニットをリロードします。

{{Note|Pacman は元のユニットファイルが更新されても置き換えられたユニットファイルをアップデートしません。そのため、この方法ではシステムメンテナンスが多少厄介になります。この理由があるために、次のセクションで説明する方法の方が推奨されます。}}

==== ドロップインファイル ====

ユニットファイル {{ic|/usr/lib/systemd/system/''unit''}} のドロップインファイルを作成するには、{{ic|/etc/systemd/system/''unit''.d/}} という名のディレクトリ (例: {{ic|/etc/systemd/system/httpd.service.d/}}) を作成してその中に {{ic|*.conf}} を配置します。このファイルを使ってオプションを上書きしたり追加してください。''systemd'' が {{ic|*.conf}} ファイルをパースして元のユニットファイルの一番上に設定を適用します。

ドロップインファイルを作成する一番簡単な方法は次のコマンドを実行することです:

# systemctl edit ''unit''

テキストエディタで {{ic|/etc/systemd/system/''unit''.d/override.conf}} ファイルが開かれ (必要であればファイルが作成されます)、編集を終えた時に自動でユニットがリロードされます。

==== 初期状態にリバート ====

{{ic|systemctl edit}} を使って変更したユニットを元に戻したい場合、以下のコマンドを実行:

# systemctl revert ''unit''

==== サンプル ====

例えば、ユニットに依存するデーモンを追加したい場合、以下のファイルを作成することができます:

{{hc|/etc/systemd/system/''unit''.d/customdependency.conf|2=
[Unit]
Requires=''new dependency''
After=''new dependency''}}

{{ic|oneshot}} タイプでないユニットの {{ic|ExecStart}} ディレクティブを置き換えるには、以下のファイルを作成します:

{{hc|/etc/systemd/system/''unit''.d/customexec.conf|2=
[Service]
ExecStart=
ExecStart=''new command''}}

{{Note|1={{ic|ExecStart}} は置き換える前に空白にする必要があるので注意してください ([https://bugzilla.redhat.com/show_bug.cgi?id=756787#c9])。タイマーの {{ic|OnCalendar}} など複数回指定できるアイテムも同じです。}}

サービスが自動的に再起動されるようにするには:

{{hc|/etc/systemd/system/''unit''.d/restart.conf|2=
[Service]
Restart=always
RestartSec=30}}

== ターゲット ==

Systemd では [[Wikipedia:ja:ランレベル|ランレベル]] に似たものとして''ターゲット''を使っています。ただしその挙動には少し違いがあります。それぞれの''ターゲット''はナンバリングされる代わりに名前がつけられ、ある特定の目的のために作られ、複数のターゲットを同時に有効にできるようになっています。''ターゲット''によっては、他の''ターゲット''のサービスを全て引継ぎ、そこにサービスを追加するよう実装されています。一般的な SystemVinit ランレベルに擬態する systemd ''ターゲット''もあり、親しみのある {{ic|telinit RUNLEVEL}} コマンドを使って使用する''ターゲット''を切り替えることが可能です。

=== 現在のターゲットを取得 ===

''systemd'' では {{ic|runlevel}} の代わりに次のコマンドが使われます:

$ systemctl list-units --type=target

=== カスタムターゲットを作る ===

sysvinit ではランレベルごとに特定の目的が設定されています; 0, 1, 3, 5, 6 のランレベルには特定の sytemd ''ターゲット''と一対一の対応関係が存在します。残念ながら、ユーザー定義のランレベル (2 や 4 など) で同じことをする良い方法はありません。もしあなたがそうしたいならば、既に存在しているランレベルをベースに新しい systemd ''ターゲット''を {{ic|/etc/systemd/system/''your target''}} として作り ({{ic|/usr/lib/systemd/system/graphical.target}} がサンプルになるかもしれません)、{{ic|/etc/systemd/system/''your target''.wants}} ディレクトリを作って、有効にしたいサービスに {{ic|/usr/lib/systemd/system/}} からシンボリックリンクを貼ることが示唆されています。

=== SysV ランレベルと systemd ターゲットの対応表 ===

{| class="wikitable"
! SysV ランレベル !! systemd ターゲット !! 説明
|-
| 0 || runlevel0.target, poweroff.target || システムを停止。
|-
| 1, s, single || runlevel1.target, rescue.target || シングルユーザーモード。
|-
| 2, 4 || runlevel2.target, runlevel4.target, multi-user.target || ユーザー定義・サイト指定ランレベル。デフォルトでは、3 と同一。
|-
| 3 || runlevel3.target, multi-user.target || マルチユーザー、非グラフィカル。一般的にマルチコンソールやネットワークを介してログインするのに使われます。
|-
| 5 || runlevel5.target, graphical.target || マルチユーザー、グラフィカル。通常、ランレベル 3 の全てのサービスにグラフィカルログインを付加。
|-
| 6 || runlevel6.target, reboot.target || 再起動
|-
| emergency || emergency.target || 緊急シェル
|-
|}

=== 現在のターゲットを変更する ===

''systemd'' ではターゲットは ''ターゲットユニット'' を通して扱うことができます。ターゲットを変えるには次のようにします:

# systemctl isolate graphical.target

これは現在のターゲットを変えるだけで、次の起動時には影響がありません。SysVinit での、{{ic|telinit 3}} や {{ic|telinit 5}} のようなコマンドと同じです。

=== 起動するデフォルトターゲットを変更 ===

標準のターゲットは {{ic|default.target}} で、これは {{ic|graphical.target}} へのシンボリックリンクです。これは、古いランレベル5にほぼ対応します。

''systemctl'' を使用して現在のターゲットを確認するには、次の手順に従います。

$ systemctl get-default

ブート先のデフォルトターゲットを変更するには、{{ic|default.target}} シンボリックリンクを変更します。''systemctl'' の場合

{{hc|1=# systemctl set-default multi-user.target|2=
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target -> /usr/lib/systemd/system/multi-user.target.}}

または、次の [[カーネルパラメータ]] のいずれかをブートローダに追加します。

* {{ic|1=systemd.unit=multi-user.target}} (これは、古いランレベル3にほぼ対応しています)
* {{ic|1=systemd.unit=rescue.target}} (これは、古いランレベル1にほぼ対応しています)

=== デフォルトのターゲット順序 ===

''systemd'' は、次の順序に従って {{ic|default.target}} を選択します。

# 上記のカーネルパラメータ
# {{ic|/etc/systemd/system/default.target}} への Symlink
# {{ic|/usr/lib/systemd/system/default.target}} への Symlink

== systemd の構成要素 ==

''systemd'' のコンポーネントをいくつか(網羅的ではない)紹介します。

* [[systemd-boot]] — シンプルな UEFI [[Arch ブートプロセス|ブートマネージャー]] です。
* {{man|1|systemd-cryptenroll}} — LUKS2 で暗号化されたボリュームに PKCS#11、FIDO2、TPM2 トークン/デバイスを登録します。
* [[systemd-firstboot]] — 最初のブートの前に基本的なシステム設定を初期化します。
* [[systemd-homed]] — ポータブルな人間のユーザー [[ユーザーとグループ|アカウント]] です。
* {{man|8|systemd-logind}} — [https://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/ セッション管理]
* [[systemd-networkd]] — [[ネットワーク設定]] 管理。
* [[systemd-nspawn]] — 軽量なネームスペースコンテナ。
* [[systemd-resolved]] — ネットワークの [[ドメイン名前解決|名前解決]]
* {{man|8|systemd-sysusers}} — パッケージのインストール時または起動時に、システムユーザーとグループを作成し、ユーザーをグループに追加します。
* [[systemd-timesyncd]] — ネットワーク上で [[時刻|システム時刻]] を同期します。
* [[systemd/ジャーナル]] — システムのログを記録します。
* [[systemd/タイマー]] — ファイルやイベントを制御するための単調またはリアルタイムのタイマー ''.service'' [[cron]] の代替。
* {{man|7|systemd-stub}} — [https://wiki.archlinux.org/title/Unified_kernel_image ユニファイドカーネルイメージ] を作成するために使用される UEFI ブートスタブです。

=== systemd.mount - マウント ===

''systemd'' は {{ic|/etc/fstab}} で指定されたパーティションとファイルシステムのマウントを担当します。{{man|8|systemd-fstab-generator}} は {{ic|/etc/fstab}} の全てのエントリを ''systemd'' ユニットに変換します; これは起動時とシステムマネージャの設定が再ロードされた時に実行されます。

''systemd'' は通常の [[fstab]] 機能を拡張し、追加のマウントオプションを提供します。これらのオプションはマウントユニットの依存関係に影響を与えます。例えば、ネットワークが立ち上がった時だけマウントするようにしたり、他のパーティションがマウントされた時だけマウントするようにすることができます。特定の ''systemd'' マウントオプションの完全なリストは、通常 {{ic|x-systemd.}} で始まり、 {{man|5|systemd.mount|FSTAB}} で詳細に説明されています。

これらのマウントオプションの例として、''自動マウント''があります。これは、ブート時に自動的にマウントするのではなく、リソースが必要な時にだけマウントすることを意味します。これは [[fstab#systemd による自動マウント]] で提供されています。

==== GPT パーティションの自動マウント ====

UEFI で起動したシステムでは、特定の条件が満たされると {{man|8|systemd-gpt-auto-generator}} は [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable Partitions Specification] に従って GPT パーティションを自動マウントし、[[fstab]] から省略することができるようになります。

前提条件は以下の通りです。

* ブートローダは [https://systemd.io/BOOT_LOADER_INTERFACE/ LoaderDevicePartUUID] EFI 変数を設定し、使用する EFI システムパーティションが特定できるようにする必要があります。これは [[systemd-boot]], {{man|7|systemd-stub}} と [[rEFInd#LoaderDevicePartUUID|rEFInd (not enabled by default)]] でサポートされています。これは {{ic|bootctl}} を実行して {{ic|Boot loader sets ESP information}} の状態をチェックすることによって確認できます。
* ルートパーティションは、使用する EFI システムパーティションと同じ物理ディスク上になければなりません。自動マウントされる他のパーティションは、ルートパーティションと同じ物理ディスク上になければなりません。これは基本的に、オートマウントされる全てのパーティションは ESP と同じ物理ディスクを共有していなければならないことを意味します。
* (必要であれば) {{ic|/efi}} マウントポイントは手動で作成する必要があります。存在しない場合、{{ic|systemd-gpt-auto-generator}} は {{ic|/boot}} を使用します。

{{Warning|GPT 自動マウントを使用している既存のシステムに {{ic|/efi}} を作成するときは、十分に注意してください。次回の起動時には {{ic|/efi}} がデフォルトのマウントポイントとして使用され、{{ic|/boot}} ディレクトリが空になってシステムが不整合状態になる可能性があります。恐らくカーネルとマイクロコードを再インストールしたり、initramfs を再生成したりする必要があるでしょう。}}

{{Tip|パーティションのオートマウントを無効にするには、パーティションの [[Wikipedia:GUID Partition Table#Partition type GUIDs|type GUID]] を変更するか、パーティション属性ビットを 63 "do not automount" に設定します、詳しくは [[gdisk#GPT パーティションの自動マウントを防ぐ]] を参照してください。}}

===== /var =====

{{ic|/var}} の自動マウントが動作するためには、PARTUUID がパーティションタイプの UUID ({{ic|4d21b016-b534-45c2-a9fb-5c16e091fd2d}}) の SHA256 HMAC ハッシュにマシン ID でキーを付けたものと一致している必要があります。必要な PARTUUID は、以下の方法で取得できます。

$ systemd-id128 -u --app-specific=4d21b016-b534-45c2-a9fb-5c16e091fd2d machine-id

{{Note|{{man|1|systemd-id128}}はマシンIDを{{ic|/etc/machine-id}} から読み取るので、システムをインストールする前に必要な PARTUUID を知ることは不可能です。}}

=== systemd-sysvcompat ===

{{Pkg|systemd-sysvcompat}} ({{Pkg|base}} の依存) の主な役割は、伝統的な linux [[init]] バイナリを提供することです。''systemd'' により制御されているシステムでは、{{ic|init}} はその {{ic|systemd}} 実行ファイルへのシンボリックリンクに過ぎません。

さらに、[[SysVinit]] のユーザーが慣れ親しんでいるであろう4つの便利なショートカットも提供されています。便利なショートカットは {{man|8|halt}}, {{man|8|poweroff}}, {{man|8|reboot}}, {{man|8|shutdown}} です。これら4つのコマンドはそれぞれ {{ic|systemctl}} へのシンボリックリンクであり、''systemd'' の動作に支配されます。そのため、[[#電源管理]] での議論が適用されます。

''systemd'' ベースのシステムは {{ic|1= init=}} [[カーネルパラメータ#パラメータ一覧|ブートパラメータ]] (例えば、[https://bbs.archlinux.org/viewtopic.php?id=233387 /bin/init is in systemd-sysvcompat ?]) と ''systemd'' ネイティブ {{ic|systemctl}} コマンド引数を使うことで、これらの System V 互換の方法を諦めることができます。

=== systemd-tmpfiles - 一時ファイル ===

''systemd-tmpfiles'' は揮発性ファイルや一時ファイル、ディレクトリの作成、削除、クリーンアップを行います。systemd-tmpfiles は {{ic|/etc/tmpfiles.d/}} と {{ic|/usr/lib/tmpfiles.d/}} にある設定ファイルを読んで、実行するアクションを決めます。前者のディレクトリにある設定ファイルは後者のディレクトリにある設定ファイルより優先されます。

設定ファイルは通常サービスファイルと一緒に提供され、{{ic|/usr/lib/tmpfiles.d/''program''.conf}} というスタイルで命名されます。例えば、[[Samba]] デーモンはディレクトリ {{ic|/run/samba}} が存在し、正しいパーミッションを持っていることを期待します。そのため、{{Pkg|samba}} パッケージはこの設定で出荷されます。

{{hc|/usr/lib/tmpfiles.d/samba.conf|
D /run/samba 0755 root root
}}

設定ファイルは、起動時に特定のファイルに値を書き込むために使用することもできます。例えば、{{ic|/etc/rc.local}} で USB デバイスからの wakeup を無効にするために {{ic|echo USBE > /proc/acpi/wakeup}} を使った場合、代わりに以下の tmpfile を使用することができます。

{{hc|/etc/tmpfiles.d/disable-usb-wake.conf|
# Path Mode UID GID Age Argument
w /proc/acpi/wakeup - - - - USBE
}}

詳しくは {{man|8|systemd-tmpfiles}} および {{man|5|tmpfiles.d}} のマニュアルページを参照してください。

{{Note|適切なモジュールのロードが完了するまでに systemd-tmpfiles-setup サービスが起動することがあるため、この方法は {{ic|/sys}} のオプションを設定するのには使えないかもしれません。この場合、{{ic|modinfo ''module''}} で設定したいオプションのパラメータがモジュールにあるかどうかを調べ、 [[カーネルモジュール#モジュールオプションを設定する|/etc/modprobe.d にある設定ファイル]] でそのオプションを設定することができます。そうでない場合は、デバイスが現れたらすぐに適切な属性を設定するように [[udev#udev ルールについて|udevルール]] を書く必要があります。}}

== ヒントとテクニック ==

=== ソケットアクティベーション ===

一部のパッケージには ''.socket'' ユニットが含まれています。例としては、{{Pkg|cups}} パッケージの {{ic|cups.socket}} ユニットがあります[https://0pointer.de/blog/projects/socket-activation2.html]。{{ic|cups.socket}} が[[有効化]]されると (なおかつ {{ic|cups.service}} を無効化しておくと)、''systemd'' は CUPS を即座には起動せず、適切なソケットをリッスンします。何らかのプログラムがそのソケットに接続しようとした際に初めて ''systemd'' が {{ic|cups.service}} を起動し、CUPS プロセスへのポートの制御を透過的に橋渡しします。

=== GUI 設定ツール ===

* {{App|systemadm|''systemd'' ユニット用のグラフィカルブラウザ。ユニットのリストを表示することができ、タイプでフィルタリングすることもできます。|https://cgit.freedesktop.org/systemd/systemd-ui/|{{Pkg|systemd-ui}}}}
* {{App|SystemdGenie|''systemd'' KDE 技術に基づく管理ユーティリティ。|https://invent.kde.org/system/systemdgenie|{{Pkg|systemdgenie}}}}

=== ネットワークが稼働した後にサービスを実行する ===

ネットワークが立ち上がった後までサービスを遅らせるには、以下の依存関係を ''.service'' ファイルに含めます。

{{hc|/etc/systemd/system/''foo''.service|2=
[Unit]
...
Wants=network-online.target
After=network-online.target
...
}}

ネットワークを管理する特定のアプリケーションのネットワーク待ち受けサービスも有効にして、{{ic|network-online.target}} がネットワークの状態を適切に反映するようにする必要があります。

* [[NetworkManager]] を利用している場合、{{ic|NetworkManager-wait-online.service}} は {{ic|NetworkManager.service}} と一緒に有効になっています。{{ic|systemctl is-enabled NetworkManager-wait-online.service}} で確認してください。有効になっていない場合は、{{ic|NetworkManager.service}} を [[systemd#ユニットを使う|再有効化]] してください。
* [[netctl]] の場合、{{ic|netctl-wait-online.service}} を [[systemd#ユニットを使う|有効化]] して下さい (''netctl-auto'' を使っていない場合。{{Bug|75836}} を参照してください)。
* [[systemd-networkd]] を利用している場合、{{ic|systemd-networkd-wait-online.service}} は {{ic|systemd-networkd.service}} と一緒に有効になっています。{{ic|systemctl is-enabled systemd-networkd-wait-online.service}} でこの状態にあるかどうか確認してください。有効になっていない場合は、{{ic|systemd-networkd.service}} を [[systemd#ユニットを使う|再有効化]] してください。

より詳しい説明は [https://systemd.io/NETWORK_ONLINE/#discussion ネットワーク設定の同期のポイント] の議論をご覧ください。

サービスが DNS クエリを実行する必要がある場合、追加で {{ic|nss-lookup.target}} の後に命令する必要があります。

{{hc|/etc/systemd/system/''foo''.service|2=
[Unit]
...
Wants=network-online.target
After=network-online.target nss-lookup.target
...
}}

{{man|7|systemd.special|Special Passive System Units}} を参照してください。

{{ic|nss-lookup.target}} が効果を発揮するためには、{{ic|1=Wants=nss-lookup.target}} で実行を要求して、{{ic|1=Before=nss-lookup.target}} で事前に実行されているように指定してあるサービスが必要です。通常、これはローカルの [[ドメイン名前解決|DNSリゾルバ]] によって行われます。

どのアクティブなサービスが {{ic|nss-lookup.target}} で実行を要求しているのかを確認してください。

$ systemctl list-dependencies --reverse nss-lookup.target

=== インストールされたユニットをデフォルトで有効にする ===

Arch Linux の {{ic|/usr/lib/systemd/system-preset/99-default.preset}} には {{ic|disable *}} と記述されています。systemctl プリセットがデフォルトで全てのユニットを無効化するようになり、新しいパッケージがインストールされたときも、ユーザーが手動でユニットを有効化する必要があります。

自動的に有効化させたい場合、{{ic|/etc/systemd/system-preset/99-default.preset}} から {{ic|/dev/null}} にシンボリックリンクを作成して設定ファイルを上書きしてください。systemctl プリセットの設定ディレクトリで指定しないかぎり、インストールされた全てのユニットが、ユニットのタイプに関わらず有効化されるようになります。詳しくは {{man|5|systemd.preset}} の man ページを参照。

{{Note|デフォルトで全てのユニットを有効化すると、パッケージに(互いに両立しない)複数のユニットが含まれている場合に問題が生じます。systemctl プリセットはディストリビューションやシステム管理者によって使われることを意図されて作られています。衝突するユニットが有効化されてしまう場合、{{ic|systemd.preset}} の man ページに書かれているように、プリセットの設定ファイルを使ってどちらか片方を明示的に無効化させる必要があります。}}

=== アプリケーション環境のサンドボックス化 ===
ユニットファイルをサンドボックスとして作成して堅牢な仮想環境にアプリケーションやプロセスを分離させることが可能です。systemd は[[wikipedia:Linux_namespaces|名前空間]]や、許可・拒否された [[ケイパビリティ]] のリスト、[[Cgroups]] を活用して実行環境を設定しプロセスをコンテナ化します—{{man|5|systemd.exec}}。

既存の systemd ユニットファイルを使ってアプリケーションをサンドボックス化するには {{Pkg|strace}}, [[wikipedia:ja:標準ストリーム#標準エラー出力 (stderr)|stderr]], [https://www.freedesktop.org/software/systemd/man/journalctl.html journalctl] などでエラーや出力を確認しながら試行錯誤が必要です。まずは上流のドキュメントを検索して先例がないか確認すると良いでしょう。堅牢にし得る選択肢の出発点を探すには、以下のコマンドを実行します。

$ systemd-analyze security ''unit''

''systemd'' をサンドボックス化するいくつかの例は以下にあります。

* {{ic|CapabilityBoundingSet}} は、ユニットに許可または拒否された {{man|7|capabilities}} のリストを定義します。{{man|5|systemd.exec|CAPABILITIES}} を参照してください。
** 例えば、[https://lwn.net/Articles/486306/ 安全なサンドボックスのゴール] の1つである {{Ic|CAP_SYS_ADM}} ケイパビリティ: {{ic|1=CapabilityBoundingSet=~ CAP_SYS_ADM}}

=== サービスの失敗を通知する ===

サービス障害を通知するためには、{{ic|1=OnFailure=}} ディレクティブを、例えば [[systemd# ドロップインファイル|ドロップイン設定ファイル]] を使用して、該当するサービスファイルに追加する必要があります。このディレクティブを各サービスユニットに追加するには、トップレベルのドロップイン設定ファイルを使用します。トップレベルのドロップインについて詳しくは {{man|5|systemd.unit}} を参照してください。

サービス用のトップレベルのドロップインを作成します。

{{hc|/etc/systemd/system/service.d/toplevel-override.conf|2=
[Unit]
OnFailure=failure-notification@%n
}}

これにより、すべてのサービスファイルに {{ic|1=OnFailure=failure-notification@%n}} が追加されます。''some_service_unit'' が失敗すると、{{ic|failure-notification@''some_service_unit''}}が開始されて通知(または実行するよう設定された任意のタスク)を処理するようになります。

テンプレートユニット {{ic|failure-notification@}} を作成します。

{{hc|/etc/systemd/system/failure-notification@.service|2=
[Unit]
Description=Send a notification about a failed systemd unit
After=network.target

[Service]
Type=simple
ExecStart=/''path''/''to''/failure-notification.sh %i
}}

{{ic|failure-notification.sh}} スクリプトを作成し、何をするか、どのように通知するか(メール、gotify、xmpp など)を定義します。{{ic|%i}} は失敗したサービスユニットの名前で、スクリプトの引数として渡されます。

起動に失敗した場合に、何度も {{ic|failure-notification@.service}} のインスタンスを起動する再帰を防ぐために、トップレベルのドロップインと同じ名前の空のドロップイン設定ファイルを作成します(空のサービスレベルのドロップイン設定ファイルはトップレベルのドロップインより優先され、後者をオーバーライドします。)

# mkdir -p /etc/systemd/system/failure-notification@.service.d
# touch /etc/systemd/system/failure-notification@.service.d/toplevel-override.conf

=== シャットダウン時に自動で外部HDDの電源を切る ===

もしシステムのシャットダウン時に外部 HDD の電源が正常に切れない場合は、その問題を修正することが望ましいでしょう。電源を切る最も便利な方法は [[udisks]] を使用することです。

{{ic|udisks2.service}} を [[有効化]] します。

スクリプトを実行するサービスは以下のようになります。

{{hc|/etc/systemd/system/handle_external_hdds.service|2=
[Unit]
Requires=udisks2.service
Requires=graphical.target
After=graphical.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/usr/local/bin/handle_external_hdds.sh
[Install]
WantedBy=graphical.target
}}

{{ic|handle_external_hdds.service}} を [[有効化]] します。

systemd の [[daemon-reload]] を実行して、新しい設定を適用します。

再起動するか {{ic|graphical.target}} をリスタートして、正常に動作するか確認します。

1つのディスクの任意の量のパーティションを扱うスクリプトの例は以下のようになります。

{{hc|/usr/local/bin/handle_external_hdds.sh|2=
#!/bin/bash -u

declare -a uuids=(''uuid_list'')

# Only proceed if the drive is present.
if <nowiki>[[ ! -L "/dev/disk/by-uuid/${uuids[0]}" ]]</nowiki>; then
exit 0
fi

for uuid in "${uuids[@]}"; do
if findmnt "/dev/disk/by-uuid/$uuid"; then
umount "/dev/disk/by-uuid/$uuid"
fi
done

# udisksctl powers off proper drive even if its partition is supplied
udisksctl power-off -b "/dev/disk/by-uuid/${uuids[0]}"
}}

''uuid_list'' はスペース区切りの UUID リストで、例えば {{ic|"''uuid_1''" "''uuid_2''"}} のように、チェックするデバイスのパーティションに対応します。

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

=== systemd のエラーを調査する ===

起動に失敗している systemd サービスを探すには以下のコマンドを実行します。

$ systemctl --state=failed

失敗している理由を探すには、ログ出力を調べてください。詳細は [[systemd/ジャーナル#フィルタリング]] を参照してください。

=== ブート問題の診断 ===

''systemd'' は、ブートプロセスの問題を診断するためのいくつかのオプションを提供しています。一般的な手順や、''systemd'' が [[ブートプロセス]] を引き継ぐ前のブートメッセージを残す方法については [[ブートデバッグ]] を参照してください。freedesktop.org の [https://freedesktop.org/wiki/Software/systemd/Debugging/ systemd デバッグドキュメント] も参照してください。

=== 特定のサービスの問題を診断 ===

ある systemd サービスが上手く動作せず、どうなっているのか詳しい情報が欲しい場合、環境変数 {{ic|SYSTEMD_LOG_LEVEL}} を {{ic|debug}} に設定してください。以下は systemd-networkd デーモンをデバッグモードで動かす例です:

サービスに [[#ドロップインファイル|ドロップインファイル]] を追加して、次の2行を追記してください。

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

あるいは、環境変数を手動でセットしても同じです。

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

その後 ''systemd-networkd'' を [[リスタート]] して、サービスのジャーナルを {{ic|-f}}/{{ic|--follow}} オプションで監視してください。

=== シャットダウン/再起動にものすごく時間がかかる ===

シャットダウンに非常に長い時間がかかる(もしくはフリーズする)場合、サービスが存在していないことが問題かもしれません。Systemd はサービスを kill する前に終了するのを待ちます。該当しているか確認するには、''systemd'' wiki の [https://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually Shutdown completes eventually] を参照してください。

一般的な問題は、シャットダウンやサスペントのプロセスが停止することです。該当するかどうか確かめるには、以下のどちらかのコマンドを実行して、出力を確認してください。

{{hc
|1=# systemctl poweroff
|2=Failed to power off system via logind: There's already a shutdown or sleep operation in progress
}}

{{hc
|1=# systemctl list-jobs
|2= JOB UNIT TYPE STATE
...
21593 systemd-suspend.service start running
21592 suspend.target start waiting
..
}}

これの [https://unix.stackexchange.com/a/579531 解決策] は、以下を実行してそれらのジョブをキャンセルすることです。

# systemctl cancel
# systemctl stop systemd-suspend.service

すると、シャットダウンやリブートをまた再開します。

=== 短いプロセスがログを出力しない ===

{{ic|journalctl -u foounit}} が短いプロセスについてなにも表示しない場合、かわりに PID を見て下さい。例えば、{{ic|systemd-modules-load.service}} が失敗したとき、{{ic|systemctl status systemd-modules-load}} によってそれが PID 123 として動いているとわかったら、その PID の journal の出力を見ることができます、{{ic|journalctl -b _PID=123}}。journal の {{ic|_SYSTEMD_UNIT}} や {{ic|_COMM}} などのメタデータは非同期に収集され {{ic|/proc}} ディレクトリにプロセスが存在している時だけ表示されます。これを修正するには、{{ic|SCM_CREDENTIALS}} のように、ソケット接続を使ってデータを流すようカーネルを変更する必要があります。簡単に言うと、これは [https://github.com/systemd/systemd/issues/2913 バグ] です。''systemd'' の設計によって、即座に失敗するサービスはジャーナルに何も出力しない場合があることを覚えておいてください。

===少しづつ起動時間が長くなっている===

{{ic|systemd-analyze}} を使用して、以前と比べて起動時間が明らかに伸びていると複数のユーザーが報告しています。{{ic|systemd-analyze blame}} を使って [[NetworkManager]] が起動するのに異常に長い時間かかるようになったという報告もあります。

問題の原因として {{ic|/var/log/journal}} が巨大になりすぎている可能性があります。そのような場合、フォルダ内のファイルを全て削除して journal のファイルサイズを[[systemd/ジャーナル#journal のサイズ制限|ここ]]に書かれているように制限するよう設定すれば解決します(できればファイルを削除する前に、どこかに一時的にバックアップしてください)。

=== 起動時に systemd-tmpfiles-setup.service の実行に失敗する ===

systemd 219 から、{{ic|/usr/lib/tmpfiles.d/systemd.conf}} は {{ic|/var/log/journal}} 下のディレクトリに対して ACL 属性を指定しており、それによって、ジャーナルが存在するファイルシステムで ACL のサポートを有効にしなくてはならなくなっています。

{{ic|/var/log/journal}} が存在するファイルシステムで ACL を有効化する方法は[[アクセス制御リスト#ACL の有効化]]を見て下さい。

=== リモートマシンで緊急モードを無効化 ===

リモートマシン (例えば Azure や Google Cloud でホストしている仮想マシン) の緊急モードは無効化すると良いでしょう。緊急モードが起動すると、ネットワークからマシンに接続できなくなってしまうからです。無効化するには以下のコマンドを実行:

# systemctl mask emergency.service
# systemctl mask emergency.target

== 参照 ==

* [[Wikipedia:systemd]]
* [https://systemd.io/ 公式ウェブサイト]
** [https://www.freedesktop.org/wiki/Software/systemd/Optimizations systemd の最適化]
** [https://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions systemd FAQ]
** [https://www.freedesktop.org/wiki/Software/systemd/TipsAndTricks systemd のヒントとテクニック]
* {{man|1|systemd}}
* その他のディストリビューション
** [[Gentoo:Systemd]]
** [[Fedora:Systemd]]
** [[Fedora:How to debug Systemd problems]]
** [[Fedora:SysVinit to Systemd Cheatsheet]]
** [[Debian:systemd]]
* [http://0pointer.de/blog/projects/systemd.html Lennart's blog story], [http://0pointer.de/blog/projects/systemd-update.html update 1], [http://0pointer.de/blog/projects/systemd-update-2.html update 2], [http://0pointer.de/blog/projects/systemd-update-3.html update 3], [http://0pointer.de/blog/projects/why.html summary]
* [https://containersolutions.github.io/runbooks/posts/linux/debug-systemd-service-units Systemd サービスのデバッグ]
* [http://0pointer.de/public/systemd-ebook-psankar.pdf 管理者向け systemd (PDF)]
* [https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units Systemctl を使用して Systemd サービスとユニットを管理する方法]
* [https://dvdhrm.wordpress.com/2013/08/24/session-management-on-linux/ systemd-logind によるセッション管理]
* [[Emacs#Syntax highlighting for systemd Files|Emacs Systemd ファイルの構文強調表示]]
* [http://www.h-online.com/open/features/Control-Centre-The-systemd-Linux-init-system-1565543.html Two] [http://www.h-online.com/open/features/Booting-up-Tools-and-tips-for-systemd-1570630.html part] ''The H Open'' 誌の紹介記事。

{{TranslationStatus|Systemd|2022-10-27|753672}}

Tor

2024-07-24T23:58:19Z

Libnumafly: /* Tor 出口ノードの実行 */ ガイドへのリンクを修正

[[Category:匿名ネットワーク]]
[[de:Tor]]
[[en:Tor]]
[[ru:Tor]]
[[zh-hans:Tor]]
{{Related articles start}}
{{Related|GNUnet}}
{{Related|I2P}}
{{Related|Freenet}}
{{Related articles end}}
[https://www.torproject.org Tor] (''T''he''o''nion''r''outing) は [[Wikipedia:ja:オニオンルーティング|オニオンルーティング]] のオープンソース実装で、匿名プロキシネットワークへのアクセスを提供します。Tor の目標は[[Wikipedia:Traffic analysis|トラフィック解析]]攻撃を防いで[[Wikipedia:ja:匿名#ネットワークにおける匿名|ネットワークの匿名性]]を守ることです。

Tor ネットワークのユーザーは、自分のマシン上でオニオンプロキシソフトウェアを実行し、SOCKS インターフェイスをクライアントに提供します。このソフトウェアは Tor に接続し、Tor ネットワークを通じて仮想回線を定期的にネゴシエートします。Tor は階層化された方法で暗号化を採用し (そのため、'オニオン' に例えられます)、ルーター間の前方秘匿性を確保します。

このプロセスを通じて、オニオンプロキシはエンドユーザーの匿名性を確保するためにネットワークトラフィックを管理します。トラフィックを暗号化し、Tor ネットワークの他のノードを介して送信し、指定したサーバーに転送する前にトラフィックを受信する最後のノードで復号化することで、ユーザーの匿名性を保ちます。トレードオフの 1 つは、Tor を使用すると、大量のトラフィックが再ルーティングされるため、通常の直接接続よりもかなり遅くなる可能性があることです。さらに、Tor はトラフィック分析に対する保護を提供しますが、Tor ネットワークの境界でのトラフィック確認 (つまり、ネットワークに出入りするトラフィック) を防ぐことはできません。詳細については、[[Wikipedia:ja:Tor|Tor (匿名ネットワーク)]] を参照してください。

{{Note|Tor だけでは、匿名性を維持するために必要なすべてが ''ある'' わけではありません。注意すべき大きな落とし穴がいくつかあります ([https://support.torproject.org/#faq_staying-anonymous Am I totally anonymous if I use Tor?] を参照)}}

== インストール ==

{{Pkg|tor}} パッケージを[[pacman|インストール]]してください。

Tor には Tor Browser でアクセスできます。{{AUR|tor-browser}} パッケージまたは [https://www.torproject.org/projects/torbrowser.html ポータブルな実行ファイル] でインストールできます。

{{AUR|arm}} (Anonymizing Relay Monitor) パッケージには帯域使用量や接続の詳細などをターミナルに表示するモニタが含まれています。

== 設定 ==

Tor をより深く理解するために、設定ファイルの {{ic|/etc/tor/torrc}} をよく見て下さい。設定オプションの説明は {{man|1|tor}} や [https://torproject.org/docs/tor-manual.html.en Tor のウェブサイト] で見られます。ほとんどの場合はデフォルト設定で問題なく Tor は動作します。

{{ic|torrc}} の設定と {{ic|tor.service}} の設定で衝突が発生する可能性があります:
* {{ic|torrc}} では、{{ic|RunAsDaemon}} はデフォルトどおりに {{ic|0}} に設定してください。{{ic|tor.service}} の {{ic|[Service]}} セクションで {{ic|Type<nowiki>=</nowiki>simple}} が設定されているためです。
* {{ic|torrc}} では、{{ic|User}} は設定しないでください。{{ic|tor.service}} の {{ic|[Service]}} セクションで {{ic|User<nowiki>=</nowiki>}} が {{ic|root}} に設定されているためです。

=== リレー設定 ===

Tor から開くことができるファイル記述子の最大数は {{ic|tor.service}} の {{ic|LimitNOFILE}} で設定できます。リレーを高速化したいときはこの数値を上げて下さい。

あなたのコンピュータでウェブサーバーを実行していない場合、{{ic|AccountingMax}} を設定する必要はありません。{{ic|ORPort}} を {{ic|443}} にしたり {{ic|DirPort}} を {{ic|80}} にすると良いでしょう。多くの Tor ユーザーはファイアウォールによって足止めされており、ウェブブラウズしかできないようになっていますが、この変更によってあなたの Tor リレーに到達できるようになります。既にポート {{ic|80}} と {{ic|443}} を使っている場合、他のポートとしては {{ic|22}}, {{ic|110}}, {{ic|143}} などが候補に挙げられています [https://www.torproject.org/docs/tor-relay-debian]。ただしこれらは特権が与えられたポートなので、{{ic|tor.service}} の {{ic|User<nowiki>=</nowiki>root}} と {{ic|torrc}} の {{ic|User tor}} を設定して、Tor を root で起動する必要があります。

詳しくは Tor ドキュメントの [https://blog.torproject.org/blog/lifecycle-of-a-new-relay Lifecycle of a New Relay] を読むことを推奨します。

=== Tor ControlPort を開く ===

ほとんどのユーザーはこれを必要としません。ただし、一部のプログラムは、Tor ノードへの低レベルのアクセスを取得するために、''あなたの Tor ControlPort'' を要求します。

ControlPort を介して、他のアプリケーションは Tor ノードを変更および監視して、Tor の実行中に Tor 設定を変更したり、Tor ネットワークのステータスや Tor 回線に関する詳細を取得したりできます。

{{ic|torrc}} ファイルに追加します

ControlPort 9051

Tor の [https://gitweb.torproject.org/torspec.git/tree/control-spec.txt control-spec.txt] より:
: For security, the [Tor control] stream should not be accessible by untrusted parties.

したがって、セキュリティを強化するために、ControlPort へのアクセスを制限します。
''Cookie ファイル''、や ''制御パスワード''、あるいはその両方を使用します。

==== Tor Control Cookie ファイルを設定する ====

{{ic|torrc}} に追加します

{{bc|
CookieAuthentication 1
CookieAuthFile /var/lib/tor/control_auth_cookie
CookieAuthFileGroupReadable 1
DataDirectoryGroupReadable 1
}}

''Cookie 認証'' を使用すると、ControlPort へのアクセスはファイル権限によって制限されます
Tor Cookie ファイルと Tor データディレクトリにコピーします。

上記の設定により、
{{ic|tor}} グループ内のすべてのユーザーが Tor Cookie ファイルにアクセスできます。

これらを {{ic|tor}} [[ユーザーグループ]] に追加します。

{{ic|tor.service}} を [[再起動]] して下さい。

これで、''ユーザー'' が Tor Cookie ファイルにアクセスできるようになります。

$ stat -c%a /var/lib/tor /var/lib/tor/control_auth_cookie

{{ic|750}} と {{ic|640}} を出力する必要があります。

==== Tor Control のパスワードを設定する ====

パスワードをプレーンテキストからハッシュに変換します

{{bc|
# set +o history # unset bash history
# tor --hash-password ''your_password''
# set -o history # set bash history
}}

そしてそのハッシュを {{ic|torrc}} に追加します

HashedControlPassword ''your_hash''

bash 履歴コマンドによりクリアテキストのパスワードが妨げられる場合
bash {{ic|$HISTFILE}} に書き込まれないようにします

==== Tor ControlSocket を開く ====

何らかのプログラムが Tor ControlSocket にアクセスする必要がある場合、
Unix ドメインソケットと同様、
以下を {{ic|torrc}} に追加します:

{{bc|
ControlSocket /var/lib/tor/control_socket
ControlSocketsGroupWritable 1
DataDirectoryGroupReadable 1
CacheDirectoryGroupReadable 1 # workaround for tor bug #26913
}}

プログラムを実行するユーザーを {{ic|tor}} [[ユーザーグループ]] に追加します

{{ic|tor.service}} を実行し、プログラムを [[再起動]] します。

ControlSocket のステータスを確認するには:

# stat -c%a /var/lib/tor /var/lib/tor/control_socket

{{ic|750}} と {{ic|660}} を出力する必要があります。

==== Tor Control をテストする ====

ControlPort をテストするには、次のコマンドを使用して {{Pkg|gnu-netcat}} を実行します。

$ echo -e 'PROTOCOLINFO\r\n' | nc 127.0.0.1 9051

ControlSocket をテストするには、次のコマンドを使用して {{Pkg|socat}} を実行します。

$ echo -e 'PROTOCOLINFO\r\n' | socat - UNIX-CLIENT:/var/lib/tor/control_socket

どちらのコマンドでも出力されるはずです

{{bc|1=
250-PROTOCOLINFO 1
250-AUTH METHODS=COOKIE,SAFECOOKIE,HASHEDPASSWORD COOKIEFILE="/var/lib/tor/control_auth_cookie"
250-VERSION Tor="0.3.4.8"
250 OK
514 Authentication required.
}}

その他のコマンドについては、Tor の [https://gitweb.torproject.org/torspec.git/tree/control-spec.txt control-spec.txt] を参照してください。

== Tor を Chroot で実行する ==

セキュリティを高めるために、[[Change Root|chroot]] で Tor を実行するのが望ましい場合があります。以下のスクリプトは {{ic|/opt/torchroot}} に適切な chroot を作成します:
{{hc|~/torchroot-setup.sh|2=<nowiki>
#!/bin/bash
export TORCHROOT=/opt/torchroot

mkdir -p $TORCHROOT
mkdir -p $TORCHROOT/etc/tor
mkdir -p $TORCHROOT/dev
mkdir -p $TORCHROOT/usr/bin
mkdir -p $TORCHROOT/usr/lib
mkdir -p $TORCHROOT/usr/share/tor
mkdir -p $TORCHROOT/var/lib

ln -s /usr/lib $TORCHROOT/lib
cp /etc/hosts $TORCHROOT/etc/
cp /etc/host.conf $TORCHROOT/etc/
cp /etc/localtime $TORCHROOT/etc/
cp /etc/nsswitch.conf $TORCHROOT/etc/
cp /etc/resolv.conf $TORCHROOT/etc/
cp /etc/tor/torrc $TORCHROOT/etc/tor/

cp /usr/bin/tor $TORCHROOT/usr/bin/
cp /usr/share/tor/geoip* $TORCHROOT/usr/share/tor/
cp /lib/libnss* /lib/libnsl* /lib/ld-linux-*.so* /lib/libresolv* /lib/libgcc_s.so* $TORCHROOT/usr/lib/
cp $(ldd /usr/bin/tor | awk '{print $3}'|grep --color=never "^/") $TORCHROOT/usr/lib/
cp -r /var/lib/tor $TORCHROOT/var/lib/
chown -R tor:tor $TORCHROOT/var/lib/tor

sh -c "grep --color=never ^tor /etc/passwd > $TORCHROOT/etc/passwd"
sh -c "grep --color=never ^tor /etc/group > $TORCHROOT/etc/group"

mknod -m 644 $TORCHROOT/dev/random c 1 8
mknod -m 644 $TORCHROOT/dev/urandom c 1 9
mknod -m 666 $TORCHROOT/dev/null c 1 3

if [[ "$(uname -m)" == "x86_64" ]]; then
cp /usr/lib/ld-linux-x86-64.so* $TORCHROOT/usr/lib/.
ln -sr /usr/lib64 $TORCHROOT/lib64
ln -s $TORCHROOT/usr/lib ${TORCHROOT}/usr/lib64
fi</nowiki>}}

このスクリプトを root で実行した後、次のコマンドで [[Change Root|chroot]] に Tor を起動できます: {{ic|# chroot --userspec=tor:tor /opt/torchroot /usr/bin/tor}}

== 使用方法 ==

[[systemd#ユニットを使う|systemd]] を使って {{ic|tor.service}} を起動・有効にしてください。

もしくは、vidalia インターフェースからも tor を起動できます。

プログラムに Tor を通すには、SOCKS5 プロキシとして 127.0.0.1 か localhost をポート 9050 (tor の標準設定) 又は 9051 ('''vidalia''' の標準設定) で使うようにプログラムを設定してください。
Tor が正しく機能しているか確認するために [https://check.torproject.org/ Tor] , [http://serifos.eecs.harvard.edu/cgi-bin/ipaddr.pl?tor=1 Harvard] , [https://torcheck.xenobite.eu/ Xenobite.eu] などのウェブサイトを開いてみましょう。

== ウェブブラウズ ==

匿名でブラウズする唯一の方法は、サポートされている ''Tor Browser Bundle'' を使用することで、パッチが適用されたバージョンの [[Firefox]] を使用します。{{Pkg|torbrowser-launcher}} パッケージや {{AUR|tor-browser}} パッケージでインストールすることができます。

Tor は通常のブラウザでも使用できます: [[#Firefox]] や [[#Chromium]] を参照して、Tor ネットワークを通してこれらのブラウザを実行してください。これは「プライベートブラウジング」モードであっても匿名でブラウジングする方法ではないことに注意してください: フィンガープリント、プラグイン、DNS リークやその他の欠点により、あなたの IP アドレスや身元が判明する可能性があります。[https://www.torproject.org/docs/faq.html.en#TBBOtherBrowser]

{{Tip|makepkg が Tor ブラウザの AUR ソース tarball ダウンロードで署名を検証するには、[[GnuPG#鍵サーバーを使用する]] で説明されているように、[https://www.torproject.org/docs/signing-keys.html.en Tor プロジェクトから署名キー]をインポートします。}}

=== Firefox ===

''設定 > 一般 > ネットワークプロキシ > 接続設定'' から SOCKS の {{ic|localhost}} ポート {{ic|9050}} を使うように手動で Firefox を設定してください (SOCKS v5)。さらに、全ての DNS リクエストが TOR の socks プロキシを通過するようにするため、"Proxy DNS when using SOCKS v5" を選択してください。

=== Chromium ===

次のコマンドで chromium を起動してください:
$ chromium --proxy-server="socks5://myproxy:8080" --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE myproxy"

{{ic|<nowiki>--proxy-server="socks5://myproxy:8080"</nowiki>}} フラグによって Chrome は http:// と https:// の URL リクエストで SOCKS プロキシサーバー "myproxy:8080" を経由するようになります (バージョン 5 の SOCKS プロトコルを使用)。URL のホストネームはプロキシサーバーによって解決されるようになります。

{{Note|{{ic|ftp://}} から始める URL はまだ SOCKS プロキシでは使用できません [https://www.chromium.org/developers/design-documents/network-stack/socks-proxy]。}}

{{ic|--proxy-server}} フラグは URL のロードだけに適用されます。Chrome の他のコンポーネントが DNS を直接使うこともあり、その場合はプロキシサーバーが迂回されてしまいます。そのようなコンポーネントとして例えば "DNS prefetcher" が存在します。Chrome で DNS プリフェッチが無効になっていない場合、SOCKS v5 プロキシサーバーを設定していても Chrome によって DNS リクエストが送信されてしまいます。DNS プリフェッチを無効化することで解決するとしても、Chrome の DNS リクエスト全てに気を配らなくてはいけません。{{ic|<nowiki>--host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE myproxy"</nowiki>}} フラグを使うことで Chrome から送信される全ての DNS リクエストを阻止できます。DNS リクエストは全て {{ic|~NOTFOUND}} ({{ic|0.0.0.0}} と同じ) アドレスにマッピングされます。"EXCLUDE" で "myproxy" だけ例外にすることで、SOCKS プロキシサーバーのアドレスだけは解決できるようにします。

[https://ipleak.net/#webrtcleak WebRTC のリーク] を防ぐには [https://chrome.google.com/webstore/detail/webrtc-network-limiter/npeicpdbkakmehahjeeohfdhnlpdklia WebRTC Network Limiter] 拡張をインストールします。

==== デバッグ ====

デバッグする際はまず about:net-internals の Proxy タブを確認してください: {{ic|chrome://net-internals/#proxy}}。

次に、{{ic|about:net-internals}} で Chrome がローカル DNS リクエストを送信していないことを確認してください: {{ic|chrome://net-internals/#dns}}。

==== 拡張 ====

Firefox と同じように [https://chrome.google.com/webstore/detail/dpplabbmogkhghncfbfdeeokoefdjegm Proxy SwitchySharp] を使うことで高速な切り替えをすることができます。

インストールしたら設定ページを開いて下さい。''Proxy Profiles'' タブから新しいプロファイル ''Tor'' を追加します。''Use the same proxy server for all protocols'' オプションのチェックが入っている場合はチェックを外してください。それから SOCKS ホストに ''localhost''、ポートに ''9050'' を追加して ''SOCKS v5'' を選択します。

任意で ''General'' タブからクイック切り替えを有効化することができ、Proxy SwitchySharp のアイコンを左クリックするだけで通常のブラウズと Tor ネットワークを切り替えることができるようになります。

==== Electron ====

[[#Chromium]] を参照してください。

=== Luakit ===

次を実行:
$ torsocks luakit

== HTTP プロキシ ==

Tor は [[Polipo]] や [[Privoxy]] などの HTTP プロキシと一緒に使うことができますが、Tor の開発チームはブラウザが直接サポートしている SOCKS5 ライブラリを使うことを推奨しています。

=== Firefox ===

[https://addons.mozilla.org/en-us/firefox/addon/foxyproxy-standard/ FoxyProxy] アドオンを使うことで URL に合わせて複数のプロキシを指定したりすることができます。Firefox を再起動したら手動で Firefox を [[Polipo]] や [[Privoxy]] が動作しているポート {{ic|8118}} の {{ic|localhost}} に設定してください。これらの設定は ''Add > Standard proxy type'' から設定できます。プロキシのラベル (例: Tor) を選択してポートとホストを ''HTTP Proxy'' と ''SSL Proxy'' フィールドに入力してください。Tor が正しく機能しているかどうかは [https://check.torproject.org/ Tor Check] ウェブサイトを開くことで確認できます。

=== Polipo ===

Tor Project は Polipo の問題を回避して匿名性を上げるためにカスタマイズされた [https://gitweb.torproject.org/torbrowser.git/plain/build-scripts/config/polipo.conf?id=1ffcd9dafb9dd76c3a29dd686e05a71a95599fb5 Polipo 設定ファイル] を作成しています。

SOCKS 5 プロキシが使える場合、Tor は自動的にポート 9050 で起動するので、Polipo は必須ではないことを覚えておいて下さい。Tor で [[Chromium]] を使いたい場合、Polipo パッケージは必要ありません (参照: [[#Chromium]])。

=== Privoxy ===

メッセンジャーなど (例: Jabber, IRC) 他のアプリケーションでセットアップを使うこともできます。アプリケーションが HTTP プロキシをサポートしていれば Privoxy に接続することができます ({{ic|127.0.0.1:8118}})。直接 SOCKS プロキシを使うには、アプリケーションから Tor を指定します ({{ic|127.0.0.1:9050}})。この方法の問題はアプリケーションが DNS 解決を独自に行うような場合、情報が漏洩する可能性があるということです。代わりに (Privoxy なおで) Socks4A を使用してください。

== インスタントメッセージ ==

IM クライアントで tor を使う場合、[[polipo]]/[[privoxy]] などの http プロキシは必要ありません。デフォルトでポート 9050 を listen する tor のデーモンを直接使用します。

=== Pidgin ===

Pidgin を設定することで全てのアカウントで、あるいはアカウントごとに Tor を使うようにすることができます。全てのアカウントで Tor を使うには Tools -> Preferences -> Proxy で設定してください。アカウントごとに Tor を使用するには ''Accounts > Manage Accounts'' からアカウントを選択して Modify をクリックし、Proxy タブを開いてください。以下のようにプロキシを設定します:

Proxy type SOCKS5
Host 127.0.0.1
Port 9150

Tor Browser を使用している場合 [https://trac.torproject.org/projects/tor/ticket/8135 2013年] にポートは 9050 から 9150 に変更されたので注意してください。"Connection refused" メッセージが表示される場合は値を変えてみてください。

== Irssi ==

Freenode は {{ic|.onion}} に直接接続することを推奨しています。接続時に nickserv で認証するには charybdis と ircd-seven の SASL が必要です。[[Irssi#SASL で認証]] を参照してください。irssi を起動:

$ torsocks irssi

nickserv に認証情報を設定してください。接続時に読み込まれます。対応している認証方式は ECDSA-NIST256P-CHALLENGE ([https://github.com/atheme/ecdsatool/blob/master/cap_sasl.pl ecdsatool] を参照) と PLAIN です。DH-BLOWFISH は [https://freenode.net/sasl/sasl-irssi.shtml サポートが打ち切られています]。

/sasl set ''network'' ''username'' ''password'' ''mechanism''

情報漏洩を防ぐために CTCP と DCC を無効化してホストネームを別の名前に設定してください [https://encrypteverything.ca/IRC_Anonymity_Guide]:

/ignore * CTCPS
/ignore * DCC
/set hostname ''fake_host''

Freenode に接続:

/connect -network ''network'' frxleqtzgvwkv7oz.onion

詳しくは [http://freenode.net/irc_servers.shtml#tor Accessing freenode Via Tor], [http://freenode.net/sasl/README.txt SASL README], [https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO/IrcSilc IRC/SILC Wiki article] を見て下さい。

== Pacman ==

Pacman のダウンロード操作 (リポジトリ DB, パッケージ, パブリックキー) を Tor ネットワークを通して行うことが可能です。やや大げさですが、もしあなたに (LAN やミラーなどに) 敵がいる場合、インストールしたパッケージが何なのか知られることがなくなります。ただし遅延がひどくなり、スループットが遅くなり、気づかれる可能性があり、(現在の接続で Tor がフィルタリングされている場合) インストールができない可能性があります。

{{Warning|It would be arguably simpler for an adversary, specifically one who desires to indiscriminately disseminate malware, to perform his/her activity by deploying malicious Tor exit node(s). Always use signed packages and verify new public keys by out-of-band means.}}

{{hc|/etc/pacman.conf|
...
<nowiki>XferCommand = /usr/bin/curl --socks5-hostname localhost:9050 -C - -f %u > %o</nowiki>
...}}

== Tor サーバーを実行する ==

Tor ネットワークは人々が提供する帯域に頼っています。ネットワークに貢献する方法は複数あります。

=== Tor ブリッジの実行 ===

Tor ブリッジは Tor のパブリックディレクトリに記載されない Tor リレーです。政府や ISP によって Tor のパブリックリレーが全てブロックされたときでも Tor ネットワークに接続することを可能にします。

==== 設定 ====

https://www.torproject.org/docs/bridges によれば、torrc ({{ic|/etc/tor/torrc}} または {{ic|$HOME/.torrc}}) に以下の4行を設定してください:

SocksPort 0
ORPort 443
BridgeRelay 1
Exitpolicy reject *:*

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

起動時に "Could not bind to 0.0.0.0:443: Permission denied" エラーが表示される場合、ORPort を高く設定するか (例: 8080)、ルーターで [http://www.portforward.com/ ポート転送] してください。

=== Tor リレーの実行 ===

あなたのマシンを (リレーのオンライン時間によって) エントリーノードや転送リレーとして動作させます。ブリッジリレーとは違って、Tor のパブリックディレクトリに記載されます。誰でも Tor のディレクトリからあなたの IP アドレスを見ることができるようになりますが、このリレーは他のリレーや Tor 出口ノードに転送するだけで、インターネットに直接転送することはありません。

==== 設定 ====

最低でも 20KiB/s は共有してください:
Nickname ''tornickname''
ORPort 9001
BandwidthRate 20 KB # Throttle traffic to 20KB/s
BandwidthBurst 50 KB # But allow bursts up to 50KB/s

リレーからの退出を拒否する:
ExitPolicy reject *:*

=== Tor 出口ノードの実行 ===

Tor ユーザーから通常のインターネットへのリクエストがあった場合、ネットワークへの出口 (出口ノード) が必要となります。出口ノードからアクセスされたホストから見ると、あなたのマシンからリクエストが飛んできたように認識されます。したがって、Tor リレーを運営するのとは異なり、出口ノードを立ち上げることは法的な責任を負うことを意味します。出口リレーを実行する前に [https://blog.torproject.org/tips-running-exit-node/ Tips for Running an Exit Node] を読むと良いでしょう。

==== 設定 ====

torrc を使うことで、出口ノードを通過できるサービスを設定することができます。

全てのトラフィックを許可:
ExitPolicy accept *:*

irc ポート 6660-6667 だけがノードから退出することを許可する:
ExitPolicy accept *:6660-6667,reject *:* # Allow irc ports but no more

デフォルトでは、Tor は特定のポートをブロックします。torrc を使うことで上書きすることが可能です:
ExitPolicy accept *:119 # Accept nntp as well as default exit policy

== TorDNS ==

Tor 0.2.x シリーズには DNS フォワーダが組み込まれています。有効化するには、以下の行を Tor の設定ファイルに追加してデーモンを再起動してください:
{{hc|/etc/tor/torrc|
DNSPort 9053
AutomapHostsOnResolve 1
AutomapHostsSuffixes .exit,.onion
}}

上記の設定で通常の DNS サーバーと同じように DNS リクエストを受け取って (上記の例ではポート 9053 を使用)、Tor ネットワーク経由でドメインを解決できるようになります。解決できる DNS クエリは A レコードなので注意してください。MX と NS クエリには返答しません。詳しくは [https://techstdout.boum.org/TorDns/ Debian によるイントロダクション] を参照。

{{Ic|<nowiki>tor-resolve</nowiki>}} を使ってコマンドラインインターフェイスから DNS クエリを実行することもできます。例:
{{bc|
$ tor-resolve archlinux.org
66.211.214.131
}}

=== 全ての DNS クエリで TorDNS を使う ===

必要であれば、宛先に Tor を使って接続するのかどうかにかかわらず、システムからのクエリは全て TorDNS を使うように設定することができます。DNS サーバーとして 127.0.0.1 を使うように設定してから {{ic|/etc/tor/torrc}} の 'DNSPort' 行を以下のように編集してください:
DNSPort 53
また、[[dnsmasq]] や [[pdnsd]] などのローカルキャッシュ DNS サーバーを使うこともできます。TorDNS は伝統的な DNS サーバーと比べて少し遅いのでそれを補うことができます。以下では ''dnsmasq'' をセットアップする方法を説明します。

DNS リクエストを listen する設定をポート 9053 に変更して {{Pkg|dnsmasq}} をインストールしてください。

dnsmasq の設定ファイルを以下のように編集:
{{hc|/etc/dnsmasq.conf|
no-resolv
port=9053
server=127.0.0.1#9053
listen-address=127.0.0.1
}}

上記の設定によって dnsmasq はローカルコンピュータからのリクエストのみ受け取り、TorDNS を上流の DNS サーバーとして使用します。それから {{ic|/etc/resolv.conf}} を編集して dnsmasq サーバーに問い合わせを行うようにしてください:

{{hc|/etc/resolv.conf|
nameserver 127.0.0.1
}}
設定したら '''dnsmasq''' デーモンを起動してください。

''dhcpd'' を使用している場合、resolv 設定ファイルが変更されないように設定を変更する必要があります。設定ファイルに以下を追加してください:
{{hc|/etc/dhcpcd.conf|
nohook resolv.conf
}}
''nohook'' 行が既に存在する場合、カンマで区切って '''resolv.conf''' を追加してください。

== Torsocks ==

'''Torsocks''' を利用すると、アプリケーションの設定を変更することなく、Tor ネットワークを介してアプリケーションを使うことができるようになります。man ページより:

:''torsocks は全てのインターネット接続を Tor ネットワーク経由にするために torsocks ライブラリとアプリケーションの間に挟まるラッパーです。''

使用例:

$ torsocks elinks checkip.dyndns.org
<nowiki>$ torsocks wget -qO- https://check.torproject.org/ | grep -i congratulations</nowiki>

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

=== Problem with user value ===

'''tor''' デーモンが起動しない場合、root で次のコマンドを実行してください (もしくは sudo を使用):

# tor

以下のエラーが表示される場合:

May 23 00:27:24.624 [warn] Error setting groups to gid 43: "Operation not permitted".
May 23 00:27:24.624 [warn] If you set the "User" option, you must start Tor as root.
May 23 00:27:24.624 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
May 23 00:27:24.624 [err] Reading config failed--see warnings above.

User の値に問題があるとは {{ic|/var/lib/tor}} ディレクトリにあるファイルやディレクトリの所有者が tor になっていないことを意味します。以下の find コマンドで確認できます:

find /var/lib/tor/ ! -user tor

上記のコマンドで出力されたファイルあるいはディレクトリの所有者を変更する必要があります。ファイルごとに所有者を変更するには:

chown tor:tor /var/lib/tor/filename

もしくは上の find コマンドで出力されたファイルの所有権を全て変更するには:

find /var/lib/tor/ ! -user tor -exec chown tor:tor {} \;

これで Tor が正しく起動するようになるはずです。

修正しても tor サービスを起動できない場合、root でサービスを起動してみてください (tor ユーザーに切り替わります)。{{ic|/etc/tor/torrc}} ファイルの user の名前を変更します:

User tor

systemd の tor サービスファイル {{ic|/usr/lib/systemd/system/tor.service}} を以下のように修正:

[Service]
User=root
Group=root
Type=simple

プロセスは tor ユーザーで実行されます。ユーザーとグループ ID を tor に変更して書き込み可能にしてください:

# chown -R tor:tor /var/lib/tor/
# chmod -R 755 /var/lib/tor

変更を保存したらデーモンを起動:

# systemctl --system daemon-reload
# systemctl start tor.service

=== Tor-ブラウザのプロキシ問題 ===

通常、{{AUR|tor-browser-bin}} は大幅なカスタマイズなしで動作します。以前にインストール/構成されバンドルされたプロキシが、いずれかの Web サイトで {{ic|proxy server is refusing connections}} というエラーで失敗した場合は、{{ic|~/.tor-browser}} ディレクトリを移動または削除して設定をリセットすることを検討してください。

=== Tor-ブラウザの空白の黒い画面 ===

[[AppArmor]] を使用している場合は、必要なリソースへのアクセスを許可するように torbrowser プロファイルを更新して下さい。[https://unix.stackexchange.com/questions/550074/debian-tor-browser-showing-a-black-screen/550246#550246 ]、[https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=942901]:

{{hc|head= /etc/apparmor.d/local/torbrowser.Browser.firefox|output=
owner /{dev,run}/shm/org.mozilla.*.* rw,
}}

== 参照 ==

* [https://www.torproject.org/docs/tor-doc-unix.html.en Running the Tor client on Linux/BSD/Unix]
* [https://trac.torproject.org/projects/tor/wiki#Unixish Unix-based Tor Articles]
* [https://trac.torproject.org/projects/tor/wiki/doc/SupportPrograms Software commonly integrated with Tor]
* [https://www.torproject.org/docs/tor-hidden-service.html.en How to set up a Tor ''Hidden Service'']
* [https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports List of tor pluggable transports for obfuscating tor's traffic]

Postfix と SASL

2024-04-08T05:05:55Z

Libnumafly: /* イントロダクション */ ブラケット抜けを修正

[[Category:メールサーバー]]
[[en:Postfix with SASL]]
{{Related articles start}}
{{Related|Postfix}}
{{Related|Dovecot}}
{{Related articles end}}
[http://www.postfix.org/SASL_README.html Postfix のサイト] より:

:''わざわざ Postfix をインストールする人たちは、Postfix が他のメーラよりもセキュアであると思っていることでしょう。Cyrus SASL ライブラリは大量のコードで成り立っています。Postfix SMTP クライアントや SMTP サーバで SASL 認証を有効にしても、 Postfix は Cyrus SASL ライブラリを使う他のメールシステムと同程度にしかセキュアになりません。Dovecot は検討に値するかもしれない代替策を提供しています。''

==イントロダクション==

この記事では [[Postfix]] で SASL 認証をセットアップする方法を説明します。

Postfix を立ち上げたら SASL 認証を追加することでリレーをなくすことができます。認証を通過した信頼できるユーザーだけがメールを送ることができるようになります。匿名ユーザーによってスパムが作成されるのを防げます。

[[extra]] に入っている {{pkg|postfix}} パッケージは既に SASL のサポートを有効にしてコンパイルされているので、SASL 認証を使う場合、2つの選択肢があります:

*{{pkg|cyrus-sasl}} パッケージを使う。
*[[Dovecot]] を有効にして (Dovecot の認証だけでなく) Postfix の認証を処理させる。

==cyrus-sasl パッケージの設定==

[[公式リポジトリ]]から {{pkg|cyrus-sasl}} を[[インストール]]してください。

SASL を有効にして他のユーザーからのメールを承認するには、{{ic|/etc/postfix/master.cf}} で (デフォルトで存在するがコメントアウトされている) 以下の行をアンコメントして [https://tools.ietf.org/html/rfc6409 "Message submission"] ポート (TCP 587) を開きます:
{{bc|<nowiki>
submission inet n - n - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
# -o smtpd_client_restrictions=$mua_client_restrictions
# -o smtpd_helo_restrictions=$mua_helo_restrictions
# -o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
</nowiki>}}

上記の設定では SSL も有効になるので、SSL 証明書を持っていない場合は、"smtpd_tls_security_level" オプションはコメントアウトされたままにしてください。

3つの制限オプション (client, helo, sender) もコメントアウトしたままにできます。smtpd_recipient_restrictions は既に SASL ユーザーを処理するからです。

通常通りに Postfix をセットアップして[[起動]]します。ブート時に起動するようにしたいときは[[有効化]]してください。

SASL は複数の認証方式を使うことができます。デフォルトの認証方式は PAM ({{ic|/etc/conf.d/saslauthd}} で設定) ですが、正しくセットアップするには {{ic|/usr/lib/sasl2/smtpd.conf}} を作成する必要があります:

{{bc|
pwcheck_method: saslauthd
mech_list: plain
log_level: 7
}}

{{pkg|pambase}} 20190105.1-1 以降では "other" サービスに対して制限付きのフォールバックが適用される [https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/pambase&id=3552aba772e8bebbe754a4d01f2729e291dd2070] ので、 Postfix で SASL 認証を使うにはこれに加えて [[PAM]] の設定ファイルを作成する必要があります [https://bugs.archlinux.org/task/61700][https://bbs.archlinux.org/viewtopic.php?pid=1824850] 。

以下の内容で {{ic|/etc/pam.d/smtp}} を作成:

{{bc|<nowiki>
#%PAM-1.0
auth required pam_unix.so
account required pam_unix.so
</nowiki>}}

postfix と saslauthd サービスを[[再起動]]してください。

上手く行っていれば、次のコマンドで Postfix サーバーに telnet できるはずです: {{ic|telnet localhost 587}}。

それから、次のコマンドを入力してください: {{ic|EHLO test.com}}。

以下のように表示されるはずです:

{{bc|
Trying 127.0.0.1...

Connected to localhost.localdomain
Escape character is '^]'

220 justin ESMTP Postfix
EHLO test.com
250-justin
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN OTP DIGEST-MD5 CRAM-MD5
250 8BITMIME
}}

==Dovecot の設定==

IMAP や POP メールサーバーとして [[Dovecot]] を使っていて既に (PAM などで) 認証を設定している場合、他のパッケージを設定する必要はありません。

{{ic|/etc/postfix/master.cf}} を編集して {{ic|submission}} または {{ic|smtp}} セクションの下に以下の行を追加してください:

{{bc|<nowiki>
# SASL authentication with dovecot
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous
-o smtpd_sasl_local_domain=$myhostname
-o smtpd_client_restrictions=permit_sasl_authenticated,reject
-o smtpd_recipient_restrictions=reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_sasl_authenticated,reject
</nowiki>}}

上記の設定で、認証を受けたユーザーだけがメールを送信できるようになります。{{ic|smtpd_client_restrictions}} がそれです。

以下を Dovecot 設定ファイル {{ic|/etc/dovecot/dovecot.conf}} に追加してください:

{{bc|<nowiki>
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
user = root
}
</nowiki>}}

{{ic|master.cf}} の {{ic|smtpd_sasl_path}} オプションで指定したのと同じ {{ic|/var/spool/postfix/private/auth}} に unix ソケットが作成されます。

最後に postfix と dovecot サービスを[[再起動]]してください。

==参照==

*Postfix 公式ドキュメントの [http://www.postfix.org/SASL_README.html Postfix SASL readme]
*Dovecot 公式ドキュメントの [https://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL SASL authentication with Dovecot]
*[http://wiki.centos.org/HowTos/postfix_sasl Centos Howto Postfix SASL]

Dd

2023-11-05T19:05:59Z

Libnumafly: 閉じ忘れられたヒントブロックを修正

{{Lowercase title}}
[[Category:コマンド]]
[[de:Dd]]
[[en:Dd]]
[[es:Dd]]
[[pt:Dd]]
[[ru:Dd]]
{{Related articles start}}
{{Related|ディスクのクローン}}
{{Related|USB インストールメディア#基本的なコマンドラインユーティリティを使う}}
{{Related|ベンチマーク#dd}}
{{Related|ディスクの完全消去#dd}}
{{Related articles end}}

[[Wikipedia:ja:dd (Unix)|dd]] はファイルの変換とコピーを主な目的とする [[Core utilities|コアユーティリティ]] です。

''cp'' と同様にデフォルトでは ''dd'' はファイルのビットごとのコピーを作成しますが、低レベルの I/O フロー制御機能を備えています。

詳細は、{{man|1|dd}} または[https://www.gnu.org/software/coreutils/dd フルドキュメント]を参照してください。

{{Tip|デフォルトでは、''dd'' はタスクが完了するまで何も出力しません。操作の進行状況を監視するには、コマンドに {{ic|1=status=progress}} オプションを追加します。}}

{{Warning|この種のコマンドはどれも、データを不可逆的に破壊する可能性があるため、''dd'' の使用には細心の注意を払う必要があります。}}

== インストール ==

''dd'' は GNU {{Pkg|coreutils}} の一部です。このパッケージ内の他のユーティリティについては、[[Core utilities]] を参照してください。

== ディスクの複製と復元 ==

''dd'' コマンドはシンプルでありながら多機能で強力なツールです。ファイルシステムの種類や OS に関係なく、コピー元からコピー先へブロック単位でコピーすることができます。ライブ CD のようなライブ環境から ''dd'' を使用するのが便利です。

{{Warning|このタイプのコマンドと同様に使用時には十分な注意が必要です。さもないと、データが破壊される可能性があります。入力ファイル ({{ic|1=if=}}) と出力ファイル ({{ic|1=of=}}) の順番を覚えておいて、逆にしないでください。出力先のドライブやパーティション ({{ic|1=of=}}) のサイズが、入力元 ({{ic|1=if=}}) と同じかそれ以上である事を常に確認してください。
}}

=== パーティションの複製 ===

物理ディスク {{ic|/dev/sda}} のパーティション 1 から、物理ディスク {{ic|/dev/sdb}} のパーティション 1 へ:

# dd if=/dev/sda1 of=/dev/sdb1 bs=64K conv=noerror,sync status=progress

{{Note|出力パーティション {{ic|1=of=}} (この例では {{ic|sdb1}}) が存在しない場合、''dd'' はこの名前のファイルを作成し、ルートファイルシステムをいっぱいにしてしまうので注意が必要です。}}

=== ハードディスク全体の複製 ===

物理ディスク {{ic|/dev/sda}} から物理ディスク {{ic|/dev/sdb}} へ:

# dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync status=progress

このコマンドは、パーティションテーブル、ブートローダー、すべてのパーティション、UUID、データを含むドライブ全体を複製します。

* {{ic|1=bs=}} はブロックサイズを設定します。デフォルトは512バイトで、これは1980年代前半以降のハードドライブの「古典」的なブロックサイズですが、最も便利なものではありません。64KBや128KBなど、より大きな値を使用してください。また、「ブロックサイズ」だけでなく、読み取りエラーの伝搬にも影響を与えるため、下記の警告をお読みください。詳細は、[https://www.mail-archive.com/eug-lug@efn.org/msg12073.html] と [http://blog.tdg5.com/tuning-dd-block-size/] を参照して、最適な bs 値を見つけてください。
* {{ic|noerror}} はすべての読み取りエラーを無視して操作を続けるように ''dd'' に指示します。''dd'' のデフォルトの動作は、いかなるエラーでも停止します。
* {{ic|sync}} は読み込みエラーがあった場合、入力ブロックをゼロで埋め、データのオフセットは同期されたままになります (読み込みエラーが疑われる場合、sync を用いた際の読み込みエラーの挙動に関する下記の詳細な説明を見てください)。
* {{ic|1=status=progress}} は、操作がいつ完了するかを推測するために使用できる転送統計を表示します。

{{Note|指定するブロックサイズは、読み取りエラーの処理方法に影響します。以下をお読みください。データの回復には、[[ディスクのクローン#ddrescue を使う|ddrescue]] を使用してください。}}

''dd'' ユーティリティには、技術的には「入力ブロックサイズ」（IBS）と「出力ブロックサイズ」（OBS）があります。{{ic|bs}} を設定すると、実質的に IBS と OBS の両方を設定することになります。通常、ブロックサイズが例えば 1MiB の場合、dd は 1024×1024 バイトを読み込み、同じバイト数を書き込みます。しかし、読み取りエラーが発生すると、事態はおかしくなります。多くの人は、{{ic|noerror,sync}} オプションを使うと、dd が「読み込みエラーをゼロで埋める」と思っているようですが、そうではありません。ドキュメントによると、dd は読み込み完了後に OBS から IBS のサイズを埋める、つまりブロックの最後にゼロを追加するのです。つまり、ディスクの場合、512 バイトの読み取りエラーが読み取りの最初に1回発生しただけで、事実上 1MB 全体がめちゃくちゃになってしまうのです: 12ERROR89 は 120000089 ではなく 128900000 となります。

ディスクにエラーがないことが確認できれば、ブロックサイズを大きくしてコピーを進めることができ、コピーの速度が数倍向上します。例えば、Celeron 2.7GHz のシステムで、bs を 512 から 64K に変更すると、コピー速度が 35MB/s から 120MB/s になります。ただし、コピー元のディスクで発生した読み取りエラーは、コピー先のディスクではブロックエラーとして発生することに注意してください。つまり、512バイトのリードエラーは、出力先の 64 KiB ブロック全体をめちゃくちゃにします。

{{Tip|''dd'' の進行状況を表示するためには、{{ic|1=status=progress}} オプションを使用してください。詳細については、{{man|1|dd}} を参照してください。}}

{{Note|
* ''ext2/3/4'' ファイルシステムの UUID を一意な状態に戻すには、すべてのパーティションで、{{ic|tune2fs /dev/sd''XY'' -U random}} を使用してください。スワップパーティションの場合は、代わりに、{{ic|mkswap -U random /dev/sd''XY''}} を使ってください。
* [[GPT]] ディスクを複製する場合、[[GPT fdisk#パーティションテーブルのバックアップとリストア|sgdisk]] を使うことで、ディスクとパーティションの GUID をランダム化し、GUID の一意性を保つことができます。
* ''dd'' によるパーティションテーブルの変更はカーネルには登録されません。再起動せずに変更を通知するには、''partprobe'' ([[GNU Parted]] の一部)のようなユーティリティを使ってください。
}}

=== パーティションテーブルのバックアップ ===

[[fdisk#パーティションテーブルのバックアップとリストア]] または [[gdisk#パーティションテーブルのバックアップとリストア]] を参照。

=== ディスクイメージの作成 ===

ライブ環境のメディアから起動し、ソースのハードドライブのパーティションがマウントされていないことを確認してください。

次に、外部のハードドライブをマウントし、ドライブをバックアップしてください:

# dd if=/dev/sda conv=sync,noerror bs=64K {{!}} gzip -c > ''/path/to/backup.img.gz''

必要であれば (出力ファイルが [[FAT32]] ファイルシステム上に保存される場合など)、ディスクイメージを複数に分けてください ({{man|1|split}} も見てください):

# dd if=/dev/sda conv=sync,noerror bs=64K {{!}} gzip -c {{!}} split -a3 -b2G - ''/path/to/backup.img.gz''

ローカルに十分なディスクスペースがない場合、イメージを ''ssh'' を通して送ることもできます:

# dd if=/dev/sda conv=sync,noerror bs=64K {{!}} gzip -c {{!}} ssh user@local dd of=backup.img.gz

最後に、イメージに保存されているパーティションテーブルを解釈するために必要な、ドライブのジオメトリ情報に関する追加情報を保存します。最も重要なのはシリンダーサイズです。

# fdisk -l /dev/sda > ''/path/to/list_fdisk.info''

{{Note|バックアップする HD のキャッシュの容量と同じブロックサイズ ({{ic|1=bs=}}) を使うと良いかもしれません。例えば、{{ic|1=bs=8192K}} は 8 MiB キャッシュでうまく行きます。この記事で説明されている 64 KiB は、デフォルトの {{ic|1=bs=512}} バイトよりも良いですが、より多くの {{ic|1=bs=}} を使えばより速く実行できます。}}

{{Tip|''gzip'' はデータ圧縮にシングルの CPU コアしか使用できません。そのせいで、データのスループットが最近のストレージの書き込みスピードよりかなり遅くなってしまいます。マルチコア圧縮でディスクイメージの作成をより速くするには、例えば {{Pkg|pigz}} などのパッケージをインストールし、上記の {{ic|gzip -c}} コマンドを {{ic|pigz -c}} に置き換えてください。巨大なディスクでは時間を節約できるかもしれません。また、他の圧縮アルゴリズム ({{Pkg|zstd}} など) を試しても良いかもしれません。}}

=== システムの復元 ===

システムを復元するには:

# gunzip -c ''/path/to/backup.img.gz'' | dd of=/dev/sda

イメージが分割されている場合は、代わりに以下を使用してください:

# cat ''/path/to/backup.img.gz*'' | gunzip -c | dd of=/dev/sda

== MBR のバックアップと復元 ==

ディスクに変更を加える前に、ドライブのパーティションテーブルとパーティションスキームをバックアップしておくと良いでしょう。また、同じパーティションレイアウトを複数のドライブにコピーするためにバックアップを使うこともできます。

MBR はディスクの先頭 512 バイトに格納されています。MBR は4つの部分から成ります:

# 始めの 440 バイトにはブートストラップコード (ブートローダ) が含まれています。
# 次の 6 バイトにはディスクのシグネチャが含まれています。
# 次の 64 バイトにはパーティションテーブルが含まれています (各16バイトの4つのエントリ、各プライマリパーティションに1つのエントリ)。
# 最後の 2 バイトにはブートシグネチャが含まれています。

MBR を {{ic|mbr_file.img}} として保存するには:

# dd if=/dev/sd''X'' of=''/path/to/mbr_file.img'' bs=512 count=1

完全な dd ディスクイメージから MBR を取り出すこともできます:

# dd if=''/path/to/disk.img'' of=''/path/to/mbr_file.img'' bs=512 count=1

バックアップから MBR を復元するには (注意。このコマンドは既存のパーティションテーブルを破壊し、ディスク上のすべてのデータにアクセスできなくなります):

# dd if=/''path/to/mbr_file.img'' of=/dev/sd''X'' bs=512 count=1

{{Warning|一致しないパーティションテーブルを使って MBR を復元すると、データを読み出せなくなり、ほぼ復元不可能になります。ブートローダを再インストールしたいだけならば、ブートローダは [https://www.pixelbeat.org/docs/disk/ DOS 互換領域]も実装しているので、そのブートローダの関連するページを見てください: [[GRUB]] や [[Syslinux]]。}}

ブートローダを復元したいだけで、プライマリパーティションテーブルのエントリに興味はないならば、単に MBR の先頭 440 バイトを復元すれば良いだけです:

# dd if=''/path/to/mbr_file.img'' of=/dev/sd''X'' bs=440 count=1

パーティションテーブルだけを復元するには、以下のコマンドを使う必要があります:

# dd if=''/path/to/mbr_file.img'' of=/dev/sd''X'' bs=1 skip=446 count=64

=== ブートローダーの削除 ===

MBR ブートスラップコードを消去するには(別のオペレーティングシステムを完全に再インストールする必要がある場合に役立つ場合があります)、最初の440バイトのみをゼロにする必要があります:

# dd if=/dev/zero of=/dev/sd''X'' bs=440 count=1

== ディスク関連や他の使用場面 ==

既にお気づきの方もいらっしゃるかもしれませんが、{{man|1|dd}} コアユーティリティは他のユーティリティと比較して [https://unix.stackexchange.com/a/12538#12538 かなり異なる] コマンドラインのシンタックスを持っています。さらに、[https://unix.stackexchange.com/a/12538#12538 他のコモディティユーティリティにはないユニークな機能] をサポートしていますが、特定のシナリオに適用すると、[https://www.pixelbeat.org/docs/coreutils-gotchas.html#dd あまり理想的でない] か[[dd#Partial_read:_copied_data_is_smaller_than_requested|potential error-prone]] デフォルト動作 (時には、できないこと) がいくつも存在します。そのため、ユーザーは ''dd'' コアユーティリティの代わりに、ある面ではより優れた代替品を使いたいと思うかもしれません。

そうは言っても、''dd'' は [[coreutils|core utility]] であり、Arch や他の多くのシステムにデフォルトでインストールされているため、代替ユーティリティやより専門化されたユーティリティよりも好ましいことに注意する必要があります。システムに新しいパッケージをインストールするのは不便です。

上記で説明した 2 つの側面をカバーするために、このセクションでは、他の汎用ユーティリティではほとんど見られない {{man|1|dd}} コアユーティリティの機能を、[[Pacman/比較表]] の記事に似た形式で要約することに専念します。ただし、サンプルの量は、''dd'' のこれらの機能を調べるのに十分な量 (''ヒント:'' の ''ie'' または ''To'' 節で示されています) にできる限り少なく、単純に削減されています。サブセクションの下のボックス)、実践または疑似コードのいずれかにおいてです.

{{note|この専用セクションを適切な長さに保つために、代替ユーティリティの比較には、公式リポジトリにあるパッケージのみが含まれています。この場合、言及されている他のユーティリティよりも明らかな利点があり、必要に応じて詳細が記載されています。 その他の代替ユーティリティについては、[[coreutils#dd の代替]] を参照して下さい。}}

=== バイナリファイルにブロック単位のパッチをインプレースに適用する ===

自動シェルスクリプトで機能が限定されたバイナリファイルパッチャーとして ''dd'' を使用することは珍しいことではありません。これは、書き込み前に指定されたオフセットによって出力ファイルを {{ic|seek}} することができ、ブロックすることができるためです。 {{ic|1=conv=notrunc}} オプションを追加して、出力ファイルにブロック単位 (または {{ic|1=bs=1}} の場合はバイト y バイト) でインプレースパッチを適用します。

たとえば、{{man|5|cpio|Portable ASCII Format}} アーカイブ内の最初のメンバーのタイムスタンプ部分を変更するには、ファイルの 49 番目のバイトから始まります (または、次の場合は {{ic|0x30}} のオフセットで始まります)。16 進表記を好む場合):

$ touch a-randomly-chosen-file
$ bsdtar -cf example-modify-ts.cpio --format odc -- a-randomly-chosen-file

$ printf '%011o' "$(date -d "2019-12-21 00:00:00" +%s)" | dd conv=notrunc of=example-modify-ts.cpio seek='''48''' oflag=seek_bytes

{{note|現在文書化されていない [https://github.com/coreutils/coreutils/commit/140eca15c4a3d3213629a048cc307fde0d094738 {{ic|seek_bytes}} 出力フラグ] は、出力への {{man|2|write}} を開始する前にブロックではなくバイトのオフセットで出力をシークするために上記に追加されています。}}

{{tip|コマンドライン入力の 16 進表記からバイトストリームを出力するには、{{man|1|basenc|base16}} および/または {{man|1|printf}} を使用します。}}

{{tip|この機能では、''dd'' の代わりに、シェルが開いたファイルディスクリプタに対して {{man|2|lseek}} を呼び出すことをサポートするシェルを使用することを検討することができます。:

* ''dd'' の入力ファイルは {{man|2|splice}} システムコールを利用するプログラムと接続されたパイプであり、ユーザはより良いパフォーマンスのために ''dd'' の不必要なユーザ空間 I/O を避けたいと考えています。
* または、シェルスクリプトのループ内で頻繁に {{man|2|fork}} が発生するのを避け、パフォーマンスペナルティを下げたい。

その場合、まずそのシェルにファイルディスクリプタを開かせ、そのファイルディスクリプタに対してシーク操作を行い、{{man|2|splice}} システムコールを使う対応するユーティリティの出力端としてこのファイルディスクリプタを割り当てる必要があります(あるいは{{man|1|zshmodules|sysseek}} のようにフォークしないシェル内蔵コマンドもあります):{{hc|$ zsh|<nowiki>$ local +xr openToWriteFD
$ zmodload zsh/system
$ sysopen -wo cloexec -u openToWriteFD example-modify-ts.cpio
$ sysseek -u $openToWriteFD 48
$ printf '%011o' "$(date -d "2019-12-21 00:00:00" +%s)" >&${openToWriteFD}</nowiki>}}
{{warning|オフセットを使用して書き込む必要があるプログラムが実際に {{man|2|splice}} を使用していることを確認できない場合は、このアプローチの使用を避けてください (これは、プログラムが出力に対していかなる種類のシークや切り捨ても実行しないことを意味します)。一部のプログラムは、この動作がコマンドラインフラグで指定されていない場合でも、入力/出力ファイル記述子を自動的にシーク/切り捨てることがあります。これにより、シェルの {{man|3|lseek}} 呼び出しが無効になったり、開いているファイル記述子が予期せず切り詰められたりすることがあります。}}}}

=== VFAT ファイルシステムイメージのボリュームラベルを表示する ===

{{tip|この特定のシナリオでは、より現実的な選択肢は {{pkg|file}} です。}}

ファイルシステム [https://wiki.osdev.org/FAT#FAT_32_2 VFAT のボリュームラベル] イメージファイルを読み取るには、ASCII スペースが埋め込まれた全長 11 バイトで、オフセットは {{ic|0x047}} です。:

$ truncate -s ''33M'' empty-hole.img
$ fatlabel empty-hole.img LabelMe

$ dd iflag=skip_bytes,count_bytes count=11 skip=$((0x047)) if=empty-hole.img | sed -e 's% *$%%'
{{note|[https://github.com/coreutils/coreutils/commit/140eca15c4a3d3213629a048cc307fde0d094738 両方の入力フラグは現在文書化されていません]:
* 以前の {{ic|skip_bytes}} は、入力ファイルから {{man|2|read}} を開始する前に、ブロック数ではなくバイト数でオフセットしてシーク (シークできない入力の場合は ''skip'') するように ''dd'' に指示しました。
* {{ic|count_bytes}} では、ブロック数ではなく、入力ファイルからコピーするブロックの総量を ''バイト'' で指定することができます。このオプションを指定しても部分的な {{man|2|read}} の対象となる可能性があるので混乱するかもしれませんが、この挙動をより理解するために [[dd#部分読み取り: コピーされたデータは要求されたデータよりも小さい|input block {{ic|count}}]] の小数値と考えるようにします。}}

{{tip|''指定された長さ内で入力 (オフセット付き) から出力にデータを転送するには''、シェルスクリプトでは、代わりに範囲表記を使用する代替手段として {{man|1|curl|r,}} を考慮することもできます。{{note|''curl'' は、入力ファイルがデバイス/パイプである場合のシーク/スキップをサポートしません。別の代替手段 {{man|1|socat}} は、入力ファイルに対するこれらの操作をサポートします (ブロックデバイスを含む、パイプを除く) 文字デバイス'') ですが、''curl'' ほどコモディティ化されていません。:{{bc|<nowiki>$ socat -u -,seek=$((0x047)),readbytes=11 - < empty-hole.img | sed -e 's% *$%%'</nowiki>}}}}}}

=== パイプで繋がれたコマンド間で sponge する ===

{{tip|タイトルですでに述べたように、この特定のシナリオでの実際的な選択肢は {{ic|<nowiki>${TMPDIR:-/tmp}</nowiki> への書き込みによるアトミック書き込みをサポートする {{man|1|sponge}} です}}}}

次の例では、出力側のブロックが予想より長くなった場合に、入力側で不必要に長く続く TCP 接続を避けるために、2 つのコマンドの間に ''dd'' を挿入し、出力ブロックサイズは入力よりも確実に大きく、それでも使用可能なメモリよりはかなり小さいものにすることができます。

$ curl -qgsfL <nowiki>http://example.org/mirrors/ftp.archlinux.org/mirrored.md5deep</nowiki> | dd ibs=128k obs=200M | ''poor-mirroring-script-that-perform-mirroring-on-input-paths-line-by-line-wo-buffer-entire-list-first''

{{warning|''dd'' はコピー操作全体を開始する前に出力ファイルを切り詰めるため、これを {{man|1|sponge}} の一般的な代替手段として考慮しないでください。}}

=== サイズの制限付きでデータを転送する ===

データストリーミングのシェルスクリプトで ''dd'' を使用すると、パイプコマンドで消費されるデータの合計長を制限することができるのは一般的です。例えば、ustar ヘッダブロック ({{man|5|tar|POSIX ustar Archives}}) をシェルスクリプトの機能を使ってストリーミング方式で検査する場合です:
{{Note|{{ic|count}} オプションの引数にある {{ic|B}} サフィックスは GNU coreutils v9.1 の [https://github.com/coreutils/coreutils/commit/97e9778296ead515e77a64942b84f88dcf36a176 新しく導入された] 機能で、 [[dd#VFAT ファイルシステムイメージのボリュームラベルを表示する]] と同じ効果を持っている。この機能は、{{ic|1=count=256k}}のように、''dd'' がバイトではなく262144個の入力ブロックをコピーすることを示すオプションと混同される可能性があります。}}
{{bc|<nowiki>hexdump-field() {
set -o pipefail
printf '%s[%d]:\n' $1 $2
dd count=${2}B status=none | hexdump -e $2'/1 "%3.2x"' -e '" | " '$2'/1 "%_p" "\n"'
}

inspect-tar-header-block() {
local -a hdrstack=(
name 100
mode 8
uid 8
gid 8
size 12
mtime 12
checksum 8
typeflag 1
linkname 100
magic 6
version 2
uname 32
gname 32
devmajor 8
devminor 8
prefix 155
pad 12
)
set - ${hdrstack[@]}
while test $# -gt 0; do
hexdump-field $1 $2 || return
shift 2
done
}</nowiki>}}
$ bsdtar -cf - /dev/tty /dev/null 2>&- | dd count=1 skip=1 status=none | inspect-tar-header-block
{{tip|''指定された長さ内で入力から出力にデータをストリーミングするには'' という代替案は、{{man|2|splice}} システムコールをサポートする {{man|1|pv|S,}} です。
{{note|もう 1 つの代替候補は {{man|1|head|c}} ですが、[[coreutils#Alternatives|GNU coreutils 以外の実装]] と glibc [https://unix.stackexchange.com/a/12538#12538 は消費する可能性があります]要求されたデータよりも多くのデータ] が発生し、ストリーミングシェルスクリプトでデータの不整合の問題が発生します。}}}}
{{Tip|上記の機能グリッドに加えて、入力ファイルがストリーミング前に特定のオフセットによって {{man|2|lseek}} され、''dd'' の出力端がプログラムに接続されたパイプである場合は、{{man|2|splice}} の場合、代わりに次の使用を検討できます。
* シーク機能が組み込まれたシェル (''すでに述べたように [[#前のサブセクションでの代替として、バイナリファイルにブロックごとにインプレースでパッチを適用する'']])
* または、Bourne のようなシェル (例:[[bash]])、シェルで開かれたファイル記述子に対する 1 回限りの {{man|2|lseek}} 用の {{man|1|xxd|s}} の助けを借りて、
次の [[bash]] の例のように {{man|1|pv|S,}} (''前述'') を実行します (ファイル記述子が {{ic|ls -l /proc によってシェルに割り当てられていないと仮定します) 最初は bash の /self/fd}} {{hc|$ bash|<nowiki>$ exec 9<dummy-but-rather-large.img
$ xxd -g 0 -l 0 -s $((0x47ffff)) <&9
$ pv -qSs 104857601200 <&9 |</nowiki> ''program-that-process-load-of-data-but-does-not-limit-read-length-as-desired-nor-support-offset-read''
$ exec 9<&-}}{{note|POSIX および一部の非 GNU 実装とは互換性がありませんが、上記の例の {{man|1|xxd|s}} の使用を、{{ic|1=count=0}} と組み合わせた ''dd'' に置き換えることは可能です。および {{ic|skip}} オプション [https://github.com/coreutils/coreutils/blob/4fd708810ce0e0d967c4c14e1ff2ff7b43440b58/tests/dd/skip-seek-past-file.sh#L74 coreutils テストスイートの例]}}}}

=== ブータブルなディスクイメージをブロックデバイスに書き込み、任意で進捗情報を表示する ===

その場合に最も適合性が低い可能性がある ''dd'' を含むコモディティユーティリティの例については、[[USB インストールメディア#基本的なコマンドラインユーティリティを使う]] を参照してください。
{{tip|''ファイルの内容をブロックデバイスに書き込む (進行状況インジケーター付き)'' という代替案として、{{man|1|dd_rescue|W}} が推奨されます。デバイス上の古いバージョンのイメージを新しいバージョンで上書きする場合、不要な書き込みを回避できます。}}

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

=== 部分読み取り: コピーされたデータは要求されたデータよりも小さい ===

[https://www.gnu.org/software/coreutils/manual/html_node/dd] のように、現時点で完全な入力ブロックが利用できない場合、''dd'' で作成されたファイルは要求されたサイズよりも小さくなる可能性があります。[https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html#dd-invocation per ドキュメント]:

:''さらに、データ変換する {{ic|conv}} 被演算子 ''(つまり、この Wiki 記事のようなオプション)'' が指定されていない場合、入力は読み取られるとすぐに出力にコピーされます。ブロックサイズより小さいです。''

Linuxでは、{{man|2|read}} システムコールは {{man|7|pipe}} から読むとき、または {{ic|/dev/urandom}} や {{ic|/dev/random}} などのデバイスファイルを読むときに早く戻ることがあります (つまり、''部分読み'') (例えば、[https://unix.stackexchange.com/a/178957#178957 基礎となるカーネルデバイスドライバーのハードコーディングされた制限] またはエントロピーが不十分です) ここで {{ic|''n''}} は出力にコピーする入力ブロックの最大数 (''潜在的な部分'') を制限します。

可能性はありますが、保証はできません。''dd'' がそのような種類の問題について警告する可能性があります。

dd: warning: partial read (''X'' bytes); suggest iflag=fullblock

解決策は、警告にあるように、入力ファイルオプションに加えて {{ic|1=iflag=fullblock}} オプションを ''dd'' コマンドに追加することです。たとえば、合計長が 40 MB のランダムデータで満たされた新しいファイルを作成するには、次のようにします。

$ dd if=/dev/urandom of=new-file-filled-by-urandom.bin bs=40M count=1 iflag=fullblock

{{Note|パイプや特殊なデバイスのファイルから読み込む際に、{{ic|1=count=''n''}} オプションを指定して、ファイルの一部を固定長でコピーすることが推奨されます、また、[[dd#ブートローダーの削除|デバイスの一部]] や [[ディスクの完全消去/ヒントとテクニック#単体ファイルの消去|ファイル]] を [[ディスクの完全消去|完全消去]] する場合は、{{ic|1=iflag=fullblock}} オプションを追加して''dd'' コマンドで行うことを常に強くお勧めします。}}

パイプから読み込む場合、{{ic|1=iflag=fullblock}} の [https://unix.stackexchange.com/questions/556016/cat-dd-pipe-causes-partial-reads-without-iflag-fullblock-why-truncated-to-128 代替案] として、{{ic|bs}} を [https://elixir.bootlin.com/linux/latest/A/ident/PIPE_BUF {{ic|linux/limits.h}}] で定義されている {{ic|PIPE_BUF}} 定数に制限して {{man|7|pipe}} の I/O を原子化します。例えば、全長5メガバイトのランダムな英数字で埋め尽くされたテキストファイルを用意する場合、以下のようになります:

$ LC_ALL=C tr -dc '[:alnum:]' </dev/urandom | dd of=passtext-5m.txt bs='''4k''' count=1280

出力ファイルはパイプではないため、(''入力'') パイプと (''出力'') ディスク上のファイル。たとえば、出力ファイルのより効率的なブロックサイズを設定するには、次のようにします。

$ LC_ALL=C tr -dc '[:alnum:]' </dev/urandom | dd of=passtext-5m.txt ibs=4k obs=''64k'' count=1280

{{tip|状況によっては、出力ブロックサイズを入力ブロックサイズと同じ値に保つだけで、{{ic|PIPE_BUF}} 定数で定義された値がすでに最適である場合があります。}}

=== 総転送バイト数の読み出しが間違っている ===

以下の概念実証のように、出力への書き込み時にエラーが発生した場合 (例えば、SIGPIPE、欠陥のある媒体、または誤ってターゲットネットワークブロックデバイスを切断したことによる ''部分書き込み'')、読み出された総転送バイト数は実際よりも大きくなる可能性があります:第2の ''dd'' は明らかに512200バイト以上を読みませんが、第1の ''dd'' インスタンスはまだ不正確なバイト数512400バイトを報告します:

$ yes 'x' | dd bs=4096 count=512400B | dd ibs=1 count=512200 status=none >/dev/null
125+1 records in
125+1 records out
512400 bytes (512 kB, 500 KiB) copied, 10.7137 s, 47.8 kB/s

上記の PoC のように中断された転送を再開する場合、"+" 記号の前の数字で示されるように、既にコピーされた全出力ブロックの数の読み出しのみに依存することをお勧めします。
{{Note|{{ic|1=iflag=fullblock}} オプションを追加しても、部分I/Oブロック数が1より大きい場合は、部分 I/O が2回以上発生したことになります。この場合、確実に転送を再開するために、次のことをお勧めします:
* 潜在的な欠陥媒体の部分読み出しに柔軟に対処するために、代わりに [[ddrescue]] を使用して転送を再実行する。
* ネットワーク接続が悪い状態で nbd に書き込む場合、{{man|1|dd_rescue}} を使って直接 I/O で転送を再実行する。
* 欠陥のある媒体への書き込みを避けることができます。}}

CUPS/プリンター共有

2023-04-16T01:23:03Z

Libnumafly: /* リモート管理 */ fix typo

[[Category:プリンター]]
[[en:CUPS/Printer sharing]]
[[ru:CUPS/Printer sharing]]
[[zh-hans:CUPS/Printer sharing]]
{{Related articles start}}
{{Related|Samba}}
{{Related|CUPS}}
{{Related articles end}}

この記事では GNU/Linux システム間、あるいは GNU/Linux システムと Microsoft Windows の間でプリンターを共有する方法を説明しています。

==複数プリンターでクラスを作成==

CUPS におけるクラスはプリンターの集合を意味します。単一の CUPS サーバーに繋がる複数のプリンターがあって、それらをバランスよく使いたいことがありえます (自動的にプリントジョブが異なるプリンターに割り当てられます)。またリモートユーザーが単一のプリンターであるかのごとく操作できるのも利点です。これは、クラス内のあるプリンターを修理しなければならないときに特に便利です。管理者はクラスからそのプリンターを外すだけでよく、エンドユーザーにとっては何もかわらず、プリントジョブは CUPSサーバーによって別のプリンターに割り当てられます。CUPS のウェブインターフェイスからクラスを追加したり管理できます。

==GNU/Linux システム間==

サーバーはウェブインターフェイスを使用するか {{ic|/etc/cups/cupsd.conf}} を手動で編集することで設定できます。クライアントの設定については、[[CUPS#ローカルの CUPS サーバーを使わない]]を見てください。

===ウェブインターフェイスを使う===

サーバーのウェブインターフェイスを開いて、''Administration'' タブを選択肢、''Server'' の下にある "Share printers connected to this system" オプションを有効にしてください。''Change Settings'' ボタンを押すことで変更が保存され、サーバーは自動的に再起動します。

複雑な設定を行いたい場合、''Edit Configuration File'' を選択することで直接 {{ic|/etc/cups/cupsd.conf}} ファイルを編集できます。詳しくは[[#手動セットアップ]]を見てください。

===手動セットアップ===

サーバー側のコンピュータ (プリンターに直接接続するコンピュータ) で、location ディレクティブを編集してサーバーへのアクセスを許可してください。例:
{{hc|/etc/cups/cupsd.conf|
<Location />
Order allow,deny
Allow localhost
Allow 192.168.0.*
</Location>
...
}}

また、クライアントが使用する IP アドレスでサーバーが待機するようにしてください:
{{hc|/etc/cups/cupsd.conf|
...
Listen <hostname>:631
...
}}

自動的に設定する方法など、詳しい解説は [https://www.cups.org/doc/network.html Using Network Printers] や {{man|5|cupsd.conf}} を見てください。

編集したら、CUPS を再起動してください。

ソケットアクティベーションを使って CUPS を起動している場合、{{ic|org.cups.cupsd.socket}} の[[systemd#ドロップインファイル|ドロップインファイル]]を作成してリモート接続でもソケットアクティベーションができるようにしてください:
{{hc|/etc/systemd/system/org.cups.cupsd.socket.d/override.conf|<nowiki>
[Socket]
ListenStream=631
</nowiki>}}

===ブラウジングの有効化===

ブラウジング (共有プリンターの探知) を有効にするには、サーバーに [[Avahi]] をインストールして起動する必要があります。プリンターの探知が必要ない場合、サーバーとクライアントには Avahi が必要ありません。

{{Note|cupsd が起動する前に [[Avahi]] が立ち上がっていないとブラウジングは機能しません。}}

ブラウジングを有効にするには、ウェブインターフェイスで ''Share printers connected to this system'' を選択するか、手動で Browsing をオンにして BrowseAddress を設定してください:
{{hc|/etc/cups/cupsd.conf|
...
Browsing On
BrowseAddress 192.168.0.*:631
...
}}

{{ic|cups}} サービスを[[再起動]]してください。

印刷サーバーの「ブラウジング」はリモートのネットワークホストのブラウジングとは異なります。印刷サーバでは、{{ic|cupsd}} が {{ic|avahi-daemon}} で通信するための DNS-SD プロトコルのサポートを提供します。古い CUPS プロトコルを使用しなければならない場合や、他のネットワークプリンターも印刷サーバーで「ブラウジング」するのでないかぎり、印刷サーバーに {{ic|cups-browsed}} サービスは不要です。リモートのネットワークホストには、印刷サーバーのネットワーク通信を「ブラウズ」するための {{ic|cups-browsed}} サービスが必須であり、{{ic|cups-browsed}} を実行すると自動的に {{ic|cupsd}} が起動します。

USB プリンターは接続すると {{ic|cups.service}} サービスが自動的に起動しますが、他の接続タイプでは自動的に起動するとは限りません。{{ic|cupsd}} が起動していないと {{ic|avahi-daemon}} は印刷サービスを提供することができず、その場合、systemd のサービスユニットファイルを起動時に実行するように修正する必要があります。さらに、依存関係が新しくなったらサービスを再度有効化・インストールしなければなりません。サービスファイルの {{ic|[Install]}} セクションを[[編集]]して {{ic|1=WantedBy=default.target}} を追加し、{{ic|cups.service}} サービスを[[起動]]・[[有効化]]してください。

==GNU/Linux と Windows==

===Linux サーバー - Windows クライアント===

Windows クライアントを共有するには、[[#Bonjour で共有]]、[[#IPP で共有]] あるいは [[#Samba で共有]] する方法があります。

設定後、Windows コンピュータにプリンターのネイティブなプリンタードライバーをインストールしてください。CUPS のプリンタードライバーを使用するように CUPS サーバーを設定している場合、Windows クライアントでは汎用の postscript プリンターを選択します (例 'HP Color LaserJet 8500 PS' や 'Xerox DocuTech 135 PS2')。テストページを印刷してみて印刷設定をテストしてください。

====Bonjour で共有====

[https://support.apple.com/kb/dl999 Bonjour Printing Services] を利用すると簡単に Windows クライアントを Unix プリントサーバーに [[#ブラウジングの有効化|ブラウジングを有効にして]] 接続できます。

====IPP で共有====

[[wikipedia:Internet_Printing_Protocol|Internet Printing Protocol]] はOS間で広くサポートされており、設定が簡単です。ポートフォワーディングやトンネリングなどの機能があります。IPP は Windows 2000 以降の Windows でネイティブでサポートされています。
{{Note|Internet Printing Client を Windows に追加する必要があるかもしれません (''Control Panel->Programs->Turn Windows features on or off->Print and Document Services'')。}}

まず、[[#GNU/Linux システム間]]に書かれているようにサーバーを設定してください。

Windows コンピュータ側で、''コントロールパネル->デバイスとプリンター''から「プリンターの追加」を選択します。Windows 10 の場合は「プリンターが一覧にない場合」をクリックしてください。次に、「共有プリンターの名前で選択する」を選んでプリンターの場所を入力してください:

http://''hostname'':631/printers/''printer_name''

''hostname'' は GNU/Linux サーバーのホスト名や IP アドレスに、''printer_name'' は接続されているプリンターの名前に置き換えてください。サーバーの完全修飾ドメイン名を使うこともできますが、{{ic|/etc/cups/cupsd.conf}} で {{ic|ServerAlias my_fully_qualified_domain_name}} を設定する必要があります。

{{Note|
* Windows の 'Add Printer' ダイアログのパスは要注意です。ダイアログボックスが提案している形式は {{ic|<nowiki>http://computername/printers/printername/.printer</nowiki>}} ですが、この形式は使えません。代わりに、上に書かれている形式を使ってください。
* プロキシを使用している場合はプロキシの除外設定を確認してください。プロキシを無効化しても再起動しないとプリンターが追加できない場合があります (Windows 7 の場合)。}}

====Samba で共有====

[[Samba]] は Windows におけるファイル共有やプリンター共有プロトコルの実装で、歴史のある実装です。

ただし Samba を使用したプリンター共有は、設定やメンテナンスが難しくなりがちです。

Linux サーバーの Samba を設定するために、{{ic|/etc/samba/smb.conf}} ファイルを編集してプリンターへのアクセスを許可してください。{{ic|smb.conf}} ファイルは以下のようになります:
{{hc|/etc/samba/smb.conf|2=
[global]
workgroup=Heroes
server string=Arch Linux Print Server
security=user

[printers]
comment=All Printers
path=/var/spool/samba
browseable=yes
# to allow user 'guest account' to print.
guest ok=no
writable=no
printable=yes
create mode=0700
write list=@adm root yourusername
}}

プリンターを共有するには上記だけで十分ですが、個別のプリンターのエントリを追加するほうが好ましいでしょう:
{{hc|/etc/samba/smb.conf|2=
[ML1250]
comment=Samsung ML-1250 Laser Printer
printer=ml1250
path=/var/spool/samba
printing=cups
printable=yes
printer admin=@admin root yourusername
user client driver=yes
# to allow user 'guest account' to print.
guest ok=no
writable=no
write list=@adm root yourusername
valid users=@adm root yourusername
}}

上記の設定を使うにはユーザーがプリンターにアクセスするためのアカウントがないといけません。公開プリンターの場合は ''guest ok'' を ''yes'' に変更して、''valid users'' 行を削除してください。アカウントを追加するには、通常の GNU/Linux アカウントをセットアップしてから、サーバーの Samba パスワードを設定してください。例:
# useradd yourusername
# smbpasswd -a yourusername


設定後、Samba デーモンを再起動してください。

Samba の印刷サーバーの設定では様々なカスタマイズが可能です。詳しくは Samba や CUPS のドキュメントを参照してください。{{ic|smb.conf.example}} ファイルにも参考になる例があります。

===Windows サーバー - Linux クライアント===
{{Warning|Windows のプリンターの名前やユーザーのパスワードに空白を含む場合やプリンター URL の特殊文字は正しくエスケープする必要があり、エスケープしないと CUPS が "lpadmin: Bad device-uri" エラーを吐きます。例えば {{ic|smb://BEN-DESKTOP/HP Color LaserJet CP1510 series PCL6}} は {{ic|smb://BEN-DESKTOP/HP%20Color%20LaserJet%20CP1510%20series%20PCL6}} となります。以下のコマンドを実行することで文字列を確認できます:
$ python -c 'from urllib.parse import quote; print("smb://" + quote("BEN-DESKTOP/HP Color LaserJet CP1510 series PCL6"))'
}}

====LPD で共有====

Windows 7, 8, 10 には LPD サーバーが組み込まれています。それを使うことでクライアントに ''Samba'' をインストールしたりサーバーで様々な設定を行うことなく簡単に共有が可能です。''Control Panel'' を開いて ''Programs'' -> ''Activate Windows functions'' の ''Print services'' から有効にできます。プロパティによってプリンターの ''shared'' を有効にする必要があります。共有名には空白なカンマなどの特殊文字を使用してはいけません。

それから CUPS からプリンターを追加できます。LPD プロトコルを選択してください。プリンターアドレスは以下のようになります:

# lpd://windowspc/printersharename

プリンターを追加する前に、使用しているプリンターにあわせて適切なプリンタードライバーをインストールする必要があります。Generic PostScript や RAW ドライバーで動作するかもしれません。

====IPP で共有====

上記と同じく、プリンターを共有する際は IPP が推奨プロトコルです。ただし、下に書かれている Samba による方法よりも少しばかり難しくなります。Windows に IPP サーバーをセットアップするには労力が必要です。サーバーソフトウェアとしては一般的に Microsoft の Internet Information Services (IIS) が使われます。Windows 10 などクライアント版の Windows には IPP クライアントしか含まれていないため、IPP で共有することはできません。

====Samba で共有====

Samba 経由で Windows のネイティブのプリンター共有を使う方法はもっと簡単です。ほとんど設定が不要で、CUPS バックエンドから全て設定できます。上記の通り、何か問題が発生する場合、大抵は認証関連の問題や Windows のアクセス制限が原因です。

サーバー側で使用したいプリンターの共有を有効にして、クライアント側のユーザーにプリンターにアクセスする権限を付与してください。

以下のセクションでは (cupsd と smbd デーモンが動作している) クライアントを設定する方法を説明します。

=====ウェブインターフェイスを使って設定=====

Samba の CUPS バックエンドはデフォルトで有効になっていますが、何らかの理由で有効でない場合は以下のコマンドを実行してから CUPS を再起動してください:
# ln -s $(which smbspool) /usr/lib/cups/backend/smb

次に、CUPS ウェブインターフェイスにログインして新しいプリンターの追加を選択してください。デバイスは "Windows Printer via SAMBA" を選択します。

デバイスの場所は以下のように入力:
smb://username:password@hostname/printer_name

またはパスワードを使わない場合:
smb://username@hostname/printer_name

ユーザーが Windows コンピュータのプリンターにアクセスする権限を持っていることを確認して適切なドライバーを選択してください。コンピュータがドメイン上にある場合、URI にドメインを含めてください:
smb://username:password@domain/hostname/printer_name

=====手動設定=====

手動で設定する場合、CUPS デーモンを停止して以下のように {{ic|/etc/cups/printers.conf}} にプリンターを追加してください:
{{hc|/etc/cups/printers.conf|2=
<DefaultPrinter MyPrinter>
AuthInfoRequired username,password
Info My printer via SAMBA
Location In my Office
MakeModel Samsung ML-1250 - CUPS+Gutenprint v5.2.7 # <= use 'lpinfo -m' to list available models
DeviceURI smb://username:password@hostname/printer_name # <= server URI as described in previous section
State Idle
Type 4
Accepting Yes
Shared No
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
AllowUser yourusername # <= do not forget to change this
OpPolicy default
ErrorPolicy stop-printer
</Printer>
}}

設定したら CUPS デーモンを再起動してテスト印刷を行ってみてください。

=====Windows 印刷サーバーの URI を確認=====

Windows では正確なデバイス URI (デバイスの場所) が明確ではありません。CUPS でデバイスの場所を指定するときに問題が発生する場合、以下のコマンドを実行して特定の windows ユーザーから利用できる共有を確認できます:
$ smbtree -U ''windowsusername''
Samba が正しく設定されていれば、上記のコマンドでローカルエリアネットワークサブネットで指定した Windows ユーザーから使える全ての共有が表示されます。以下のように出力されます:
{{bc|WORKGROUP
\\REGULATOR-PC
\\REGULATOR-PC\Z
\\REGULATOR-PC\Public
\\REGULATOR-PC\print$ Printer Drivers
\\REGULATOR-PC\G
\\REGULATOR-PC\EPSON Stylus CX8400 Series EPSON Stylus CX8400 Series}}
上記の場合、最後の行がプリンターとわかります。上記の EPSON Stylus プリンターに印刷する場合、CUPS で使用する URI は以下のようになります:
smb://username.password@REGULATOR-PC/EPSON%20Stylus%20CX8400%20Series

==リモート管理==

[[#GNU/Linux システム間]]に書かれているようにサーバーをセットアップしたら、設定によってリモートで管理することができます。管理を許可するホストを {{ic|/etc/cups/cupsd.conf}} の {{ic|<Location /admin>}} ブロックに追加してください。使用する構文は[[#手動セットアップ]]で説明されているものと同じです。3つのレベルで権限を与えることができます:

<Location /> #access to the server
<Location /admin> #access to the admin pages
<Location /admin/conf> #access to configuration files

リモートホストに与えたいレベルにあわせて、セクションに {{ic|Allow}} ステートメントを追加してください。{{ic|Allow}} ステートメントは以下の形式で使用することができます:
Allow from all
Allow from host.domain.com
Allow from *.domain.com
Allow from ip-address
Allow from ip-address/netmask
Allow from @LOCAL

Deny ステートメントを使うこともできます。例えば、ローカルネットワークインターフェイスの全てのホストに完全な権限を与えたい場合、{{ic|/etc/cups/cupsd.conf}} を以下のように編集:
# Restrict access to the server...
# By default only localhost connections are possible
<Location />
Order allow,deny
'''Allow from @LOCAL'''
</Location>

# Restrict access to the admin pages...
<Location /admin>
Order allow,deny
'''Allow from @LOCAL'''
</Location>

# Restrict access to configuration files...
<Location /admin/conf>
AuthType Basic
Require user @SYSTEM
Order allow,deny
'''Allow from @LOCAL'''
</Location>

以下の設定を追加することでリモートマシンから CUPS ウェブインターフェイスを使用した場合に起こる {{ic|426 - Upgrade Required}} エラーを止めることができます:

DefaultEncryption Never

=== Kerberos ===

[[Kerberos]] を使ってリモートの CUPS サーバーにアクセスするユーザーを認証することができます。マシンにキータブが存在することが前提で、"HTTP" のチケットが必要です。{{ic|<nowiki>http://localhost:631</nowiki>}} の代わりに {{ic|<nowiki>https://host.example.co.uk:631</nowiki>}} を使ってください。認証するために暗号化 (https) が必要な上に Kerberos/Negotiate を機能させるために完全なホストネームが必要です。さらにサーバーの {{ic|/etc/cups/cupsd.conf}} を設定して {{ic|DefaultAuthType}} を {{ic|Negotiate}} にする必要があります。

[[Samba]] の winbind NSS サポートを使用する場合、AD グループ名を {{ic|/etc/cups/cups-files.conf}} に追加することができます。以下の例では {{ic|sysadmin}} が AD グループです:
SystemGroup sys root sysadmin

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

一般的なトラブルシューティングについては [[CUPS/トラブルシューティング]]を見てください。

====GTK アプリケーションで印刷できない====
GTK アプリケーションから印刷しようとすると "getting printer information failed" と表示される場合、{{ic|/etc/hosts}} に次の行を追加してください:
# serverip some.name.org ServersHostname

=== Samba でプリンターを追加・編集できない ===

Samba を使ってプリンターを追加・編集しようとすると、インターフェイスによる CPU の使用率が 100% の状態が30秒も続いた後に以下のメッセージが表示される場合:

Unable to get list of printer drivers: Success

Gutenprint (https://bugs.archlinux.org/task/43708) の既知のバグが原因です。Gutenprint をアンインストールして foomatic-db だけをインストールしてください。次のコマンドで "Success" メッセージの代わりにドライバーのリストが返ってくるはずです:

# lpinfo -m

=== Windows でパーミッションエラー ===

ユーザーによっては別の構文を使うことで 'NT_STATUS_ACCESS_DENIED' エラーが解決する場合があります (Windows クライアント):
smb://workgroup/username:password@hostname/printer_name

==他のオペレーティングシステム==
他の印刷システムと CUPS を繋げる方法の詳細は CUPS マニュアルにあります。例: http://localhost:631/help/network.html

Deluge

2022-10-09T14:51:42Z

Libnumafly: /* Web */ 大洪水→deluge

[[Category:BitTorrent]]
[[de:Deluge]]
[[en:Deluge]]
[[es:Deluge]]
[[ko:Deluge]]
{{Related articles start}}
{{Related|rTorrent}}
{{Related|systemd}}
{{Related|systemd/ユーザー}}
{{Related|iptables}}
{{Related|OpenSSL}}
{{Related articles end}}

[http://deluge-torrent.org/ Deluge] は Python 3 で書かれたフル機能の BitTorrent アプリケーションです。以下のような様々な機能が揃っています: クライアント/サーバーモデル、DHT のサポート、マグネットリンク、プラグインシステム、UPnP のサポート、フルストリーム暗号、プロキシのサポート、3つの異なるクライアントアプリケーション。サーバーデーモンが動作している間、ユーザーはコンソールクライアントや GTK+ ベースの GUI、またはウェブベースの UI を使って接続することができます。完全な機能のリストは [http://dev.deluge-torrent.org/wiki/About こちら] から見れます。

== インストール ==

{{Pkg|deluge}} パッケージからインストールできます。GTK+ クライアントを使うには {{AUR|pygtk}} パッケージが必要です。Be sure to read and install the optional dependencies for the gtk client {{Pkg|deluge-gtk}} to enable desktop notifications and appindicator notifications.

== デーモン ==
Deluge はクライアント・サーバーモデルで稼働します。サーバーはデーモンとも呼ばれバックグラウンドで動作してクライアント (コンソール, gtk, ウェブベース) が接続してくるのを待機します。クライアントが切断してもデーモンはキューに入った torrent ファイルの転送を実行し続けます。

インストール時、pacman は非特権の '''deluge''' ユーザーを作成します。付属の {{ic|/usr/bin/deluged}} デーモンを実行するためのユーザーです。デーモンを起動する方法は複数存在します:
# Systemd のシステムサービス (deluge ユーザーとして実行)。
# Systemd のユーザーサービス (他のユーザーとして実行)。
# 直接実行 (他のユーザーとして実行)。

{{Tip|セキュリティをできるかぎり高めるために、{{ic|deluged}} は systemd のシステムサービス ({{ic|deluged.service}}) で実行することを推奨します。deluge ユーザーはシェルにアクセスすることがなくホスト環境の他のグループに入っていません。非特権の deluge ユーザーとして実行する場合、Xorg やクライアントを起動しなくてもシステムサービスを起動できるというメリットもあります。}}

=== システムサービス ===

{{ic|deluged.service}} サービスを[[起動]]/[[有効化]]してください。

=== ユーザーサービス ===

{{Warning|複数のユーザーでデーモンを実行する場合、ユーザーごとにデフォルトポート (58846) を変更する必要があります。}}

ユーザーサービスを使うことで {{ic|systemd --user}} が実行されたときに {{ic|deluged}} を起動することができます。以下のユーザーサービスファイルを作成することで使うことが可能です:
{{hc|/etc/systemd/user/deluged.service|<nowiki>
[Unit]
Description=Deluge Daemon
After=network.target

[Service]
ExecStart=/usr/bin/deluged -d -P %h/.config/deluge/deluge.pid

[Install]
WantedBy=default.target</nowiki>}}
ユーザーから deluge のユーザーサービスを起動・有効化してください:
$ systemctl --user start deluged
$ systemctl --user enable deluged

{{ic|deluged}} のユーザーサービスは {{ic|$HOME/.config/systemd/user/}} に配置することもできます。ユーザーサービスについて詳しくは [[systemd/ユーザー]] を見て下さい。

== 設定 ==

Deluge はクライアントを使って設定することも、{{ic|$HOME/.config/deluge/}} にある JSON フォーマットの設定ファイルを編集して設定することもできます (''$HOME'' は {{ic|deluged}} を動作させるユーザーのホームディレクトリです、デーモンが ''deluge'' ユーザーによって動作している場合、デフォルトのホームディレクトリは {{ic|/srv/deluge/}} になります)。

=== ダウンロード・アップロードに共有ディレクトリを使う ===
systemd の {{ic|deluged.service}} を使用する場合、共有ディレクトリはシステムの他のユーザーがデータにアクセスできるように共有する必要があります。一般的な設定例:

# 共有ディレクトリの所有者と所有グループを {{ic|deluge:deluge}} に変更。
# 共有ディレクトリの[[ファイルのパーミッションと属性]]を最低でも 770 に設定。
# (ファイルにアクセスする必要がある) ユーザーを deluge グループに追加。

{{ic|/mnt/torrent_data}} を使用する場合:
# chown -R deluge:deluge /mnt/torrent_data
# chmod 770 /mnt/torrent_data
# usermod -a -G deluge YOURUSER

{{Note|usermod を使用してグループ所属を変更する場合、変更を有効にする前にログアウト/ログインが必要です。}}

=== ファイアウォール ===

Deluge は、シード用の着信接続を許可するために、TCP および UDP の少なくとも1つのポートを開く必要があります。Deluge が着信接続用のポートを開くことができない場合、ユーザーは使用するポート(複数可)を開く必要があります。この例では、ポート56881 から 56889 が TCP および UDP 用に開かれています。
# iptables -A INPUT -p tcp --dport 56881:56889 -j ACCEPT
# iptables -A INPUT -p udp --dport 56881:56889 -j ACCEPT
NAT ルーター/ファイアウォールの背後にいるユーザーは、転送に対応するポートを設定する必要があります。 UPnP も使用できますが、事前定義されたポートが必要なため、システムのローカルファイアウォールでは機能しません。
{{Note|これを単一のポートに制限することができます。TCP と UDP の両方を必ず有効にしてください。}}

多くのデフォルト設定では、接続追跡 (conntrack) で iptables を使用して ''無効な'' パケットをドロップするように設定すると、大量の正当なトレントトラフィック (特に DHT トラフィック) が ''無効'' としてドロップされる場合があります。これは通常、conntrack のメモリ制限、またはピア間のパケット間の長い時間によって発生します (最下部の [http://libtorrent.rakshasa.no/wiki/RTorrentUsingDHT] および [https://www.linuxquestions.org/questions/showthread.php?p=5145026] を参照)。この問題の症状には、特にトレントクライアントが 1 〜 2 日以上継続してアクティブな場合に、トレントがシードされないこと、DHT を有効にして、deluge/libtorrent が 48 時間以上継続して実行され、多くのトレントがアクティブな場合でも、常に低いオーバーヘッドトラフィック (ある報告では、入出力ともに 3KiB/s 未満) が発生することなどがあります。このため、リスニングポートを ACCEPT に設定しても、最適なパフォーマンスを得るためには、すべてのトレントトラフィックの接続追跡を無効にする必要があるかもしれません (conntrack のメモリ問題など、無効なパケットをドロップする原因が、これらのポートへのトラフィック/ポートからのトラフィックを受け入れるルールに優先する場合があるためです。)

トレントの接続追跡を完全にオフにするには、Deluge の受信トラフィックと送信トラフィックの両方にポートを指定します。
{{Note|libtorrent で着信接続を制限することはお勧めしません。これにより、異なるトレントであっても、同じクライアントへの複数の接続を維持する機能が制限されます。}}

次のコマンドを発行します(関連するポート範囲を置き換えた後)
# iptables -t raw -I PREROUTING -p udp --dport 56881:57200 -j NOTRACK
# iptables -t raw -I OUTPUT -p udp --sport 56881:57200 -j NOTRACK
# iptables -t raw -I PREROUTING -p tcp --dport 56881:57200 -j NOTRACK
# iptables -t raw -I OUTPUT -p tcp --sport 56881:57200 -j NOTRACK
# iptables -I INPUT -p icmp --icmp-type 3 -j ACCEPT
# iptables -I INPUT -p icmp --icmp-type 4 -j ACCEPT
# iptables -I INPUT -p icmp --icmp-type 11 -j ACCEPT
# iptables -I INPUT -p icmp --icmp-type 12 -j ACCEPT
これらのポートで接続追跡が無効になると、これらの重要な ICMP メッセージ (タイプ3 (Destination Unreachable),4 (Source Quench),11 (Time Exceeded),および12 (Parameter Problem) が無効と宣言されるため、ICMP 許容値が望ましいです。それら自体(netfilter はそれらが関連付けられている接続を認識しないため)およびそれらは潜在的にブロックされます。

{{Warning|1024:65535 のポート範囲は、すべての DNS クエリを壊します。}}

=== プラグイン ===

完全なプラグインのリストは [http://dev.deluge-torrent.org/wiki/Plugins Deluge Wiki] にあります。

[https://github.com/ratanakvlun/deluge-ltconfig ltConfig] は libtorrent の設定を直接変更できる便利なプラグインで、プリセットにも対応しています。

このプラグインは {{ic|announce_ip}} のような追加設定を提供します。(トラッカーにアナウンスする IP), {{ic|half_open_limit}} のような追加設定を提供します。(最大半開放接続数の制限を解除する) などの追加設定や、プライバシーや (シード) スピードブースト機能を提供します。

== クライアント ==

=== コンソール ===

コンソールクライアントは次のコマンドで起動できます:
$ deluge-console
利用可能なコマンドのリストを確認したいときは {{ic|help}} コマンドを使って下さい。

=== GTK+ ===

{{Note|デーモン (サーバー) の設定には、「編集」→「環境設定」→「インターフェース」でクラシックモードを無効にする必要があります。}}

GTK+ クライアントは次のコマンドで起動できます:
$ deluge-gtk
または:
$ deluge

GTK+ クライアントには便利なプラグインがたくさん付いています:
* AutoAdd - .torrent ファイルのディレクトリを監視。
* Blocklist - IP ブロックリストをダウンロード・インポート。
* Execute - イベントによってコマンドを実行。
* Extractor - ダウンロード完了時に圧縮ファイルを解凍 '''''(ディスク I/O の使用量が増えることがあるので注意)'''''。
* Label - ラベルをトレント、状態、トラッカー、キーワードフィルターに割り当てることができます
* Notifications - イベントやその他のプラグインの通知(電子メール、ポップアップ、点滅、サウンド)を提供します
* Scheduler - 1時間ごと、1日ごとに、アクティブなトレントとその速度を制限します
* WebUi - GTK+ クライアントを介して WebUI を開始できるようにします

=== Web ===

ユーザーがデーモンへの GTK またはシェルベースのアクセスを望まない場合は、Web クライアントも提供されます。上記の Deluge デーモンと同様に、Web クライアントはいくつかの異なる方法で起動できます。
# Systemd system サービス (deluge のユーザーとして実行)
# Systemd user サービス (別のユーザーとして実行)
# 直接実行する (別のユーザーとして実行)

{{Note|
* Web インターフェイスのデフォルトのパスワードは ''deluge'' です
* Web クライアントは、プラグインシステムなど、GTKUI と同じ機能の多くを提供します。
* 中間者攻撃から保護するために、Web クライアントに HTTPS を使用することをお勧めします。
* ユーザーは、SSL 証明書が信頼されていないというブラウザからの警告によって迎えられる場合があります。続行するには、ブラウザでこれに例外を追加してください。独自の証明書の作成については、[[OpenSSL]] ページを参照してください。
* 複数のユーザーがデーモンを実行している場合は、ユーザーごとにデフォルトのポート(8112)を変更する必要があります。
}}

{{Tip|最高レベルのセキュリティを確保するには、systemd システムサービス({{ic|deluge-web.service}})を介して {{ic|deluge-web}} を実行することをお勧めします。これは、deluge ユーザーがシェルアクセス(制限付きアカウント)を持っていないためです。ホストシステム上の他のグループ所属。非特権の deluge ユーザーとして実行することによるセキュリティ上の利点に加えて、システムサービスは、Xorg またはクライアントを起動しなくても起動時に実行できます。}}

実行後、https://127.0.0.1:8112 で暗号化を使用している場合、またはホスト IP アドレスで暗号化を使用している場合、ユーザーは http://127.0.0.1:8112 を参照して Web クライアントに接続できます。

==== システムサービス ====

Deluge には Deluge のウェブ UI を[[起動]]するのに使用する systemd システムユニットである {{ic|deluge-web.service}} が付属しています。Deluge Web UI は Connection Manager を使用して同一ホスト上で複数の Deluge クライアントを管理します。ウェブ UI クライアントからホストの Deluge クライアントに接続するには {{ic|deluged}} サービスを [[起動]]・[[有効化]] してください。

==== ユーザーサービス ====

ユーザーサービスを使うことで {{ic|systemd --user}} が実行されたときに {{ic|deluge-web}} を起動することができます。以下のユーザーサービスファイルを作成することで使うことが可能です:
{{hc|/etc/systemd/user/deluge-web.service|<nowiki>
[Unit]
Description=Deluge Web UI
After=deluged.service

[Service]
ExecStart=/usr/bin/deluge-web --ssl

[Install]
WantedBy=default.target
</nowiki>}}
ユーザーから deluge のユーザーサービスを [[起動]]・[[有効化]] してください:
$ systemctl --user start deluge-web
$ systemctl --user enable deluge-web

{{ic|deluge-web}} のユーザーサービスは {{ic|$HOME/.config/systemd/user/}} に配置することもできます。ユーザーサービスについて詳しくは [[systemd/ユーザー]] を見てください。

== ヘッドレスセットアップ ==

Deluge は、クライアント/サーバーモデルのため、シードボックスと呼ばれることが多いヘッドレスシステムで非常に役立ちます。ヘッドレスシステムで Deluge を設定するには、上記のようにデーモンを設定します。

=== ユーザーの作成 ===

サーバーとのリモート操作を許可するには、{{ic|$HOME/.config/deluge/auth}} にユーザーを作成します。例えば:
$ echo "delugeuser:p422WoRd:10" >> $HOME/.config/deluge/auth
{{Note|
* 作成されたユーザー/パスワードは、どのシステムユーザーとも一致する必要はありません。また、適切なセキュリティプラクティスを維持するために、''not'' の必要があります。
* このファイルのユーザー/パスワードは、ウェブクライアント設定のようにハッシュ化またはソルト化されていません。
* ユーザー/パスワードは /srv/deluge/.config/deluge/auth にあるユーザー/パスワードと一致する必要があります。一致しない場合、認証は失敗します。
}}

数字 ''10'' は ''Admin'' レベルに相当します。その他の値については、次の表を参照してください。

{| class="wikitable" align="center"
|-
! レベル名 !! レベル値
|-
| None || 0
|-
|Read Only || 1
|-
| Normal || 5
|-
| Admin || 10
|}

{{Note|Deluge 1.35では、これらの値は効果がありませんが、マルチユーザーオプションは開発中です。}}

=== リモートの許可 ===

デフォルト設定ではリモート接続は許可されていません。{{ic|$HOME/.config/deluge/core.conf}} の "allow_remote" 設定を変更してください:
"allow_remote": true,

{{Note|
* {{ic|$HOME/.config/deluge/core.conf}} は最初に設定を変更したときに自動的に作成されます。存在しない場合、{{ic|deluge-console}} で値を設定できます: {{ic|config --set allow_remote true}}。
* デーモンの実行中に設定を変更しても反映されません。サービスを停止してからファイルを変更してください。
}}

=== ファイアウォール ===

リモートアクセス用にポートを開いてください。以下の例ではデフォルトのデーモンポート (58846) を使います:
# iptables -A INPUT -p tcp --dport 58846 -j ACCEPT
ファイアウォールのルールに関する詳細は [[iptables]] を見て下さい。

NATルーター/ファイアウォールの背後にいるユーザーは、この動作が必要な場合、ネットワークの外部からデーモンにアクセスするためにポートを転送する必要があります。

=== 接続 ===

コンソールクライアントの場合:
connect <host>[:<port>] <user> <password>

GTK+ クライアントの場合: ''Edit > Connection Manager > Add''。

ウェブクライアントの場合: ''Connection Manager > Add''。

==== SSH トンネル ====

SSH トンネルを作成して、任意のクライアントで暗号化された接続を使用できます。これには、追加のループバックアドレスを追加する必要がありますが、これは起動時に自動化できます。この手順がないと、接続はローカルと見なされます。 SSHトンネルを確立するための実際のコマンドは、ユーザー入力が必要なため自動化できません。それを行うには、いくつかの方法があります。
{{hc|/etc/systemd/system/extra_lo_addr.service|<nowiki>
[Unit]
Description=extra loopback address
Wants=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ip addr add 127.0.0.2/8 dev lo
ExecStop=/sbin/ip addr del 127.0.0.2/8 dev lo

[Install]
WantedBy=multi-user.target
</nowiki>}}

$ ssh -fNL 127.0.0.2:58846:localhost:58846 <ssh host>
ポート '''58846''' は、デリュージサーバーが実行されているポートに置き換え、''' ssh host''' は、デリュージと SSH サーバーの両方をホストするサーバーに置き換える必要があります。

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

=== No module named service_identity ===

{{ic|deluged}} や {{ic|deluge-console}} を実行したときに以下のようなメッセージが表示される場合:

:0: UserWarning: You do not have a working installation of the service_identity module: 'No module named service_identity'.
Please install it from <https://pypi.python.org/pypi/service_identity> and make sure all of its dependencies are satisfied.
Without the service_identity module and a recent enough pyOpenSSL to support it, Twisted can perform only rudimentary TLS
client hostname verification. Many valid certificate/hostname mappings may be rejected.

{{Pkg|python-twisted}} の任意の依存パッケージである {{Pkg|python-service-identity}} がインストールされていないことが原因です。{{Bug|43806}} を見てください。

=== Web ui .torrent アップロードが機能しない ===

リバースプロキシの背後で Web UI を実行しているユーザーは、.torrent アップロードの埋め込みを許可する必要があります (X-Frame-Options ALLOW)

=== 実行スクリプトが見つからないか、実行可能ではありません ===

[https://dev.deluge-torrent.org/wiki/Plugins/Execute Execute] プラグインを使用する場合、deluge がスクリプトを実行しようとすると、次のエラーメッセージがログに記録されます。

[ERROR ][deluge_execute.core :145 ] Execute script not found or not executable

{{ic|deluged}} がシステムサービスとして実行されている場合、他のユーザーのホームディレクトリにアクセスできない可能性があることに注意してください。カスタムスクリプトを {{ic|/usr/local/bin/}} に配置することを検討してください。

スクリプト権限の問題は、[[sudo]] を使用して {{ic|deluge}} ユーザーとしてデバッグできます。
$ sudo -u deluge /path/to/script

=== 予期しないシャットダウンの後、Torrent リストが完全に消えました ===

これは通常、状態ファイルが破損していることを意味します。 [https://forum.deluge-torrent.org/viewtopic.php?t=55087 これは、過去10年間、断続的な問題でした。]以前に実行されていたすべてのトレントのコピーとともに1つのバックアップ状態ファイルが必要です。この問題を解決するために復元できる deluge プロファイルフォルダ(systemd ユーザーの場合、これは通常 {{ic|/srv/deluge/.config/deluge/state}} です)ただし、特に数回の再起動後にトレントリストに気付いただけの場合は、すぐに上書きされる可能性があります。それが再び起こらないようにするための推奨される行動方針は、state ファイルと Torrent ファイルの毎日のバックアップを自動化することです。

=== コンソールを使用できません ===

Deluge を {{ic|deluge}} ユーザで実行する場合、 {{ic|deluge-console}} には {{ic|deluge}} ユーザでアクセスしないと、 Python のさまざまな例外やバグに遭遇する可能性があります。

$ sudo -u deluge deluge-console

もしくは

$ sudo deluge-console -c /srv/deluge/.config/deluge

== 参照 ==

* [http://deluge-torrent.org/ Deluge ホームページ]
* [http://dev.deluge-torrent.org/wiki Deluge wiki]

GRUB

2022-06-26T04:49:15Z

Libnumafly: /* Windows 8/10 が認識されない */ 高速スタートアップに関する豆知識

[[Category:ブートローダー]]
[[Category:GNU]]
[[ar:GRUB]]
[[cs:GRUB]]
[[de:GRUB]]
[[el:GRUB]]
[[en:GRUB]]
[[es:GRUB]]
[[fa:گراب]]
[[fr:GRUB]]
[[he:GRUB]]
[[id:GRUB]]
[[it:GRUB]]
[[nl:GRUB]]
[[pt:GRUB]]
[[ru:GRUB]]
[[tr:GRUB2]]
[[uk:GRUB]]
[[zh-hans:GRUB]]
[[zh-hant:GRUB]]
{{Related articles start}}
{{Related|Arch ブートプロセス}}
{{Related|Master Boot Record}}
{{Related|GUID Partition Table}}
{{Related|Unified Extensible Firmware Interface}}
{{Related|GRUB Legacy}}
{{Related|GRUB/EFI サンプル}}
{{Related|GRUB/ヒントとテクニック}}
{{Related|マルチブート USB ドライブ}}
{{Related articles end}}

[https://www.gnu.org/software/grub/ GRUB] (GRand Unified Bootloader) は[[Arch ブートプロセス#ブートローダー|マルチブートローダー]] です。GRUB Legacy の後継の研究開発プロジェクト [https://www.nongnu.org/pupa/ PUPA] から GRUB は作られています。全てを整理するため GRUB はスクラッチから書きなおされモジュール性とポータビリティを獲得しました [https://www.gnu.org/software/grub/grub-faq.html#q1]。現在の GRUB は GRUB2 とも呼ばれ、GRUB Legacy はバージョン 0.9x に対応しています。

{{Note|記事全体で、{{ic|''esp''}} は [[EFI システムパーティション]](別名 ESP) のマウントポイントを示します。}}

== UEFI システム ==

{{Note|
* 次のページを読んで理解しておくことをおすすめします: [[Unified Extensible Firmware Interface]]、[[パーティショニング#GUID Partition Table]]、[[Arch ブートプロセス#UEFI_2]]。
* UEFI を使うようにインストールする場合、インストールメディアを UEFI モードで起動することが重要です。さもないと、''efibootmgr'' が GRUB の UEFI ブートエントリを追加できません。[[#デフォルト/フォールバックのブートパス|フォールバックブートパス]]へのインストールは NVRAM を使用しないため、BIOS モードでも可能です。
* UEFI を使用してディスクから起動するには EFI システムパーティションが必要です。[[EFI システムパーティション#既存のパーティションの確認]] に従って、すでに EFI システムパーティションが存在するかどうかを確認してください。存在しない場合は作成する必要があります。}}

=== インストール ===

{{Note|
* それぞれのマザーボードの製造者によって　UEFI は別々に実装されているということは有名です。GRUB や EFI が正しく動作しないという問題が起きたユーザーは下で説明されていること以外のハードウェア特有のケースについて詳しい手順を共有することが奨励されています。この記事では総合的なことしか書かれていないので、特別な場合については [[GRUB/EFI サンプル]]のページを見て下さい。
* このセクションでは、あなたが GRUB を x86_64 システムにインストールすると仮定しています。IA32(32ビット) UEFI システムの場合(32ビット CPU と混同しないでください)、適切な場所の {{ic|x86_64-efi}} を {{ic|i386-efi}} に置き換えてください。
}}

まず、{{Pkg|grub}} と {{Pkg|efibootmgr}} を[[インストール]]してください。''GRUB'' はブートローダである一方、''efibootmgr'' はブートエントリを NVRAM に書き込むために GRUB のインストールスクリプトによって使用されます。

そして、以下の手順に従って GRUB をディスクにインストールしてください:

# [[EFI システムパーティション#パーティションのマウント|EFI システムパーティションをマウント]]してください。そして、このセクションの後の部分で出てくる {{ic|''esp''}} という記述をそのマウントポイントに置き換えてください。
# ブートローダの識別子を選んでください、ここでは {{ic|GRUB}} とします。{{ic|''esp''/EFI/}} にあなたが選んだものと同じ名前のディレクトリが作成され、そこに EFI バイナリが格納されます。その名前が UEFI ブートメニューの GRUB ブートエントリの名前になります。
# 以下のコマンドを実行して、GRUB EFI アプリケーション {{ic|grubx64.efi}} を {{ic|''esp''/EFI/GRUB/}} に、モジュールを {{ic|/boot/grub/x86_64-efi/}} にインストールしてください。{{bc|1=# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=GRUB}} {{Note| GRUB をブートローダとしてインストールするシステム内でパッケージをインストールし、{{ic|grub-install}} を実行してください。つまり、ライブインストール環境から起動している場合、{{ic|grub-install}} は chroot 環境の中で実行する必要があるということです。何らかの理由で、インストールされたシステムの外で {{ic|grub-install}} を実行する必要がある場合、マウントされた {{ic|/boot}} ディレクトリへのパスを {{ic|1=--boot-directory=}} オプションに渡してください。例: {{ic|1=--boot-directory=/mnt/boot}}.}}

上記のインストール作業が完了した後、メインの GRUB ディレクトリが {{ic|/boot/grub/}} に作成されています。{{ic|grub-install}} は[[#ファームウェアブートマネージャーに GRUB エントリを作成する|ファームウェアのブートマネージャにもエントリを作成しようとする]]ことに注意してください。その名前は上記の例では {{ic|GRUB}} となります。しかし、ブートエントリが埋まっていると、これは失敗します。この場合は [[efibootmgr]] を使って必要ないエントリを削除してください。

設定を確定したあとに[[#メイン設定ファイルの生成|メインの設定ファイルを生成]]することを忘れないでください。

{{Tip| {{ic|--removable}} オプションを使うと、GRUB は {{ic|''esp''/EFI/BOOT/BOOTX64.EFI}} にインストールされます({{ic|i386-efi}} の場合は {{ic|''esp''/EFI/BOOT/BOOTIA32.EFI}})。これにより、EFI 変数がリセットされた場合やドライブを他のコンピュータに移した場合でもドライブから起動することができるようになります。通常は BIOS を使用する方法と同じようにドライブを選択することで使うことができます。Windows とデュアルブートする場合、Windows は EFI パーティションの EFI フォルダの中に boot という名前のフォルダを作成するので注意してください。このフォルダによって Windows の EFI ブートオプションが再作成されます。}}

{{Note|
* オプション {{ic|--efi-directory}} と {{ic|--bootloader-id}} は GRUB UEFI 専用です。{{ic|--efi-directory}} は ESP のマウントポイントを指定します。このオプションと同じものとして以前は {{ic|--root-directory}} が使われていました。
* GRUB を BIOS システムで設定するときと異なり {{ic|grub-install}} コマンドの最後に <device_path> オプション (例: {{ic|/dev/sda}}) を使わないことに注意してください。UEFI のブートローダーは MBR やパーティションのブートセクタを全く使わないので <device_path> が指定されてもインストールスクリプトはそれを無視します。
}}

問題が発生した場合は [[#UEFI]] を見て下さい。加えて [[GRUB/ヒントとテクニック#UEFI の詳細情報]] も参照してください。

== BIOS システム ==

=== GUID Partition Table (GPT) 特有の手順 ===

BIOS/[[GPT]] の構成では、[https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation BIOS ブートパーティション]が必要です。GRUB は {{ic|core.img}} をこのパーティションに埋め込みます。

{{Note|
* この方法を試す前に、すべてのシステムでこのパーティショニング方式がサポートされているわけではないということを心に留めておいてください。詳細は [[パーティショニング#GUID Partition Table]] を見てください。
* BIOS ブートパーティションは BIOS/GPT のセットアップでのみ GRUB が必要とします。BIOS/MBR セットアップでは、GRUB は MBR の後にある隙間を {{ic|core.img}} のために使用します。しかし、GPT では 1 番目のパーティションの前にそのような未使用のスペースが存在することが保証されていません。
* [[UEFI]] システムでは、ブートセクタが組み込まれないので、BIOS ブートパーティションは必要ありません。しかし、UEFI システムでは [[EFI システムパーティション]]が必要です。
}}

ディスク上にパーティションタイプ GUID {{ic|21686148-6449-6E6F-744E-656564454649}} の、ファイルシステムの無い 1 メビバイトのパーティションを作成してください(''fdisk'' か ''gdisk'' で {{ic|1=+1M}})。

* [[fdisk]] では、パーティションタイプ {{ic|BIOS boot}} を選択してください。
* [[gdisk]] では、パーティションタイプコード {{ic|ef02}} を選択してください。
* [[parted]] では、そのパーティションで {{ic|bios_grub}} フラグをセット/アクティブ化してください。

このパーティションはどのような順番で配置しても良いですが、ディスクの先頭 2 TiB 以内になければなりません。このパーティションは GRUB のインストール前に作成する必要があります。パーティションの準備が完了したら、以下の指示に従ってブートローダーをインストールします。

GPT のアライメント仕様から外れますが、1番目のパーティションの前にあるスペースは BIOS ブートパーティションとしても使用できます。このパーティションは定期的にアクセスされるものではないのでパフォーマンスの問題は無視できますが、一部のディスクユーティリティは警告を発します。''fdisk'' や ''gdisk'' では、セクター 34 から 2047 までの区間の新しいパーティションを作成して、先のパーティションタイプを設定してください。見える状態のパーティションが先頭から始まるようにするには、このパーティションを最後に追加することを検討してください。

=== Master Boot Record (MBR) 特有の手順 ===

通常 MBR でパーティションされた環境において [[MBR]] の後の隙間 (512バイトの MBR 領域の後ろで最初のパーティションの前) は 31 KiB になっていて、このパーティションテーブルでは DOS 互換のシリンダー・アライメントは問題になりません。しかしながら GRUB の {{ic|core.img}} 用に十分な領域を確保するため 1 から 2 MiB ほど MBR の後の領域をとることを推奨します ({{bug|24103}})。この領域を獲得したり他の 512 バイトでないセクターの問題を起こさないために ({{ic|core.img}} の埋め込みとは関係ありません) 1 MiB パーティション・アライメントをサポートしているパーティションツールを使うのが得策です。

=== インストール ===

{{Pkg|grub}} パッケージから GRUB を[[インストール]]できます。{{AUR|grub-legacy}} がインストールされている場合は置き換えられます。次に以下の手順を実行します。

# grub-install --target=i386-pc ''/dev/sdX''

{{ic|''/dev/sdX''}} は GRUB がインストールされる '''ディスク''' ('''パーティションではありません''') です。例えば、{{ic|/dev/sda}}、{{ic|/dev/nvme0n1}} または {{ic|/dev/mmcblk0}} です。ブロックデバイスの命名方法については、[[デバイスファイル#ブロックデバイスの名前]]を参照してください。

次に、[[#メイン設定ファイルの生成|メイン設定ファイルを生成]]する必要があります。

[[LVM]] を {{ic|/boot}} に使用している場合、GRUB を複数の物理ディスクにインストールすることができます。

{{Tip|USB メモリなどに GRUB をインストールする他の方法については、[[GRUB/ヒントとテクニック#代替インストール方法]]を参照してください。}}

{{ic|grub-install}} コマンドの詳細については、{{man|8|grub-install}} および [https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html#BIOS-installation GRUB Manual] を参照してください。

== 設定 ==

インストールされたシステムでは、GRUB は起動の度に設定ファイル {{ic|/boot/grub/grub.cfg}} をロードします。ツールを使う場合は、[[#grub.cfg の生成]] を、手動で作成する場合は [[#grub.cfg のカスタマイズ]] を参照してください。

=== grub.cfg の生成 ===

このセクションでは {{ic|/etc/default/grub}} 設定ファイルの編集についてだけ扱っています。他のオプションは [[GRUB/ヒントとテクニック]] を見て下さい。

{{Note|{{ic|/etc/grub.d/}} 下のファイルや {{ic|/etc/default/grub}} に変更を加えた後は必ず[[#メイン設定ファイルの生成|メイン設定ファイルの再生成]]を行なって下さい。}}

==== メイン設定ファイルの生成 ====

インストールした後は、メインの設定ファイル {{ic|/boot/grub/grub.cfg}} を生成する必要があります。生成されるファイルは {{ic|/etc/default/grub}} の様々なオプションや {{ic|/etc/grub.d/}} のスクリプトによって設定されます。

追加の設定をしていない場合、設定ファイル自動生成スクリプトは、ブートさせるシステムの root ファイルシステムを見つけて、その情報を設定ファイルに保存します。これを成功させるには、システムを起動させているか、またはシステムに chroot していることが重要です。

{{Note|1=<nowiki></nowiki>
* 設定ファイルのパスは {{ic|/boot/grub/grub.cfg}} です、{{ic|/boot/grub/i386-pc/grub.cfg}} ではありません。
* [[chroot]] や [[systemd-nspawn]] コンテナで ''grub-mkconfig'' を実行しようとした場合、次のようなエラーによりうまく行かないことがあります: {{ic|grub-probe: error: failed to get canonical path of ''/dev/sdaX''}}。この場合、[https://bbs.archlinux.org/viewtopic.php?pid=1225067#p1225067 このフォーラムの投稿]で記述されているように [[arch-chroot]] を使ってみて下さい。
* [[LVM]] を使って GRUB を [[chroot]] 環境内でインストールしているときに {{ic|grub-mkconfig}} が不定期に固まる場合、[[#Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds]] を見てください。
}}

''grub-mkconfig'' ツールを使って {{ic|/boot/grub/grub.cfg}} を生成してください:

# grub-mkconfig -o /boot/grub/grub.cfg

デフォルトで、生成スクリプトは生成する設定に Arch Linux の[[カーネル]]をメニューエントリに自動で追加します。

{{Tip|
* [[カーネル]]をインストール/アンインストールした後に上記の''grub-mkconfig'' コマンドを再度実行する必要があります。
* 複数の GRUB エントリを管理するためのヒントとして、例えば {{Pkg|linux}} と {{Pkg|linux-lts}} の両方を使用している場合、[[GRUB/ヒントとテクニック#複数のエントリ]]を見てください。
}}

他のオペレーティングシステムのエントリを自動的に追加する方法は [[#他の OS の検出]] を見てください。

{{ic|/etc/grub.d/40_custom}} を編集して {{ic|/boot/grub/grub.cfg}} を再生成することで、追加のカスタムメニューエントリを追加することができます。または、{{ic|/boot/grub/custom.cfg}} を作成して、そこにカスタムのメニューエントリを追加することもできます。{{ic|/boot/grub/custom.cfg}} を編集した後に ''grub-mkconfig'' を再度実行する必要はありません。{{ic|/etc/grub.d/41_custom}} には生成された設定ファイルを読み込むために必要な {{ic|source}} 文があるからです。

{{Tip|{{ic|/etc/grub.d/40_custom}} は {{ic|/etc/grub.d/''nn''_custom}} を作成する際のテンプレートとして使うことができます。{{ic|''nn''}} の部分は優先順位で、スクリプトを実行する順番を決定します。スクリプトを実行する順番は GRUB ブートメニューエントリの配置を決定します。実行しなければならないスクリプトを確実に実行させるために、{{ic|''nn''}} は {{ic|06}} よりも大きくする必要があります。}}

カスタムのメニューエントリの例は [[#ブートメニューエントリの例]] を見てください。

==== 他の OS の検出 ====

''grub-mkconfig'' がインストールされている他のシステムを検索して自動的にメニューに追加するには、 {{Pkg|os-prober}} パッケージを [[インストール]] して、他のシステムが起動するパーティションを [[マウント]] してください。その後、''grub-mkconfig'' を再実行します。もし、以下のような出力が出たら {{ic|Warning: os-prober will not be executed to detect other bootable partitions}} {{ic|/etc/default/grub}} を編集してコメントを追加、もしくはコメントアウトを外してください。
GRUB_DISABLE_OS_PROBER=false を追加、もしくはコメントアウトを外します。
その後、もう一度試してください。

{{Note|毎回他の OS を含めるために ''grub-mkconfig'' を実行するたびにパーティションをマウントすることを忘れないでください。}}

{{Tip|最後に選択したブートエントリを GRUB に記憶させたい場合もあるでしょう、[[GRUB/ヒントとテクニック#以前のエントリを思い出させる]] を参照してください。}}

===== MS Windows =====

UEFI モードでインストールされた Windows の場合、Windows Boot Manager ({{ic|bootmgfw.efi}}) を含んでいる [[EFI システムパーティション]]がマウントされていることを確認してください。root として {{ic|os-prober}} を実行すると、Windows のエントリを検出・生成します。

BIOS モードでインストールされた Windows の場合、Windows ''システムパーティション'' をマウントしてください(そのパーティションの[[永続的なブロックデバイスの命名#by-label|ファイルシステムラベル]]は {{ic|System Reserved}} か {{ic|SYSTEM}} であるはずです)。root として {{ic|os-prober}} を実行すると、Windows のエントリを検出・生成します。

{{Note| BIOS モードでインストールされた Windows の場合:
* NTFS パーティションはデフォルトの Linux ドライバでマウントすると、必ずしも検出されないかもしれません。GRUB が検出しない場合、[[NTFS-3G]] をインストールして再マウントしてみてください。
{{Out of date| Windows 7 以降、{{ic|bootmgr}} は[[Wikipedia:System partition and boot partition#Microsoft definition|システムパーティション]]内にあり、このパーティションは暗号化されていません。}}
* 暗号化された Windows パーティションは、マウントする前に暗号化を解除する必要があるかもしれません。BitLocker では、[[cryptsetup]] や {{AUR|dislocker}} で実行できます。これで {{Pkg|os-prober}} が正しいエントリを追加できるはずです。}}

==== 追加引数 ====

カスタムの追加引数を Linux イメージに渡すために、{{ic|/etc/default/grub}} で {{ic|GRUB_CMDLINE_LINUX}} と {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} 変数を設定することができます。この2つは {{ic|grub.cfg}} を生成するときに互いに標準のブートエントリに追加されます。''recovery'' ブートエントリについては、{{ic|GRUB_CMDLINE_LINUX}} だけが生成時に使われます。

両方を使う必要はありませんが、上手く使えば便利です。例えば、{{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} ({{ic|sda'''X'''}} はスワップパーティション) を使ってハイバネーションの後の復帰を有効にすることができます。生成された recovery ブートエントリでは resume やメニューエントリからの起動中のカーネルメッセージを表示しない ''quiet'' は使われません。そして、他の (標準の) メニューエントリではオプションとして使われます。

GRUB のリカバリエントリを生成するには {{ic|/etc/default/grub}} で {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} をコメントアウトする必要があります。

また、{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}} を使うこともできます ({{ic|${swap_uuid} }} は swap パーティションの [[永続的なブロックデバイスの命名|UUID]] に置き換えて下さい)。

複数のエントリを使う時はダブルクォートの中でスペースで区切って下さい。resume と systemd の両方を使うなら次のようになります:

{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}

詳しくは[[カーネルパラメータ]]を見て下さい。

==== LVM ====

[[LVM]] を {{ic|/boot}} で使っている場合、メニューエントリの行の前に次を追加してください:

insmod lvm

そしてメニューエントリで root を次のように指定してください:

set root=lvm/''lvm_group_name''-''lvm_logical_boot_partition_name''

サンプル:

# (0) Arch Linux
menuentry "Arch Linux" {
insmod lvm
set root=lvm/VolumeGroup-lv_boot
# you can only set following two lines
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro
initrd /initramfs-linux.img
}

==== RAID ====

GRUB には RAID ボリュームの便利な制御機能があります。ボリュームをネイティブに指定できる {{ic|insmod mdraid09}} または {{ic|mdraid1x}} を追加する必要があります。例えば、{{ic|/dev/md0}} は次のようになります:
set root=(md/0)

一方パーティション済みの RAID ボリューム (例: {{ic|/dev/md0p1}}) は次のとおりです:
set root=(md/0,1)

RAID1 を GPT ef02/'BIOS boot partition' のドライブ上の、{{ic|/boot}} パーティション (もしくは RAID1 root パーティション上の {{ic|/boot}}) で使っている場合に grub をインストールするには、ドライブの両方で ''grub-install'' を実行するだけです。例:
# grub-install --target=i386-pc --debug /dev/sda
# grub-install --target=i386-pc --debug /dev/sdb
ここで {{ic|/boot}} がある RAID1 アレイは {{ic|/dev/sda}} と {{ic|/dev/sdb}} に収容されます。

{{Note|GRUB は2015年9月現在 [[Btrfs]] の RAID 0/1/10 からの起動をサポートしていますが、RAID 5/6 からの起動はサポートしていません。RAID 5/6 では GRUB によってサポートされている [[mdadm]] を使ってください。}}

==== 暗号化された /boot ====

GRUB には暗号化された {{ic|/boot}} を起動するための特別なサポートがあります。これは、[[LUKS]] ブロックデバイスをアンロックして、GRUB の設定を読み込み、[[initramfs]] と [[カーネル]] をそのブロックデバイスからロードすることにより行われます。このオプションは[[dm-crypt/特記事項#暗号化されていない boot パーティションのセキュア化|暗号化されていないブートパーティション]]の問題を解決することを試みます。

{{Tip|{{ic|/boot}} を別のパーティションに保存する必要は'''ありません'''。システムのルート {{ic|/}} ディレクトリツリー下に保存することもできます。}}

{{Warning|GRUB 2.06 の LUKS2 に対するサポートは限られています。詳細は [[#LUKS2]] セクションを見てください。}}

この機能を有効化するには、{{ic|/boot}} が存在するパーティションを通常通り [[LUKS]] を使って暗号化してください。そして、以下のオプションを {{ic|/etc/default/grub}} に追加してください。

{{hc|/etc/default/grub|output=
GRUB_ENABLE_CRYPTODISK=y
}}

このオプションは grub-install により使用され、grub の {{ic|core.img}} を生成します。なので、このオプションを追加した後に [[#インストール|GRUB を(再)インストール]]することを忘れないでください。

これだけだと、パスフレーズを2回入力させられることになります。1回目は起動の初期段階で GRUB が {{ic|/boot}} マウントポイントをアンロックするためのもので、2回目は iniramfs により実装されている root ファイルシステムそれ自体をアンロックするためのものです。[[dm-crypt/デバイスの暗号化#キーファイルを initramfs に埋め込む|キーファイル]]を使えば、これを防げます。

{{Warning|
* [[#メイン設定ファイルの生成|メインの設定ファイルを生成]]したいときは、{{ic|/boot}} がマウントされていることを確認してください。
* {{ic|/boot}} マウントポイントが関与するシステムアップデートを行うために、アップデートする前に、暗号化された {{ic|/boot}} がアンロックされていて、かつ、マウントされていることを確認してください。{{ic|/boot}} パーティションが別にある場合、[[crypttab]] を[[dm-crypt/デバイスの暗号化#キーファイルを initramfs に埋め込む|キーファイル]]と一緒に使うことでこれを自動化できます。
}}

{{Note|
* 特殊なキーマップを使用している場合、デフォルトの GRUB はそれが何なのかわかりません。このことは、[[LUKS]] ブロックデバイスをアンロックするためにどのようにしてパスフレーズを入力するかに関連しています。[[GRUB/ヒントとテクニック#初期ブートにおけるコアイメージの手動設定]] を参照してください。
* パスワードの入力画面が表示されない問題が発生した場合(cryptouuid や cryptodisk、"device not found" に関係するエラー)、{{ic|1=--modules="part_gpt part_msdos"}} を {{ic|grub-install}} コマンドの最後に付け加えて GRUB を再インストールしてみてください。
}}

{{Tip|1=[https://bbs.archlinux.org/viewtopic.php?id=234607 pacman フック] を使用すれば、{{ic|/boot}} 内のファイルにアクセスする必要のあるアップグレード時に {{ic|/boot}} を自動マウントできます。}}

===== LUKS2 =====

GRUB 2.06 の LUKS2 に対するサポートは限られています。[https://savannah.gnu.org/bugs/?55093 GRUB bug #55093] を参照してください。

{{Tip|1=LUKS2 サポートのパッチが施された {{AUR|grub-improved-luks2-git}} を使用できます。}}

* Argon2id (''cryptsetup'' デフォルト) と Argon2i PBKDF はサポートされていません。PBKDF2 のみのサポートです。
* {{ic|grub-install}} は LUKS2 のアンロックに使用できるコアイメージの作成をサポートしていません。回避策については、下記のコメントや {{AUR|grub-git}} のコメントを参照してください。

[[#インストール]] セクションで説明されているように {{ic|grub-install}} を使用してください。しかし、生成される EFI バイナリは LUKS2 をサポートしておらず、置き換える必要があります。

{{ic|grub-pre.cfg}} を作成してください。下記の {{ic|/dev/nvme0n1p2}} は適宜置き換えてください。コメントにあるコマンドの出力は暗号化されたパーティションの UUID からハイフンを除いたものになります。

{{bc|
# ... の部分は次のコマンドの出力に置き換えてください: lsblk -no TYPE,UUID ''/dev/nvme0n1p2''<nowiki> | awk '$1=="part"{print $2}' | tr -d -
set crypto_uuid=...
cryptomount -u $crypto_uuid
# LVM を使用する場合、crypto0 の部分を lvm/NameOfVolume のように置き換えてください。
set root=crypto0
set prefix=($root)/boot/grub
insmod normal
normal
</nowiki>}}

以下のコマンドを実行してください。[[LVM]] を使用する場合、{{ic|lvm}} を追加してください。必要であれば {{ic|ext2}} を {{ic|btrfs}} に置き換えてください:

$ grub-mkimage -p /boot/grub -O x86_64-efi -c grub-pre.cfg -o /tmp/grubx64.efi luks2 part_gpt cryptodisk gcry_rijndael pbkdf2 gcry_sha256 ext2

ESP にコピーしてください:

# install -v /tmp/grubx64.efi ''esp''/EFI/GRUB/grubx64.efi

起動中に無効なパスフレーズを入力して GRUB のレスキューシェルに入った場合、{{ic|cryptomount -a}} を実行してすべての(できれば1つだけ)暗号化されたパーティションをマウントしてみてください。または、{{ic|cryptomount -u $crypto_uuid}} を使用して特定のパーティションをマウントしてください。その後、通常通り {{ic|insmod normal}} と {{ic|normal}} で進めてください。

正しいパスフレーズを入力したが {{ic|Invalid passphrase}} というエラーにより即座に戻される場合、正しい暗号化モジュールを指定していることを確認してください。{{ic|cryptsetup luksDump ''/dev/nvme0n1p2''}} を使って、ハッシュ関数(SHA-256, SHA-512)とインストールされているモジュール({{ic|gcry_sha256}}, {{ic|gcry_sha512}})が一致するか、PBKDF アルゴリズムが pbkdf2 であるかを確認してください。{{ic|cryptsetup luksConvertKey --hash ''sha256'' --pbkdf pbkdf2 ''/dev/nvme0n1p2''}} を使えば、ハッシュと PBDKDF アルゴリズムを今あるキーに対して変更することができます。通常の状況では、パスフレーズが処理されるのに数秒掛かるはずです。

=== grub.cfg のカスタマイズ ===

このセクションでは ''grub-mkconfig'' に頼らずに {{ic|/boot/grub/grub.cfg}} 内にある GRUB のブートエントリーを手動で作成する方法について言及します。

基本的な GRUB の設定ファイルでは以下のオプションが使用されます。

* {{ic|(hd''X'',''Y'')}} はディスク ''X'' 上に存在するパーティション ''Y'' を表します。パーティション番号は1から始まり、ディスク番号は0から始まります。
* {{ic|1=set default=''N''}} はデフォルトのブートエントリを表し、ユーザーが操作せずにタイムアウトした後に選択されます。
* {{ic|1=set timeout=''M''}} は、ユーザーの選択が無かった場合に ''M'' 秒の間待ってデフォルトのブートエントリが起動されることを表します。
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} は {{ic|title}} というタイトルのブートエントリを表します。
* {{ic|1=set root=(hd''X'',''Y'')}} はカーネルと GRUB モジュールが格納されているブートパーティションを表します。(boot は分離されたパーティションである必要はなく、単に "root" パーティション({{ic|/}})下にあるディレクトリを指定しても構いません)

==== ブートメニューエントリの例 ====

{{Tip| 以下のブートエントリは ''grub-mkconfig'' によって生成された {{ic|/boot/grub/grub.cfg}} でも使用可能です。以下を {{ic|/etc/grub.d/40_custom}} に追加して[[#メイン設定ファイルの生成|メインの設定ファイルを再生成]]するか、あるいは以下を直接 {{ic|/boot/grub/custom.cfg}} に追加してください。}}

複数の GRUB エントリーを管理するヒントとして、例えば {{Pkg|linux}} と {{Pkg|linux-lts}} カーネルを同時使用している場合は [[GRUB/ヒントとテクニック#複数のエントリ]] を見てください。

[[Archiso]] と [[Archboot]] のブートメニューエントリについては [[マルチブート USB ドライブ#ブートエントリ]] を見てください。

===== GRUB コマンド =====

====== "Shutdown" メニューエントリ ======

{{bc|
menuentry "System shutdown" {
echo "System shutting down..."
halt
}
}}

====== "Restart" メニューエントリ ======

{{bc|
menuentry "System restart" {
echo "System rebooting..."
reboot
}
}}

====== "UEFI Firmware Settings" メニューエントリ ======

{{bc|1=
if [ ${grub_platform} == "efi" ]; then
menuentry 'UEFI Firmware Settings' --id 'uefi-firmware' {
fwsetup
}
fi
}}

===== EFI バイナリ =====

UEFI モードで起動している場合、GRUB は他の EFI バイナリをチェインロードできます。

{{Tip|1=GRUB が UEFI モードで起動している時にだけメニューエントリを表示するには、メニューエントリを {{ic|if}} 文で囲ってください。

{{bc|1=
if [ ${grub_platform} == "efi" ]; then
''UEFI のときだけ表示するメニューエントリをここへ''
fi
}}

}}

====== UEFI シェル ======

[[EFI システムパーティション]]直下に [[Unified Extensible Firmware Interface#UEFI シェル|UEFI シェル]] を置いてメニューエントリに追加すれば、UEFI シェルを起動できます:

{{bc|1=
menuentry "UEFI Shell" {
insmod fat
insmod chain
search --no-floppy --set=root --file /shellx64.efi
chainloader /shellx64.efi
}
}}

====== gdisk ======

[[gdisk#gdisk EFI アプリケーション|gdisk EFI アプリケーション]]をダウンロードして {{ic|gdisk_x64.efi}} を {{ic|''esp''/EFI/tools/}} にコピーしてください。

{{bc|1=
menuentry "gdisk" {
insmod fat
insmod chain
search --no-floppy --set=root --file /EFI/tools/gdisk_x64.efi
chainloader /EFI/tools/gdisk_x64.efi
}
}}

====== Unified カーネルイメージをチェインロード ======

[[セキュアブート]]に従って生成したか他の方法によって生成した [[Unified カーネルイメージ]]を持っているならば、それをブートメニューに追加できます。例えば:

{{bc|1=
menuentry "Arch Linux" {
insmod fat
insmod chain
search --no-floppy --set=root --fs-uuid ''FILESYSTEM_UUID''
chainloader /EFI/Linux/Arch-linux.efi
}
}}

===== デュアルブート =====

====== GNU/Linux ======

もう一つのディストリビューションが {{ic|sda2}} パーティションにあると仮定します:

{{bc|1=
menuentry "Other Linux" {
set root=(hd0,2)
linux /boot/vmlinuz (必要であれば追加のオプションをここへ)
initrd /boot/initrd.img (カーネルが必要とする/使用するイメージはここへ)
}
}}

代わりに UUID やファイルシステムのラベルで GRUB に正しいパーティションを探させるには:

{{bc|1=
menuentry "Other Linux" {
# UUID が 763A-9CB6 だとすると
search --no-floppy --set=root --fs-uuid 763A-9CB6

# OTHER_LINUX というラベルで探す (パーティションラベルが曖昧でないことを確認してください)
#search --no-floppy --set=root --label OTHER_LINUX

linux /boot/vmlinuz (必要であれば追加のオプションをここへ。例えば、root=UUID=763A-9CB6)
initrd /boot/initrd.img (カーネルが必要とする/使用するイメージはここへ)
}
}}

もう一つのディストリビューションが、インストール済みの GRUB と {{ic|grub.cfg}}、カーネル、initramfs のある有効な {{ic|/boot}} フォルダーをすでに持っているならば、GRUB にその {{ic|grub.cfg}} ファイルを起動中にその場で読み込ませることができます。例えば、{{ic|hd0}} と4番目の GPT パーティションの場合:

{{bc|1=
menuentry "configfile hd0,gpt4" {
insmod part_gpt
insmod btrfs
insmod ext2
set root='hd0,gpt4'
configfile /boot/grub/grub.cfg
}
}}

このエントリを選ぶと GRUB は他のボリュームからその {{ic|grub.cfg}} を読み込み、メニューを表示させます。{{ic|configfile}} ファイル内のコマンドによって環境変数が変更されても、{{ic|configfile}} から返ると環境変数の変更はすべて破棄されます。始めの GRUB メニューに戻る場合は {{ic|Esc}} を押してください。

====== UEFI/GPT モードでインストールされた Windows ======

このモードではメニューエントリが選択されると Windows ブートローダーの場所を発見し、GRUB のあとにブートローダーをチェインロードします。ここでするべきことは主に Windows の [[EFI システムパーティション]]を見つけて、そのパーティションから Windows のブートローダーを実行することです。

{{Note| このメニューエントリは、UEFI ブートモードで実行中であり、かつ Windows のビット数が UEFI のビット数と一致する場合にのみ機能します。BIOS モードでインストールされた GRUB では機能しません。さらなる情報については [[Windows と Arch のデュアルブート#Windows の UEFI と BIOS の制限]]と [[Windows と Arch のデュアルブート#ブートローダーの UEFI と BIOS の制限]] をご覧ください。}}

{{bc|1=
if [ "${grub_platform}" == "efi" ]; then
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI/GPT" {
insmod part_gpt
insmod fat
insmod chain
search --no-floppy --fs-uuid --set=root $hints_string $fs_uuid
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
fi
}}

{{ic|$hints_string}} と {{ic|$fs_uuid}} は以下の2つのコマンドで得られます。

{{ic|$fs_uuid}} コマンドは EFI システムパーティションの UUID を割り出します。

{{hc|1=# grub-probe --target=fs_uuid ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=
1ce5-7f28
}}

代わりに、{{ic|blkid}} を(root として)実行して、EFI システムパーティションの UUID をそこから読み込むこともできます。

{{ic|$hints_string}} コマンドは EFI システムパーティションの場所を割り出します。以下の例ではハードドライブ0にあります:

{{hc|1=# grub-probe --target=hints_string ''esp''/EFI/Microsoft/Boot/bootmgfw.efi|2=
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1
}}

以上の2つのコマンドでは Windows が使用する ESP が {{ic|''esp''}} にマウントされていると仮定しています。Windows である以上、Windows の EFI ファイルへのパスが異なる場合があるかもしれません。

====== BIOS/MBR モードでインストールされた Windows ======

{{Note| GRUB は {{ic|bootmgr}} ディレクトリの直接ブートをサポートしています。Windows を BIOS/MBR で起動するためにパーティションブートセクターを [https://www.gnu.org/software/grub/manual/grub.html#Chain_002dloading チェインロード]する必要はもはやありません。}}

{{Warning| {{ic|/bootmgr}} が存在する場所は'''システムパーティション'''であり、"本当"の Windows パーティション(通常、{{ic|C:}})ではありません。システムパーティションの[[永続的なブロックデバイスの命名#by-label|ファイルシステムラベル]]は {{ic|System Reserved}} か {{ic|SYSTEM}} であり、サイズは約100~549 MiB 程度です。さらなる情報については [[Wikipedia:System partition and boot partition]] をご覧ください。}}

このセクションを通して Windows のパーティションは {{ic|/dev/sda1}} にあると仮定します。パーティションが異なる場合は {{ic|hd0,msdos1}} という記述をすべて変更してください。

{{Note| 以下のメニューエントリは BIOS ブートモードでのみ機能します。UEFI モードでインストールされた GRUB では機能しません。[[Windows と Arch のデュアルブート#Windows の UEFI と BIOS の制限]]と [[Windows と Arch のデュアルブート#ブートローダーの UEFI と BIOS の制限]] をご覧ください。}}

両方の例で {{ic|''XXXXXXXXXXXXXXXX''}} はファイルシステムの UUID を表しています。UUID は {{ic|lsblk --fs}} コマンドを使って得られます。実際の UUID に置き換えてください。

Windows Vista/7/8/8.1/10 では:

{{bc|1=
if [ "${grub_platform}" == "pc" ]; then
menuentry "Microsoft Windows Vista/7/8/8.1/10 BIOS/MBR" {
insmod part_msdos
insmod ntfs
insmod ntldr
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''
ntldr /bootmgr
}
fi
}}

Windows XP では:

{{bc|1=
if [ "${grub_platform}" == "pc" ]; then
menuentry "Microsoft Windows XP" {
insmod part_msdos
insmod ntfs
insmod ntldr
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 ''XXXXXXXXXXXXXXXX''
ntldr /ntldr
}
fi
}}

{{Note| GRUB をインストールすると Windows 8 が汚染される場合があります。この場合、{{ic|\boot\bcd}} (エラーコード {{ic|0xc000000f}})のエラーにより Windows が起動できなくなります。これを直すには Windows 回復コンソール(インストールディスク上にある {{ic|cmd.exe}})を開いて、以下を実行してください:

X:\> bootrec.exe /fixboot
X:\> bootrec.exe /RebuildBcd

{{ic|bootrec.exe /Fixmbr}} を'''実行しない'''でください。GRUB が吹き飛びます。あるいはトラブルシューティングメニューにあるスタートアップ修復機能を使用できます。これは GRUB を吹き飛ばしませんし、ほとんどのエラーを修復します。
また、対象のハードドライブとブート可能ドライブの両方'''だけ'''を接続しておくほうが良いでしょう。通常、他のデバイスが接続されていると Windows はブート情報の修復に失敗します。}}

===== ラベルを使う =====

{{ic|search}} コマンドに対して {{ic|--label}} オプションを使えば、ファイルシステムに付けられた人間が読みやすい文字列であるラベルを使うことができます。まずはじめに、[[永続的なブロックデバイスの命名#by-label|ファイルシステムにラベルがあることを確認]]してください。

そして、ラベルを使ってエントリを追加してください。例えば:

menuentry "Arch Linux, session texte" {
search --label --set=root archroot
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro
initrd /boot/initramfs-linux.img
}

== コマンドシェルを使う ==

GRUB のモジュールを全て保存するには MBR は小さすぎるので、メニューと基本的なコマンドだけが MBR に入っています。GRUB の機能のほとんどは {{ic|/boot/grub}} 内のモジュールとして存在し、必要に応じて挿入されます。エラー状態になると (例: パーティションレイアウトが変更された場合) GRUB は起動に失敗します。このとき、コマンドシェルが表示されます。

GRUB は複数のシェル・プロンプトを提供しています。メニューの読込に問題があってもブートローダがディスクを見つけられるときは、"normal" シェルが出ます:
sh:grub>

深刻な問題があるときは (例: GRUB が必要なファイルを見つけられない)、代わりに "rescue" シェルが出ます:
grub rescue>

rescue シェルは通常のシェルの制限されたサブセットで、使える機能が少なくなっています。rescue シェルが出てきた時は、まず "normal" モジュールの挿入を試して、"normal" シェルを起動してみて下さい:
grub rescue> set prefix=(hdX,Y)/boot/grub
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod
rescue:grub> normal

=== ページャのサポート ===

GRUB はページャをサポートしており長い出力をするコマンド ({{ic|help}} コマンドなど) を読むことができます。これは通常のシェルモードでしか動作せずレスキューモードでは使えません。ページャを有効にするには、GRUB コマンドシェルで次を入力して下さい:
sh:grub> set pager=1

=== コマンドシェル環境を使ってオペレーティングシステムを起動する ===

grub>

GRUB のコマンドシェル環境を使ってオペレーティングシステムを起動することが可能です。
通常は'''チェインロード'''を使ってドライブやパーティションから Windows / Linux を起動するということが考えられます。

''チェインロード''は現在のブートローダから別のブートローダをロードすることを意味します。

他のブートローダはディスクの最初 (MBR) やパーティションの最初に埋め込むことができます。

==== パーティションのチェインロード ====

set root=(hdX,Y)
chainloader +1
boot

X=0,1,2...
Y=1,2,3...

例えば最初のハードディスクの最初のパーティションに保存された Windows をチェインロードするには:

set root=(hd0,1)
chainloader +1
boot

同じようにパーティションにインストールされた GRUB をチェインロードすることもできます。

==== ディスクやドライブのチェインロード ====

set root=hdX
chainloader +1
boot

==== UEFI モードでインストールされた Windows/Linux のチェインロード ====

insmod ntfs
set root=(hd0,gpt4)
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi
boot

''insmod ntfs'' を使うことで ntfs ファイルシステムモジュールをロードして Windows をロードすることができます。上記の例では (hd0,gpt4) または /dev/sda4 が EFI System Partition (ESP) です。''chainloader'' 行のエントリはチェインロードする .efi ファイルのパスを指定しています。

==== 通常のロード ====

[[#rescue コンソールを使う]] の例を見て下さい。

=== rescue コンソールを使う ===

まず [[#コマンドシェルを使う]] を見て下さい。標準シェルを有効にできない場合、ライブ CD や他のレスキューディスクを使って起動し、設定のエラーを直して GRUB を再インストールという方法があります。ただし、そのようなブートディスクはいつも使えるというわけではありません (もしくは必要ありません); レスキューコンソールは驚くほど堅牢です。

GRUB rescue で利用できるコマンドには {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, {{ic|unset}} があります。この例では {{ic|set}} と {{ic|insmod}} を使います。{{ic|set}} は変数を修正し {{ic|insmod}} は新しいモジュールを挿入して機能を追加します。

始める前に、ユーザーは自分の {{ic|/boot}} パーティションの位置を知っていなければなりません (分割パーティションなのか、root 下のサブディレクトリなのか):
grub rescue> set prefix=(hdX,Y)/boot/grub

X は物理ドライブ番号、Y はパーティション番号に置き換えてください。

{{Note|boot パーティションを分割している場合、パスから {{ic|/boot}} を省いて下さい (つまり、{{ic|1=set prefix=(hdX,Y)/grub}} と入力する)。}}

コンソールの機能を拡張するために、{{ic|linux}} モジュールを挿入します:
grub rescue> insmod i386-pc/linux.mod

もしくは:
grub rescue> insmod linux

これで {{ic|linux}} と {{ic|initrd}} コマンドが使えます、これらのコマンドは慣れているはずです ([[#設定]] を見て下さい)。

例えば、Arch Linux を起動:
set root=(hd0,5)
linux /boot/vmlinuz-linux root=/dev/sda5
initrd /boot/initramfs-linux.img
boot

boot パーティションを分割しているなら、行を変更する必要があります:
{{Note|上の prefix と同じような形式で boot パーティションを手動で指定する必要があります。}}
set root=(hd0,5)
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6
initrd (hdX,Y)/initramfs-linux.img
boot

{{Note|{{ic|linux}} コマンドの実行中に {{ic|error: premature end of file /YOUR_KERNEL_NAME}} と表示される場合は、代わりに {{ic|linux16}} を使ってみて下さい。}}

Arch Linux 環境のブートに成功したら、必要に応じて {{ic|grub.cfg}} を修正し GRUB を再インストールすることができます。

GRUB を再インストールして問題を完全に修正するには、必要応じて {{ic|/dev/sda}} を変更します。詳しくは [[#インストール]] を見て下さい。

== GRUB を消去 ==

一般に、''grub'' を消去するにはインストール手順を逆の順番で行う必要があります。おそらく最後には残ったものをすべて綺麗にします。しかし、作業を始める前に、''grub'' を削除した後に PC が起動するかどうかや、どう起動させるかを考えておかなければなりません。''grub'' を削除したい理由はおそらく他のブートローダーを使いたくなったからでしょう。安全ですが少し難しい方法は ''grub'' を削除する前に他のブートローダーが動作することを確認することです。

他のブートローダーをインストールする前に ''grub'' を削除するときでも、他の如何なる場合でも、UEFI の場合は以下を実行してください:
$ efibootmgr
そして、他のブートローダーが {{ic|BootOrder}} の行にあることを確認してください。もし ''grub'' が削除されていない場合、他のブートローダーが ''grub'' の前にあるはずです。もし ''grub'' がすでに削除されている場合、''grub'' はその行に存在しないはずです。しかし、これは PC が他のブートローダーを起動するための必要条件であり、十分条件ではないことに注意してください。また、''grub'' を完全に削除するための十分条件でもありません。

UEFI マシンと非 UEFI マシンの両方において、{{ic|grub-install}} は ''grub'' のインストール作業の一部として手動で実行されます。UEFI の場合、{{ic|grub-install}} は仕事の1つとして {{ic|efibootmgr --create}} の実行と等価なことを行います。''grub'' を削除するには {{ic|grub-install}} の成果物を削除する必要があります。{{ic|efibootmgr --create}} と反対のことをするコマンドは {{ic|efibootmgr --delete-bootnum}} やこれと等価なプログラムです。{{ic|efibootmgr --delete-bootnum}} コマンドを実行すべきブートエントリの番号を得る一つの方法は(引数なしの) {{ic|efibootmgr}} の出力です。

{{ic|grub-install}} は {{ic|/boot/grub}} ディレクトリを作成し、これは手動で削除する必要があります。しかし、''grub'' を再びインストールするためにこのディレクトリを残しておきたいユーザーもいるでしょう。

GPT/UEFI に移行した後に [[パーティショニング#Master Boot Record (bootstrap code)|MBR boot code]] を削除したい場合は [[dd#ブートローダーの削除|dd を使って]]ください:

# dd if=/dev/zero of=/dev/sd''X'' bs=440 count=1

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

=== サポートのないファイルシステム ===

GRUB が root のファイルシステムをサポートしていない場合、代替の {{ic|/boot}} パーティションをサポートのあるファイルシステムで作成する必要があります。開発バージョンの GRUB である {{aur|grub-git}} が該当するファイルシステムをネイティブサポートしている場合があります。

GRUB をサポートされないファイルシステムで使用した場合、ドライブの [[UUID]] を抽出できないため、GRUB は古典的で非永続的な {{ic|/dev/''sdXx''}} 名を使います。この場合、{{ic|/boot/grub/grub.cfg}} を手動で編集し、{{ic|1=root=/dev/''sdXx''}} を {{ic|1=root=UUID=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''}} のように置き換える必要があるかもしれません。{{ic|blkid}} コマンドを使えばデバイスの UUID を得られます。[[永続的なブロックデバイスの命名]] を見てください。

GRUB はバージョン 2.0.4 より [[F2FS]] をサポートしていますが、{{ic|extra_attr}} フラグを有効にして作成された F2FS パーティションからブートファイルを正しく読み込むことができません。

=== デバッグメッセージを有効にする ===

{{Note|この変更は[[#メイン設定ファイルの生成|メインの設定ファイルを生成]]すると上書きされます。}}

以下を {{ic|grub.cfg}} に追加してください:

set pager=1
set debug=all

=== msdos-style エラーメッセージ ===

grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.
However, blocklists are UNRELIABLE and its use is discouraged.
grub-setup: error: If you really want blocklists, use --force.

このエラーは VMware コンテナに GRUB をインストールしようとすると起こることがあります。詳しくは [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 ここ] を読んで下さい。最初のパーティションが MBR (ブロック 63) のすぐ後ろから始まっていて、最初のパーティションの前に通常の 1 MiB のスペース (2048 ブロック) がない場合に起こります。[[#Master Boot Record (MBR) 特有の手順]] を読んで下さい。

=== UEFI ===

==== よくあるインストール時のエラー ====

* grub-install の実行時に sysfs や procfs に関する問題が表示される場合、{{ic|modprobe efivars}} を実行してください。[[Unified Extensible Firmware Interface#UEFI 変数]] を参照。
* {{ic|--target}} と {{ic|--directory}} オプションのどちらかがないと、{{ic|grub-install}} はどこにファームウェアをインストールすればいいのか決められません。そのような場合 {{ic|grub-install}} は {{ic|source_dir does not exist. Please specify --target or --directory}} というメッセージを表示します。
* grub-install を実行した後、パーティションが EFI パーティションではないというような表示がされる場合、おそらくパーティションが {{ic|Fat32}} ではありません。

==== ファームウェアブートマネージャーに GRUB エントリを作成する ====

{{ic|grub-install}} は自動的にブートマネージャーにメニューエントリを追加しようと試みます。もし GRUB がそれを行わない場合、[[UEFI#efibootmgr]] を見て、{{ic|efibootmgr}} を使ってメニューエントリを作成する指示を読んでください。しかし、[[UEFI#ISO から UEFI ブータブル USB を作成する]] にあるように、よくある原因は CD/USB を UEFI モードで起動していないというものです。

==== レスキューシェルが起動する ====

GRUB がロードしたときにエラーを表示せずにレスキューシェルを起動する場合、おそらく {{ic|grub.cfg}} が存在しなかったり間違った場所に置かれていることが原因です。GRUB UEFI を {{ic|--boot-directory}} でインストールして {{ic|grub.cfg}} がなかったり、ブートパーティションのパーティション番号 ({{ic|grubx64.efi}} ファイルにハードコードされています) が変更されているときにこの問題が発生します。

==== GRUB UEFI がロードされない ====

EFI の動作の例:
{{hc|# efibootmgr -v|
BootCurrent: 0000
Timeout: 3 seconds
BootOrder: 0000,0001,0002
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI
}}

画面が数秒間真っ暗になってその後次のブートオプションが試行される場合、[https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 この投稿]によると、GRUB を root パーティションに移動することで直るかもしれません。ブートオプションは削除して後でまた作成する必要があります。GRUB のエントリは次のようにしてください:
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)

==== デフォルト/フォールバックのブートパス ====

一部の UEFI ファーウェアではブート可能なファイルが既知の場所に存在している必要があり、それ以外の場所では UEFI NVRAM ブートエントリに表示されません。この場合、{{ic|grub-install}} が、GRUB を起動するエントリが {{ic|efibootmgr}} によって追加されたと報告するでしょうが、VisualBIOS のブート順序セレクターには表示されません。解決策は GRUB をデフォルト/フォールバックのブートパスにインストールすることです('''--removable''' を追加してください):

# grub-install --target=x86_64-efi --efi-directory=''esp'' '''--removable'''

あるいは、すでにインストールされた GRUB の EFI 実行ファイルをデフォルト/フォールバックのパスに移動することができます:

# mv ''esp''/EFI/grub ''esp''/EFI/BOOT
# mv ''esp''/EFI/BOOT/grubx64.efi ''esp''/EFI/BOOT/BOOTX64.EFI

=== Invalid signature ===

(パーティションを再設定したりハードドライブを追加した後) Windows を起動しようとしたときに "invalid signature" エラーが起こる場合、GRUB のデバイス設定を移動（削除）して再設定してください:
# mv /boot/grub/device.map /boot/grub/device.map-old
# grub-mkconfig -o /boot/grub/grub.cfg
これで {{ic|grub-mkconfig}} は Windows を含む全てのブートオプションを記述したはずです。これで動作したら、{{ic|/boot/grub/device.map-old}} は削除してください。

=== 起動中にフリーズする ===

GRUB がカーネルと initial ramdisk をロードした後、エラーを出さずにブートが固まる場合、{{ic|add_efi_memmap}} カーネルパラメータを取り除いてみてください。

=== 他の OS から Arch が見つからない ===

他のディストリビューションで {{ic|os-prober}} を使って Arch Linux を自動的に検索できないという報告が複数確認されています。この問題が発生する場合、{{ic|/etc/lsb-release}} をおくことで検知が改善されると報告されています。このファイルと更新ツールは[[公式リポジトリ]]にある {{pkg|lsb-release}} パッケージから利用可能です。

=== chroot でインストールした時に警告が表示される ===

chroot 環境で (例えばシステムのインストール中に) LVM システムに GRUB をインストールする場合、{{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} または {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning}} などの警告が表示されることがあります。これは {{ic|/run}} が chroot 中は利用できないのが原因です。これらの警告によってシステムが起動できなくなるということはないので、安心してインストールを続行してください。

=== GRUB のロードが遅い ===

ディスク容量が残りわずかの場合 GRUB がロードされるのにかなり時間がかかることがあります。起動が遅い場合 {{ic|/boot}} や {{ic|/}} に十分な空き容量があるか確認してください。

=== error: unknown filesystem ===
GRUB が {{ic|error: unknown filesystem}} と出力して起動しない理由はいくつか考えられます。[[UUID]] が正しいこと、全てのファイルシステムが問題なく、GRUB によってサポートされていることが確認できる場合、[[#GUID Partition Table (GPT) 特有の手順|BIOS Boot Partition]] がドライブの最初の 2TB の中にない可能性があります [https://bbs.archlinux.org/viewtopic.php?id=195948]。適当なパーティショニングツールを使ってパーティションが最初の 2TB 以内にあるようにして、GRUB を再インストール・再設定してください。

また、このエラーは [[ext4]] ファイルシステムがいくつかの機能をサポートしていないことが原因かもしれません:

* {{ic|large_dir}} - サポートされません。
* {{ic|metadata_csum_seed}} - GRUB 2.11 でサポートされます([https://git.savannah.gnu.org/cgit/grub.git/commit/?id=7fd5feff97c4b1f446f8fcf6d37aca0c64e7c763 commit]).

{{Warning| {{ic|/boot}} ファイルシステム上で[[ファイルシステム]]の新しい機能を有効化する前に、GRUB がそれらをサポートしていることを確認してください。}}

=== grub-reboot で再設定されない ===

GRUB は Btrfs のルートパーティションに書き込むを行うことができません [https://bbs.archlinux.org/viewtopic.php?id=166131]。grub-reboot を使って他のエントリを起動した場合、ディスク上の環境を更新することができなくなります。(ディストリビューションを切り替えるなどの場合に) 他のエントリから grub-reboot を実行するか他のファイルシステムを使ってください。{{ic|grub-editenv create}} を実行して {{ic|/etc/default/grub}} に {{ic|GRUB_DEFAULT<nowiki>=</nowiki>0}} を設定することでエントリをリセットできます (設定後は {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} を行ってください)。

=== Btrfs のせいでインストールができない ===

パーティションテーブルを作成しないで Btrfs を使ってドライブをフォーマットしている場合 (例: {{ic|/dev/sdx}})、後からパーティションテーブルを書き込むと、Btrfs のフォーマットが一部残留します。ほとんどのユーティリティや OS は残留した Btrfs を認識できないため、GRUB は (たとえ --force が付けられていても) インストールを拒否します:

# grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
# grub-install: error: filesystem `btrfs' doesn't support blocklists.

ドライブを完全に消去してもいいですが、{{ic|wipefs -o 0x10040 /dev/sdx}} を使えばデータを残して Btrfs のスーパーブロックだけを消去することができます。

=== Windows 8/10 が認識されない ===

Windows 8/10 の "高速スタートアップ", "ハイブリッドブート", "Hiberboot" と呼ばれる設定を有効にしていると Windows のパーティションをマウントすることができません。そのため {{ic|grub-mkconfig}} が Windows を認識することができなくなります。Windows で設定を無効化することで GRUB のメニューに追加することができるようになるはずです。

もし高速スタートアップを無効に変更したくない場合には、WindowsをシャットダウンするときにShiftキーを押しながらシャットダウンをクリックするとその時だけ高速スタートアップの準備をしない完全なシャットダウンが実行されます。

=== VirtualBox EFI モード ===

バージョン6.1以前の VirtualBox では [[#デフォルト/フォールバックのブートパス|デフォルト/フォールバックのブートパス]] に GRUB をインストールしてください。

=== Device /dev/xxx not initialized in udev database even after waiting 10000000 microseconds ===

grub-mkconfig が止まって以下のようなエラーを吐く場合:
{{ic|WARNING: Device /dev/''xxx'' not initialized in udev database even after waiting 10000000 microseconds}}

chroot 環境が {{ic|/run/lvm/}} にアクセスできるようにする必要があります:

# mkdir /mnt/hostlvm
# mount --bind /run/lvm /mnt/hostlvm
# arch-chroot /mnt
# ln -s /hostlvm /run/lvm

{{Bug|61040}} と [https://bbs.archlinux.org/viewtopic.php?pid=1820949#p1820949 回避策]を見てください。

=== grub-rescue プロンプトと暗号化済み /boot ===

[[#Boot パーティション|暗号化済みの /boot]] を使用している場合に間違ったパスワードを入力してしまうと grub-rescue プロンプトに入ります。

この grub-rescue プロンプトでは出来ることが限られています。以下のコマンドを使ってブートを完了させます:

{{bc|
grub rescue> cryptomount <partition>
grub rescue> insmod normal
grub rescue> normal
}}

より良い説明は [https://blog.stigok.com/2017/12/29/decrypt-and-mount-luks-disk-from-grub-rescue-mode.html このブログ投稿]をご覧ください。

=== GRUB をインストールしたが起動時にメニューが表示されない ===

{{ic|/etc/default/grub}} を見て {{ic|GRUB_TIMEOUT}} が {{ic|0}} に設定されていないかチェックしてください。{{ic|0}} に設定されていた場合、正の数に設定し直してください。この値はデフォルトの GRUB エントリが起動されるまでの秒数を表しています。{{ic|GRUB_TIMEOUT_STYLE}} が {{ic|hidden}} に設定されていないかもチェックしてください。{{ic|hidden}} に設定されていた場合、{{ic|menu}} に設定し直してください。これでメニューがデフォルトで表示されるようになります。以上が終わったら、[[#メイン設定ファイルの生成|メインの設定ファイルを再生成]]して、再起動してメニューが表示されるか確かめてください。

== 参照 ==

* [[Wikipedia:GNU GRUB]]
* [https://www.gnu.org/software/grub/manual/grub.html 公式 GRUB マニュアル]
* [https://help.ubuntu.com/community/Grub2 Ubuntu wiki の GRUB ページ]
* [https://help.ubuntu.com/community/UEFIBooting UEFI システム用にコンパイルする手順を説明している GRUB wiki ページ]
* [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]
* [https://web.archive.org/web/20160424042444/http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html#Editing_etcgrub.d05_debian_theme GRUB の設定方法の詳細な説明]
* [https://archived.forum.manjaro.org/t/detecting-efi-files-and-booting-them-from-grub/38083 efi ファイルを検出して grub から起動する]

メタパッケージとパッケージグループ

2022-05-24T15:04:50Z

Libnumafly: 漢字の修正・表現の変更

[[Category:パッケージ管理]]
[[en:Meta package and package group]]
[[es:Meta package and package group]]
[[pt:Meta package and package group]]
[[ru:Meta package and package group]]
'''メタパッケージ''' と '''パッケージグループ''' は、関連するパッケージ一式を表すために、[[パッケージャー]] によって定義されています。
どちらも、メタパッケージまたはグループ名をパッケージ名の代わりに使用することで、パッケージ一式を同時にインストールまたはアンインストールすることができます。グループはパッケージではありませんが、パッケージと同じようにインストールすることができます。[[pacman#パッケージグループのインストール]] と [[PKGBUILD#groups]] を参照してください。

== メタパッケージとパッケージグループの違い ==

メタパッケージと普通のパッケージの違いは、メタパッケージは依存パッケージによって関連したパッケージを結び付けるためだけに存在し、それ自身は空っぽなことです。
''メタパッケージ'' は多くの場合"-meta"サフィックスが付けられており、複数の関連したパッケージを同時にインストールまたはアンインストールできるようにするという点で似た機能を提供します。

それぞれ長所と短所を持ち合せています:

''メタパッケージ'':

* メタパッケージは、他のパッケージと全く同じようにしてインストールすることができます。([[pacman#特定のパッケージのインストール]] を参照)
* メタパッケージは、他のパッケージと全く同じようにしてアンインストールすることができます。([[[pacman#パッケージの削除]] を参照)
* メタパッケージに新しい依存パッケージが追加された際、それらも追加されます。
* ユーザーは依存パッケージのうちどれをインストールするかを選択することができません。
* ユーザーは、メタパッケージそれ自体をアンインストールすることなくその依存パッケージをアンインストールすることはできません。

''パッケージグループ'':

* パッケージグループは、そのグループの中のどのパッケージをインストールするかをユーザーに選択させます。([[pacman#パッケージグループのインストール]] を参照)
* パッケージグループはパッケージ群をインストールするため、パッケージグループ自体をアンインストールすることはできません。その代わりに、 {{ic|pacman -R ''groupname''}} はそのパッケージグループの全てのパッケージをアンインストールしようとします。
* パッケージグループに新しいメンバーが追加されても、自動的にインストールされません。
* ユーザーはグループメンバーのうちどれをインストールするかを選択することができます。
* ユーザーはグループ全体を削除することなくグループメンバーをアンインストールすることができます。

== メタパッケージ ==

一番重要なメタパッケージは {{Pkg|base}} です。これは Arch Linux のインスールに必要な最低限のパッケージを含んでいます。ここには、以下のようなものが含まれています:

* {{Pkg|glibc}} や [[bash]] といった basics、
* [[pacman]] や [[systemd]] といった、ディストリビューション関連のもの
* [[core utilities]] 、プロセス、ファイルやファイル圧縮ユーティリティなどの POSIX ツール群
* {{Pkg|iproute2}} のようなネットワーク周りのツール

[[カーネル]] は選択式の依存パッケージです。[https://www.archlinux.org/news/base-group-replaced-by-mandatory-base-package-manual-intervention-required/ それが導入された際のアナウンス] や [https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029435.html base がメタパッケージである理由] を参考にしてください。

== グループ ==

The most important package group is {{Grp|base-devel}}. It contains tools required to build many packages like [[GCC]] and [[GNU make|make]]. See also [[makepkg#Usage]].

== 参照 ==

* [https://www.archlinux.org/groups/ List of all package groups]
* 例:
** [[GNOME#Installation]]
** [[KDE#Installation]]
** [[i3#Installation]]

Overlayfs

2022-02-10T06:30:40Z

Libnumafly: /* 参照 */ ドキュメントへのリンクを修正

[[Category:ファイルシステム]]
[[en:Overlay filesystem]]
[[ru:Overlay filesystem]]
{{Related articles start}}
{{Related|ファイルシステム}}
{{Related articles end}}

[https://github.com/torvalds/linux/commit/e9be9d5e76e34872f0c37d72e25bc27fe9e2c54c 最初のカーネルコミット] より:

:''Overlayfs を使用すると、読み書きできる通常のディレクトリツリーを、他の読み取り専用のディレクトリツリーの上に重ねることができます。変更は全て、上部の書き込み可能なレイヤーに行われます。このような仕組みは主としてライブ CD で使われていますが、他にも幅広い用途が考えられます。''

:''Overlayfs が他の"統合ファイルシステム"と違う点は、ファイルが開かれた後、全ての操作はあくまで、上層であれ下層であれ、ファイルシステムに直接行われるというところです。これによって実装がシンプルになり、ほとんどの場合で通常の操作と変わらないパフォーマンスを発揮します。''

Overlayfs は Linux カーネル 3.18 から取り込まれました [https://github.com/torvalds/linux/commit/e9be9d5e76e34872f0c37d72e25bc27fe9e2c54c]。

== インストール ==

Overlayfs はデフォルトのカーネルで有効になっています。使用するにはモジュールをロードする必要があるかもしれません:

$ modprobe overlay

== 使用方法 ==

オーバーレイをマウントするには次の {{ic|mount}} オプションを使います:

# mount -t overlay overlay -o lowerdir=''/lower'',upperdir=''/upper'',workdir=''/work'' ''/merged''

{{Note|使用するディレクトリ (''workdir'') は上部のディレクトリと同じファイルシステムでマウントされている必要があります。}}

下層ディレクトリは {{ic|:}} で区切って複数指定することができます。例:

# mount -t overlay overlay -o lowerdir=''/lower1:/lower2:/lower3'',upperdir=''/upper'',workdir=''/work'' ''/merged''

overlayfs のエントリを {{ic|/etc/fstab}} に追加するときは以下のような形式を使います:

{{hc|1=/etc/fstab|2=overlay ''/merged'' overlay noauto,x-systemd.automount,lowerdir=''/lower'',upperdir=''/upper'',workdir=''/work'' 0 0}}

{{ic|noauto}} と {{ic|x-systemd.automount}} マウントオプションは必須のオプションであり、これを設定しないとオーバーレイをマウントできなくなって systemd が起動時にフリーズします。オーバーレイに始めてアクセスしたとき、もしくはリクエストが（準備が整うまで）バッファされたときに、オーバーレイはマウントされます。[[Fstab#systemd で自動マウント]]を見て下さい。

=== 読み取り専用のオーバーレイ ===

複数のディレクトリを組み合わせた読み取り専用のビューを作成したい場合、簡単に作成することができます。{{ic|upper}} と {{ic|work}} は必要なくなります:
# mount -t overlay overlay -o lowerdir=''/lower1:/lower2'' ''/merged''

{{ic|upperdir}} を指定しなかった場合、オーバーレイは自動的に読み取り専用としてマウントされます [https://github.com/torvalds/linux/blob/352526f45387cb96671f13b003bdd5b249e509bd/fs/overlayfs/super.c#L897]。

== 参照 ==

* [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/filesystems/overlayfs.rst Overlay Filesystem documentation]

Fstab

2022-02-10T06:13:37Z

Libnumafly: /* フィールドの定義 */ <fsck>→<pass> 解説に合わせて見本を修正

{{Lowercase title}}
[[Category:ファイルシステム]]
[[Category:ブートプロセス]]
[[en:Fstab]]
[[es:Fstab]]
[[fr:Fstab]]
[[hu:Fstab]]
[[it:Fstab]]
[[pl:Fstab]]
[[ru:Fstab]]
[[zh-hans:Fstab]]
[[zh-hant:Fstab]]
{{Related articles start}}
{{Related|永続的なブロックデバイスの命名}}
{{Related|ファイルシステム}}
{{Related|マウント}}
{{Related|tmpfs}}
{{Related|スワップ}}
{{Related articles end}}

[[Wikipedia:Fstab|/etc/fstab]] ファイルはディスクパーティションや様々なブロックデバイス、リモートファイルをどうやってファイルシステムにマウントするかを記述します。

ファイルシステムは一行毎に記述されます。書かれている定義は、起動時やシステムマネージャの設定がリロードされたときに [[systemd]] の mount ユニットに動的に変換されます。デフォルトの設定はマウントを必要とするサービスが起動する前にファイルシステムの fsck とマウントを自動的に実行します。例えば、[[NFS]] や [[Samba]] などのリモートファイルシステムはネットワークが立ち上がった後に systemd によって自動的にマウントされます。そのため、{{ic|/etc/fstab}} に指定するローカル・リモートファイルシステムのマウントに設定は必要ありません。詳しくは {{man|5|systemd.mount}} を見て下さい。

{{ic|mount}} コマンドはディレクトリやデバイスがひとつだけ指定された場合、他のパラメータの値を取得するために fstab を使います。このとき、fstab に記述されたマウントオプションも使われます。

== ファイル例 ==

ファイルシステムの UUID を使用したシンプルな {{ic|/etc/fstab}}

{{hc|/etc/fstab|2=
# <device> <dir> <type> <options> <dump> <fsck>
UUID=0a3407de-014b-458b-b5c1-848e92a327a3 / ext4 noatime 0 1
UUID=f9fe0b69-a280-415d-a03a-a32752370dee none swap defaults 0 0
UUID=b411dc99-f0a0-4c87-9e05-184977be8539 /home ext4 noatime 0 2
}}

== フィールドの定義 ==

{{ic|/etc/fstab}} ファイルには以下のフィールドが含まれ、スペースかタブで区切ります:

<device> <dir> <type> <options> <dump> <pass>

* '''<device>''' - マウントされるパーティションやストレージデバイス。こちらも参照 [https://wiki.archlinux.jp/index.php/Fstab#.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.82.B7.E3.82.B9.E3.83.86.E3.83.A0.E3.81.AE.E8.AD.98.E5.88.A5 ファイルシステムの識別]
* '''<dir>''' - <device> がマウントされるマウントポイント。
* '''<type>''' - マウントされるパーティションやストレージデバイスのファイルシステムタイプ。さまざまなファイルシステムがサポートされています: {{ic|ext2}}, {{ic|ext3}}, {{ic|ext4}}, {{ic|btrfs}}, {{ic|reiserfs}}, {{ic|xfs}}, {{ic|jfs}}, {{ic|smbfs}}, {{ic|iso9660}}, {{ic|vfat}}, {{ic|ntfs}}, {{ic|swap}}, {{ic|auto}}。{{ic|auto}} タイプはどのファイルシステムタイプが使われているかマウントコマンドに推測させます。これはディスクメディア (CD/DVD) に役立ちます。
* '''<options>''' - 使用されるファイルシステムのマウントオプション。[https://linux.die.net/man/8/mount マウントオプション]にはファイルシステム固有のものもあることに気をつけて下さい。最も一般的なオプションは:

:* {{ic|auto}} - 起動時、または {{ic|mount -a}} コマンドが実行されたときに自動でマウントします。
:* {{ic|noauto}} - 自動ではマウントしません。
:* {{ic|exec}} - ファイルシステム上のバイナリの実行を許可します。
:* {{ic|noexec}} - ファイルシステム上のバイナリの実行を禁止します。
:* {{ic|ro}} - ファイルシステムを読み込み専用でマウント。
:* {{ic|rw}} - ファイルシステムを読み書き可能でマウント。
:* {{ic|user}} - 全てのユーザーにファイルシステムのマウントを許可します。上書きしないかぎり、自動で {{ic|noexec}}, {{ic|nosuid}}, {{ic|nodev}} も有効になります。
:* {{ic|users}} - ユーザーグループに入っている全てのユーザーにファイルシステムのマウントを許可します。
:* {{ic|nouser}} - root だけにファイルシステムのマウントを許可します。
:* {{ic|owner}} - デバイスの所有者にマウントを許可します。
:* {{ic|sync}} - I/O は同期的に行なわれます。
:* {{ic|async}} - I/O は非同期で行われます。
:* {{ic|dev}} - ファイルシステム上の特別なデバイスを解釈します。
:* {{ic|nodev}} - ファイルシステム上の特別なデバイスを解釈しません。
:* {{ic|suid}} - suid や sgid ビットの操作を許可します。ほとんどの場合、一時的な権限で特別な作業を行うためにユーザーがバイナリ実行可能ファイルを実行できるようにするため使われます。
:* {{ic|nosuid}} - suid や sgid ビットの操作を禁止します。
:* {{ic|noatime}} - ファイルシステムの inode アクセス日時を更新しません。パフォーマンスの向上に役立ちます ([[#atime オプション]] を見て下さい)。
:* {{ic|nodiratime}} - ファイルシステムのディレクトリの inode アクセス日時を更新しません。パフォーマンスの向上に役立ちます ([[#atime オプション]] を見て下さい)。
:* {{ic|relatime}} - 変更日時にあわせて inode アクセス日時を更新します。以前のアクセス日時が現在の変更日時よりも前のときだけアクセス日時が更新されます (noatime に似ていますが、変更されたあとファイルが読み込まれたか知る必要がある mutt などのアプリケーションを破壊しません)。パフォーマンスの向上に役立ちます ([[#atime オプション]]を見て下さい)。
:* {{ic|discard}} - ブロックがフリーになったときにブロックデバイスに [[SSD#TRIM|TRIM]] コマンドを実行します。ファイルシステムが [[SSD]] 上にあるときは使うことが推奨されています。
:* {{ic|flush}} - データを頻繁にフラッシュする {{ic|vfat}} のオプション。全てのデータが書き込まれるまではコピーダイアログやプログレスバーは止まったままになります。
:* {{ic|nofail}} - 存在するときはデバイスをマウントし、存在しないときは無視します。起動時にリムーバブルメディアのエラーが報告されるのを防止します。
:* {{ic|defaults}} - 使われるファイルシステムのデフォルトのマウントオプション。{{ic|ext4}} のデフォルトのオプションは: {{ic|rw}}, {{ic|suid}}, {{ic|dev}}, {{ic|exec}}, {{ic|auto}}, {{ic|nouser}}, {{ic|async}}。

* '''<dump>''' - バックアップを作る時を決定するために dump ユーティリティによって使われます。Dump はエントリをチェックしその値を使ってファイルシステムがバックアップされるべきかどうか決定します。指定できるエントリは0か1です。0の場合、dumpはファイルシステムを無視します; 1の場合、dump はバックアップを作成します。ほとんどのユーザーは dump をインストールしないので、<dump> エントリには0を入れて下さい。

* '''<pass>''' - ファイルシステムをチェックする順番を決めるために [[fsck]] によって使われます。指定できるエントリは {{ic|0}} か {{ic|1}} もしくは {{ic|2}} です。root ファイルシステムには一番優先度の高い {{ic|1}} を設定してください。[[btrfs]] の場合は {{man|8|fsck.btrfs}} にあるように、このフィールドを {{ic|0}} にするべきです。その他のファイルシステムには2を入れて下さい。{{ic|0}} が設定されたファイルシステムは fsck ユーティリティによってチェックされません。

== ファイルシステムの識別 ==

{{ic|/etc/fstab}} でパーティションやストレージデバイスを識別する方法は3つあります: カーネルの名前記述子、ファイルシステムのラベルやUUID、GPT パーティションのラベルやUUIDです。UUID やラベルにはドライブがマシンに（物理的に）接続されている順番と切り離せるという利点があります。これは、BIOS でストレージデバイスの順番を変更したり、ストレージデバイスの配線を変えるときに有用です。また、ときどき BIOS はストレージデバイスの順番を変更してしまうことがあります。なお、UUID はカーネルの名前記述子やラベルよりも優先されます。詳しくは[[永続的なブロックデバイスの命名]]の記事を読んで下さい。

パーティションについて基本的な情報を一覧するには、次を実行:

{{hc|$ lsblk -f|
NAME FSTYPE LABEL UUID MOUNTPOINT
sda
├─sda1 ext4 Arch_Linux 978e3e81-8048-4ae1-8a06-aa727458e8ff /
├─sda2 ntfs Windows 6C1093E61093B594
└─sda3 ext4 Storage f838b24e-3a66-4d02-86f4-a2e73e454336 /media/Storage
sdb
├─sdb1 ntfs Games 9E68F00568EFD9D3
└─sdb2 ext4 Backup 14d50a6c-e083-42f2-b9c4-bc8bae38d274 /media/Backup
sdc
└─sdc1 vfat Camera 47FA-4071 /media/Camera}}

=== カーネルの名前記述子 ===

{{ic|lsblk -f}} を実行してパーティションを一覧し、前に {{ic|/dev}} を付けて下さい。

[[#ファイル例|サンプル]]を見て下さい。

=== ラベル ===

{{Note|衝突がおこるのを避けるために、ラベルをかぶらせてはいけません。}}

デバイスやパーティションにラベルをつける方法は [[永続的なブロックデバイスの命名#by-label]] を見て下さい。root パーティションのリネームは "ライブ" Linux ディストリビューション (Parted Magic, Ubuntu, etc) から行なって下さい。root パーティションは初めにアンマウントする必要があるからです。

{{ic|lsblk -f}} を実行してパーティションを一覧し、前に {{ic|1=LABEL=}} を付けて下さい:

{{hc|/etc/fstab|2=
# <file system> <dir> <type> <options> <dump> <pass>

LABEL=Arch_Linux / ext4 defaults,noatime 0 1
LABEL=Arch_Swap none swap defaults 0 0}}

=== UUID ===

全てのパーティションとデバイスは固有の UUID を持っています。UUID はパーティションを作成したりフォーマットするときにファイルシステムユーティリティ (例: {{ic|mkfs.*}}) によって生成されます。詳しくは [[永続的なブロックデバイスの命名#by-uuid]] を見て下さい。

{{ic|lsblk -f}} を実行してパーティションを一覧し、前に {{ic|1=UUID=}} を付けて下さい:

{{Tip|特定のパーティションの UUID だけを表示したい場合: {{ic|$ lsblk -no UUID /dev/sda2}}。
}}

{{hc|/etc/fstab|2=
# <file system> <dir> <type> <options> <dump> <pass>

UUID=24f28fc6-717e-4bcd-a5f7-32b959024e26 / ext4 defaults,noatime 0 1
UUID=03ec5dd3-45c0-4f95-a363-61ff321a09ff /home ext4 defaults,noatime 0 2
UUID=4209c845-f495-4c43-8a03-5363dd433153 none swap defaults 0 0}}

=== GPT ラベル ===
{{ic|blkid}} を実行してパーティションを確認し、''PARTLABEL'' の値を使って下さい (クォートは要りません):

{{hc|/etc/fstab|<nowiki>
# <file system> <dir> <type> <options> <dump> <pass>
PARTLABEL=EFI\040SYSTEM\040PARTITION /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
PARTLABEL=GNU/LINUX / ext4 rw,relatime,data=ordered 0 1
PARTLABEL=HOME /home ext4 rw,relatime,data=ordered 0 2
PARTLABEL=SWAP none swap defaults 0 0
</nowiki>}}

{{Note|フィールドに空白が含まれている場合、[[#ファイルパスのスペース（空白）]]を参照。}}

=== GPT UUID ===

{{ic|blkid}} を実行してパーティションを確認し、''PARTUUID'' の値を使って下さい (クォートは要りません):

{{hc|/etc/fstab|<nowiki>
# <file system> <dir> <type> <options> <dump> <pass>
PARTUUID=d0d0d110-0a71-4ed6-936a-304969ea36af /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro 0 2
PARTUUID=98a81274-10f7-40db-872a-03df048df366 / ext4 rw,relatime,data=ordered 0 1
PARTUUID=7280201c-fc5d-40f2-a9b2-466611d3d49e /home ext4 rw,relatime,data=ordered 0 2
PARTUUID=039b6c1c-7553-4455-9537-1befbc9fbc5b none swap defaults 0 0
</nowiki>}}

== ヒントとテクニック ==

=== systemd による自動マウント ===

詳細は {{man|5|systemd.automount}} にあります。

==== ローカルパーティション ====

巨大な {{ic|/home}} パーティションが存在する場合、''fsck'' によって {{ic|/home}} がチェックされている間に、{{ic|/home}} を使わないサービスを起動できるようにすると良いかもしれません。{{ic|/home}} パーティションの {{ic|/etc/fstab}} エントリに以下のオプションを追加することでそのように設定できます:

noauto,x-systemd.automount

{{ic|/home}} に最初にアクセスしたときに fsck とマウントを行うようになり、パーティションの準備が出来るまでカーネルが {{ic|/home}} へのファイルアクセスを全てバッファします。

{{Note|この設定を使うと {{ic|/home}} ファイルシステムのタイプが {{ic|autofs}} になり、デフォルトで [[mlocate]] から無視されるようになります。{{ic|/home}} の自動マウントによる高速化はせいぜい1〜2秒がいいとこなので、環境によっては、この設定はあまり意味がないかもしれません。}}

==== リモートファイルシステム ====

同じ設定はリモートファイルシステムのマウントにも適用できます。アクセスしたときにだけリモートファイルシステムをマウントしたい場合、{{ic|noauto,x-systemd.automount}} パラメータを使って下さい。さらに、{{ic|1=x-systemd.device-timeout=}} オプションを使うことでネットワークに接続できないときのタイムアウトを指定できます。また、{{ic|_netdev}} オプションで systemd がネットワークに依存するマウントであることを認識してネットワークがオンラインになった後に順番を入れ替えます。

noauto,x-systemd.automount,x-systemd.device-timeout=30,_netdev

{{Note|1={{ic|automount}} と一緒に {{ic|exec}} フラグを使う場合、{{ic|user}} フラグを削除するようにしてください。詳しくは [https://bugzilla.redhat.com/show_bug.cgi?id=769636 Fedora Bug Report] を参照。}}

==== 暗号化ファイルシステム ====

キーファイルによって暗号化したファイルシステムがある場合も、{{ic|noauto}} パラメータを {{ic|/etc/crypttab}} の適当なエントリに追加することができます。設定することで ''systemd'' は起動時に暗号化デバイスを開かないようになり、実際にアクセスされたときになってから指定したキーファイルを使ってファイルシステムを開いてマウントします。デバイスが利用可能になるのを systemd が待機しないようになるので、暗号化 RAID デバイスなどを使っている場合、起動時間が数秒間短くなるかもしれません。例:

{{hc|/etc/crypttab|
data /dev/md0 /root/key noauto}}

==== 自動マウント解除 ====

{{ic|x-systemd.idle-timeout}} フラグを使うことで一定時間アイドル状態のときにタイムアウトするのを指定できます。例:

noauto,x-systemd.automount,x-systemd.idle-timeout=1min

上記の設定の場合、1分間操作がないと systemd によってアンマウントされます。

=== スワップの UUID ===

スワップパーティションが UUID を持っていない場合、手動で追加することが可能です。これは {{ic|lsblk -f}} コマンドでスワップの UUID が表示されないときに発生します。スワップに UUID を指定する手順は以下になります:

スワップパーティションを確認:

# swapon -s

スワップを無効化:

# swapoff /dev/sda7

新しく UUID を指定してスワップを再作成:

# mkswap -U random /dev/sda7

スワップを有効化:

# swapon /dev/sda7

=== ファイルパスのスペース（空白） ===

マウントポイントにスペース（空白）が含まれている場合、エスケープ文字 {{ic|\}} と3文字の8進数コード {{ic|040}} を使ってスペースの代わりにしてください:

{{hc|/etc/fstab|2=
UUID=47FA-4071 /home/username/Camera\040Pictures vfat defaults,noatime 0 0
/dev/sda7 /media/100\040GB\040(Storage) ext4 defaults,noatime,user 0 2}}

=== 外部デバイス ===

存在するときに外部デバイスをマウントして、無い時は無視するには {{ic|nofail}} オプションが必要です。このオプションは起動時にエラーが報告されるのを防止します。

{{hc|/etc/fstab|2=
/dev/sdg1 /media/backup jfs defaults,nofail,x-systemd.device-timeout=1 0 2}}

systemd 219 から、{{ic|nofail}} オプションを使う時は {{ic|x-systemd.device-timeout}} オプションも使用することが推奨されます。デフォルトのデバイスタイムアウトが90秒になったため、{{ic|nofail}} しか指定しない場合、外部デバイスを切断したときに起動が90秒伸びることになるからです。上記のようにタイムアウトを再設定して上げて下さい。タイムアウトを0に設定してはいけません。永遠にタイムアウトしなくなります。

また、外部デバイスを扱うのに他の systemd ユニットをロードする必要がある場合 (例えばネットワークで共有する場合など)、{{ic|1=x-systemd.requires=x}} と {{ic|x-systemd.automount}} を組み合わせて使うことで、ユニットが起動してから自動マウントさせることができます。例:

{{hc|/etc/fstab|2=
/host/share /net/share cifs noauto,nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10,workgroup=workgroup,credentials=/foo/credentials 0 0}}

また、[[NetworkManager#NetworkManager Wait Online を有効にする|NetworkManager-wait-online]] や [[Systemd-networkd#起動時にマウントサービスが失敗する|systemd-networkd-wait-online]] を有効化する方法もあります。

=== atime オプション ===

{{ic|noatime}}, {{ic|nodiratime}}, {{ic|relatime}} を使用するとドライブのパフォーマンスが改善します。Linux は読み込まれるたびに記録する（ドライブに書き込む） {{ic|atime}} をデフォルトで使っています。これは Linux をサーバーに使っている時は理にかなっていますが、デスクトップとして利用する場合はそれほど意味がありません。{{ic|atime}} オプションの最悪な点は、ページキャッシュからファイルを読み込む（ドライブではなくメモリから読み込む）ときでさえ書き込みを行ってしまうことです！{{ic|noatime}} オプションはファイルを読み込むたびにドライブにファイルのアクセス日時を書き込むのを完全に無効にします。これはほとんど全てのアプリケーションでうまくいきますが、そのような情報が必要な [[Mutt]] などの例外がわずかに存在します。mutt のために、{{ic|relatime}} オプションを使うほうがいいでしょう。{{ic|relatime}} オプションはファイルが変更されたときだけファイルアクセス日時の書き込みを有効にします ({{ic|noatime}} はアクセス日時が変更日時より古い場合でもアクセス日時を変更しません)。{{ic|nodiratime}} オプションはファイルアクセス日時の書き込みをディレクトリでだけ無効化し、その他のファイルではアクセス日時の書き込みが行われます。[[Mutt]] などのプログラムを動作させるために妥協として {{ic|relatime}} を使うのがベストだと思われます。

逆に {{ic|strictatime}} オプションはファイルにアクセスするたびにアクセス日時を更新します。サーバーとして Linux を使っている場合には意味がありますが、デスクトップ用途ではあまり有意義ではありません。{{ic|strictatime}} オプションの欠点として、たとえ (ドライブではなくメモリから読み込む) ページキャッシュからファイルを読み込んだ場合でも、ディスクに書き込みが発生してしまいます。

{{Note|{{ic|noatime}} は {{ic|nodiratime}} を含んでいます。両方を指定する必要はありません。[https://lwn.net/Articles/244941/ ]}}

カーネル 4.0 から {{ic|lazytime}} という新しいオプションが追加されました。{{ic|lazytime}} は inode タイムスタンプ (アクセス・変更・作成日時) の変更をメモリ上に保存することでディスクへの書き込みを減らします。ディスク上のタイムスタンプが更新されるのは次の場合に限られます。(1) ファイルのタイムスタンプとは関係ない変更によってファイルの inode を更新する必要があるとき。(2) ディスクへの同期が発生したとき。(3) 削除されていない inode がメモリから追い出されたとき。(4) メモリ上のコピーがディスクに最後に書き込まれてから24時間以上経ったとき。
{{Warning|システムがクラッシュした場合、ディスク上のアクセス時間や最終変更日時は最大で24時間ずれる可能性があります。}}

{{ic|lazytime}} オプションは前述の {{ic|*atime}} オプションと一緒に使うことが可能です。

=== FAT32 に標準ユーザーとして書き込み ===

[[FAT#FAT32 に標準ユーザーとして書き込み]]を参照してください。

=== root パーティションの再マウント ===

何らかの理由で誤って root パーティションを読み込み専用でマウントしてしまった場合は、次のコマンドで root パーティションを再マウントしてください:

# mount -o remount,rw /

=== バインドマウント ===

{{Note|ディレクトリを別の場所にバインドしていることはプログラムからはわからないため、{{ic|rm -r *}} のようなコマンドを実行してしまうと元の場所のファイルも消去されてしまいます。そのため、通常はソフトリンクを使うことが推奨されます。Btrfs 上のディレクトリにアクセスする必要がありソフトリンクは使えない場合、[[Btrfs#サブボリューム|サブボリューム]]機能でマウントオプションのようにケーパビリティを拡張できます。}}

権限がないために特定のディレクトリにプログラムやユーザーがアクセスできない場合、プログラムがアクセスできる場所にディレクトリをバインドマウントすることでアクセスさせることができます。プログラムがあるディレクトリ ''bar'' にはアクセスできるがディレクトリ ''foo'' にはアクセスできないとき、{{ic|/etc/fstab}} にエントリを追加することで特にパーミッションを弄らないでもアクセス権限を与えられます:
{{hc|/etc/fstab|2=
/<path to foo> /<path to bar> none bind 0 0}}

== 参照 ==

*[https://www.kernel.org/pub/linux/docs/lanana/device-list/devices-2.6.txt ブロックデバイスを含むデバイスリスト]
*[http://www.pathname.com/fhs/2.2/index.html Filesystem Hierarchy Standard]
* [https://www.askapache.com/optimize/super-speed-secrets/ tmpfs を使ってキャッシュとサイト速度を30倍に高速化]
* [[Samba#マウントエントリ|Samba 共有を /etc/fstab に追加]]

カテゴリ:Arch の入手とインストール

2021-10-19T11:07:12Z

Libnumafly: /* インストール方法 */ リムーバブルメディアに Arch をインストール

[[Category:Arch について]]
[[ar:Category:Installation process]]
[[bg:Category:Installation process]]
[[bs:Category:Installation process]]
[[cs:Category:Installation process]]
[[da:Category:Installation process]]
[[de:Category:Installation]]
[[el:Category:Installation process]]
[[en:Category:Installation process]]
[[es:Category:Installation process]]
[[fi:Category:Installation process]]
[[hr:Category:Installation process]]
[[id:Category:Installation process]]
[[it:Category:Installation process]]
[[ko:Category:Installation process]]
[[lt:Category:Installation process]]
[[nl:Category:Installation process]]
[[pl:Category:Installation process]]
[[pt:Category:Installation process]]
[[ru:Category:Installation process]]
[[sk:Category:Installation process]]
[[sr:Category:Installation process]]
[[th:Category:Installation process]]
[[tr:Category:Installation process]]
[[uk:Category:Installation process]]
[[zh-hans:Category:Installation process]]
[[zh-hant:Category:Installation process]]
このカテゴリは Arch Linux のリリース、ダウンロード、インストールについての記事を含みます。

インストールメディアとその [[GnuPG]] 署名は [https://www.archlinux.jp/download/ ダウンロード] ページから入手できます。

== 署名の検証 ==

イメージを使う前に署名を検証することを推奨します。''HTTP ミラー''からダウンロードした場合は特にそうです。ミラーはボランティアによって運営されており、[http://web.archive.org/web/20091220092429/http://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation 悪意のあるイメージを提供している] 可能性もあるからです。

[[GnuPG]] がインストールされているシステムで署名を検証するには、(''チェックサム''の下にある) ''PGP 署名''を ISO と同じディレクトリにダウンロードし、{{ic|gpg --keyserver-options auto-key-retrieve --verify archlinux-<version>-dual.iso.sig}} を実行します。

別の方法としては、既存の Arch Linux システムから {{ic|pacman-key -v archlinux-<version>-dual.iso.sig}} を実行する方法もあります。

{{Note|
* [https://www.archlinux.jp/download/ archlinuxjp.org] に記載されていないミラーサイトからダウンロードした場合は署名自体が改ざんされていることもあり得ます。信頼がおけないミラーサイトからダウンロードした場合は、署名を復号化するのに使われる公開鍵が別の信頼できる鍵によって署名されていることを確認してください。{{ic|gpg}} コマンドを使うと公開鍵の指紋を出力できます。
* 署名の真正性を検証する別の方法としては、公開鍵の指紋が ISO ファイルを署名した [https://www.archlinux.org/people/developers/ Arch Linux 開発者] の鍵指紋と同じであることを確認します。鍵の信頼性を確認する方法についてより詳しくは[[Wikipedia:ja:公開鍵暗号|公開鍵暗号]]を参照してください。
}}

== インストール方法 ==
以下の表はインストールメディアを起動する一般的な方法の概要を示しています。インストールの手順中にリモートのリポジトリからパッケージを取得するため、これらの方法はインターネットに接続できることが必要になります。インターネットが利用できない場合は[[パッケージのオフラインインストール]]や [[Archiso#インターネットにアクセスできない環境でのインストール]]を参照してください。

{{Note|
* [[w:ja:Power On Self Test|POST]] の段階で特定のキーを押すことで起動デバイスとして Arch のインストールメディアが挿入されているドライブを指定します。詳しくはマザーボードのマニュアルを読んでください。
* Arch のメニューが表示されたら ''Boot Arch Linux'' を選択してから {{ic|Enter}} を押してインストール環境を起動してください。
* [[カーネルパラメータ#設定|ブートパラメータ]]のリストは [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] を、含まれているパッケージのリストは [https://git.archlinux.org/archiso.git/tree/configs/releng/packages.both packages.both] を見てください。
}}

{| class="wikitable"
! 方法
! 記事
! 条件
|-
| イメージをフラッシュメディアや光学ディスクに書き込んでそこから起動する。
|
* [[USB インストールメディア]]
* [[光学ディスクドライブ#焼き込み]]
|
* 1台、または多くとも2,3台のマシンへのインストール
* 直接ブート可能なシステムが得られる
|-
| サーバーでイメージをマウントし、クライアントにネットワーク越しでサーバーから起動させる。
|
* [[PXE]]
* [[ディスクレスシステム]]
|
* クライアント・サーバーモデル
* (1 Gbit 以上の) 有線ネットワーク接続
|-
| 既存の Linux でイメージをマウントし、chroot 環境から Arch をインストールする。
|
* [[既存の Linux からインストール]]
* [[SSH からインストール]]
|
* 短いダウンタイムで既存のシステムを置き換える
* ローカルマシンへのインストール、または [[VNC]] か [[SSH]] 経由でリモートマシンへのインストール
|-
| 仮想マシンをセットアップして Arch をゲストとしてインストールする。
|
* [[:カテゴリ:仮想化]]
* [[既存環境を仮想マシンに (から) 移動]]
|
* 仮想化ソフトウェアが動作する OS
* 学習・テスト・デバッグ用の隔離されたシステムが得られる
|-
| Windows 環境と共存するように Arch をインストールする。
|
* [[Windows と Arch のデュアルブート]]
|
* Windows ユーザーと共有できるマシン
* Windows がプリインストールされたデバイスを簡単にファクトリーリセットできること
|-
| Windows Subsystem for Linux に Arch をインストールする。
|
* [[WSL にインストール]]
|
* Windows 10 Creators Update 以上が動作しているマシン
* ネットワークアクセスでないかぎり GUI 無し
|-
| “ポータブルな Arch”として、リムーバブルメディアに Arch をインストールする。
|
* [[リムーバブルメディアに_Arch_Linux_をインストール|リムーバブルメディアにインストール]]
|
* フラッシュストレージドライブにインストールする場合、[[ソリッドステートドライブ#SSD_.E3.81.AE.E8.AA.AD.E3.81.BF.E6.9B.B8.E3.81.8D.E3.82.92.E6.9C.80.E5.B0.8F.E5.8C.96.E3.81.99.E3.82.8B.E3.83.92.E3.83.B3.E3.83.88|読み書き回数の最小化が推奨される]]
|}

== 参考 ==
* [https://projects.archlinux.org/archiso.git/tree/docs/README.transfer README.transfer]
* [https://projects.archlinux.org/archiso.git/tree/docs/README.altbootmethods README.altbootmethods]

カテゴリ:Arch の入手とインストール

2021-10-19T10:59:19Z

Libnumafly: /* インストール方法 */ リムーバブルメディアに Arch をインストール

[[Category:Arch について]]
[[ar:Category:Installation process]]
[[bg:Category:Installation process]]
[[bs:Category:Installation process]]
[[cs:Category:Installation process]]
[[da:Category:Installation process]]
[[de:Category:Installation]]
[[el:Category:Installation process]]
[[en:Category:Installation process]]
[[es:Category:Installation process]]
[[fi:Category:Installation process]]
[[hr:Category:Installation process]]
[[id:Category:Installation process]]
[[it:Category:Installation process]]
[[ko:Category:Installation process]]
[[lt:Category:Installation process]]
[[nl:Category:Installation process]]
[[pl:Category:Installation process]]
[[pt:Category:Installation process]]
[[ru:Category:Installation process]]
[[sk:Category:Installation process]]
[[sr:Category:Installation process]]
[[th:Category:Installation process]]
[[tr:Category:Installation process]]
[[uk:Category:Installation process]]
[[zh-hans:Category:Installation process]]
[[zh-hant:Category:Installation process]]
このカテゴリは Arch Linux のリリース、ダウンロード、インストールについての記事を含みます。

インストールメディアとその [[GnuPG]] 署名は [https://www.archlinux.jp/download/ ダウンロード] ページから入手できます。

== 署名の検証 ==

イメージを使う前に署名を検証することを推奨します。''HTTP ミラー''からダウンロードした場合は特にそうです。ミラーはボランティアによって運営されており、[http://web.archive.org/web/20091220092429/http://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation 悪意のあるイメージを提供している] 可能性もあるからです。

[[GnuPG]] がインストールされているシステムで署名を検証するには、(''チェックサム''の下にある) ''PGP 署名''を ISO と同じディレクトリにダウンロードし、{{ic|gpg --keyserver-options auto-key-retrieve --verify archlinux-<version>-dual.iso.sig}} を実行します。

別の方法としては、既存の Arch Linux システムから {{ic|pacman-key -v archlinux-<version>-dual.iso.sig}} を実行する方法もあります。

{{Note|
* [https://www.archlinux.jp/download/ archlinuxjp.org] に記載されていないミラーサイトからダウンロードした場合は署名自体が改ざんされていることもあり得ます。信頼がおけないミラーサイトからダウンロードした場合は、署名を復号化するのに使われる公開鍵が別の信頼できる鍵によって署名されていることを確認してください。{{ic|gpg}} コマンドを使うと公開鍵の指紋を出力できます。
* 署名の真正性を検証する別の方法としては、公開鍵の指紋が ISO ファイルを署名した [https://www.archlinux.org/people/developers/ Arch Linux 開発者] の鍵指紋と同じであることを確認します。鍵の信頼性を確認する方法についてより詳しくは[[Wikipedia:ja:公開鍵暗号|公開鍵暗号]]を参照してください。
}}

== インストール方法 ==
以下の表はインストールメディアを起動する一般的な方法の概要を示しています。インストールの手順中にリモートのリポジトリからパッケージを取得するため、これらの方法はインターネットに接続できることが必要になります。インターネットが利用できない場合は[[パッケージのオフラインインストール]]や [[Archiso#インターネットにアクセスできない環境でのインストール]]を参照してください。

{{Note|
* [[w:ja:Power On Self Test|POST]] の段階で特定のキーを押すことで起動デバイスとして Arch のインストールメディアが挿入されているドライブを指定します。詳しくはマザーボードのマニュアルを読んでください。
* Arch のメニューが表示されたら ''Boot Arch Linux'' を選択してから {{ic|Enter}} を押してインストール環境を起動してください。
* [[カーネルパラメータ#設定|ブートパラメータ]]のリストは [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] を、含まれているパッケージのリストは [https://git.archlinux.org/archiso.git/tree/configs/releng/packages.both packages.both] を見てください。
}}

{| class="wikitable"
! 方法
! 記事
! 条件
|-
| イメージをフラッシュメディアや光学ディスクに書き込んでそこから起動する。
|
* [[USB インストールメディア]]
* [[光学ディスクドライブ#焼き込み]]
|
* 1台、または多くとも2,3台のマシンへのインストール
* 直接ブート可能なシステムが得られる
|-
| サーバーでイメージをマウントし、クライアントにネットワーク越しでサーバーから起動させる。
|
* [[PXE]]
* [[ディスクレスシステム]]
|
* クライアント・サーバーモデル
* (1 Gbit 以上の) 有線ネットワーク接続
|-
| 既存の Linux でイメージをマウントし、chroot 環境から Arch をインストールする。
|
* [[既存の Linux からインストール]]
* [[SSH からインストール]]
|
* 短いダウンタイムで既存のシステムを置き換える
* ローカルマシンへのインストール、または [[VNC]] か [[SSH]] 経由でリモートマシンへのインストール
|-
| 仮想マシンをセットアップして Arch をゲストとしてインストールする。
|
* [[:カテゴリ:仮想化]]
* [[既存環境を仮想マシンに (から) 移動]]
|
* 仮想化ソフトウェアが動作する OS
* 学習・テスト・デバッグ用の隔離されたシステムが得られる
|-
| Windows 環境と共存するように Arch をインストールする。
|
* [[Windows と Arch のデュアルブート]]
|
* Windows ユーザーと共有できるマシン
* Windows がプリインストールされたデバイスを簡単にファクトリーリセットできること
|-
| Windows Subsystem for Linux に Arch をインストールする。
|
* [[WSL にインストール]]
|
* Windows 10 Creators Update 以上が動作しているマシン
* ネットワークアクセスでないかぎり GUI 無し
|-
| “ポータブルな Arch”として、リムーバブルメディアに Arch をインストールする。
|
* [[リムーバブルメディアに_Arch_Linux_をインストール|リムーバブルメディアにインストール]]
|
* フラッシュストレージドライブにインストールする場合、読み書き回数の最小化が推奨される
|}

== 参考 ==
* [https://projects.archlinux.org/archiso.git/tree/docs/README.transfer README.transfer]
* [https://projects.archlinux.org/archiso.git/tree/docs/README.altbootmethods README.altbootmethods]

カテゴリ:Arch の入手とインストール

2021-04-17T14:25:36Z

Libnumafly: /* 署名の検証 */ 削除された外部サイトへのリンクをwaybackmachineアーカイブで代替

[[Category:Arch について]]
[[ar:Category:Installation process]]
[[bg:Category:Installation process]]
[[bs:Category:Installation process]]
[[cs:Category:Installation process]]
[[da:Category:Installation process]]
[[de:Category:Installation]]
[[el:Category:Installation process]]
[[en:Category:Installation process]]
[[es:Category:Installation process]]
[[fi:Category:Installation process]]
[[hr:Category:Installation process]]
[[id:Category:Installation process]]
[[it:Category:Installation process]]
[[ko:Category:Installation process]]
[[lt:Category:Installation process]]
[[nl:Category:Installation process]]
[[pl:Category:Installation process]]
[[pt:Category:Installation process]]
[[ru:Category:Installation process]]
[[sk:Category:Installation process]]
[[sr:Category:Installation process]]
[[th:Category:Installation process]]
[[tr:Category:Installation process]]
[[uk:Category:Installation process]]
[[zh-hans:Category:Installation process]]
[[zh-hant:Category:Installation process]]
このカテゴリは Arch Linux のリリース、ダウンロード、インストールについての記事を含みます。

インストールメディアとその [[GnuPG]] 署名は [https://www.archlinux.jp/download/ ダウンロード] ページから入手できます。

== 署名の検証 ==

イメージを使う前に署名を検証することを推奨します。''HTTP ミラー''からダウンロードした場合は特にそうです。ミラーはボランティアによって運営されており、[http://web.archive.org/web/20091220092429/http://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation 悪意のあるイメージを提供している] 可能性もあるからです。

[[GnuPG]] がインストールされているシステムで署名を検証するには、(''チェックサム''の下にある) ''PGP 署名''を ISO と同じディレクトリにダウンロードし、{{ic|gpg --keyserver-options auto-key-retrieve --verify archlinux-<version>-dual.iso.sig}} を実行します。

別の方法としては、既存の Arch Linux システムから {{ic|pacman-key -v archlinux-<version>-dual.iso.sig}} を実行する方法もあります。

{{Note|
* [https://www.archlinux.jp/download/ archlinuxjp.org] に記載されていないミラーサイトからダウンロードした場合は署名自体が改ざんされていることもあり得ます。信頼がおけないミラーサイトからダウンロードした場合は、署名を復号化するのに使われる公開鍵が別の信頼できる鍵によって署名されていることを確認してください。{{ic|gpg}} コマンドを使うと公開鍵の指紋を出力できます。
* 署名の真正性を検証する別の方法としては、公開鍵の指紋が ISO ファイルを署名した [https://www.archlinux.org/people/developers/ Arch Linux 開発者] の鍵指紋と同じであることを確認します。鍵の信頼性を確認する方法についてより詳しくは[[Wikipedia:ja:公開鍵暗号|公開鍵暗号]]を参照してください。
}}

== インストール方法 ==
以下の表はインストールメディアを起動する一般的な方法の概要を示しています。インストールの手順中にリモートのリポジトリからパッケージを取得するため、これらの方法はインターネットに接続できることが必要になります。インターネットが利用できない場合は[[パッケージのオフラインインストール]]や [[Archiso#インターネットにアクセスできない環境でのインストール]]を参照してください。

{{Note|
* [[w:ja:Power On Self Test|POST]] の段階で特定のキーを押すことで起動デバイスとして Arch のインストールメディアが挿入されているドライブを指定します。詳しくはマザーボードのマニュアルを読んでください。
* Arch のメニューが表示されたら ''Boot Arch Linux'' を選択してから {{ic|Enter}} を押してインストール環境を起動してください。
* [[カーネルパラメータ#設定|ブートパラメータ]]のリストは [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] を、含まれているパッケージのリストは [https://git.archlinux.org/archiso.git/tree/configs/releng/packages.both packages.both] を見てください。
}}

{| class="wikitable"
! 方法
! 記事
! 条件
|-
| イメージをフラッシュメディアや光学ディスクに書き込んでそこから起動する。
|
* [[USB インストールメディア]]
* [[光学ディスクドライブ#焼き込み]]
|
* 1台、または多くとも2,3台のマシンへのインストール
* 直接ブート可能なシステムが得られる
|-
| サーバーでイメージをマウントし、クライアントにネットワーク越しでサーバーから起動させる。
|
* [[PXE]]
* [[ディスクレスシステム]]
|
* クライアント・サーバーモデル
* (1 Gbit 以上の) 有線ネットワーク接続
|-
| 既存の Linux でイメージをマウントし、chroot 環境から Arch をインストールする。
|
* [[既存の Linux からインストール]]
* [[SSH からインストール]]
|
* 短いダウンタイムで既存のシステムを置き換える
* ローカルマシンへのインストール、または [[VNC]] か [[SSH]] 経由でリモートマシンへのインストール
|-
| 仮想マシンをセットアップして Arch をゲストとしてインストールする。
|
* [[:カテゴリ:仮想化]]
* [[既存環境を仮想マシンに (から) 移動]]
|
* 仮想化ソフトウェアが動作する OS
* 学習・テスト・デバッグ用の隔離されたシステムが得られる
|-
| Windows 環境と共存するように Arch をインストールする。
|
* [[Windows と Arch のデュアルブート]]
|
* Windows ユーザーと共有できるマシン
* Windows がプリインストールされたデバイスを簡単にファクトリーリセットできること
|-
| Windows Subsystem for Linux に Arch をインストールする。
|
* [[WSL にインストール]]
|
* Windows 10 Creators Update 以上が動作しているマシン
* ネットワークアクセスでないかぎり GUI 無し
|}

== 参考 ==
* [https://projects.archlinux.org/archiso.git/tree/docs/README.transfer README.transfer]
* [https://projects.archlinux.org/archiso.git/tree/docs/README.altbootmethods README.altbootmethods]

Privoxy

2021-02-05T00:53:42Z

Libnumafly: /* Tor による転送 */ privoxyのconfigサンプルより、Torに転送する際の推奨設定値に書換

[[Category:プロキシサーバー]]
[[en:Privoxy]]
[[it:Privoxy]]
{{Related articles start}}
{{Related|Tor}}
{{Related|Polipo}}
{{Related|Hostsblock}}
{{Related articles end}}

[http://www.privoxy.org/ Privoxy] は HTTP プロトコルのフィルタリングプロキシです。よく [[Tor]] と組み合わせて使われます。Privoxy は高度なフィルタリング機能を持ったウェブプロキシで、プライバシーの保護やウェブページのコンテンツのフィルタリング、クッキーの管理やアクセスの制御、広告やバナー、ポップアップの削除などが可能です。スタンドアロンなシステムとマルチユーザーネットワーク両方をサポートしています。

[[Wikipedia:SOCKS|SOCKS]] プロキシを直接使用する場合、ブラウザによって DNS リクエストが漏洩して匿名性が減るために、Privoxy の使用は必須になります。

==インストールとセットアップ==
[[公式リポジトリ]]から {{Pkg|privoxy}} パッケージを[[インストール]]してください。

Privoxy と [[Tor]] を一緒に使う場合、両方のアプリケーションがチェインで情報を交換する必要があります。転送ルールを指定してください。

最後に、ネットワーク上の他のコンピュータから Privoxy を使えるようにしたい場合、以下を追加します:
listen-address [SERVER-IP]:[PORT]

例:
listen-address 192.168.1.1:8118

== i2p ==

[[I2P]] ルーターで .i2p サイトを転送するには、以下を {{ic|/etc/privoxy/config}} に追加:
forward .i2p localhost:4444

==Tor による転送==

{{ic|/etc/privoxy/config}} ファイルを編集して最後の行に以下を追加してください (行末の . に注意):
forward-socks5t / localhost:9050 .

この例では Tor によって使われるデフォルトのポートを使用します。ポート番号を変更している場合は、上記の例の番号も変更してください。Tor をターゲットにする場合は {{ic|forward-socks5}} の代わりに {{ic|forward-socks5t}} を使うことが勧められています。
他のターゲットでも同じ例が使えます。他のプロキシに変更する場合、必要に応じてメソッド ([[Wikipedia:SOCKS#SOCKS5|SOCKS5]]) とポートを指定して下さい。{{ic|/etc/privoxy/config}} のオプションのリストや例はマニュアルの5章を参照してください。

上記の設定で Tor で全てのブラウザのトラフィックが転送されます。.onion のサイトだけを Tor に転送したい場合、以下を使って下さい:
forward-socks5t .onion localhost:9050 .

== ヒントとテクニック‎ ==
=== Privoxy と Polipo ===

{{warning|永続的なキャッシュを使用すると Tor (や他のプロキシ) の匿名性が減ります。特定のリクエストが存在しないことからキャッシュしていることを判別できるからです。}}

Privoxy と一緒に軽量で高速なキャッシュウェブプロキシを使いたい場合、[[Polipo]] を使うことができます。全てのトラフィックを Polipo のポート 8123 に転送して、Privoxy のトラフィックを Polipo に送るようにしてください:
forward / localhost:8123 .

==Privoxy による広告ブロック==

{{warning|広告をブロックすると、ブラウザが判定しやすくなるため、匿名性が減ることにつながります。匿名性のために Tor など他のプロキシを使っている場合は広告ブロックを使用しないほうが賢明です。}}

ウェブブラウザのブロック拡張を使用するとページのロード時間が長くなることがあります。さらに、AdBlock Plus などの拡張はブラウザによってはサポートされていません。システム全体で使えるアドブロックをインストールする方法としてお気に入りのブラウザでプロキシのアドレスを設定することができます。

Privoxy をインストールしたら Opera の urlfilter インポータを [[AUR]] からダウンロード・インストールしてください ([https://aur.archlinux.org/packages/blocklist-to-privoxy/?ID=63431 blocklist-to-privoxy])。[[AUR ヘルパー]]を使ってインストールできます。

上記の "opera-fanboy" フィルターの代わりに adblock plus のフィルターを使うこともできます (fanboy フィルターは長いことアップデートされていません)。こちらのスクリプト (https://github.com/Andrwe/privoxy-blocklist) は自動的に adblock plus のフィルターをダウンロードして、privoxy に対応するフォーマットに変換し、privoxy の設定ファイルを編集してフィルターを追加します。 1) スクリプトを実行すると {{ic|/etc/conf.d/privoxy-blacklist}} が作成されます。 2) {{ic|/etc/conf.d/privoxy-blacklist}} を編集して、"PRIVOXY_USER=" という行とその下の2行をアンコメントしてください。 3) スクリプトをもう一度実行してブロックリストをダウンロード・インストールします。 4) privoxy を再起動してください。

Facebook の "Like" ボタン, Twitter の "follow", Google Plus の "+1" などによるトラッキングをブロックするには {{ic|/etc/privoxy/user.action}} を編集して以下の行を最後に追加してください:
{+block-as-image{Facebook "like" and similar tracking URLs.}}
www.facebook.com/(extern|plugins)/(login_status|like(box)?|activity|fan)\.php
platform.twitter.com/widgets/follow_button?
plusone.google.com

==使用方法==
Privoxy サービス ({{ic|privoxy.service}}) を[[起動]]・[[有効化]]してください。

Privoxy を使うようにプログラムを設定してください。デフォルトのアドレスは:
localhost:8118

Firefox の場合、以下から設定します:
Preferences > Advanced > Network > Settings

Chromium の場合、以下のコマンドで設定できます:

$ chromium --proxy-server="localhost:8118"

また、{{ic|http_proxy}} 環境変数を設定する方法もあります。Firefox, Chromium などのアプリケーションに反映されます:
http_proxy="<nowiki>http://localhost:8118</nowiki>"

==参照==
* [http://www.privoxy.org/ Privoxy 公式ウェブサイト]
* [https://www.torproject.org/index.html.en Tor 公式ウェブサイト]