Difference between revisions of "Talk:Linux Containers"

From ArchWiki
Jump to: navigation, search
(systemd support)
(removed out-dated discussion)
 
(37 intermediate revisions by 15 users not shown)
Line 1: Line 1:
 +
== Example using only netctl ==
 +
@Lahwaacz - While I agree that we don't want to duplicate content in other articles, I feel that providing a working configuration within the article is welcomed for completeness just as we do in the beginners guide.  Therefore, a few common set ups are needed in my opinion. See, https://wiki.archlinux.org/index.php?title=Linux_Containers&diff=373914&oldid=373913 [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 19:20, 16 May 2015 (UTC)
  
== systemd support ==
+
:I'm sorry but these two approaches are opposite: we can either avoid duplication or follow the BG style. What is wrong with instructions such as "Create a bridge named ... as described in ..." which is still sufficiently (IMO) complete? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:16, 16 May 2015 (UTC)
  
LXC support for containers using systemd appears to be broken currently.
+
::I think the article should keep the two examples following the BG style. Just my $0.02. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 01:24, 17 May 2015 (UTC)
  
http://sourceforge.net/mailarchive/message.php?msg_id=30058163
+
:::+1 for merging, the wired network section is practically a copy of [[Bridge with netctl]], I don't see anything specific to Linux Containers here. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:33, 18 May 2015 (UTC)
----
 
