Provided by: lxc-utils_3.0.3-0ubuntu1~18.04.3_amd64 bug

NAME

       lxc.container.conf - LXC コンテナ設定ファイル

説明

       LXC は良く知られた、多くのテストが行われた Linux コンテナのランタイムです。LXC は、2008 年
       以来アクティブに開発されており、世界中の重要な本番環境で実証されています。開発への貢献者の
       中には、Linux   カーネル内の良く知られた様々なコンテナ機能の実装に貢献した人と同じ人もいま
       す。

       LXC は主にシステムコンテナにフォーカスを当てています。つまり、VM  で得られる環境と可能な限
       り近い環境を提供を提供するにも関わらず、別々のカーネルを実行したり、ハードウェアをすべてシ
       ミュレートしたりすることによるオーバーヘッドがないコンテナのことです。

       このような環境は、名前空間 (namespace)、強制アクセスコントロール、cgroup  といったカーネル
       のセキュリティ機能の組み合わせで実現しています。

       LXC は非特権コンテナをサポートしています。非特権コンテナは、いかなる特権も持たずに実行する
       コンテナです。非特権コンテナの実行には、コンテナを実行しているカーネルにユーザ名前空間
       (user  namespace) のサポートが必要です。LXC は、ユーザ名前空間がメインラインカーネルにマー
       ジされてから、初めて非特権コンテナをサポートしたランタイムです。

       本質的には、ユーザ名前空間は与えられた UID、GID の組を隔離します。ユーザ名前空間は、ホスト
       上の UID、GID のある範囲を、それとは異なるコンテナ上の UID、GID の範囲へマッピングすること
       で実現します。カーネルは、ホスト上では実際には UID、GID は特権を持たないにも関わらず、コン
       テナ内ではすべての  UID、GID が期待されるように見えるように変換を行います。 例えば、コンテ
       ナ内では UID、GID が 0 として実行中のプロセスは、ホスト上では UID、GID が 100000  として見
       えるでしょう。実装と動作の詳細は、ユーザ名前空間の man ページから得られます。UID と GID の
       マッピングは lxc.idmap を使って定義できます。

       Linux コンテナは、簡単な設定ファイルで定義します。設定ファイル中のオプションは key = value
       の形で一行で表します。'#'       は、その行はコメントであることを示します。ケーパビリティや
       cgroup のオプションのような、リスト形式で指定するオプションでは、value  がない形式で指定で
       き、そのように使うと、それ以前に定義した値をすべてクリアします。

       LXC  は、シングルドットを使って設定キーの名前空間を表します。lxc.net.0  のような複雑な設定
       キーは、lxc.net.0.typelxc.net.0.linklxc.net.0.ipv6.address  や、さらに細分化された設定
       向けの色々なサブキーを持つことを意味します。

   設定
       複数の関係するコンテナの管理を容易にするために、コンテナの設定ファイルに別のファイルをロー
       ドすることが可能です。 例えば、ネットワークの設定を、複数のコンテナから include させるよう
       に 1 つのファイルに定義することが可能です。 その場合、コンテナが他のホストに移動すると、そ
       のファイルだけを更新する必要があるかもしれません。

       lxc.include
              include させたいファイルを指定します。 include  するファイルは、lxc  設定ファイルの
              フォーマットとして有効でなければいけません。

   アーキテクチャ
       コンテナに対してアーキテクチャを設定することが可能です。  例えば、64 ビットのホスト上で 32
       ビットのバイナリを動かすために 32 ビットアーキテクチャを設定することが可能です。  この設定
       を行うことにより、パッケージのダウンロードを行うなどの作業のうち、アーキテクチャ名に依存す
       るような作業を行うコンテナスクリプトの修正を行います。

       lxc.arch
              コンテナに設定するアーキテクチャを指定します。

              有効なオプションには以下のようなものがあります。 x86, i686, x86_64, amd64

   ホスト名
       utsname セクションは、コンテナに設定されるホスト名を定義します。  コンテナは、システムのホ
       スト名を変えることなく、自身のホスト名を持つ事が可能です。  このことにより、ホスト名はコン
       テナ専用となります。

       lxc.uts.name
              コンテナのホスト名を指定します。

   クリーンなシャットダウン時のシグナル
       コンテナをクリーンにシャットダウンするためにコンテナの init プロセスに送るシグナル名か番号
       を指定できます。init  システムによって、クリーンなシャットダウンを行うために使うシグナルは
       異なります。このオプションではシグナルとして  kill(1)  で使う形式を指定できます。   例えば
       SIGKILL, SIGRTMIN+14, SIGRTMAX-10 のような形式、もしくは数字を指定します。デフォルトのシグ
       ナルは SIGPWR です。

       lxc.signal.halt
              コンテナをシャットダウンするために使うシグナルを指定します。

   リブート時のシグナル
       コンテナをリブートするために送るシグナル名か番号を指定できます。このオプションではシグナル
       として  kill(1) で使う形式を指定できます。 例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10 のよう
       な形式、もしくは数字を指定します。デフォルトのシグナルは SIGINT です。

       lxc.signal.reboot
              コンテナをリブートするために使うシグナルを指定します。

   強制停止時のシグナル
       コンテナを強制的にシャットダウンするために送るシグナル名か番号を指定できます。このオプショ
       ンではシグナルとして   kill(1)  で使う形式を指定できます。  例えば  SIGKILL,  SIGRTMIN+14,
       SIGRTMAX-10 のような形式、もしくは数字を指定します。デフォルトのシグナルは SIGKILL です。

       lxc.signal.stop
              コンテナを停止するのに使用するシグナルを指定します。

   INIT コマンド
       コンテナの init として使うコマンドを設定します。

       lxc.execute.cmd
              デフォルトで実行するバイナリのコンテナの  root   からの絶対パスを指定します。これは
              lxc-execute のための設定です。

       lxc.init.cmd
              init  として使うバイナリの、コンテナの root からの絶対パスを指定します。これは lxc-
              start のための設定です。デフォルトは /sbin/init です。

   INIT のワーキングディレクトリ
       コンテナのワーキングディレクトリとして、コンテナ内の絶対パスを設定します。LXC は init を実
       行する前に、このディレクトリに移動します。

       lxc.init.cwd
              ワーキングディレクトリとして使うコンテナ内の絶対パス

   INIT が使う ID
       init と後続のコマンドが使う UID/GID を設定します。システムコンテナを起動するのに非 root な
       UID を使うと、特権がないために動作しないでしょう。UID/GID の指定は、通常はアプリケーション
       コンテナの動作の際に役に立ちます。 デフォルト値: UID(0)、GID(0)

       lxc.init.uid
              init が使う UID です。

       lxc.init.gid
              init が使う GID です。

   PROC
       コンテナ内の proc ファイルシステムで設定できるパラメータを設定します。

       lxc.proc.[proc file name]
              設定したい   proc  ファイルシステムのファイル名を指定します。指定できるファイル名は
              /proc/PID/ 以下に存在するものです。 例:

                            lxc.proc.oom_score_adj = 10

   一時的なコンテナ
       シャットダウン後にコンテナを削除するかどうかを指定できます。

       lxc.ephemeral
              指定できる値は 0 または 1 のみです。この値を 1 に設定すると、シャットダウン後にコン
              テナを削除します。

   ネットワーク
       ネットワークセクションは、コンテナ内でどのようにネットワークを仮想化するかを定義します。
       ネットワークの仮想化はレイヤー 2 で作動します。 ネットワークの仮想化を使用するためには、コ
       ンテナのネットワークインターフェースを定義しなければなりません。    いくつかの仮想インター
       フェースをアサインすることができます。  そして、仮に物理ネットワークインターフェースが一つ
       しかなくても、コンテナ内でいくつもの仮想インターフェースを使うことができます。

       lxc.net
              値を指定せずに使い、それ以前に定義されたすべてのネットワークオプションをクリアでき
              ます。

       lxc.net.[i].type
              コンテナがどの種類のネットワーク仮想化を使うかを指定します。すべての lxc.net.* キー
              に、追加のインデックス      i      を使うと、複数のネットワークを指定できます。例え
              ば、lxc.net.0.type = vethlxc.net.1.type = veth は、同じタイプの異なるネットワー
              クを  2 つ指定します。 同じインデックスを指定したキーはすべて同じネットワークの指定
              になります。例えば、lxc.net.0.link = br0lxc.net.0.type と同じネットワークの設定
              になります。 現時点では、以下のネットワーク仮想化のタイプが使えます:

              none: ホストのネットワーク名前空間を共有します。 これにより、ホストのネットワークデ
              バイスをコンテナ内で使うことが可能になります。 もしコンテナもホストも  init  として
              upstart を使っている場合、(例えば) コンテナ内で 'halt' を実行すると、ホストがシャッ
              トダウンしてしまうことにもなります。 非特権コンテナでは、sysfs をマウントできないの
              で、この設定は動作しません。この問題に対する回避策は、ホストの sysfs を bind マウン
              トすることです。ただしこの回避策は安全ではありません。

              empty: ループバックインターフェースだけを作成します。

              veth: 一方がコンテナに、もう一方が lxc.net.[i].link  オプションで指定されたブリッジ
              に接続されるペアの仮想イーサネットデバイスを作成します。 もし、ブリッジが指定されて
              いない場合、veth ペアデバイスは作成されますが、ブリッジには接続されません。  ブリッ
              ジはコンテナが開始する前にシステムで事前に設定しておく必要があります。 lxc はコンテ
              ナ外の設定を扱うことはありません。 デフォルトでは、lxc がコンテナの外部に属するネッ
              トワークデバイスに対する名前を決定します。 しかし、もしこの名前を自分で指定したい場
              合、lxc.net.[i].veth.pair オプションを使って名前を設定し、lxc  に対して指定をするこ
              とができます    (非特権コンテナの場合をのぞきます。セキュリティ上の理由からこのオプ
              ションは無視されます)。

              vlan: vlan インターフェースは lxc.net.[i].link で指定されたインターフェースとリンク
              し、コンテナに割り当てられます。 vlan の指定は lxc.net.[i].vlan.id オプションで指定
              します。

              macvlan: macvlan インターフェースは lxc.net.[i].link により指定されるインターフェー
              スとリンクし、コンテナに割り当てられます。  lxc.net.[i].macvlan.mode でモードを指定
              すると、その macvlan の指定を、同じ上位デバイスで異なる macvlan  の間の通信をする時
              に使います。  指定できるモードは  privatevepabridgepassthru  のいずれかです。
              private  モードの場合、デバイスは同じ上位デバイスの他のデバイスとの通信を行いません
              (デフォルト)。   新しい仮想イーサネットポート集約モード   (Virtual   Ethernet  Port
              Aggregator (VEPA)) である vepa モードの場合、隣接したポートが、ソースとデスティネー
              ションの両方が macvlan ポートに対してローカルであるフレームを全て返すと仮定します。
              すなわち、ブリッジが reflective relay として設定されているということです。 上位デバ
              イスから入ってくるブロードキャストフレームは、VEPA  モードである全ての macvlan イン
              ターフェースに送りつけられます。   ローカルのフレームはローカルには配送されません。
              bridge  モードの場合、同じポートの異なる macvlan インターフェースの間のシンプルなブ
              リッジとして動作します。   あるインターフェースから他のインターフェースへのフレーム
              は、直接配送され、外部には送出されません。 ブロードキャストフレームは、全ての他のブ
              リッジと外部のインターフェースに対して送られます。 しかし、reflective relay  からフ
              レームが返ってきたときは、再度それを配送することはしません。  全ての MAC アドレスを
              知っているので、ブリッジモジュールのように、macvlan ブリッジモードは学習や STP の必
              要はありません。   passthru  モードの場合、物理インターフェースで受け取った全てのフ
              レームは  macvlan  インターフェースに転送されます。passthru  モードの場合、ひとつの
              macvlan インターフェースだけが、ひとつの物理インターフェースに対して設定できます。

              phys: lxc.net.[i].link で指定された、すでに存在しているインターフェースがコンテナに
              割り当てられます。

       lxc.net.[i].flags
              ネットワークに対して行うアクションを指定します。

              up: インターフェースを起動させます。

       lxc.net.[i].link
              実際のネットワークトラフィックに使うインターフェースを指定します。

       lxc.net.[i].mtu
              インターフェースに対する MTU を指定します。

       lxc.net.[i].name
              インターフェース名は動的に割り当てられます。しかし、もしコンテナが使用する設定ファ
              イルが一般的な名前を使用するために、他の特定の名前が必要であれば  (例えば  eth0  な
              ど)、コンテナ内のインターフェースは、このオプションで指定した名前にリネームされま
              す。

       lxc.net.[i].hwaddr
              仮想インターフェースの  MAC  アドレスは、デフォルトでは動的に割り当てられます。しか
              し、MAC アドレスの衝突や、リンクローカルIPv6 アドレスを常に同じにした場合などは、こ
              のオプションが必要です。アドレス中の "x" という文字は、ランダムな値に置き換えられま
              す。これによりテンプレートに hwaddr を設定することが可能になります。

       lxc.net.[i].ipv4.address
              仮想インターフェースに割り当てる ipv4 アドレスを指定します。複数行により複数の ipv4
              アドレスを指定します。このアドレスは  x.y.z.t/m というフォーマットで指定します。例)
              192.168.1.123/24

       lxc.net.[i].ipv4.gateway
              コンテナでゲートウェイとして使う IPv4 アドレスを指定します。アドレスは x.y.z.t とい
              うフォーマットです。例)   192.168.1.123  auto  という特別な値を指定できます。これは
              (lxc.net.[i].link で指定した)  ブリッジインターフェースの最初のアドレスを使用し、そ
              れをゲートウェイに使うという意味になります。auto はネットワークタイプとして vethmacvlan を指定している時だけ有効となります。

       lxc.net.[i].ipv6.address
              仮想インターフェースに割り当てる ipv6 アドレスを指定します。複数行により複数の ipv6
              アドレスを指定します。このアドレスは   x::y/m   というフォーマットで指定します。例)
              2003:db8:1:0:214:1234:fe0b:3596/64

       lxc.net.[i].ipv6.gateway
              コンテナでゲートウェイとして使う IPv6 アドレスを指定します。アドレスは x::y  という
              フォーマットです。例) 2003:db8:1:0::1 auto という特別な値を記述する事も可能です。こ
              れは (lxc.net.[i].link  で指定した)  ブリッジインターフェースの最初のアドレスを使用
              し、それをゲートウェイに使うという意味になります。auto   はネットワークタイプとして
              vethmacvlan を指定している時だけ有効となります。

       lxc.net.[i].script.up
              ホスト側から使われる、ネットワークの作成と設定が済んだ後に実行するスクリプトを指定
              します。

              すべてのフックで追加の情報が使えます。以下の情報がスクリプトに提供されます:

              • LXC_HOOK_TYPE: フックタイプ。'up' か 'down' のいずれかです

              • LXC_HOOK_SECTION: セクションタイプとして 'net' が設定されます

              • LXC_NET_TYPE: ネットワークタイプ。有効なネットワークタイプのうちのひとつです (例:
                'macvlan', 'veth')

              • LXC_NET_PARENT:                ホスト上の親デバイス名。これはネットワークタイプが
                'macvlan'、'veth'、'phys' のどれかのときだけ設定されます

              • LXC_NET_PEER:  ホスト上のピアデバイス名。これはネットワークタイプが 'veth' の場合
                のみ設定されます。この情報は lxc.hook.version が 1 に設定されている場合のみ設定さ
                れます

       この情報が環境変数の形で提供されるか、スクリプトへの引数の形で提供されるかは
       lxc.hook.version の値によって決まります。もし lxc.hook.version が  1  に設定されている場合
       は、環境変数の形で提供されます。もし  0 が設定されている場合は、スクリプトへの引数として提
       供されます。

       スクリプトからの標準出力は debug  レベルでロギングされます。標準エラー出力はロギングされま
       せん。しかし、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可
       能です。

       lxc.net.[i].script.down
              ホスト側から使われる、ネットワークを破壊する前に実行するスクリプトを指定します。

              すべてのフックで追加の情報が使えます。以下の情報がスクリプトに提供されます:

              • LXC_HOOK_TYPE: フックタイプ。'up' か 'down' のいずれかです

              • LXC_HOOK_SECTION: セクションタイプとして 'net' が設定されます

              • LXC_NET_TYPE: ネットワークタイプ。有効なネットワークタイプのうちのひとつです (例:
                'macvlan', 'veth')

              • LXC_NET_PARENT:                ホスト上の親デバイス名。これはネットワークタイプが
                'macvlan'、'veth'、'phys' のどれかのときだけ設定されます

              • LXC_NET_PEER: ホスト上のピアデバイス名。これはネットワークタイプが 'veth'  の場合
                のみ設定されます。この情報は lxc.hook.version が 1 に設定されている場合のみ設定さ
                れます

       この情報が環境変数の形で提供されるか、スクリプトへの引数の形で提供されるかは
       lxc.hook.version  の値によって決まります。もし  lxc.hook.version が 1 に設定されている場合
       は、環境変数の形で提供されます。もし 0  が設定されている場合は、スクリプトへの引数として提
       供されます。

       スクリプトからの標準出力は  debug レベルでロギングされます。標準エラー出力はロギングされま
       せん。しかし、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可
       能です。

   新しい擬似端末のインスタンス (DEVPTS)
       さらに厳しい隔離のために、コンテナは自身のプライベートな  pseudo tty (擬似端末) を持つこと
       が可能です。

       lxc.pty.max
              もし設定された場合、コンテナは新しい pseudo tty  インスタンスを持ち、それを自身のプ
              ライベートとします。  この値は pts インスタンスに許可される pseudo tty の最大数を指
              定します (この制限はまだ実装されていません)。

   コンテナのシステムコンソール
       コンテナでルートファイルシステムを持つように設定されており、inittab ファイルでコンソールの
       使用が設定されている場合、このコンソールの出力がどこになされるのかを指定したいと思うでしょ
       う。

       lxc.console.buffer.size
              このオプションを設定すると、liblxc はインメモリのリングバッファを割り当てます。コン
              テナのコンソールはリングバッファに出力されます。リングバッファは少なくとも標準ペー
              ジサイズの大きさでなければなりません。ページサイズより小さい値を与えた場合
              は、liblxc  はページサイズのリングバッファを割り当てます。ページサイズは通常は  4KB
              です。 'auto' を指定すると、liblxc は 128KB のリングバッファを割り当てます。 リング
              バッファサイズを数値指定する場合、値がバイトに変換されるときに   2   の累乗になりま
              す。サイズ接頭辞付きの単位として   'KB'、'MB'、'GB'   が使えます。(この場合の変換は
              1024  の倍数に基づいています。つまり 'KB' == 'KiB'、'MB' == 'MiB'、'GB' == 'GiB' と
              いう意味です。加えて、単位の大文字小文字は無視されます。すなわち   'kB'、'KB'、'Kb'
              は同一に扱われます。)

       lxc.console.size
              liblxc  は lxc.console.logfile で指定したコンソールログのサイズを、このオプションで
              設定した値に制限します。ログファイルのサイズは少なくとも標準ページサイズでなければ
              なりません。ページサイズ以下の値を設定した場合は、liblxc   はログファイルのサイズを
              ページサイズに設定します。ページサイズは通常は   4KB   です。   'auto'   を指定する
              と、liblxc はログファイルのサイズを 128KB に制限します。 ログファイルサイズの値を数
              値指定する場合、値がバイトに変換されるときに 2 の累乗になります。サイズ接頭辞付きの
              単位として 'kB'、'MB'、'GB' が使えます。(この場合の変換は 1024 の倍数に基づいていま
              す。つまり 'kB' == 'KiB'、'MB' == 'MiB'、'GB' == 'GiB' という意味です。加えて、単位
              の大文字小文字は無視されます。すなわち  'kB'、'KB'、'Kb' は同一に扱われます。) ディ
              スク上のコンソールリングバッファとミラーになるようにしたい場合は、lxc.console.sizelxc.console.buffer.size の値を同じ値に設定します。

       lxc.console.logfile
              コンソール出力を書き込むファイルのパスを指定します。ディスクに保存されるリングバッ
              ファログと異なり、このファイルはサイズが大きくなり続けるので、ファイルがローテート
              や削除されない限りは、ユーザのディスクをいっぱいにしてしまう可能性があります。この
              問題は、インメモリのリングバッファオプションである、lxc.console.buffer.sizelxc.console.buffer.logfile を使うことでも回避できます。

       lxc.console.rotate
              lxc.console.logfile  で指定したコンソールログファイルをローテートするかどうかを指定
              します。ユーザはログファイルをローテートするように API リクエストを送ることができま
              す。古いログファイルは、元のファイル名と同じ名前のファイルに  ".1" というサフィック
              スが付け加わります。     ユーザがコンソールログでディスクがいっぱいになるのを防ぐに
              は、ログファイルをローテートし、不要なログファイルを削除してください。この問題はイ
              ンメモリのリングバッファオプションである         lxc.console.buffer.sizelxc.console.buffer.logfile を使うことでも防げます。

       lxc.console.path
              コンソールを割り当てるデバイスのパスを指定します。'none' というキーワードは、単純に
              コンソールを無効にします。 'none'  を指定し、コンテナ内のコンソールに対するデバイス
              ノードを  /dev/console  に作成するか、もしくはホストの  /dev/console をコンテナ内の
              /dev/console に bind mount する場合、そのコンテナはホストの /dev/console へ直接アク
              セスを行うことに注意が必要です。 そのコンテナがデバイスへの書き込み権を持っている場
              合は危険ですので、注意してこの指定を使用する必要があります。

   TTY を通したコンソール
       このオプションはコンテナが root ファイルシステムを持つように設定されており、inittab ファイ
       ルで  tty 上に getty の起動が設定されている場合に役に立ちます。 このオプションはコンテナで
       利用できる tty の数を指定します。 inittab ファイルに設定する getty  の数は、このオプション
       の指定する  tty の数より大きくしてはいけません。 さもなければ、超過した分の getty セッショ
       ンはコンソールか /var/log/messages  にうっとうしいメッセージを生死を表示しながら、永久に生
       死を繰り返すでしょう。

       lxc.tty.max
              コンテナに作成出来る tty の数を指定します。

   コンソールデバイスの位置
       LXC のコンソールはホストによって作られ、コンテナ内で要求されたデバイスに bind マウントされ
       た Unix98 PTY 経由で提供されます。 デフォルトでは /dev/console/dev/ttyN に bind マウン
       トされます。 これはゲスト内でのパッケージのアップグレードを妨げる可能性があります。 なので
       /dev 以下のディレクトリを指定することができます。 LXC はこのディレクトリ以下にファイルを作
       成し、これらのファイルを  bind  マウントします。  そして、これらの (作成された) ファイルは
       /dev/console/dev/ttyN にシンボリックリンクされます。  シンボリックリンクを消去したり置
       き換えたりすることは可能ですから、パッケージのアップグレードは成功します。

       lxc.tty.dir
              コンテナのコンソールデバイスを作成するための  /dev 以下のディレクトリを指定します。
              LXC は /dev/console に対する bind mount や /dev/console  デバイスノードをこのディレ
              クトリ以下に移動することに注意が必要です。

   /DEV ディレクトリ
       デフォルトでは、lxc  はコンテナの /dev 以下に fd, stdin, stdout, stderr のシンボリックリン
       クを作成しますが、自動的にはデバイスノードのエントリは作成しません。    これは、コンテナの
       rootfs  で必要な設定を行えるようにするものです。 lxc.autodev が 1 に設定されている場合、コ
       ンテナの rootfs をマウントした後、LXC は新しい tmpfs を /dev 以下にマウントします (500k 制
       限の)。 そして初期デバイスの最小限のセットを作成します。 これは、"systemd" ベースの "init"
       環境のコンテナを起動する時に通常必要ですが、他の環境の場合はオプショナルなものです。  コン
       テナの /dev ディレクトリ内の追加デバイスは lxc.hook.autodev フックを使用して作成されます。

       lxc.autodev
              コンテナの起動時に  LXC  が /dev をマウントして最小限の /dev を作成するのを止めるに
              は、この値を 0 に設定してください。

   マウントポイント
       マウントポイントセクションは、マウントするための区別された場所を指定します。  これらのマウ
       ントポイントは、コンテナだけに見え、コンテナ外で実行されるプロセスから見えることはありませ
       ん。 例えば、/etc/var/home をマウントするときに役に立つでしょう。

       注意: 通常 LXC  は、マウント対象と相対パス指定のバインドマウントを、適切にコンテナルート以
       下に閉じ込めます。  これは、ホストのディレクトリやファイルに対して重ね合わせを行うようなマ
       ウントによる攻撃を防ぎます。(絶対パス指定のマウントソース中の各パスがシンボリックリンクで
       ある場合は無視されます。)  しかし、もしコンテナの設定が最初に、/home/joe  のようなコンテナ
       ユーザのコントロール配下にあるディレクトリを、コンテナ中のある  path  にマウントし、その後
       path  以下でマウントが行われるような場合、コンテナユーザがタイミングを見計らって自身のホー
       ムディレクトリ以下でシンボリックリンクを操作するような TOCTTOU  攻撃が成立する可能性があり
       ます。

       lxc.mount.fstab
              マウント情報の書かれた  fstab フォーマットで書かれたファイルの場所を指定します。 マ
              ウントする場所は相対バスで書くことができます。そして、ほとんどの場合にコンテナの
              root からの相対パスとなるはずです。例えば、以下のように書きます。

                           proc proc proc nodev,noexec,nosuid 0 0

              この例は、root  ファイルシステムがどこにあっても、コンテナの /proc 以下に proc ファ
              イルシステムをマウントします。これは、ブロックデバイスがバックエンドのファイルシス
              テムだけでなく、コンテナのクローンにも柔軟に対応できます。

              ファイルシステムがイメージファイルやブロックデバイスからマウントされている場合、3
              つ目のフィールド (fs_vfstype) は mount(8) のように auto  を指定することはできず、明
              確に指定しなければいけません。

       lxc.mount.entry
              fstab  フォーマットの一行と同じフォーマットのマウントポイントの指定をします。  加え
              て、LXC では rslave や rprivate  といったマウント・プロパゲーションオプションと、独
              自の 3 つのマウントオプションが使えます。 optional は、マウントが失敗しても失敗を返
              さずに無視します。 create=dircreate=file は、マウントポイントをマウントする際に
              ディレクトリもしくはファイルを作成します。  relative を指定すると、マウントされたコ
              ンテナルートからの相対パスとして取得されます。

                            dev/null proc/kcore none bind,relative 0 0

              は dev/null を ${LXC_ROOTFS_MOUNT}/dev/null と展開し、コンテナ内の proc/kcore  にマ
              ウントします。

       lxc.mount.auto
              標準のカーネルファイルシステムで自動的にマウントするものを指定します。 これは劇的に
              設定を容易にする可能性があります。

              • proc:mixed (or proc): /proc を読み書き可能でマウントします。 ただし、/proc/sys/proc/sysrq-trigger  は、セキュリティとコンテナの隔離の目的でリードオンリーで再マ
                ウントされます。

              • proc:rw: /proc を読み書き可能でマウントします。

              • sys:mixed (or sys): /sys/devices/virtual/net のみ書き込み可能で、その他の /sys は
                リードオンリーでマウントします。

              • sys:ro: /sys を、セキュリティとコンテナの隔離の目的でリードオンリーでマウントしま
                す。

              • sys:rw: /sys を読み書き可能でマウントします。

              • cgroup:mixed: /sys/fs/cgroup を tmpfs  でマウントし、そのコンテナの追加が行われた
                全ての階層に対するディレクトリを作成し、それらの階層内に  cgroup 名でサブディレク
                トリを作成し、そのコンテナ自身の cgroup  をそのディレクトリにバインドマウントしま
                す。コンテナは自身の  cgroup ディレクトリに書き込みが可能ですが、親ディレクトリは
                リードオンリーで再マウントされているため書き込めません。

              • cgroup:mixed:force:  force   を指定すると、LXC   はあらゆる状況でコンテナのための
                cgroup   マウントを実行します。それ以外は   cgroup:mixed   と同様です。これは主に
                cgroup 名前空間が有効な場合に便利です。この場合は完全に安全ですので、LXC は通常コ
                ンテナの init バイナリが cgroup をマウントしたままの状態にしておきます。

              • cgroup:ro:  cgroup:mixed と同様にマウントされますが、全てリードオンリーでマウント
                されます。

              • cgroup:ro:force: force を指定すると、LXC はあらゆる状況でコンテナのための  cgroup
                マウントを実行します。それ以外は cgroup:ro と同様です。これは主に cgroup 名前空間
                が有効な場合に便利です。この場合は完全に安全ですので、LXC  は通常コンテナの  init
                バイナリが cgroup をマウントしたままの状態にしておきます。

              • cgroup:rw:  cgroup:mixed と同様にマウントされますが、全て読み書き可能でマウントさ
                れます。 コンテナ自身の cgroup に至るまでのパスも書き込み可能になることに注意が必
                要ですが、cgroup  ファイルシステムにはならず、 /sys/fs/cgroup の tmpfs の一部分に
                なるでしょう。

              • cgroup:rw:force: force を指定すると、LXC はあらゆる状況でコンテナのための  cgroup
                マウントを実行します。それ以外は cgroup:rw と同様です。これは主に cgroup 名前空間
                が有効な場合に便利です。この場合は完全に安全ですので、LXC  は通常コンテナの  init
                バイナリが cgroup をマウントしたままの状態にしておきます。

              • cgroup  (マウントオプションなしの場合): コンテナが CAP_SYS_ADMIN ケーパビリティを
                保持している場合、cgroup:rw となります。保持していない場合、cgroup:mixed となりま
                す。

              • cgroup-full:mixed: /sys/fs/cgroup を tmpfs でマウントし、そのコンテナの追加が行わ
                れた全ての階層構造に対するディレクトリを作製し、ホストからコンテナまでの階層構造
                を全てバインドマウントし、コンテナ自身の  cgroup を除いてリードオンリーにします。
                cgroup と比べると、コンテナ自身の cgroup に至るまでの全てのパスが tmpfs  の下層の
                シンプルなディレクトリとなり、コンテナ自身の  cgroup の外ではリードオンリーになり
                ますが、/sys/fs/cgroup/$hierarchy はホストの全ての cgroup 階層構造を含みます。 こ
                れにより、コンテナにはかなりの情報が漏洩します。

              • cgroup-full:mixed:force: force を指定すると、LXC はあらゆる状況でコンテナのための
                cgroup マウントを実行します。それ以外は cgroup-full:mixed  と同様です。これは主に
                cgroup 名前空間が有効な場合に便利です。この場合は完全に安全ですので、LXC は通常コ
                ンテナの init バイナリが cgroup をマウントしたままの状態にしておきます。

              • cgroup-full:ro: cgroup-full:mixed  と同様にマウントされますが、全てリードオンリー
                でマウントされます。

              • cgroup-full:ro:force:  force  を指定すると、LXC  はあらゆる状況でコンテナのための
                cgroup  マウントを実行します。それ以外は  cgroup-full:ro   と同様です。これは主に
                cgroup 名前空間が有効な場合に便利です。この場合は完全に安全ですので、LXC は通常コ
                ンテナの init バイナリが cgroup をマウントしたままの状態にしておきます。

              • cgroup-full:rw: cgroup-full:mixedと同様にマウントされますが、全て読み書き可能でマ
                ウントされます。 この場合、コンテナは自身の cgroup から脱出する可能性があることに
                注意してください (コンテナが CAP_SYS_ADMIN を持ち、自身で cgroup ファイルシステム
                をマウント可能なら、いずれにせよそのようにするかもしれないことにも注意してくださ
                い)。

              • cgroup-full:rw:force:  force  を指定すると、LXC  はあらゆる状況でコンテナのための
                cgroup   マウントを実行します。それ以外は  cgroup-full:rw  と同様です。これは主に
                cgroup 名前空間が有効な場合に便利です。この場合は完全に安全ですので、LXC は通常コ
                ンテナの init バイナリが cgroup をマウントしたままの状態にしておきます。

              • cgroup-full  (マウントオプションなしの場合):  コンテナが CAP_SYS_ADMIN ケーパビリ
                ティを保持している場合、cgroup-full:rw               となります。保持していない場
                合、cgroup-full:mixed となります。

       cgroup 名前空間が有効の場合、cgroup の自動マウントの指定はどれも無視されます。これは、コン
       テナが自身でファイルシステムをマウントするため、自動マウントがコンテナの init を混乱させる
       可能性があるためです。

       cgroup  ファイルシステムの自動マウントが有効の場合、/sys/fs/cgroup 以下の tmpfs は常に読み
       書き可能でマウントされることに注意が必要です (しかし :mixed:ro  の場合は、個々の階層の
       /sys/fs/cgroup/$hierarchy は読み込み専用となるでしょう)。これは Ubuntu の mountall(8) コマ
       ンドの特異な動きに対処するためのものです。特異な動きとは、/sys/fs/cgroup  が読み込み専用で
       マウントされた状態で、コンテナが CAP_SYS_ADMIN を持たない場合、/sys/fs/cgroup を読み書き可
       能で再マウントしようとしてできないため、コンテナのブート時にユーザからの入力を待ってしまう
       というものです。

       例:

                     lxc.mount.auto = proc sys cgroup
                     lxc.mount.auto = proc:rw sys:rw cgroup-full:rw

   ルートファイルシステム
       コンテナのルートファイルシステムは、ホストのルートファイルシステムと異なるようにすることも
       可能です。

       lxc.rootfs.path
              コンテナのルートファイルシステムを指定します。 この値はイメージファイル、ディレクト
              リ、ブロックデバイスのどれかを取ることができます。 もし指定されない場合、コンテナは
              ホストとルートファイルシステムを共有します。

              ディレクトリ、単純なブロックデバイスのバックエンドを持つコンテナの場合、パス名を使
              うことができます。  もし rootfs が nbd デバイスの場合、nbd:file:1 という指定は file
              を nbd デバイスとして使用し、その 1 番目のパーティションが rootfs  としてマウントさ
              れます。       nbd:file       という指定は、nbd      デバイス自身をマウントします。
              overlayfs:/lower:/upper という指定は、rootfs は /lower という読み込み専用でマウント
              されるディレクトリの上に、/upper というディレクトリを読み書き可能で重ね合わせてマウ
              ントします。 overlayfs は、複数の /lower ディレクトリを指定できます。 loop:/file/file を loop デバイスとして使用し、loop デバイスをマウントします。

       lxc.rootfs.mount
              root ファイルシステムの変更の前に、lxc.rootfs.path を再帰的にどこにバインドするのか
              を指定します。これは  pivot_root(8)  システムコールが確実に成功する事を保証します。
              どんなディレクトリでも良く、デフォルトでも通常は動くはずです。

       lxc.rootfs.options
              rootfs をマウントするときに追加したいマウントオプション。

   CONTROL GROUP
       CONTROL GROUP セクションは、(lxc とは) 別のサブシステムの設定を含みます。 lxc は、このサブ
       システム名の正しさはチェックしません。  実行時のエラーを検出するのに不便ですが、別の将来の
       サブシステムをサポート出来るという有利な点もあります。

       lxc.cgroup.[control name]
              legacy  な  cgroup  階層  (cgroup  v1) に設定する値を指定します。コントローラー名は
              control group そのままの名前です。 許される名前や値の書式は LXC  が指定することはな
              く、コンテナが実行された時に実行されている  Linux カーネルの機能に依存します。 例え
              ば lxc.cgroup.cpuset.cpus のようになります。

       lxc.cgroup2.[controller name]
              単一の cgroup 階層 (cgroup v2) に設定する値を指定します。  許される名前や値の書式は
              LXC が指定することはなく、コンテナが実行された時に実行されている Linux カーネルの機
              能に依存します。 例えば lxc.cgroup2.memory.high のようになります。

       lxc.cgroup.dir
              コンテナの cgroup を作成するパスやディレクトリを指定します。 例えば、"c1"  という名
              前のコンテナで  lxc.cgroup.dir = my-cgroup/first のように設定すると、"my-cgroup" の
              サブ cgroup  のようにコンテナの  cgroup  を作成します。  例えば、ユーザのカレントの
              cgroup  である  "my-user" が cgroup v1 階層にある cpuset コントローラの root cgroup
              内に存在する場合、この設定は "/sys/fs/cgroup/cpuset/my-user/my-cgroup/first/c1"  と
              いう  cgroup をこのコンテナ向けに作成します。 存在しない cgroup は LXC が作成します
              が、ユーザがカレントの cgroup に書き込み権を持っていることが前提となります。

   ケーパビリティ
       コンテナが root 権限で実行されていても、コンテナ内ではケーパビリティ (capabilities) を削除
       する事は可能です。

       lxc.cap.drop
              コンテナ内で削除するケーパビリティ (capability) を指定します。 一行でスペース区切り
              で複数のケーパビリティを指定することも可能です。 指定は、"CAP_"  というプレフィック
              スなしで、小文字でケーパビリティを指定します。  例えば、CAP_SYS_MODULE というケーパ
              ビリティは sys_module  と指定する必要があります。  詳しくは以下を参照してください。
              capabilities(7)  この設定を、値を指定しない状態で使った場合、それ以前に指定された削
              除対象のケーパビリティの指定をすべてクリアします (lxc.cap.drop に何も指定しない状態
              になります)。

       lxc.cap.keep
              コンテナ内で維持するケーパビリティを指定します。指定した以外の全てのケーパビリティ
              はドロップされます。 特別な値 "none" が指定されている時点で、lxc はこの時点で保持す
              ることになっている全てのケーパビリティをクリアします。"none" を単独で使用するとすべ
              てのケーパビリティを削除できます。

   名前空間
       名前空間は clone したり (lxc.namespace.clone)、keep したり (lxc.namespace.keep)、share  し
       たり (lxc.namespace.share.[namespace identifier]) できます。

       lxc.namespace.clone
              コンテナ作成時に作成する名前空間を指定します。作成する名前空間はスペース区切りのリ
              ストで指定します。指定する名前空間名は、/proc/PID/ns ディレクトリ内に存在する標準の
              名前空間指示子でなければなりません。 lxc.namespace.clone を明示的に設定していない場
              合は、カーネルがサポートするすべての名前空間と現在の設定が使われます。

              新しいマウント、ネット、IPC 名前空間を作る場合は lxc.namespace.clone=mount net  ipc
              と指定します。

       lxc.namespace.keep
              コンテナが、作成元のプロセスから継承する  (新しい名前空間を作らずに元のプロセスの名
              前空間のまま実行する)  名前空間を指定します。継承する名前空間はスペース区切りのリス
              トで指定します。指定する名前空間名は、/proc/PID/ns ディレクトリ内に存在する標準の名
              前空間指示子でなければなりません。lxc.namespace.keep はブラックリストを指定するオプ
              ションです。つまり、コンテナに特定の名前空間を使い続けることを強制したい場合に便利
              です。

              ネットワーク、ユーザ、IPC  名前空間を元のプロセスの名前空間のままで実行したい場合は
              lxc.namespace.keep=user net ipc と指定します。

              PID  名前空間を共有すると、ほとんどの init で動作しない可能性があることに注意してく
              ださい。

              コンテナが新しいユーザ名前空間をリクエストし、そのコンテナがネットワーク名前空間は
              継承したい場合は、ユーザ名前空間も同様に継承する必要があることに注意してください。

       lxc.namespace.share.[namespace identifier]
              他のコンテナやプロセスから継承する名前空間を指定します。[namespace  identifier]  に
              は、/proc/PID/ns ディレクトリ内に現れる名前空間のひとつが入ります。

              他のプロセスから名前空間を継承するには、lxc.namespace.share.[namespace  identifier]
              の値をプロセスの PID に設定します。例えば lxc.namespace.share.net=42 のようになりま
              す。

              他のコンテナから名前空間を継承するには、lxc.namespace.share.[namespace  identifier]
              の値をコンテナ名に設定します。例えば lxc.namespace.share.pid=c3 のようになります。

              標準の  liblxc のパスとは異なるコンテナパスに存在する他のコンテナから名前空間を継承
              するには、lxc.namespace.share.[namespace identifier] をそのコンテナのフルパスで指定
              します。例えば lxc.namespace.share.user=/opt/c3 のようになります。

              名前空間を継承するためには、呼び出し元が継承元のプロセスまたはコンテナに対して十分
              な権限を持っている必要があります。

              システムコンテナ間での PID 名前空間の共有は、ほとんどの init システムではうまく動作
              しない可能性があることに注意が必要です。

              ふたつのプロセスが異なるユーザ名前空間に存在し、そのうちのひとつが他のネットワーク
              名前空間を継承したい場合、通常はユーザ名前空間も同様に継承する必要があることに注意
              が必要です。

   リソース制限
       コンテナに対するソフトもしくはハードリミットを変更できます。非特権コンテナでは、制限を下げ
       ることしかできません。明示的に指定されていないリソースは継承されます。

       lxc.prlimit.[limit name]
              設定したいリソースと制限値を指定します。制限値はコロンで区切られた 2 つの値で指定し
              ます。値は数値もしくは 'unlimited' で指定します。ソフトもハードも同じ値を指定する場
              合は単一の値を指定できます。指定できる名前は、"RLIMIT_"  接頭辞がなく小文字で書かれ
              た、"RLIMIT_"  リソース名です。例えば、RLIMIT_NOFILE は "nofile" と指定します。詳し
              くは setrlimit(2) を参照してください。 値を指定せずに使用した場合、lxc はこの指定以
              前に設定されたリソース制限をクリアします。明示的に制限が設定されていないリソースに
              ついては、コンテナを起動したプロセスから継承します。

   SYSCTL
       コンテナ用のカーネルパラメータを設定します。

       lxc.sysctl.[kernel parameters name]
              設定したいカーネルパラメータを指定します。指定できるパラメータは /proc/sys 以下に存
              在するものです。 すべての sysctl パラメータが仮想化(名前空間化)されているわけでは
              ないことに注意してください。仮想化されていない sysctl  を設定すると、システムワイド
              で設定が変更されてしまいます。  sysctl(8).   値を指定しないでこの設定を指定した場合
              は、この設定より前に設定されたパラメータをクリアします。

   APPARMOR プロファイル
       lxc が apparmor サポートでコンパイルされ、インストールされている場合で、ホストで  apparmor
       が有効な場合、コンテナが従って動くべき apparmor プロファイルは、コンテナの設定で指定するこ
       とが可能です。   デフォルトは、ホストのカーネルで   cgroup   名前空間が使える場合は   lxc-
       container-default-cgnsです。使えない場合は lxc-container-default です。

       lxc.apparmor.profile
              コンテナが従うべき apparmor プロファイルを指定します。 コンテナが apparmor による制
              限を受けないように設定するには、以下のように設定します。

              lxc.apparmor.profile = unconfined

              もし apparmor プロファイルが変更されないままでなくてはならない場合  (ネストしたコン
              テナである場合や、すでに confined されている場合) は以下のように設定します。

              lxc.apparmor.profile = unchanged

       lxc.apparmor.allow_incomplete
              apparmor プロファイルはパス名ベースですので、多数のファイルの制限を行う際、執念深い
              攻撃者に対して効果的であるためにはマウントの制限が必要です。 しかし、これらのマウン
              トの制限は    upstream   のカーネルではまだ実装されていません。マウントの制限なしで
              も、apparmor プロファイルによって予想外のダメージに対する保護が可能です。

              このフラグが 0 の場合 (デフォルト)、カーネルが apparmor  のマウント機能をサポートし
              ていない場合にコンテナが起動しません。これはカーネルを更新した後に機能が退行したこ
              とが検出できるようにするためです。 不完全な apparmor の保護の下でコンテナを起動する
              ためには、このフラグを 1 に設定してください。

   SELINUX コンテキスト
       lxc が SELinux サポートでコンパイルされ、インストールされている場合で、ホストで SELinux が
       有効な場合、コンテナが従って動くべき SELinux  コンテキストは、コンテナの設定で指定すること
       が可能です。 デフォルトは unconfined_t であり、これは lxc がコンテキストを変えないという意
       味になります。 ポリシーの例と追加の情報は /usr/share/lxc/selinux/lxc.te ファイルを参照して
       ください。

       lxc.selinux.context
              コンテナが従うべき  SELinux コンテキストを指定するか、unconfined_t を指定します。例
              えば以下のように設定します。

              lxc.selinux.context = system_u:system_r:lxc_t:s0:c22

   SECCOMP の設定
       コンテナは、起動時に seccomp  プロファイルをロードすることで、利用可能なシステムコールを減
       らして起動することが可能です。  seccomp の設定ファイルは、1 行目がバージョン番号、2 行目が
       ポリシーのタイプで始まる必要があり、その後に設定を書きます。

       現時点では、バージョン番号は 1 と 2 をサポートしています。バージョン 1  では、ポリシーはシ
       ンプルなホワイトリストですので、2 行目は "whitelist" でなければなりません。 そして残りの行
       には 1 行に 1 つずつ、システムコール番号を書きます。各行のシステムコール番号がホワイトリス
       ト化され、リストにない番号は、そのコンテナではブラックリストに入ります。

       バージョン  2 では、ポリシーはブラックリストもしくはホワイトリストで表され、ルールごとのア
       クションと、ポリシーごとのデフォルトのアクションを設定できます。そして、アーキテクチャごと
       の設定と、テキストで書かれたシステムコール名での設定が可能です。

       以下にブラックリストのポリシーの例を示します。これは  mknod 以外の全てのシステムコールが許
       可され、mknod が呼ばれると、何もせずに単に 0(成功) を返します。

             2
             blacklist
             mknod errno 0

       lxc.seccomp.profile
              コンテナがスタートする前にロードする seccomp の設定を含むファイルを指定します。

   PR_SET_NO_NEW_PRIVS
       PR_SET_NO_NEW_PRIVS を付与すると、対象の execve() は、execve()  の呼び出しなしでは実行でき
       なかったことに対する特権を許可しなくなります (例えば、set-user-ID、set-group-ID 許可ビット
       や、ファイルケーパビリティが動作しなくなります)。 一度設定されると、このビットは解除できま
       せん。このビットの設定は fork() や clone() で生成される子プロセスにも継承され、execve() の
       前後で保持されます。 PR_SET_NO_NEW_PRIVS は、コンテナに適用しようとする AppArmor  プロファ
       イルもしくは SELinux コンテキストへの変更がなされたあとに適用されます。

       lxc.no_new_privs
              コンテナに対して PR_SET_NO_NEW_PRIVS ビットを設定するかどうかを指定します。1 に設定
              すると有効になります。

   UID のマッピング
       コンテナは、ユーザとグループの id のマッピングを持った専用のユーザ名前空間で起動することが
       可能です。 たとえば、コンテナ内のユーザ id 0 を、ホストのユーザ id 200000 にマッピングする
       ことが可能です。 コンテナの root  ユーザはコンテナ内では特権を持ちますが、ホストでは特権を
       持ちません。  通常は、システムコンテナは  id の範囲を要求し、それをマッピングします。 例え
       ば、コンテナ内のユーザとグループの id 0 から 20,000 を 200,000 から 220,000 にマッピングし
       ます。

       lxc.idmap
              4 つの値を記述する必要があります。 最初の文字は 'u' か 'g' のどちらかで、ユーザかグ
              ループの ID のどちらをマッピングするかを指定します。 次はコンテナのユーザ名前空間内
              に現れる最初のユーザ  ID です。 その次は、そのユーザ ID のホスト上での値です。 最後
              は、ID のマッピングをいくつ連続して行うかの数を指定します。

   コンテナのフック
       コンテナのフックは、コンテナの存続期間の色々な場面で実行することのできるプログラムやスクリ
       プトです。

       コンテナフックが実行されるとき、追加の情報が渡されます。追加の引数がコマンドライン引数で渡
       されるか、環境変数経由で渡されるかを判断するのに、lxc.hook.version が使えます。引数は:

       • コンテナ名

       • セクション (常に 'lxc')

       • フックのタイプ ('clone' や 'pre-mount' など)

       • 追加の引数。clone フックの場合、lxc-clone に渡される追加の引数は、フックへの引数として追
         加されます。stop  フックの場合は、コンテナの名前空間のそれぞれに対するファイルディスクリ
         プタへのパスが、名前空間名とともに渡されます。

       次の環境変数がセットされます。

       • LXC_CGNS_AWARE: コンテナで cgroup namespace が使えるかどうか

       • LXC_CONFIG_FILE: コンテナの設定ファイルのパス

       • LXC_HOOK_TYPE: フックのタイプ (例えば 'clone'、'mount'、'pre-mount')。この環境変数が存在
         するかどうかは  lxc.hook.version の値次第です。この値が 1 なら、LXC_HOOK_TYPE が設定され
         ています。

       • LXC_HOOK_SECTION: セクションタイプ (例えば 'lxc'、'net')。この環境変数が存在するかどうか
         は lxc.hook.version の値次第です。この値が 1 なら、LXC_HOOK_TYPE が設定されています。

       • LXC_HOOK_VERSION: フックのバージョン。この値は、コンテナの lxc.hook.version の値と同じで
         す。もし、この値が 0 に設定されているなら、古いスタイルのフックが使われます。もし 1 に設
         定されているなら、新しいスタイルのフックが使われます。

       • LXC_LOG_LEVEL: コンテナのログレベル

       • LXC_NAME: コンテナ名

       • LXC_[NAMESPACE IDENTIFIER]_NS: コンテナの名前空間が参照する /proc/PID/fd/ 以下のファイル
         ディスクリプタのパス。それぞれの名前空間ごとに別々の環境変数になります。これらの環境変数
         は lxc.hook.version が 1 に設定されてる場合のみ設定されます。

       • LXC_ROOTFS_MOUNT: マウントされた root ファイルシステムへのパス

       • LXC_ROOTFS_PATH: コンテナの lxc.rootfs.path エントリ。これはマウントされた rootfs が存在
         する場所にはならないでしょう。それには LXC_ROOTFS_MOUNT を使用してください。

       • LXC_SRC_NAME: clone フックの場合、元のコンテナの名前

       スクリプトからの標準出力は debug レベルでロギングされます。 標準エラー出力はロギングされま
       せん。  しかし、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは
       可能です。

       lxc.hook.version
              環境変数経由の新しいスタイルで引数を渡すには 1 に設定します。そうでなく、引数として
              渡すには 0 に設定します。この設定は、古い方法でスクリプトに引数として渡されているす
              べてのフック引数に影響します。特に、コンテナ名のセクション (例:  'lxc',  'net')  と
              フックタイプ (例: 'clone', 'mount', 'pre-mount') 引数に影響します。新しいスタイルの
              フックが使われる場合、引数は環境変数として利用できます。 コンテナ名は LXC_NAME に設
              定されます(これはこの設定項目に設定されている値とは関係なく設定されます)。セクショ
              ンは LXC_HOOK_SECTION に設定されます。そしてフックタイプは LXC_HOOK_TYPE に設定され
              ます。 この設定は、コンテナの名前空間を参照するファイルディスクリプタのパスをどのよ
              うに渡すかにも影響します。1              に設定した場合、名前空間ごとに別の環境変数
              LXC_[NAMESPACE  IDENTIFIER]_NS に設定されます。0 に設定すると、パスは stop フックの
              引数として渡されます。

       lxc.hook.pre-start
              コンテナの  tty、コンソールの作成、マウントが実行される前に、ホストの名前空間内で実
              行するフック。

       lxc.hook.pre-mount
              コンテナのファイルシステムの名前空間で実行されますが、rootfs が設定される前に実行す
              るフック。 これにより rootfs の操作が可能になります。  例えば、暗号化されたファイル
              システムのマウントなどです。 このフック内でなされるマウントはホストには影響しません
              (mounts propagation を除いて)。  なので、それらはコンテナがシャットダウンする時に自
              動的にクリーンアップされます。

       lxc.hook.mount
              マウントが完了した後ですが、pivot_root の前にコンテナの名前空間で実行されるフック。

       lxc.hook.autodev
              lxc.autodev == 1 が設定されている場合で、マウントが完了し、マウント時のフックも実行
              された後ですが、pivot_root の前にコンテナの名前空間で実行するフック。  このフックの
              目的は、systemd ベースのコンテナ向けの autodev オプションが設定されている時に、コン
              テナの /dev ディレクトリを設定するのを支援することです。コンテナの /dev  ディレクト
              リは、このフックが実行される時有効な ${LXC_ROOTFS_MOUNT} 環境変数からの相対パスとな
              ります。

       lxc.hook.start-host
              コンテナのセットアップが済んだあと、コンテナの init  を実行する直前に、ホストの名前
              空間で実行するためのフックです。

       lxc.hook.start
              コンテナの init が実行される直前にコンテナの名前空間で実行されるフック。 コンテナ内
              で利用可能なプログラムである必要があります。

       lxc.hook.stop
              コンテナのシャットダウン後、コンテナの名前空間への参照とともに、ホストの名前空間で
              実行されるフックです。     それぞれの名前空間に対応する追加の引数がフックに渡されま
              す。その引数にはコロンで区切られた名前空間のタイプ名とファイル名が含まれてお
              り、ファイル名は名前空間に対するファイルディスクリプタを取得するのに使えます。 タイ
              プ名は /proc/PID/ns ディレクトリ内のファイル名です。 例えば、マウント名前空間に対応
              する引数は通常は mnt:/proc/PID/fd/12 のようになります。

       lxc.hook.post-stop
              コンテナがシャットダウンされた後にホストの名前空間で実行するフック。

       lxc.hook.clone
              コンテナが新しいコンテナにクローンされる際に実行されるフック。詳しくは lxc-clone(1)
              を参照してください。

       lxc.hook.destroy
              コンテナを破壊する際に実行されるフックです。

   コンテナのフックで使える環境変数
       起動時のフックに設定情報を提供し、フックの機能を助けるための環境変数がいくつか利用可能で
       す。 全ての変数が全てのコンテキストで利用可能なわけではありません。 具体的には、全てのパス
       はホストシステム上のパスであり、そのため、lxc.hook.start フックの時点では使用できません。

       LXC_NAME
              LXC コンテナの名前。共通のログ環境内でのログメッセージに使うときに便利です。[-n]

       LXC_CONFIG_FILE
              コンテナの設定ファイルのホスト上でのパス。 これは、他の方法では得られない追加の設定
              情報を見つけるために、コンテナに、元の、トップレベルの設定ファイルの位置を与えるも
              のです。 [-f]

       LXC_CONSOLE
              設定されている場合のコンテナのコンソール出力のパス。 [-c] [lxc.console.path]

       LXC_CONSOLE_LOGPATH
              設定されている場合のコンテナのコンソールログ出力のパス。 [-L]

       LXC_ROOTFS_MOUNT
              初期にコンテナがマウントされる場所。 これは、コンテナインスタンスが起動するためのコ
              ンテナの  rootfs へのホスト上のパスであり、インスタンスのための移行が行われる場所で
              す。 [lxc.rootfs.mount]

       LXC_ROOTFS_PATH
              rootfs.mount               へマウントされるコンテナのルートへのホスト上のパスです。
              [lxc.rootfs.path]

       LXC_SRC_NAME
              clone フックの場合のみ使われます。クローン元のコンテナ名が設定されます。

       LXC_TARGET
              stop  フックの場合のみ使われます。コンテナのシャットダウンの場合は "stop"、リブート
              の場合は "reboot" が設定されます。

       LXC_CGNS_AWARE
              この変数が設定されていない場合、お使いのバージョンの LXC は cgroup 名前空間を扱えま
              せん。設定されている場合、この値は  1 に設定されています。そして、cgroup 名前空間を
              扱えます。 この変数はカーネルで cgroup 名前空間が有効であることは保証しません。この
              変数は lxcfs のマウントフックが使います。

   ロギング
       ロギングはコンテナごとに設定することが可能です。  デフォルトでは、lxc パッケージのコンパイ
       ル条件に依存し、コンテナのスタートアップは ERROR  レベルでのみロギングされ、コンテナのパス
       以下か、/var/log/lxc  以下のどちらかにコンテナ名 (の後に '.log' が付与される) をもとにした
       名前でロギングされます。

       デフォルトのログレベルとログファイルは両方とも、コンテナの設定ファイル内で指定され、デフォ
       ルトの値を上書きします。  同様に、設定ファイルのエントリは  lxc-start のコマンドラインオプ
       ションで上書きすることも可能です。

       lxc.log.level
              ログを取得するレベル。 ログレベルは 0..8 の範囲の整数です。  数字が小さいほど冗長な
              デバッグを意味します。  具体的には、0 = trace, 1 = debug, 2 = info, 3 = notice, 4 =
              warn, 5 = error, 6 = critical, 7 = alert, and 8 = fatal です。 指定されない場合、レ
              ベルのデフォルトは 5 (error) で、それ以上のエラーがロギングされます。

              (フックスクリプトやネットワークインターフェースの起動、停止時のスクリプトのような)
              スクリプトが呼ばれた時、スクリプトの標準出力は level 1  の  debug  でロギングされま
              す。

       lxc.log.file
              ログ情報を書き込むファイル。

       lxc.log.syslog
              ログ情報を syslog に送ります。ログレベルとして lxc.log.level の値を使用します。指定
              する値は使用する  syslog  の  facility  です。有効な値は  daemon,  local0,  local1,
              local2, local3, local4, local5, local5, local6, local7 のいずれかです。

   自動起動
       自動起動オプションでは、自動起動させるコンテナと順番の設定が可能です。    このオプションは
       LXC ツールが直接使用するか、ディストリビューションが提供する外部ツールが使用するかもしれま
       せん。

       lxc.start.auto
              コンテナを自動起動させるかどうかを設定します。 有効な値は 0(オフ) か 1(オン) です。

       lxc.start.delay
              コンテナを起動させた後、次のコンテナを起動させるまでにどれくらい  (秒) 待つかを設定
              します。

       lxc.start.order
              多数の自動起動させるコンテナがある場合のコンテナの起動順を決めるのに使う整数を指定
              します。

       lxc.monitor.unshare
              この値が 0 でない場合、コンテナが初期化される前 (pre-start フックが実行される前) に
              マウント名前空間がホストから   unshare   されます。この機能を使う場合、スタート時に
              CAP_SYS_ADMIN ケーパビリティが必要です。デフォルト値は 0 です。

       lxc.group
              コンテナを追加したいコンテナグループ名を指定します。 複数の値を設定でき、複数回指定
              することもできます。 設定されたグループは、関連する一連のコンテナを起動させるために
              使われます。

   自動起動とシステムブート
       コンテナはいくつでもグループに属することができ、全く属さないことも可能です。特別なグループ
       が  2  つ存在します。1  つは  NULL  グループです。これはどのグループにも属さないコンテナで
       す。もう 1 つは "onboot" グループです。

       LXC サービスが有効になった状態でシステムがブートすると、最初に "onboot" グループのメンバー
       である    lxc.start.auto     ==     1     が設定されたコンテナを起動しようとします。起動は
       lxc.start.order  の順に起動します。 lxc.start.delay が指定されている場合、現在対象となって
       いるコンテナに初期化の時間を与え、ホストシステムの負荷を低減するために、次のコンテナを開始
       させるまでに遅延時間を与えます。  "onboot"  グループのメンバーが開始した後、LXC システムは
       lxc.start.auto == 1 が設定された、どのグループのメンバーでもない (NULL グループの)  コンテ
       ナのブートを onboot グループのコンテナと同様に開始します。

   コンテナの環境変数
       コンテナに環境変数を渡したい場合   (環境変数はコンテナの  init  とその子孫全てで利用可能で
       す)、lxc.environment パラメータがその用途に使えます。 機微 (センシティブ) な情報を渡さない
       ように注意が必要です。そのような情報を持たないコンテナ内のプロセスでこれらの環境変数が利用
       可能になってしまいます。環境変数は常に /proc/PID/environ 経由で利用可能になります。

       この設定項目は、設定したい環境変数ごとに 1 度ずつ、何度でも指定できます。

       lxc.environment
              コンテナに渡したい環境変数を指定します。 例:

                            lxc.environment = APP_ENV=production
                            lxc.environment = SYSLOG_SERVER=192.0.2.42

       以下に紹介するいくつかの例に加えて、他の設定例が /usr/share/doc/lxc/examples にあります。

   ネットワーク
       この設定は、片方をブリッジである br0 と接続される veth  ペアデバイスを使うコンテナを設定し
       ます (ブリッジは管理者によりあらかじめシステム上に設定済みである必要があります)。 仮想ネッ
       トワークデバイスは、コンテナ内では eth0 とリネームされます。

               lxc.uts.name = myhostname
               lxc.net.0.type = veth
               lxc.net.0.flags = up
               lxc.net.0.link = br0
               lxc.net.0.name = eth0
               lxc.net.0.hwaddr = 4a:49:43:49:79:bf
               lxc.net.0.ipv4.address = 1.2.3.5/24 1.2.3.255
               lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597

   UID/GID のマッピング
       この設定は、コンテナ内のユーザとグループ両方の     id     0-9999      の範囲を、ホスト上の
       100000-109999 へマッピングします。

               lxc.idmap = u 0 100000 10000
               lxc.idmap = g 0 100000 10000

   CONTROL GROUP
       この設定は、アプリケーションのための control group をいくつか設定します。 cpuset.cpus は定
       義された cpu のみ使用できるように制限します。 cpus.share は、control group の (cpu) 優先度
       を指定します。 devices.allow は、特定のデバイスを使用可能にします。

               lxc.cgroup.cpuset.cpus = 0,1
               lxc.cgroup.cpu.shares = 1234
               lxc.cgroup.devices.deny = a
               lxc.cgroup.devices.allow = c 1:3 rw
               lxc.cgroup.devices.allow = b 8:0 rw

   複雑な設定
       この例は、control group を使って、複雑なネットワークスタックを作成し、新しいホスト名を指定
       し、いくつかの場所をマウントし、ルートファイルシステムを変更するような複雑な設定を示しま
       す。

               lxc.uts.name = complex
               lxc.net.0.type = veth
               lxc.net.0.flags = up
               lxc.net.0.link = br0
               lxc.net.0.hwaddr = 4a:49:43:49:79:bf
               lxc.net.0.ipv4.address = 10.2.3.5/24 10.2.3.255
               lxc.net.0.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3597
               lxc.net.0.ipv6.address = 2003:db8:1:0:214:5432:feab:3588
               lxc.net.1.type = macvlan
               lxc.net.1.flags = up
               lxc.net.1.link = eth0
               lxc.net.1.hwaddr = 4a:49:43:49:79:bd
               lxc.net.1.ipv4.address = 10.2.3.4/24
               lxc.net.1.ipv4.address = 192.168.10.125/24
               lxc.net.1.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596
               lxc.net.2.type = phys
               lxc.net.2.flags = up
               lxc.net.2.link = dummy0
               lxc.net.2.hwaddr = 4a:49:43:49:79:ff
               lxc.net.2.ipv4.address = 10.2.3.6/24
               lxc.net.2.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297
               lxc.cgroup.cpuset.cpus = 0,1
               lxc.cgroup.cpu.shares = 1234
               lxc.cgroup.devices.deny = a
               lxc.cgroup.devices.allow = c 1:3 rw
               lxc.cgroup.devices.allow = b 8:0 rw
               lxc.mount.fstab = /etc/fstab.complex
               lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0
               lxc.rootfs.path = dir:/mnt/rootfs.complex
               lxc.cap.drop = sys_module mknod setuid net_raw
               lxc.cap.drop = mac_override

SEE ALSO

       chroot(1), pivot_root(8), fstab(5) capabilities(7)

SEE ALSO

       lxc(7),   lxc-create(1),  lxc-copy(1),  lxc-destroy(1),  lxc-start(1),  lxc-stop(1),  lxc-
       execute(1), lxc-console(1), lxc-monitor(1), lxc-wait(1),  lxc-cgroup(1),  lxc-ls(1),  lxc-
       info(1), lxc-freeze(1), lxc-unfreeze(1), lxc-attach(1), lxc.conf(5)

作者

       Daniel Lezcano <daniel.lezcano@free.fr>

                                            2023-05-05                      lxc.container.conf(5)