'\" -*- coding: UTF-8 -*- .if \n(.g .ds T< \\FC .if \n(.g .ds T> \\F[\n[.fam]] .de URL \\$2 \(la\\$1\(ra\\$3 .. .if \n(.g .mso www.tmac .TH lxc.container.conf 5 2017-03-15 "" "" .SH NAME lxc.container.conf \- LXC コンテナ設定ファイル .SH 説明 linux コンテナ (\fBlxc\fR) は、常に使用する前に作成されます。 コンテナは、プロセスがコンテナを使う時に仮想化/隔離するシステムリソースのセットを定義することによって作成します。 デフォルトでは、pid, sysv ipc, マウントポイントが仮想化され、隔離されます。 他のシステムリソースは、設定ファイルで明確に定義されない限りは、コンテナをまたいで共有されます。 例えば、もしネットワークが設定されていなければ、コンテナを作成する側とコンテナでネットワークを共有します。 しかし、ネットワークが指定されれば、新しいネットワークスタックがコンテナ用に作成され、コンテナは作成元の環境のネットワークを使いません。 .PP 設定ファイルは、コンテナに割り当てられる様々なシステムリソースを定義します。 現時点では、utsname、ネットワーク、マウントポイント、root ファイルシステム、ユーザ名前空間、control groups がサポートされます。 .PP 設定ファイルのオプション一つを、\fBkey = value\fR の形で一行で表します。 \&'#' は、その行はコメントであることを示します。 ケーパビリティや cgroup のオプションのような、リスト形式で指定するオプションでは、value がない形式で指定できます。このように使うと、それ以前に定義した値をすべてクリアします。 .SS 設定 複数の関係するコンテナの管理を容易にするために、コンテナの設定ファイルに別のファイルをロードすることが可能です。 例えば、ネットワークの設定を、複数のコンテナから include させるように 1 つのファイルに定義することが可能です。 その場合、コンテナが他のホストに移動すると、そのファイルだけを更新する必要があるかもしれません。 .TP \*(T<\fBlxc.include\fR\*(T> include させたいファイルを指定します。 include するファイルは、lxc 設定ファイルのフォーマットとして有効でなければいけません。 .SS アーキテクチャ コンテナに対してアーキテクチャを設定することが可能です。 例えば、64 ビットのホスト上で 32 ビットのバイナリを動かすために 32 ビットアーキテクチャを設定することが可能です。 この設定を行うことにより、パッケージのダウンロードを行うなどの作業のうち、アーキテクチャ名に依存するような作業を行うコンテナスクリプトの修正を行います。 .TP \*(T<\fBlxc.arch\fR\*(T> コンテナに設定するアーキテクチャを指定します。 有効なオプションは以下です。 \*(T<\fBx86\fR\*(T>, \*(T<\fBi686\fR\*(T>, \*(T<\fBx86_64\fR\*(T>, \*(T<\fBamd64\fR\*(T> .SS ホスト名 utsname セクションは、コンテナに設定されるホスト名を定義します。 コンテナは、システムのホスト名を変えることなく、自身のホスト名を持つ事が可能です。 このことにより、ホスト名はコンテナ専用となります。 .TP \*(T<\fBlxc.utsname\fR\*(T> コンテナのホスト名を指定します。 .SS クリーンなシャットダウン時のシグナル lxc-stop がコンテナをクリーンにシャットダウンするためにコンテナの init プロセスに送るシグナル名か番号を指定できます。 init システムによって、クリーンなシャットダウンを行うために使うシグナルは異なります。 このオプションではシグナルとして kill(1) で使う形式を指定することができます。 例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10 のような形式、もしくは数字を指定します。デフォルトのシグナルは SIGPWR です。 .TP \*(T<\fBlxc.haltsignal\fR\*(T> コンテナをシャットダウンするために使うシグナルを指定します。 .SS リブート時のシグナル lxc-stop がコンテナをリブートするために送るシグナル名か番号を指定できます。 このオプションではシグナルとして kill(1) で使う形式を指定することができます。 例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10 のような形式、もしくは数字を指定します。デフォルトのシグナルは SIGINT です。 .TP \*(T<\fBlxc.rebootsignal\fR\*(T> コンテナをリブートするために使うシグナルを指定します。 .SS 強制停止時のシグナル lxc-stop がコンテナを強制的にシャットダウンするために送るシグナル名か番号を指定することができます。 このオプションではシグナルとして kill(1) で使う形式を指定することができます。 例えば SIGKILL, SIGRTMIN+14, SIGRTMAX-10 のような形式、もしくは数字を指定します。デフォルトのシグナルは SIGKILL です。 .TP \*(T<\fBlxc.stopsignal\fR\*(T> コンテナを停止するのに使用するシグナルを指定します。 .SS "INIT コマンド" コンテナの init として使うコマンドを設定します。 このオプションは lxc-execute では無視されます。 デフォルトは /sbin/init です。 .TP \*(T<\fBlxc.init_cmd\fR\*(T> init として使うバイナリの、コンテナの rootfs からの絶対パスを指定します。 .SS "INIT が使う ID" lxc-execute が実行するコンテナの init と、その後に起動するコマンドが使用する UID/GID を設定します。 このオプションは lxc-execute がユーザ名前空間内で起動するときのみ使われます。 デフォルト値は UID(0), GID(0) です。 .TP \*(T<\fBlxc.init_uid\fR\*(T> ユーザ名前空間内で init が使う UID です。 .TP \*(T<\fBlxc.init_gid\fR\*(T> ユーザ名前空間内で init が使う GID です。 .SS 一時的なコンテナ シャットダウン後にコンテナを削除するかどうかを指定できます。 .TP \*(T<\fBlxc.ephemeral\fR\*(T> 指定できる値は 0 または 1 のみです。この値を 1 に設定すると、シャットダウン後にコンテナを削除します。 .SS ネットワーク ネットワークセクションは、コンテナ内でどのようにネットワークを仮想化するかを定義します。 ネットワークの仮想化はレイヤー 2 で作動します。 ネットワークの仮想化を使用するためには、コンテナのネットワークインターフェースを定義しなければなりません。 いくつかの仮想インターフェースをアサインすることができます。 そして、仮に物理ネットワークインターフェースが一つしかなくても、コンテナ内でいくつもの仮想インターフェースを使うことができます。 .TP \*(T<\fBlxc.network\fR\*(T> 値を指定せずに使い、それ以前に定義されたすべてのネットワークオプションをクリアできます。 .TP \*(T<\fBlxc.network.type\fR\*(T> コンテナがどの種類のネットワーク仮想化を使うかを指定します。 一つのネットワークの設定ごとに \*(T<\fBlxc.network.type\fR\*(T> フィールドを指定します。 このように、一つのコンテナに複数のネットワークインターフェースを割り当てることができるだけでなく、同じコンテナに対して複数のネットワーク仮想化の種類を指定することが出来ます。 仮想化の種類は以下の値を取る事が出来ます: \*(T<\fBnone:\fR\*(T> ホストのネットワーク名前空間を共有します。 これにより、ホストのネットワークデバイスをコンテナ内で使うことが可能になります。 もしコンテナもホストも init として upstart を使っている場合、(例えば) コンテナ内で 'halt' を実行すると、ホストがシャットダウンしてしまうことにもなります。 \*(T<\fBempty:\fR\*(T> ループバックインターフェースだけを作成します。 \*(T<\fBveth:\fR\*(T> 一方がコンテナに、もう一方が \*(T<\fBlxc.network.link\fR\*(T> オプションで指定されたブリッジに接続されるペアの仮想イーサネットデバイスを作成します。 もし、ブリッジが指定されていない場合、veth ペアデバイスは作成されますが、ブリッジには接続されません。 ブリッジはコンテナが開始する前にシステムで事前に設定しておく必要があります。 \fBlxc\fR はコンテナ外の設定を扱うことはありません。 デフォルトでは、\fBlxc\fR がコンテナの外部に属するネットワークデバイスに対する名前を決定します。 しかし、もしこの名前を自分で指定したい場合、\*(T<\fBlxc.network.veth.pair\fR\*(T> オプションを使って名前を設定し、lxc に対して指定をすることができます (非特権コンテナの場合をのぞきます。セキュリティ上の理由からこのオプションは無視されます)。 \*(T<\fBvlan:\fR\*(T> vlan インターフェースは \*(T<\fBlxc.network.link\fR\*(T> で指定されたインターフェースとリンクし、コンテナに割り当てられます。 vlan の指定は \*(T<\fBlxc.network.vlan.id\fR\*(T> オプションで指定します。 \*(T<\fBmacvlan:\fR\*(T> macvlan インターフェースは \*(T<\fBlxc.network.link\fR\*(T> により指定されるインターフェースとリンクし、コンテナに割り当てられます。 \*(T<\fBlxc.network.macvlan.mode\fR\*(T> でモードを指定すると、その macvlan の指定を、同じ上位デバイスで異なる macvlan の間の通信をする時に使います。 指定できるモードは \*(T<\fBprivate\fR\*(T>、\*(T<\fBvepa\fR\*(T>、\*(T<\fBbridge\fR\*(T>、\*(T<\fBpassthru\fR\*(T> のいずれかです。 \*(T<\fBprivate\fR\*(T> モードの場合、デバイスは同じ上位デバイスの他のデバイスとの通信を行いません (デフォルト)。 新しい仮想イーサネットポート集約モード (Virtual Ethernet Port Aggregator (VEPA)) である \*(T<\fBvepa\fR\*(T> モードの場合、隣接したポートが、ソースとデスティネーションの両方が macvlan ポートに対してローカルであるフレームを全て返すと仮定します。 すなわち、ブリッジが reflective relay として設定されているということです。 上位デバイスから入ってくるブロードキャストフレームは、VEPA モードである全ての macvlan インターフェースに送りつけられます。 ローカルのフレームはローカルには配送されません。 \*(T<\fBbridge\fR\*(T> モードの場合、同じポートの異なる macvlan インターフェースの間のシンプルなブリッジとして動作します。 あるインターフェースから他のインターフェースへのフレームは、直接配送され、外部には送出されません。 ブロードキャストフレームは、全ての他のブリッジと外部のインターフェースに対して送られます。 しかし、reflective relay からフレームが返ってきたときは、再度それを配送することはしません。 全ての MAC アドレスを知っているので、ブリッジモジュールのように、macvlan ブリッジモードは学習や STP の必要はありません。 \*(T<\fBpassthru\fR\*(T> モードの場合、物理インターフェースで受け取った全てのフレームは macvlan インターフェースに転送されます。\*(T<\fBpassthru\fR\*(T> モードの場合、ひとつの macvlan インターフェースだけが、ひとつの物理インターフェースに対して設定できます。 \*(T<\fBphys:\fR\*(T> \*(T<\fBlxc.network.link\fR\*(T> で指定された、すでに存在しているインターフェースがコンテナに割り当てられます。 .TP \*(T<\fBlxc.network.flags\fR\*(T> ネットワークに対して行うアクションを指定します。 \*(T<\fBup:\fR\*(T> インターフェースを起動させます。 .TP \*(T<\fBlxc.network.link\fR\*(T> 実際のネットワークトラフィックに使うインターフェースを指定します。 .TP \*(T<\fBlxc.network.mtu\fR\*(T> インターフェースに対する MTU を指定します。 .TP \*(T<\fBlxc.network.name\fR\*(T> インターフェース名は動的に割り当てられます。 しかし、もしコンテナが使用する設定ファイルが一般的な名前を使用するために、他の特定の名前が必要であれば (例えば eth0 など)、コンテナ内のインターフェースは、このオプションで指定した名前にリネームされます。 .TP \*(T<\fBlxc.network.hwaddr\fR\*(T> 仮想インターフェースの MAC アドレスは、デフォルトでは動的に割り当てられます。 しかし、MAC アドレスの衝突や、リンクローカルIPv6 アドレスを常に同じにした場合などは、このオプションが必要です。 アドレス中の "x" という文字は、ランダムな値に置き換えられます。 これによりテンプレートに hwaddr を設定することが可能になります。 .TP \*(T<\fBlxc.network.ipv4\fR\*(T> 仮想インターフェースに割り当てる ipv4 アドレスを指定します。 複数行により複数の ipv4 アドレスを指定します。 このアドレスは x.y.z.t/m というフォーマットで指定します。 例えば、192.168.1.123/24。ブロードキャストアドレスも同じ行の ipv4 アドレスのすぐ後で指定しなくてはなりません。 .TP \*(T<\fBlxc.network.ipv4.gateway\fR\*(T> コンテナでゲートウェイとして使う IPv4 アドレスを指定します。 アドレスは x.y.z.t というフォーマットです。 例えば、192.168.1.123。 \*(T<\fBauto\fR\*(T> という特別な値を記述する事も可能です。 これは (\*(T<\fBlxc.network.link\fR\*(T> で指定した) ブリッジインターフェースの最初のアドレスを使用し、それをゲートウェイに使うという意味になります。 \*(T<\fBauto\fR\*(T> はネットワークタイプとして \*(T<\fBveth\fR\*(T> と \*(T<\fBmacvlan\fR\*(T> を指定している時だけ有効となります。 .TP \*(T<\fBlxc.network.ipv6\fR\*(T> 仮想インターフェースに割り当てる ipv6 アドレスを指定します。 複数行により複数の ipv6 アドレスを指定します。 このアドレスは x::y/m というフォーマットで指定します。 例えば、2003:db8:1:0:214:1234:fe0b:3596/64。 .TP \*(T<\fBlxc.network.ipv6.gateway\fR\*(T> コンテナでゲートウェイとして使う IPv6 アドレスを指定します。 アドレスは x::y というフォーマットです。例えば、2003:db8:1:0::1。 \*(T<\fBauto\fR\*(T> という特別な値を記述する事も可能です。 これは (\*(T<\fBlxc.network.link\fR\*(T> で指定した) ブリッジインターフェースの最初のアドレスを使用し、それをゲートウェイに使うという意味になります。 \*(T<\fBauto\fR\*(T> はネットワークタイプとして \*(T<\fBveth\fR\*(T> と \*(T<\fBmacvlan\fR\*(T> を指定している時だけ有効となります。 .TP \*(T<\fBlxc.network.script.up\fR\*(T> ホスト側から使われる、ネットワークの作成と設定が済んだ後に実行するスクリプトを指定します。 以下の引数がスクリプトに渡されます: コンテナ名、設定セクション名(net)。 その後の引数はスクリプトのフックで使われる設定セクションに依存します。 以下がネットワークシステムによって使われます: 実行コンテキスト (up)、ネットワークのタイプ (empty/veth/macvlan/phys) ネットワークのタイプによっては、更に別の引数が渡されるかもしれません: veth/macvlan/phys の場合 (ホスト側の) デバイス名 スクリプトからの標準出力は debug レベルでロギングされます。 標準エラー出力はロギングされません。 しかし、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可能です。 .TP \*(T<\fBlxc.network.script.down\fR\*(T> ホスト側から使われる、ネットワークを破壊する前に実行するスクリプトを指定します。 以下の引数がスクリプトに渡されます: コンテナ名、設定セクション名(net)。 その後の引数はスクリプトのフックで使われる設定セクションに依存します。 以下がネットワークシステムによって使われます: 実行コンテキスト (up)、ネットワークのタイプ (empty/veth/macvlan/phys)。 ネットワークのタイプによっては、更に別の引数が渡されるかもしれません: veth/macvlan/phys。そして最後に (ホスト側の) デバイス名が渡されます。 スクリプトからの標準出力は debug レベルでロギングされます。 標準エラー出力はロギングされません。 しかし、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可能です。 .SS "新しい擬似端末のインスタンス (DEVPTS)" さらに厳しい隔離のために、コンテナは自身のプライベートな pseudo tty (擬似端末) を持つことが可能です。 .TP \*(T<\fBlxc.pts\fR\*(T> もし設定された場合、コンテナは新しい pseudo tty インスタンスを持ち、それを自身のプライベートとします。 この値は pts インスタンスに許可される pseudo tty の最大数を指定します (この制限はまだ実装されていません)。 .SS コンテナのシステムコンソール コンテナでルートファイルシステムを持つように設定されており、inittab ファイルでコンソールの使用が設定されている場合、このコンソールの出力がどこになされるのかを指定したいと思うでしょう。 .TP \*(T<\fBlxc.console.logfile\fR\*(T> コンソール出力を書き込むファイルのパスを指定します。 .TP \*(T<\fBlxc.console\fR\*(T> コンソールを割り当てるデバイスのパスを指定します。'none' というキーワードは、単純にコンソールを無効にします。 この設定は、アプリケーションが書き込む事ができるコンソールデバイスファイルが rootfs に存在する場合、メッセージがホスト側に出力されるので危険です。 .SS "TTY を通したコンソール" このオプションはコンテナが root ファイルシステムを持つように設定されており、inittab ファイルで tty 上に getty の起動が設定されている場合に役に立ちます。 このオプションはコンテナで利用できる tty の数を指定します。 inittab ファイルに設定する getty の数は、このオプションの指定する tty の数より大きくしてはいけません。 さもなければ、超過した分の getty セッションはコンソールか /var/log/messages にうっとうしいメッセージを生死を表示しながら、永久に生死を繰り返すでしょう。 .TP \*(T<\fBlxc.tty\fR\*(T> コンテナに作成出来る tty の数を指定します。 .SS コンソールデバイスの位置 LXC のコンソールはホストによって作られ、コンテナ内で要求されたデバイスに bind マウントされた Unix98 PTY 経由で提供されます。 デフォルトでは \*(T<\fI/dev/console\fR\*(T> と \*(T<\fI/dev/ttyN\fR\*(T> に bind マウントされます。 これはゲスト内でのパッケージのアップグレードを妨げる可能性があります。 なので \*(T<\fI/dev\fR\*(T> 以下のディレクトリを指定することができます。 LXC はこのディレクトリ以下にファイルを作成し、これらのファイルを bind マウントします。 そして、これらの (作成された) ファイルは \*(T<\fI/dev/console\fR\*(T> と \*(T<\fI/dev/ttyN\fR\*(T> にシンボリックリンクされます。 シンボリックリンクを消去したり置き換えたりすることは可能ですから、パッケージのアップグレードは成功します。 .TP \*(T<\fBlxc.devttydir\fR\*(T> コンテナのコンソールデバイスを作成するための \*(T<\fI/dev\fR\*(T> 以下のディレクトリを指定します。 .SS "/DEV ディレクトリ" デフォルトでは、lxc はコンテナの \*(T<\fI/dev\fR\*(T> 以下に fd, stdin, stdout, stderr のシンボリックリンクを作成しますが、自動的にはデバイスノードのエントリは作成しません。 これは、コンテナの rootfs で必要な設定を行えるようにするものです。 lxc.autodev が 1 に設定されている場合、コンテナの rootfs をマウントした後、LXC は新しい tmpfs を \*(T<\fI/dev\fR\*(T> 以下にマウントします (500k 制限の)。 そして初期デバイスの最小限のセットを作成します。 これは、"systemd" ベースの "init" 環境のコンテナを起動する時に通常必要ですが、他の環境の場合はオプショナルなものです。 コンテナの /dev ディレクトリ内の追加デバイスは \*(T<\fBlxc.hook.autodev\fR\*(T> フックを使用して作成されます。 .TP \*(T<\fBlxc.autodev\fR\*(T> コンテナの起動時に LXC が /dev をマウントして最小限の /dev を作成するのを止めるには、この値を 0 に設定してください。 .SS "KMSG のシンボリックリンクの有効化" /dev/console へのシンボリックリンクとして /dev/kmsg を作成することを有効にします。デフォルトは 0 です。 .TP \*(T<\fBlxc.kmsg\fR\*(T> /dev/kmsg へのシンボリックリンクを有効にするには 1 を設定してください。 .SS マウントポイント マウントポイントセクションは、マウントするための区別された場所を指定します。 これらのマウントポイントは、コンテナだけに見え、コンテナ外で実行されるプロセスから見えることはありません。 例えば、/etc や /var や /home をマウントするときに役に立つでしょう。 .PP 注意: 通常 LXC は、マウント対象と相対パス指定のバインドマウントを、適切にコンテナルート以下に閉じ込めます。 これは、ホストのディレクトリやファイルに対して重ね合わせを行うようなマウントによる攻撃を防ぎます。(絶対パス指定のマウントソース中の各パスがシンボリックリンクである場合は無視されます。) しかし、もしコンテナの設定が最初に、/home/joe のようなコンテナユーザのコントロール配下にあるディレクトリを、コンテナ中のある \*(T<\fIpath\fR\*(T> にマウントし、その後 \*(T<\fIpath\fR\*(T> 以下でマウントが行われるような場合、コンテナユーザがタイミングを見計らって自身のホームディレクトリ以下でシンボリックリンクを操作するような TOCTTOU 攻撃が成立する可能性があります。 .TP \*(T<\fBlxc.mount\fR\*(T> マウント情報の書かれた \*(T<\fIfstab\fR\*(T> フォーマットで書かれたファイルの場所を指定します。 マウントする場所は相対バスで書くことができます。そして、ほとんどの場合にコンテナの root からの相対パスとなるはずです。例えば、以下のように書きます。 .nf \*(T< proc proc proc nodev,noexec,nosuid 0 0 \*(T>.fi この例は、root ファイルシステムがどこにあっても、コンテナの /proc 以下に proc ファイルシステムをマウントします。 これは、ブロックデバイスがバックエンドのファイルシステムだけでなく、コンテナのクローンにも柔軟に対応できます。 ファイルシステムがイメージファイルやブロックデバイスからマウントされている場合、3 つ目のフィールド (fs_vfstype) は \fBmount\fR(8) のように auto を指定することはできず、明確に指定しなければいけません。 .TP \*(T<\fBlxc.mount.entry\fR\*(T> fstab フォーマットの一行と同じフォーマットのマウントポイントの指定をします。 fstab フォーマットに加えて、LXC ではマウントに対して独自の 2 つのオプションが使えます。 \*(T<\fBoptional\fR\*(T> は、マウントが失敗しても失敗を返さずに無視します。 \*(T<\fBcreate=dir\fR\*(T> と \*(T<\fBcreate=file\fR\*(T> は、マウントポイントをマウントする際にディレクトリもしくはファイルを作成します。 .TP \*(T<\fBlxc.mount.auto\fR\*(T> 標準のカーネルファイルシステムで自動的にマウントするものを指定します。 これは劇的に設定を容易にする可能性があります。 .RS .TP 0.2i • \*(T<\fBproc:mixed\fR\*(T> (or \*(T<\fBproc\fR\*(T>): \*(T<\fI/proc\fR\*(T> を読み書き可能でマウントします。 ただし、\*(T<\fI/proc/sys\fR\*(T> と \*(T<\fI/proc/sysrq\-trigger\fR\*(T> は、セキュリティとコンテナの隔離の目的でリードオンリーで再マウントされます。 .TP 0.2i • \*(T<\fBproc:rw\fR\*(T>: \*(T<\fI/proc\fR\*(T> を読み書き可能でマウントします。 .TP 0.2i • \*(T<\fBsys:mixed\fR\*(T> (or \*(T<\fBsys\fR\*(T>): /sys/devices/virtual/net のみ書き込み可能で、その他の \*(T<\fI/sys\fR\*(T> はリードオンリーでマウントします。 .TP 0.2i • \*(T<\fBsys:ro\fR\*(T>: \*(T<\fI/sys\fR\*(T> を、セキュリティとコンテナの隔離の目的でリードオンリーでマウントします。 .TP 0.2i • \*(T<\fBsys:rw\fR\*(T>: \*(T<\fI/sys\fR\*(T> を読み書き可能でマウントします。 .TP 0.2i • \*(T<\fBcgroup:mixed\fR\*(T>: \*(T<\fI/sys/fs/cgroup\fR\*(T> を tmpfs でマウントし、そのコンテナの追加が行われた全ての階層構造に対するディレクトリを作製し、その cgroup の名前でその中にサブディレクトリを作製し、そのコンテナ自身の cgroup をそのディレクトリにバインドマウントします。 コンテナは自身の cgroup ディレクトリに書き込みが可能ですが、親ディレクトリはリードオンリーで再マウントされているため書き込めません。 .TP 0.2i • \*(T<\fBcgroup:ro\fR\*(T>: \*(T<\fBcgroup:mixed\fR\*(T> と同様にマウントされますが、全てリードオンリーでマウントされます。 .TP 0.2i • \*(T<\fBcgroup:rw\fR\*(T>: \*(T<\fBcgroup:mixed\fR\*(T> と同様にマウントされますが、全て読み書き可能でマウントされます。 コンテナ自身の cgroup に至るまでのパスも書き込み可能になることに注意が必要ですが、cgroup ファイルシステムにはならず、 \*(T<\fI/sys/fs/cgroup\fR\*(T> の tmpfs の一部分になるでしょう。 .TP 0.2i • \*(T<\fBcgroup\fR\*(T> (マウントオプションなしの場合): コンテナが CAP_SYS_ADMIN ケーパビリティを保持している場合、\*(T<\fBcgroup:rw\fR\*(T> となります。保持していない場合、\*(T<\fBcgroup:mixed\fR\*(T> となります。 .TP 0.2i • \*(T<\fBcgroup\-full:mixed\fR\*(T>: \*(T<\fI/sys/fs/cgroup\fR\*(T> を tmpfs でマウントし、そのコンテナの追加が行われた全ての階層構造に対するディレクトリを作製し、ホストからコンテナまでの階層構造を全てバインドマウントし、コンテナ自身の cgroup を除いてリードオンリーにします。 \*(T<\fBcgroup\fR\*(T> と比べると、コンテナ自身の cgroup に至るまでの全てのパスが tmpfs の下層のシンプルなディレクトリとなり、コンテナ自身の cgroup の外ではリードオンリーになりますが、\*(T<\fI/sys/fs/cgroup/$hierarchy\fR\*(T> はホストの全ての cgroup 階層構造を含みます。 これにより、コンテナにはかなりの情報が漏洩します。 .TP 0.2i • \*(T<\fBcgroup\-full:ro\fR\*(T>: \*(T<\fBcgroup\-full:mixed\fR\*(T> と同様にマウントされますが、全てリードオンリーでマウントされます。 .TP 0.2i • \*(T<\fBcgroup\-full:rw\fR\*(T>: \*(T<\fBcgroup\-full:mixed\fR\*(T>と同様にマウントされますが、全て読み書き可能でマウントされます。 この場合、コンテナは自身の cgroup から脱出する可能性があることに注意してください (コンテナが CAP_SYS_ADMIN を持ち、自身で cgroup ファイルシステムをマウント可能なら、いずれにせよそのようにするかもしれないことにも注意してください)。 .TP 0.2i • \*(T<\fBcgroup\-full\fR\*(T> (マウントオプションなしの場合): コンテナが CAP_SYS_ADMIN ケーパビリティを保持している場合、\*(T<\fBcgroup\-full:rw\fR\*(T> となります。保持していない場合、\*(T<\fBcgroup\-full:mixed\fR\*(T> となります。 .RE cgroup 名前空間が有効の場合、\*(T<\fBcgroup\fR\*(T> の自動マウントの指定はどれも無視されます。これは、コンテナが自身でファイルシステムをマウントするため、自動マウントがコンテナの init を混乱させる可能性があるためです。 cgroup ファイルシステムの自動マウントが有効の場合、\*(T<\fI/sys/fs/cgroup\fR\*(T> 以下の tmpfs は常に読み書き可能でマウントされることに注意が必要です (しかし \*(T<\fB:mixed\fR\*(T> と \*(T<\fB:ro\fR\*(T> の場合は、個々の階層の \*(T<\fI/sys/fs/cgroup/$hierarchy\fR\*(T> は読み込み専用となるでしょう)。これは Ubuntu の \fBmountall\fR(8) コマンドの特異な動きに対処するためのものです。特異な動きとは、\*(T<\fI/sys/fs/cgroup\fR\*(T> が読み込み専用でマウントされた状態で、コンテナが CAP_SYS_ADMIN を持たない場合、/sys/fs/cgroup を読み書き可能で再マウントしようとしてできないため、コンテナのブート時にユーザからの入力を待ってしまうというものです。 例: .nf \*(T< lxc.mount.auto = proc sys cgroup lxc.mount.auto = proc:rw sys:rw cgroup\-full:rw \*(T> .fi .SS ルートファイルシステム コンテナのルートファイルシステムは、ホストのルートファイルシステムと異なるようにすることも可能です。 .TP \*(T<\fBlxc.rootfs\fR\*(T> コンテナのルートファイルシステムを指定します。 この値はイメージファイル、ディレクトリ、ブロックデバイスのどれかを取ることができます。 もし指定されない場合、コンテナはホストとルートファイルシステムを共有します。 ディレクトリ、単純なブロックデバイスのバックエンドを持つコンテナの場合、パス名を使うことができます。 もし rootfs が nbd デバイスの場合、\*(T<\fInbd:file:1\fR\*(T> という指定は \*(T<\fIfile\fR\*(T> を nbd デバイスとして使用し、その 1 番目のパーティションが rootfs としてマウントされます。 \*(T<\fInbd:file\fR\*(T> という指定は、nbd デバイス自身をマウントします。 \*(T<\fIoverlayfs:/lower:/upper\fR\*(T> という指定は、rootfs は \*(T<\fI/lower\fR\*(T> という読み込み専用でマウントされるディレクトリの上に、\*(T<\fI/upper\fR\*(T> というディレクトリを読み書き可能で重ね合わせてマウントします。 \*(T<\fIaufs:/lower:/upper\fR\*(T> は overlayfs で指定している部分を aufs と指定すれば同じことになります。\*(T<\fIoverlayfs\fR\*(T> と \*(T<\fIaufs\fR\*(T> は両方とも、複数の \*(T<\fI/lower\fR\*(T> ディレクトリを指定できます。 \*(T<\fIloop:/file\fR\*(T> は \*(T<\fI/file\fR\*(T> を loop デバイスとして使用し、loop デバイスをマウントします。 .TP \*(T<\fBlxc.rootfs.mount\fR\*(T> root ファイルシステムの変更の前に、\*(T<\fBlxc.rootfs\fR\*(T> を再帰的にどこにバインドするのかを指定します。これは \fBpivot_root\fR(8) システムコールが確実に成功する事を保証します。 どんなディレクトリでも良く、デフォルトでも通常は動くはずです。 .TP \*(T<\fBlxc.rootfs.options\fR\*(T> rootfs をマウントするときに追加したいマウントオプション。 .TP \*(T<\fBlxc.rootfs.backend\fR\*(T> 使用するバックエンドのタイプを、例えば 'dir' や 'zfs' のように指定します。 コンテナ起動時に LXC が推測できますが、時間がかかります。これを指定すると、余分な処理を避けられます。 .SS "CONTROL GROUP" CONTROL GROUP セクションは、(lxc とは) 別のサブシステムの設定を含みます。 \fBlxc\fR は、このサブシステム名の正しさはチェックしません。 実行時のエラーを検出するのに不便ですが、別の将来のサブシステムをサポート出来るという有利な点もあります。 .TP \*(T<\fBlxc.cgroup.[subsystem name]\fR\*(T> 設定する control group の値を指定します。 サブシステム名は、control group のそのままの名前です。 許される名前や値の書式は LXC が指示することはなく、コンテナが実行された時に実行されている Linux カーネルの機能に依存します。 例えば \*(T<\fBlxc.cgroup.cpuset.cpus\fR\*(T> .SS ケーパビリティ コンテナが root 権限で実行されていても、コンテナ内ではケーパビリティ (capabilities) を削除する事は可能です。 .TP \*(T<\fBlxc.cap.drop\fR\*(T> コンテナ内で削除するケーパビリティ (capability) を指定します。 一行でスペース区切りで複数のケーパビリティを指定することも可能です。 指定は、"CAP_" というプレフィックスなしで、小文字でケーパビリティを指定します。 例えば、CAP_SYS_MODULE というケーパビリティは sys_module と指定する必要があります。 詳しくは以下を参照してください。 \fBcapabilities\fR(7) この設定を、値を指定しない状態で使った場合、それ以前に指定された削除対象のケーパビリティの指定をすべてクリアします (lxc.cap.drop に何も指定しない状態になります)。 .TP \*(T<\fBlxc.cap.keep\fR\*(T> コンテナ内で維持するケーパビリティを指定します。指定した以外の全てのケーパビリティはドロップされます。 特別な値 "none" が指定されている時点で、lxc はこの時点で保持することになっている全てのケーパビリティをクリアします。"none" を単独で使用するとすべてのケーパビリティを削除できます。 .SS "APPARMOR プロファイル" lxc が apparmor サポートでコンパイルされ、インストールされている場合で、ホストで apparmor が有効な場合、コンテナが従って動くべき apparmor プロファイルは、コンテナの設定で指定することが可能です。 デフォルトは、ホストのカーネルで cgroup 名前空間が使える場合は \fBlxc-container-default-cgns\fRです。使えない場合は \fBlxc-container-default\fR です。 .TP \*(T<\fBlxc.aa_profile\fR\*(T> コンテナが従うべき apparmor プロファイルを指定します。 コンテナが apparmor による制限を受けないように設定するには、以下のように設定します。 .nf \*(T .fi もし apparmor プロファイルが変更されないままでなくてはならない場合 (ネストしたコンテナである場合や、すでに confined されている場合) は以下のように設定します。 .nf \*(T .fi .TP \*(T<\fBlxc.aa_allow_incomplete\fR\*(T> apparmor プロファイルはパス名ベースですので、多数のファイルの制限を行う際、執念深い攻撃者に対して効果的であるためにはマウントの制限が必要です。 しかし、これらのマウントの制限は upstream のカーネルではまだ実装されていません。マウントの制限なしでも、apparmor プロファイルによって予想外のダメージに対する保護が可能です。 このフラグが 0 の場合 (デフォルト)、カーネルが apparmor のマウント機能をサポートしていない場合にコンテナが起動しません。これはカーネルを更新した後に機能が退行したことが検出できるようにするためです。 不完全な apparmor の保護の下でコンテナを起動するためには、このフラグを 1 に設定してください。 .SS "SELINUX コンテキスト" lxc が SELinux サポートでコンパイルされ、インストールされている場合で、ホストで SELinux が有効な場合、コンテナが従って動くべき SELinux コンテキストは、コンテナの設定で指定することが可能です。 デフォルトは \fBunconfined_t\fR であり、これは lxc がコンテキストを変えないという意味になります。 ポリシーの例と追加の情報は /usr/share/lxc/selinux/lxc.te ファイルを参照してください。 .TP \*(T<\fBlxc.se_context\fR\*(T> コンテナが従うべき SELinux コンテキストを指定するか、\fBunconfined_t\fR を指定します。例えば以下のように設定します。 .nf \*(T .fi .SS "SECCOMP の設定" コンテナは、起動時に seccomp プロファイルをロードすることで、利用可能なシステムコールを減らして起動することが可能です。 seccomp の設定ファイルは、1 行目がバージョン番号、2 行目がポリシーのタイプで始まる必要があり、その後に設定を書きます。 .PP 現時点では、バージョン番号は 1 と 2 をサポートしています。バージョン 1 では、ポリシーはシンプルなホワイトリストですので、2 行目は "whitelist" でなければなりません。 そして残りの行には 1 行に 1 つずつ、システムコール番号を書きます。各行のシステムコール番号がホワイトリスト化され、リストにない番号は、そのコンテナではブラックリストに入ります。 .PP バージョン 2 では、ポリシーはブラックリストもしくはホワイトリストで表され、ルールごとのアクションと、ポリシーごとのデフォルトのアクションを設定できます。そして、アーキテクチャごとの設定と、テキストで書かれたシステムコール名での設定が可能です。 .PP 以下にブラックリストのポリシーの例を示します。これは mknod 以外の全てのシステムコールが許可され、mknod が呼ばれると、何もせずに単に 0(成功) を返します。 .PP .nf \*(T< 2 blacklist mknod errno 0 \*(T>.fi .TP \*(T<\fBlxc.seccomp\fR\*(T> コンテナがスタートする前にロードする seccomp の設定を含むファイルを指定します。 .SS "UID のマッピング" コンテナは、ユーザとグループの id のマッピングを持った専用のユーザ名前空間で起動することが可能です。 たとえば、コンテナ内のユーザ id 0 を、ホストのユーザ id 200000 にマッピングすることが可能です。 コンテナの root ユーザはコンテナ内では特権を持ちますが、ホストでは特権を持ちません。 通常は、システムコンテナは id の範囲を要求し、それをマッピングします。 例えば、コンテナ内のユーザとグループの id 0 から 20,000 を 200,000 から 220,000 にマッピングします。 .TP \*(T<\fBlxc.id_map\fR\*(T> 4 つの値を記述する必要があります。 最初の文字は 'u' か 'g' のどちらかで、ユーザかグループの ID のどちらをマッピングするかを指定します。 次はコンテナのユーザ名前空間内に現れる最初のユーザ ID です。 その次は、そのユーザ ID のホスト上での値です。 最後は、ID のマッピングをいくつ連続して行うかの数を指定します。 .SS コンテナのフック コンテナのフックは、コンテナの存続期間の色々な場面で実行することのできるプログラムやスクリプトです。 .PP コンテナのフックが実行されるとき、情報がコマンドライン引数と環境変数の両方を通して渡されます。引数は: .TP 0.2i • コンテナ名 .TP 0.2i • セクション (常に 'lxc') .TP 0.2i • フックのタイプ ('clone' や 'pre-mount' など) .TP 0.2i • 追加の引数。clone フックの場合、lxc-clone に渡される追加の引数は、フックへの引数として追加されます。stop フックの場合は、コンテナの名前空間のそれぞれに対するファイルディスクリプタへのパスが、名前空間名とともに渡されます。 .PP 以下の環境変数がセットされます。 .TP 0.2i • LXC_NAME: コンテナ名 .TP 0.2i • LXC_ROOTFS_MOUNT: マウントされた root ファイルシステムへのパス .TP 0.2i • LXC_CONFIG_FILE: コンテナの設定ファイルのパス .TP 0.2i • LXC_SRC_NAME: clone フックの場合、元のコンテナの名前 .TP 0.2i • LXC_ROOTFS_PATH: コンテナの lxc.rootfs エントリ。これはマウントされた rootfs が存在する場所にはならないでしょう。それには LXC_ROOTFS_MOUNT を使用してください。 .PP スクリプトからの標準出力は debug レベルでロギングされます。 標準エラー出力はロギングされません。 しかし、フックの標準エラー出力を標準出力にリダイレクトすることにより保存することは可能です。 .TP \*(T<\fBlxc.hook.pre\-start\fR\*(T> コンテナの tty、コンソールの作成、マウントが実行される前に、ホストの名前空間内で実行するフック。 .TP \*(T<\fBlxc.hook.pre\-mount\fR\*(T> コンテナのファイルシステムの名前空間で実行されますが、rootfs が設定される前に実行するフック。 これにより rootfs の操作が可能になります。 例えば、暗号化されたファイルシステムのマウントなどです。 このフック内でなされるマウントはホストには影響しません (mounts propagation を除いて)。 なので、それらはコンテナがシャットダウンする時に自動的にクリーンアップされます。 .TP \*(T<\fBlxc.hook.mount\fR\*(T> マウントが完了した後ですが、pivot_root の前にコンテナの名前空間で実行されるフック。 .TP \*(T<\fBlxc.hook.autodev\fR\*(T> \*(T<\fBlxc.autodev\fR\*(T> == 1 が設定されている場合で、マウントが完了し、マウント時のフックも実行された後ですが、pivot_root の前にコンテナの名前空間で実行するフック。 このフックの目的は、systemd ベースのコンテナ向けの autodev オプションが設定されている時に、コンテナの /dev ディレクトリを設定するのを支援することです。コンテナの /dev ディレクトリは、このフックが実行される時有効な ${\*(T<\fBLXC_ROOTFS_MOUNT\fR\*(T>} 環境変数からの相対パスとなります。 .TP \*(T<\fBlxc.hook.start\fR\*(T> コンテナの init が実行される直前にコンテナの名前空間で実行されるフック。 コンテナ内で利用可能なプログラムである必要があります。 .TP \*(T<\fBlxc.hook.stop\fR\*(T> コンテナのシャットダウン後、コンテナの名前空間への参照とともに、ホストの名前空間で実行されるフックです。 それぞれの名前空間に対応する追加の引数がフックに渡されます。その引数にはコロンで区切られた名前空間のタイプ名とファイル名が含まれており、ファイル名は名前空間に対するファイルディスクリプタを取得するのに使えます。 タイプ名は \*(T<\fI/proc/PID/ns\fR\*(T> ディレクトリ内のファイル名です。 例えば、マウント名前空間に対応する引数は通常は \*(T<\fImnt:/proc/PID/fd/12\fR\*(T> のようになります。 .TP \*(T<\fBlxc.hook.post\-stop\fR\*(T> コンテナがシャットダウンされた後にホストの名前空間で実行するフック。 .TP \*(T<\fBlxc.hook.clone\fR\*(T> コンテナが新しいコンテナにクローンされる際に実行されるフック。詳しくは \fBlxc-clone\fR(1) を参照してください。 .TP \*(T<\fBlxc.hook.destroy\fR\*(T> コンテナを破壊する際に実行されるフックです。 .SS コンテナのフックで使える環境変数 起動時のフックに設定情報を提供し、フックの機能を助けるための環境変数がいくつか利用可能です。 全ての変数が全てのコンテキストで利用可能なわけではありません。 具体的には、全てのパスはホストシステム上のパスであり、そのため、\*(T<\fBlxc.hook.start\fR\*(T> フックの時点では使用できません。 .TP \*(T<\fBLXC_NAME\fR\*(T> LXC コンテナの名前。共通のログ環境内でのログメッセージに使うときに便利です。[\*(T<\fB\-n\fR\*(T>] .TP \*(T<\fBLXC_CONFIG_FILE\fR\*(T> コンテナの設定ファイルのホスト上でのパス。 これは、他の方法では得られない追加の設定情報を見つけるために、コンテナに、元の、トップレベルの設定ファイルの位置を与えるものです。 [\*(T<\fB\-f\fR\*(T>] .TP \*(T<\fBLXC_CONSOLE\fR\*(T> 設定されている場合のコンテナのコンソール出力のパス。 [\*(T<\fB\-c\fR\*(T>] [\*(T<\fBlxc.console\fR\*(T>] .TP \*(T<\fBLXC_CONSOLE_LOGPATH\fR\*(T> 設定されている場合のコンテナのコンソールログ出力のパス。 [\*(T<\fB\-L\fR\*(T>] .TP \*(T<\fBLXC_ROOTFS_MOUNT\fR\*(T> 初期にコンテナがマウントされる場所。 これは、コンテナインスタンスが起動するためのコンテナの rootfs へのホスト上のパスであり、インスタンスのための移行が行われる場所です。 [\*(T<\fBlxc.rootfs.mount\fR\*(T>] .TP \*(T<\fBLXC_ROOTFS_PATH\fR\*(T> rootfs.mount へマウントされるコンテナのルートへのホスト上のパスです。 [\*(T<\fBlxc.rootfs\fR\*(T>] .TP \*(T<\fBLXC_SRC_NAME\fR\*(T> clone フックの場合のみ使われます。クローン元のコンテナ名が設定されます。 .TP \*(T<\fBLXC_TARGET\fR\*(T> stop フックの場合のみ使われます。コンテナのシャットダウンの場合は "stop"、リブートの場合は "reboot" が設定されます。 .TP \*(T<\fBLXC_CGNS_AWARE\fR\*(T> この変数が設定されていない場合、お使いのバージョンの LXC は cgroup 名前空間を扱えません。設定されている場合、この値は 1 に設定されています。そして、cgroup 名前空間を扱えます。 この変数はカーネルで cgroup 名前空間が有効であることは保証しません。この変数は lxcfs のマウントフックが使います。 .SS ロギング ロギングはコンテナごとに設定することが可能です。 デフォルトでは、lxc パッケージのコンパイル条件に依存し、コンテナのスタートアップは ERROR レベルでのみロギングされ、コンテナのパス以下か、/var/lib/lxc 以下のどちらかにコンテナ名 (の後に '.log' が付与される) をもとにした名前でロギングされます。 .PP デフォルトのログレベルとログファイルは両方とも、コンテナの設定ファイル内で指定され、デフォルトの値を上書きします。 同様に、設定ファイルのエントリは \fBlxc-start\fR のコマンドラインオプションで上書きすることも可能です。 .TP \*(T<\fBlxc.loglevel\fR\*(T> ログを取得するレベル。 ログレベルは 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 でロギングされます。 .TP \*(T<\fBlxc.logfile\fR\*(T> ログ情報を書き込むファイル。 .SS 自動起動 自動起動オプションでは、自動起動させるコンテナと順番の設定が可能です。 このオプションは LXC ツールが直接使用するか、ディストリビューションが提供する外部ツールが使用するかもしれません。 .TP \*(T<\fBlxc.start.auto\fR\*(T> コンテナを自動起動させるかどうかを設定します。 有効な値は 0(オフ) か 1(オン) です。 .TP \*(T<\fBlxc.start.delay\fR\*(T> コンテナを起動させた後、次のコンテナを起動させるまでにどれくらい (秒) 待つかを設定します。 .TP \*(T<\fBlxc.start.order\fR\*(T> 多数の自動起動させるコンテナがある場合のコンテナの起動順を決めるのに使う整数を指定します。 .TP \*(T<\fBlxc.monitor.unshare\fR\*(T> この値が 0 でない場合、コンテナが初期化される前 (pre-start フックが実行される前) にマウント名前空間がホストから unshare されます。この機能を使う場合、スタート時に CAP_SYS_ADMIN ケーパビリティが必要です。デフォルト値は 0 です。 .TP \*(T<\fBlxc.group\fR\*(T> コンテナを追加したいコンテナグループ名を指定します。 複数の値を設定でき、複数回指定することもできます。 設定されたグループは、関連する一連のコンテナを起動させるために使われます。 .SS 自動起動とシステムブート コンテナはいくつでもグループに属することができ、全く属さないことも可能です。特別なグループが 2 つ存在します。1 つは NULL グループです。これはどのグループにも属さないコンテナです。もう 1 つは "onboot" グループです。 .PP LXC サービスが有効になった状態でシステムがブートすると、最初に "onboot" グループのメンバーである lxc.start.auto == 1 が設定されたコンテナを起動しようとします。起動は lxc.start.order の順に起動します。 lxc.start.delay が指定されている場合、現在対象となっているコンテナに初期化の時間を与え、ホストシステムの負荷を低減するために、次のコンテナを開始させるまでに遅延時間を与えます。 "onboot" グループのメンバーが開始した後、LXC システムは lxc.start.auto == 1 が設定された、どのグループのメンバーでもない (NULL グループの) コンテナのブートを onboot グループのコンテナと同様に開始します。 .SS コンテナの環境変数 コンテナに環境変数を渡したい場合 (環境変数はコンテナの init とその子孫全てで利用可能です)、\fBlxc.environment\fR パラメータがその用途に使えます。 機微 (センシティブ) な情報を渡さないように注意が必要です。そのような情報を持たないコンテナ内のプロセスでこれらの環境変数が利用可能になってしまいます。環境変数は常に \fB/proc/PID/environ\fR 経由で利用可能になります。 .PP この設定項目は、設定したい環境変数ごとに 1 度ずつ、何度でも指定できます。 .TP \*(T<\fBlxc.environment\fR\*(T> コンテナに渡したい環境変数を指定します。 例: .nf \*(T< lxc.environment = APP_ENV=production lxc.environment = SYSLOG_SERVER=192.0.2.42 \*(T> .fi .SH 例 以下に紹介するいくつかの例に加えて、他の設定例が /usr/share/doc/lxc/examples にあります。 .SS ネットワーク この設定は、片方をブリッジである br0 と接続される veth ペアデバイスを使うコンテナを設定します (ブリッジは管理者によりあらかじめシステム上に設定済みである必要があります)。 仮想ネットワークデバイスは、コンテナ内では eth0 とリネームされます。 .PP .nf \*(T< lxc.utsname = myhostname lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.name = eth0 lxc.network.hwaddr = 4a:49:43:49:79:bf lxc.network.ipv4 = 1.2.3.5/24 1.2.3.255 lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597 \*(T> .fi .SS "UID/GID のマッピング" この設定は、コンテナ内のユーザとグループ両方の id 0-9999 の範囲を、ホスト上の 100000-109999 へマッピングします。 .PP .nf \*(T< lxc.id_map = u 0 100000 10000 lxc.id_map = g 0 100000 10000 \*(T> .fi .SS "CONTROL GROUP" この設定は、アプリケーションのための control group をいくつか設定します。 cpuset.cpus は定義された cpu のみ使用できるように制限します。 cpus.share は、control group の (cpu) 優先度を指定します。 devices.allow は、特定のデバイスを使用可能にします。 .PP .nf \*(T< 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 \*(T> .fi .SS 複雑な設定 この例は、control group を使って、複雑なネットワークスタックを作成し、新しいホスト名を指定し、いくつかの場所をマウントし、ルートファイルシステムを変更するような複雑な設定を示します。 .PP .nf \*(T< lxc.utsname = complex lxc.network.type = veth lxc.network.flags = up lxc.network.link = br0 lxc.network.hwaddr = 4a:49:43:49:79:bf lxc.network.ipv4 = 10.2.3.5/24 10.2.3.255 lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3597 lxc.network.ipv6 = 2003:db8:1:0:214:5432:feab:3588 lxc.network.type = macvlan lxc.network.flags = up lxc.network.link = eth0 lxc.network.hwaddr = 4a:49:43:49:79:bd lxc.network.ipv4 = 10.2.3.4/24 lxc.network.ipv4 = 192.168.10.125/24 lxc.network.ipv6 = 2003:db8:1:0:214:1234:fe0b:3596 lxc.network.type = phys lxc.network.flags = up lxc.network.link = dummy0 lxc.network.hwaddr = 4a:49:43:49:79:ff lxc.network.ipv4 = 10.2.3.6/24 lxc.network.ipv6 = 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 = /etc/fstab.complex lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0 lxc.rootfs = /mnt/rootfs.complex lxc.cap.drop = sys_module mknod setuid net_raw lxc.cap.drop = mac_override \*(T> .fi .SH "SEE ALSO" \fBchroot\fR(1), \fBpivot_root\fR(8), \fB\*(T<\fIfstab\fR\*(T>\fR(5) \fB\*(T<\fIcapabilities\fR\*(T>\fR(7) .SH "SEE ALSO" \fBlxc\fR(7), \fBlxc-create\fR(1), \fBlxc-copy\fR(1), \fBlxc-destroy\fR(1), \fBlxc-start\fR(1), \fBlxc-stop\fR(1), \fBlxc-execute\fR(1), \fBlxc-console\fR(1), \fBlxc-monitor\fR(1), \fBlxc-wait\fR(1), \fBlxc-cgroup\fR(1), \fBlxc-ls\fR(1), \fBlxc-info\fR(1), \fBlxc-freeze\fR(1), \fBlxc-unfreeze\fR(1), \fBlxc-attach\fR(1), \fBlxc.conf\fR(5) .SH 作者 Daniel Lezcano <\*(T>