 Okay. Let's start. One minute preview. I'm Steph. Hello. I work at Red Hat. And I work on Cockpit. And much of the Cockpit guys are here. Martin, Lars, several people who are hacking on Cockpit. Kirill and Nikolai as well. Pretty cool stuff. I'm going to show you first why we did this thing. But I'm also going to show you how it works. I think that's the more interesting part. And all of this works today. This is not some bullshit I'm showing you that's like future magic. You can actually literally open your laptops right now on any of these operating systems and do everything I'm doing here. You are all there if you want to follow along. But there's only half an hour or so. Maybe you won't get the chance. So Linux. I know we understand how Linux works inside all the FDs and processes and how the syscalls work and all of these things. But this is how Linux looks to people who have never seen Linux before. And for us, when we get to that nice root hash prompt, give me a root hash prompt and I can conquer the world. But for most people, this is very scary. So Cockpit was started with two goals. One is to make Linux usable by non-expert admins. Those coming from the Windows world, for example. But even people who are not admins at all. And secondly, to make complex features, even those that we all use, and we don't want to have to learn about. We just want to get the job done. Make them discoverable and easy to do. And I'll show you some examples of that. This is what it looks like. You contact the host that you want to log into on port 9090. It's a standard port. And you get a login interface. This will say whatever your operating system is on rel. It will say rel. And you can do all sorts of things with it. It's a remote interactive Linux admin interface. You access your server remotely because apparently that's a thing. You don't have to put monitors on your servers anymore these days. And it's a Linux admin interface. It's interactive. You go into the Linux system as if you were in there with a SSH session. And you actually do things with it interactively. It's less of a policy-based thing, but it's something that you troubleshoot, configure, and interact with the system on the fly. Microsoft is copying Cockpit now. This is one of the places where Linux got it first and Microsoft is copying it. You're building a similar interactive web interface for Windows Server in a browser as well. And when you look at it, it's like, hmm, that looks pretty much the same as what we got here. So that's pretty cool. So here's what it looks like. Let's say to make a network bond. Now, I'm going to show you a network bond because there's 15 ways to make a network bond in Linux. And what we try to do is show you one really good best practice way. So you don't have to read blog posts, figure out how to make a network bond, stay past a boot, figure out which version of the operating system you're on, what applies then. You can just go and discover and do this and get on with the work that you really care about, which is probably not making a network bond. So this is an example of making Linux discoverable for even for all of us. We can also do things like Mount Nice SCSI disk, which I really don't know how to do from the command line, because I haven't spent the time to learn it. But I won't go through this example. We don't have that much time. You can, of course, dive into the Kubernetes dashboard. In fact, let's just do that live if this works. So you can go into the various containers that are running in a Kubernetes cluster. You can just go into a shell here on the network gods are not with me. But you get the idea. You can dive in. You can see the log output of a certain container. You can go and see what volumes or what's going on. I can change the number of instances. I mean, the number of pods for a certain application controller and so on. So very discoverable. Again, that's because of the network outage, but you get the idea. Okay. So let's switch back. So, but what is this really? Because if I was standing here trying to sell you Webmin, I wouldn't be so excited. I wouldn't be working on this. And I want to show you what's under the covers, because that's actually really cool. This is why I hack on cockpit. It's really a real Linux session in a web browser. So you have Linux sessions on a VT or terminal. You have Linux sessions in a GUI on a desktop like X or Wayland. This is a third kind of Linux session. Honest. I'm not just bullshitting you here and I'll show you why. This is how cockpit works. It does not have a mid tier written in Pearl or Python or your favorite flavor of node. What it has is pure UI that runs in your web browser and interacts directly with all the services on the system. In fact, I counted them the other day. There's over 90 different services that it interacts with, APIs and so on. And I'll give a talk about how we managed to pull that crazy thing off tomorrow. And then there's no place where we have to wrap everything or a mid tier where all the logic of cockpit system or the data lives. It has no data of its own. It really just talks to the system as you would from a terminal or by the APIs of that system. Let's take a look at how it works. Over here, we have the various system APIs. We have Divas APIs. We have file APIs such as slash proc or Etsy password. We have some APIs look like processes. You spawn them and they produce predictable output. That's an API. You have Unix socket. You have REST APIs like the Docker REST API. And so on. And over here, we have a web interface where all that logic is running to configure stuff, troubleshoot stuff and so on. So how do we connect the dots between them? There's this thing called the bridge, which is really like the shell of the login session. And on its standard in and standard out, it sends these kind of JSON messages. We'll take a look at what these are specifically later and play with them a bit. And it sends them back and forth. And it basically doesn't know anything about adminning a system or various kinds of tasks, configuring ISCSI, what have you. It just knows how to take these JSON messages and convert them into API calls to these various different APIs. So you can kind of see it'll talk to system D. Not because it knows anything about system D, but because system D has a Divas API and it knows how to talk Divas. This side is the thing that knows about system D. And it tells it, I want to talk to system D and I want to do it this way. But you can't talk standard in and standard out to a process in a user session from a web browser. So there's one more piece that's missing. And it's CockpitWS. This is a web socket. A web socket lets you send these messages, these same messages that go into the standard in and standard out of that user session process over the web to the web browser and interact that way. So what's really cool is playing with this. I open up Cockpit log in. And here I can, in the JavaScript console, I can interact. I'm going to try and interact with a Divas API. And let's make it host name D, which is part of system D. We open up proxy for that. This is all JavaScript. The browser doesn't know about kernel name or kernel release or all of this. It's actually on the fly using the Divas introspection through the bridge, through those messages to get this kind of information. And here I'm setting the host name of the system to Marmalade. You can see Cockpit itself reacted to this change. And of course, the host name is actually changed, as you would expect. Here's another example of spawning a process from JavaScript, from a login session in a web browser. As the user who logged in, I'm going to spawn a process and it's going to be ping. There we go. Good old DNS server. And bang. Hit enter. Yes. And there we go. The output is streamed. You can send input, output, all the good stuff, as you would expect. And let's just show one more example of this. I'm going to access a file. It's going to be at COS release. And we can do things like watch files. In fact, let's take a look at that later. And of course, we get the output of that file. So Cockpit is built like this, on all these same little primitives, interacting the system from a real login session in a browser. So let's look at what makes that tick, the protocol. There is a link to a cool tutorial, but you can't click it because it's on a screen. So I'm going to show you what's on that page. In fact, I'm going to do it for you. Let's open a terminal. And I'm going to run that bridge process in a special way that I can interact with it. All message passing protocols have weird framing and whatever. I'm going to simplify it and put a simple dash dash dash frame so that we can actually type this stuff right here. So here is a... I'm going to ask... I'm going to send it this one command to open a channel on this standard in standard out. Obviously, lots of things are going on on the system. So we multiplex them in channels. This channel is called my debus. It's a debus channel. We went through several versions of debus-type channels because, yeah, but we got it right eventually. And we're going to talk again to hostname, the same thing we did before. We're going to ask it and it sends us back, okay, we're ready, there's a channel going on. And it sends us some messages about this channel, who the owner is of this channel. You can see this is a debus unique name if you're familiar with debus. What I'm going to do is call a debus method. And again, I'm going to call the set static hostname here. And, except for this time, I'm going to call it my pinkpony. And let's see what happens. And we called, we got back a reply and this particular debus method, set static hostname, does not have a return value, so you see null there. And let's take a look at what happened. We are my pinkpony. So this is how we interact with the system. Let's do a little more. And of course, in these messages, in real life they're not separated by dashes, we just put that here for interacting with it. But in these messages, there's binary data sometimes streamed, there's all sorts of data multiplexed in here and you get about, I think about 30 megabytes a second throughputs, even with all the inefficiencies of this kind of multi-step transport. So let's take a look. I'm going to open a process. I'm going to spawn a process. This time it's going to be a little different. Let's do it. And it's going to be IP adder show. And you can see I got streamed the output in two, three, four, three different messages here. One, two, and three. And this particular channel is called myproc and I got the exit status of the process here. So a lot of this is built on this kind of interacting with the system. And in this way, we really make it possible for the Linux session to be completely realized in the web browser. So one thing that's very clear when you look at all this is that APIs are not what you thought APIs were in 1990. In-process APIs are not really APIs. And you see this all over. This is not just cockpit, but all over microservices, all over, especially when you're dealing with containerization, when you're dealing with libraries that need to quote-unquote libraries that have APIs that need to be used from something that's foreign to it, making two containers work together. There's so many examples that we're in 2017 now. APIs that are in-process only are implementation details. They are nice, they should be stable. Of course we shouldn't try and break them. They should be treated well, but they really aren't APIs in the useful sense anymore. APIs that are removable, callable by something in a different process are what you would consider an API nowadays. That is a Unix socket, that is a command line interface, anything that you can call from a different process. This is the definition we came up with when we figured out what we can use and what we can't use. And it's very similar to a lot of the other modern techniques for composing systems. But now we're going to move along here. Cockpit is really cool because you can literally write a piece of UI as quickly as you can write a shell script. And we're going to show that. We're going to do that live here. Cockpit does not have functionality to export a directory over NFS. There's a pull request open, but I haven't merged yet, so I could give this talk. So let's do that right here. Well, not merge the pull request, but... So in order to make a menu item show up in Cockpit, let's go over to Cockpit. Here we are. Here's various menu items you can see. And you can see there's no NFS functionality here. What I'm going to do is there's a small file that describes what should show up, the label, and the file to use. And of course, for the purposes of this demo, we're disabling one or two of the kind of security features, which would force us to use multiple files in order to keep this simple. But let's... We'll link this directory. This is all documented, by the way, but I won't show you the documentation right now. We'll link this directory into local share Cockpit. And we'll log out and log back into Cockpit. And you can see there's NFS export in the list. Now, of course, as any cooking show or chef will have one that's made before or partially made before, and I've done that. What I have here is a file. It's just HTML with some JavaScript and something crashed. And it includes... Nice. It includes some basic JavaScript files, the Cockpit.js functionality that you saw before with Cockpit.file and those kinds of things we used from the command line. And we have a little form here that shows a path and a button to click. And we already have a little bit of JavaScript going on. So here, when we click the export button, we call the run function, and the run function looks at the path input field, puts in this variable, and we call this export FS path with that variable. This here is pretty cool. What this says is, I would like to run this command as root, even though I'm not root, I would like to use sudo or polkit to run this command and Cockpit takes care of all that magic for you. And literally, with those two words, you have privilege escalation if the user is allowed to escalate privileges and has logged in, maybe in the wheel group, maybe in the sudo group on Debian, then they're allowed to do this command. If not, we'll get a failure here. So what's missing? Well, let's try this out, actually. We're in Cockpit. We're going to say we're in export opt, and nothing happened. Let's look at export FS. We can see that opt is actually exported, and that's what that to do there was about. It's not really showing any information about what we need to export. And here's an output field, this box, that we need to populate with some information. So let's do that. Let's say we're going to watch this file. I'm going to call it nfse tab, and then we're going to call the export FS function. I really hope this works. Curly. Yes. Oops. My indentation is shit. Okay. Well, if this... Yes, there we go. And when... Oh, boy. I'm really... Okay. Well, let's... I'm sorry. I didn't practice this before. I really haven't practiced, and I'm able to do it. What I'm going to do is copy in what we have prepared. In the object, that's right. This is good. This is like pair programming, except for with tons of people. And when this is done, I want the data to go to... Wow, the indentation is really crap. To... Let's see if this works. I don't have any error handling hooked up, so this is hoping for the best. But you can see, we literally got the output of exportFS into that terminal... I mean, into that box there in less than a minute. And watch this trick. So let's say exportFS from the command line. I don't think you should ever do that, but I'm going to do it. It showed up there. Weird, man. Cockpit reacts to the system as it changes, and it was so easy to do that. That was really, really simple to make work. And again, of course, if we do stuff like that, now it's starting to react to the changes made from Cockpit. This is one of the things Cockpit does. It doesn't think it knows about the system. Almost all the pages are implemented in such a way that it will update the system and then wait for the system state to change and actually show that changed state. So no matter whether you did it from a tool or you did it from your own UI, the UI remains consistent. And that's something we want, because we want people not to be limited into Cockpit now, you are stuck here forever, but to be able to outgrow it and use the terminal alongside it, use other tools, use Ansible, what have you to work with the system and have Cockpit update its state and say, yo, something's changed in the system. And just the admins or people who are using it to test, nice. Make them kiss. Okay. So let's go back to here. What do we have next? But all of this must come at a horrendous cost. You have abused my system. I feel, yeah. Except for, Cockpit has zero footprint. It has very few dependencies. It's written in C on the server. There's no big application stack there, PHP or Node or what have you. Cockpit is built. Wait a second. The point of Cockpit is not the point of running Cockpit on a server is not to run Cockpit. It's to do whatever the server was supposed to be there for. It's not going to take over your server and own it. It really starts on demand. And of course it uses system desocket activation to do this as we all know and love. Here you can see all the processes. We have five minutes left. You can see all the processes that are named Cockpit. When I hit the port 9090, a process starts. And when I log in, you can see the login session start. Boom. There's a session, there's a bridge, various processes all in a real session. And of course when you exit Cockpit when you log out that stuff all goes away and after about I think 10 minutes the other one will disappear. It's a real login session too. Let's log in. And this video is cut off, which is not cool. But when I'm logged in and I open up a terminal in Cockpit and I run ID, you can see I'm logged in as the user that I logged in. It's all scripts. It's all run with your permissions. And you can do nothing to the system that you can't do. Cockpit doesn't imagine like draw policy on what it can do in the system. It uses a real login session to do this. And of course, login D shows the Cockpit user session with all the various processes in it. It works over SSH. You don't have to open port 9090. Now the real party trick would be to get your browser to speak SSH. Unfortunately, I just pulled that off. So you really need one system listening on port 9090. A bastion host, so to speak. And you connect to it on port 9090 but then it can root over SSH port 22 like we said. This is the protocol spoken over standard in and standard out. So it can launch Cockpit bridge on these other systems and talk to these other systems as you would expect. So in a lot of cloud situations you can literally without opening a single port connect, troubleshoot, diagnose figure out logging on a system and use that then to interact with all the rest of the systems in the cloud without having to go and deploy Cockpit to all of them or open ports on all of them or figure that part out. And here's a demo that is cut off about exactly that. Should I try to make this work? Yeah, this is not cool. Here's a better one. Here's a demo of OS Tree on Red Hat Atomic and us updating doing an update of the operating system on it. And what we do here sort of ties us all together. We're on a remote host and we're running this operating system over here 742 and we're going to change to 724 we're going to change to 725 we can see there's no updates but rather than bonk that button there I'm going to run an Ansible playbook to update the systems. There we go. Actually, yes. Oh, you're going to show me. I don't have time for this. And you'll see Cockpit already responded to the changing state of the system it's starting to do the upgrade the upgrade runs through and you can see the system is rebooting and it'll reconnect shortly. So, I'm sorry to have to cut this off there's so much more to show about Cockpit and it's pretty amazing but I have no more time I'm all out of time. Oh, there you go. But there's time for a couple of questions I think and I'd love to take them. Yep. Is the communications protocol of a web socket actually secured? Or is that a plain text? The question is, oh, you have a mic I won't repeat it. It is secure. It's secure in the sense that TLS is secure. It's just as secure as any web interaction with HTTP or anything like that. It's over TLS again and then the second hop over SSH is of course SSH keys, SSH agent as you would expect secure in that way. And yet, one more question. Awesome. Bye.