 Well, hello, and welcome to another Dev Nation. We have an exciting topic for you guys today. I know all developers at this point, all architects are about Linux as their deployment system. Linux is the way they put their services out there live into the world, and we're going to talk about the next generation of Linux. We're going to talk about that right now. Do keep in mind, we're going to take your questions and chat information into that chat tab. I will be trying to pick up questions and throw them at Max later into the session. There's a lot of people on the line today. You can see our numbers will be building. A lot of people will be entering the chat, so just keep that in mind. It'll be noisy, I suspect, but we have a really great session for you. Let me introduce Max Bergerhout. Yes, I think I got to write that time. He's coming to us live from the Netherlands, and so he's going to be drilling down and showing us a lot of great demonstrations, plus he has a lot of the links that I'll be providing in the chat as we go. Just keep in mind, the chat tab will be your friend. Remember, if you can't hear or can't see, which you can't hear or can't see, refresh your browser is 99% of the time that solves the problem. All right, well, let's get started, Max. Thank you, Ber. So, let me switch to my presentation real quick, or maybe you should do a little intro about myself. My name is Max Bergerhout. I work as a Solutions Architect for Red Hat in the Benelux region. I specialize in the Red Hat platform and cloud portfolio. And in that work, I talk to a lot of people in operations as well as people in development teams and talk about our products, talk about RHEL, and the last couple of months, I've been talking about RHEL8 a lot, RHEL8 beta, and that is what we'll be doing today. I'll show you around the new version of RHEL that we've been building and show you around. And so don't be afraid to ask any questions in the chat box. I'll try to answer later on as many as I can. So switch over to the presentation screen there. There we go. So I hope you guys can see this. Let me check. Yeah, you guys can see this. So we've had this bit. I also do a lot of Twittering. So if you wanna follow me, go to at Max Bergerhout at Max Bergerhout on Twitter and you can follow me there, Twitter, I'll tweet about a lot of Red Hat related stuff. I also do a lot of stuff on YouTube on the channel called 100 Things to Do with Red Hat Management Products. And you'll probably forget that. So you can go to bit.ly slash 100 Things Red Hat as well. And I have a couple of pretty cool videos about Ansible and all that kind of stuff over there if you wanna hear more. So in order for me to understand my audience a little bit better, I would appreciate it if you could go to bit.ly slash dnl poll, that's bit.ly slash dnl poll. And you should see this specific screen there. Just pick a couple of languages that you're interested in on using on REL8 and maybe some languages that you're already using on REL6 or REL7 and I'll try to tailor my demos based on the results of this poll later on. Now, while you're doing that, I have to show you this. What I'm going to talk about is beta software. That means that not everything that is part of my demos might not or will not end up that way in the final product. Some things might change before general availability. Some things might end up to be tech preview. Some things might be dropped completely. That is all still undergoing debate until the very final moments where we decide what is in J and what is not. So please don't try to read anything between the lines. Don't assume any software versions you see scrolling across my screen are going to be available in that specific exact version because it might not be so. Having said that, here's what I want to talk about today. I want to talk about a very cool new feature called AppStreams, which is part of REL8 that allows us to give you more of faster versions or basically give you access to new versions of programming languages along the lifecycle of REL8 all the time, multiple versions in parallel as well. I'm going to show you how to build a quick LAMP stack with what is available in REL8 in terms of software. We'll look at what else is available in AppStreams because LAMP will be Linux, obviously Apache, MySQL, PHP. What else is in AppStreams? We're going to look at how to build containers with REL8, but we're going to start off with something that is pretty cool and pretty new in REL8. We've had it in REL7 as well, to be honest, but REL8 is offering a lot more functionality in this thing called Web Console and Image Build. So let me switch over to here. This is, let me maximize that as well, this is the Web Console login screen. I'm going to log into this with my root credentials because I'm lazy, but you can use non-privileged accounts as well if you want to. And this gives me a web-based UI to control my system with. So you don't have to learn all those command-line tools. You can just log into the website and manage many, many parts of your system. You can still do command-line, obviously, it won't interfere with each other, but this makes it a little bit easier. So things you can do here, for example, you can apply updates. You don't have to go into, you don't have to log in over SSH and do YUM commands. You can just go here and apply updates. It's simple, you can join a domain. You can view the system logs. And Web Console was installed by default on every new installation of REL 8. And you don't let anything else you do is enable it, so it will be there. You can go through all of the logs and filter the logs by date. You can filter the logs with severity. So if you have an application that logs to the normal SysLog, it's very easy to just go through this website and read through all of the potential error messages or whatever. You can configure storage. So maybe you have an operations theme that presents a new disk to your test or development environment. You can go into the Web Console and configure that piece of storage yourself. It's pretty easy to do. You can go into the networking tab and you can get metrics about the performance of your networking interface. You can get networking logs. You can configure bonding or teaming or bridge or whatever. And you can even manually or automatically, I should say, configure your firewall. Just click this link over here. Click add services. And you can, for example, let's say we want to build a web server. So we go search for HTTP and we can click there and add service. I'm not going to do that now because this specific machine does something else, but I can just open up firewall ports very easily through this UI here. I'm going to use three systems in my demo that I'll talk about in a second and we'll be able to add these systems individually to the dashboard here so we can get some metrics about the systems that are running my application. So maybe I have a database server and two web servers and a load balancer. So I want to keep track of the performance of those systems and I can do that in a single UI that will show you the performance of all of those individual VMs in terms of CPU, in terms of memory, in terms of network performance, in terms of disk throughput. I can keep track of how that is working from the web console in row eight. So I think that would be pretty useful if you were trying to debug performance of an application. You know, one other thing I want to show is called Image Builder. Image Builder is a really cool new feature in row eight and it allows you to build images for various private and public cloud platforms right from the web console in row eight. So basically what you do is you go to the Image Builder tab here with a create blueprint, give it a name, let's call it DNL demo and I can just add RPMs to this. I can just say, give me, I don't know, give me get because we're developers, right today. So we just give me get, there we go. And I can install, where are we? We can install get. I can commit this specific package that I've added to this. So the blueprint will now be saved with the addition of git here on top of what is absolutely minimal for an operating system to run, there we go. And from there I can go create an image. I can click create image and I can create an AMI, Q-Cow image for open stack, generic Q-Cow image on Azure, if you're HD or VMware, if you're MDK. I can just click this, click create and then I can wait a couple of minutes and it will spit out a file for me to download and push into a private or public cloud. So that's pretty useful. And one of the use cases for that is for example to build images for a web server, images for a load balancer, images for a database and use these as the basis for your application deployment. And by using these you can speed up application bootstrapping by a large margin. And I've been talking to customers that tell me that building a database from scratch based on an empty image can easily take them 10, 20, 30 minutes because of the software installations they need to do. Well, no more because we can push, simply create and push an image that contains all of the software already from onto that private or public cloud platform. Now, as an example, I have empty base image here. Empty base image has a couple of components selected. So I have cockpit, which is the community name for what we have here in the web console. We have a git, we have midnight commander because also I do forget commands as well. We have some other RPMs that I wanted to have installed in this image. So if you want to add custom RPMs to this that works as well. And then I've created an image, it's a QCOW image has been built. I built this last Wednesday and I can just download it from here and then push it onto my ref cluster and boot VMs from it. And that is exactly what I have done with the three VMs that I mentioned earlier to the REL8 beta DNL010203 they're based on that image I built in image builder. So I think that would be pretty interesting to take a look at. Now I've only showed you how to do RPMs, create an image based on RPMs. But if you would go to the terminal over here on the system that I'm building these images on I can actually see the configuration of these images as they're stored in a text configuration file. So the empty base image looks like this. Come on. Has a name and description version number and it has a list of packages as you saw already in the other screen they're added when this image is built. And then I added this manually just by editing this file to create a root user with a very simple password that you should not use in production obviously. And I'm adding an SSH key. So when I built this specific image I can just upload it to a private or public cloud or to a VMware cluster. And I can from there on I'll use Ansible to do the rest of configuration because I already have a user that has a known password and a known SSH key. So that should be interesting. Let's move on to some programming environments. So let's take a different system for this. Let's use the zero one. So I'm going to assume that a lot of you are interested in Java. So I'll start there because Java is also a little different. Java is not an upstream per se. I, let me check. This is readable, right? I hope so at least it should be. We ship in a rel eight beta we ship both Java eight and Java 11. So I can just go you yum install Java one dot eight dot zero dash open JDK dev. And this one is still Java eight. So this is just the weight works on rel seven and rel six is the exact same thing. Notice that I'm not using DNF DNF. You could probably change that acronym to mean do not follow or something like that. It's just consider it to be yum for all of your muscle memory that you just, you know from from using yum it's still there. And you can use yum as the command line name of the command utility as well. So now I have installed Java. Just go Java version. I have Java one eight. I have the Java compiler here as well. So that's both there. I can also install Java 11. It's not much different from Java eight. There we go. Install Java 11. Now I have two versions of Java on my system and the way we switch between the two versions of Java is actually quite the same as it would be on rel six and seven. It's the alternative system and I'll show that in a second. Now we ship both eight and 11 versions of Java. Those are the upstream long-term support versions. We do not recommend ship or support Java nine or 10. You can read more about that on the customer portal because they are not long-term support. I think Java one eight and Java 11 have end of life dates somewhere halfway to 2020s. So you should be fine for a while. Let's go, let's go do alternatives list here for a bit. So we can see that we have Java linking now, pointing to Java one eight. Let's switch that around. Let's do config, let's point it to Java 11. Let's do the same thing for the compiler. Now we're going to my demos directory and compile this little Java program I have there and run it and it should say hello, row eight. So we have Java 11 and Java eight available on roll of eight beta, okay? So that was one. Now I want to see what the poll looks like. So let's switch over to the poll. Hoping I'm picking the right screen here. So let's pick this one, okay. So where are we at? What's interesting? Python is interesting for people and that's good to know because Python is actually a little different from the other app streams as well. And shell, I'm not going to do shell. That's more here as a bit of a, just to make that poll complete. So let's look at Python for a bit because Python is interesting in terms of roll eight. So normally on basically every Linux system you can go Python and you drop into the interactive Python shell, but not on roll eight. Roll eight does not have a version of Python that is available in the standard location that you would expect it at. Let me check my notes real quick and let's skipping over something. It doesn't probably am. Well, anyway, where's Python? There we are. So that's not there. We do have a hidden version of Python over here. That is what we use for things like Ansible and Stratas and Aconda and things like that. But if you want to use your own version of Python for example, for Django, if you want to write a Django application, you probably want to use the Python that we ship in the AppStreams repository. Now, if you check the way we ship RHEL, wait, no, no, no, that's not a command. You can see that we actually only have two repositories for RHEL. So that's a lot easier than it used to be. We have BaseOS, which is everything that has something to do with the actual operating system and we have the AppStream repository, which is where all of my programming environments live. If I want to take a look at all of the AppStreams that are available to my system, I have a young module list and it will spit out a whole list of all of the modules that are available to my system. And here you can see that we ship both Python 2.7 and Python 3.6 as an AppStream. And we can install them both, to be honest. So we can do young, yes, install module Python 2.7 and we get Python 2.7 installed. Now I'm really happy, wait, no. Now we do demos and something goes wrong. It was get almost little heart attack. Everything turns out to be fine. So we get Python 2 running here. Python 2 got installed. We installed Python 3.6 as well. So this will give me Python 2 and Python 3 binaries. So I don't have Python 2, right? Python 2.7, Python 3, Python 3.6.8. It's fine, but I still do not have the Python binary. So if you want to do, you know, basically just install Django from its Git repository, it's probably going to refer to the Python binary. If you want to set up either Python 2 or Python 3 as the Python binary in your normal path, just run alternatives config Python and select Python 3. And Python 3, it's really cool. It's going to enable you to run Django 2.1 up, which is something you couldn't do with Python 2, as far as I know. So Python is still there and just a little bit more flexible. So these app streams will allow us to ship more modern, again, and more modern programming languages and switch them out a little faster than we were able to with real 6 and 7. And they also allow us to basically start shipping new versions, new major versions of programming languages, halfway along the lifecycle of real 8, for example. We don't have to wait for real 9, so that's pretty cool. So let's see what other languages you guys are interested in. So we have Java, Python, we talked about Python. We have PHP. So I'm not a pro guy. So this is the one thing I don't have a demo for us. I'm going to do PHP, right? Because I want to show you how to build a LAMP stack anyway, because it's all built on app streams in real 8. So let's go look at PHP. Let's look at what versions of PHP we have available as an app stream on real 8. We actually have two. We have PHP 7.1 and PHP 7.2. Now, don't expect these to both ship for GA. That's just my personal expectation. It doesn't really make sense to have these two ship for GA as well, but it makes for a nice demo. So we're happy they're here. We have 7.1 and 7.2. The 7.2 has a little D between the square brackets there, which means it's the default version that you will install if you install Python. If you install PHP, you will get PHP 7.2. And then you get the common profile. Now, what a profile is is probably easiest explained based on a database. So we have Postgres here. Postgres 10 is the default. We also ship 9.6. And then we have a client and a server profile. The server profile is the default. If I run young module install PostgresQL, I would get version 10 and the server. If I want to install only the client, which is the other profile, I have to explicitly tell young to do that. So that probably explains what a profile is. So in order to be able to show you how to upgrade a module, I'm going to force it to install PHP 7.1 for now. PHP 7.1 and then actually install it. Yeah, you see that we also enable modules, app streams for Apache, HTTP and Nginx. So we also ship Nginx as part of an app stream. So when you use Apache, Nginx is there for you. Now let's install PHP. I shouldn't have done the dash y. Scroll back now to show this. Come on, stop. So as you can see, we're installing PHP. We're also installing Apache. We have some weak dependencies here that are installed by default. We didn't have to necessarily. That's a new feature in YAM4. But I have PHP 7.1. So what we now need to do is make sure we enable the actual web server. Here we go. And copy over the index file to the web server directory, like that. And then we need to open up the firewall. So let's open the firewall through what we had earlier in the web console. So let's go over here. Let's click this. Let's go add services. Let's go HTTP. Click there. Add service. And there we go. We now have web traffic over port 80. We can go here again. So I can open up a new page. Let's go around 8. There we go. So the only thing in the index file was PHP Info. And you can see here now that version 7.1 is running on this system. This is not really spectacular in PHP Info. Let's go back here and upgrade this to PHP 7.2. So it's your young module to install PHP 7.2. So I'm specifying the version of the AppStream when it uses. And just wait a couple of minutes for this to finish. Da, da, da, da. There we go. We've got a restart HTTP. And as you can see, we've switched from one AppStream to another from 7.1.7.2. And we have installed PHP 7.2. So if I go back to my PHP Info file here, take a look at the version number as I refreshed this. And we're still in 7.2. Probably you don't want to do this in production, obviously. You only want to do some tests and dev systems, but it makes for a fairly easy way to upgrade from one version to another. Modules will not migrate your data. So keep that in mind. If you do this from Postgres 9 to Postgres 10, which we both ship in rel 8 as a beta. The Postgres 10 is going to tell you, no, no, no. You have to export and import your data because the data format changed. So modules will not help you there, but they will help you with making that software available for you, which is half of the job, right? So you don't have to go to all kinds of third-party websites anymore to get your hands on new version of PHP or Python or whatever. So now we have a patch, and we have PHP. We have them both running. To build a proper LAMP stack, we need a database. So let's go back to my list of AppStreams and check what kind of databases we have available in rel 8. Now there we go. So we have from top to bottom, we have MariaDB, which is what I'm going to use later on. We have MySQL, MySQL, whatever you want to call it, version 8. We have versions 10 and 9.6 of Postgres. Again, do not assume this will all end up in the GA version of the product, but I'm just showing you what we have in the beta. And we have two versions of Redis, versions 4 and 5. Now for my demo, I'm just going to use MariaDB because that is personally what I'm most familiar with. So I'm going to go yum install Maria module install MariaDB. And if you look at how this formulated, this is going to give me version 10.3, and it's going to give me the server because that's in default. So let's go there, install install install. And there we go. So we see we're enabling some modules, MariaDB, obviously some Perl stuff, installing my MariaDB server profile, installing some packages, some dependencies, and some weak dependencies because I'm not explicitly told it not to. And there we go. So if we go here, you can see that darn it. Some of these RPMs came from the base OS repositories, and some came from the app stream repositories. Now I have my database installed as a good little boy. So I'm going to start it up, and there we go. So I've now started, and as a moving better little boy, I should run my cluster installation script to make sure that my password is set and all the weird stuff has been removed from the database. So there we go. The database has been set up. And now I need some little bit of glue between my Perl or MariaDB and PHP. So we install PHP, MySQL, and D, just a little module, PHP module to talk to MariaDB, and now we can restart the database at the web server again. There we go. And copy a little demo script to that location, and then we go back to this page and go add the minor. This is just, I don't know if you guys know this specific script, but it's a PHP script that we use to do database administration. A little bit like PHP MyAdmin, but I think it can do all kinds of different databases. And I can log into my local database. I can create a database called DevNation, and there we go. So that all works perfectly, and that's pretty nice. It's the way LAMSTAC works on the REL8. Now, I've shown you that we've shipped with MariaDB, MySQL, Postgres, and Redis. We are not shipping Mongo anymore. If you want to learn more about why that is, it's a legal reason, has to do with a new license for Mongo. It's in the REL8 release notes, and I think Burke will probably link that in the checkbox at this point. I'm not going to install Postgres because I think that'll probably take a little bit too much time. So let's do one more language, just for fun and giggles. What else did you guys think was interesting? Let's do, I think I did Java, right? So let's do, I don't think Rust is getting enough love. It's kind of disappointing. Let's do go. Let's do, let's go weird and let's do go. So in REL8, let's take a different machine for this. In REL8, we actually ship, bam. Wait, so it's the second VM. We actually ship Golang and Rust and Node and all that stuff in AppStreams as well. So if you check that module list, AppStream list again real quick, you can see we have Rustul set. That's kind of my thing. Scala, we have Varnish as well in here. We have Node, two versions of Node. We have, where's Golang? We have Golang, we have LLVM. So we have a whole lot of different languages that you can play around with. But for now, we're just doing our self-executing. Yes, install and go, tool set. So no more playing around with that. Get that supported and shipped from Red Hat on your system. There's go. So I have a couple of, a little demo. Hello, Worldfire for this as well. So it shouldn't take too long to demo this. And then we'll take a brief look at how containers work on REL8. And I think we need to call it a day at that point. It's a huge RPM, pick the wrong demo to do. I see, I think the Rust one's probably even bigger. Okay, come on, come on, come on. Almost there. Okay, there we are. So now I have go. So what I can do now is go to the demo's directory that also lives on this machine. I have a little go program called helloworld.go. It's, if you write go, you know, it's pretty simple. It's just package main import format. And then it says, hello world, hello from go tool set REL8. So we can just go build, hello world.go, and then we go into binary. And that's it. So we have go available on your system, just the Rust, just this node, just this LLVM, everything is just there. So let's take a brief final look at the way containers work. If you've paid attention over the past couple of years, you know that we've built together with the community a couple of purpose-built tools, scope.io build a potman to manage your containers with and build your containers with basically along the UNIX philosophy of do one thing and do it well. Don't have a demo running if you don't have to. And because it also aligns nicely with what the upstream communities in OpenShift and OKD are doing with CRIO. I won't go into a lot of detail about the backgrounds there, but just know that we have potman available on REL8. There it is. I installed this because it takes forever to install because there's an SELinux add-on. It needs to compile at installation time. Potman, run mitregistry.access.rel8.com. We have REL8 container images available for you if you want to play around with them. I suggest you do. And just say, just hello, Dev Nation, REL8, awesome. And I should be able to run this. I will pull that REL8 data image from the Red Hat registry and run that echo command in it. Now, we can also do that with a REL7 image. They should be compatible with each other in a REL8 kernel space in a REL7 user length. We pay a lot of attention to making sure that works. Just wait for one or two seconds to, there we are. Hello, Dev Nation, REL8, awesome. So there we have potman run. Now, potman can by itself build let's go into the container directory there. Potman can build containers based on a Docker file. So if you want to build, if you want to, basically you could sim link potman to Docker with this command line compatible. So we can do potman, let's forget what this is, build, tag it as bnl demo, and build it. So we'll just build the Docker file that's listed there, pull down the REL8 data image board, you got that. And we can now see what images we have built. And we can actually pop them in and run that thing that I built a couple of seconds ago. It should output that exact thing. So potman can help you build images quickly and pretty easily. Builda can actually help you do that in a more flexible way without having to rely on a Docker file. Builda allows you to basically mount a virtual file system on your system and then install your software with YUM or just by copying files into that directory. And you can do that with any kind of scripting you want. We'll give you one layer of container image. And you can do that very easily as well. There are great tutorials about that from Dan Walsh. But I think I have to call it a day at this point because we're 28 minutes in. So I'm going to switch back over to the in Expo screen. I'm going to stop my screen sharing. Maybe we can do a little bit of questions and answers. And we have a lot of different questions. Let's try to hit a couple. One that was very obvious is the web console looks awesome. But what if I have 1,000 or 1,300 servers with Carl's question, 1,300 servers to manage, what would be the strategy for managing a massive number of servers? Yeah, that would be ansible, right? I could theoretically, I think I showed that, I could theoretically add all of those systems to the web console and manage them all by one. That's not what you want to do if you have 1,300 servers. So that's where ansible comes in. You can write a nice playbook. The playbook can touch as many servers as you want. And then your life as a CIS admin or as a developer, no matter what, becomes a lot easier. So ansible is your friend there. And satellite, I think as well. Is that another key ingredient from this architecture? Oh, yeah, yeah, obviously. Yes, I'm trying to figure out which sound I should make. Sorry. Yeah, satellites should definitely play a role in that as well. I actually made sure my satellite worked with these demo VMs earlier on to make sure that all of the software I wanted to install was lightning fast. Satellite makes it easier for you to make sure that you can have a fixed patch cycle. So if you want to do it, if you don't want to just talk about configuration management, which I was before, and you want to talk about patching and doing software releases based on RPM, just satellites is definitely where you want to go. And for VM provisioning as well, it's awesome. And then we're kind of running out of time, but I want to make sure we talk about migration. That came up as a question multiple times. People were like, hey, I've got REL7 servers. How do I upgrade my grade to REL8? What would you say the strategy should be? What should people be thinking about as it means preparing for their migration, their upgrade? So let me see, yeah. You can do various things. We do try to provide an actual upgrade path, as far as I know, between REL7 and REL8. So you can actually do the in-place upgrade. My recommendation based on experience would be you could do that, but if you are moving towards a more cattle approach of all of your systems, I have cloud image and all that kind of stuff, you probably have your Ansible Playbooks ready. You could redeploy your system in a breeze. But if you can't, that upgrade path is brilliant. And it would really take a lot of the pain of moving between different valve versions. OK, now it's a key question that people are very focused on. There's a bunch of other things, too, that were interesting. One was, can I build images without needing to be root? Can I make that a service that my users can go create their own craft drone images without needing to be root? Has anyone thought about that from a REL8 standpoint? So if I'm not mistaking, I actually did that for these images. Because I always try to do a demo. You try to take every possible opportunity for a failure out of the workflow. So I logged in with root. But I can log into that web console with my normal user. And I can just build those images with my normal user account. It's actually not a problem. You could do a build farm for each and every development team could have their own web console system and build their own images and push them into a cloud. It should be a problem. OK, good. And that makes sense to me, too. And then one thing I want to just double click on. And then, unfortunately, we're out of time. And I apologize that from a question standpoint. But what about my software collections? AppStreams, does that replace my software collections? Just talk about that one more time, because I did see that question come up several times. Yeah, so AppStream solved a problem. So I'm not a product manager. We have a product manager here in the room that would be very welcome for this question. But to my understanding, AppStream solved the problem. But it also didn't solve some other problems. And with AppStreams, what we can actually do is put those binaries in the expected places on your systems, like user bin Python. It's not in some path in opt or whatever. And that makes it easier to develop for those systems and bring those new versions into rel in the locations that they're expected to be. I'm not the person to tell you whether or not AppStreams are completely replacing software collections in the end. That's all for product management, to say, I think. OK, and that's a fair point. And unfortunately, we are out of time. We're over a lot of time for running these webcasts. Thank you guys all so much for your questions. Feel free. You guys all have my email address sent to the right person to answer them. But otherwise, we had a lot of engagement and lots of questions, lots of ideas. The demos were awesome, by the way. I think you did an awesome job. So thank you so much for that. And the presentation was fantastic. You're welcome. What I can do, I'll just drop my Twitter handle again in the chat box. So if you want to ask questions that are for the benefit of the whole world, just ask them there and I'll try to answer them. And yeah, if not, my email address is pretty simple as well. So let's drop that in there. All right. All right. Yeah, and I'd need your Twitter link there, too. All right, well, thank you so much for your time today. Thank you all for attending. Max, awesome job. And hopefully, we'll get a lot of questions in the back channel on our Twitter and email. And then otherwise, please go download that RHEL 8. We gave you the download link. And make sure to check out the cheat sheet and make sure to check out the other resources we added to the chat. Thank you so much and have a great day.