I found [http://comments.gmane.org/gmane.linux.kernel.containers.lxc.general/4126 this thread] to contain both solutions and caveats/issues relating to systemd in LXC.
 
  
<blockquote>First step appears to be to [http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface set a container=LXC] (or some other short string) before invoking init in the containerIs there a mechanism to do this?</blockquote>
+
:::-1 for merging the network stuff.  The examples provided in the article are appropriate.  For me as a consumer of information, the Archwiki merges the past couple years have led to more confusing, fragmented articles/how-to's because now, you end up having to flip back and forth between multiple browser tabs, searching entire articles for the one or two bits that relate to what you are actually trying to accomplish, rather than having relevant info provided in context, right where you need/want it. Sure, have the larger, more exhaustive networking article that I can reference for the nitty, gritty details. And I get that that may also be desirable from wiki maintainers perspective.  For a user perspective, however, it's much less efficient for me have to search through it all, try to figure out what context is applicable or not, etc.  Tough balancing act.  I've just been noticing that as of late things that used to be fairly easy and straight forward to follow, no longer are, and require much more jumping around to sort out the bits you're actually looking for.  Peace[[User:Kgunders|Kgunders]] ([[User talk:Kgunders|talk]]) 17:33, 28 September 2015 (UTC)
  
<blockquote>Because of doing the devtmpfs thing, the guest can immediately see things like removable drives coming and going and might, presumably, be able to mount them. Not thrilled with that from a security standpoint. Would also mean the guests could access things like my permanent forensic CDs that are in the CD drives.  I guess that can be restricted in the config but still makes me a bit uncomfortable that the guest has complete visibility into the hosts dev system.<br /><br />
+
:::-1 for merging for the reasons nicely articulated by Kgunders. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 19:11, 28 September 2015 (UTC)
Another gotcha, albeit a much more minor one...  When systemd drops into this mode, you no longer have vty consoles available so lxc-console won't work.  That's actually on their page.<br /><br />
 
I remember seeing this:
 
<blockquote>If systemd detects it is run in a container it will spawn a single shell on /dev/console, and not care about VTs or multiple gettys on VTs</blockquote>
 
</blockquote>
 
  
<blockquote>Forgot to include the entry I added to the config file to make it all workie...
+
== Rewrite a section about "Host network configuration" ==
</blockquote>
 
    lxc.mount.entry=devtmpfs /srv/lxc/rootfs/dev devtmpfs defaults 0 0
 
  
<blockquote>Container seems to hang if lxc-start is run in disconnected mode (lxc-start -d -o {log}). Starts up fine with a console that's connected to pty's but not to a log it seems...</blockquote>
+
I was looking at the above-mentined section, and it does not make any sense to me. First, a bridge interface for containers has nothing to do with whether the host uses wired or wireless connection. Why is it necessary to add an external interface to the bridge? The topology of a network for containers, and how it is connected to the internet is a separate issue.
  
[[User:Takeshita kenji|Takeshita kenji]] ([[User talk:Takeshita kenji|talk]]) 04:26, 20 January 2013 (UTC)
+
Therefore, I suggest that I rewrite this section by providing an example of an empty bridge interface. Then, it can be NAT'ed or or whatever. I would argue that NAT is the best setup option because it automatically protects containers from possible malicious network traffic. [[User:Lisaev|Lisaev]] ([[User talk:Lisaev|talk]]) 02:12, 30 November 2016 (UTC)
----
 
The [https://wiki.gentoo.org/wiki/LXC#Arch_Linux Gentoo Wiki page] about LXC says to just go back to the systemd+sysvinit script setup:
 
  
    pacman -S systemd systemd-sysvcompat initscripts
+
:Describing this sensibly is difficult because it's not specific to Linux Containers. There is already much info about this on this wiki, see e.g. [[QEMU#Networking]]. I think there should be a separate page with the general info about topologies and virtual interfaces, on which other pages could build, adding their specifics etc. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:23, 30 November 2016 (UTC)
  
However:
+
::I agree. To me, sensibly means what I use most in practice on dosens of containers -- an empty bridge with veth interfaces dynamically created by LXC and NAT'ed behind the host. The point here is not to give a complete overview of all LXC networking capabilities, because LXC documentation is written well enough, but to give a starting working configuration. I agree that it is not the only possible configuration, but I think that in the current form the host network section is unnecessary confusing :) [[User:Lisaev|Lisaev]] ([[User talk:Lisaev|talk]]) 05:11, 2 December 2016 (UTC)
<blockquote>Further steps are needed to set-up a working archlinux container in gentoo.</blockquote>
 
[[User:Takeshita kenji|Takeshita kenji]] ([[User talk:Takeshita kenji|talk]]) 04:29, 20 January 2013 (UTC)
 
----
 
One last note: systemd support is a topic under active discussion on the lxc-devel mailing list.  [http://sourceforge.net/mailarchive/forum.php?thread_name=20130117170142.GA27967%40sergelap&forum_name=lxc-devel This thread], for example.
 
  
[[User:Takeshita kenji|Takeshita kenji]] ([[User talk:Takeshita kenji|talk]]) 04:37, 20 January 2013 (UTC)
+
:::Hi, I've added a section on how to enable the legacy lxcbr0 (before i was aware of exactly how talks work. This information was not easy to come by when sitting on a laptop with just WIFI, and if I want it someone else will was the general idea... --[[User:Izznogooood|Izznogooood]] ([[User talk:Izznogooood|talk]]) 20:04, 17 October 2017 (UTC)
  
----
+
== Rewrite the section "Container creation" ==
[[User:starfry]] 21:47, 27 March 2013 (UTC)
 
  
I have a fully operational implementation of LXC inside a container that runs systemd. I have started a sub-page off the LXC wiki page to record my notes [[Lxc-systemd]]. It has been a hard slog with lots of disussion with both the lxc and systemd folks but I have it working now. Let me know if I can provide any more information.
+
''Apologize: I'm not English mother tongue, it will be very hard for me to have grammatical validation''
----
+
 
 +
Since LXC is version 3, the whole templates has been revamped. In order to create container, the choice is now to download the templates from a central place:
 +
{{bc|[mrakotomandimby@arch-00 arch-00]$ sudo lxc-create -n test -t download
 +
Setting up the GPG keyring
 +
Downloading the image index
 +
 
 +
---
 +
DIST RELEASE ARCH VARIANT BUILD
 +
---
 +
...
 +
alpine edge amd64 default 20180331_17:50
 +
...
 +
archlinux current amd64 default 20180330_01:27
 +
...
 +
centos 7 amd64 default 20180331_02:16
 +
...
 +
debian jessie amd64 default 20180330_22:42
 +
...
 +
 
 +
}}
 +
 
 +
It will prompt you the Distrubution, Release, then Architecture.
 +
 
 +
If you prefer the one line version:
 +
{{bc|[mrakotomandimby@arch-00 ~]$ sudo lxc-create -n test -t download -- --dist archlinux --release current --arch amd64}}
 +
 
 +
{{unsigned|19:30, 31 March 2018‎|Rakotomandimby}}
 +
 
 +
:: I updated the article, please review. [[User:Graysky|Graysky]] ([[User talk:Graysky|talk]]) 11:06, 1 April 2018 (UTC)
 +
 
 +
== Append the section "Container creation" with archlinux-bootstrap images ==
 +
 
 +
Arch provides archlinux-bootstrap images that can be used when pacman is not available (on non-arch systems or when it is broken). In fact, I think it is the simplest method that other distros should use. I verified this method on Fedora 24 server system.
 +
 
 +
Any objections if I add this? [[User:Lisaev|Lisaev]] ([[User talk:Lisaev|talk]]) 02:39, 30 November 2016 (UTC)
 +
 
 +
:Like the section above, this is not specific to Linux Containers. Bootstrapping Arch is already described in [[Install_from_existing_Linux#Method_A:_Using_the_bootstrap_image_.28recommended.29]], making a container from that should be fairly trivial. Perhaps some links would be enough? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 06:27, 30 November 2016 (UTC)
 +
 
 +
::Actually, I dodn't know about that section you mentioned :) Yes, then it should be mostly a link... I suggested the edit because on non-arch distros, the default lxc-archlinux template fails if pacman is not found. Of course, this is stupid because pacman is not needed at all! Unfortunately, the archlinux template is a bloated mess of features (even if pacman is present) because it does not have a dedicated maintainer who would block some features, and upstream LXC accepts almost any patch that is formally correct. Hence, I wanted to provide a 5-line set of instructions so that ppl who run non-arch hosts could deploy arch guests witjout building pacman... [[User:Lisaev|Lisaev]] ([[User talk:Lisaev|talk]]) 05:18, 2 December 2016 (UTC)
 +
 
 +
== double tty ==
 +
 
 +
When login to the container with lxc-console -n CONTAINER_NAME a problem with a double tty presents.
 +
 
 +
The problem can be avoided using lxc-console -n CONTAINER_NAME -t 0 but i don't know if it is a good workaround.
 +
 
 +
I have added that to the page in the section Basic_usage.
 +
 
 +
More information on the problem:
 +
*https://github.com/lxc/lxc/issues/484
 +
*https://github.com/lxc/lxc/issues/520
 +
 
 +
[[User:Monty programador|Monty programador]] ([[User talk:Monty programador|talk]]) 09:54, 28 February 2017 (UTC)
 +
 
 +
== dnsmasq ==
 +
"You also need to install Dnsmasq which is a dependency for lxcbr0." This instruction is false, therefor this wiki needs an update. After weeks of trying via the Arch wiki and further asking in IRC, I could not get a working network. Today a Mastodon connection [https://angristan.xyz/setup-network-bridge-lxc-net/ added a blog post] with a simple gotcha "Do not install the dnsmasq package. Indeed, dnsmasq-base contains the binary and the doc, whereas dnsmasq also contains the service. However, lxc-net spawns its own dnsmasq process, so if you install dnsmasq, it will run on its own and cause a conflict with lxc-net". They go on to describe the exact error I returned when following the steps described in this Arch wiki.
 +
 
 +
Essentially DNSMASQ duplicates the call to the network socket. Disabling it, stopping it, and restoring resolv.conf (I'd previously edited to accommodate OpenNIC DNS's) resulted in a working bridged network to the LXC container.
 +
 
 +
[[User:Bunnybooboo|Bunnybooboo]] ([[User talk:Bunnybooboo|talk]]) 11:36, 17 February 2018 (UTC)

Latest revision as of 11:12, 1 April 2018

Example using only netctl

@Lahwaacz - While I agree that we don't want to duplicate content in other articles, I feel that providing a working configuration within the article is welcomed for completeness just as we do in the beginners guide. Therefore, a few common set ups are needed in my opinion. See, https://wiki.archlinux.org/index.php?title=Linux_Containers&diff=373914&oldid=373913 Graysky (talk) 19:20, 16 May 2015 (UTC)

I'm sorry but these two approaches are opposite: we can either avoid duplication or follow the BG style. What is wrong with instructions such as "Create a bridge named ... as described in ..." which is still sufficiently (IMO) complete? -- Lahwaacz (talk) 21:16, 16 May 2015 (UTC)
I think the article should keep the two examples following the BG style. Just my $0.02. Graysky (talk) 01:24, 17 May 2015 (UTC)
+1 for merging, the wired network section is practically a copy of Bridge with netctl, I don't see anything specific to Linux Containers here. — Kynikos (talk) 03:33, 18 May 2015 (UTC)
-1 for merging the network stuff. The examples provided in the article are appropriate. For me as a consumer of information, the Archwiki merges the past couple years have led to more confusing, fragmented articles/how-to's because now, you end up having to flip back and forth between multiple browser tabs, searching entire articles for the one or two bits that relate to what you are actually trying to accomplish, rather than having relevant info provided in context, right where you need/want it. Sure, have the larger, more exhaustive networking article that I can reference for the nitty, gritty details. And I get that that may also be desirable from wiki maintainers perspective. For a user perspective, however, it's much less efficient for me have to search through it all, try to figure out what context is applicable or not, etc. Tough balancing act. I've just been noticing that as of late things that used to be fairly easy and straight forward to follow, no longer are, and require much more jumping around to sort out the bits you're actually looking for. Peace. Kgunders (talk) 17:33, 28 September 2015 (UTC)
-1 for merging for the reasons nicely articulated by Kgunders. Graysky (talk) 19:11, 28 September 2015 (UTC)

Rewrite a section about "Host network configuration"

I was looking at the above-mentined section, and it does not make any sense to me. First, a bridge interface for containers has nothing to do with whether the host uses wired or wireless connection. Why is it necessary to add an external interface to the bridge? The topology of a network for containers, and how it is connected to the internet is a separate issue.

Therefore, I suggest that I rewrite this section by providing an example of an empty bridge interface. Then, it can be NAT'ed or or whatever. I would argue that NAT is the best setup option because it automatically protects containers from possible malicious network traffic. Lisaev (talk) 02:12, 30 November 2016 (UTC)

Describing this sensibly is difficult because it's not specific to Linux Containers. There is already much info about this on this wiki, see e.g. QEMU#Networking. I think there should be a separate page with the general info about topologies and virtual interfaces, on which other pages could build, adding their specifics etc. -- Lahwaacz (talk) 06:23, 30 November 2016 (UTC)
I agree. To me, sensibly means what I use most in practice on dosens of containers -- an empty bridge with veth interfaces dynamically created by LXC and NAT'ed behind the host. The point here is not to give a complete overview of all LXC networking capabilities, because LXC documentation is written well enough, but to give a starting working configuration. I agree that it is not the only possible configuration, but I think that in the current form the host network section is unnecessary confusing :) Lisaev (talk) 05:11, 2 December 2016 (UTC)
Hi, I've added a section on how to enable the legacy lxcbr0 (before i was aware of exactly how talks work. This information was not easy to come by when sitting on a laptop with just WIFI, and if I want it someone else will was the general idea... --Izznogooood (talk) 20:04, 17 October 2017 (UTC)

Rewrite the section "Container creation"

Apologize: I'm not English mother tongue, it will be very hard for me to have grammatical validation

Since LXC is version 3, the whole templates has been revamped. In order to create container, the choice is now to download the templates from a central place:

[mrakotomandimby@arch-00 arch-00]$ sudo lxc-create -n test -t download
Setting up the GPG keyring
Downloading the image index

---
DIST	RELEASE	ARCH	VARIANT	BUILD
---
...
alpine	edge	amd64	default	20180331_17:50
...
archlinux	current	amd64	default	20180330_01:27
...
centos	7	amd64	default	20180331_02:16
...
debian	jessie	amd64	default	20180330_22:42
...

It will prompt you the Distrubution, Release, then Architecture.

If you prefer the one line version:

[mrakotomandimby@arch-00 ~]$ sudo lxc-create -n test -t download -- --dist archlinux --release current --arch amd64

—This unsigned comment is by Rakotomandimby (talk) 19:30, 31 March 2018‎. Please sign your posts with ~~~~!

I updated the article, please review. Graysky (talk) 11:06, 1 April 2018 (UTC)

Append the section "Container creation" with archlinux-bootstrap images

Arch provides archlinux-bootstrap images that can be used when pacman is not available (on non-arch systems or when it is broken). In fact, I think it is the simplest method that other distros should use. I verified this method on Fedora 24 server system.

Any objections if I add this? Lisaev (talk) 02:39, 30 November 2016 (UTC)

Like the section above, this is not specific to Linux Containers. Bootstrapping Arch is already described in Install_from_existing_Linux#Method_A:_Using_the_bootstrap_image_.28recommended.29, making a container from that should be fairly trivial. Perhaps some links would be enough? -- Lahwaacz (talk) 06:27, 30 November 2016 (UTC)
Actually, I dodn't know about that section you mentioned :) Yes, then it should be mostly a link... I suggested the edit because on non-arch distros, the default lxc-archlinux template fails if pacman is not found. Of course, this is stupid because pacman is not needed at all! Unfortunately, the archlinux template is a bloated mess of features (even if pacman is present) because it does not have a dedicated maintainer who would block some features, and upstream LXC accepts almost any patch that is formally correct. Hence, I wanted to provide a 5-line set of instructions so that ppl who run non-arch hosts could deploy arch guests witjout building pacman... Lisaev (talk) 05:18, 2 December 2016 (UTC)

double tty

When login to the container with lxc-console -n CONTAINER_NAME a problem with a double tty presents.

The problem can be avoided using lxc-console -n CONTAINER_NAME -t 0 but i don't know if it is a good workaround.

I have added that to the page in the section Basic_usage.

More information on the problem:

Monty programador (talk) 09:54, 28 February 2017 (UTC)

dnsmasq

"You also need to install Dnsmasq which is a dependency for lxcbr0." This instruction is false, therefor this wiki needs an update. After weeks of trying via the Arch wiki and further asking in IRC, I could not get a working network. Today a Mastodon connection added a blog post with a simple gotcha "Do not install the dnsmasq package. Indeed, dnsmasq-base contains the binary and the doc, whereas dnsmasq also contains the service. However, lxc-net spawns its own dnsmasq process, so if you install dnsmasq, it will run on its own and cause a conflict with lxc-net". They go on to describe the exact error I returned when following the steps described in this Arch wiki.

Essentially DNSMASQ duplicates the call to the network socket. Disabling it, stopping it, and restoring resolv.conf (I'd previously edited to accommodate OpenNIC DNS's) resulted in a working bridged network to the LXC container.

Bunnybooboo (talk) 11:36, 17 February 2018 (UTC)