Keith C. Perry on 20 Apr 2016 12:37:38 -0700


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] [plug-announce] TOMORROW - Tue, Apr 19, 2016: PLUG North - "Linux Containers" by Jason Plum and Rich Freeman (*6:30 pm* at CoreDial in Blue Bell)


Yea that's pretty much what I have on my Arch systems (accept I match on en*).  Slightly more work compared to traditional bridge setups but I figured I need to start getting into some systemd stuff at some point.

One thing that should be mentioned in that regard is the use of the "networkctl" or "networkctl status" which has a particularly nice output.

Another thing mentioned was the of ephemeral containers and the need to use btrfs.  So to try that out I attempted Example 5 in the man page which would simply be booting a snapshot of the current host system

systemd-nspawn -xbD /

That fails with

Failed to create snapshot /.#machine.4fdf96bbc0c40191 from /: Inappropriate ioctl for device

This is indeed not using btrfs.  This seems like a design mistake since it forces the use of a particular filesystem which for now is not even production quality.  A more agnostic and production quality requirement would have been to hook into LVM and use its snap-shotting facilities.  I suspect somewhere out there is a conversation about why this was not done but I didn't check.

Also, so that others are aware.  If you are going to boot from an image.  Your image needs to use a GPT disk structure or make use of a single MBR boot partition.  Here's an example of one of my Kali USB sticks failing to boot  :(

systemd-nspawn -bi /dev/sdb
Failed to identify root partition in disk image
    /dev/sdb
Note that the disk image needs to either contain only a single MBR partition of
type 0x83 that is marked bootable, or a single GPT partition of type 0FC63DAF-8483-4772-8E79-3D69D8477DE4 or follow
    http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
to be bootable with systemd-nspawn.

My standards do not allow for stand alone boot partitions so for me this reinforces the idea that its time to start moving to GPT partitioning generally.


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
Keith C. Perry, MS E.E. 
Owner, DAO Technologies LLC 
(O) +1.215.525.4165 x2033 
(M) +1.215.432.5167 
www.daotechnologies.com

----- Original Message -----
From: "Rich Freeman" <r-plug@thefreemanclan.net>
To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Wednesday, April 20, 2016 7:57:37 AM
Subject: Re: [PLUG] [plug-announce] TOMORROW - Tue, Apr 19, 2016: PLUG North - "Linux Containers" by Jason Plum and Rich Freeman (*6:30 pm* at CoreDial in Blue Bell)

Thanks to all who came out.  As I said when I started - we could have
easily chatted about containers all week long.  Hopefully everybody
was able to grok the concepts at least.

Slides can be found at:
https://docs.google.com/presentation/d/1qIn3818JCzCL8lcRP8GZXS_XqH_HkvfD5lrQxttUcV0/edit?usp=sharing

I'm sure a video will be up shortly.

One of the questions that came up at the end was a quick recipe for
setting up a network bridge in systemd-networkd so that you could
easily run containers on their own interfaces.  This recipe will also
work for kvm (which is why my bridge is named brkvm - I just recycled
my kvm bridge for nspawn).

Inside /etc/systemd/network create the following files:
cat brkvm.netdev
[NetDev]
Name=brkvm
Kind=bridge

cat brkvm.network
[Match]
Name=brkvm

[Network]
DNS=192.168.0.5
Address=192.168.0.5/24
Gateway=192.168.0.21

cat eth-bridge.network
[Match]
Name=e*

[Network]
Bridge=brkvm

Note that the above is for a static interface.  You could replace the
DNS/Address/Gateway lines with DHCP=yes and just use DHCP.  My
container host is also my dhcp server.

You'll need to tweak the last one if this box is also a router, unless
you wanted to bridge your multiple external interfaces.  You'd just
have multiple network interface files and give each a more specific
name file with their individual configurations.  The match on name=e*
covers both the traditional eth0 and the newer udev persistent names.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug