 Our next speaker is Thomas Voelner from Red Hat talking about how you can try to deploy free-ank here with us. Try is good. So, I don't need to introduce myself now. So, here's the agenda, but I think we can simply skip it. So, the goal of the project was to create roles, Ansible roles for IPA, that are not only a wrapper around the normal in small scripts, so that they can provide additional features, but heavily depend on the code of the installers. So, what they in fact do is they reuse the code that it is in the installer, call it into small pieces, and so in the end we will be able to replace, for example, a part in there. You will see later on we have several parts in there. One big goal was also to have exactly the same results. We can have additional things, but we need to have the same results with the same settings. Also, there will be a server client and also replica role. Right now in the repository you can find the server and the client roles. The replica role is in the work. It's not pushed because it produces an error in the server. And the support is free IPA 4.5+, for client it's 4.4, for server it's 4.5, and the replica will also support 4.5+. By the way, if you have any questions at any time you can ask me. So, here is the comparison between using the normal installers and the Ansible free IPA. For a normal installers you need to log into the machines, you need to set it up, you need to have principal password or key tab, you need to wait until it's done, then you can proceed to the next one. So, at first the server, then the clients and replica and so on. And with Ansible you have, that is a goal, a simple installation with more than one machine possible. You have one configuration file that is the inventory file per domain or realm. You have a simple use of OTP for clients. So, this is something we added for the client. It can be used in installation and in update processes. And it's more secure because you do not need to provide the admin password to the clients while installing or working on them. We have advanced auto detection for clients so it's not needed to provide all information that is needed right now for the normal client install script. And we can repair broken client installations. There is one exception, if the KRB5 key tab is missing we cannot do anything about this because for this we need another authentication. So, we come to the next one, the free IPA client installation steps. So, at first the domain discovery is done and validation of parameters, time synchronization, then the enrollment is happening, so creating a host entry and key tab. SSSD, PAM and NSS are configured, Kerberos, Klein is configured, PKI and DNS. So, right now we are coming to client configuration using Ansible free IPA. So, as I said the Ansible free IPA roles are depending heavily on the code of the normal installers. So, everything you do there you can also do with the Ansible roles. And additionally we have full auto discovery so there is no need to provide domain or realm. It simply gets this as a simple try from the FQDN of the client or the server. And it's using the DNS SRV or TXT records for LDAP and Kerberos to find them. There is by the way a small issue you can run into, so if they are pointing to something wrong, yep, I'm sorry. So, you can then say okay this is the domain I want to have, this is realm I want to have and it will overwrite the settings you get from DNS. Okay, I had this, I had this, okay we have three supported enrollment types. So, the normal one is admin principle and password but the common one. But I like the OTP version much more than that. It's really simple and Ansible free IPA client because it's only one setting. You only need to enable yes, I want to use OTP and it will do it for you. And you can also use a host key tab. So, here we have a very simple and minimal client inventory file for IPA clients. So, you see there is only the FQDN. Everything else is discovered from auto discovery using DNS records. And here we have the settings you can add there. So, there is a group that is named IPA servers where you add the information about the servers. So, the first one would be the master, the second one could be a replica and so on. If you do not have it, it will try to auto detect it. If it's not there, it will complain. IPA clients, this is also a group. You can have one to many entries there and Ansible will take care about this so that all of them are installed. And in the playbook or in the background, you do not see it directly. If you have already machines in there that are installed, it will be detected. It will be looked at the machine. So, is there something we need to do? Is there something we need to change? And if everything is fine, it will simply stop the processing of this playbook for the machine. So, it will continue with the next one. If there is something it will complain. If you additionally said allow repair, the setting you see online, oh, it's in here. The fourth one, it will try to fix the machine as far as possible. There are some cases, yeah, as I said, missing KOB5 keytab, we cannot fix this easily. So, the next settings are IPA ADM admin keytab password and principle. Principle is something you do not need to set. You can, but it will be automatically set if it's not there. If you do not define it, it will automatically be defined internally as admin. You most likely need to set the password in some sort. I prefer the way to use Ansible Vault for this so that you do not have the password in the inventory file, but in a vault file that is secured and you can use it in your playbook later on. And if you add, for example, the IPA client use OTP equals yes into your inventory file, it will automatically switch to OTP usage. And if the client already is part of the domain and there is a KOB5 keytab, it will simply detect it, will use it and will not produce any errors on the machine. If you have, for example, a keytab there that is not matching the domain and so on, so you cannot use it, it will detect that and also fail. So, for client, client is already major, I would say, mature. And the server that comes later is in earlier states. But I will discuss this later on. So, there are other settings, K-init, attempts, no NTP, this is wrong, should be no NTP and NK home there, for the client itself, and they are also available later on in the server. So, we now come to the playbooks, the minimal playbooks. So, here is install client YAML. Oh, it's dark. Oh, I'm sorry. Oh, oh. I'm sorry. So, at first we have the install client YAML file. You see here, it's using the host group IPA clients that have been defined in the inventory file. It uses a vals file to provide the password that is an Ansible vault, a secured password, and then it calls the role IPA client with a state present. If your samples replace present to absent, it will reinstall IPA client. So, as we only have half an hour, I do not have the most, but we come to server now. So, if you're using the script here, so the inventory file and also the playbooks, you can simply use them in the upstream repository. And there are also examples, also the variables are explained there. So, for IPA server, you see the list is a little bit longer, there are much more steps. So, there's domain discovery which is currently not really in there, but it needs to be in there. So, for example, if you have already a server or, for example, the wrong DNS TXT records, the normal installation, also the Ansible IPA server installation will simply fail because at some point it will use them, sadly. So, there will be some additional domain discovery code or domain discovery in the beginning of the IPA server setup so that it's able to find out, oh, there is something conflicting and maybe we are able to discover how we can solve this then, or it will simply fail. We will see. It will validate the parameters in this step. It will configure the firewall. This step is up to you right now because we do not have one firewall solution for all. The next step is time synchronization and configuration, directory server configuration, Calvars, certificate server, Calvars again. OTP, Custodia, HTTP and so on. You see it's really a long list. This is one of the reasons why it takes a little bit longer to install the server and in the end there is the client configuration. And lately I've been able to use IPA client role for this because in Ansible I had a fix that I can use. So, include role can be used now for the client. So, it's really nice. IPA server is using IPA client role to set up the client with on master settings. So, now we come to a server inventory file. You see, it's a little bit longer but you need to set some things here. And here I simply added the passwords. Yeah, I know they are rubbish. And you can simply also use vault passwords here. And here you also see an excerpt of the settings you can use for the server inventory file. All of them are explained in the repository. So, there is a server MD file. So, here you see it's using IPA server because I want to make sure that everyone understands there's exactly one server because IPA replica is another thing and with the combined playbook that we will have later on it will be possible to make this a little bit easier so that it could auto discover what is the real one or it will take the first one as real master and the others as replica. And we have bars here. So, we need to set the domain but we can also get this from the FQDN which is right not there and also the realm. We have the admin password and the DM password that we should set either this way or with a vault file. And if you look further down you see there's also IPA client no NTP, IPA client MK home there. So, the server already tries to make it more obvious what it will be affected by the setting. So, there will be some adaptions also in the client and there it will also be reflected in IPA replica so that you have the same settings everywhere. So, no NTP and MK home there are things that are affecting the client and it's done there. So, they will use this prefix as a name. So, the next ones are the playbooks for server. So, we have install server and uninstall server. You see they're very similar to the other one to the client ones. I left out the vault file here because the passwords are already part of the inventory file. And the next one is then the cluster inventory file. So, this is really something nice we can do now. We can install at first the server and afterwards several clients. And to have settings that are available for IPA client and IPA server at the same time, I'm using an additional group which is IPA. It's not used later on. It's only here to make sure that the settings we have in IPA vars are available in the clients of IPA. So, IPA server and IPA clients. You can name this group whatever you want to. But please don't use IPA server, IPA client for this. So, with the IPA server vars we have in the top. This will only be visible in the IPA server role. And IPA client vars will only be visible in the IPA client role. So, we have some separation but... Do you have a question? Okay. But it's possible with some tricks or with some magic to access them also. So, it's not really separation but it's simpler for the user. And we come to the playbooks. So, the install cluster playbook is a little bit longer than the other one because it simply consists of two. Right now, the server is tried first and then the client and if the server fails in this playbook, the clients will be tried to install either way. But we can combine them. But it's not done here because for this we need some more magic in the playbook of the server to make sure that if the server is already installed, it's not stopping the processing for the client. And what I've done here, if you have a look back at the previous slide, you see setup DNS is turned off here. And auto forward is also not enabled because it also needs setup DNS. This is because I'm using the external DNS server. So, there's already mapping and various mapping. And if you want to use setup DNS, you need to add an additional step between servers and clients to add the client up here, there's his names, FQDNs into the DNS server of the server. I left this out. There is a module already available in Ansible itself, IPaHost with add and so on. It should be simple to add them. And finally, we come to the uninstalled cluster. So, it's simply a reverse of the install cluster YAML file. So, at first, it uninstalls the client and then installs the server. And after you've done this, it's behaving exactly the same as with the current installers. So, it cleans up mostly all files. There are some remains, yes, but this is also with the normal installers. And we might address this at a later point so that we will fix this in normal installers and also in the Ansible installers. So, I think I was too fast, right? 10 minutes for questions. Maybe we can switch the light on? Yeah. Or maybe I can show you an installation, but it will take some time. Well, 10 minutes? Let's see. I think 40 minutes, something like this. So, here I have virtual machines. There is a server. Here are three clients. Two of them running Fedora 27 when it's Rails 7.4. And I used the uninstalled before so I can simply run install. And it will... Here are some deprecation warnings from Ansible. Oh, great! Oh, no, I have no network. So, it tries to install the packages. And it will simply fail. Expected, I'm sorry. So, we should have something soon. Come on. Well, you can try to use the local... No. So, now it should be able to access the repositories for the packages. Come on. Ah, okay, looks better. So, it first installs the packages. Oh, there is, by the way, a warning from the normal installer that currently will be disabled. Yeah, in the server, this needs to be addressed still. There is code already to not depend on NTP, but it's not there yet. And I'm using the upstream repository here. So, you see, it's doing a lot of things. I started it in verbose mode. So, here, it's doing the tests. It creates the IDmax, IDstart. It detects IPAPython version. Oh, by the way, this is also an interesting thing. As IPAP bindings are up to now partly Python-free, or mostly Python-free, there are some issues with older versions. So, what the roles are doing, or the modules that are used in the roles are doing is to detect what Python version do I have in the system. Can I use it also for IPA? Do I need to go to two, or can I use three, and so on? So, there are some version checks in there, and also to make sure that the imports are working. Sadly, we cannot support old IPA versions right now, and I don't know if we can get there easily because there have been major changes internally, and as the modules that have been created for this are using code from the installer scripts. The old installer scripts have been a long thingy as spaghetti code, so it's not easily possible to get some pieces out of it, and for IPAP Client 4.4, I already did some tricks to be able to use the script, yes? I have one question. You're doing a lot of stuff also regarding the system-basic configuration, and as said, I'm doing Ansible myself, and of course I'm also writing for the service, it's okay to say it needs this system environment, those OS packages like NTP or something like this, but for all the clients you have out there, it's pretty hard to decide where to draw the line, and where you interfere with some basic modules, but this is an issue with the normal installer scripts too. How do you draw the line? How do you find out what to do? Right now, we're doing exactly the same thing. We have them as long as the install scripts, the normal ones have them too. But this plan, for example, we have the module to set up NTP, and as soon as there's a role that we can easily use for NTP configuration, we switch over to this one, and we will do the same for Kaveros, for SSSD and so on, so it was really important to split the whole thing up into small pieces that we can simply replace at some moment with roles that are providing the functionality and are able to really configure a service. But I found that if I split things over roles, I found it hard to really pass notifications or structure the system like this that any change is really notifying each other to be restarted. If you split over roles, that's pretty hard. That's almost unpeasible. We're more than that. One thing that... another thing that we do not have in the server right now are external CA. So the code is there, it might be working, but we're working on a solution to have external CA before installing the server, that you have a single step to set it up to get all the signing requests to have all together and to start the server installation using external CA completely afterwards. So because the current model to stop processing and writing a file out and asking the user some questions is not working with Ansible. But we are working on this, maybe in some... I don't know. In some time, we will have a solution for that because we need it for several other things too. So you see right now HTTP. CA is done already. So how much time do we have still? Five minutes. Might get something like that. Might. We have a little bit overhead with Ansible with cutting into pieces, but it's really not that much. And the good thing is, for example, with the client, we have been able to add so nice features, for example, the OTP stuff. So it's really worth it. And okay, we could have done this simple version with simply calling the install script. Oh, we are at clients now. So here are the clients. One, two, three. And it's trying to set up... It's importing the variables, making sure the packages are installed afterwards to the discovery. Here, it's done. Here it detects the Python interpreter and sets it to version three for two machines, one to two, because it's a REL 7.4. Now we have the discovery. Oh, it's too quick. So there are lots of skipped things because OTP has been disabled right now here, but you can simply enable it and it will automatically detect it, and so on. And if you have a working KAB5 key tab from a previous installation, it will pick it up automatically. Yeah. We're done. So anybody who is setting up a server and three clients and replica will be added in some weeks, hopefully? As soon as we have been able to sort out why we can kill the server. Okay, so do you have any questions? Yes? Okay. Yeah, I will repeat the question. So why aren't we simply using the standard tools that are available in the distributions? This is right. Simple. Because we need to be able to provide support for several versions, and we already have code in the installer scripts that are handling this, and to add this into Ansible itself might be a solution, but right now, as I said, we are trying to be as compatible as possible. So we're exactly doing the same steps with the same code, and also with different versions. So personally, I do not want to add yet another wrapper around off-config, off-whatever, and so on. As it is done already in the IPaCode. Effectively, it calls to that code. If internally it does it, yes. Internally it's using off-config and so on. But if the role itself would need to do that right now, it might be something that we can address in the future when we're maybe switching to the Ansible installers as a default. But right now, we want to keep it as close as possible together. Can you repeat that, please? I only got it half. Yeah, it's in one repository. They will be pushed into Ansible repository at some point. Yes, that's the plan. Then it will be ready. That's a good answer. The Ansible guys also need to do some homework on their side to support some of the interesting use cases we're raising for them, like the roles inherent. Yeah, at least this is addressed now. Yeah, some of them are addressed, some not. There's also still some work to be done on the Ansible side to make that possible. Time off! Thank you.