 Okay, so hello, I'm Wendy from Red Hat, the Anaconda Instar team, and today I would like to talk about customizing the system Instar. I'm one of the developers and maintainers of Installer for Fedora, RL, and other distributions. So how can you customize the system Installer? So basically we have one application, but it looks a little different on every distribution. For example, this is Fedora Silver Blue. Silver Blue and Workstation is trying to provide very minimal user interface, because they are installing global initial setup, so a lot of configuration happens after the first reboot when you can set up your user account and stuff like that. So it doesn't make sense to show it during the installation as well. Fedora Server doesn't have this option because it doesn't necessarily install graphical system. So all configuration happens during the installation, so there are some additional screens. Then the SynthOS stream, it shows all available add-ons that we kind of have at this moment. And the RL, we have additional support for Red Hat subscriptions, so that's another screen. Okay, so what are the most common customizations that are asked by users? So one of them is very obvious, it's branding. People want to change colors and change the background of the left bar and upper bar and add a logo and some names. The other thing, customize defaults. So when we have some UI elements in the code, you want to control what's going to be displayed there by default, because in the ideal case, you don't want users to click on it, and in the ideal case, they would just be happy with the defaults and continue with what they need to do. But different distributions have different expectations and policy and directions and group of users, so they don't agree on these values. So you need to find a way how to customize it as well. As I already mentioned, Silverblue and Workstation are showing very minimal amount of screens, so we support hiding these screens based on their names. So distributions can have full control over what's going to be displayed to the user. And there is a little more advanced thing, and it's limiting the functionality. This is a little different than hiding the screen, because hiding the screen will just hide the UI elements. While when you want to limit the functionality, it will also disable some parts of the installer, so like Anaconda will not touch these areas at all and will completely ignore it. Where it is used the most is the support for the redhead subscriptions, because this is disabled in other distributions, and we just don't want Anaconda to look in that direction, so it's disabled for these distributions. So how these things are actually configured. We use something we call Anaconda configuration files. It's not very surprising, it's just a very simple file in the format. We have some sections, some options, some comments. Even though it's not surprising, we didn't have anything like this until like few years ago, and it was very painful, so this is basically the reason why I'm giving this presentation, because the customizations are not new. What's new is how you can do them and how the code is working with them. So we basically use the same format, but we use them in four different ways. So we have something like four types of configuration files. The first one is the default configuration file, and that's just a fully defined configuration that's just like this base layer, and it contains like every default that normally would be in the code, because we had like a lot of hardcoded fallbacks, like if this is not set and this is not set, then use just this one. And since it was hardcoded, it was very hard to change it or find it why it doesn't work. So now it's there, and we just use it as a fallback here, and we could remove these fallbacks from the code, which is great. The other area, our profiles, profiles are basically like named configurations that can be used for specific distributions, I will get to that later. When we support something like custom configuration files, there's just a drop there, and you can like put there anything you want to change, and we will automatically load it and apply it, and you don't have to care about anything else. And the last one is the runtime configuration file. This is the file that we generate. I will get to that later as well. So what are the Anaconda profiles? So as I said, different distributions have a little different configurations, and we need to somehow keep them in our code base or packages, and we need to decide when we want to use which profile, and it needs to be very deterministic. You don't want to, I don't know, start for the workstation, but show something very different because people are confused and report bugs, and you don't want that. So this is basically the reason why we started to look into the Anaconda configuration files because before that, we had something like this. It's called Anaconda install class, and it's just, yeah, it's a Python code, it's just class, which is based on another confusing class, and there's some logic for like deciding if the class should be used, and there are some options that you can like change and set, and there are some functions. Like, this could easily, this could very easily broke, and it happened several times because it's Python code, so there's usually like a bunch of imports on the top of that, and when we moved to function somewhere, it broke like all these classes, and the bad part was that these classes were not even in our code base. They were installed by some third-party packages, and sometimes we had even hard time to find which packages provided these classes. So yeah, this was like a nightmare for developers. So what we did instead was to introduce the configuration files and create something like a profile. The profile is basically, the format is the same as we saw before. There are just two additional sections. The first one, the profile, defines the profile. Every profile has a unique ID, and it can say that it's based on another profile. And what's cool about this is that very often we have these families of distributions like Fedora, Fedora server, and Fedora ROX session. They share a lot of configuration, and we didn't want to duplicate the code and create new configuration every time because it would be very difficult to keep track of what's changing and if the configuration is really correct. So basically, we introduced something like a simple inheritance, and you can just say, okay, use everything that this Fedora profile is using, but I want to change some additional stuff, and it's working pretty great. The other section that support for automated profile detection. So basically, Anaconda can choose a profile in two different ways. The most straightforward one is that you just specify, use a profile, you provide the profile ID, Anaconda will find the correct file, and do everything. What's most common is that you don't define the profile at all, and Anaconda chooses it based on OS release values of the installation environment. And there are some options with some values, and we just match them against them. So like if the OS release file contains these OS ID and variant ID, then we will say, okay, this is the profile that should be used and use it. This looks also very obvious, but before that, it was really complicated, and we had a lot of bugs when just some install classes jumped in the priority and very used when they couldn't. So simplifying it solved a lot of our issues. So the methods of the profiles, I already mentioned some. Yeah, the Python code, it was just horrible, please don't ever do it. Like if you have this option, just say no. The fact that we support only single inheritance, I also see it as a benefit because multiple inheritance, it's cool, it's just sometimes a little unpredictable and hard to understand. People were actually asking for support for multiple inheritance with the configuration file, we said no. Then yeah, we definitely simplified the product detection. It's very primitive, but it's working, and we don't have any issues with that. And one of the biggest benefits is that with the install classes, so we created this object and we had to drag it everywhere in the code. And every time we had UI element and we wanted to decide what was going to be there by default, it was really horrible because we had four different sources that could provide us this information and we had to check all of them. So it was like the user set it up, was it set up in the Kistar file? Is it set in the install classes? And if no, use this hard-coded default. So every time we wanted to touch it, you had to test all of these cases because it's like four different branches. So yeah, that wasn't fun. What was great about Profiles is that they are just very natural part of Anaconda configuration because they are just merged into this one configuration that we use when we're on Anaconda running. And it's called runtime configuration, so let's look at it. Runtime configuration is basically just fully defined configuration of the actual run. So we just merge all the sources into one file. We generate this file and everything that we run after that is using just this temporary file and that's it. And what's great is that everything that we run after we generate this file, it doesn't have to care about profiles or just some customization or stuff like that. It just uses this one file and it just has everything in it. So how is it actually created? We basically parse and merge a lot of configuration files. So we start with the default configuration because it's the base layer. Then we select the profile and read everything that's related to that. Then we load the custom customizations. Then we actually change some options and sections based on the kernel arguments and command life options. That's also great because we don't have to deal with that later. And then we have this one actual configuration in the parser and we just generate it into a file and that's it. And what happens next? After that, we start something we call the debas modus. And basically Anaconda is no longer just one process. It runs multiple processes and each process has a different meaning or area. It cares about the storage network. And when this process is started, the first thing it's looking for is this runtime configuration. So these processes, everything that we start in Anaconda has access to the same configuration. And it's really great because we don't have to care about a lot of stuff. We can just initialize everything as we import it and as we create these services. So this is very cool. So the main benefits. I guess the biggest one is that we have just this single source of default values. We don't have these horrible branches when we have to check all these values and everything and we just ask this one thing and everything else was already resolved. So this is great. It's also much more thermistic. Yeah, thank you. The other thing, yeah, this file should be constant like once we generate it. It shouldn't be, can you open it, please? Once it generated, it shouldn't change. That's basically by design because we don't want to check these later. Because you don't want to check these later and update these values somewhere because we no longer remember that these were some defaults. So the file should be constant and it's removed after Anaconda is finished. The biggest selling point is that it's accessible from everywhere pretty much. So here are some examples from the beginning of the installation. Presentations, sorry, too much installations. And how can you actually do them? So it's pretty straightforward. The branding, with the branding, you can just provide your own CSS file and change anything you want, basically. So the images are in these files. And the custom style sheet is just loaded based on, like, on top of our style sheet. The custom line defaults. So since it's very easy for developers to use these options and defaults, it's just everywhere in the code. So you can very easily change something and it will have impact everywhere. So the default scheme is used also for auto-partitioning in the UI. Yeah, it's very easy to change your default right now. Then the hidden screens. I'm so sorry. Then the hidden screens. You can just specify a screen by its class name. We are going to change it to screen IDs to make it usable in the UI. But the principle is pretty much the same. We just ignore anything that's mentioned here. And then you can, like, disable any of the Anaconda modules. It's not any. We don't support all of them at this moment. But you can disable most of them. And the most common example is with the subscription when you can just say, tell Anaconda to never, like, touch this area and don't use this module. And this code will never be started or run or accessible, which is great. So I made it. Does anyone have any questions? Yeah, and there are some additional information if you want to. No. Oh, sorry. Yeah, the question was if the configuration can be defined in Kickstart. So I think, no, because it's just we need this information very early. And parsing Kickstart file is not, like, trivial operation. And we already have to need a lot of stuff set up. And we need to configuration early. So I think the only way how to get it to the system is with an updates image. Yeah. Or install it, like, by a package when you create the boot. So it looks like this is it. Thank you so much. Yeah. So these profiles are actually in our code base and we install all of them. So they are on the system. And I mentioned that we detect, like, what kind of system we are running on. And based on that we choose the profile. But the current policy is actually that we have a lot of profiles or some obscure distributions because why, why not? So you can find them actually, yeah, in the profile. There are a lot of them. Yeah, it's both. We have a boot option where you can specify the profile ID and it will just force this profile to be used. But usually it's auto-detected and we look at its OS release file and it just describes the installation environment. And the practice is that the installation environment is basically what you are currently installing. It's complicated. So it's enough. So we are able to, like, detect what kind of system it should be and choose the profile based on that. Yeah, definitely. It's already injectable. You can use all your profile. Or if you just don't care about profiles and want to just change something, you can use the custom configuration files because it's just a directory. And it's merged, like, it's the last thing that we load so it will overwrite anything else you can. So it's very easy to, like, play with. But yeah, it's Instaur. So Instaur is not very fun to develop. Yeah, it's very easy to change the configuration. Yeah. Any more questions? Wow, that's a complex question. I guess write us an email and we will try to direct you to the right people. I guess what you want it like... Yeah, okay. Sorry, I won't repeat the question. It's just complicated. We have a discussion section on GitHub, so maybe just trace our questions there and we will help you. It's just because when you create these ISOs, it's not just Anaconda, it involves other projects and it's a lot of tool handles. Yeah, maybe let's move to the hall so we can clear the space for the other person. So thank you very much and see you next time.