v1 ASG2017 2017-10-20 2017-10-22 3 00:05 https://cfp.all-systems-go.io https://cfp.all-systems-go.io/media/ASG2017/img/asg-logo-ondark.svg UTC Kinvolk Office default 2017-10-20T16:30:00+00:00 16:30 03:00 None ASG2017-1-pre-registration-event default en Meet-up at the Kinvolk Office! false https://cfp.all-systems-go.io/ASG2017/talk/142/ https://cfp.all-systems-go.io/ASG2017/talk/142/feedback/ Event Loft default 2017-10-21T07:30:00+00:00 07:30 00:15 None ASG2017-2-opening default en Check In and Say Hello! false https://cfp.all-systems-go.io/ASG2017/talk/141/ https://cfp.all-systems-go.io/ASG2017/talk/141/feedback/ Event Loft presentation 2017-10-21T07:45:00+00:00 07:45 00:40 None ASG2017-3-really-crazy-container-troubleshooting-stories Monitoring & Tracing Gianluca Borello en In this talk, the presenter will share a few container troubleshooting stories that were encountered in the life of an infrastructure operator. The use cases are deliberately chosen to be a bit advanced and focused around exploring the inner workings of core libraries and kernel, to remind everyone that even the lowest level of modern systems need some love. The talk will follow a hands-on agenda, interactively iterating over all the key points of the troubleshooting process, focusing on the different tools used and providing immediate value to the listener, who should be able to apply the various workflows to other scenarios. Example use cases presented: - Troubleshooting resource isolation between containers - Tracing the root cause of a crashing containerized application - Monitoring memory and performance issues in containers false https://cfp.all-systems-go.io/ASG2017/talk/115/ https://cfp.all-systems-go.io/ASG2017/talk/115/feedback/ Event Loft presentation 2017-10-21T08:30:00+00:00 08:30 00:25 A quick introduction to the unique memory management concepts of Rust. ASG2017-4-rust-memory-management Debugging & Tooling Zeeshan Ali Khan en Rust is a systems programming language that focuses on safety and performance at the same time. Most people new to Rust, often struggle with memory management. The goal of this talk is to give a very quick overview of Rust's memory management. false https://cfp.all-systems-go.io/ASG2017/talk/118/ https://cfp.all-systems-go.io/ASG2017/talk/118/feedback/ Event Loft presentation 2017-10-21T09:00:00+00:00 09:00 00:15 Open services mark a paradigm shift similar to the disruption caused by open-source software in the 90s, but the path to effective adoption of open services tooling is sometimes unclear. Blake will share patterns and learnings from his experience integrating one such tool, Habitat, at smartB GmbH. ASG2017-5-incremental-adoption-of-open-services-with-habitat Service Management Blake Irvin en The modern computing world revolves around delivering applications as services. Until recently, massively scalable services were the specialized domain of tech giants, and attempts by small teams to reproduce the tooling available to Fortune 100 players often led to frustration and wasted time. Habitat is part of a new family of tools aimed at making application runtimes and service orchestration layers safe, repeatable and fully open. At smartB, Blake has brought Habitat to his org to reduce operational complexity, guarantee application runtime behavior and provide dependency isolation and transparency for applications and their corollary security profiles. smartB is his 5th startup in 10 years and his first foray into sustainability engineering. false https://cfp.all-systems-go.io/ASG2017/talk/104/ https://cfp.all-systems-go.io/ASG2017/talk/104/feedback/ Event Loft default 2017-10-21T09:15:00+00:00 09:15 00:15 None ASG2017-6-break default en Have a tea, coffee and/or Club Mate! false https://cfp.all-systems-go.io/ASG2017/talk/144/ https://cfp.all-systems-go.io/ASG2017/talk/144/feedback/ Event Loft presentation 2017-10-21T09:30:00+00:00 09:30 00:45 The introduction on Accelerated Networking on Azure created challenges integrating support in Linux distributions. The original method using bonding had issues that were solved by introducing a new mode called "Transparent VF". This mode solves issues with udev, cloudinit and distribution specific network initialization. This talk will also cover the process of how Linux support for Azure is integrated with upstreamand distributions. ASG2017-7-azure-networking-integration-challenges Networking Stephen Hemminger en false https://cfp.all-systems-go.io/ASG2017/talk/93/ https://cfp.all-systems-go.io/ASG2017/talk/93/feedback/ Event Loft default 2017-10-21T10:15:00+00:00 10:15 01:30 None ASG2017-8-lunch default en Yummy food available from food trucks in the courtyard false https://cfp.all-systems-go.io/ASG2017/talk/146/ https://cfp.all-systems-go.io/ASG2017/talk/146/feedback/ Event Loft presentation 2017-10-21T11:45:00+00:00 11:45 00:40 We'll be talking about what we learned throughout the past year running systemd in production at Facebook: new challenges that have come up, how the integration process went and the areas of improvement we discovered. We'll also discuss our efforts building a monitoring solution for system services based on systemd. ASG2017-9-systemd-facebook-a-year-later Service Management Davide Cavalca en This talk is a followup to <a href="https://www.youtube.com/watch?v=LhYd0S3qiMY">Deploying systemd at scale</a> that was presented at systemd.conf 2016, and covers the aftermath of the migration of our fleet to CentOS 7. Now that systemd is available everywhere, we found more and more services that started adopting it for their deployment, leveraging its features and occasionally exposing interesting behaviors. At the same time, we've been able to hone our process for integrating and rolling out new versions of systemd on the fleet, and started building tooling to manage and monitor it at scale. false https://cfp.all-systems-go.io/ASG2017/talk/126/ https://cfp.all-systems-go.io/ASG2017/talk/126/feedback/ Event Loft presentation 2017-10-21T12:30:00+00:00 12:30 00:25 rkt is a modern container runtime, built for security, efficiency, and composability. It is one of the container runtimes supported by Kubernetes but the current implementation (“rktnetes”) doesn’t support the Container Runtime Interface (CRI). The work-in-progress CRI implementation is called rktlet. This presentation will give an update on the rkt project, what new features were implemented recently and what’s coming up. It will also give an update on the state of the rktlet: what features are missing and what workarounds should be removed before it becomes a complete implementation of the CRI. ASG2017-10-state-of-the-rkt-container-runtime Process Isolation Iago López Galeiras en false https://cfp.all-systems-go.io/ASG2017/talk/123/ https://cfp.all-systems-go.io/ASG2017/talk/123/feedback/ Event Loft presentation 2017-10-21T13:00:00+00:00 13:00 00:40 Desktop application sandboxing is quite different than traditional container isolation, learn how flatpak does it, using the concept of portals. ASG2017-11-portals-dynamic-permissions-in-flatpak Process Isolation Alexander Larsson en Flatpak is a distribution independent bundling and deployment system for Linux, focusing on desktop applications. One core aspect of flatpak is application sandboxing, which has very different requirements on the desktop than in the traditional container space. Applications need to be isolated from the system, yet in order to be easy and intuitive to use they must integrate with the desktop environment in complex ways. Flatpak solves this by using a concept called Portals. This talk will discuss how Flatpak sandboxing/security works and the how Portals fit in this system. false https://cfp.all-systems-go.io/ASG2017/talk/114/ https://cfp.all-systems-go.io/ASG2017/talk/114/feedback/ Event Loft presentation 2017-10-21T13:45:00+00:00 13:45 00:15 Containers: love 'em or hate 'em -- whether you think they're the hottest new thing or yesteryear's same ideas in new clothing -- the both rapid and sustained rate of adoption of recent container technologies says one thing clearly: We Were Missing Something. But what, exactly? And have we found "it"? Or are we just beginning to uncover something new about the way we all, in our deepest hearts, wish computers would be? In this talk, we'll survey where containers came from, and question where they’re going: a discussion that crosses package management, releasing, deployment, immutability, reproducibility, and questions how meanings of all these things are now changing. ASG2017-12-containers-what-did-we-learn- Process Isolation Eric Myhre en Containers have brought a lot of new patterns and behaviors into focus. For example, atomic deploys have become part of everyday conversation; fully captured dependencies and snapshots are now the norm; and the very concept of "releasing" software is beginning to morph. But many of these concepts -- at least, as implemented in popular container systems today -- seem to be somewhere between poorly integrated or outright in conflict with our present understanding of "package managers" and "config management". What do containers need to learn from the decades of package management before today? And what hints do the package managers we all know and love need to take from the explosion of containers? Containers are an exciting opportunity to revisit many of our oldest assumptions about how to design systems: let's take this opportunity to think carefully and ask tough questions. false https://cfp.all-systems-go.io/ASG2017/talk/100/ https://cfp.all-systems-go.io/ASG2017/talk/100/feedback/ Event Loft default 2017-10-21T14:00:00+00:00 14:00 00:15 None ASG2017-13-break default en Have a tea, coffee and/or Club Mate! false https://cfp.all-systems-go.io/ASG2017/talk/148/ https://cfp.all-systems-go.io/ASG2017/talk/148/feedback/ Event Loft presentation 2017-10-21T14:15:00+00:00 14:15 00:40 As Infrastructure operators we're exposed to a lot of plumbing and not a lot of porcelain. Worse, because our concerns are often esoteric (in the eyes of application developers) we have to fix our own pipes too. Often this leads to the "homeowners dilemma"... Making the call of when to patch things up, when to rip out the pipes, and when to abandon gas lamps for electricity. We outline a number of aging pipes, proposed (and implemented) solutions, and ideas for dragging our systems into the future. ASG2017-14-fix-forget-or-forge-a-new-path- Security Brian 'redbeard' Harrington en On the systems side AAA services haven't kept up with the pace of application development, our hardware is aging, and there are components of infrastructure that have fallen by the wayside. Modern switches still support (non-TLS) RADIUS and TACACS+, other networking gear still only supports SNMP v1, and then we've got logging... In this talk we take stock of the landscape and discuss which pieces should be fixed, which desperately need to be abandoned, and which we have been thinking about all wrong. false https://cfp.all-systems-go.io/ASG2017/talk/159/ https://cfp.all-systems-go.io/ASG2017/talk/159/feedback/ Event Loft presentation 2017-10-21T15:00:00+00:00 15:00 00:25 Today, the systemd project uses a non-standard superset of C to get destructor-like functionality. But, we pay a heavy price for doing it this way: we lose compiler portability, use hundreds of boilerplate macros, and confuse static analysis tools (which don't always realize why we're not leaking memory). At compilation, the cleanup functionality gets mapped to the same facilities that handle C++ destructors. So, essentially, we're already using a non-standard version of C++ as well as a non-standard version of C. We can end this charade by following in GCC's footsteps and <a href="https://lwn.net/Articles/542457/">explicitly using a subset of C++</a>. By doing so, we can shed thousands of lines of C-trying-to-be-C++. We can also improve memory safety and code readability -- <a href="https://medium.com/@davidtstrauss/choosing-some-c-over-c-f5acb3dce4f5">all while keeping the feel of C</a>. ASG2017-15-streamlining-systemd-s-code-and-safety Service Management David Strauss en <p>Today, the systemd project uses a non-standard superset of C to get destructor-like functionality. But, we pay a heavy price for doing it this way: we lose compiler portability, use hundreds of boilerplate macros, and confuse static analysis tools (which don't always realize why we're not leaking memory). At compilation, the cleanup functionality gets mapped to the same facilities that handle C++ destructors. So, essentially, we're already using a non-standard version of C++ as well as a non-standard version of C. We can end this charade by following in GCC's footsteps and <a href="https://lwn.net/Articles/542457/">explicitly using a subset of C++</a>. By doing so, we can shed thousands of lines of C-trying-to-be-C++. We can also improve memory safety and code readability -- <a href="https://medium.com/@davidtstrauss/choosing-some-c-over-c-f5acb3dce4f5">all while keeping the feel of C</a>.</p> <p>In this presentation, we'll consider options for systems'd codebase:</p> <ul> <li>Converting instances of "cleanup" to destructors. This should allow us to discard a couple thousand lines of boilerplate and many "goto cleanup" situations.</li> <li>Converting raw pointers to equivalents with enforced semantics. For internal APIs, this should clarify handoff of memory ownership. For event loops, this should allow typed user data.</li> <li>While I'm no advocate of object-orientation, our concept of a "unit" cleanly maps to an abstract superclass. IDEs and code analysis tools will benefit from moving away from homegrown inheritance.</li> <li>We often return error codes as ints, and it would be good to explicitly use a real type instead. This will make refactoring easier if we change a function between returning an int vs. error vs. boolean.</li> <li>The journal would benefit from a higher-level storage library like RocksDB (which offers a slim version for resource-constrained environments). Libraries like RocksDB are possible to use from C but have a richer (and easier-to-use) C++ API.</li> </ul> false https://cfp.all-systems-go.io/ASG2017/talk/124/ https://cfp.all-systems-go.io/ASG2017/talk/124/feedback/ Event Loft presentation 2017-10-21T15:30:00+00:00 15:30 00:25 BPF is a Linux in-kernel virtual machine that is used for networking, tracing, seccomp and more. This talk will give an introduction to the extended BPF subsystem in Linux, an overview on how it works, show available tools to work with and explain possibilities as well as limits. ASG2017-16-a-gentle-introduction-to-e-bpf Monitoring & Tracing Michael Schubert en false https://cfp.all-systems-go.io/ASG2017/talk/92/ https://cfp.all-systems-go.io/ASG2017/talk/92/feedback/ Event Loft presentation 2017-10-21T16:00:00+00:00 16:00 00:30 systemd service management today supports a number of the features that container management is known for, but for classic system services. Let's see which ones, and how to make use of them. ASG2017-17-containers-without-a-container-manager-with-systemd Process Isolation Lennart Poettering en systemd service management today supports a number of the features that container management is known for, but for classic system services. Let's see which ones, and how to make use of them. We'll talk about sandboxing, resource bundling, service management and resource management, and more. We'll discuss what container managers can do, that systemd service management can't and vice versa. Last but not least we'll have a look at systemd-nspawn, systemd's very own container manager and what it adds on top of systemd's native service management. false https://cfp.all-systems-go.io/ASG2017/talk/101/ https://cfp.all-systems-go.io/ASG2017/talk/101/feedback/ Galerie presentation 2017-10-21T07:45:00+00:00 07:45 00:40 Bluetooth technology has been extended with a brand new mesh feature. This presentation gives an introduction to Bluetooth Mesh and its impacts on the ecosystem. It shows the new and exciting use cases that a mesh enabled Bluetooth low energy enables. The presentation will also put a focus on Linux and Zephyr operating systems and its integration with Bluetooth Mesh. ASG2017-18-introducing-bluetooth-mesh Networking Marcel Holtmann en false https://cfp.all-systems-go.io/ASG2017/talk/105/ https://cfp.all-systems-go.io/ASG2017/talk/105/feedback/ Galerie presentation 2017-10-21T08:30:00+00:00 08:30 00:25 Extended Berkeley Packet Filter (eBPF) allows for high-performance introspection of the Linux kernel execution. eBPF is widely available (part of the mainline kernel and enabled by most distributions), flexible (any kernel code path can be probed) and safe (driven from userspace and statically verified). In this talk, I will introduce eBPF, explaining how it can be used to track TCP connections in real time. On the way I will demonstrate it is possible to access eBPF from languages other than C (Golang) and remove undesirable runtime dependencies (LLVM compiler and kernel-headers). At Weaveworks we are using eBPF for the connection-tracker of the Weave Scope visualization tool. ASG2017-19-high-performance-linux-monitoring-with-ebpf Monitoring & Tracing Alfonso Acosta en false https://cfp.all-systems-go.io/ASG2017/talk/139/ https://cfp.all-systems-go.io/ASG2017/talk/139/feedback/ Galerie presentation 2017-10-21T09:00:00+00:00 09:00 00:15 With the growing number of network cloud services it becomes essential to be able to monitor, troubleshoot and analyze different virtualization or container technologies. Being able to monitor complex heterogeneous federated cloud environments is key. Skydive is a real-time and post-mortem topology and packet analyzer. To do so, it listens for networking kernel events, monitors network namespaces, watches external components such as OVSDB and Docker. Skydive can make use of AF_PACKET or eBPF programs to capture traffic. Thanks to its classifier Skydive is able to map the network traffic with the topology. ASG2017-20-network-troubleshooting-in-heterogeneous-cloud-environment-with-skydive Networking Sylvain Afchain en With the growing number of network cloud services it becomes essential to be able to monitor, troubleshoot and analyze different virtualization or container technologies. Being able to monitor complex heterogeneous federated cloud environments is key. Skydive is a real-time and post-mortem topology and packet analyzer. To do so, it listens for networking kernel events, monitors network namespaces, watches external components such as OVSDB and Docker. Skydive can make use of AF_PACKET or eBPF programs to capture traffic. Thanks to its classifier Skydive is able to map the network traffic with the topology. We will show through a demo how Skydive can help operators to visualize, understand and troubleshoot packet forwarding from point to point. false https://cfp.all-systems-go.io/ASG2017/talk/113/ https://cfp.all-systems-go.io/ASG2017/talk/113/feedback/ Galerie default 2017-10-21T09:15:00+00:00 09:15 00:15 None ASG2017-21-break default en Have a tea, coffee and/or Club Mate! false https://cfp.all-systems-go.io/ASG2017/talk/145/ https://cfp.all-systems-go.io/ASG2017/talk/145/feedback/ Galerie presentation 2017-10-21T09:30:00+00:00 09:30 00:45 Habitat is the best way for software developers to build, deploy, and manage modern applications - regardless of their expertise. Habitat provides a self-healing, self-configuring, stack-agnostic, frictionless abstraction for running applications—regardless of their complexity on whatever infrastructure you prefer, from physical hardware and virtual machines to containers and everything in between. This session will show you how to build and run your own application. You will learn how scaffolding helps you quickly and easily package your application. Explore the build system used for generating Habitat artifacts. Run an application using the Habitat supervisor. This is the talk for anyone who's just learning about Habitat or those that are interested in seeing some of the newer features of the framework. ASG2017-22-getting-started-with-habitat Service Management Jamie Winsor en Habitat is the best way for software developers to build, deploy, and manage modern applications - regardless of their expertise. Habitat provides a self-healing, self-configuring, stack-agnostic, frictionless abstraction for running applications—regardless of their complexity on whatever infrastructure you prefer, from physical hardware and virtual machines to containers and everything in between. This session will show you how to build and run your own application. You will learn how scaffolding helps you quickly and easily package your application. Explore the build system used for generating Habitat artifacts. Run an application using the Habitat supervisor. This is the talk for anyone who's just learning about Habitat or those that are interested in seeing some of the newer features of the framework. false https://cfp.all-systems-go.io/ASG2017/talk/103/ https://cfp.all-systems-go.io/ASG2017/talk/103/feedback/ Galerie default 2017-10-21T10:15:00+00:00 10:15 01:30 None ASG2017-23-lunch default en Yummy food available from food trucks in the courtyard false https://cfp.all-systems-go.io/ASG2017/talk/147/ https://cfp.all-systems-go.io/ASG2017/talk/147/feedback/ Galerie presentation 2017-10-21T11:45:00+00:00 11:45 00:40 We will discuss the various malware infecting Linux IoT devices including Mirai, Hajime, and BrickerBot and the vulnerabilities they leverage to enslave or brick connected devices. We will walk the audience through specific vectors they used to exploit devices and cover some basics in security hardening that would have largely protected from many of the widespread malware. Some of the fundamental security concepts we will cover include: Closing unused open network ports Intrusion detection systems Enforcing password complexity and policies Removing unnecessary services Frequent software updates to fix bugs and patch security vulnerabilities We will also delve into the arguments and counter-arguments of vigilante hacking with Hajime and BrickerBot as examples and the potential long-term consequences in this new age of connected devices. ASG2017-24-the-iot-botnet-wars-linux-devices-and-the-absence-of-basic-security-hardening Security Drew Moseley en This talk will cover the ongoing battle being waged is leveraging insecure Linux-based Internet of Things (IoT) devices. BrickerBot is an example of a recent malware strain attacking connected devices and causing them to “brick,” making an electronic device completely useless in a permanent denial-of-service (PDoS) attack. Additionally, the Mirai botnet consisted of connected printers, IP cameras, residential gateways, and baby monitors that flooded DNS servers. Mirai was behind the largest DDoS attack of its kind ever in October 2016, with an estimated throughput of 1.2 terabits per second. It leveraged these enslaved devices to bring down large portions of the internet, including services such as Netflix, GitHub, HBO, Amazon, Reddit, Twitter, and DIRECTV. BrickerBot’s goal appears to counter Mirai’s: Bricking insecure Linux devices so that malware such as Mirai can’t subjugate these devices in another DDoS attack. We will take an in-depth look at the anatomy of the attack. We will then dive into basic some security hardening principles which would have helped protect against many of these attacks. Some of the fundamental security concepts we will cover include: Closing unused open network ports Intrusion detection systems Enforcing password complexity and policies Removing unnecessary services Frequent software updates to fix bugs and patch security vulnerabilities false https://cfp.all-systems-go.io/ASG2017/talk/129/ https://cfp.all-systems-go.io/ASG2017/talk/129/feedback/ Galerie presentation 2017-10-21T12:30:00+00:00 12:30 00:25 Cockpit is an open source project that has built the new system admin UI for Linux. It turns Linux server into something discoverable and usable. Its goal is to remove the steep learning curve for Linux deployments. Cockpit lets you immediately dive into things like storage, network configuration, system log diagnosis, container troubleshooting and Kubernetes orchestration. All while being zero-footprint: It goes away when not in use. Cockpit interacts well with other management configuration tools, it reacts instantly to system changes made elsewhere. We'll look at how Cockpit is an actual linux user session that you drive through your browser, running with user privileges, and accesses to the native system APIs and tools. You'll be able to build new pieces of sysadmin UI as fast as you write a shell script. In fact we'll do it on stage in a few minutes. ASG2017-25-cockpit-a-linux-sysadmin-session-in-your-browser Service Management Stef Walter en false https://cfp.all-systems-go.io/ASG2017/talk/99/ https://cfp.all-systems-go.io/ASG2017/talk/99/feedback/ Galerie presentation 2017-10-21T13:00:00+00:00 13:00 00:40 A status report on Reproducible builds, which enable everyone to verify that a given binary is made from the source it is claimed to be made from, by enabling anyone to create bit by bit identical binaries. ASG2017-26-reproducible-builds-where-do-we-want-to-go-tomorrow- Security Holger Levsen en We've made lots of progress, but we are still far from our goals of changing the (software) world This talk will report on the state of reproducible builds in various distributions (Debian, Archlinux, coreboot, F-Droid, Fedora, FreeBSD, Guix, NetBSD, OpenWrt, SuSE, and Qubes OS - to name a few) and thus should be interesting and insightful for anyone working on any free software project. Holger will explain how he started working on this in the Debian context and how his focus shifted slightly over the time. So he will start with explaining the status of Reproducible Debian, but this is quickly followed by an overview of common problems and solutions, followed by a quick explaination of the shared test infrastructure for reproducible tests of any project. You will learn how the community was broadened, what future plans we have to address what might be needed beyond being able to reproducible build something, so this becomes truly meaningful for users in practice. In this talk you will also learn about the challanges we're facing to deliver on the promise. Being able to reproducibly build in theory is not enough, one needs to be able to do so in practice. And enabling this on a distro scale is much harder than we thought… false https://cfp.all-systems-go.io/ASG2017/talk/117/ https://cfp.all-systems-go.io/ASG2017/talk/117/feedback/ Galerie lighning_talk 2017-10-21T13:45:00+00:00 13:45 00:15 Containers have become a popular way of packaging and running applications, especially for server applications using microservice architectures. As containers can be started in no time, building new container images replacing old ones has become the predominant way of applying updates. Having continuous delivery pipelines for building these images becomes a key problem. This talk will show how the Open Build Service provides a way to automate container builds including tracking updates and automatic rebuilds of dependent containers. This makes it easy to create secure and up to date containers all day. ASG2017-27-building-containers-all-day Debugging & Tooling Cornelius Schumacher en false https://cfp.all-systems-go.io/ASG2017/talk/95/ https://cfp.all-systems-go.io/ASG2017/talk/95/feedback/ Galerie default 2017-10-21T14:00:00+00:00 14:00 00:15 None ASG2017-28-break default en Have a tea, coffee and/or Club Mate! false https://cfp.all-systems-go.io/ASG2017/talk/149/ https://cfp.all-systems-go.io/ASG2017/talk/149/feedback/ Galerie presentation 2017-10-21T14:15:00+00:00 14:15 00:40 To achieve faster and easier containerization at Facebook we have started utilizing Chef, Btrfs and Systemd to improve our container system. These tools helped us to design a robust base for our cluster management will allow us to concentrate more higher level functionality. Our version of image and task handling tries address some issues common both to Facebook and the industry. ASG2017-29-using-systemd-for-containers-facebook Service Management Zeal JagannathaZoltan Puskas en Co-presented by Zoltan Puskas and Zeal Jagannatha false https://cfp.all-systems-go.io/ASG2017/talk/135/ https://cfp.all-systems-go.io/ASG2017/talk/135/feedback/ Galerie presentation 2017-10-21T15:00:00+00:00 15:00 00:25 Landlock is a proposal for a new Linux Security Module (LSM) to create secure sandboxes with the goal “to empower any process, including unprivileged ones, to securely restrict themselves.” This presentation will give an overview on what Landlock is, discuss the current status of the patchset and demonstrate how Landlock works, as well as its differences compared to other Linux security modules. ASG2017-30-landlock-lsm-towards-unprivileged-sandboxing Security Michael Schubert en false https://cfp.all-systems-go.io/ASG2017/talk/110/ https://cfp.all-systems-go.io/ASG2017/talk/110/feedback/ Galerie presentation 2017-10-21T15:30:00+00:00 15:30 00:25 A key requirement for connected Linux devices is the ability to deploy remote software updates to them so that bugs, vulnerabilities and new features can be addressed while devices live in the field for up to 10 years. As part of the Mender.io project, we have interviewed more than 100 embedded developers to understand best practices and the current state of enabling software updates for connected devices today. The key requirements found during this study can be split into the following areas we cover: - Robustness - Ease - Performant - Secure - Extensible ASG2017-31-software-updates-for-connected-linux-devices-key-requirements Security Drew Moseley en In order to address these requirements, design trade-offs need to be made. In this presentation, we will cover the most common update strategies, such as using A/B dual rootfs, maintenance-mode updates, package managers, tarballs, and see the trade-offs of each approach. Remote Software Updates for Connected Devices: Key Considerations A key requirement for connected devices is the ability to deploy remote software updates to them so that bugs, vulnerabilities and new features can be addressed while devices live in the field for up to 10 years. As part of the Mender.io project, we have interviewed more than 100 embedded developers to understand best practices and the current state of enabling software updates for connected devices today. The key requirements found during this study can be split into the following areas: Robust - the cost of bricking devices is high Ease - teams generally do not have much time to invest in an updater mechanism Performant - bandwidth is the key limiting resource for connected devices, but other system resources should also be conserved during the update process. Downtime during the update process should be kept to a minimum. Secure - the update process must not enable attackers to deploy malicious software to the devices Extensible - connected devices vary greatly and the updater must be generic and extensible to support the majority of them In order to address these requirements, design tradeoffs need to be made. In this presentation, we will cover the most common update strategies, such as using A/B dual rootfs, maintenance-mode updates, package managers, tarballs, and see the tradeoffs of each approach. We will also consider other important design aspects of an updater, such as validating deployment compatibility, integrity, authenticity, sanity-checking after the update, handling update failures, identifying extension points, device portability, persistent user-data, and reducing bandwidth consumption and downtime. false https://cfp.all-systems-go.io/ASG2017/talk/122/ https://cfp.all-systems-go.io/ASG2017/talk/122/feedback/ Galerie default 2017-10-21T16:00:00+00:00 16:00 00:30 Today the technological worlds centralize principle is to automate each conceivable thing for simplicity in life, providing security, saving electricity and time. <cite>Home automation is “The Internet of Things"…The way that all of our devices and appliances will be networked together to provide us with a seamless control over all aspects of our home and more.</cite> Also a step toward what is referred to as the "Internet of Things," in which everything has an assigned IP address, and can be monitored and accessed remotely. The idea of automating each appliance in the home is done from many years ago, it started with connecting two electric wires to the battery and close the circuit by connecting load as a light. ASG2017-32-securing-home-automation-with-tor Security Kalyan Dikshit en Be Safe. Be Secure Automation is, unsurprisingly, one of the two main characteristics of home automation. Automation refers to the ability to program and schedule events for the devices on the network. The programming may include time-related commands, such as having your lights turn on or off at specific times each day. It can also include non-scheduled events, such as turning on all the lights in your home when your security system alarm is triggered. Home automation systems are advancement to the mechanization processes wherein human efforts are needed with the machinery equipments to operate various loads in homes.The popularity of home automation has been expanding incredibly because of much higher reasonableness and straightforwardness through Smartphones and wireless networks. <cite>"Internet of Things"</cite> is interlinked through these networks; because of the popularity of the home automation is improved by the quality of service provided by the devices. Different home automation systems are developed for automatically on and off the appliances with different applications. Once you start to understand the possibilities of home automation scheduling, you can come up with any number of useful and creative solutions to make your life better. In present days most of the automation systems utilize the combination of hardwired and wireless systems for controlling the appliances. Security is extremely important for achieving this goal. As this worldwide network of interconnected objects can be exploited anywhere by anyone and anytime, it is necessary to enhance it with strong security foundations able to give birth to a world-changing paradigm. Tor is a cumulative routing system that has helped many towards “Safe and Secure Browsing”. Tor can be used to secure our Home Automation, and in unlocking its workings, we will avoid being locked out of our smart home physically. false https://cfp.all-systems-go.io/ASG2017/talk/119/ https://cfp.all-systems-go.io/ASG2017/talk/119/feedback/ Galerie default 2017-10-21T17:00:00+00:00 17:00 04:55 None ASG2017-33-social-event default en Meet people and be merry! false https://cfp.all-systems-go.io/ASG2017/talk/143/ https://cfp.all-systems-go.io/ASG2017/talk/143/feedback/ Event Loft presentation 2017-10-22T07:30:00+00:00 07:30 00:25 Kubernetes promises healing your application on all kinds of failure scenarios, but why not self-heal Kubernetes itself? ASG2017-34-what-if-component-xxx-dies-introducing-self-healing-kubernetes Service Management Max Leonard Inden en This talk introduces self-hosted Kubernetes (K8s inside itself) to autonomously recover from failure scenarios with the help of e.g. itself, systemd and checkpointing. We will ask and answer questions like “What happens when xxx dies”. The theory will be followed by a demo on a live cluster showcasing what happens when we kill central Kubernetes components, like the API-Server. Let’s see how well Kubernetes recovers. false https://cfp.all-systems-go.io/ASG2017/talk/137/ https://cfp.all-systems-go.io/ASG2017/talk/137/feedback/ Event Loft presentation 2017-10-22T08:00:00+00:00 08:00 00:40 Potential solutions to achieving containerization on constrained devices. 1. Why? 2. a content addressable elf linker (bolter) 3. space efficient container imaging (korhal) 4. oci compliant runtime (railcar) ASG2017-35-kubernetes-for-toasters- Service Management Arvid E. Picciani en potential solutions to achieving containerization on constrained devices. false https://cfp.all-systems-go.io/ASG2017/talk/108/ https://cfp.all-systems-go.io/ASG2017/talk/108/feedback/ Event Loft presentation 2017-10-22T08:45:00+00:00 08:45 00:30 In this talk, I will present different use cases for using BPF in a Kubernetes cluster. BPF is a Linux in-kernel virtual machine and there are different kinds of BPF programs for different subsystems that will be considered: kprobes, traffic control, cgroups, LSM. I’ll follow with concrete examples, such as Weave Scope’s HTTP Statistics plugin. Finally, I’ll share tips and tricks on how to develop your own BPF programs in Kubernetes with the libraries bcc and gobpf, and show ways of easily test those with SemaphoreCI and rkt. ASG2017-36-using-bpf-in-kubernetes Monitoring & Tracing Alban Crequy en Linux superpowers in the cloud BPF and Kubernetes are both Open Source technologies on Linux but their respective communities initially had little overlaps. I want to bring more visibility of what BPF can offer to Kubernetes users and developers. false https://cfp.all-systems-go.io/ASG2017/talk/134/ https://cfp.all-systems-go.io/ASG2017/talk/134/feedback/ Event Loft default 2017-10-22T09:15:00+00:00 09:15 00:15 None ASG2017-37-break default en Have a tea, coffee and/or Club Mate! false https://cfp.all-systems-go.io/ASG2017/talk/150/ https://cfp.all-systems-go.io/ASG2017/talk/150/feedback/ Event Loft presentation 2017-10-22T09:30:00+00:00 09:30 00:25 How to get a slightly broken hard disk for testing file systems or udisks? A wifi access point which supports the old 802.11b standard for writing a test case for NetworkManager? Downloading a photo from a particular camera model which you don't own, but got a libgphoto bug report for? In this hands-on presentation and live demo of various Linux kernel and userspace tools I will show you how. ASG2017-38-simulate-hardware-for-integration-testing Debugging & Tooling Martin Pitt en false https://cfp.all-systems-go.io/ASG2017/talk/121/ https://cfp.all-systems-go.io/ASG2017/talk/121/feedback/ Event Loft presentation 2017-10-22T10:00:00+00:00 10:00 00:45 n the Cockpit project we’ve done something amazing: We’ve built “robot” contributors to an Open Source project. “Cockpituous”, our project’s #5 contributor, is actually our automated team members. Bots do the mundane tasks that would otherwise use up the time of human contributors. During the talk you can see them self-organizing, finding issues, contributing code changes, making decisions, releasing the software into Linux distros and containers. They work in a completely distributed, organic way, and run in containers. We’ll talk about how humans are pair-programming with bots, and moving at a pace that would be unthinkable otherwise. Treating the bots as team members is fundamental to achieving this. I’m excited to show you how to pull that off. ASG2017-39-cyborg-teams Debugging & Tooling Stef Walter en Happy humans, tired machines false https://cfp.all-systems-go.io/ASG2017/talk/130/ https://cfp.all-systems-go.io/ASG2017/talk/130/feedback/ Event Loft default 2017-10-22T10:45:00+00:00 10:45 01:30 None ASG2017-40-lunch default en Yummy food available from food trucks in the courtyard false https://cfp.all-systems-go.io/ASG2017/talk/152/ https://cfp.all-systems-go.io/ASG2017/talk/152/feedback/ Event Loft presentation 2017-10-22T12:15:00+00:00 12:15 00:40 The Meson build system has been picking up steam this year and many fundamental projects have transitioned to it from their old build systems. In this talk we shall look at the advantages and disadvantages these transitions have brought, what we can expect from the future of build systems and what effect this change may have on the larger Linux ecosystem. ASG2017-41-meson-and-the-changing-linux-build-landscape Debugging & Tooling Jussi Pakkanen en The build system may seem like a simple and unimportant part of software development but it turns out to have implications that are both wide and deep. For example when Debian changed their package builds of systemd to use Meson, the build time on mips machines dropped from almost two hours to less than one. These sorts of changes enable workflows and process changes that simply were not possible or feasible with old tools. In addition to single projects, this transition has wider implications for distros and other aggregate works. We shall look into some of these changes ranging from full distro rebuilds to the core dependencies and tooling needed to build a modern Linux distro and how that might change in the future. false https://cfp.all-systems-go.io/ASG2017/talk/111/ https://cfp.all-systems-go.io/ASG2017/talk/111/feedback/ Event Loft presentation 2017-10-22T13:00:00+00:00 13:00 00:40 None ASG2017-42-insecure-containers- Security Andrew Martin en Open Source Software underpins the internet and many enterprises, but has repeatedly proven itself vulnerable to accident and tampering. As we fight to continuously secure millions of servers from attack, have we found a crucial panacea in containers? This talk examines the anatomy of major vulnerabilities, demonstrates their applicability to containerised applications, and explores container native security tooling throughout the pipeline. It covers recent major CVEs, container security models and extensions (cgroups, namespaces, rlimits, capabilities, Seccomp, AppArmor), their implementation in Docker and Kubernetes (flags, configuration best practices, entitlements), container breakout and hardening live demos, and container native security tooling (static/dynamic analysis, secret leakage prevention, IDS). false https://cfp.all-systems-go.io/ASG2017/talk/160/ https://cfp.all-systems-go.io/ASG2017/talk/160/feedback/ Event Loft presentation 2017-10-22T13:45:00+00:00 13:45 00:30 AgileBits, the company behind the 1password password manager, published a spec for their “opvault” format to show how confident they are in its design. This eliminates the need to reverse-engineer the encryption when trying to read from such a vault on a system where they don’t provide their tool. In this talk we’ll see an overview of the design of the format, such as the key derivation or the decision to split the meta-data from the details such as username and passwords. At the same time, the talk will follow the implementation of a library to read this format in Rust, which started as a way to practice the language but now has grown a GUI to display these entries so I can use the vault on my desktop. ASG2017-43-creating-your-own-1password-clone Security Carlos Martín Nieto en false https://cfp.all-systems-go.io/ASG2017/talk/158/ https://cfp.all-systems-go.io/ASG2017/talk/158/feedback/ Event Loft default 2017-10-22T14:15:00+00:00 14:15 00:15 None ASG2017-44-break default en Have a tea, coffee and/or Club Mate! false https://cfp.all-systems-go.io/ASG2017/talk/154/ https://cfp.all-systems-go.io/ASG2017/talk/154/feedback/ Event Loft presentation 2017-10-22T14:30:00+00:00 14:30 00:40 Secure boot as it currently exists in desktop Linux distributions is sufficient to verify that the bootloader and kernel have not been tampered with, but generally does nothing to ensure that userland is secure. How can we fix that? ASG2017-45-building-a-secure-boot-chain-to-userland Security Matthew Garrett en Full system security requires the ability to determine that the entire system is in a trustworthy state. Secure Boot as currently implemented in Linux gets us partway there, but not all the way. Going further involves tying into additional security functionality, much of which already exists but is poorly integrated. This presentation will cover what needs to be done, the components required to do it and the integration work that distributions will need to do to make it viable. false https://cfp.all-systems-go.io/ASG2017/talk/140/ https://cfp.all-systems-go.io/ASG2017/talk/140/feedback/ Event Loft presentation 2017-10-22T15:15:00+00:00 15:15 00:25 Updating embedded systems reliably requires more than just the actual update process. This presentation gives an overview of the overall design and components needed for successful system updates. ASG2017-46-updating-embedded-systems-putting-it-all-together Security Michael Olbrich en With the security issues in recent year, the fact that updates are necessary is no longer in question. Still, for embedded systems updates remain a challenge. With no administrator to handle unexpected problems, a failed update can render the device unusable, which is not acceptable. Performing updates reliably is only possible when updating is considered in the design of the entire system, from the bootloader to the application. This presentation gives an overview of the building blocks and decisions made to create such a design. The configuration and boot choices in the bootloader, watchdog handling, monitoring at boot- and runtime and, of course, the actual update process itself. The result is showcased using various open source components such as barebox, systemd, rauc and casync. false https://cfp.all-systems-go.io/ASG2017/talk/133/ https://cfp.all-systems-go.io/ASG2017/talk/133/feedback/ Event Loft default 2017-10-22T15:45:00+00:00 15:45 00:30 None ASG2017-47-closing default en Till the next time! false https://cfp.all-systems-go.io/ASG2017/talk/156/ https://cfp.all-systems-go.io/ASG2017/talk/156/feedback/ Galerie presentation 2017-10-22T07:30:00+00:00 07:30 00:25 kube-spawn is a tool to easily start a local, multi-node Kubernetes cluster on a Linux machine. While it was originally meant to be used mainly by developers of Kubernetes, it has been turned into a tool that is great for just trying Kubernetes out. In this talk, I will give a general introduction to kube-spawn and cover integration issues. ASG2017-48-kube-spawn-testing-multi-node-kubernetes-clusters-on-linux-systems Debugging & Tooling Dongsu Park en kube-spawn aims to become the easiest means of testing and fiddling with Kubernetes on Linux. It provides an environment that Kubernetes will eventually be running on, a full Linux OS. On the host side, end users are able to run native Kubernetes command-line tools to get every nodes and pods to work. For each container, kube-spawn bootstaps each instance based on CoreOS Container Linux, with the help of systemd-nspawn. In this talk I will introduce kube-spawn briefly from the perspective of end users. After that, I'm going to cover several integration issues, which have been discovered during implementation. It will range from administration tools like kubeadm to low-level issues such as btrfs-based storage pools. false https://cfp.all-systems-go.io/ASG2017/talk/109/ https://cfp.all-systems-go.io/ASG2017/talk/109/feedback/ Galerie presentation 2017-10-22T08:00:00+00:00 08:00 00:40 cgroupv1 (or just "cgroups") has helped revolutionise the way that we manage and use containers over the past 8 years. A complete overhaul is coming -- cgroupv2. This talk will go into why a new control group system was needed, the changes from cgroupv1, and practical uses that you can apply to improve the level of control you have over the processes on your servers. We will go over: - Design decisions and deviations for cgroupv2 compared to v1 - Pitfalls and caveats you may encounter when migrating to cgroupv2 - Discussion of the internals of cgroupv2 - Practical information about how we are using cgroupv2 inside Facebook ASG2017-49-cgroupv2-linux-s-new-unified-control-group-hierarchy Monitoring & Tracing Chris Down en false https://cfp.all-systems-go.io/ASG2017/talk/96/ https://cfp.all-systems-go.io/ASG2017/talk/96/feedback/ Galerie presentation 2017-10-22T08:45:00+00:00 08:45 00:30 When configuration changes, daemon-reload stops the world in an increasingly unsustainable way. The problem is getting worse for two reasons: (1) heavier use of systemd means more units and longer reload times and (2) expanded use of socket activation/D-Bus activation/automount means more things urgently need PID 1's attention. There are ways to fix this up, but we'll need to move away from stopping the world (the main event loop), throwing out most loaded state, reloading state, and then resuming event handling. ASG2017-50-unbreaking-reloads-strategies-for-fast-and-non-blocking-reconfiguration Service Management David Strauss en <p>When configuration changes, daemon-reload stops the world in an increasingly unsustainable way. The problem is getting worse for two reasons: (1) heavier use of systemd means more units and longer reload times and (2) expanded use of socket activation/D-Bus activation/automount means more things urgently need PID 1's attention. There are ways to fix this up, but we'll need to move away from stopping the world (the main event loop), throwing out most loaded state, reloading state, and then resuming event handling.</p> <p>We'll explore these options:</p> <ul> <li>Incremental state reloading, possibly when dependencies and other cascading configuration remains the same</li> <li>Amortized state reloading with an atomic switch on completion</li> <li>Offloading configuration loading to a separate thread or process, followed by an atomic switch-over on completion.</li> </ul> <p>We'll need to be careful to maintain the memory footprint on resource-constrained devices, but we have options:</p> <ul> <li>Choosing to still stop the world when a system is resource-constrained</li> <li>Storing unit data in a tree that supports snapshots and copy-on-write, which would constrain the maximum footprint during reload to barely more than it is today</li> </ul> false https://cfp.all-systems-go.io/ASG2017/talk/131/ https://cfp.all-systems-go.io/ASG2017/talk/131/feedback/ Galerie default 2017-10-22T09:15:00+00:00 09:15 00:15 None ASG2017-51-break default en Have a tea, coffee and/or Club Mate! false https://cfp.all-systems-go.io/ASG2017/talk/151/ https://cfp.all-systems-go.io/ASG2017/talk/151/feedback/ Galerie presentation 2017-10-22T09:30:00+00:00 09:30 00:25 In a world of connected devices, IoT and embedded systems, building robust products needs a modern deployment workflow where security and constant updates are as important as the product itself. The abilities of these systems to protect themselves, isolate applications inside sandboxes or containers, and support constant updates will enhance the product's security, its longevity and all the offered services around it. In this regard, Linux containers are one of the mechanisms that may allow to solve some of the Embedded and IoT systems problems, however their adoption is still facing some challenges such how can these mechanisms fit in the final embedded environment ? In order to improve container integration in the Embedded Linux world, we will explore in this presentation some upcoming systemd and Linux kernel features, notably a new Security Permission model for systemd, a new lightweight container environment that allows to deploy and sandbox portable applications, some new kernel hardening features that can be used by both containers and the kernel itself to protect the entire system. Additionally we will discuss how to apply constant updates, how we can integrate this with systemd, and how to update the entire system. Some of this or all of it is already or will be available by default in Yocto project. To conclude we will demonstrate some results on how to block real life vulnerabilities in such Embedded Linux systems. ASG2017-52-modern-deployment-for-embedded-linux-and-iot Security Djalal Harouni en In a world of connected devices, IoT and embedded systems, building robust products needs a modern deployment workflow where security and constant updates are as important as the product itself. The abilities of these systems to protect themselves, isolate applications inside sandboxes or containers, and support constant updates will enhance the product's security, its longevity and all the offered services around it. In this regard, Linux containers are one of the mechanisms that may allow to solve some of the Embedded and IoT systems problems, however their adoption is still facing some challenges such how can these mechanisms fit in the final embedded environment ? In order to improve container integration in the Embedded Linux world, we will explore in this presentation some upcoming systemd and Linux kernel features, notably a new Security Permission model for systemd, a new lightweight container environment that allows to deploy and sandbox portable applications, some new kernel hardening features that can be used by both containers and the kernel itself to protect the entire system. Additionally we will discuss how to apply constant updates, how we can integrate this with systemd, and how to update the entire system. Some of this or all of it is already or will be available by default in Yocto project. To conclude we will demonstrate some results on how to block real life vulnerabilities in such Embedded Linux systems. This presentation will contain: some kernel hardening measures, lightweight containers, new sandbox model and system updates. Also the integration with Yocto will be discussed so we can create better secure embedded Linux systems. Anyone who is interested in shipping portable secure applications for Embedded Linux systems, improving Embedded Linux and IoT security, kernel hardening and Linux kernel Self Protection projects bits for embedded systems is welcome. The Embedded and IoT industry is facing major security challenges, therefore there is a huge need for improvements. false https://cfp.all-systems-go.io/ASG2017/talk/112/ https://cfp.all-systems-go.io/ASG2017/talk/112/feedback/ Galerie presentation 2017-10-22T10:00:00+00:00 10:00 00:45 casync is a novel tool for delivering OS images across the Internet. While there are many tools like this around, casync has some features that set it apart. In this talk we'll discuss why it is useful for delivering your IoT, container, application or OS images, and how you can make use of it. ASG2017-53-synchronizing-images-with-casync Service Management Lennart Poettering en casync is a novel tool for delivering OS images across the Internet. While there are many tools like this around, casync has some features that set it apart. In this talk we'll discuss why it is useful for delivering your IoT, container, application or OS images, and how you can make use of it. false https://cfp.all-systems-go.io/ASG2017/talk/125/ https://cfp.all-systems-go.io/ASG2017/talk/125/feedback/ Galerie default 2017-10-22T10:45:00+00:00 10:45 01:30 None ASG2017-54-lunch default en Yummy food available from food trucks in the courtyard false https://cfp.all-systems-go.io/ASG2017/talk/153/ https://cfp.all-systems-go.io/ASG2017/talk/153/feedback/ Galerie presentation 2017-10-22T12:15:00+00:00 12:15 00:40 Nowadays, most end devices have multiple network interfaces to connect to the Internet. They usually pick a statically configured default interface, such as WiFi, which they prefer over LTE when both are available, but this is not necessarily the choice that provides the best performance to the application. Socket Intents is a research prototype that addresses the problem of finding policies of which network interface to pick for what kind of traffic or application. It provides several networking APIs through which an application can specify its "Intents", i.e., what it knows or assumes about its own traffic. The prototype then decides which of the available network interfaces to use. ASG2017-55-which-network-to-use-when-socket-intents Networking Theresa Enghardt en Hacking the Socket API for fun and research The Socket Intents framework is a research prototype developed at the INET group at TU Berlin, running in user space on Linux and Mac OS. It is written in C and released under a BSD license. Using the Socket Intents library, an application can set up a connection specifying its "Intents", e.g., whether the connection is going to be a small query or a large bulk transfer, whether it is intended to be a long-lived steady stream of data or a series of interactive bursts, and whether it is time-critical or background traffic. The client library then queries a daemon, the Multi Access Manager (MAM), to make a decision about which of the available network interfaces to bind this connection to, based on the Intents and on current performance estimates if available. Socket Intents aims to overcome the assumption that only one network interface would be available at a time, or that there is always the same statically configured "default" interface to use. By itself, the Socket API does not provide a good way to choose between different interfaces without placing the burden on the application. Instead of having each applications implement an interface selection logic by itself, Socket Intents provides one daemon, the Multi Access Manager, to gather as much information about the currently available network interfaces and their performance as possible. As it knows about the performance of the connected networks and about the needs of the application, based on its Intents, the Multi Access Manager can make decisions about which network interface to ues for what connection. It can also make decisions for individual objects, e.g., components of a web page, and schedule them among multiple persistens TCP connections that were established over multiple interfaces. Also, it is compatible with Multi-Path TCP (MPTCP) and can choose to schedule an object or connection over not a single interface, but multiple bundles interfaces. false https://cfp.all-systems-go.io/ASG2017/talk/138/ https://cfp.all-systems-go.io/ASG2017/talk/138/feedback/ Galerie presentation 2017-10-22T13:00:00+00:00 13:00 00:40 Containers are pretty cool, but in scenarios where they don't satisfy all the requirements, service providers still rely on virtualization. Hardware virtualization became mainstream 1 decade ago and it never stopped evolving. I even dare to say that virtualization is not boring anymore! In this presentation I will talk about the most significant hardware changes in the virtualization world. ASG2017-56-virtualization-what-changed-in-the-last-decade Process Isolation Hugo Tavares Reis en false https://cfp.all-systems-go.io/ASG2017/talk/136/ https://cfp.all-systems-go.io/ASG2017/talk/136/feedback/ Galerie presentation 2017-10-22T13:45:00+00:00 13:45 00:30 This presentation is about a new 802.11 wireless daemon for Linux. It is a lightweight daemon handling all aspects around WiFi support for Linux. It is designed with a tiny footprint for IoT use cases in mind. After its initial release last year, this provides the update on the progress and its integration into ConnMan and Network Manager. ASG2017-57-update-on-new-wifi-daemon-for-linux Networking Marcel Holtmann en false https://cfp.all-systems-go.io/ASG2017/talk/132/ https://cfp.all-systems-go.io/ASG2017/talk/132/feedback/ Galerie default 2017-10-22T14:15:00+00:00 14:15 00:15 None ASG2017-58-break default en Have a tea, coffee and/or Club Mate! false https://cfp.all-systems-go.io/ASG2017/talk/155/ https://cfp.all-systems-go.io/ASG2017/talk/155/feedback/ Galerie presentation 2017-10-22T14:30:00+00:00 14:30 00:10 The container has become one of the most overloaded industry buzzwords of the last five years. From Jails to LXC to Zones to systemd-nspawn Docker to rkt - there's an assortment of different tools on different platforms that call themselves containers, and no clear consensus what it means when it comes to distributing containers or implementing the underlying technical details. The Open Container Initiative was formed in 2015 to try to remedy this situation by establishing a shared set of container standards for different implementers to agree on. With representatives from all major server operating system platforms, the Initiative has made great strides towards specifying a truly interoperable container. The two key OCI projects recently hit their canonical 1.0 version; this talk will explain what OCI is and what that milestone means for the container ecosystem. ASG2017-59-what-s-in-a-container-the-oci-answer Process Isolation Jon Boulle en false https://cfp.all-systems-go.io/ASG2017/talk/157/ https://cfp.all-systems-go.io/ASG2017/talk/157/feedback/ Galerie presentation 2017-10-22T14:45:00+00:00 14:45 00:25 Used by many major distributions, systemd is widely known in the desktop and server world. But it is not so common to find it in embedded product. In this talk, we will show how systemd can be a real benefit for the embedded world; for both your sanity and your time. We will discuss how systemd was integrated into Phantom, a speaker from Devialet, and what was the pro and cons of using it. ASG2017-60-tango-with-systemd Service Management Maxime Hadjinlian en Building a product from scratch is a challenge, even more so with a small team. Every line of code that you don't have to maintain; every hour you win by using an already existing piece of code that solve your problem, is more hours you can spend creating new features for your product. Using systemd in an embedded device is not a choice done by many, but it can be really beneficial to your product, your team and yourself. We'll first start discussing how to reduce systemd to debunk the fact that it's huge. Then we will see the benefits of using systemd and how it can help you build your system without worrying. false https://cfp.all-systems-go.io/ASG2017/talk/128/ https://cfp.all-systems-go.io/ASG2017/talk/128/feedback/ Galerie presentation 2017-10-22T15:15:00+00:00 15:15 00:25 See how Red Hat's Session Recording project is using Systemd Journal to store and playback recordings of terminal sessions. Wonder at the challenges the project faces, such as dealing with various terminal types, character encodings, random playback positioning, etc. ASG2017-61-journal-as-a-storage-and-other-adventures-in-user-session-recording Security Nikolai Kondrashov en Red Hat's customers in financial, medical, government and other areas have been asking for a session recording feature for a while, and so the User Session Recording project was started. Nikolai Kondrashov is going to introduce our project briefly and then show how we use Systemd Journal to store and playback recordings of terminal sessions for our Cockpit UI. He is going to talk about limitations of, and possible improvements for this solution, and then about other challenges the project faces: dealing with different terminal types, character encodings, implementing recording playback, etc. And, of course, there is going to be a demo! false https://cfp.all-systems-go.io/ASG2017/talk/107/ https://cfp.all-systems-go.io/ASG2017/talk/107/feedback/