From 3f2df33444034a8710f070fae7423f0f152ffe60 Mon Sep 17 00:00:00 2001 From: Trent Palmer Date: Thu, 29 Jun 2017 16:11:32 -0700 Subject: [PATCH] extend docs/nspawn.md --- docs/nspawn.md | 37 ++++++++++++++++++++++++++++++++++- site/index.html | 2 +- site/mkdocs/search_index.json | 15 +++++++++----- site/nspawn/index.html | 36 +++++++++++++++++++++++++++++++++- 4 files changed, 82 insertions(+), 8 deletions(-) diff --git a/docs/nspawn.md b/docs/nspawn.md index 8189499..52b09da 100644 --- a/docs/nspawn.md +++ b/docs/nspawn.md @@ -2,6 +2,8 @@ [This Link For Arch Linux Wiki for Nspawn Containers](https://wiki.archlinux.org/index.php/Systemd-nspawn) +I like the idea of starting with the easy containers first. + ### Create a FileSystem ```bash @@ -24,6 +26,15 @@ At this point you might want to copy over some configs to save time later. ```bash systemd-nspawn -b -D passwd +# assuming you copied over /etc/locale.gen +locale-gen +# set timezone +timedatectl set-timezone +# enable network time +timedatectl set-ntp 1 +# enable networking +systemctl enable systemd-networkd +systemctl enable systemd-resolved poweroff # if you want to nat the container add *-n* flag systemd-nspawn -b -D -n @@ -32,6 +43,7 @@ systemd-nspawn -b -D -n --bind=/var/cache/pacman/pkg ``` ### Networking +Here's a link that skips ahead to [Automatically Starting the Container](#automatically-starting-the-container) On Arch, assuming you have systemd-networkd and systemd-resolved set up correctly, networking from the host end of things should @@ -52,7 +64,7 @@ Kind=bridge Name=br0 [Network] -Address=10.0.55.1/24 +Address=10.0.55.1/24 # arbitrarily pick a subnet range to taste DHCPServer=yes IPMasquerade=yes ``` @@ -70,6 +82,8 @@ systemd-nspawn -b -D --network-bridge=br0 --bind=/var/cache/pacman/p ``` ### Automatically Starting the Container +Here's a link back up to [Networking](#networking) +in case you previously skipped ahead. There are two ways to automate starting the container. You can override `systemd-nspawn@.service` or create an *nspawn* file. @@ -112,6 +126,9 @@ machinectl shell bash ``` +This would be a good time to check for network and name resolution, +symlink resolv.conf if need be. + ### Initial Configuration Inside The Container ```bash @@ -131,3 +148,21 @@ ping -c 3 google.com ``` [If you want to change the locale](https://wiki.archlinux.org/index.php/locale) + +## Final Observations +* You can start/stop nspawn containers with `machinectl` command. +* You can start nspawn containers with `systemd-nspawn` command. +* You can configure the systemd service for a container with @nspawn.service file override +* Or you can configure an nspawn container with a dot.nspawn file + +But in regards to the above list +I have noticed differences in behaviour, +in some scenarios, concerning file attributes +for bind mounts. + +Another curiosity: when you have nspawn containers natted on VirtualEthernet connections, +they might be able to ping each other at 10.x.y.z, but not resolve each other. But they might +be able to resolve each other if they are all connected to the same bridge interface or nspawn +network zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z, +or fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers +to talk to each other. But I intend to look into this some more. diff --git a/site/index.html b/site/index.html index 3da282b..60d0c68 100644 --- a/site/index.html +++ b/site/index.html @@ -174,5 +174,5 @@ diff --git a/site/mkdocs/search_index.json b/site/mkdocs/search_index.json index 1e029ed..70e113d 100644 --- a/site/mkdocs/search_index.json +++ b/site/mkdocs/search_index.json @@ -142,12 +142,12 @@ }, { "location": "/nspawn/", - "text": "Nspawn Containers\n\n\nThis Link For Arch Linux Wiki for Nspawn Containers\n\n\nCreate a FileSystem\n\n\ncd /var/lib/machines\n# create a directory\nmkdir \n# use pacstrap to create a file system\npacstrap -i -c -d base --ignore linux\n\n\n\n\nAt this point you might want to copy over some configs to save time later.\n\n\n\n\n/etc/locale.conf\n\n\n/root/.bashrc\n\n\n/etc/locale.gen\n\n\n\n\nFirst boot and create root password\n\n\nsystemd-nspawn -b -D \npasswd\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D -n --bind=/var/cache/pacman/pkg\n\n\n\n\nNetworking\n\n\nOn Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work.\n\nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done.\n\n\n# /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge\n\n\n\n\n# /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24\nDHCPServer=yes\nIPMasquerade=yes\n\n\n\n\nNotice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the \nsystemd-nspawn\n\ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other.\n\n\n# first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D --network-bridge=br0 --bind=/var/cache/pacman/pkg\n\n\n\n\nAutomatically Starting the Container\n\n\nThere are two ways to automate starting the container. You can override\n\nsystemd-nspawn@.service\n or create an \nnspawn\n file. \n\n\nFirst enable machines.target\n\n\n# to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@.service\n\n\n\n\nEdit \n/etc/systemd/system/systemd-nspawn@.service\n to add the \nsystemd-nspawn\n options\nyou want to the \nExecStart\n command.\n\n\nOr create \n/etc/systemd/nspawn/.nspawn\n\n\n# /etc/systemd/nspawn/.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0\n\n\n\n\n# /etc/systemd/nspawn/.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though\n\n\n\n\n# in either case\nsystemctl start/enable systemd-nspawn@\n# to get a shell\nmachinectl shell \n# and then to get an environment\nbash\n\n\n\n\nInitial Configuration Inside The Container\n\n\n# set time zone if you don't want UTC\ntimedatectl set-timezone \n# enable ntp, networktime\ntimedatectl set-ntp 1\n# enable networking from inside the container\nsystemctl enable systemd-networkd\nsystemctl start systemd-networkd\nsystemctl enable systemd-resolved\nsystemctl start systemd-resolved\nrm /etc/resolv.conf \nln -s /run/systemd/resolve/resolv.conf /etc/\n# ping google\nping -c 3 google.com\n\n\n\n\nIf you want to change the locale", + "text": "Nspawn Containers\n\n\nThis Link For Arch Linux Wiki for Nspawn Containers\n\n\nI like the idea of starting with the easy containers first.\n\n\nCreate a FileSystem\n\n\ncd /var/lib/machines\n# create a directory\nmkdir \n# use pacstrap to create a file system\npacstrap -i -c -d base --ignore linux\n\n\n\n\nAt this point you might want to copy over some configs to save time later.\n\n\n\n\n/etc/locale.conf\n\n\n/root/.bashrc\n\n\n/etc/locale.gen\n\n\n\n\nFirst boot and create root password\n\n\nsystemd-nspawn -b -D \npasswd\n# assuming you copied over /etc/locale.gen\nlocale-gen\n# set timezone\ntimedatectl set-timezone \n# enable network time\ntimedatectl set-ntp 1\n# enable networking\nsystemctl enable systemd-networkd\nsystemctl enable systemd-resolved\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D -n --bind=/var/cache/pacman/pkg\n\n\n\n\nNetworking\n\n\nHere's a link that skips ahead to \nAutomatically Starting the Container\n\n\nOn Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work.\n\nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done.\n\n\n# /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge\n\n\n\n\n# /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24 # arbitrarily pick a subnet range to taste\nDHCPServer=yes\nIPMasquerade=yes\n\n\n\n\nNotice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the \nsystemd-nspawn\n\ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other.\n\n\n# first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D --network-bridge=br0 --bind=/var/cache/pacman/pkg\n\n\n\n\nAutomatically Starting the Container\n\n\nHere's a link back up to \nNetworking\n\nin case you previously skipped ahead.\n\n\nThere are two ways to automate starting the container. You can override\n\nsystemd-nspawn@.service\n or create an \nnspawn\n file. \n\n\nFirst enable machines.target\n\n\n# to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@.service\n\n\n\n\nEdit \n/etc/systemd/system/systemd-nspawn@.service\n to add the \nsystemd-nspawn\n options\nyou want to the \nExecStart\n command.\n\n\nOr create \n/etc/systemd/nspawn/.nspawn\n\n\n# /etc/systemd/nspawn/.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0\n\n\n\n\n# /etc/systemd/nspawn/.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though\n\n\n\n\n# in either case\nsystemctl start/enable systemd-nspawn@\n# to get a shell\nmachinectl shell \n# and then to get an environment\nbash\n\n\n\n\nThis would be a good time to check for network and name resolution,\nsymlink resolv.conf if need be.\n\n\nInitial Configuration Inside The Container\n\n\n# set time zone if you don't want UTC\ntimedatectl set-timezone \n# enable ntp, networktime\ntimedatectl set-ntp 1\n# enable networking from inside the container\nsystemctl enable systemd-networkd\nsystemctl start systemd-networkd\nsystemctl enable systemd-resolved\nsystemctl start systemd-resolved\nrm /etc/resolv.conf \nln -s /run/systemd/resolve/resolv.conf /etc/\n# ping google\nping -c 3 google.com\n\n\n\n\nIf you want to change the locale\n\n\nFinal Observations\n\n\n\n\nYou can start/stop nspawn containers with \nmachinectl\n command. \n\n\nYou can start nspawn containers with \nsystemd-nspawn\n command.\n\n\nYou can configure the systemd service for a container with @nspawn.service file override\n\n\nOr you can configure an nspawn container with a dot.nspawn file\n\n\n\n\nBut in regards to the above list\nI have noticed differences in behaviour,\nin some scenarios, concerning file attributes\nfor bind mounts.\n\n\nAnother curiosity: when you have nspawn containers natted on VirtualEthernet connections,\nthey might be able to ping each other at 10.x.y.z, but not resolve each other. But they might\nbe able to resolve each other if they are all connected to the same bridge interface or nspawn\nnetwork zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,\nor fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers\nto talk to each other. But I intend to look into this some more.", "title": "Nspawn" }, { "location": "/nspawn/#nspawn-containers", - "text": "This Link For Arch Linux Wiki for Nspawn Containers", + "text": "This Link For Arch Linux Wiki for Nspawn Containers I like the idea of starting with the easy containers first.", "title": "Nspawn Containers" }, { @@ -157,17 +157,17 @@ }, { "location": "/nspawn/#first-boot-and-create-root-password", - "text": "systemd-nspawn -b -D \npasswd\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D -n --bind=/var/cache/pacman/pkg", + "text": "systemd-nspawn -b -D \npasswd\n# assuming you copied over /etc/locale.gen\nlocale-gen\n# set timezone\ntimedatectl set-timezone \n# enable network time\ntimedatectl set-ntp 1\n# enable networking\nsystemctl enable systemd-networkd\nsystemctl enable systemd-resolved\npoweroff\n# if you want to nat the container add *-n* flag\nsystemd-nspawn -b -D -n\n# and to bind mount the package cache\nsystemd-nspawn -b -D -n --bind=/var/cache/pacman/pkg", "title": "First boot and create root password" }, { "location": "/nspawn/#networking", - "text": "On Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work. \nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done. # /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge # /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24\nDHCPServer=yes\nIPMasquerade=yes Notice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the systemd-nspawn \ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other. # first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D --network-bridge=br0 --bind=/var/cache/pacman/pkg", + "text": "Here's a link that skips ahead to Automatically Starting the Container On Arch, assuming you have systemd-networkd and systemd-resolved\nset up correctly, networking from the host end of things should\njust work. \nHowever on Linode it does not. What does work on Linode is to create\na bridge interface. Two files for br0 will get the job done. # /etc/systemd/network/50-br0.netdev\n[NetDev]\nName=br0\nKind=bridge # /etc/systemd/network/50-br0.netdev\n[Match]\nName=br0\n\n[Network]\nAddress=10.0.55.1/24 # arbitrarily pick a subnet range to taste\nDHCPServer=yes\nIPMasquerade=yes Notice how the configuration file tells systemd-networkd to offer\nDHCP service and to perform masquerade. You can modify the systemd-nspawn \ncommand to use the bridge interface. Every container attached to this bridge\nwill be on the same subnet and able to talk to each other. # first restart systemd-networkd to bring up the new bridge interface\nsystemctl restart systemd-networkd\n# and add --network-bridge=br0 to systemd-nspawn command\nsystemd-nspawn -b -D --network-bridge=br0 --bind=/var/cache/pacman/pkg", "title": "Networking" }, { "location": "/nspawn/#automatically-starting-the-container", - "text": "There are two ways to automate starting the container. You can override systemd-nspawn@.service or create an nspawn file. First enable machines.target # to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@.service Edit /etc/systemd/system/systemd-nspawn@.service to add the systemd-nspawn options\nyou want to the ExecStart command. Or create /etc/systemd/nspawn/.nspawn # /etc/systemd/nspawn/.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0 # /etc/systemd/nspawn/.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though # in either case\nsystemctl start/enable systemd-nspawn@\n# to get a shell\nmachinectl shell \n# and then to get an environment\nbash", + "text": "Here's a link back up to Networking \nin case you previously skipped ahead. There are two ways to automate starting the container. You can override systemd-nspawn@.service or create an nspawn file. First enable machines.target # to override the systemd-nspawn@.service file\ncp /lib/systemd/system/systemd-nspawn@.service /etc/systemd/system/systemd-nspawn@.service Edit /etc/systemd/system/systemd-nspawn@.service to add the systemd-nspawn options\nyou want to the ExecStart command. Or create /etc/systemd/nspawn/.nspawn # /etc/systemd/nspawn/.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nBridge=br0 # /etc/systemd/nspawn/.nspawn\n[Files]\nBind=/var/cache/pacman/pkg\n\n[Network]\nVirtualEthernet=1 # this seems to be the default sometimes, though # in either case\nsystemctl start/enable systemd-nspawn@\n# to get a shell\nmachinectl shell \n# and then to get an environment\nbash This would be a good time to check for network and name resolution,\nsymlink resolv.conf if need be.", "title": "Automatically Starting the Container" }, { @@ -175,6 +175,11 @@ "text": "# set time zone if you don't want UTC\ntimedatectl set-timezone \n# enable ntp, networktime\ntimedatectl set-ntp 1\n# enable networking from inside the container\nsystemctl enable systemd-networkd\nsystemctl start systemd-networkd\nsystemctl enable systemd-resolved\nsystemctl start systemd-resolved\nrm /etc/resolv.conf \nln -s /run/systemd/resolve/resolv.conf /etc/\n# ping google\nping -c 3 google.com If you want to change the locale", "title": "Initial Configuration Inside The Container" }, + { + "location": "/nspawn/#final-observations", + "text": "You can start/stop nspawn containers with machinectl command. You can start nspawn containers with systemd-nspawn command. You can configure the systemd service for a container with @nspawn.service file override Or you can configure an nspawn container with a dot.nspawn file But in regards to the above list\nI have noticed differences in behaviour,\nin some scenarios, concerning file attributes\nfor bind mounts. Another curiosity: when you have nspawn containers natted on VirtualEthernet connections,\nthey might be able to ping each other at 10.x.y.z, but not resolve each other. But they might\nbe able to resolve each other if they are all connected to the same bridge interface or nspawn\nnetwork zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z,\nor fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers\nto talk to each other. But I intend to look into this some more.", + "title": "Final Observations" + }, { "location": "/arch_redis_nspawn/", "text": "Quick Dirty Redis Nspawn Container on Arch Linux\n\n\nRefer to the \nNspawn\n page for setting up the nspawn container,\ninstall redis, and start/enable redis.service.\nOnce you have the container running, it seems all you have to do to get\nthings working in a container subnet is to change the bind address.\n\n\n# /etc/redis.conf\n# bind 127.0.0.1\nbind 0.0.0.0\n\n\n\n\nyou can nmap port 6379, be sure to restart redis\n\n\nAgain I would refer you to the Arch Wiki", diff --git a/site/nspawn/index.html b/site/nspawn/index.html index 456a77a..c069075 100644 --- a/site/nspawn/index.html +++ b/site/nspawn/index.html @@ -76,6 +76,8 @@
  • Initial Configuration Inside The Container
    • +
  • Final Observations
    • + @@ -126,6 +128,7 @@

    Nspawn Containers

    This Link For Arch Linux Wiki for Nspawn Containers

    +

    I like the idea of starting with the easy containers first.

    Create a FileSystem

    cd /var/lib/machines
 # create a directory
@@ -143,6 +146,15 @@ pacstrap -i -c -d <container> base --ignore linux
 
    First boot and create root password
    
 
    systemd-nspawn -b -D <container>
 passwd
+# assuming you copied over /etc/locale.gen
+locale-gen
+# set timezone
+timedatectl set-timezone <timezone>
+# enable network time
+timedatectl set-ntp 1
+# enable networking
+systemctl enable systemd-networkd
+systemctl enable systemd-resolved
 poweroff
 # if you want to nat the container add *-n* flag
 systemd-nspawn -b -D <container> -n
@@ -151,6 +163,7 @@ systemd-nspawn -b -D <container> -n --bind=/var/cache/pacman/pkg
 
    
 
 
    Networking
    
+
    Here's a link that skips ahead to Automatically Starting the Container
    
 
    On Arch, assuming you have systemd-networkd and systemd-resolved
 set up correctly, networking from the host end of things should
 just work.
    
@@ -167,7 +180,7 @@ Kind=bridge
 Name=br0
 
 [Network]
-Address=10.0.55.1/24
+Address=10.0.55.1/24 # arbitrarily pick a subnet range to taste
 DHCPServer=yes
 IPMasquerade=yes
    @@ -183,6 +196,8 @@ systemd-nspawn -b -D <container> --network-bridge=br0 --bind=/var/cache/pa

    Automatically Starting the Container

    +

    Here's a link back up to Networking +in case you previously skipped ahead.

    There are two ways to automate starting the container. You can override systemd-nspawn@.service or create an nspawn file.

    First enable machines.target

    @@ -217,6 +232,8 @@ machinectl shell <container> bash +

    This would be a good time to check for network and name resolution, +symlink resolv.conf if need be.

    Initial Configuration Inside The Container

    # set time zone if you don't want UTC
 timedatectl set-timezone <timezone>
@@ -234,6 +251,23 @@ ping -c 3 google.com

    If you want to change the locale

    +

    Final Observations

    +
      +
    • You can start/stop nspawn containers with machinectl command.
      • +
    • You can start nspawn containers with systemd-nspawn command.
      • +
    • You can configure the systemd service for a container with @nspawn.service file override
      • +
    • Or you can configure an nspawn container with a dot.nspawn file
      • +
    +

    But in regards to the above list +I have noticed differences in behaviour, +in some scenarios, concerning file attributes +for bind mounts.

    +

    Another curiosity: when you have nspawn containers natted on VirtualEthernet connections, +they might be able to ping each other at 10.x.y.z, but not resolve each other. But they might +be able to resolve each other if they are all connected to the same bridge interface or nspawn +network zone, but will randomly resolve each other in any of the 10.x.y.z, 169.x.y.z, +or fe80::....:....:....%host (ipv6 local) spaces, which would complicate configuring the containers +to talk to each other. But I intend to look into this some more.