Yesterday, I delivered a talk to a lively audience at ContainerWorld in Santa Clara, California.
If I measured "the most interesting slides" by counting "the number of people who took a picture of the slide", then by far "the most interesting slides" are slides 8-11, which pose an answer the question:
"Should I run my PaaS on top of my IaaS, or my IaaS on top of my PaaS"?
In the Ubuntu world, that answer is super easy -- however you like! At Canonical, we're happy to support:
In all cases, the underlying substrate is perfectly consistent:
you've got 1 to N physical or virtual machines
which are dynamically provisioned by MAAS or your cloud provider
running stable, minimal, secure Ubuntu server image
carved up into fast, efficient, independently addressable LXD machine containers
With that as your base, we'll easily to conjure-up a Kubernetes, an OpenStack, or both. And once you have a Kubernetes or OpenStack, we'll gladly conjure-up one inside the other.
As always, I'm happy to share my slides with you here. You're welcome to download the PDF, or flip through the embedded slides below.
Or, if you're feeling more enterprisey and want the full experience, try:
$ conjure-up canonical-kubernetes
I hope to meet some of you at ContainerWorld in Santa Clara next week. Marco Ceppi and I are running a Kubernetes installfest workshop on Tuesday, February 21, 2017, from 3pm - 4:30pm. I can guarantee that every single person who attends will succeed in deploying their own Kubernetes cluster to a public cloud (AWS, Azure, or Google), or to their Ubuntu laptop or VM.
Finally, I invite you to check out this 30-minute podcast with David Daly, from DevOpsChat, where we talked quite a bit about Containers and Kubernetes and the experience we're working on in Ubuntu...
I've been one of DD-WRT's biggest fans, for more than 10 years. I've always flashed my router with custom firmware, fine-tuned my wired and wireless networks, and locked down a VPN back home. I've genuinely always loved tinkering with network gear.
A couple of weeks ago, I decided to re-deploy my home network. I've been hearing about Ubiquiti Networks from my colleagues at Canonical, where we use Ubiquiti gear for our many and varied company events. Moreover, it seems a number of us have taken to running the same kits in our home offices.
There's something quite unique about the UniFi Controller -- the server that "controls" your router, gateway, and access points. Rather than being built into the USG itself, you run the server somewhere else.
Sure you can buy their hardware appliance (which I'm sure is nice). But you can just as easily run it on an Ubuntu machine yourself. That machine could be a physical machine on your network, a virtual machine locally or in the cloud, or it could be an LXD machine container.
I opted for the latter. I'm happily running the UniFi Controller in a LXD machine container, and it's easy for you to setup, too.
I'm running Ubuntu 16.04 LTS 64-bit on an Intel NUC somewhere in my house. It happens to be running Ubuntu Desktop, as it's attached to one of the TVs in my house, as a media playing device. In it's spare time, it's a server I use for LXD, Docker, and other development purposes.
I've configured the network on the machine to "bridge" LXD to my USG router, which happens to be running DHCP and DNS. I'm going to move that to a MAAS server, but that's a post for another day.
Here's /etc/network/interfaces on that machine:
kirkland@masterbr:~⟫ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet dhcp
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
So eth0 is bridged, to br0. ifconfig looks like this:
It's important to notice that this container drew an IP address on my 10.0.0.0/24 LAN. It will need this, to detect, federate, and manage the Ubiquiti hardware.
Now, let's exec into it, and import our SSH keys, so that we can SSH into it later.
kirkland@masterbr:~⟫ lxc exec unifi-controller bash
root@unifi-controller:~# ssh-import-id kirkland
2016-12-09 21:56:36,558 INFO Authorized key ['4096', 'd3:dd:e4:72:25:18:f3:ea:93:10:1a:5b:9f:bc:ef:5e', 'kirkland@x220', '(RSA)']
2016-12-09 21:56:36,568 INFO Authorized key ['2048', '69:57:f9:b6:11:73:48:ae:11:10:b5:18:26:7c:15:9d', 'kirkland@mac', '(RSA)']
2016-12-09 21:56:36,569 INFO [2] SSH keys [Authorized]
root@unifi-controller:~# exit
exit
kirkland@masterbr:~⟫ ssh root@10.0.0.183
The authenticity of host '10.0.0.183 (10.0.0.183)' can't be established.
ECDSA key fingerprint is SHA256:we0zAxifd0dcnAE2tVE53NFbQCop61f+MmHGsyGj0Xg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.0.183' (ECDSA) to the list of known hosts.
root@unifi-controller:~#
Now, let's add the Unifi repository and install the deb and all its dependencies. It's a big pile of Java and MongoDB, which I'm happy to keep nicely "contained" in this LXD instance!
root@unifi-controller:~# echo deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti
deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti
root@unifi-controller:~# echo "deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti" | sudo tee -a /etc/apt/sources.list
deb http://www.ubnt.com/downloads/unifi/debian stable ubiquiti
root@unifi-controller:~# apt-key adv --keyserver keyserver.ubuntu.com --recv C0A52C50
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.hhgdd0ssJQ --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv C0A52C50
gpg: requesting key C0A52C50 from hkp server keyserver.ubuntu.com
gpg: key C0A52C50: public key "UniFi Developers " imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
root@unifi-controller:~# apt update >/dev/null 2>&1
root@unifi-controller:~# apt install unifi
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
os-prober
Use 'apt-get autoremove' to remove it.
The following extra packages will be installed:
binutils ca-certificates-java default-jre-headless fontconfig-config
fonts-dejavu-core java-common jsvc libasyncns0 libavahi-client3
libavahi-common-data libavahi-common3 libboost-filesystem1.54.0
libboost-program-options1.54.0 libboost-system1.54.0 libboost-thread1.54.0
libcommons-daemon-java libcups2 libflac8 libfontconfig1 libgoogle-perftools4
libjpeg-turbo8 libjpeg8 liblcms2-2 libnspr4 libnss3 libnss3-nssdb libogg0
libpcrecpp0 libpcsclite1 libpulse0 libsctp1 libsnappy1 libsndfile1
libtcmalloc-minimal4 libunwind8 libv8-3.14.5 libvorbis0a libvorbisenc2
lksctp-tools mongodb-clients mongodb-server openjdk-7-jre-headless tzdata
tzdata-java
Suggested packages:
binutils-doc default-jre equivs java-virtual-machine cups-common
liblcms2-utils pcscd pulseaudio icedtea-7-jre-jamvm libnss-mdns
sun-java6-fonts fonts-dejavu-extra fonts-ipafont-gothic fonts-ipafont-mincho
ttf-wqy-microhei ttf-wqy-zenhei ttf-indic-fonts-core ttf-telugu-fonts
ttf-oriya-fonts ttf-kannada-fonts ttf-bengali-fonts
The following NEW packages will be installed:
binutils ca-certificates-java default-jre-headless fontconfig-config
fonts-dejavu-core java-common jsvc libasyncns0 libavahi-client3
libavahi-common-data libavahi-common3 libboost-filesystem1.54.0
libboost-program-options1.54.0 libboost-system1.54.0 libboost-thread1.54.0
libcommons-daemon-java libcups2 libflac8 libfontconfig1 libgoogle-perftools4
libjpeg-turbo8 libjpeg8 liblcms2-2 libnspr4 libnss3 libnss3-nssdb libogg0
libpcrecpp0 libpcsclite1 libpulse0 libsctp1 libsnappy1 libsndfile1
libtcmalloc-minimal4 libunwind8 libv8-3.14.5 libvorbis0a libvorbisenc2
lksctp-tools mongodb-clients mongodb-server openjdk-7-jre-headless
tzdata-java unifi
The following packages will be upgraded:
tzdata
1 upgraded, 44 newly installed, 0 to remove and 10 not upgraded.
Need to get 133 MB of archives.
After this operation, 287 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
...
done.
Finally, we point a web browser at this server, http://10.0.0.183:8443/ in my case, and run through the UniFi setup there.
From Linux kernel livepatches to encryption to ASLR to compiler optimizations and configuration hardening, we strive to ensure that Ubuntu 16.04 LTS is the most secure Linux distribution out of the box.
If you haven't heard about last week's Dirty COW vulnerability, I hope all of your Linux systems are automatically patching themselves...
Why? Because every single Linux-based phone, router, modem, tablet, desktop, PC, server, virtual machine, and absolutely everything in between -- including all versions of Ubuntu since 2007 -- was vulnerable to this face-palming critical security vulnerability.
Any non-root local user of a vulnerable system can easily exploit the vulnerability and become the root user in a matter of a few seconds. Watch...
Coincidentally, just before the vulnerability was published, we released the Canonical Livepatch Service for Ubuntu 16.04 LTS. The thousands of users who enabled canonical-livepatch on their Ubuntu 16.04 LTS systems with those first few hours received and applied the fix to Dirty COW, automatically, in the background, and without rebooting!
If you haven't already enabled the Canonical Livepatch Service on your Ubuntu 16.04 LTS systems, you should really consider doing so, with 3 easy steps:
Install the canonical-livepatch snap $ sudo snap install canonical-livepatch
Enable the service with your token $ sudo canonical-livepatch enable [TOKEN]
And you’re done! You can check the status at any time using:
$ canonical-livepatch status --verbose
Let's retry that same vulnerability, on the same system, but this time, having been livepatched...
Aha! Thwarted!
So that's the Ubuntu 16.04 LTS kernel space... What about userspace? Most of the other recent, branded vulnerabilities (Heartbleed, ShellShock, CRIME, BEAST) have been critical vulnerabilities in userspace packages.
As of Ubuntu 16.04 LTS, the unattended-upgrades package is now part of the default package set, so you should already have it installed on your Ubuntu desktops and servers. If you don't already have it installed, you can install it with:
$ sudo apt install unattended-upgrades
And moreover, as of Ubuntu 16.04 LTS, the unattended-upgrades package automatically downloads and installs important security updates once per day, automatically patching critical security vulnerabilities and keeping your Ubuntu systems safe by default. Older versions of Ubuntu (or Ubuntu systems that upgraded to 16.04) might need to enable this behavior using:
$ sudo dpkg-reconfigure unattended-upgrades
With that combination enabled -- (1) automatic livepatches to your kernel, plus (2) automatic application of security package updates -- Ubuntu 16.04 LTS is the most secure Linux distribution to date. Period.
Ubuntu 16.04 LTS’s 4.4 Linux kernel includes an important new security capability in Ubuntu -- the ability to modify the running Linux kernel code, without rebooting, through a mechanism called kernel livepatch.
Today, Canonical has publicly launched the Canonical Livepatch Service -- an authenticated, encrypted, signed stream of Linux livepatches that apply to the 64-bit Intel/AMD architecture of the Ubuntu 16.04 LTS (Xenial) Linux 4.4 kernel, addressing the highest and most critical security vulnerabilities, without requiring a reboot in order to take effect. This is particularly amazing for Container hosts -- Docker, LXD, etc. -- as all of the containers share the same kernel, and thus all instances benefit.
I’ve tried to answer below some questions that you might have. As you have others, you’re welcome
to add them to the comments below or on Twitter with hastag #Livepatch.
Install the canonical-livepatch snap $ sudo snap install canonical-livepatch
Enable the service with your token $ sudo canonical-livepatch enable [TOKEN]
And you’re done! You can check the status at any time using:
$ canonical-livepatch status --verbose
Q: What are the system requirements?
A: The Canonical Livepatch Service is available for the generic and low latency flavors of the 64-bit Intel/AMD (aka, x86_64, amd64) builds of the Ubuntu 16.04 LTS (Xenial) kernel, which is a Linux 4.4 kernel. Canonical livepatches work on Ubuntu 16.04 LTS Servers and Desktops, on physical machines, virtual machines, and in the cloud. The safety, security, and stability firmly depends on unmodified Ubuntu kernels and network access to the Canonical Livepatch Service (https://livepatch.canonical.com:443). You also will need to apt update/upgrade to the latest version of snapd (at least 2.15).
Q: What about other architectures?
A: The upstream Linux livepatch functionality is currently limited to the 64-bit x86 architecture, at this time. IBM is working on support for POWER8 and s390x (LinuxOne mainframe), and there’s also active upstream development on ARM64, so we do plan to support these eventually. The livepatch plumbing for 32-bit ARM and 32-bit x86 are not under upstream development at this time.
Q: What about other flavors?
A: We are providing the Canonical Livepatch Service for the generic and low latency (telco) flavors of the the Linux kernel at this time.
Q: What about other releases of Ubuntu?
A: The Canonical Livepatch Service is provided for Ubuntu 16.04 LTS’s Linux 4.4 kernel. Older releases of Ubuntu will not work, because they’re missing the Linux kernel support. Interim releases of Ubuntu (e.g. Ubuntu 16.10) are targeted at developers and early adopters, rather than Long Term Support users or systems that require maximum uptime. We will consider providing livepatches for the HWE kernels in 2017.
Q: What about derivatives of Ubuntu?
A: Canonical livepatches are fully supported on the 64-bit Ubuntu 16.04 LTS Desktop, Cloud, and Server operating systems. On other Ubuntu derivatives, your mileage may vary! These are not part of our automated continuous integration quality assurance testing framework for Canonical Livepatches. Canonical Livepatch safety, security, and stability will firmly depend on unmodified Ubuntu generic kernels and network access to the Canonical Livepatch Service.
Q: How does Canonical test livepatches?
A: Every livepatch is rigorously tested in Canonical's in-house CI/CD (Continuous Integration / Continuous Delivery) quality assurance system, which tests hundreds of combinations of livepatches, kernels, hardware, physical machines, and virtual machines. Once a livepatch passes CI/CD and regression tests, it's rolled out on a canary testing basis, first to a tiny percentage of the Ubuntu Community users of the Canonical Livepatch Service. Based on the success of that microscopic rollout, a moderate rollout follows. And assuming those also succeed, the livepatch is delivered to all free Ubuntu Community and paid Ubuntu Advantage users of the service. Systemic failures are automatically detected and raised for inspection by Canonical engineers. Ubuntu Community users of the Canonical Livepatch Service who want to eliminate the small chance of being randomly chosen as a canary should enroll in the Ubuntu Advantage program (starting at $12/month).
Q: What kinds of updates will be provided by the Canonical Livepatch Service?
A: The Canonical Livepatch Service is intended to address high and critical severity Linux kernel security vulnerabilities, as identified by Ubuntu Security Notices and the CVE database. Note that there are some limitations to the kernel livepatch technology -- some Linux kernel code paths cannot be safely patched while running. We will do our best to supply Canonical Livepatches for high and critical vulnerabilities in a timely fashion whenever possible. There may be occasions when the traditional kernel upgrade and reboot might still be necessary. We’ll communicate that clearly through the usual mechanisms -- USNs, Landscape, Desktop Notifications, Byobu, /etc/motd, etc.
Q: What about non-security bug fixes, stability, performance, or hardware enablement updates?
A: Canonical will continue to provide Linux kernel updates addressing bugs, stability issues, performance problems, and hardware compatibility on our usual cadence -- about every 3 weeks. These updates can be easily applied using ‘sudo apt update; sudo apt upgrade -y’, using the Desktop “Software Updates” application, or Landscape systems management. These standard (non-security) updates will still require a reboot, as they always have.
Q: Can I rollback a Canonical Livepatch?
A: Currently rolling-back/removing an already inserted livepatch module is disabled in Linux 4.4. This is because we need a way to determine if we are currently executing inside a patched function before safely removing it. We can, however, safely apply new livepatches on top of each other and even repatch functions over and over.
Q: What about low and medium severity CVEs?
A: We’re currently focusing our Canonical Livepatch development and testing resources on high and critical security vulnerabilities, as determined by the Ubuntu Security Team. We'll livepatch other CVEs opportunistically.
Q: Why are Canonical Livepatches provided as a subscription service?
A: The Canonical Livepatch Service provides a secure, encrypted, authenticated connection, to ensure that only properly signed livepatch kernel modules -- and most importantly, the right modules -- are delivered directly to your system, with extremely high quality testing wrapped around it.
Q: But I don’t want to buy UA support!
A: You don’t have to! Canonical is providing the Canonical Livepatch Service to community users of Ubuntu, at no charge for up to 3 machines (desktop, server, virtual machines, or cloud instances). A randomly chosen subset of the free users of Canonical Livepatches will receive their Canonical Livepatches slightly earlier than the rest of the free users or UA users, as a lightweight canary testing mechanism, benefiting all Canonical Livepatch users (free and UA). Once those canary livepatches apply safely, all Canonical Livepatch users will receive their live updates.
Q: But I don’t have an Ubuntu SSO account!
A: An Ubuntu SSO account is free, and provides services similar to Google, Microsoft, and Apple for Android/Windows/Mac devices, respectively. You can create your Ubuntu SSO account here.
Q: But I don’t want login to ubuntu.com!
A: You don’t have to! Canonical Livepatch is absolutely not required maintain the security of any Ubuntu desktop or server! You may continue to freely and anonymously ‘sudo apt update; sudo apt upgrade; sudo reboot’ as often as you like, and receive all of the same updates, and simply reboot after kernel updates, as you always have with Ubuntu.
Q: But I don't have Internet access to livepatch.canonical.com:443!
A: You should think of the Canonical Livepatch Service much like you think of Netflix, Pandora, or Dropbox. It's an Internet streaming service for security hotfixes for your kernel. You have access to the stream of bits when you can connect to the service over the Internet. On the flip side, your machines are already thoroughly secured, since they're so heavily firewalled off from the rest of the world!
Q: Where’s the source code?
A: The source code of livepatch modules can be found here. The source code of the canonical-livepatch client is part of Canonical's Landscape system management product and is commercial software.
Q: What about Ubuntu Core?
A: Canonical Livepatches for Ubuntu Core are on the roadmap, and may be available in late 2016, for 64-bit Intel/AMD architectures. Canonical Livepatches for ARM-based IoT devices depend on upstream support for livepatches.
Q: How does this compare to Oracle Ksplice, RHEL Live Patching and SUSE Live Patching?
A: While the concepts are largely the same, the technical implementations and the commercial terms are very different:
Oracle Ksplice uses it’s own technology which is not in upstream Linux.
RHEL and SUSE currently use their own homegrown kpatch/kgraft implementations, respectively.
Ksplice is free, but unsupported, for Ubuntu Desktops, and only available for Oracle Linux and RHEL servers with an Oracle Linux Premier Support license ($2299/node/year).
It’s a little unclear how to subscribe to RHEL Kernel Live Patching, but it appears that you need to first be a RHEL customer, and then enroll in the SIG (Special Interests Group) through your TAM (Technical Account Manager), which requires Red Hat Enterprise Linux Server Premium Subscription at $1299/node/year. (I'm happy to be corrected and update this post)
Canonical Livepatching is available for every Ubuntu Advantage customer, starting at our entry level UA Essential for $150/node/year, and available for free to community users of Ubuntu.
Q: What happens if I run into problems/bugs with Canonical Livepatches?
A: Ubuntu Advantage customers will file a support request at support.canonical.com where it will be serviced according to their UA service level agreement (Essential, Standard, or Advanced). Ubuntu community users will file a bug report on Launchpad and we'll service it on a best effort basis.
Q: Why does canonical-livepatch client/server have a proprietary license?
A: The canonical-livepatch client is part of the Landscape family of tools available to Canonical support customers. We are enabling free access to the Canonical Livepatch Service for Ubuntu community users as a mark of our appreciation for the broader Ubuntu community, and in exchange for occasional, automatic canary testing.
Q: How do I build my own livepatches?
A: It’s certainly possible for you to build your own Linux kernel live patches, but it requires considerable skill, time, computing power to produce, and even more effort to comprehensively test. Rest assured that this is the real value of using the Canonical Livepatch Service! That said, Chris Arges has blogged a howto for the curious a while back:
Q: How do I get notifications of which CVEs are livepatched and which are not?
A: You can, at any time, query the status of the canonical-livepatch daemon using: ‘canonical-livepatch status --verbose’. This command will show any livepatches successfully applied, any outstanding/unapplied livepatches, and any error conditions. Moreover, you can monitor the Ubuntu Security NoticesRSS feed and the ubuntu-security-announce mailing list.
Q: Isn't livepatching just a big ole rootkit?
A: Canonical Livepatches inject kernel modules to replace sections of binary code in the running kernel. This requires the CAP_SYS_MODULE capability. This is required to modprobe any module into the Linux kernel. If you already have that capability (root does, by default, on Ubuntu), then you already have the ability to arbitrarily modify the kernel, with or without Canonical Livepatches. If you’re an Ubuntu sysadmin and you want to disable module loading (and thereby also disable Canonical Livepatches), simply ‘echo 1 | sudo tee /proc/sys/kernel/modules_disabled’.
My wife, Kimberly, and I watch Saturday Night Live religiously. As in, we probably haven't missed a single episode since we started dating more than 12 years ago. And in fact, we both watched our fair share of SNL before we had even met, going back to our teenage years.
We were catching up on SNL's 42nd season premier late this past Sunday night, after putting the kids to bed, when I was excited to see a hilarious sketch/parody of Mr. Robot.
If SNL is my oldest TV favorite, Mr. Robot is certainly my newest! Just wrapping its 2nd season, it's a brilliantly written, flawlessly acted, impeccably set techno drama series on USA. I'm completely smitten, and the story seems to be just getting started!
Okay, so Kim and I are watching a hilarious sketch where Leslie Jones asks Elliot to track down the person who recently hacked her social media accounts. And, as always, I take note of what's going in the background on the computer screen. It's just something I do. I love to try and spot the app, the OS, the version, identify the Linux kernel oops, etc., of anything on any computer screen on TV.
At about the 1:32 mark of the SNL/Mr.Robot skit, there was something unmistakable on the left computer, just over actor Pete Davidson's right shoulder. Merely a fraction of a second, and I recognized it instantly! A dark terminal, split into a dozen sections. A light grey boarder, with a thicker grey highlighting one split. The green drip of text from The Matrix in one of the splits. A flashing, bouncing yellow audio wave in another. An instant rearrangement of all of those windows each second.
It was Byobu and Hollywood! I knew it. Kim didn't believe me at first, until I proved it ;-)
A couple of years ago, after seeing a 007 film in the theater, I created a bit of silliness -- a joke of a program that could turn any Linux terminal into a James Bond caliber hacker screen. The result is a package called hollywood, which any Ubuntu user can install and run by simply typing:
$ sudo apt install hollywood
$ hollywood
And a few months ago , Hollywood found its way into an NBC News piece that took itself perhaps a little too seriously, as it drummed up a bit of fear around "Ransomware".
But, far more appropriately, I'm absolutely delighted to see another NBC program -- Saturday Night Live -- using Hollywood exactly as intended -- for parody!
On Monday this week, I was afforded the distinct privilege to deliver the opening keynote at the OpenZFS Developer Summit in San Francisco. It was a beautiful little event, with a full day of informative presentations and lots of networking during lunch and breaks.
Hopefully you'll enjoy the demo -- especially the most interesting raw tracing system new in the Ubuntu 16.04 LTS Linux 4.4 kernel, something called The Berkeley Packet Filter, or "BPF" for short. I used a series of open source utilities from Brendan Gregg (from Netflix), called iovisor/bcc. Quoting the README.md on Github:
BCC is a toolkit for creating efficient kernel tracing and manipulation programs, and includes several useful tools and examples. It makes use of extended BPF (Berkeley Packet Filters), formally known as eBPF, a new feature that was first added to Linux 3.15. Much of what BCC uses requires Linux 4.1 and above.
I'll follow up this post with another one, formally introducing BPF and how to install and use bcc in Ubuntu 16.04 LTS, if anyone is interested...
A couple of weeks ago, I delivered a talk at the Container Camp UK 2016. It was an brilliant event, on a beautiful stage at Picturehouse Central in Picadilly Circus in London.
I reinstalled my primary laptop (Lenovo x250) about 3 months ago (June 30, 2016), when I got a shiny new SSD, with a fresh Ubuntu 16.04 LTS image.
Just yesterday, I needed to test something in KVM. Something that could only be tested in KVM.
kirkland@x250:~⟫ kvm
The program 'kvm' is currently not installed. You can install it by typing:
sudo apt install qemu-kvm
127 kirkland@x250:~⟫
I don't have KVM installed? How is that even possible? I used to be the maintainer of the virtualization stack in Ubuntu (kvm, qemu, libvirt, virt-manager, et al.)! I lived and breathed virtualization on Ubuntu for years...
Alas, it seems that I've use LXD for everything these days! It's built into every Ubuntu 16.04 LTS server, and one 'apt install lxd' away from having it on your desktop. With ZFS, instances start in under 3 seconds. Snapshots, live migration, an image store, a REST API, all built in. Try it out, if you haven't, it's great!
kirkland@x250:~⟫ time lxc launch ubuntu:x
Creating supreme-parakeet
Starting supreme-parakeet
real 0m1.851s
user 0m0.008s
sys 0m0.000s
kirkland@x250:~⟫ lxc exec supreme-parakeet bash
root@supreme-parakeet:~#
But that's enough of a LXD advertisement...back to the title of the blog post.
Here, I want to download an Ubuntu cloud image, and boot into it. There's one extra step nowadays. You need to create your "user data" and feed it into cloud-init.
In the nominal case, you can now just launch KVM, and add your user data as a cdrom disk. When it boots, you can login with "ubuntu" and "passw0rd", which we set in the seed:
Finally, let's enable more bells an whistles, and speed this VM up. Let's give it all 4 CPUs, a healthy 8GB of memory, a virtio disk, and let's port forward ssh to 2222:
And with that, we can how ssh into the VM, with the public SSH key specified in our seed:
kirkland@x250:~⟫ ssh -p 5555 ubuntu@localhost
The authenticity of host '[localhost]:5555 ([127.0.0.1]:5555)' can't be established.
RSA key fingerprint is SHA256:w2FyU6TcZVj1WuaBA799pCE5MLShHzwio8tn8XwKSdg.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? yes
Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-36-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Get cloud support with Ubuntu Advantage Cloud Guest:
http://www.ubuntu.com/business/services/cloud
0 packages can be updated.
0 updates are security updates.
ubuntu@ubuntu:~⟫
I hope you'll enjoy a shiny new 6-part blog series I recently published at Linux.com.
The first article is a bit of back story, perhaps a behind-the-scenes look at the motivations, timelines, and some of the work performed between Microsoft and Canonical to bring Ubuntu to Windows.
The second article is an updated getting-started guide, with screenshots, showing a Windows 10 user exactly how to enable and run Ubuntu on Windows.
The third article walks through a dozen or so examples of the most essential command line utilities a Windows user, new to Ubuntu (and Bash), should absolutely learn.
The fourth article shows how to write and execute your first script, "Howdy, Windows!", in 6 different dynamic scripting languages (Bash, Python, Perl, Ruby, PHP, and NodeJS).
The fifth article demonstrates how to write, compile, and execute your first program in 7 different compiled programming languages (C, C++, Fortran, Golang).
The sixth and final article conducts some performance benchmarks of the CPU, Memory, Disk, and Network, in both native Ubuntu on a physical machine, and Ubuntu on Windows running on the same system.
I really enjoyed writing these. Hopefully you'll try some of the examples, and share your experiences using Ubuntu native utilities on a Windows desktop. You can find the source code of the programming examples in Github and Launchpad:
Now, write it to a microSD card using dd. I'm using the card reader built into my Thinkpad, but you might use a USB adapter. You'll need to figureout the block device of your card, and perhaps unmount it, if necessary. Then, you can write the image to disk:
If it's connected to a USB mouse and an HDMI monitor, then you'll land in a console where you can login with the username 'ubuntu' and password 'ubuntu', and then you'll be forced to choose a new password.
Assuming it has an Ethernet connection, it should DHCP. You might need to check your router to determine what IP address it got, or it sets it's hostname to 'ubuntu'. In my case, I could automatically resolve it on my network, at ubuntu.canyonedge, with IP address 10.0.0.113, and ssh to it:
$ ssh ubuntu@ubuntu.canyonedge
Again, you can login on first boot with password 'ubuntu' and you're required to choose a new password.
On first boot, it will automatically resize the filesystem to use all of the available space on the MicroSD card -- much nicer than having to resize2fs yourself in some offline mode!
Now, you're off and running. Have fun with sudo, apt, byobu, lxd, docker, and everything else you'd expect to find on a classic Ubuntu server ;-) Heck, you'll even find the snap command, where you'll be able to install snap packages, right on top of your classic Ubuntu Server! And if that doesn't just bake your noodle...
100% complete technical mumbo jumbo. The goal was to turn your terminal into something that belongs in a Hollywood hacker film.
I am proud to see it included in this NBCNews piece about "Ransomware". All of the screenshots, demonstrating what a "hacker" is doing with a system are straight from Ubuntu, Byobu, and Hollywood!
Here are a few screenshots, and the video is embedded below...
Below you can find the audio/video recording of my OpenStack Austin presentation, where I demonstrated Ubuntu OpenStack Mitaka, running on top of Ubuntu 16.04 LTS, entirely within LXD machine containers. You can also download the PDF of the slides here. And there are a number of other excellent talks here!
I'm delighted to share the slides from our joint IBM and Canonical webinar about Ubuntu on IBM POWER8 and LinuxOne servers. You can download the PDF here, watch the recording here, or tab through the slides or watch the video embedded below. Enjoy!
The sponsorship contract for the OpenStack Summit explicitly states that only the official lanyard sponsor may distribute lanyards. Whilst we understand the reason that clause is there, we don't agree with it. It just doesn't seem very "open" nor in the spirit of OpenStack.
Freedom of choice is an important aspect of all open source communities and one that we certainly champion, so attendees should be free to wear whatever branded lanyard they want with pride at the OpenStack Summit in Austin and we at Canonical will celebrate it. My hometown here, Austin, prides itself on diversity, where we like to Keep Austin Weird!
So please -- partners, customers, competitors, other OpenStack Sponsors: if you want to distribute your own lanyards then please go ahead safe in the knowledge that Canonical will not complain to the conference organizers. Let's Keep OpenStack (a little bit) Weird, too!
25,671: Ubuntu 16.04 LTS is comprised of 25,671 source packages
main, universe, restricted, multiverse
150,562+: Over 150,562 (and counting!) cloud instances of Xenial have launched to date
and we haven't even officially released yet!
216,475: A complete archive of all binary .deb packages in Ubuntu 16.04 LTS consists of 216,475 debs.
24,803 arch independent
27,159 armhf
26,845 arm64
28,730 i386
28,902 amd64
27,061 powerpc
26,837 ppc64el
26,138 s390x
1,426,792,926: A total line count of all source packages in Ubuntu 16.04 LTS using cloc yields 1,426,792,926total lines of source code
250,478,341,568: A complete archive all debs, all architectures in Ubuntu 16.04 LTS requires 250GB of disk space
Yes, that's 1.4 billion lines of source code comprising the entire Ubuntu 16.04 LTS archive. What an amazing achievement of open source development!
Perhaps my fellow nerds here might be interested in a breakdown of all 1.4 billion lines across 25K source packages, and throughout 176 different programming languages, as measured by Al Danial's cloc utility. Interesting data!
You can see the full list here. What further insight can you glean?
I'm thrilled to introduce Docker 1.10.3, available on every Ubuntu architecture, for Ubuntu 16.04 LTS, and announce the General Availability of Ubuntu Fan Networking!
i686 (does anyone seriously still run 32-bit intel servers?)
amd64 (most servers and clouds under the sun)
ppc64el (OpenPower and IBM POWER8 machine learning super servers)
s390x (IBM System Z LinuxOne super uptime mainframes)
That's Docker-Docker-Docker-Docker-Docker-Docker, from the smallest Raspberry Pi's to the biggest IBM mainframes in the world today! Never more than one 'sudo apt install docker.io' command away.
Moreover, we now have Docker running inside of LXD! Containers all the way down. Application containers (e.g. Docker), inside of Machine containers (e.g. LXD), inside of Virtual Machines (e.g. KVM), inside of a public or private cloud (e.g. Azure, OpenStack), running on bare metal (take your pick).
Let's have a look at launching a Docker application container inside of a LXD machine container:
Oh, and let's talk about networking... We're also pleased to announce the general availability of Ubuntu Fan networking -- specially designed to connect all of your Docker containers spread across your network. Ubuntu's Fan networking feature is an easy way to make every Docker container on your local network easily addressable by every other Docker host and container on the same network. It's high performance, super simple, utterly deterministic, and we've tested it on every major public cloud as well as OpenStack and our private networks.
Simply installing Ubuntu's Docker package will also install the ubuntu-fan package, which provides an interactive setup script, fanatic, should you choose to join the Fan. Simply run 'sudo fanatic' and answer the questions. You can trivially revert your Fan networking setup easily with 'sudo fanatic deconfigure'.
kirkland@x250:~$ sudo fanatic
Welcome to the fanatic fan networking wizard. This will help you set
up an example fan network and optionally configure docker and/or LXD to
use this network. See fanatic(1) for more details.
Configure fan underlay (hit return to accept, or specify alternative) [10.0.0.0/16]:
Configure fan overlay (hit return to accept, or specify alternative) [250.0.0.0/8]:
Create LXD networking for underlay:10.0.0.0/16 overlay:250.0.0.0/8 [Yn]: n
Create docker networking for underlay:10.0.0.0/16 overlay:250.0.0.0/8 [Yn]: Y
Test docker networking for underlay:10.0.0.45/16 overlay:250.0.0.0/8
(NOTE: potentially triggers large image downloads) [Yn]: Y
local docker test: creating test container ...
34710d2c9a856f4cd7d8aa10011d4d2b3d893d1c3551a870bdb9258b8f583246
test master: ping test (250.0.45.0) ...
test slave: ping test (250.0.45.1) ...
test master: ping test ... PASS
test master: short data test (250.0.45.1 -> 250.0.45.0) ...
test slave: ping test ... PASS
test slave: short data test (250.0.45.0 -> 250.0.45.1) ...
test master: short data ... PASS
test slave: short data ... PASS
test slave: long data test (250.0.45.0 -> 250.0.45.1) ...
test master: long data test (250.0.45.1 -> 250.0.45.0) ...
test master: long data ... PASS
test slave: long data ... PASS
local docker test: destroying test container ...
fanatic-test
fanatic-test
local docker test: test complete PASS (master=0 slave=0)
This host IP address: 10.0.0.45
I've run 'sudo fanatic' here on a couple of machines on my network -- x250 (10.0.0.45) and masterbr (10.0.0.8), and now I'm going to launch a Docker container on each of those two machines, obtain each IP address on the Fan (250.x.y.z), install iperf, and test the connectivity and bandwidth between each of them (on my gigabit home network). You'll see that we'll get 900mbps+ of throughput:
kirkland@masterbr:~⟫ sudo docker run -it ubuntu bash
root@effc8fe2513d:/# apt update >/dev/null 2>&1 ; apt install -y iperf >/dev/null 2>&1
root@effc8fe2513d:/# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 02:42:fa:00:08:00
inet addr:250.0.8.0 Bcast:0.0.0.0 Mask:255.0.0.0
inet6 addr: fe80::42:faff:fe00:800/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
RX packets:7659 errors:0 dropped:0 overruns:0 frame:0
TX packets:3433 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:22131852 (22.1 MB) TX bytes:189875 (189.8 KB)
root@effc8fe2513d:/# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ 4] local 250.0.8.0 port 5001 connected with 250.0.45.0 port 54274
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 1.05 GBytes 899 Mbits/sec
Finally, let's have another long hard look at the image from the top of this post. Download it in full resolution to study very carefully what's happening here, because it's pretty [redacted] amazing!
Here, we have a Byobu session, split into 6 panes (Shift-F2 5x Times, Shift-F8 6x times). In each pane, we have an SSH session to Ubuntu 16.04 LTS servers spread across 6 different architectures -- armhf, arm64, i686, amd64, ppc64el, and s390x. I used the Shift-F9 key to simultaneously run the same commands in each and every window. Here are the commands I ran:
That's right. We just launched Ubuntu LXD containers, as well as Docker containers against every Ubuntu 16.04 LTS architecture. How's that for Ubuntu everywhere!?!
I certainly earned some spending money in high school and beer money in college (1997-2001) through a series of side jobs, building websites in PHP and Postgres, at least one of which is still up and going strong -- DivItUp.com. So yeah, PHP sort of holds a soft spot in my heart.
One of the newest members of the Ubuntu Server Team at Canonical, Nish Aravamudan, has worked hard this cycle in merging PHP7 into Ubuntu 16.04 LTS. In doing so, he's worked with Zend and the upstream PHP developers as well as Ondřej Surý and Debian to ensure an outstanding PHP experience in Ubuntu, as always.
In doing so, we have now comprehensively bumped all of PHP and its libraries from PHP5 to PHP7 in Xenial. And it's available on every Ubuntu architecture -- amd64, arm64, armhf, i386, powerpc, ppc64el, s390x.
As such, PHP7 will be the only version of PHP supported in Ubuntu 16.04 LTS.
If you have a hard dependency on PHP5, then you should either remain on Ubuntu 14.04 LTS (Trusty), which is supported for another 3 years. Or better yet, perhaps you should have a look at LXD! Yeah, just drop your legacy PHP5 code into a LXD container running Ubuntu 14.04 LTS. You might even be interested in the adapt package which makes this even easier for you. Seriously, LXD is awesome for exactly this use case!
However, I suspect your experience might be very similar to mine... You see, I have a bunch of PHP code that I wrote like 12+ years ago, that largely "just works" and I never, ever, ever have to touch. You can find a couple of those projects packaged in Ubuntu, like Pictor and Musica. Once Nish got all of my PHP library dependencies packaged (libapache2-mod-php, php-cli, php-imagick, php-getid3), my decade-old PHP code just worked!
I'm actually really impressed with the PHP community here. I love that my ancient PHP code continues to "just work" with the new PHP7 engine. [Deleted a lengthy grumble about all of my Python2.x code that had to change to run under Python3...]
And not only did it just work, it's actually faster than ever before. PHP7 at its core is faster than ever before. Check out the info graphic below for more info!
Cheers,
Dustin
p.s. And if you're looking for Drupal, Nish is hard at work, trying to get Drupal8 into Ubuntu 16.04 LTS too ;-)
Dustin Kirkland (Twitter, LinkedIn) is an engineer at heart, with a penchant for reducing complexity and solving problems at the cross-sections of technology, business, and people.
With a degree in computer engineering from Texas A&M University (2001), his full-time career began as a software engineer at IBM in the Linux Technology Center working on the Linux kernel and security certifications, including a one-year stint as an dedicated engineer-in-residence at Red Hat in Boston (2005). Dustin was awarded the title Master Inventor at IBM, in recognition of his prolific patent work as an inventor and reviewer with IBM's intellectual property attorneys.
Dustin then first joined Canonical (2008) as an engineer (eventually, engineering manager), helping create the Ubuntu Server distribution and establishing Ubuntu as the overwhelming favorite Linux distribution in Amazon, Google, and Microsoft's cloud platforms, as well as authoring and maintaining dozens of new open source packages.
Dustin joined Gazzang (2011), a venture-backed start-up built around an open source project that he co-authored (eCryptFS), as Chief Technology Officer, and helped dozens of enterprise customers encrypt their data at rest and securely manage their keys. Gazzang was acquired by Cloudera (2014).
Having effectively monetized eCryptFS as an open source project at Gazzang, Dustin returned to Canonical (2013) as the VP of Product for Ubuntu and spent the next several years launching a portfolio of products and services (Ubuntu Advantage, Extended Security Maintenance, Canonical Livepatch, MAAS, OpenStack, Kubernetes) that continues to deliver considerable annual recurring revenue. With Canonical based in London, an 800+ work-from-home employee roster and customers spread across 40+ countries, Dustin traveled the world over, connecting with clients and colleagues steeped in rich cultural experiences.
Google Cloud (2018) recruited Dustin from Canonical to product manage Google's entrance into on-premises data centers with its GKE On-Prem (now, Anthos) offering, with a specific focus on the underlying operating system, hypervisor, and container security. This work afforded Dustin a view deep into the back end data center of many financial services companies, where he still sees tremendous opportunities for improvements in security, efficiencies, cost-reduction, and disruptive new technology adoption.
Seeking a growth-mode opportunity in the fintech sector, Dustin joined Apex Clearing (now, Apex Fintech Solutions) as the Chief Product Officer (2019), where he led several organizations including product management, field engineering, data science, and business partnerships. He drastically revamped Apex's product portfolio and product management processes, retooling away from a legacy "clearing house and custodian", and into a "software-as-a-service fintech" offering instant brokerage account opening, real-time fractional stock trading, a secure closed-network crypto solution, and led the acquisition and integration of Silver's tax and cost basis solution.
Drawn back into a large cap, Dustin joined Goldman Sachs (2021) as a Managing Director and Head of Platform Product Management, within the Consumer banking division, which included Marcus, and the Apple and GM credit cards. He built a cross-functional product management community and established numerous documented product management best practices, processes, and anti-patterns.
Dustin lives in Austin, Texas, with his wife Kim and their wonderful two daughters.
