{"schedule": {"version": "v1", "base_url": "https://cfp.all-systems-go.io/ASG2018/schedule/", "conference": {"acronym": "ASG2018", "title": "All Systems Go! 2018", "start": "2018-09-27", "end": "2018-09-30", "daysCount": 4, "timeslot_duration": "00:05", "rooms": [{"name": "Loft", "guid": null, "description": null, "capacity": null}, {"name": "Kuppel", "guid": null, "description": null, "capacity": null}, {"name": "Gallerie", "guid": null, "description": null, "capacity": null}, {"name": "Kinvolk Office", "guid": null, "description": null, "capacity": null}, {"name": "Mein Haus am See", "guid": null, "description": null, "capacity": null}], "days": [{"index": 1, "date": "2018-09-27", "day_start": "2018-09-27T04:00:00+00:00", "day_end": "2018-09-28T03:59:00+00:00", "rooms": {"Kinvolk Office": [{"id": 62, "guid": "1839e651-edc0-57d3-8979-a4143971d9c2", "logo": "", "date": "2018-09-27T16:30:00+00:00", "start": "16:30", "duration": "03:00", "room": "Kinvolk Office", "slug": "ASG2018-62-pre-registration-meetup", "url": "https://cfp.all-systems-go.io/ASG2018/talk/227/", "title": "Pre-registration meetup", "subtitle": "", "track": "default", "type": "talk", "language": "en", "abstract": "Pre-registration meetup with talks where attendees can pickup badges and hangout.", "description": null, "recording_license": "", "do_not_record": false, "persons": [], "links": [], "attachments": [], "answers": []}]}}, {"index": 2, "date": "2018-09-28", "day_start": "2018-09-28T04:00:00+00:00", "day_end": "2018-09-29T03:59:00+00:00", "rooms": {"Loft": [{"id": 63, "guid": "69d34474-bdc5-55bd-86c0-d160323ac8cc", "logo": "", "date": "2018-09-28T07:30:00+00:00", "start": "07:30", "duration": "00:15", "room": "Loft", "slug": "ASG2018-63-opening", "url": "https://cfp.all-systems-go.io/ASG2018/talk/222/", "title": "Opening", "subtitle": "", "track": "default", "type": "default", "language": "en", "abstract": null, "description": null, "recording_license": "", "do_not_record": false, "persons": [], "links": [], "attachments": [], "answers": []}, {"id": 64, "guid": "1dcaeaa9-085c-5db5-8c4b-93a7705587dc", "logo": "", "date": "2018-09-28T07:45:00+00:00", "start": "07:45", "duration": "00:30", "room": "Loft", "slug": "ASG2018-64-little-services-big-risks", "url": "https://cfp.all-systems-go.io/ASG2018/talk/219/", "title": "Little Services, Big Risks", "subtitle": "", "track": "Service and Resource Management", "type": "talk", "language": "en", "abstract": "As we isolate functionality into services distributed across networks, we increasingly strain the concept of trust boundaries. Hosts are no longer simply trusted or untrusted, and each host comes with a new foothold for attackers. This risk is called the Confused Deputy Problem, and it\u2019s part of a growing number of attacks, including the one on Equifax. We need to stop assuming trusted services -- especially huge ones like those in traditional web stacks -- remain trustworthy. Capability-based models offer hope, but we need a few more patterns to use them with modern microservices.\n\nView Slide Deck", "description": "Extending capability-based security models to achieve micro-segmentation for grids of services\nThe Confused Deputy Problem has a history going back to early Unix. Attacks on passwd are a classic case. The architecture of passwd is simple: allow unprivileged users to invoke a setuid executable that performs a high-privilege operation under defined preconditions. This means passwd has been deputized to alter the passwords for all users. However, if you can confuse passwd into misusing its ambient authority, you can gain privileges. As a rule, a compromised service can do anything the service itself is allowed to do.\n\nOne of the answers has been Mandatory Access Control (MAC) like selinux. Firewalls are analogous for networked services. These systems operate by confining which principals can access which files or services. This helps somewhat; passwd has no business updating /boot (for example). However, in cases like Equifax, principals were only talking to the expected systems; the attacker used the web server to exfiltrate data from the database backing the web application, even accessing tables the web application would be expected to access.\n\nJust as with passwd, Equifax\u2019s problem was trusting an application to both perform its functionality and enforce authorization. Capability-based models are one answer: rather than trusting a complex service to enforce authorization against deeper systems, we provide the client with proof that it\u2019s allowed to access its own records and have the service forward this proof to deeper systems in order to read or manipulate corresponding records. It\u2019s now harder to turn a compromised service into a system-wide attack.\n\nSystems using capabilities are in widespread use: Kerberos, Google\u2019s Firebase, and concert tickets all use the concept of a token providing proof-of-authorization in a way decoupled from principals. However, things get weird when interaction is no longer directly between the primary principal (say, a web client) and nested services. Because possessing a capability is sufficient to exercise it, how do we handle cases where deeper services should have access to fewer (or more, or different) objects than the ones in front of them?\n\nIn this presentation, we\u2019ll look at state-of-the-art methods for delegating capabilities, including \u201csealing\u201d (reducing the authorization of shallow services) and original techniques to forward only a subset of the caller\u2019s capabilities (reducing the authorization of deep services), all designed for use with distributed services across networks.\n\nNote: The capabilities here are unrelated to Linux kernel capabilities. However, Linux does have some capabilities like the ones mentioned, including the idea of handing off a file descriptor from one application to another. This allows one app to open the FD and hand it to another that cannot (but can use the FD once in possession). Socket activating a web server on port 80 despite starting the web server as an unprivileged user is one example of handing off a capability via FD.", "recording_license": "", "do_not_record": false, "persons": [{"id": 12, "code": "8SUNZD", "public_name": "David Strauss", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 65, "guid": "c71bb5af-b8e2-5d00-ad15-db2bdc3170e5", "logo": "", "date": "2018-09-28T08:15:00+00:00", "start": "08:15", "duration": "00:30", "room": "Loft", "slug": "ASG2018-65-fedora-coreos", "url": "https://cfp.all-systems-go.io/ASG2018/talk/232/", "title": "Fedora CoreOS", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "What exactly is Red Hat up with CoreOS .....and what were they thinking when they announced a Fedora CoreOS? In this talk, we'll briefly look at some of the excellent work pioneered by the Container Linux team around the self-driving, container focused operating system. We'll also overlay how the container ecosystem has changed over the past 5 years and what we're doing at the OS-level to refocus and ultimately give users a better experience.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"id": 43, "code": "ZMMSAP", "public_name": "Ben Breard", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 66, "guid": "a9aed7b5-36bf-52b2-9cc8-7d8d1f904a86", "logo": "", "date": "2018-09-28T08:45:00+00:00", "start": "08:45", "duration": "00:30", "room": "Loft", "slug": "ASG2018-66-a-debugger-from-scratch-", "url": "https://cfp.all-systems-go.io/ASG2018/talk/213/", "title": "A debugger from scratch ", "subtitle": "", "track": "Monitoring & Tracing", "type": "talk", "language": "en", "abstract": "At some stage in your programming life you may well have used a debugger, but did you wonder how it was able to step into and control your executable? In this talk we'll see how debuggers work by building one from scratch in a few lines of Go.", "description": "In this talk Liz will explore how a debugger gains control of a process with the all-powerful ptrace system call. You'll see how we can find the machine code that corresponds to a line of human-readable source code and vice-versa. She will show how breakpoints are set, explain how the stack gets built up, and demonstrate how to generate a stack trace showing the path to that breakpoint. \n\nEven if you know nothing about machine code, you'll leave this talk with a better understanding of how a computer runs an executable, and how a debugger is able to start and stop the executable as you wish. ", "recording_license": "", "do_not_record": false, "persons": [{"id": 44, "code": "RF98FB", "public_name": "Liz Rice", "biography": "Maxime Hadjinlian is an embedded Linux engineer at Devialet. He was involved in the creation of the current and future software stack running on Devialet\u2019s product. He also contributes in his spare time to a few open-source projects, including Buildroot.", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 67, "guid": "92fcd838-6a42-5a39-a301-bc812a5c1184", "logo": "", "date": "2018-09-28T09:30:00+00:00", "start": "09:30", "duration": "00:45", "room": "Loft", "slug": "ASG2018-67-resource-control-fb", "url": "https://cfp.all-systems-go.io/ASG2018/talk/167/", "title": "Resource Control @FB", "subtitle": "", "track": "Service and Resource Management", "type": "talk", "language": "en", "abstract": "After years of development and experimentation, we finally have comprehensive OS-level work-conserving resource isolation working and are now in the process of deploying for various applications including workload protection and container stacking. This talk examines the project and the resulting resource control methods.", "description": "Functional resource control using cgroup2\nFB has been actively experimenting with cgroup2 resource control for years. In the process, we developed several kernel and userland mechanisms, fixed numerous isolation issues, and discovered a number of surprising interactions.\n\nWe finally have comprehensive OS-level work-conserving resource isolation working and are now in the process of refining and deploying the developed comprehensive resource isolation mechanism for various applications such as workload protection and container stacking.\n\nLet's take a look at the mistakes, the lessons, the result, and discuss how best this can be integrated into the whole operating system.", "recording_license": "", "do_not_record": false, "persons": [{"id": 46, "code": "CFWHAQ", "public_name": "Johannes Weiner", "biography": "Stef is an avid open source hacker. He's contributed to over a hundred open source projects. He can be found preaching about continuous integration and working on the Cockpit Linux admin interface. He's a usability freak. Stef lives in Germany, and works at Red Hat.", "answers": []}, {"id": 45, "code": "DFQYHR", "public_name": "Tejun Heo", "biography": "Holger Levsen has been a Debian user for 20 years and started contributing 15 years ago. He got involved in doing QA work on Debian in 2007 via first working on piuparts, which led him to start https://jenkins.debian.net in 2012. At the end of 2013 he had the idea to use this jenkins setup and a small script to build some packages twice and compare the results. That's how he got involved in Reproducible Builds.\r\n", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 68, "guid": "d05841f7-ca0e-53f1-820a-94d1b6f88f2f", "logo": "", "date": "2018-09-28T10:15:00+00:00", "start": "10:15", "duration": "00:30", "room": "Loft", "slug": "ASG2018-68-monitoring-file-system-syscalls-in-a-distributed-architecture", "url": "https://cfp.all-systems-go.io/ASG2018/talk/214/", "title": "Monitoring File System Syscalls in a Distributed Architecture", "subtitle": "", "track": "Monitoring & Tracing", "type": "talk", "language": "en", "abstract": "In a distributed world, monitoring system calls with kauditd can present challenges. In this talk we will address some of those challenges and give a use case of how we build an event pipeline for monitoring file system events.", "description": "With the rise of containers and generic container based operating systems we find ourselves with a large quantity of nodes that do general compute tasks. These nodes produce a large volume of audit data that we can leverage for many tasks. In our use case we wanted a way to monitor all file system changes in ways that we could not do with the existing libraries or tools. In this talk we will describe how we chose to use audit log system to monitor file system changes, how we built our system to scale and the pros and cons we have found from our solution. We will also talk about possible future work with respect to security and execution monitoring.", "recording_license": "", "do_not_record": false, "persons": [{"id": 47, "code": "AHXHYD", "public_name": "Daniel Feinberg", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 69, "guid": "3eb69099-fd56-54d2-b89c-4ee0aba3f29f", "logo": "", "date": "2018-09-28T10:45:00+00:00", "start": "10:45", "duration": "00:15", "room": "Loft", "slug": "ASG2018-69-monitoring-linux-capabilities-in-the-container-using-bpf", "url": "https://cfp.all-systems-go.io/ASG2018/talk/178/", "title": "Monitoring Linux Capabilities in the Container using BPF", "subtitle": "", "track": "Monitoring & Tracing", "type": "talk", "language": "en", "abstract": "Modern container engines such as systemd.nspawn and rkt provide a means of restricting privilege by limiting Linux capabilities. At Facebook, however, the heterogeneity of services and complexity of libraries running inside the container, along with our full init system model, make determining the set of capabilities that a task uses non-trivial. In this talk, we will discuss how we tackled this problem in a performant manner by building Capmond, a host-level daemon that leverages BPF to monitor capability usage by a process, and map it reliably to the associated container. Learn about the challenges we faced in making this work on our unique infrastructure, how this compares to known solutions such as auditd, and how we are leveraging Capmond to build sandboxes around capability usage, ssh sessions, system calls, and more. Capmond is in the process of being open sourced, so we'll also talk about how you can use it in your organization to help monitor your production systemd (nspawn) containers.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"id": 48, "code": "F3PHBF", "public_name": "William Smith", "biography": "CTO of superscale networks.\r\n15y into linux userspace in embedded devices.\r\nEx-Nokia/Trolltech", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 70, "guid": "21efd206-138b-50f7-a9f1-3bfa165cb02a", "logo": "", "date": "2018-09-28T12:15:00+00:00", "start": "12:15", "duration": "00:30", "room": "Loft", "slug": "ASG2018-70-fluent-bit-solving-logging-challenges-for-cloud-native-environments", "url": "https://cfp.all-systems-go.io/ASG2018/talk/193/", "title": "Fluent Bit: Solving Logging Challenges for Cloud Native Environments", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "Logging could be considered simple when dealing with a few applications, but in environments with distributed systems where log data comes from multiple sources and likely in different formats it becomes complex and data analysis harder.\n\nIn this session I will dig into the challenges of logging for distributed systems and the experience of building a tool called Fluent Bit to solve the problems associated with performance, unstructured data and log centralization within others.\n", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"id": 49, "code": "GGNFXM", "public_name": "Eduardo Silva", "biography": "", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 71, "guid": "41788abf-c19b-5414-a882-3f4dfcb33b9c", "logo": "", "date": "2018-09-28T12:45:00+00:00", "start": "12:45", "duration": "00:30", "room": "Loft", "slug": "ASG2018-71-cilium-bringing-the-bpf-revolution-to-kubernetes-networking-and-security", "url": "https://cfp.all-systems-go.io/ASG2018/talk/221/", "title": "Cilium - Bringing the BPF Revolution to Kubernetes Networking and Security", "subtitle": "", "track": "Networking", "type": "talk", "language": "en", "abstract": null, "description": null, "recording_license": "", "do_not_record": false, "persons": [{"id": 50, "code": "9S3VCC", "public_name": "Thomas Graf", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 72, "guid": "eca982b6-a228-59fd-a431-b82167efc576", "logo": "", "date": "2018-09-28T13:15:00+00:00", "start": "13:15", "duration": "00:30", "room": "Loft", "slug": "ASG2018-72-oomd", "url": "https://cfp.all-systems-go.io/ASG2018/talk/175/", "title": "oomd", "subtitle": "", "track": "Service and Resource Management", "type": "talk", "language": "en", "abstract": "Running out of memory on a host is a particularly nasty scenario. In the Linux kernel, if memory is being overcommitted, it results in the kernel out-of-memory (OOM) killer kicking in. In this talk, Daniel Xu will cover why the Linux kernel OOM killer is surprisingly ineffective and how oomd, a newly opensourced userspace OOM killer, does a more effective and reliable job. Not only does the switch from kernel space to userspace result a more flexible solution, but it also directly translates to better resource utilization. His talk will also do a deep dive into the Linux kernel changes and improvements necessary for oomd to operate.\n", "description": "A userspace OOM killer\nOut of memory killing has historically happened inside kernel space. On a memory overcommitted linux system, malloc(2) and friends will never fail. However, if an application dereferences the returned pointer and the system has run out of physical memory, the linux kernel is forced to OOM kill one or more processes. This is typically a slow and painful process because the kernel spends an unbounded amount of time swapping in and out pages and evicting the page cache. Furthermore, configuring policy is not very flexible while being somewhat complicated.\n\noomd aims to solve this problem in userspace. oomd leverages cgroupsv2 and newly exposed counters and statistics to monitor a system holistically. oomd takes corrective action in userspace before an OOM occurs in kernel space. Corrective action is configured via a flexible plugin system, in which custom code can be written. By default, this involves killing offending processes. This enables an unparalleled level of flexibility where each workload can have custom protection rules. Furthermore, time spent churning pages in kernelspace is minimized. In practice at Facebook, we've regularly seen 30 minute host lockups go away entirely.", "recording_license": "", "do_not_record": false, "persons": [{"id": 51, "code": "MPQM8J", "public_name": "Daniel Xu", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 73, "guid": "91d58678-70c6-5352-b8dd-85c9d61c26cc", "logo": "", "date": "2018-09-28T13:45:00+00:00", "start": "13:45", "duration": "00:30", "room": "Loft", "slug": "ASG2018-73-container-run-times-and-fun-times", "url": "https://cfp.all-systems-go.io/ASG2018/talk/179/", "title": "Container Run-times and Fun-times", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "A dive into the world of running systemd as an *in container* process manager at Facebook.", "description": "Using systemd inside a container @FB\nAt @FB we heavily utilize systemd on our servers. But, there's more! We also heavily utilize systemd inside our containers as well! Combined with our btrfs based image deployment mechanism we leverage all the good parts of systemd within our containers. I'll show how we utilize all the various components of systemd within a container, including how we use Portable Services! I'll talk about the philosophy of this design, our approach to building container images with systemd in mind, and our our approach to Runtime Composition of services. Come listen and enjoy a deep dive into how we use btrfs, systemd, and portable services, and what benefit it provides for us across our large container infrastructure.", "recording_license": "", "do_not_record": false, "persons": [{"id": 52, "code": "37BA99", "public_name": "Lindsay Salisbury", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 74, "guid": "1d89da90-dd51-5993-8111-459f59283106", "logo": "", "date": "2018-09-28T14:30:00+00:00", "start": "14:30", "duration": "00:45", "room": "Loft", "slug": "ASG2018-74-portable-services-are-ready-to-use", "url": "https://cfp.all-systems-go.io/ASG2018/talk/200/", "title": "Portable Services are Ready to Use", "subtitle": "", "track": "Service and Resource Management", "type": "talk", "language": "en", "abstract": "Portable Services bring certain aspects of containers to classic system service management. Let's discuss them in technical detail!", "description": "Portable Services bring certain aspects of containers to classic system service management. With systemd v239 Portable Services are for the first time complete and ready for users to take advantage of. In this talk we'll have a look on the underlying technical concepts, how things fit together and what the precise limitations and benefits are.", "recording_license": "", "do_not_record": false, "persons": [{"id": 14, "code": "PEZUVF", "public_name": "Lennart Poettering", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 75, "guid": "ff6639e6-d2c5-5b7e-a117-3604a951e839", "logo": "", "date": "2018-09-28T15:15:00+00:00", "start": "15:15", "duration": "00:45", "room": "Loft", "slug": "ASG2018-75-is-my-system-fast-", "url": "https://cfp.all-systems-go.io/ASG2018/talk/198/", "title": "Is my system fast?", "subtitle": "", "track": "Monitoring & Tracing", "type": "talk", "language": "en", "abstract": "Computer systems are complex. Most software applications are distributed and expected to scale. That does not make them any simpler. Further, there is the real world all of that is expected to work in. To analyze performance of such a system isn't less complex. Luckily, there is help. The Open Source universe is full of excellent tools that can help. The talk introduces a few of them.", "description": "An introduction of some tools that help to answer this question.\nThe talk walks down the path of comparing two Linux servers that look pretty much the same from the specs. Introducing test-tools like stress-ng, sysjitter, fio, packetdrill, and friends it is shown how to get a good overview of the systems CPU, memory, disk, and network performance.\n\nSince benchmark results are usually time variant a few basic statistical terms are refreshed and used for visualizing those results employing different chart types.\n\nThe field of performance analysis is wide. There isn't more time in 45 minutes than just to scratch the surface. At the end of the talk the audience will have a few pointers of how to start evaluating their own Linux systems to provide the right performance for their applications.", "recording_license": "", "do_not_record": false, "persons": [{"id": 53, "code": "ENWHJD", "public_name": "Frank Becker", "biography": "Sylvain is a principal software engineer at Red Hat. His main interests are networking and SDN solutions.", "answers": []}], "links": [], "attachments": [], "answers": []}], "Kuppel": [{"id": 76, "guid": "898c77fc-f781-5268-aebd-cf18da5b152a", "logo": "", "date": "2018-09-28T07:45:00+00:00", "start": "07:45", "duration": "00:45", "room": "Kuppel", "slug": "ASG2018-76-linuxboot-and-booting-fast", "url": "https://cfp.all-systems-go.io/ASG2018/talk/165/", "title": "LinuxBoot and booting fast", "subtitle": "", "track": "Booting", "type": "talk", "language": "en", "abstract": "In contrast to most firmware, like UEFI based or the BIOS, Linux is free software, has drivers for everything and is well known to the administrator. So why not use it in the firmware too? Some work has to be done though to fit it into the flash ROM chip and make it fast.", "description": "Use Linux as the bootloader and start the system up fast.\nDue to increases in flash ROM chip sizes, it\u2019s possible again to put the Linux kernel and an initrd there, and use Linux as a boot loader. In 2017 the LinuxBoot project joined the Linux Foundation, and several big companies backed it. This talk presents the project, the benefits and gives a short demonstration in conjunction with coreboot.\n\nTo achieve the goal, the Linux kernel should be adapted for the board to make it as small as possible. So, it\u2019s back to building your own Linux kernel. Additionally, the boot time should not suffer, so methods on how to profile and to improve start-up time are presented.\n\n", "recording_license": "", "do_not_record": false, "persons": [{"id": 54, "code": "XRJTRC", "public_name": "Paul Menzel", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 77, "guid": "577e1f62-aee3-5e93-88a7-52ea04a7088f", "logo": "", "date": "2018-09-28T08:45:00+00:00", "start": "08:45", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-77-http-tunneling-in-go-using-http-2-streams", "url": "https://cfp.all-systems-go.io/ASG2018/talk/205/", "title": "HTTP tunneling in Go using HTTP/2 streams", "subtitle": "", "track": "Networking", "type": "talk", "language": "en", "abstract": "This talk describes our experience developing Wormhole Connector, a distributed proxy component that connects external enterprise systems to a Kyma Kubernetes cluster. The connection between the Wormhole Connector and the Kubernetes cluster is based on HTTP/2, taking advantage of the stream concept to multiplex multiple connections (HTTP/1 or HTTP/2) through one active HTTP/2 connection.\n\nIt will cover how we use the Serf and Raft libraries to make the Wormhole Connector highly available, our experience using the Go standard library to support HTTP/2 connections, and technical details describing how everything works under the hood.", "description": "And making it highly available with Serf and Raft\nThis talk describes our experience developing Wormhole Connector, a distributed proxy component that connects external enterprise systems to a Kyma Kubernetes cluster. The connection between the Wormhole Connector and the Kubernetes cluster is based on HTTP/2, taking advantage of the stream concept to multiplex multiple connections (HTTP/1 or HTTP/2) through one active HTTP/2 connection.\n\nIt will cover how we use the Serf and Raft libraries to make the Wormhole Connector highly available, our experience using the Go standard library to support HTTP/2 connections, and technical details describing how everything works under the hood.", "recording_license": "", "do_not_record": false, "persons": [{"id": 8, "code": "GEWR7G", "public_name": "Iago L\u00f3pez Galeiras", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 78, "guid": "d1c13064-f695-575a-abbe-9542901ae5f7", "logo": "", "date": "2018-09-28T09:30:00+00:00", "start": "09:30", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-78-nettools", "url": "https://cfp.all-systems-go.io/ASG2018/talk/209/", "title": "nettools", "subtitle": "", "track": "Networking", "type": "talk", "language": "en", "abstract": "nettools is a yet-to-be-released project providing low-level libraries for network configuration. Within the scope of the project falls protocols like DHCP, NDP, IPv4 Address Conflict Detection, and IPv4LL. The first library scheduled to be released is IPv4ACD, a pre-release version of which is already used by NetworkManager. This talk gives an overview of the design principles of the project, the current status and the future plans.", "description": "A collection of network configuration libraries\n", "recording_license": "", "do_not_record": false, "persons": [{"id": 56, "code": "Z38YSP", "public_name": "David Herrmann", "biography": null, "answers": []}, {"id": 55, "code": "NLCPVA", "public_name": "Tom Gundersen", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 79, "guid": "eda89580-f60b-5941-8882-23ea5da96cbf", "logo": "", "date": "2018-09-28T10:00:00+00:00", "start": "10:00", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-79-being-compliant-with-open-container-initiative-spec", "url": "https://cfp.all-systems-go.io/ASG2018/talk/195/", "title": "Being compliant with Open Container Initiative Spec", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "Open Container Initiative (OCI) started in 2015 to make different implementations of container runtimes and images compliant with well-defined specifications. Together with other folks at Kinvolk, I have been involved in various OCI projects since months, and encountered various issues that occur in runtime specs and runtime-tools for verification. Since we live in a real world, not everything works well as expected. I\u2019m going to talk about practical issues, and possible ways to get it improved.", "description": "Open Container Initiative (OCI) defines container runtime specs (https://github.com/opencontainers/runtime-spec) as well as container image specs (https://github.com/opencontainers/image-spec) and distribution spec (https://github.com/opencontainers/distribution-spec).\n\nThere is also runtime-tools (https://github.com/opencontainers/runtime-tools) that helps container runtime to verify compliance of the runtime specifications. The standard container runtime is runc (https://github.com/opencontainers/runc) that is included in multiple high-level container managers like Docker or containerd. Most of the practical issues arise when specification is not clearly defined in the first place, or when container runtimes have own reasons for not being compliant with the specs, or when there\u2019s no consensus in the community how it should proceed. \n\nOn the other hand, container orchestration systems like Kubernetes have defined their own interfaces such as Container Runtime Interface (CRI). The different interfaces (OCI runtime and CRI) exist at different layers in the software stack. I'll show how CRI depends on OCI and some mismatches between them.\n\nIn this talk I want to introduce such practical issues, and try to suggest how we should proceed regarding spec compliance.\n", "recording_license": "", "do_not_record": false, "persons": [{"id": 35, "code": "ATCTEK", "public_name": "Dongsu Park", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 80, "guid": "9e24a7bb-9074-5fc5-8048-9b3974c2ab23", "logo": "", "date": "2018-09-28T10:30:00+00:00", "start": "10:30", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-80-from-physical-to-cloud-to-container", "url": "https://cfp.all-systems-go.io/ASG2018/talk/182/", "title": "From Physical to Cloud to Container", "subtitle": "", "track": "Foundations", "type": "talk", "language": "en", "abstract": "Uyuni, an opinionated fork of the Spacewalk project, provides open source lifecycle management for today's datacenter.\nWith the help of Salt for configuration management it keeps your workloads up to date and secure.", "description": "One system to deploy and manage them all\nUyuni manages all your Linux workloads. It bootstraps physical servers, creates VMs for virtualization and cloud, builds container images, and tracks what runs on your Kubernetes clusters.\nUyuni is open source, backed by SUSE Linux, and actively developed.\nThis presentation will give an overview about this project, it's current possibilities for managing datacenters, and briefly talk about future plans.", "recording_license": "", "do_not_record": false, "persons": [{"id": 57, "code": "KVYEQE", "public_name": "Klaus K\u00e4mpf", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 81, "guid": "ade44a61-1039-5022-bc53-eeef412524bf", "logo": "", "date": "2018-09-28T11:00:00+00:00", "start": "11:00", "duration": "00:15", "room": "Kuppel", "slug": "ASG2018-81-playing-with-casync-instagram", "url": "https://cfp.all-systems-go.io/ASG2018/talk/210/", "title": "Playing with casync @ instagram", "subtitle": "", "track": "Foundations", "type": "talk", "language": "en", "abstract": "In Instagram, we have been experimenting with casync as an alternative package format for deployment of the site. This talks describe our findings", "description": "Last year when Lennart presented in ASG about casync, we were excited to check it out. So we checked what was necessary to deploy parts of our sites with it. and we spend some times experimenting... This talk show our results, so far...", "recording_license": "", "do_not_record": false, "persons": [{"id": 58, "code": "GJTUGA", "public_name": "Alvaro Leiva Geisse", "biography": "", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 82, "guid": "4edbd7df-c956-55ae-afae-deee4f4e3e35", "logo": "", "date": "2018-09-28T12:15:00+00:00", "start": "12:15", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-82-path-agnostic-binaries-co-installable-libraries-and-how-to-have-nice-things", "url": "https://cfp.all-systems-go.io/ASG2018/talk/204/", "title": "Path-agnostic binaries, co-installable libraries, and How To Have Nice Things", "subtitle": "", "track": "Foundations", "type": "talk", "language": "en", "abstract": "Portability is a shining goal for all software -- an objective since the beginning of computing through the present. And yet, it also remains illusive. We once sought to develop software \"portable\" between whole OSes and kernels; today, we've lost control of our build and distribution pipelines so completely that portability of a binary between two barely-different distributions of linux is considered radical and nearly impossible. Even \"portability\" of a binary when moving between two directories on the same host is often a trial by fire. In this talk, we will define and discuss two specific kinds of portability -- what it means to build path-agnostic libraries and what it means to support co-installable libraries -- then explore what this kind of freedom could do for us, and most importantly, practical ways to achieve these goals within existing systems.", "description": "Computers are general purpose computers -- they can run any program.\n\nBut theory aside, is that really true? Forget tivoization and the rise of walled-garden app stores -- when considering new software, often one of the first questions we ask ourselves as linux users is \"Is it available on ${distro|packman}?\"... We've already been doing this to ourselves for decades. Source builds are possible, but remain full of \"well actually\" moments; containerization hints at the sheer popularity of The Dream of escaping this madness; and yet, most of our day to day business is guided and limited by what's available in a package manager, and our machines as a whole are limited by which package manager we've chosen.\n\nDistributions become inherently balkanized: no one can install anyone else's packages with anything short of a full chroot. Why? Nobody *wants* this. The fracturing creeps in from somewhere. Is it something we can fix?\n\nWhat would it look like if we tried to define packages without distros? Packages without the need for management, beyond drag and drop? Packages with *bring your own* management? Easily relocatable, path-agnostic binaries, and co-installable libraries -- all of them able to work together, or be shipped independently at the user's choice, free of version conflicts in either form?\n\nWe can have all these things. And if you think this is going to be a talk about static linking, think again: there are more options, and there are things we can do now, and we can do them within the ecosystems and infrastructure of existing distros non-disruptively.\n\nThere are already a variety of approaches to producing relocatable binaries: from static linking, to snapshots and images which require chroots to be executable, to content-addressable (but still absolute-pathed) dynamic linking -- distros and tools using all of these approaches exist. In this talk, we'll survey all of them, plus go beyond into approaches to dynamic linking which are free from absolute paths completely. Finally, we'll compare and contrast all these approaches, map any limitations and assumptions, and try to plot a road ahead.", "recording_license": "", "do_not_record": false, "persons": [{"id": 10, "code": "KWCMGE", "public_name": "Eric Myhre", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 83, "guid": "7feccd91-4b36-5087-a584-8adbe9e0d0bb", "logo": "", "date": "2018-09-28T12:45:00+00:00", "start": "12:45", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-83-to-run-an-app-with-guarantees-we-must-first-create-the-universe-", "url": "https://cfp.all-systems-go.io/ASG2018/talk/162/", "title": "To Run an App With Guarantees We Must First Create The Universe ", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "We\u2019ll look at patterns and anti-patterns for self-contained, immutable runtime environment for applications using Habitat, with a focus on special cases, integrated testing and advanced hacks. ", "description": "Lessons from managing self-contained application runtimes in production\n", "recording_license": "", "do_not_record": false, "persons": [{"id": 5, "code": "NUALJN", "public_name": "Blake Irvin", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 84, "guid": "8f1a99e4-eb8d-5c52-96aa-93a494089c86", "logo": "", "date": "2018-09-28T13:15:00+00:00", "start": "13:15", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-84-systemd-in-2018", "url": "https://cfp.all-systems-go.io/ASG2018/talk/230/", "title": "systemd in 2018", "subtitle": "", "track": "Service and Resource Management", "type": "talk", "language": "en", "abstract": null, "description": null, "recording_license": "", "do_not_record": false, "persons": [{"id": 14, "code": "PEZUVF", "public_name": "Lennart Poettering", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 85, "guid": "027d500a-b7fc-5ab9-bd94-eb474d79cbca", "logo": "", "date": "2018-09-28T13:45:00+00:00", "start": "13:45", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-85-dbus-broker", "url": "https://cfp.all-systems-go.io/ASG2018/talk/208/", "title": "dbus-broker", "subtitle": "", "track": "Desktop", "type": "talk", "language": "en", "abstract": "dbus-broker is an implementation of the DBus specification, intended to be a drop-in replacement for the reference implementation on Linux. It is now scheduled to be the default system and user bus in the next Fedora release. This talks shows some of the lessons learned during this relatively young project, the challenges faced, what the current status is and the plans for the future.", "description": "Status update\n", "recording_license": "", "do_not_record": false, "persons": [{"id": 56, "code": "Z38YSP", "public_name": "David Herrmann", "biography": null, "answers": []}, {"id": 55, "code": "NLCPVA", "public_name": "Tom Gundersen", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 86, "guid": "de5fef69-7091-5077-91f0-13d971b7033a", "logo": "", "date": "2018-09-28T14:30:00+00:00", "start": "14:30", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-86-titus-adventures-in-multi-tenant-scheduling", "url": "https://cfp.all-systems-go.io/ASG2018/talk/203/", "title": "Titus: Adventures in Multi-tenant Scheduling", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "Titus is a multitenant scheduler that runs a variety of workloads that vary from online workloads which serve customer traffic to big data workloads which perform machine learning. Getting all of these workloads to cooperate on a shared pool of resources together. Just to add a bit of complexity to the mix, these workloads all run on the cloud, and a shared storage and network fabric. Come to this talk to learn about how our approach to multi-tenancy works, as well as some of the challenges we faced along the way. \n", "description": "Titus is a system which allows users to submit arbitrary container workloads to the cloud, and get their workloads running across many thousands of cores or more. This comes with a variety of challenges. We attacked this problem with a three-pronged approach. \n\nOur approach to scheduling is multi-tenant first. Our scheduler understands different workloads and the fact that different workloads have different Service Level Objectives. In addition to this, it understands the cloud, and the fact it\u2019s a shared control plane. Lastly, we\u2019ve had to teach our scheduler to handling situations during failover, and when scaling up is key versus traditional scheduling.\n\nOur approach to systems is evolving. Historically, our fleet was many single-tenant VMs. We\u2019ve attacked systems level multi-tenancy from the multiple perspectives. The first of these involved giving our user the APIs that were as close to what they had on the VM. Subsequently, we\u2019ve tried to enable security mechanisms like seccomp and apparmor that allow us to run nearly any workload on Titus. Lastly, we\u2019re still figuring out resource isolation. Cgroups have come a long way, but there is a long way to go ahead before we can be as good as VMs.\n\nAll of our infrastructure runs on the cloud. We decided that our approach to scheduling, and systems multi-tenancy should be cloud native, and leverage as many mechanisms as possible that already exist in the cloud rather than invent our own. Although this gave us a massive head start, it didn\u2019t come for free. We had to solve problems like coordination-free optimistic interactions with our SDN, and solutions to shared-storage. \n", "recording_license": "", "do_not_record": false, "persons": [{"id": 59, "code": "DCGWTQ", "public_name": "Sargun Dhillon", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 87, "guid": "08796f26-bd92-5c57-8c3a-244804f16df6", "logo": "", "date": "2018-09-28T15:00:00+00:00", "start": "15:00", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-87-thunderbolt-3-hardware-enablement-for-gnu-linux", "url": "https://cfp.all-systems-go.io/ASG2018/talk/180/", "title": "Thunderbolt 3 hardware enablement for GNU/Linux", "subtitle": "", "track": "Foundations", "type": "talk", "language": "en", "abstract": "Thunderbolt 3 is a high-speed IO technology that can be used to connect docks, graphic cards or other peripherals requiring high speed. However, the mechanism that allows these high speeds also poses a security risk because malicious devices could obtain sensitive information from the computer's memory. As a result kernel provides an interface to authorize thunderbolt devices before they can be used. The talk will explain the technology and explain the enablement we did to make thunderbolt 3 work for GNU/Linux.", "description": "Thunderbolt 3 is a relatively new technology to connect peripherals to a computer. Because it can access the computer's resources directly, it allows for very high speeds: it is fast enough to drive external graphics cards.\nHowever, the mechanism that allows these high speeds also poses a security risk because malicious devices could obtain sensitive information from the computer's memory.\nVersion 3 of the Thunderbolt interface therefore provides security levels in order to mitigate the aforementioned security risk that connected devices pose to the system. As a result, devices need to be authorized manually. The talk aims to provide an overview of the Thunderbolt technology and will try to clarify some of the confusing aspects, e.g. the many modes and features of the USB type C connector that Thunderbolt 3 uses. Finally, the talk will show how some tricky user experience problems were solved,", "recording_license": "", "do_not_record": false, "persons": [{"id": 60, "code": "8ZMF8L", "public_name": "Christian Kellner", "biography": "Michael is a Software Engineer from Berlin where he works on low-level Linux software at Kinvolk GmbH, a Linux development company. Before that, he was working as a Backend and Operations Engineer for a Swiss Infrastructure-as-a-Service provider.", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 88, "guid": "de535705-f0b9-5fd6-8695-25f950916f69", "logo": "", "date": "2018-09-28T15:30:00+00:00", "start": "15:30", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-88-bpf-and-the-future-of-the-kernel-extensibility", "url": "https://cfp.all-systems-go.io/ASG2018/talk/229/", "title": "BPF and the future of the kernel extensibility", "subtitle": "", "track": "Monitoring & Tracing", "type": "talk", "language": "en", "abstract": null, "description": "To bring cool ideas to life, the Linux kernel and user space need to work together. The core kernel is a stable ABI base, a common denominator for everything that builds on top. In contrast, BPF is a specific know-how, a secret sauce of the cool idea. The Linux kernel needs BPF to stay relevant, and BPF has to become friendlier to programmers. This talk explores the steps taken towards this long-term goal, from recently introduced BPF-to-BPF functions and type information to bounded loops, memory allocation, and beyond.", "recording_license": "", "do_not_record": false, "persons": [{"id": 61, "code": "AH33XY", "public_name": "Alexei Starovoitov", "biography": "A self-taught software engineer. Interested in low-level and embedded programming. Working at Red Hat Common Logging team. Founder of the DIGImend project. Born in Russia, living in Finland.", "answers": []}], "links": [], "attachments": [], "answers": []}], "Mein Haus am See": [{"id": 89, "guid": "9c90b9a2-dd3a-59aa-b8c5-d01353172f8b", "logo": "", "date": "2018-09-28T17:00:00+00:00", "start": "17:00", "duration": "04:45", "room": "Mein Haus am See", "slug": "ASG2018-89-social-event", "url": "https://cfp.all-systems-go.io/ASG2018/talk/228/", "title": "Social event", "subtitle": "", "track": "default", "type": "default", "language": "en", "abstract": "TBA", "description": null, "recording_license": "", "do_not_record": false, "persons": [], "links": [], "attachments": [], "answers": []}]}}, {"index": 3, "date": "2018-09-29", "day_start": "2018-09-29T04:00:00+00:00", "day_end": "2018-09-30T03:59:00+00:00", "rooms": {"Loft": [{"id": 90, "guid": "87445950-c9f6-5221-8ce2-97cf7318da85", "logo": "", "date": "2018-09-29T07:30:00+00:00", "start": "07:30", "duration": "00:30", "room": "Loft", "slug": "ASG2018-90-cri-o-all-the-runtime-kubernetes-need", "url": "https://cfp.all-systems-go.io/ASG2018/talk/211/", "title": "CRI-O: All the Runtime Kubernetes need", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": null, "description": "CRI-O is a brand new container runtime dedicated and optimized to support kubernetes workload. Its goal is to be a stable container runtime tied to kubernetes releases, replacing the docker daemon.\n\nHistorically every update of Docker has broken Kubernetes. This has led to major rewriting and fixes of Kubernetes, which is understandable since Docker is not primarily for Kubernetes. Kubernetes needs a container runtime dedicated to its specifications.\n\nCRI-O, the name comes from the Container Runtime Interface for Open container runtimes, takes advantages of emerging standards like OCI Runtime and Image Specification, as well as open source projects to handle container images (github.com:containers/image, github.com:containers/storage) . This means as these projects advance CRI-O will be able to take advantage of the improvements and features, but all the while guaranteeing that it will not break any functionality required by the Kubernetes CRI. CRI-O works with runc and Clear Containers runtimes.\n\nCRI-O was designed from the ground up to satisfy Kubernetes Container Runtime Interface, and currently passes all node and E2E tests. The github repository has been setup to not accept any pull requests that causes these tests to break. We will be tying the versions of CRI-O to the Kubernetes versions, to maintain complete compatibility.\n\nThis talk will describe the CRI-O architecture as well as demonstrate different kubernetes features running on top of CRI-O exercising the CRI API. The attendees will learn how to configure CRI-O with kubernetes and use it for their workloads.", "recording_license": "", "do_not_record": false, "persons": [{"id": 62, "code": "YF9YLL", "public_name": "Antonio (runcom) Murdaca", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 91, "guid": "5e234c74-97e5-5bb5-abf4-1097a03a9b88", "logo": "", "date": "2018-09-29T08:00:00+00:00", "start": "08:00", "duration": "00:30", "room": "Loft", "slug": "ASG2018-91-state-of-systemd-facebook", "url": "https://cfp.all-systems-go.io/ASG2018/talk/192/", "title": "State of systemd @ Facebook", "subtitle": "", "track": "Service and Resource Management", "type": "talk", "language": "en", "abstract": "We'll be covering happenings, learnings and new challenges running and supporting systemd in production on the Facebook fleet throughout the past year.", "description": "This talk is a followup to systemd @ Facebook \u2014 a year later that was presented last year. We'll cover the latest developments, how we're leveraging new systemd features, how we continue rolling systemd on the fleet, and finally discuss a number of interesting case studies.", "recording_license": "", "do_not_record": false, "persons": [{"id": 7, "code": "3SCYJP", "public_name": "Davide Cavalca", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 92, "guid": "2e0ad72f-9346-5d4d-acb0-289be3c7a49b", "logo": "", "date": "2018-09-29T08:30:00+00:00", "start": "08:30", "duration": "00:30", "room": "Loft", "slug": "ASG2018-92-container-runtimes-draw-some-lines", "url": "https://cfp.all-systems-go.io/ASG2018/talk/186/", "title": "Container Runtimes: draw some lines", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "Future of connecting to the container runtime as docker phases out", "description": "Since docker came on the scene in 2013, for many it was the first they'd heard of containers. They existed before, and an have exploded since then. Today if you intend on running containers in production it means at the kubernetes level, though what is happening below that? what does this mean for direct access and on-going developer experience? ", "recording_license": "", "do_not_record": false, "persons": [{"id": 63, "code": "TMFY8N", "public_name": "Vincent Batts", "biography": "Originally from South Korea, he settled in Berlin a few years ago. In the past he did mainly Linux system programming when working for a German IaaS provider. Recently he has been involved in open source projects such as systemd, fleet, rkt. He usually works in Go and C, and also likes to learn about fresh programming languages like Rust.", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 93, "guid": "39077285-bcdf-5d5a-9244-8ae2e21f0b69", "logo": "", "date": "2018-09-29T09:00:00+00:00", "start": "09:00", "duration": "00:15", "room": "Loft", "slug": "ASG2018-93-passive-filesystem-verification", "url": "https://cfp.all-systems-go.io/ASG2018/talk/185/", "title": "Passive filesystem verification", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "A more generic approach to ensure you have what you'd expect to have", "description": "(and massage)\nA side effect of the many new ways to package filesystems (here's looking at you, containers!), is that filesystems are being copied around without many of the features that traditional packaging provided (i.e. `rpm -qV ...`). Much progress has been made for reproducible digests of containers. In this talk Vincent Batts will review options for distributing filesystems with reproducibility, and verifying the at-rest outcomes.", "recording_license": "", "do_not_record": false, "persons": [{"id": 63, "code": "TMFY8N", "public_name": "Vincent Batts", "biography": "Originally from South Korea, he settled in Berlin a few years ago. In the past he did mainly Linux system programming when working for a German IaaS provider. Recently he has been involved in open source projects such as systemd, fleet, rkt. He usually works in Go and C, and also likes to learn about fresh programming languages like Rust.", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 94, "guid": "570412ea-3d98-5c3f-9fda-681226467854", "logo": "", "date": "2018-09-29T09:30:00+00:00", "start": "09:30", "duration": "00:45", "room": "Loft", "slug": "ASG2018-94-flatpak-a-technical-walkthrough", "url": "https://cfp.all-systems-go.io/ASG2018/talk/181/", "title": "Flatpak, a technical walkthrough", "subtitle": "", "track": "Desktop", "type": "talk", "language": "en", "abstract": "Flatpak is a desktop-focused application distribution and deployment\nsystem for linux. This talk will walk through the technical\ndetails of the core functionallity and explain how it work and\nwhy it works that way.\n", "description": "
\nFlatpak has now had a major stable release and the rate of change is\nslowing down. This is a good time to take a look at how the\nthings work behind the scenes.\n
\n\nThis talk will go through the technical details behind flatpak,\nexplaining things like ostree, bubblewrap and how flatpak uses this to\nimplement the sandbox and basic flatpak commands. It will also explain\nin high-level terms how the portals and other desktop integration\nfeatures work.\n
", "recording_license": "", "do_not_record": false, "persons": [{"id": 9, "code": "KBBBGM", "public_name": "Alexander Larsson", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 95, "guid": "d44a6949-2dc7-5501-9557-ee46dece2f19", "logo": "", "date": "2018-09-29T10:15:00+00:00", "start": "10:15", "duration": "00:45", "room": "Loft", "slug": "ASG2018-95-kexec-kdump-under-the-hood-", "url": "https://cfp.all-systems-go.io/ASG2018/talk/169/", "title": "Kexec/Kdump under the hood ", "subtitle": "", "track": "Booting", "type": "talk", "language": "en", "abstract": "Kdump is a vital tool for debugging severe kernel crashes, especially if the failure can't be reproduced easily or an direct access to the system is not possible.\n\n", "description": "How to debug your crashed system\nKdump is a vital tool for debugging severe kernel crashes, especially if the failure can't be reproduced easily or an direct access to the system is not possible.\n\nWhen an sever error happens in the kernel, a new crash kernel get loaded which saves the memory of the crashed system. These dump can be used to analyze the state of the machine and hopefully give insights on what has happened.\n\nThis talks will dive into the internals of kexec and kdump. How the crash kernel get set-up, how it's execution get triggered. We will also look into kexec-tool, the user-space part needed to set up a system to use kdump. Where necessary, the architectural specific details will be explained by looking at the arm64 implementation. This talk is thought for people who want to have an insight into how kdump is working.", "recording_license": "", "do_not_record": false, "persons": [{"id": 64, "code": "F8XX9F", "public_name": "Matthias Brugger", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 96, "guid": "95ad815f-a2d5-56cd-ad44-a5d5d525c6cf", "logo": "", "date": "2018-09-29T12:15:00+00:00", "start": "12:15", "duration": "00:30", "room": "Loft", "slug": "ASG2018-96-using-machine-learning-to-find-linux-bugs", "url": "https://cfp.all-systems-go.io/ASG2018/talk/207/", "title": "Using Machine Learning to find Linux bugs", "subtitle": "", "track": "Foundations", "type": "talk", "language": "en", "abstract": "I\u2019d like to show you how to find bugs in Linux systems using machine learning, when paired with the totally seemingly useless and annoying false positives that come out of your integration tests. \n", "description": "I\u2019d like to show you how to find bugs in Linux systems using machine learning, when paired with the totally seemingly useless and annoying false positives that come out of your integration tests. \n\nWe\u2019ve all been frustrated unreproducible bugs in Linux \u2026 And also by stupid test-flakes that show up as failures in integration tests even though nothing related has changed. Both unproducible bugs and test flakes are the result of permutations in timing, load, ordering.\n\nI want to prove that unreproducible bugs are the same thing as test flakes. And we have a massive source of data here, millions of records of test flakes.\n\nLets take a look at how the Cockpit project trains bots to correlate these flakes into unsupervised clusters. and automatically make use of the data, identifying real bugs, or simply retriggering tests. \n\nWe\u2019ll dive into details about Normalized Compression Distance, Unsupervised Clustering, TF-IDF and many other simple techniques used to zero in on the bugs.\n", "recording_license": "", "do_not_record": false, "persons": [{"id": 20, "code": "EYRNSC", "public_name": "Stef Walter", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 97, "guid": "b241d524-2528-5bfe-962f-a6bfca855c2b", "logo": "", "date": "2018-09-29T13:00:00+00:00", "start": "13:00", "duration": "00:45", "room": "Loft", "slug": "ASG2018-97-replacing-docker-with-podman", "url": "https://cfp.all-systems-go.io/ASG2018/talk/177/", "title": "Replacing Docker with Podman", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "This talk will describe all of the reasons for podman, all of its features demonstrate its functionality, ", "description": "Simple tool for running pods and containers\nI will cover the background of podman, how we built it, why we built it, \nI will demonstrate using it in multiple different ways, \nRunning containers\nbuilding container images\nCommunicating with it via var link, cockpit integration.\nCommunicating with it from a remote machine.", "recording_license": "", "do_not_record": false, "persons": [{"id": 65, "code": "XWBLSH", "public_name": "Dan Walsh", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 98, "guid": "f4103f2c-61a8-5741-ac7b-3df6276565c9", "logo": "", "date": "2018-09-29T13:45:00+00:00", "start": "13:45", "duration": "00:30", "room": "Loft", "slug": "ASG2018-98-fearless-multimedia-programming", "url": "https://cfp.all-systems-go.io/ASG2018/talk/172/", "title": "Fearless Multimedia Programming", "subtitle": "", "track": "Desktop", "type": "talk", "language": "en", "abstract": "Whether you are interested in multimedia programming in specific or curious about how Rust programming language can enable you to write almost-bug-free code without having to compromise on efficiency, this talk is for you.", "description": "GStreamer is a popular framework of choice for multimedia programming in the Linux world, especially for embedded. Since efficiency is a typical core requirement for embedded solutions, traditionally C/C++ have been the languages of choice for writing GStreamer applications and plugins. Unfortunately, this efficiency comes at the price of safety. Even the most skilled C/C++ developers make mistakes with memory management and the results could potentially be catastrophic. Thread safety is another aspect that is central to multimedia solutions but is extremely difficult to achieve with C/C++.\n\nRust language is designed to be both efficient and safe at the same time. In this talk, Zeeshan will present how GStreamer's Rust bindings not only make multimedia programming a lot safer, easier and fun but also allow developers to write even more efficient code than C/C++ in certain cases.\n\nWhile the talk will be focused on multimedia and GStreamer in specific, most of the concepts presented shall be very generic.", "recording_license": "", "do_not_record": false, "persons": [{"id": 4, "code": "WPLP97", "public_name": "Zeeshan Ali", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 99, "guid": "d8ee2b20-0488-5c34-b03d-2e1b693f5812", "logo": "", "date": "2018-09-29T14:30:00+00:00", "start": "14:30", "duration": "00:30", "room": "Loft", "slug": "ASG2018-99-netboot21-bootloaders-in-the-21st-century", "url": "https://cfp.all-systems-go.io/ASG2018/talk/215/", "title": "Netboot21: Bootloaders in the 21st Century", "subtitle": "", "track": "Booting", "type": "talk", "language": "en", "abstract": "Sick of insecure PXE booting over TFTP? Come learn about our efforts to write modern boot loaders in Linux's user space.", "description": "User-space bootloaders with LinuxBoot\nLinuxBoot is a project to put Linux kernels into firmware. LinuxBoot means we have the full toolset of modern languages like Go at our fingertips: let's use them! We can now easily develop boot loaders with trivial support for HTTPS-, gRPC- or TPM-based network booting.", "recording_license": "", "do_not_record": false, "persons": [{"id": 66, "code": "D7UUWT", "public_name": "Chris Koch", "biography": "Iago brought his relaxed Spanish demeanor to Berlin a few years back. Since then, he\u2019s been diving and swimming around the internals of various Linux flavors; Android, embedded and Cloud. He\u2019s a top contributor to the rkt project and for the past year he was pushing the limits of eBPF to get runtime statistics. Although he once got distracted by functional programming, his daily tasks see him working mainly in Go and C.", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 100, "guid": "2ae9cfef-c1c1-5d34-a722-04f71bb72132", "logo": "", "date": "2018-09-29T15:00:00+00:00", "start": "15:00", "duration": "00:30", "room": "Loft", "slug": "ASG2018-100-efficient-network-analytics-with-bpf-ebpf-using-skydive", "url": "https://cfp.all-systems-go.io/ASG2018/talk/202/", "title": "Efficient Network Analytics with BPF/eBPF using Skydive", "subtitle": "", "track": "Monitoring & Tracing", "type": "talk", "language": "en", "abstract": "Efficient monitoring of large-scale networks poses a delicate balance between capture granularity on the one hand and the imposed overheads and performance penalties on the other. Skydive is an open source real-time network topology and protocol analyzer, featuring smart network collection which is both granular and efficient. Skydive allows for efficient network monitoring at scale through Linux networking features such as BPF and eBPF. \n\nIn the talk we will present Skydive and will give an update of the features that introduced since one year. We will show how Skydive leverages eBPF to produce useful insights on top of network topology information. We will share some performance results showing the efficiency of Skydive BPF/eBPF capturing in the context of a Kubernetes deployment.\n", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"id": 17, "code": "GYY9MR", "public_name": "Sylvain Afchain", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 101, "guid": "ec9dd9b4-00a8-50dc-be7f-ac810d39e812", "logo": "", "date": "2018-09-29T15:30:00+00:00", "start": "15:30", "duration": "00:30", "room": "Loft", "slug": "ASG2018-101-lightning-talks", "url": "https://cfp.all-systems-go.io/ASG2018/talk/233/", "title": "Lightning Talks", "subtitle": "", "track": "default", "type": "talk", "language": "en", "abstract": "Please submit your talks to mpitt [at] redhat [dot] com or to organizers at the venue", "description": "Submit Your Talks at the Venue\n", "recording_license": "", "do_not_record": false, "persons": [], "links": [], "attachments": [], "answers": []}, {"id": 102, "guid": "01c8b84a-590e-508d-a1b8-1be3a6f10146", "logo": "", "date": "2018-09-29T16:00:00+00:00", "start": "16:00", "duration": "00:30", "room": "Loft", "slug": "ASG2018-102-closing", "url": "https://cfp.all-systems-go.io/ASG2018/talk/223/", "title": "Closing", "subtitle": "", "track": "default", "type": "default", "language": "en", "abstract": null, "description": null, "recording_license": "", "do_not_record": false, "persons": [], "links": [], "attachments": [], "answers": []}], "Kuppel": [{"id": 103, "guid": "619b044d-663e-53fa-9de6-08bbf2401a07", "logo": "", "date": "2018-09-29T07:30:00+00:00", "start": "07:30", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-103-scale-your-auditing-events", "url": "https://cfp.all-systems-go.io/ASG2018/talk/216/", "title": "Scale Your Auditing Events", "subtitle": "", "track": "Monitoring & Tracing", "type": "talk", "language": "en", "abstract": "The Linux Audit daemon is responsible for writing audit records to the disk, which you can then access with ausearch and aureport. However, it turned out that parsing and centralizing these records is not as easy as you would hope. Elastic's new Auditbeat fixes this by keeping the original configuration, but ships them to a centralized location where you can easily visualize all events.", "description": "You can also use Auditbeat to detect changes to critical files, like binaries and configuration files, and identify potential security policy violations. This talk shows you what can you do to discover changes, events, and potential security breaches as soon as possible on interactive dashboards. Additionally, we are combining Auditd events with logs, which are security relevant.", "recording_license": "", "do_not_record": false, "persons": [{"id": 67, "code": "CTRKAH", "public_name": "Philipp Krenn", "biography": "Stephen Hemminger is a Linux developer who specializes in networking. He is maintainer of the Linux bridging and the iproute2 utilities. Having been involved with TCP/IP since the early days of UNIX. He is a member of the DPDK Technical Advisory Board. Steve has written many network drivers for Linux including netem, vxlan, and Marvell sky2 Ethernet devices. Many of his contributions have involved integrating so many different networking pieces that he decided to give himself the title of Network Plumber.", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 104, "guid": "f329f096-3080-5a15-8519-08712df35409", "logo": "", "date": "2018-09-29T08:00:00+00:00", "start": "08:00", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-104-peer-to-peer-os-and-flatpak-updates", "url": "https://cfp.all-systems-go.io/ASG2018/talk/220/", "title": "Peer to peer OS and flatpak updates", "subtitle": "", "track": "Desktop", "type": "talk", "language": "en", "abstract": "Recently, work that we have been doing on Endless OS to allow peer to peer OS and flatpak updates has been reaching maturity and nearing wider deployment. This talk will give an overview of how we support LAN and USB updates of OSTrees, how it fits in upstream in OSTree and flatpak, and what you\u2019d need to do to enable peer to peer updates for your OSTree system.", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"id": 68, "code": "WHSLQT", "public_name": "Philip Withnall", "biography": "", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 105, "guid": "0d7aeb92-712a-5076-95d7-7bd5b3954620", "logo": "", "date": "2018-09-29T08:30:00+00:00", "start": "08:30", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-105-running-android-on-the-mainline-graphics-stack", "url": "https://cfp.all-systems-go.io/ASG2018/talk/164/", "title": "Running Android on the Mainline Graphics Stack", "subtitle": "", "track": "Foundations", "type": "talk", "language": "en", "abstract": "It is now possible to run Android ontop of an entirely Open Source Linux Graphics stack, this talk will dig into how you can do it too!", "description": "Finally, it is possible to run Android on top of mainline Graphics! The recent addition of DRM Atomic Modesetting and Explicit Synchronization to the kernel paved the way, albeit some changes to the Android userspace were necessary.\n\nThe Android graphics stack is built on a abstraction layer, thus drm_hwcomposer - a component to connect this abstraction layer to the mainline DRM API - was created. Moreover, changes to MESA and the abstraction layer itself were also needed for a full conversion to mainline.\n\nThis talk will cover recent developments in the area which enabled Qualcomm, i.MX and Intel based platforms to run Android using the mainline graphics stack. ", "recording_license": "", "do_not_record": false, "persons": [{"id": 69, "code": "AT7MQB", "public_name": "Robert Foss", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 106, "guid": "15354f48-950f-55f6-85ed-5ce345452581", "logo": "", "date": "2018-09-29T09:00:00+00:00", "start": "09:00", "duration": "00:15", "room": "Kuppel", "slug": "ASG2018-106-chef-in-strange-places", "url": "https://cfp.all-systems-go.io/ASG2018/talk/171/", "title": "Chef in Strange Places", "subtitle": "", "track": "Service and Resource Management", "type": "talk", "language": "en", "abstract": "How Facebook uses Chef to manage many different largescale heterogenous environments.", "description": "Facebook uses chef to deploy and manage a wide array of environments across our fleet, ranging from network switches to mobile phones to LXC containers to off-network devices. This talk will explore our toolchain for building, testing, and running Chef code in this diverse ecosystem of environments and includes stories about it's evolution and development.", "recording_license": "", "do_not_record": false, "persons": [{"id": 23, "code": "WENXF9", "public_name": "Zeal Jagannatha", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 107, "guid": "5bfb03e6-b018-5d2a-b73e-096c8d2acd67", "logo": "", "date": "2018-09-29T09:30:00+00:00", "start": "09:30", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-107-the-state-of-your-supply-chain", "url": "https://cfp.all-systems-go.io/ASG2018/talk/184/", "title": "The State of Your Supply Chain", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "Container security often focuses on runtime best-practices whilst neglecting delivery of the software in the supply chain. Application, library, and OS vulnerabilities are a likely route to data exfiltration, and emerging technologies in the container ecosystem offer a new opportunity to mitigate this risk. \n", "description": "Treating containers as immutable artefacts and injecting configuration allows us to \"upgrade\" images by rebuilding and shipping whole software bundles, avoiding configuration drift and state inconsistencies. This makes it possible to constantly patch software, and to easily enforce governance of artefacts both pre- and post-deployment.\n\nIn this talk we detail an ideal, security-hardened container supply chain, describe the current state of the ecosystem, and dig into specific tools. Grafeas, Kritis, in-toto, Clair, Micro Scanner, TUF, and Notary are covered, and we demo how to gate container image pipelines and deployments on cryptographically verified supply chain metadata.", "recording_license": "", "do_not_record": false, "persons": [{"id": 31, "code": "JSBJTJ", "public_name": "Andrew Martin", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 108, "guid": "11e08242-737a-5b4b-bdd3-fa54df265a6c", "logo": "", "date": "2018-09-29T10:00:00+00:00", "start": "10:00", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-108-the-future-of-networking-apis", "url": "https://cfp.all-systems-go.io/ASG2018/talk/188/", "title": "The Future of Networking APIs", "subtitle": "", "track": "Networking", "type": "talk", "language": "en", "abstract": "This talk presents TAPS (Transport Services), a proposed abstraction for a new Networking API, and calls for the Linux community to get involved.", "description": "Even decades after its introduction, the Socket API is still the de-facto standard Networking API on many systems. Its simplifying abstraction of a network connection as a file helped making networking easier to integrate into applications in the early days, but by now, networking has become way more complex. We have to deal with asynchronous communication, with the choice between IPv4 and IPv6 addresses, with multiple local network interfaces being available, and more. With the development of new transport protocols, such as QUIC, an application may even be able to choose a different transport protocol than TCP, which fundamentally offers the same service.\nIt would be beneficial to develop a future networking API with a better abstraction, so applications can make use of the different options without having to implement a complex decision logic themselves.\nThe Transport Services (TAPS) Working Group in the IETF is currently developing such an abstraction, which will be proposed as a new standard networking API. It will be fundamentally event-based and object-oriented, presenting a simple Connection and Message abstraction to applications. An application only has to specify abstract requirements for a new Connection, such as reliable and in-order Delivery of messages, and the Transport System below the API will choose a transport protocol and network configuration.\nThis talk presents the current TAPS architecture and API elements, and calls for the Linux community to get involved, for example by developing a new implementation of this API or reviewing and commenting on the documents.", "recording_license": "", "do_not_record": false, "persons": [{"id": 38, "code": "XPEVTP", "public_name": "Theresa Enghardt", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 109, "guid": "8fd767ef-92ba-51a4-bf71-5f8909d10fcd", "logo": "", "date": "2018-09-29T10:30:00+00:00", "start": "10:30", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-109-2018-desktop-linux-platform-issues", "url": "https://cfp.all-systems-go.io/ASG2018/talk/174/", "title": "2018 Desktop Linux Platform Issues", "subtitle": "", "track": "Desktop", "type": "talk", "language": "en", "abstract": "TL;DR: Stop making \"Desktop Linux\" a moving target by agreeing on a minimal baseline that third-party application can take for granted to exist on each Desktop Linux system.", "description": "Will the year of the Linux desktop ever arrive? What can we do to make it happen?\nTo make \"Desktop Linux\" a viable platform (as in: Windows, macOS) to develop against, we need to insist on backward compatibility and either need to find the \"least common denominator\" by experimentation (as we have done for over a decade now), or get the main Linux distributions (Ubuntu, Fedora, openSUSE, Debian, etc.) to agree on a certain set of infrastructure that can be expected to be \"there\", in a consistant way, without unnecessary differences.\n\nA guaranteed minimal set of infrastructure (available in the default installation of all distributions) with guaranteed backward compatibility is required for \"Desktop Linux\" to become viable as a platform.", "recording_license": "", "do_not_record": false, "persons": [{"id": 70, "code": "B9NQC9", "public_name": "Simon Peter", "biography": "Theresa is a PhD student and research assistant at the Internet Network Architectures (INET) group at TU Berlin. With a background in telecommunications and computer science, she is doing research in computer networking. Her PhD topic is about how getting information about multiple available access networks from a host perspective, and how to make useful choices between them.", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 110, "guid": "e5060f18-2c8e-5bcf-91bb-962b943a9da1", "logo": "", "date": "2018-09-29T12:15:00+00:00", "start": "12:15", "duration": "00:45", "room": "Kuppel", "slug": "ASG2018-110-configuration-driven-event-tracing-with-traceleft-and-ebpf", "url": "https://cfp.all-systems-go.io/ASG2018/talk/191/", "title": "Configuration Driven Event Tracing with Traceleft and eBPF", "subtitle": "", "track": "Monitoring & Tracing", "type": "talk", "language": "en", "abstract": "Traceleft is a framework built upon eBPF which allows generation of system events such as file operations and network calls via a configuration driven system. It can act as a foundation for building auditing and incident analysis or monitoring tools that work at the system level and need targeted and filtered information. While traditionally, eBPF based analysis requires writing scripts in a limited C subset, Traceleft aims at providing a configuration based definition system events to be monitored over which filters can be set as required. This talk shares our experiences of developing Traceleft along with some use cases and challenges faced.", "description": "Use cases and implementation challenges\nThe tiny eBPF VM in the Linux kernel has given us unprecedented flexibility in developing tooling for analyzing systems. In this talk we discuss Traceleft - a new auditing and incident analysis framework that can be used to build monitoring tools for filesystem and network events. Traceleft is a configuration driven framework that latches on to syscalls and other relevant Linux kernel functions identified in Traceleft. The eBPF programs are generated, compiled on the fly and inserted in the kernel, based on a set of JSON based configurations. Traceleft supports tracing network calls, file operations such as opening/closing of a target files, for a given set of processes and the aggregation of these events. Traceleft is built using Go and uses Gobpf library and allows the configurations to be sent over the wire using Protobuf format. Traceleft started as a joint effort between ShiftLeft and Kinvolk to develop an easy, repeatable way to provide a configurable way to audit syscalls and classify security events filtered on processes and files. The tools built over Traceleft can be used for live monitoring and alert generation.\n\nImplementing Traceleft presented many challenges.\n\neBPF tracing programs need to be recompiled for each kernel version and updated for each application profile. It needs to keep track of new processes and match them with new applications in a race-free way. Reading information from different sources bring many race possibilities. Catching syscalls and their parameters bring limitations: matching specific syscalls with specific syscalls or remote hosts for network calls. We will discuss how we overcame some of the challenges.\n", "recording_license": "", "do_not_record": false, "persons": [{"id": 71, "code": "HBGWB9", "public_name": "Suchakra Sharma", "biography": null, "answers": []}, {"id": 28, "code": "MQVR9X", "public_name": "Alban Crequy", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 111, "guid": "ca4d353b-a44a-5da6-8707-5b7b43221aca", "logo": "", "date": "2018-09-29T13:00:00+00:00", "start": "13:00", "duration": "00:45", "room": "Kuppel", "slug": "ASG2018-111-libcapsule", "url": "https://cfp.all-systems-go.io/ASG2018/talk/173/", "title": "libcapsule", "subtitle": "", "track": "Foundations", "type": "talk", "language": "en", "abstract": "libcapsule is a project that allows segregated dynamic linking: Access to the symbols of a library without being exposed to any of the dependencies of that library without requiring recompilation of the binary that pulls it in.\n", "description": "segregated loading of dynamic libraries\nlibcapsule's goal is to improve portability of programs that are distributed with runtimes (cf flatpak) that still need access to [some] libraries from the host (eg libGL) while insulating said program from any system libraries outside the runtime other than those it directly requires.", "recording_license": "", "do_not_record": false, "persons": [{"id": 72, "code": "DDCSS7", "public_name": "Vivek Das Mohapatra", "biography": "Max is a test engineer at CoreOS hacking on Kubernetes and Prometheus. Previously a frontend engineer working on ReactJS integrations and UI component testing, he decided to stop suppressing his interest for distributed systems at scale and joined CoreOS. Now he implements new testing infrastructures and development automations to support the Tectonic and the Prometheus project.", "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 112, "guid": "6cbcf172-c5eb-5ea6-8796-7841d436f621", "logo": "", "date": "2018-09-29T13:45:00+00:00", "start": "13:45", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-112-is-cockpit-secure-", "url": "https://cfp.all-systems-go.io/ASG2018/talk/231/", "title": "Is Cockpit Secure?", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "Cockpit makes Linux discoverable. But it's really a Linux session in a\nweb browser, accessing the native system APIs and tools directly from\njavascript.\n\nDoes that sound scary? How can we be sure that accessing Linux from a\nweb browser is secure? What about the web server stack? What about\nauthentication and privilege escalation?\n\nWe'll talk about how Cockpit deals with security, authentication,\nprivilege escalation, and browser lock down. I'll show you various\ntechniques to tailor Cockpit's security options to your situation, like\nusing bastion hosts.\n", "description": null, "recording_license": "", "do_not_record": false, "persons": [{"id": 20, "code": "EYRNSC", "public_name": "Stef Walter", "biography": null, "answers": []}], "links": [], "attachments": [], "answers": []}, {"id": 113, "guid": "daae9fd3-b18f-5355-b384-e340850b7bd4", "logo": "", "date": "2018-09-29T14:30:00+00:00", "start": "14:30", "duration": "00:30", "room": "Kuppel", "slug": "ASG2018-113-past-present-and-future-of-system-containers", "url": "https://cfp.all-systems-go.io/ASG2018/talk/224/", "title": "Past, present and future of system containers", "subtitle": "", "track": "Cloud & Container", "type": "talk", "language": "en", "abstract": "System containers, the oldest type of containers, focus on running an entire Linux distribution, including all its services in very much the same way it would on a physical system or virtual machine.", "description": "System containers come with some unique challenges, users of those containers expect to be able to do pretty much everything that they can on a normal system. This means it\u2019s not possible to restrict those containers quite as much as application containers can be.\n\nIt also means that there are extra expectations to be met:\n\n