The configuration for a debian stretch container is the same, except the the file
/etc/network/interfaces will also describe eth0, but you only have to add the
description for eth1.
This seems to work.
+# eth0.network
+[Match]
+Name=eth0
+
+[Network]
+DHCP=ipv4
+# eth1.network
+[Match]
+Name=eth1
+
+[Network]
+DHCP=ipv4
+
+[DHCP]
+UseRoutes=false
+Once you assign the containers static ip addresses for their eth1
interfaces, you can use the /etc/hosts file on each container to make them
diff --git a/site/search/search_index.json b/site/search/search_index.json
index a0b636d..a560b69 100644
--- a/site/search/search_index.json
+++ b/site/search/search_index.json
@@ -27,7 +27,7 @@
},
{
"location": "/lxd_container_home_server_networking_for_dummies/",
- "text": "LXD Container Home Server Networking For Dummies\n\n\nWhy?\n\n\nIf you're going to operate a fleet of LXD containers for home\nentertainment, you probably want some of them exposed with their\nown ip addresses on your home network, so that you can use them\nas containerized servers for various applications.\n\n\nOthers containers, you might want to be inaccessable from the lan,\nin a natted subnet, where they can solicit connections to the\noutside world from within their natted subnet, but are not addressable\nfrom the outside. A database server that you connect a web app to, for\ninstance, or a web app that you have a reverse proxy in front of.\n\n\nBut these are two separate address spaces, so ideally all of the containers\nwould have a second interface of their own, by which they could connect\nto a third network, that would be a private network that all of the containers\ncan use to talk directly to each other (or the host machine).\n\n\nIt's pretty straightforward, you just have to glue all the pieces together.\n\n\nThree Part Overview.\n\n\n\n\n\n\nDefine and create some bridges. \n\n\n\n\n\n\nDefine profiles that combine the network\ninterfaces in different combinations. In addition to two\nbridges you will have a macvlan with which to expose the containers\nthat you want exposed, but the macvlan doesn't come into\nplay until here in step two when you define profiles. \n\n\n\n\n\n\nAssign each container which profile it should use,\nand then configure the containers to use the included\nnetwork interfaces correctly. \n\n\n\n\n\n\nBuild Sum Moar Bridges\n\n\nThe containers will all have two network interfaces from\ntheir own internal point of view, \neth0\n and \neth1\n. \n\n\nIn this\nscheme we create a bridge for a natted subnet and a bridge for\na non-natted subnet. All of the containers will connect to the\nnon-natted subnet on their second interface, \neth1\n, and some\nof the containers will connect to the natted subnet on their \nfirst interface \neth0\n. The containers that don't connect\nto the natted subnet will instead connect to a macvlan\non their first interface \neth0\n, but that isn't part of this\nstep.\n\n\nbridge for a natted subnet\n\n\nIf you haven't used lxd before, you'll want to run the command \nlxd init\n.\nBy default this creates exactly the bridge we want, called \nlxdbr0\n.\n\n\nOtherwise you would use the following command to create \nlxdbr0\n.\n\n\nlxc network create lxdbr0\n\n\n\n\nTo generate a table of all the existing interfaces.\n\n\nlxd network list\n\n\n\n\nThis bridge is for our natted subnet, so we just want to go with\nthe default configuration.\n\n\nlxc network show lxdbr0\n\n\n\n\nThis cats a yaml file where you can see the randomly\ngenerated network for \nlxdbr0\n.\n\n\nconfig:\n ipv4.address: 10.99.153.1/24\n ipv4.nat: \"true\"\n ipv6.address: fd42:211e:e008:954b::1/64\n ipv6.nat: \"true\"\ndescription: \"\"\nname: lxdbr0\ntype: bridge\nused_by: []\nmanaged: true\n\n\n\n\nbridge for a non-natted subnet\n\n\nCreate \nlxdbr1\n\n\nlxc network create lxdbr1\n\n\n\n\nUse the following commands to remove nat from \nlxdbr1.\n\n\nlxc network set lxdbr1 ipv4.nat false\nlxc network set lxdbr1 ipv6.nat false\n\n\n\n\nOf if you use this next command, your favourite\ntext editor will pop open, preloaded with the complete yaml file\nand you can edit the configuration there.\n\n\nlxc network edit lxdbr1\n\n\n\n\nEither way you're looking for a result such as the following.\nNotice that the randomly generated address space is different\nthat the one for \nlxdbr0\n, and that the *nat keys are set\nto \"false\".\n\n\nconfig:\n ipv4.address: 10.151.18.1/24\n ipv4.nat: \"false\"\n ipv6.address: fd42:89d4:f465:1b20::1/64\n ipv6.nat: \"false\"\ndescription: \"\"\nname: lxdbr1\ntype: bridge\nused_by: []\nmanaged: true\n\n\n\n\nProfiles\n\n\nrecycle the default\n\n\nWhen you first ran \nlxd init\n, that created a default profile.\nConfirm with the following.\n\n\nlxc profile list\n\n\n\n\nTo see what the default profile looks like.\n\n\nlxc profile show default\n\n\n\n\nconfig:\n environment.http_proxy: \"\"\n security.privileged: \"true\"\n user.network_mode: \"\"\ndescription: Default LXD profile\ndevices:\n eth0:\n nictype: bridged\n parent: lxdbr0\n type: nic\n root:\n path: /\n pool: default\n type: disk\nname: default\nused_by: []\n\n\n\n\nprofile the natted\n\n\nThe easiest way to create a new profile is start by copying another one.\n\n\nlxc profile copy default natted\n\n\n\n\nedit the new \nnatted\n profile\n\n\nlxc profile edit natted\n\n\n\n\nAnd add an \neth1\n interface attached to \nlxdbr1\n. \neth0\n and \neth1\n will\nbe the interfaces visible from the container's point of view.\n\n\nconfig:\n environment.http_proxy: \"\"\n security.privileged: \"true\"\n user.network_mode: \"\"\ndescription: Natted LXD profile\ndevices:\n eth0:\n nictype: bridged\n parent: lxdbr0\n type: nic\n eth1:\n nictype: bridged\n parent: lxdbr1\n type: nic\n root:\n path: /\n pool: default\n type: disk\nname: natted\nused_by: []\n\n\n\n\nAny container assigned to the \nnatted\n profile, will have an interface \neth0\n connected\nto a natted subnet, and a second interface \neth1\n connected to a non-natted subnet, with\na static ip on which it will be able to talk directly to the other containers and the host\nmachine.\n\n\nprofile the exposed\n\n\nCreate the \nexposed\n profile\n\n\nlxc profile copy natted exposed\n\n\n\n\nand edit the new \nexposed\n profile\n\n\nlxc profile edit exposed\n\n\n\n\nchange the nictype for \neth0\n from \nbridged\n to \nmacvlan\n, and the parent should be\nthe name of the physical ethernet connection on the host machine, instead of a bridge.\n\n\nconfig:\n environment.http_proxy: \"\"\n security.privileged: \"true\"\n user.network_mode: \"\"\ndescription: Exposed LXD profile\ndevices:\n eth0:\n nictype: macvlan\n parent: eno1\n type: nic\n eth1:\n nictype: bridged\n parent: lxdbr1\n type: nic\n root:\n path: /\n pool: default\n type: disk\nname: exposed\nused_by: []\n\n\n\n\nAny container assigned to the \nexposed\n profile, will have an interface \neth0\n connected\nto a macvlan, addressable from your lan, just like any other arbitrary computer on\nyour home network, and a second interface \neth1\n connected to a non-natted subnet, with\na static ip on which it will be able to talk directly to the other containers and the host\nmachine.\n\n\nAssign Containers to Profiles and configure them to connect correctly.\n\n\nThere are a lot of different ways that a Linux instance can solicit network services. So for\nnow I will just describe a method that will work here for a lxc container from ubuntu:16.04, as\nwell as a debian stretch container from images.linuxcontainers.org.\n\n\nStart a new container and assign the profile. We'll use an arbitrary whimsical container name,\n\nquick-joey\n. This process is the same for either the \nnatted\n profile or the \nexposed\n profile.\n\n\nlxc init ubuntu:16.04 quick-joey\n# assign the profile\nlxc profile assign quick-joey exposed\n# start quick-joey\nlxc start quick-joey\n# and start a bash shell\nlxc exec quick-joey bash\n\n\n\n\nWith either an ubuntu:16.04 container, or a debian stretch container, for either the \nnatted\n or\n\nexposed\n profile, because of all the above configuration work they will automatically connect on\ntheir \neth0\n interfaces and be able to talk to the internet. You need to edit \n/etc/network/interfaces\n,\nthe main difference being what that file looks like before you edit it.\n\n\nYou need to tell these containers how to connect to the non-natted subnet on \neth1\n.\n\n\nubuntu:16.04\n\n\nIf you start a shell on an ubuntu:16.04 container, you see that \n/etc/network/interfaces\n\ndescribes the loopback device for localhost, then sources \n/etc/network/interfaces.d/*.cfg\n where\nsome magical cloud-config jazz is going on. You just want to add a static ip description for \neth1\n\nto the file \n/etc/network/interfaces\n. And obviously take care that the static ip address you assign is\nunique and on the same subnet with \nlxdbr1\n.\n\n\nReminder: the address for \nlxdbr1\n is 10.151.18.1/24, (but it will be different on your machine).\n\n\nauto lo\niface lo inet loopback\n\nsource /etc/network/interfaces.d/*.cfg\n# what you add goes below here\nauto eth1\niface eth1 inet static\n address 10.151.18.123\n netmask 255.255.255.0\n broadcast 255.255.255.255 \n network 10.151.18.0\n\n\n\n\ndebian stretch\n\n\nThe configuration for a debian stretch container is the same, except the the file\n\n/etc/network/interfaces\n will also describe eth0, but you only have to add the \ndescription for eth1.\n\n\nthe /etc/hosts file\n\n\nOnce you assign the containers static ip addresses for their \neth1\n\ninterfaces, you can use the \n/etc/hosts\n file on each container to make them\naware of where the other containers and the host machine are.\n\n\nFor instance, if you want the container \nquick-joey\n to talk directly\nto the host machine, which will be at the ip address of \nlxdbr1\n, start a shell\non the container \nquick-joey\n\n\nlxc exec quick-joey bash\n\n\n\n\nand edit \n/etc/hosts\n\n\n# /etc/hosts\n10.151.18.1 mothership\n\n\n\n\nOr you have a container named \nfat-cinderella\n, that needs to be able to talk\ndirectly \nquick-joey\n.\n\n\nlxc exec fat-cinderella bash\nvim /etc/hosts\n\n\n\n\n# /etc/hosts\n10.151.18.123 quick-joey\n\n\n\n\netcetera",
+ "text": "LXD Container Home Server Networking For Dummies\n\n\nWhy?\n\n\nIf you're going to operate a fleet of LXD containers for home\nentertainment, you probably want some of them exposed with their\nown ip addresses on your home network, so that you can use them\nas containerized servers for various applications.\n\n\nOthers containers, you might want to be inaccessable from the lan,\nin a natted subnet, where they can solicit connections to the\noutside world from within their natted subnet, but are not addressable\nfrom the outside. A database server that you connect a web app to, for\ninstance, or a web app that you have a reverse proxy in front of.\n\n\nBut these are two separate address spaces, so ideally all of the containers\nwould have a second interface of their own, by which they could connect\nto a third network, that would be a private network that all of the containers\ncan use to talk directly to each other (or the host machine).\n\n\nIt's pretty straightforward, you just have to glue all the pieces together.\n\n\nThree Part Overview.\n\n\n\n\n\n\nDefine and create some bridges. \n\n\n\n\n\n\nDefine profiles that combine the network\ninterfaces in different combinations. In addition to two\nbridges you will have a macvlan with which to expose the containers\nthat you want exposed, but the macvlan doesn't come into\nplay until here in step two when you define profiles. \n\n\n\n\n\n\nAssign each container which profile it should use,\nand then configure the containers to use the included\nnetwork interfaces correctly. \n\n\n\n\n\n\nBuild Sum Moar Bridges\n\n\nThe containers will all have two network interfaces from\ntheir own internal point of view, \neth0\n and \neth1\n. \n\n\nIn this\nscheme we create a bridge for a natted subnet and a bridge for\na non-natted subnet. All of the containers will connect to the\nnon-natted subnet on their second interface, \neth1\n, and some\nof the containers will connect to the natted subnet on their \nfirst interface \neth0\n. The containers that don't connect\nto the natted subnet will instead connect to a macvlan\non their first interface \neth0\n, but that isn't part of this\nstep.\n\n\nbridge for a natted subnet\n\n\nIf you haven't used lxd before, you'll want to run the command \nlxd init\n.\nBy default this creates exactly the bridge we want, called \nlxdbr0\n.\n\n\nOtherwise you would use the following command to create \nlxdbr0\n.\n\n\nlxc network create lxdbr0\n\n\n\n\nTo generate a table of all the existing interfaces.\n\n\nlxd network list\n\n\n\n\nThis bridge is for our natted subnet, so we just want to go with\nthe default configuration.\n\n\nlxc network show lxdbr0\n\n\n\n\nThis cats a yaml file where you can see the randomly\ngenerated network for \nlxdbr0\n.\n\n\nconfig:\n ipv4.address: 10.99.153.1/24\n ipv4.nat: \"true\"\n ipv6.address: fd42:211e:e008:954b::1/64\n ipv6.nat: \"true\"\ndescription: \"\"\nname: lxdbr0\ntype: bridge\nused_by: []\nmanaged: true\n\n\n\n\nbridge for a non-natted subnet\n\n\nCreate \nlxdbr1\n\n\nlxc network create lxdbr1\n\n\n\n\nUse the following commands to remove nat from \nlxdbr1.\n\n\nlxc network set lxdbr1 ipv4.nat false\nlxc network set lxdbr1 ipv6.nat false\n\n\n\n\nOf if you use this next command, your favourite\ntext editor will pop open, preloaded with the complete yaml file\nand you can edit the configuration there.\n\n\nlxc network edit lxdbr1\n\n\n\n\nEither way you're looking for a result such as the following.\nNotice that the randomly generated address space is different\nthat the one for \nlxdbr0\n, and that the *nat keys are set\nto \"false\".\n\n\nconfig:\n ipv4.address: 10.151.18.1/24\n ipv4.nat: \"false\"\n ipv6.address: fd42:89d4:f465:1b20::1/64\n ipv6.nat: \"false\"\ndescription: \"\"\nname: lxdbr1\ntype: bridge\nused_by: []\nmanaged: true\n\n\n\n\nProfiles\n\n\nrecycle the default\n\n\nWhen you first ran \nlxd init\n, that created a default profile.\nConfirm with the following.\n\n\nlxc profile list\n\n\n\n\nTo see what the default profile looks like.\n\n\nlxc profile show default\n\n\n\n\nconfig:\n environment.http_proxy: \"\"\n security.privileged: \"true\"\n user.network_mode: \"\"\ndescription: Default LXD profile\ndevices:\n eth0:\n nictype: bridged\n parent: lxdbr0\n type: nic\n root:\n path: /\n pool: default\n type: disk\nname: default\nused_by: []\n\n\n\n\nprofile the natted\n\n\nThe easiest way to create a new profile is start by copying another one.\n\n\nlxc profile copy default natted\n\n\n\n\nedit the new \nnatted\n profile\n\n\nlxc profile edit natted\n\n\n\n\nAnd add an \neth1\n interface attached to \nlxdbr1\n. \neth0\n and \neth1\n will\nbe the interfaces visible from the container's point of view.\n\n\nconfig:\n environment.http_proxy: \"\"\n security.privileged: \"true\"\n user.network_mode: \"\"\ndescription: Natted LXD profile\ndevices:\n eth0:\n nictype: bridged\n parent: lxdbr0\n type: nic\n eth1:\n nictype: bridged\n parent: lxdbr1\n type: nic\n root:\n path: /\n pool: default\n type: disk\nname: natted\nused_by: []\n\n\n\n\nAny container assigned to the \nnatted\n profile, will have an interface \neth0\n connected\nto a natted subnet, and a second interface \neth1\n connected to a non-natted subnet, with\na static ip on which it will be able to talk directly to the other containers and the host\nmachine.\n\n\nprofile the exposed\n\n\nCreate the \nexposed\n profile\n\n\nlxc profile copy natted exposed\n\n\n\n\nand edit the new \nexposed\n profile\n\n\nlxc profile edit exposed\n\n\n\n\nchange the nictype for \neth0\n from \nbridged\n to \nmacvlan\n, and the parent should be\nthe name of the physical ethernet connection on the host machine, instead of a bridge.\n\n\nconfig:\n environment.http_proxy: \"\"\n security.privileged: \"true\"\n user.network_mode: \"\"\ndescription: Exposed LXD profile\ndevices:\n eth0:\n nictype: macvlan\n parent: eno1\n type: nic\n eth1:\n nictype: bridged\n parent: lxdbr1\n type: nic\n root:\n path: /\n pool: default\n type: disk\nname: exposed\nused_by: []\n\n\n\n\nAny container assigned to the \nexposed\n profile, will have an interface \neth0\n connected\nto a macvlan, addressable from your lan, just like any other arbitrary computer on\nyour home network, and a second interface \neth1\n connected to a non-natted subnet, with\na static ip on which it will be able to talk directly to the other containers and the host\nmachine.\n\n\nAssign Containers to Profiles and configure them to connect correctly.\n\n\nThere are a lot of different ways that a Linux instance can solicit network services. So for\nnow I will just describe a method that will work here for a lxc container from ubuntu:16.04, as\nwell as a debian stretch container from images.linuxcontainers.org.\n\n\nStart a new container and assign the profile. We'll use an arbitrary whimsical container name,\n\nquick-joey\n. This process is the same for either the \nnatted\n profile or the \nexposed\n profile.\n\n\nlxc init ubuntu:16.04 quick-joey\n# assign the profile\nlxc profile assign quick-joey exposed\n# start quick-joey\nlxc start quick-joey\n# and start a bash shell\nlxc exec quick-joey bash\n\n\n\n\nWith either an ubuntu:16.04 container, or a debian stretch container, for either the \nnatted\n or\n\nexposed\n profile, because of all the above configuration work they will automatically connect on\ntheir \neth0\n interfaces and be able to talk to the internet. You need to edit \n/etc/network/interfaces\n,\nthe main difference being what that file looks like before you edit it.\n\n\nYou need to tell these containers how to connect to the non-natted subnet on \neth1\n.\n\n\nubuntu:16.04\n\n\nIf you start a shell on an ubuntu:16.04 container, you see that \n/etc/network/interfaces\n\ndescribes the loopback device for localhost, then sources \n/etc/network/interfaces.d/*.cfg\n where\nsome magical cloud-config jazz is going on. You just want to add a static ip description for \neth1\n\nto the file \n/etc/network/interfaces\n. And obviously take care that the static ip address you assign is\nunique and on the same subnet with \nlxdbr1\n.\n\n\nReminder: the address for \nlxdbr1\n is 10.151.18.1/24, (but it will be different on your machine).\n\n\nauto lo\niface lo inet loopback\n\nsource /etc/network/interfaces.d/*.cfg\n# what you add goes below here\nauto eth1\niface eth1 inet static\n address 10.151.18.123\n netmask 255.255.255.0\n broadcast 255.255.255.255 \n network 10.151.18.0\n\n\n\n\ndebian stretch\n\n\nThe configuration for a debian stretch container is the same, except the the file\n\n/etc/network/interfaces\n will also describe eth0, but you only have to add the \ndescription for eth1.\n\n\nsystemd-networkd\n\n\nThis seems to work.\n\n\n# eth0.network\n[Match]\nName=eth0\n\n[Network]\nDHCP=ipv4\n\n\n\n\n# eth1.network\n[Match]\nName=eth1\n\n[Network]\nDHCP=ipv4\n\n[DHCP]\nUseRoutes=false\n\n\n\n\nthe /etc/hosts file\n\n\nOnce you assign the containers static ip addresses for their \neth1\n\ninterfaces, you can use the \n/etc/hosts\n file on each container to make them\naware of where the other containers and the host machine are.\n\n\nFor instance, if you want the container \nquick-joey\n to talk directly\nto the host machine, which will be at the ip address of \nlxdbr1\n, start a shell\non the container \nquick-joey\n\n\nlxc exec quick-joey bash\n\n\n\n\nand edit \n/etc/hosts\n\n\n# /etc/hosts\n10.151.18.1 mothership\n\n\n\n\nOr you have a container named \nfat-cinderella\n, that needs to be able to talk\ndirectly \nquick-joey\n.\n\n\nlxc exec fat-cinderella bash\nvim /etc/hosts\n\n\n\n\n# /etc/hosts\n10.151.18.123 quick-joey\n\n\n\n\netcetera",
"title": "LXD Container Home Server Networking For Dummies"
},
{
@@ -95,6 +95,11 @@
"text": "The configuration for a debian stretch container is the same, except the the file /etc/network/interfaces will also describe eth0, but you only have to add the \ndescription for eth1.",
"title": "debian stretch"
},
+ {
+ "location": "/lxd_container_home_server_networking_for_dummies/#systemd-networkd",
+ "text": "This seems to work. # eth0.network\n[Match]\nName=eth0\n\n[Network]\nDHCP=ipv4 # eth1.network\n[Match]\nName=eth1\n\n[Network]\nDHCP=ipv4\n\n[DHCP]\nUseRoutes=false",
+ "title": "systemd-networkd"
+ },
{
"location": "/lxd_container_home_server_networking_for_dummies/#the-etchosts-file",
"text": "Once you assign the containers static ip addresses for their eth1 \ninterfaces, you can use the /etc/hosts file on each container to make them\naware of where the other containers and the host machine are. For instance, if you want the container quick-joey to talk directly\nto the host machine, which will be at the ip address of lxdbr1 , start a shell\non the container quick-joey lxc exec quick-joey bash and edit /etc/hosts # /etc/hosts\n10.151.18.1 mothership Or you have a container named fat-cinderella , that needs to be able to talk\ndirectly quick-joey . lxc exec fat-cinderella bash\nvim /etc/hosts # /etc/hosts\n10.151.18.123 quick-joey etcetera",
diff --git a/site/sitemap.xml b/site/sitemap.xml
index 06fcd08..7abebd5 100644
--- a/site/sitemap.xml
+++ b/site/sitemap.xml
@@ -4,7 +4,7 @@