"Fossies" - the Fresh Open Source Software Archive  

Source code changes of the file "doc/ja/lxc.container.conf.sgml.in" between
lxc-4.0.9.tar.gz and lxc-4.0.10.tar.gz

About: LXC are userspace tools for the Linux kernel containers that let users easily create and manage system or application containers.

lxc.container.conf.sgml.in  (lxc-4.0.9):lxc.container.conf.sgml.in  (lxc-4.0.10)
skipping to change at line 546 skipping to change at line 546
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term> <term>
<option>lxc.net.[i].type</option> <option>lxc.net.[i].type</option>
</term> </term>
<listitem> <listitem>
<para> <para>
<!-- <!--
specify what kind of network virtualization to be used specify what kind of network virtualization to be used
for the container. for the container.
Must be specified before any other option(s) on the net device.
Multiple networks can be specified by using an additional index Multiple networks can be specified by using an additional index
<option>i</option> <option>i</option>
after all <option>lxc.net.*</option> keys. For example, after all <option>lxc.net.*</option> keys. For example,
<option>lxc.net.0.type = veth</option> and <option>lxc.net.0.type = veth</option> and
<option>lxc.net.1.type = veth</option> specify two different <option>lxc.net.1.type = veth</option> specify two different
networks of the same type. All keys sharing the same index networks of the same type. All keys sharing the same index
<option>i</option> will be treated as belonging to the same <option>i</option> will be treated as belonging to the same
network. For example, <option>lxc.net.0.link = br0</option> network. For example, <option>lxc.net.0.link = br0</option>
will belong to <option>lxc.net.0.type</option>. will belong to <option>lxc.net.0.type</option>.
Currently, the different virtualization types can be: Currently, the different virtualization types can be:
--> -->
コンテナがどの種類のネットワーク仮想化を使うかを指定します。すべての <option>lxc.net.*</option> キーに、 コンテナがどの種類のネットワーク仮想化を使うかを指定します。ネットワークデバイスの他のオプションを設定する前に指定しなければいけませ
追加のインデックス <option>i</option> を使うと、複数のネットワークを指定できます。例えば、<option>lxc.net.0.type = ん。
veth</option> と <option>lxc.net.1.type = veth</option> は、同じタイプの異なるネットワークを 2 つ指定し すべての <option>lxc.net.*</option> キーに、追加のインデックス <option>i</option>
ます。 使うと、複数のネットワークを指定できます。例えば、<option>lxc.net.0.type = veth</option> と <option>lxc.ne
t.1.type = veth</option> は、同じタイプの異なるネットワークを 2 つ指定します。
同じインデックスを指定したキーはすべて同じネットワークの指定になります。例えば、<option>lxc.net.0.link = b r0</option> は <option>lxc.net.0.type</option> と同じネットワークの設定になります。 同じインデックスを指定したキーはすべて同じネットワークの指定になります。例えば、<option>lxc.net.0.link = b r0</option> は <option>lxc.net.0.type</option> と同じネットワークの設定になります。
現時点では、以下のネットワーク仮想化のタイプが使えます: 現時点では、以下のネットワーク仮想化のタイプが使えます:
</para> </para>
<para> <para>
<!-- <!--
<option>none:</option> will cause the container to share <option>none:</option> will cause the container to share
the host's network namespace. This means the host the host's network namespace. This means the host
network devices are usable in the container. It also network devices are usable in the container. It also
means that if both the container and host have upstart as means that if both the container and host have upstart as
skipping to change at line 1481 skipping to change at line 1483
<!-- <!--
NOTE - LXC will generally ensure that mount targets and relative NOTE - LXC will generally ensure that mount targets and relative
bind-mount sources are properly confined under the container bind-mount sources are properly confined under the container
root, to avoid attacks involving over-mounting host directories root, to avoid attacks involving over-mounting host directories
and files. (Symbolic links in absolute mount sources are ignored) and files. (Symbolic links in absolute mount sources are ignored)
However, if the container configuration first mounts a directory which However, if the container configuration first mounts a directory which
is under the control of the container user, such as /home/joe, into is under the control of the container user, such as /home/joe, into
the container at some <filename>path</filename>, and then mounts the container at some <filename>path</filename>, and then mounts
under <filename>path</filename>, then a TOCTTOU attack would be under <filename>path</filename>, then a TOCTTOU attack would be
possible where the container user modifies a symbolic link under possible where the container user modifies a symbolic link under
his home directory at just the right time. their home directory at just the right time.
--> -->
注意: 通常 LXC は、マウント対象と相対パス指定のバインドマウントを、適切にコンテナルート以下に閉じ込めます。 注意: 通常 LXC は、マウント対象と相対パス指定のバインドマウントを、適切にコンテナルート以下に閉じ込めます。
これは、ホストのディレクトリやファイルに対して重ね合わせを行うようなマウントによる攻撃を防ぎます。(絶対パス指定のマウントソース中の各パスがシン ボリックリンクである場合は無視されます。) これは、ホストのディレクトリやファイルに対して重ね合わせを行うようなマウントによる攻撃を防ぎます。(絶対パス指定のマウントソース中の各パスがシン ボリックリンクである場合は無視されます。)
しかし、もしコンテナの設定が最初に、/home/joe のようなコンテナユーザのコントロール配下にあるディレクトリを、コンテナ中のある <fil ename>path</filename> にマウントし、その後 <filename>path</filename> 以下でマウントが行われるような場合、コンテ ナユーザがタイミングを見計らって自身のホームディレクトリ以下でシンボリックリンクを操作するような TOCTTOU 攻撃が成立する可能性があります。 しかし、もしコンテナの設定が最初に、/home/joe のようなコンテナユーザのコントロール配下にあるディレクトリを、コンテナ中のある <fil ename>path</filename> にマウントし、その後 <filename>path</filename> 以下でマウントが行われるような場合、コンテ ナユーザがタイミングを見計らって自身のホームディレクトリ以下でシンボリックリンクを操作するような TOCTTOU 攻撃が成立する可能性があります。
</para> </para>
<variablelist> <variablelist>
<varlistentry> <varlistentry>
<term> <term>
<option>lxc.mount.fstab</option> <option>lxc.mount.fstab</option>
</term> </term>
skipping to change at line 1993 skipping to change at line 1995
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term> <term>
<option>lxc.rootfs.options</option> <option>lxc.rootfs.options</option>
</term> </term>
<listitem> <listitem>
<para> <para>
<!-- <!--
extra mount options to use when mounting the rootfs. Specify extra mount options to use when mounting the rootfs.
--> The format of the mount options corresponds to the
rootfs をマウントするときに追加したいマウントオプション。 format used in fstab. In addition, LXC supports the custom
<option>idmap=</option> mount option. This option can be used
to tell LXC to create an idmapped mount for the container's
rootfs. This is useful when the user doesn't want to recursively
chown the rootfs of the container to match the idmapping of the
user namespace the container is going to use. Instead an
idmapped mount can be used to handle this.
The argument for
<option>idmap=</option>
can either be a path pointing to a user namespace file that
LXC will open and use to idmap the rootfs or the special value
"container" which will instruct LXC to use
the container's user namespace to idmap the rootfs.
-->
rootfs をマウントするときに使うマウントオプション。マウントオプションのフォーマットは fstab で使うフォーマットと同
じです。
加えて、LXC では独自の <option>idmap=</option> マウントオプションが使えます。このオプションを使うと
、LXC に対してコンテナの rootfs を idmapped マウントするように指示できます。
これは、コンテナが使うユーザー名前空間の ID マッピングと一致させるために、コンテナの rootfs を再帰的に chown
したくない場合に役に立ちます。代わりに idmapped マウントが使えます。
<option>idmap=</option> の引数は、LXC が開いて rootfs を idmap するのに使うユーザー名
前空間ファイルを指すパス、もしくは "container" という特別な値のどちらかです。"container" という値は、コンテナのユーザー名前空間を使って
rootfs を idmap するように LXC に指示します。
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term> <term>
<option>lxc.rootfs.managed</option> <option>lxc.rootfs.managed</option>
</term> </term>
<listitem> <listitem>
<para> <para>
skipping to change at line 2021 skipping to change at line 2040
LXC がコンテナのストレージを管理していない場合は、この値を 0 に設定します。 LXC がコンテナのストレージを管理していない場合は、この値を 0 に設定します。
0 に設定すると、LXC はコンテナのストレージを変更しません。デフォルト値は 1 です。 0 に設定すると、LXC はコンテナのストレージを変更しません。デフォルト値は 1 です。
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
</variablelist> </variablelist>
</refsect2> </refsect2>
<refsect2> <refsect2>
<title>Control group</title> <title>Control group ("cgroup")</title>
<para> <para>
<!-- <!--
The control group section contains the configuration for the The control group section contains the configuration for the
different subsystem. <command>lxc</command> does not check the different subsystem. <command>lxc</command> does not check the
correctness of the subsystem name. This has the disadvantage correctness of the subsystem name. This has the disadvantage
of not detecting configuration errors until the container is of not detecting configuration errors until the container is
started, but has the advantage of permitting any future started, but has the advantage of permitting any future
subsystem. subsystem.
--> -->
CONTROL GROUP セクションは、(lxc とは) 別のサブシステムの設定を含みます。 CONTROL GROUP セクションは、(lxc とは) 別のサブシステムの設定を含みます。
<command>lxc</command> は、このサブシステム名の正しさはチェックしません。 <command>lxc</command> は、このサブシステム名の正しさはチェックしません。
実行時のエラーを検出するのに不便ですが、別の将来のサブシステムをサポート出来るという有利な点もあります。 実行時のエラーを検出するのに不便ですが、別の将来のサブシステムをサポート出来るという有利な点もあります。
</para> </para>
<para>
<!--
The kernel implementation of cgroups has changed significantly over the
years. With Linux 4.5 support for a new cgroup filesystem was added
usually referred to as "cgroup2" or "unified hierarchy". Since then the
old cgroup filesystem is usually referred to as "cgroup1" or the
"legacy hierarchies". Please see the cgroups manual page for a detailed
explanation of the differences between the two versions.
-->
カーネルにおける cgroup 実装は長年にわたって大きく変化してきました。
Linux 4.5 で新しい cgroup ファイルシステムのサポートが追加されました。通常は "cgroup2" や "unified hie
rarchy"(単一階層構造) と呼ばれています。
それ以来、通常は古い cgroup ファイルシステムは "cgroup1" や "legacy hierarchies"(レガシー階層構造)と呼
ばれています。
この 2 つのバージョンの違いについての詳細な説明は、cgroup のマニュアルページをご覧ください。
</para>
<para>
<!--
LXC distinguishes settings for the legacy and the unified hierarchy by
using different configuration key prefixes. To alter settings for
controllers in a legacy hierarchy the key prefix
<option>lxc.cgroup.</option> must be used and in order to alter the
settings for a controller in the unified hierarchy the
<option>lxc.cgroup2.</option> key must be used. Note that LXC will
ignore <option>lxc.cgroup.</option> settings on systems that only use
the unified hierarchy. Conversely, it will ignore
<option>lxc.cgroup2.</option> options on systems that only use legacy
hierachies.
-->
LXC は cgroup1(レガシー階層構造)と cgroup2(単一階層構造)に対する設定を、異なる設定プレフィックスを使って区別しています。
cgroup1 に対する設定を変更するには <option>lxc.cgroup.</option> というプレフィックスを使う必要があり、cg
roup2 の設定を変更するには <option>lxc.cgroup2.</option> を使う必要があります。
LXC は、cgroup2 だけが使われているシステム上の <option>lxc.cgroup.</option> を無視します。逆に cgr
oup1 だけが使われているシステム上の <option>lxc.cgroup2.</option> を無視します。
</para>
<para>
<!--
At its core a cgroup hierarchy is a way to hierarchically organize
processes. Usually a cgroup hierarchy will have one or more
"controllers" enabled. A "controller" in a cgroup hierarchy is usually
responsible for distributing a specific type of system resource along
the hierarchy. Controllers include the "pids" controller, the "cpu"
controller, the "memory" controller and others. Some controllers
however do not fall into the category of distributing a system
resource, instead they are often referred to as "utility" controllers.
One utility controller is the device controller. Instead of
distributing a system resource it allows to manage device access.
-->
cgroup 階層の本質は、プロセスを階層的に構造化する方法です。通常は、cgroup 階層では 1 つ以上の「コントローラー」が有効になってい
ます。
通常、cgroup 階層の「コントローラー」は階層に従って特定のタイプのシステムリソースを分配する役割を果たします。
コントローラーには "pids" コントローラー、"cpu" コントローラー、"memory" コントローラーなどがあります。
しかし、システムリソースの分配するという役割に該当しないコントローラーもあります。このようなコントローラーは「ユーティリティー」コントローラーと
呼ばれたりします。
ユーティリティーコントローラーの 1 つにデバイスコントローラーがあります。このコントローラーはシステムリソースを分配する代わりにデバイスへのア
クセスを管理できます。
</para>
<para>
<!--
In the legacy hierarchy the device controller was implemented like most
other controllers as a set of files that could be written to. These
files where named "devices.allow" and "devices.deny". The legacy device
controller allowed the implementation of both "allowlists" and
"denylists".
-->
cgroup1 では、デバイスコントローラーは他の多くのコントローラーと同様に、書き込みできるファイルのセットとして実装されていました。
これらのファイルは "devices.allow" と "devices.deny" という名前のファイルでした。レガシーデバイスコントローラー
は「許可リスト(allowlists)」と「拒否リスト(denylists)」の両方を実装できました。
</para>
<para>
<!--
An allowlist is a device program that by default blocks access to all
devices. In order to access specific devices "allow rules" for
particular devices or device classes must be specified. In contrast, a
denylist is a device program that by default allows access to all
devices. In order to restrict access to specific devices "deny rules"
for particular devices or device classes must be specified.
-->
許可リスト(allowlist)とは、すべてのデバイスへのアクセスをブロックするデバイスプログラムです。特定のデバイスへのアクセスを行うには、特
定のデバイスもしくはデバイスクラスに対する「許可ルール(allow rules)」を指定する必要があります。
一方、拒否リスト(denylist)はデフォルトですべてのデバイスへのアクセスを許可するデバイスプログラムです。特定のデバイスへのアクセスを拒否
するには、特定のデバイスもしくはデバイスクラスに対する「拒否ルール(deny rules)」を指定する必要があります。
</para>
<para>
<!--
In the unified cgroup hierarchy the implementation of the device
controller has completely changed. Instead of files to read from and
write to a eBPF program of
<option>BPF_PROG_TYPE_CGROUP_DEVICE</option> can be attached to a
cgroup. Even though the kernel implementation has changed completely
LXC tries to allow for the same semantics to be followed in the legacy
device cgroup and the unified eBPF-based device controller. The
following paragraphs explain the semantics for the unified eBPF-based
device controller.
-->
cgroup2 では、デバイスコントローラーの実装が完全に変わりました。読み書きするファイルの代わりに、<option>BPF_PROG_TYP
E_CGROUP_DEVICE</option> の eBPF プログラムを cgroup にアタッチできます。
カーネルの実装が完全に変わったのにもかかわらず、LXC は cgroup1 のデバイスコントローラーと cgroup2 の eBPF ベースのデ
バイスコントローラーで同じセマンティクスに従えるようにしています。
このあとの段落では、cgroup2 の eBPF デバイスコントローラーに対するセマンティクスを説明します。
</para>
<para>
<!--
As mentioned the format for specifying device rules for the unified
eBPF-based device controller is the same as for the legacy cgroup
device controller; only the configuration key prefix has changed.
Specifically, device rules for the legacy cgroup device controller are
specified via <option>lxc.cgroup.devices.allow</option> and
<option>lxc.cgroup.devices.deny</option> whereas for the
cgroup2 eBPF-based device controller
<option>lxc.cgroup2.devices.allow</option> and
<option>lxc.cgroup2.devices.deny</option> must be used.
-->
先に述べたように、cgroup2 の eBPF ベースのデバイスコントローラーに対するデバイスルールを指定するフォーマットは、cgroup1 の
デバイスコントローラーと同じです。ただし、設定キーのプレフィックスは変更されています。
具体的には、cgroup1 のデバイスコントローラーに対するデバイスルールは <option>lxc.cgroup.devices.allow<
/option> と <option>lxc.cgroup.devices.deny</option> を使って指定します。一方、cgroup2 の eBPF
ベースのコントローラーでは <option>lxc.cgroup2.devices.allow</option> と <option>lxc.cgroup2.d
evices.deny</option> を使わなければなりません。
</para>
<para>
<itemizedlist>
<listitem>
<para>
<!--
A allowlist device rule
<programlisting>
lxc.cgroup2.devices.deny = a
</programlisting>
will cause LXC to instruct the kernel to block access to all
devices by default. To grant access to devices allow device rules
must be added via the <option>lxc.cgroup2.devices.allow</option>
key. This is referred to as a "allowlist" device program.
-->
許可リスト(allowlist)のデバイスルール
<programlisting>
lxc.cgroup2.devices.deny = a
</programlisting>
は、カーネルに対してデフォルトですべてのデバイスへのアクセスをブロックするように LXC が指示します。
デバイスへのアクセスを許可するには、デバイスに対する許可ルールを <option>lxc.cgroup2.devices.allow
</option> を使って追加する必要があります。これは「許可リスト」デバイスプログラムとして参照されます。
</para>
</listitem>
<listitem>
<para>
<!--
A denylist device rule
<programlisting>
lxc.cgroup2.devices.allow = a
</programlisting>
will cause LXC to instruct the kernel to allow access to all
devices by default. To deny access to devices deny device rules
must be added via <option>lxc.cgroup2.devices.deny</option> key.
This is referred to as a "denylist" device program.
-->
拒否リスト(denylist)のデバイスルール
<programlisting>
lxc.cgroup2.devices.allow = a
</programlisting>
は、カーネルに対してすべてのデバイスへのアクセスをデフォルトで許可するように LXC が指示します。
デバイスへのアクセスを拒否するには、デバイスに対する拒否ルールを <option>lxc.cgroup2.devices.deny<
/option> を使って追加する必要があります。これは「拒否リスト」デバイスプログラムとして参照されます。
</para>
</listitem>
<listitem>
<para>
<!--
Specifying any of the aformentioned two rules will cause all
previous rules to be cleared, i.e. the device list will be reset.
-->
前述の 2 つのルールのいずれかを指定すると、それ以前に指定していたルールがすべてクリアされます。つまり、デバイスリストがリセットさ
れます。
</para>
</listitem>
<listitem>
<para>
<!--
When an allowlist program is requested, i.e. access to all devices
is blocked by default, specific deny rules for individual devices
or device classes are ignored.
-->
許可リストプログラムが要求される場合、つまりデフォルトですべてのデバイスへのアクセスがブロックされている場合、個別のデバイスやデバイ
スクラスへの拒否ルールを指定しても無視されます。
</para>
</listitem>
<listitem>
<para>
<!--
When a denylist program is requested, i.e. access to all devices
is allowed by default, specific allow rules for individual devices
or device classes are ignored.
-->
拒否リストプログラムが要求される場合、つまりデフォルトですべてのデバイスへのアクセスが許可されている場合、個別のデバイスやデバイスク
ラスへの許可ルールを指定しても無視されます。
</para>
</listitem>
</itemizedlist>
</para>
<para>
<!--
For example the set of rules:
-->
例えば、次のようなルールの組
<programlisting>
lxc.cgroup2.devices.deny = a
lxc.cgroup2.devices.allow = c *:* m
lxc.cgroup2.devices.allow = b *:* m
lxc.cgroup2.devices.allow = c 1:3 rwm
</programlisting>
<!--
implements an allowlist device program, i.e. the kernel will block
access to all devices not specifically allowed in this list. This
particular program states that all character and block devices may be
created but only /dev/null might be read or written.
-->
は、許可リスト(allowlist)デバイスプログラムを実装します。つまり、カーネルはこのリストで許可されるように設定されていないすべてのデバイ
スへのアクセスをブロックします。
このプログラムでは、すべてのキャラクターデバイスとブロックデバイスが作成できますが、読み書きは /dev/null に対してしか行なえません。
</para>
<para>
<!--
If we instead switch to the following set of rules:
-->
代わりに先のルールから次のようなルールの組に変更したとすると、
<programlisting>
lxc.cgroup2.devices.allow = a
lxc.cgroup2.devices.deny = c *:* m
lxc.cgroup2.devices.deny = b *:* m
lxc.cgroup2.devices.deny = c 1:3 rwm
</programlisting>
<!--
then LXC would instruct the kernel to implement a denylist, i.e. the
kernel will allow access to all devices not specifically denied in
this list. This particular program states that no character devices or
block devices might be created and that /dev/null is not allow allowed
to be read, written, or created.
-->
LXC はカーネルに拒否リスト(denylist)の実装を指示します。つまりカーネルはこのリストで拒否を指定していないすべてのデバイスへのアクセ
スを許可します。
このプログラムでは、キャラクターデバイスとブロックデバイスは作成できません。そして /dev/null の読み書きと作成は許可されません。
</para>
<para>
<!--
Now consider the same program but followed by a "global rule"
which determines the type of device program (allowlist or
denylist) as explained above:
-->
ここで、同じプログラムでも、前述のようにデバイスのプログラムタイプを決定するような「グローバルルール」が続いている場合を考えてみましょう。
<programlisting>
lxc.cgroup2.devices.allow = a
lxc.cgroup2.devices.deny = c *:* m
lxc.cgroup2.devices.deny = b *:* m
lxc.cgroup2.devices.deny = c 1:3 rwm
lxc.cgroup2.devices.allow = a
</programlisting>
<!--
The last line will cause LXC to reset the device list without changing
the type of device program.
-->
最後の行は、デバイスプログラムのタイプを変更せずに、LXC がデバイスリストをリセットしてしまいます。
</para>
<para>
<!--
If we specify:
-->
次のように指定した場合、
<programlisting>
lxc.cgroup2.devices.allow = a
lxc.cgroup2.devices.deny = c *:* m
lxc.cgroup2.devices.deny = b *:* m
lxc.cgroup2.devices.deny = c 1:3 rwm
lxc.cgroup2.devices.deny = a
</programlisting>
<!--
instead then the last line will cause LXC to reset the device list and
switch from a allowlist program to a denylist program.
-->
前の例と違って最後の行によって、LXC はデバイスリストをリセットし、許可リスト(allowlist)から拒否リスト(denylist)にプログ
ラムを変更してしまいます。
</para>
<variablelist> <variablelist>
<varlistentry> <varlistentry>
<term> <term>
<option>lxc.cgroup.[control name]</option> <option>lxc.cgroup.[control name].[controller file]</option>
</term> </term>
<listitem> <listitem>
<para> <para>
<!-- <!--
Specify the control group value to be set on a legacy cgroup Specify the control group value to be set on a legacy cgroup
hierarchy. The controller name is the literal name of the control hierarchy. The controller name is the literal name of the control
group. The permitted names and the syntax of their values is not group. The permitted names and the syntax of their values is not
dictated by LXC, instead it depends on the features of the Linux dictated by LXC, instead it depends on the features of the Linux
kernel running at the time the container is started, eg. kernel running at the time the container is started, eg.
<option>lxc.cgroup.cpuset.cpus</option> <option>lxc.cgroup.cpuset.cpus</option>
--> -->
legacy な cgroup 階層 (cgroup v1) に設定する値を指定します。コントローラー名は control grou p そのままの名前です。 レガシー cgroup 階層 (cgroup v1) に設定する値を指定します。コントローラー名は control group その ままの名前です。
許される名前や値の書式は LXC が指定することはなく、コンテナが実行された時に実行されている Linux カーネルの機能に依存しま す。 許される名前や値の書式は LXC が指定することはなく、コンテナが実行された時に実行されている Linux カーネルの機能に依存しま す。
例えば <option>lxc.cgroup.cpuset.cpus</option> のようになります。 例えば <option>lxc.cgroup.cpuset.cpus</option> のようになります。
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
<varlistentry> <varlistentry>
<term> <term>
<option>lxc.cgroup2.[controller name]</option> <option>lxc.cgroup2.[controller name].[controller file]</option>
</term> </term>
<listitem> <listitem>
<para> <para>
<!-- <!--
Specify the control group value to be set on the unified cgroup Specify the control group value to be set on the unified cgroup
hierarchy. The controller name is the literal name of the control hierarchy. The controller name is the literal name of the control
group. The permitted names and the syntax of their values is not group. The permitted names and the syntax of their values is not
dictated by LXC, instead it depends on the features of the Linux dictated by LXC, instead it depends on the features of the Linux
kernel running at the time the container is started, eg. kernel running at the time the container is started, eg.
<option>lxc.cgroup2.memory.high</option> <option>lxc.cgroup2.memory.high</option>
skipping to change at line 3732 skipping to change at line 4022
lxc.net.0.ipv6.address = 2003:db8:1:0:214:5432:feab:3588 lxc.net.0.ipv6.address = 2003:db8:1:0:214:5432:feab:3588
lxc.net.1.type = macvlan lxc.net.1.type = macvlan
lxc.net.1.flags = up lxc.net.1.flags = up
lxc.net.1.link = eth0 lxc.net.1.link = eth0
lxc.net.1.hwaddr = 4a:49:43:49:79:bd 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 = 10.2.3.4/24
lxc.net.1.ipv4.address = 192.168.10.125/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.1.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3596
lxc.net.2.type = phys lxc.net.2.type = phys
lxc.net.2.flags = up lxc.net.2.flags = up
lxc.net.2.link = dummy0 lxc.net.2.link = random0
lxc.net.2.hwaddr = 4a:49:43:49:79:ff lxc.net.2.hwaddr = 4a:49:43:49:79:ff
lxc.net.2.ipv4.address = 10.2.3.6/24 lxc.net.2.ipv4.address = 10.2.3.6/24
lxc.net.2.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297 lxc.net.2.ipv6.address = 2003:db8:1:0:214:1234:fe0b:3297
lxc.cgroup.cpuset.cpus = 0,1 lxc.cgroup.cpuset.cpus = 0,1
lxc.cgroup.cpu.shares = 1234 lxc.cgroup.cpu.shares = 1234
lxc.cgroup.devices.deny = a lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c 1:3 rw lxc.cgroup.devices.allow = c 1:3 rw
lxc.cgroup.devices.allow = b 8:0 rw lxc.cgroup.devices.allow = b 8:0 rw
lxc.mount.fstab = /etc/fstab.complex lxc.mount.fstab = /etc/fstab.complex
lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0 lxc.mount.entry = /lib /root/myrootfs/lib none ro,bind 0 0
lxc.rootfs.path = dir:/mnt/rootfs.complex lxc.rootfs.path = dir:/mnt/rootfs.complex
lxc.rootfs.options = idmap=container
lxc.cap.drop = sys_module mknod setuid net_raw lxc.cap.drop = sys_module mknod setuid net_raw
lxc.cap.drop = mac_override lxc.cap.drop = mac_override
</programlisting> </programlisting>
</refsect2> </refsect2>
</refsect1> </refsect1>
<refsect1> <refsect1>
<title>See Also</title> <title>See Also</title>
<simpara> <simpara>
 End of changes. 11 change blocks. 
13 lines changed or deleted 333 lines changed or added

Home  |  About  |  Features  |  All  |  Newest  |  Dox  |  Diffs  |  RSS Feeds  |  Screenshots  |  Comments  |  Imprint  |  Privacy  |  HTTP(S)