 So here I am with my little path project. I was working on recent hackathons, and I'd like to share the news, and here maybe, catch me on the form and booth, if you'd like to talk about it more, we have only 15 minutes. So why I'm doing that is, the reason for that is that I think, for everyone to have a good image-based provisioning unattended story. Now with the cloud, everyone is now doing image-based provisioning, right? Is this the right way to do it in the cloud mostly? And even other distributions, like Ubuntu, if you install Ubuntu today, it is actually image-based installation, and there's cloud in it. Also, there are other tools, like kind of metal as a service, that actually does image-based provisioning for bare metal. And I spent a decade working with Forman and Satellite, maintaining its provisioning capabilities, and these two solutions, Mass and Satellite are common in a way that they are pretty tough to install. They really want to control all infrastructure. They want to control the HTTP server, TFTP server. And if you can live with it, that's great, it works well. If you can't afford it, maybe you already have the HTTP server or other infrastructure doesn't really work that way, so then you're fighting against it. So I was thinking like maybe, can there be a little service that could provide you bare metal image-based provisioning? Because there's a common secret that Anaconda can actually do image-based provisioning, and this feature has been added in, I think, 7.2 Anthroposlinux, and it's been meant for virtualization, like Overt, but these days it's still used for all the stream installations, and you can actually use this for normal Fedora or real installations. So I was thinking like maybe I could write a project, a small little service that you just run, and it will provide opinionated provisioning for image-based provisioning, it's important, so it needs to have an image, and then you can deploy it. Based around Anaconda, so it is built for Anaconda, it will not work for other distributions at the moment because it uses some unique features, and it's also based that it only supports EFI HTTP boot, which is basically like a simplified or more modern version of pixie booting. You don't need to have a TFTP server, you don't need to have a really complex setup, it's much easier, it's just HTTP or HTTPS, and of course, secure boot and HTTPS and the HTTPS6, maybe these are all the features that customers really ask, right? So I was thinking like can I do that, and here I am with my project I want to share with you. So first of all, if you want to do any kind of image-based provisioning, you need to build an image, right? There are a couple of options. You can use LiveMedia Creator, which is in Fedora. It is, I think, not in RHEL, or second option I would recommend this one is to use Composer. Let's build Composer is a component program, a demon that you can install on Fedora or RHEL, and maybe other distributions, I don't know, and it is a common line client, so you can use it to actually build what's called Blueprint. Basically, it's like which packages to build, what the users you want to create, which gives us stuff like that, and then you create an image. Third option is if you go to consoleware.com, if you have an account, you can even use free account. Build image is there. Now, this service, it is basically a Go application, very small, it's called Forester Controller, that is the service that you need to run. You only need to give it a configuration in a sense that you need to point it to a directory where it will store images. That's basically it. It also needs Postgres and three tables, so it's not really big, and there's a CLI, and that's all you have, so you just build it. It's not in Fedora or anything like that, it's a prototype, I have a GitHub, I'll share it with you, and that thing you need to do on your infrastructure is to set your DHCP server in a way that you just want to point it to this service, right? So in my case, it's running on port 8000, and you need to go and give it the slash boot slash cmfify, and that's all you need to do. It's like three, literally three lines for Libert. For testing, you can actually use Libert, because that won't, you know, you can continue using the default network, and for ISC DHCP, you would do the similar configuration. Now the workflow is a little bit different from what you maybe know from Foreman. I call it AllaCard menu, and if you're familiar with Beaker, it's actually very similar. You first register and apply, and so in this workflow, EFI really don't work well with fallback mechanisms of BIOS, where you boot from network and it doesn't boot, then boot from hard drive, that doesn't really work in EFI. So this service actually provides out-of-bound management capabilities, meaning it needs to be able to power on a server and power it off and change boot order. So for this, I'm planning to add Redfish API, right? And also maybe IPMI in the future for now, so the project only supports Libvert. That is meant for testing. It's not meant for that. You would like to install images using booting from network, that's really not the way to work. So first thing you need to register appliance, in this case, you know, Libvert, that is only supported appliance right now, and then you do end listing operation, which terminology is a little bit vague. I'm not still trying to find it. This is borrowed from Ubuntu mouse, but basically it will go and search all your, let me say, blades within your chassis, or in this case, Libvert VMs, and it will store the inventory in the database, some information about them, specifically UUID, so you can actually power them on and off. And then you can power them on using the API of the service, and it will boot into Anaconda, and Anaconda will, because these systems are not yet set or configured to be installed, it will actually do what I call discovery. It will basically try to run a DMID code and find amount of CPUs and memory stuff like that, and it will report these facts back to the service, right? That's exactly what Beaker does, except Beaker actually installs the system. This one is basically Anaconda, and then it shuts down. And once you're ready, or before you can be ready, you need to upload an image, so you have an ISO image that you've previously built or downloaded from our portal, or created in OSBuild Composer, you upload it to the service, and the service, oh my God, hopefully this work, and the service will actually extract some files, key files like shim, bootloader, grub, Anaconda, and the image itself, and then finally you're ready to acquire the system. Again, terminology is acquiring means, like you take it from your list of inventory of available machines, and you just want to put this particle image onto this system, and that's it. If you're ready to release the system back to the pool, you just call it release, and this is basically the operation workflow. As I've said, I'm using some unique features of Anaconda, specifically live EMG or prescript and HTTP headers, but this is not important. This is my Fedora cockpit, and I'm running terminal, and here this is how it looks like the service. You just call us CLI, it has three commands, image, system, and PLI, and so first step, I have an image here called test one, and the important thing is it is UFI image, it needs to be, sorry, UFI VM, because UFI HTTP boot is a special thing, it doesn't work on BIOS, because BIOS, a Pixi doesn't have like a full HTTP stack, it only has like UDP, very simple protocol, so you need to have an EFI. So the idea here is you have a bunch of servers, and you have let's say IPMI or Redfish API management, so you can actually like do the same workflow with these. If you want to put an image in the cloud redhead.com portal, this is how it looks like, make sure to check bare metal here ISO, that is the type of the image you want to build. Or you use image builder, image builder has a nice user interface, this is my home server, and you can actually install OS builds cockpit plugin, I think, and allows you to like do all the customizations like put the SSH keys there, and first boot scripts and things like that, so that's great. So once I have an image, I upload it here. So this line image upload, you'll give it a name, and then the ISO, right? And then I list all the images, so in this case there's only one image called the row nine. Now I'm ready to define appliance, this is basically like a machine or chassis with multiple blades, in this case again this project is a really early prototype, so it only supports Libert as like a testing machine, right? And so I give it a name and it only supports Unix local connection, right? Now I can do endless thing operation, endless thing does is actually it connects to the appliance and lists all the, in this case VMs, these are not blades, I'm giving it a regular expression, I want only to use everything that starts with test because I have multiple VMs there that I don't want to have a list of systems. So every system has an important thing is MAC address or multiple MAC addresses, it's a list. Every system has a like generated name, pun, cockpook, whatever this is, it's just a random name, so you can use it. And then the most important thing is UID, so it actually can do a power operation. Now I'm going to reset it, reset basically means boot from network, like connect to the appliance and boot it from network. And now you'll see the system is booting up on the network, we'll try Pixi first and then falls back to the HTTP boot over IPv4, Anaconda boots up, and in the background you can't see it, but it will execute a Python script that will just collect some data all over the system, very similar to Beaker. And in the future you could maybe search for systems that have more than 100 gigs of memory or some stuff like that, it's not implemented yet. And then it powers it off. But now if I show the PEM system again, I see a bunch of new facts, and in this phase this system could actually do like CPU burn or memory testing or after provisioning it could actually wipe the drive, that's what Ubuntu mouse does, there's nothing like that is implemented. And now the final and the most important thing is system acquire, you give it an image, well, nine in my case, and I'm actually, I forgot to type in the name of this, like make address or the name of the system, that would not work, but suppose that I've typed it in, Anaconda starts up and it downloads actually like EMG tar, tar ball, which actually is your file system, prepares the drive, storage, copies the file over, prepares boot logger and stuff, and then it reboots and your system is installed. So that is it, that is my project called Forester. And going forward, so I'd like to hear your opinion if you would like me to continue work on this, and maybe I need to write documentation. Of course, until I implement Redfish, it's sort of like unusable, why would you implement provisioning of images onto a lever like that? That's insane, right? You would upload the image into a lever and run it, of course, so that doesn't make sense, of course. So Redfish is first one, my maybe Terraform plugin, there are some Bermetal Terraform plugins these days, but these are really tied to like a specific vendor or specific environment here. This is like, if you want to install Redhead of Fedora, and you have like a DHCP server, you can just, and a system that has PMC operation, like Redfish or IPMI, you can do that. And maybe Ansible module or some integration with console, or maybe alternative to Beaker, it could be interesting. So many options. I'm eager to hear from you if you like it or not. So now, a minute, we have two minutes for questions, and find me at the form and booth if you want to talk about it a little bit more. That is my project, thank you. And here's the URL, if you want to test it, it's really easy to like just jump in and forest.org slash forest.org GitHub. Thank you.