 So, as you probably know, Fedora IoT images are official Fedora images that use the OS3 technology. And OSBuild Composer is a web service for building custom operating system artifacts. So, this means, for example, virtual machine images, but also OS3 commits. And you can deploy OSBuild Composer locally, and it is based on OSBuild, which was presented at DEF CON last year. And you can find a link in these slides. Now, I will very briefly introduce OSBuild Composer itself. As I said, it is a web service for creating customized operating system artifacts. And in order to specify the customization, you need to create something which we call a blueprint. And you can see very simple example of a blueprint here. It's a tunnel file. And in this example, I have created one user with name test and password password. But you can also install additional RPM packages or enable system these services and a lot of other customizations. Now, Christian will talk about OS3. Okay, what is OS3? The tagline of OS3 is like git but for file system trees. And that means that basically all the stuff that is stored in a repository is content-addressed very much like git. And then a commit in such a repository is basically a complete file system tree. So you basically get to a commit if you have a complete root file system tree like your normal Fedora installation, for example. And then you run OS3 commit command on that tree. And then you put all the files very much like a git commit command. Like put all the files in one atomic commit that belongs together. And then you can have multiple ones where this previous commit is referred to as a parent very much like in git as well. And then if you want to actually use such a commit, you have to create a deployment which is basically as in git a checkout of that commit. Plus a kernel that is contained in the commit and bootloader. But obviously you also need some state which is contained at C and bar. And then in this checkout that you do to save space, you don't actually, as in contrast to git, you don't actually create copies of the files. But what happens is that you create hard links into the repository. So all the files on your file system are actually hard links into the same file in the repository. Which obviously only makes sense if the files in the file system is read only otherwise you could, you know, edit the files and then you would hose up the commit that you don't want to. So this whole thing basically assumes that you have an immutable system image that is self contained. And then very much as in with git, you know, if two commits contain exactly the same file, you can share the same file because you just get another hard link into, you know, the repository. And then between deployments what you share is the state that is an Etsy and bar. And if you like, switch from one commit to another level, there will be three way merge between old state and Etsy new state and Etsy and the configuration that you have made the files yourself. One thing that is very cool about RPMOS tree is that it allows you to layer specific packages on top of your base image because, you know, if your base image is immutable, how do you get additional software on top of it? Well, there's this feature of layering that, you know, in the newest version of RPMOS tree can even apply it live before you had to actually do a reboot. And obviously the other features you could use is flat pads or containers. And the big, the two big feature that I actually gives you compared to a traditional system is that you have this immutable system images and you can do atomic updates because when you, when you basically switch to and you commit what would happen is that you prepare deployment and then only on reboot when you reboot into the new system, you will actually reboot into this new deployment. If something goes wrong, then you can easily just revert to the previous commit to the previous deployment, which is exactly in this data as it was before. And in Fedora IoT, there's even a feature called Green Boot, which does boot checking. So like you make a new deployment, try to boot into it. You will try it three times to put into the system if it doesn't work. So if, if the Green Boot success target from system D is not reached, it will automatically select the previous deployment as the next boot operation. So after on the fourth boot try, you will actually end up automatically in the previous commit, if the new commit does not actually deploy properly. Overview. Back to Martin. Yes, thank you. So I will show a quick demo. This demo is a little bit more complicated than creating the image and simply booting it. Because in this demo, I will create an OS3 commit and then I will create an HTTP server that will serve this commit in an OS3 repository. Then I will need to download Fedora installation ISO and run the ISO in QMU and finally configure Anaconda to install the commit. So as you can see, the demo will be quite long. So first of all, I need to make sure that I'm creating the commit for the right Fedora release. If I want to create an OS build composer, then at the moment only create OS3 commits for the same Fedora release that the host system is using. So in my demo, I'm using Fedora 33. I've also created a blueprint. As you can see here, I want an additional user in my system and I want the fish package to be installed. Now I can use the composer CLI tool to push the blueprint into OS build composer and I can start a compose using the compose start command and name of the blueprint as an argument and also Fedora IoT commit, which is the name of image type that we use for Fedora OS3 commits. And you can also monitor the status of your running compose using composer CLI compose status. And once the compose is finished, you can download the OS3 commit inside of a terrible using the composer CLI compose image command and you need to specify the UUID of your compose. So now we have the quest three commit inside the star ball. So next we need to download the installation ISO for Fedora 33. In this case, I will use the Fedora net install ISO and I will create a configuration for Anaconda. As you probably know, you can create a kickstart file that will instruct Anaconda what to do in order to install the system. So, I will not describe the whole kickstart file, but on the last line, you can see the OS3 setup command, which specifies where to look for the OS3 commits for the repository and what to download from it. If you are wondering where the 10.0.2.2 IP address comes from, it's because I will use QMU to boot the VM. And this is a special IP address that you can use to reach the host system. Okay, now that I have to commit and I have the installation ISO and the kickstart file, I need to serve the OS3 commit using some HTTP server. So my first idea, of course, would be to use something very simple. For example, the Python 3 HTTP server. Unfortunately, OS3 produces a lot of requests and the built-in Python HTTP server cannot handle the load. So what I will do instead is that I will create a container that will run HTTPD. And I will place the OS3 commit and the kickstart file inside this container. So, as you can see here, I have the Dockerfile and the table and the kickstart file in a single directory, and I use what man built to create the container. Now I can simply run the container and bind the HTTP port to port 8000. Now I open another tab in my terminal emulator and I need to create a disk image. So previously I downloaded the installation ISO, but that's not a disk image. You need to create a disk image separately so that you can install the new system to it. So I'm using the QMU-IMG command to create a disk image for my VM. And I want to create, for example, 5 gigabytes disk. And then I can use QMU-System x86 to actually boot the VM. And as you can see in the command, I specify the federal net installation ISO as an argument and also the disk image. Now when I hit enter, I will see this screen. This is the standard booting screen. And now you need to interrupt the installation process and you need to move focus on the install federatory 3-line. And then you hit tap. Once you do that, you will see the grab command line. And can you see my pointer? Yes. Perfect. And as you can see here, I specify the location of the kickstart file that is available from the running HTTP server. Now when I hit enter, Anaconda will automatically download the kickstart file and I specify the OS3 repository and commits in the kickstart file so the installation will happen automatically. So once this is finished, I will see my customized Fedora IoT image. And as you can see here, I can log in using the user test and the password. But I forgot to create a home directory for my user so Besh complains that it does not exist. And I can also make sure that Fish is installed and Fish is complaining even more about the fact that I have forgot to create a home directory. But as you can see, the user is there and the package is there as well. So we have successfully created the custom Fedora IoT image. Now back to Christian. So what are the current features that we are supporting? I mean the first thing is obviously the customizations that you can do by the blueprints, like creating users, the colon, the time zone and others. There is a communication somewhere that you can look up. And then very recently we added support which is not yet released so that we can create a commit directly in the container with the web server. Basically the step that Martin showed where he manually creates a container via a Docker file, we can now directly natively do so you get the container with the commit directly from OS build and Composer. And then also the last step that is the TDS that you have to download the net installer and then manually specify the kickstart that you created on the command line. We also can now create boot isos ourselves and have the OS recommit directly in the installation image so that when you create the boot loader, the boot ISO you can get it. Use it on this image file that Martin created as well, and it will automatically install the commit without any intermediary web server or something needed. Okay, next slide maybe. One of the features that are missing like one obvious one is that for currently it's only 8664 supported. So I would be nice and also currently we don't support making raw QCAR images based on commits. I mean OS build a low level tool can't do it but we haven't wired the bits up into Composer. So this is also something that if somebody wants to help out could jump in. What also is currently a bit cumbersome is the whole infrastructure on commits. It's not very basically end up with like either an install commit. And then in order to create updates you have to somehow like look at the commit idea itself. It's a bit cumbersome. And then maybe there would also be, you know, room for more customizations. All right, I think that's it. Thank you. Any questions. Okay, it's time for Q&A section. So if I want to ask any questions, put them in the chat or Q&A section. So one question from Dan Chermak. And it says how hard would it be to split up the old story image image generation out of OS build so that other image builders could use it to. I mean, there is a there's a tool called RPMOS tree that and it's just the same thing that you manage the OS tree installation with the algorithm. And it can also take, create these commits based on a thing called a tree file that you might look up. But for S build itself, the way we support creating the OS trees is quite deeply integrated in OS build. Like, OS build is super flexible. We couldn't create, you know, all sorts of artifacts and the way OS build the little tool works is that we have a bunch of stages that are run one after another and they work on the file system tree. So there's an RPM stage to install the RPM and then there's like the user stage that creates the user and then there's a few stages that prepare the tree for the RPM commit for the OS tree commit and then there's an OS tree commit stage. So, like ripping this out and making it available for some other image builder would basically mean you reimplement all of this. But, or as well as real level tool, maybe you can just integrate was built itself into other image builders. If you wanted to do that. Okay, there's another question from James. Can the customization include using Python bit to install Python modules. So, if the Python bit module is packaged in RPM, you can install it, but we don't support installing the raw Python modules using possible composer. So, yeah, that's probably it. And other questions from Benjamin block. How hard is it to add custom modification to the image that are not packaged in RPM. Is that possible at all. And so what kind of customizations you mean like files or, or, I mean, as the low level is always a, there's always this sport of Queen, but, or as well the low level tool can do and there's lots of room for making customizations there but then the question is, you know, what composer, which is a thing on top that actually knows how to, in, you know, how to make a fedora image for example what goes into it, and how that can be customized and there we don't support that many things because, you know, we want to like mess up the system too much, or maybe we haven't even just thought of some of the customizations that are needed. So if you have some pressing ideas or so then maybe come to us and the bug tracker issue tracker and file them. Another question from Dan Chermark that says so always built is the low level tool invoked by always built composer. Yes. So always put is like, you know, we always say it's the specific assembler that is, you give it a manifest and the manifest contains, it's a chasing file contains everything to produce the image and if you run it twice it will produce the function exactly the same image and basically there's some differences because time steps and tools, you know, like RPM whatever, you know, sometimes create files and so the time sense of the files where they will differ but you know the image if you, you know, run the manifest, the same manifest twice but basically produce function is the very same exact image. And it supports all sorts of things including like chemistry commits or, you know, Q cars and stuff. And then the knowledge how to make a fedora image and the knowledge how to make a real for edge image or a real image which this is basically how to plug the stages together to make a West variant out of this this list and composer, which is providing this web service and queuing and work management and all sorts of high level functionality and talk. Okay. And fear another question. Does always build composer have any relationship with core OS assembler by James Pali. So far, not. I mean, we, we are in context and in talking to Colin and the group around there, because there and there is some efforts to maybe like share some bits and pieces and maybe, you know, streamline the two things together a bit more. But so far, there is no, like, there are no bits share so far, not yet.