 At first, we have the general IPADM password setting. This is used to store the cavers password for the admin principle. And additionally, we have IPADM principle, which is by default admin, so you only need to set it if your admin is not admin. And we have the IPADM password for the directory manager. So the next one, right directly to the server role. So here we have a server inventory file. So for the roles, we are defining the groups here. So IPADS server group is used to deploy the initial master. And we also have variables. So you see in vars, we have the admin password, the M password, the domain, the realm, and an additional setting MK homedir. And this is called IPA client because it's directly going to the IPA client deployment part. So every server is also deploying a client with a reduced set of settings and options. And this is used for that. So the admin principle is not here because I'm using normally admin and are not changing it. I'm not changing. So here we have some options. This is the selections, selection. So we have the IPA server domain and realm. If you need to set the host name manually, so overwriting what is already there, you can set IPA server host name. Then it will change the host name of the machine or the node. This is not done automatically for you. Next setting is important if you already have the packages installed, which I'm doing here in my demo because the network connection is a little bit unstable here. So I already installed all the packages and I'm setting this to no. It's by default true. So it tries not to install any packages. And the next one is also very important for Fedora and CentOS and REL. And by the way, also for new latest DBN versions is set up firewall D. This is also by default yes and is opening all the ports and services that we need in the firewall using firewall D. Then we have two Boolean settings. So the set up are the AD trust to configure AD trust capability, set up KRA and set up DNS. So for KRA and DNS configuration. And you see also I added here IPA client MK home there. And this is only a subset. The whole list of options and parameters that the roles are supporting are documented in the upstream documentation. Everything is there. So yeah, that's for you. So next episode deployment. So this is a playbook that is part of Ansible free API. So it's part of the playbooks folder. It's simply using the IPA server role and our setting is setting state to present and using the inventory file. So in the deployment in the last line you see how I'm normally calling it. So with the inventory you've seen before and in playbooks install server. So if you're using the GitHub repository directly you need to manually change or adapt your Ansible configuration to point to the roles and the modules. This is also in the upstream documentation. So and here we are going directly to replica. Okay, so for replicas it's fairly similar but we have IPA replicas because we have only one initial server. So there's only one. And if you have more than one there there's simply ignored. So only the first one is used. If you have IPA replicas you can deploy several replicas at once using Ansible free API. This is only limited by the number of workers that you're using in Ansible and also by the IPA version that you have on your notes. So for REL7 for example, I would not go far beyond one or two. For REL8 I was able to go beyond four. So at the same time using the same server. And here you see I'm also defining passwords for admin and DM and also domain realm and the MCOD, home dear thing. I'm using this later on my demo. So I added it here too. And here we have the options. Here we have the options for the IPA replica role. So most of them are the same but they are using the different prefix IPA replica simply to be able to diverse between server and replica if you have different settings there. But if you only have the IPA server domain, IPA server realm, they will be used instead. If the IPA replica domain and IPA replica realm are not set. So this is very useful and is used for client deployment that I show later on. And also there is the install packages setting again and also the setup firewall D. For server the firewall configuration is done after the server is deployed. But for replica we needed to do this before the replica is deployed because there is also already the connection check between the replica and the server and the server is trying to connect to the replica and if the firewall isn't open, I'm sorry, it will not work. And additionally, we have the setup AD trust and setup CA. This is something that we do not have in server but in replica and the KRA and DNS and the MK home there again. So this is the replica deployment that we do normally. So it's also part of the playbooks folder. So if you're simply changing the inventory file you can simply use the playbook sizes. If you want to use for example Ansible Vault you need to adapt them because you need to provide the path to the vault and you need to integrate it. This is also mentioned in the upstream documentation but it will be too much for this here. So we are coming directly to client. So and after I've done the slides for server replica and client, I will start a demo already. So in the background for the deployment. So for client we have the same as for replicas so we have more than one. And we have the IPaClient prefix for the variables. Again, domain and realm are used from server if they are set and if the IPaClient settings are not there. And the next one are the options for IPaClient role. So here we have two additional ones that are not part of... So the first one is not simply possible. You need to do it on your own. With the normal command line installers. So IPaClient use OTP is automatically creating an OTP password for you using the controller and the server that you've defined. So a part is done in the controller and a part is done on the server and the password if it's vault or not vault it will never ever be passed to the client. Only the one-time password is transferred to the client. So for one-time use. And if you are creating the one-time password on your own you can use IPaClient OTP. You cannot simply set IPaAdminPassword because it will be handled a little bit different. So it will not have the result. For example, if you are also deploying a replica because you can also use OTP for the client deployment part of a replica. Then we have the MK HomeJer as before and the IPaClient servers. Oh, I forgot to add this to IPaReplica because there's also IPaReplica servers. If you want to ping your machine, your node if it's a client or replica to a specific server you're setting this. But there is a downside. If you do this all the DNS lookup for example in Kerberos will be deactivated. This is IPaDeployment. And the roles are doing exactly the same. And we have one more special one. This is a low repair. So I know from point of ansible and ad-impotency this should be done automatically but sometimes this is not wished. So right now it's still a parameter. Maybe it will default to yes at some point but I'm not sure about that. So what a low repair does is it's trying to analyze the client deployment and try to take errors. So if the key tab is not correct, if there are files missing, so it tries to repair all the things that are needed to have a running client. There is one downside, sure. So if you remove the key tab it cannot do a lot for you because yeah the key tab is something that we need and we cannot recreate it easily. There is no way to do that. So and the next one is install packages again. So to escape package installation. And the last one, yes please. Okay, can you repeat your question? Yeah, yeah, yeah, sure. So the question was why we have hyperclined user OTP and why it's not the default, right? Basically. Okay, so the OTP stuff has some limitations or the automatic generation of OTP. So you need to have a controller that is able to do K in it against the server. So you need to have a K in it. You need to be able to install GSS API if you want to use the key tab. So this is a limitation. This is why hyperclined OTP has been added and you cannot use them together. There will be an error. So hyperclined OTP is used with the output of hyperhost. In hyperhost you can say, okay, create a random password for me. I have an example for this later on. Okay, so and for the client deployment part we have as for all the others, install client which is part of the playbooks folder and for deployment you simply call it in the same way as the others. And the good thing is, if we come to the next one to cluster, so we have an example of a cluster environment here. So you see we have the IPa server group, we have the IPa replicas group, we have the IPa clients group. And we define a IPa cluster group without any content besides children and wars. And we are simply attaching all the other groups to IPa cluster and define variables for IPa cluster. So we have the admin password, the dm password, the server domain, server realm and client mkhomedir. So all this is automatically passed to the IPa server, IPa replica and IPa client roles. This is why it's important to have IPa server underscore fallbacks for all the roles for this to simplify the cluster inventory. Because in the cluster you will most likely not change the domain of the realm. It's not supported. And for the deployment, it starts on the left side and continues on the right. This is also in the playbooks folder, this is installed cluster. So you see it first it deploys the server, then deploys the replicas and then finally deploys the clients. And here it's using the cluster inventory that you've seen before. So it should be fairly simple to combine all the things together. Nice is that you can use the cluster inventory also to install only the servers or the replicas or the clients. So you can even say install server, install replica or install client and we'll only do this step. So I think I will start the demo in the background just a second, which we know is this. I think there's one. So we simply do, here I'm using slightly different names. I can show you. Oh, I think it's too small, isn't it? Okay, let's make it huge. So here, if you have a look at this, this is my inventory file I'm using. I'm using sentos 81. This is why I'm using co81 local because I have domains for 81, 80, rel, Fedora and so on. So I'm using slightly different domain and realm names. But you see aside from that and also different passwords, it's nearly the same as the other one. The only thing that I've, thank you. Additionally is the install packages stuff. So I set this to no because of the network issues that we have here and I'm installing locally here. So what I'm doing right now is I'm simply installing the server part. So it's using the server machine, doing the tests, creating the master password. So I will continue with the slides at the same time and we can jump back to this. So the next point is the management modules. So for rel 81, we had already some management modules. So for host, for user, for topology but they have been limited. And with H2, we have by far more in there. So more modules and the modules that we have are providing all features and all parameters that the IPA commands are providing. Also, we have the GSS API support in the same way as Ansible upstream modules for IDM. But there is one difference between the upstream modules. So the upstream modules are using the JSON API and we are directly using the API, the IPA API. So the parameters for authentication are different and they are in line with the roles. So we have exactly the same names here but all the other parameters for the users, for the hosts it's the same as with Ansible upstream modules but we also support the internal names. So if you know the internal names or the command line names, they are also valid. And there is one big change that we have additionally to the Ansible upstream modules. This is support of member actions. So with the Ansible upstream modules you always need to recreate your group if you want to add a user. So you need to get all users that are part of the group add your user to the list and write it back because there is no add the user. There is only here this is the set of users that is part of this group. And with the modules that we have we can add, we can ensure that a user is in a group or we can ensure that the user is not in a group. Additionally we have also other actions. So I will only provide information about the default stuff so because we do not have a lot of time for the others. So the IPa host module. Here's a nice example that you should make that you might know also from Ansible upstream. It's slightly adapted. So there is the IPa admin password setting here. If you can use ticket forwarding or if you can use vault it will not be here. This is just a simple example. You can enhance it at any time. And you see we have all the stuff that is also part of upstream. But additionally we have, if you look here, a additional setting. This is the host setting where you can place a dict of host. I'm sorry we have the same for users also. Aside from that we use the names from Ansible upstream. So random certificate and so on or random password and user certificate. User certificate is for example an internal name. So but we support them all which is really nice. And here you see also the additional setting action. This is used to define if you want to act on the host or if you want to change member. So for example to add a certificate to existing host entry, we do not need to create the whole thing again. We simply add the certificate with the action member. And we can do this for certificates, for managed host, for principles and all the create key tab and retrieve key tab settings. There are lots of. And this is way more than I can show in here. So please have a look at upstream for that. And the last one is also known from the Ansible upstream modules. This is update password. So there is one thing. If you define a password in your playbook or inventory file for user, oh, thank you, or for a host, you need to make, you might not want to set it every single time again. We cannot check if the password is still the same because we get something hashed back. So yeah, we will write it every time. So the ad-importancy will fade here. So it will say, yeah, we're changing all the time, but yeah, we don't need to. So this setting for, which you can set on create or always, always is the default by the way. Also upstream. So, and here we have the OTP, the manual OTP generation that we have been for the question before. So we're using the IPA host module. This is part of Ansible free APA, and you see it's Ansible free APA 017 plus, so 8.2 and up or Fedora or Galaxy. And we register a result. And the modules, part of Ansible upstream are only returning something if you create, if you ask for a random password. This is simply because if we add, let's say 1,000 users, what you get in return will be really huge. So only for this, only for random passwords, we are returning the random passwords. And you see in here, we are registering IPA host result and using IPA host result host random password. And there is an example also upstream for several random passwords. So if you have several hosts, you will get several random passwords back with the random setting. So for every single host, you will get a random password. So and here we are using IPA client OTP. We created the random password beforehand. We're using IPA client OTP simply and it will be doing the right thing in the background for you. And oh, there is something missing here, topology. So let's go to topology management module. And this IPA topology segment. So if you deployed several replicas, you need to also add topology segments for that. And this module is exactly for this case. And it's already part of 8.1. It was not changed for 8.2 because it was already supporting everything that topology segment could do. There is one thing that we are, that the module is doing better than the normal command line tool. The normal command line tool is always asking for a name. In here, the name is automatically generated from the left and the right node. So it first tries to find the nodes and then creates a name accordingly. If it does not try, if it will not be able to find the nodes, it will fail, but that's expected. And for topology, or maybe I should start the next part. Let's have a look. So you see here, our server deployment was doing all the steps. So we have been setting up NTPDS, KRB, Custodia, CAE, OTPD, KRAE, DNS. So this is the minimal DNS setup because I was not enabling setup DNS. So this is only the bare minimum that it does in this step. It is just skipped because we have not enabled it. So it's providing all the information about the steps that it's doing. And here you see it's doing the setup client deployment part. We're setting the on master setting, which should not be used outside of this, but we need to have this setting otherwise we cannot do this client deployment part with the same role. So we are using iPoClient role also for server and replica deployments internally. And you see finally the result is good. So it took five minutes 59 on this notebook. I've limited memory by the way, but it's still working. So we can go to the next one. So I go back to the slides. So, and this is the wrong order. Perfect. So iPod apology segment has some options as the upstream stuff also. So we have the suffix, the name, direction and state. For state we have the additional settings enabled, disabled. This is not the same as present and absent. Because we need to also have the same functionality as upstream with the IPA commands. And there's also checked or initialized. So you can use the same snippet here also for to initialize or to enable and disable. And for example, if you have more than one topology segment that you want to add, you can do something like this here. So we are defining a dict that we are walking in the next step. The topology segment module is not supporting to do this internally so far. But we've done this for server, we've done this for host and we've done this for user. So I think we can also add this for topology segment because it's a normal use case to have more than one. And you see, we can also, here in the third line, we cannot only add a domain or a CA to topology segment, we can add them at the same time or remove them at the same time. Simply to have less to write, we're going directly to the IPA user module. What time is it? Here you see a example for user presence. So we're using user pinky. With the first name pinky and last name Akmeh, with a password that is defined. So it will be usable immediately. And with the update password. So it will only be set on creation time. So if you run this repeatedly, there will be no change. And this is something that has been added for each two. We can define users as a dict. So not only one user can be added at the time, but several. And it's using exactly the same settings as the other one. So you can provide everything in here that you can. So you can provide everything in here that we have also in the other one. So all settings. And additionally, we have something really nice with that. So we are defining a JSON file for all our users. So we have a users dictionary in there with the name first, last, and so on. And on the right side, you see, we are simply including it and passing it through the module. And it will do the right thing for you. It will make sure that the users exist. You can also remove them, but then you only should have the name in there. But you can run it repeatedly and it will not do anything anymore. It will say, yeah, all users are there, we're fine. So no changes. And we can also use the random password stuff for users. It's done in the same way as for host, I'm sorry. So it's also returning structures in the same way, but it's not adding host, it's adding user. So, and if you have more than one, it's in the upstream documentation. I'm sorry, it's so long. So the print result. And here we have the options or a selection of that. And you see also here we have the special action setting. So we can add principles, managers, certificates, and certain data separately to a user or we can ensure that it's there, we can ensure that it's not there. This is also, again, a big advantage over the upstream module in Ansible. Aside from that, all settings that you have for users and IPA user command are there. We have some additionally, like for example, the update password stuff again, but I think I explained it already. So it's the same for user. And we have the IPA group module. Oh, she is getting loud, good. So for group presence, here we also have advantage in the same way as for user and group, for user and host. But aside from that, we are supporting everything again from Ansible upstream, from, I'm sorry, IPA upstream command. So we can also use the action. So you see an example here, we have action member. So the user brain will be added to the existing subs group. And if you repeat it, there will be no change because it's also able to detect the member, it's already member, so we don't need to do anything. And these are the options for the IPA group module, a selection of that. So the normal staff name or CN, so you can also use CN, the internal name for that. And we have the user group, service and so on. So, but service has been added for 47 plus. It's only supported with free IPA 47 plus, I'm sorry. So if you have a version that is older, so something like rel75, it will fail on this one, you will get an error message. It's not the supported thing you can do here. I will look at the deployment, just a second. So here you can see we deployed two replicas. So IPA replica one, CO81 local and also the number two. And it's doing nearly the same steps as the initial master, but still the deployment steps in the command line tools are different. So it's doing exactly the same. It's using internal code for that and everything is here. And here's here already again. The first stuff, it does some adaption in the firewall. Does the test, is everything fine for our deployment? Then it starts the client deployment part. This is a full client. Also the command line tool is doing exactly the same internally. So it's doing a client install first, if it's not there. And we have also the same functionality. So if the client has already deployed, it will skip this step. And you will see only skipped in here. So after the client is done, here we have always the name of the role inside so that you see where it stopped and where the other one started again. So you see the firewall configuration. We do not need to do this for the client. The client does not need any firewall change, only replica and server. It does the preparation, add the servers, do all the configured things and finally we are done. So do you have any questions so far by the way? Nope, perfect. So let's go to the next one. So the client part is faster. Less to do. Thank you. So we have also the iPassudo module. And there is sudo command and sudo command group also. I limited just here to iPassudo rule because we do not have a lot of time altogether. So here you can see you can, with 8.2, this is not part of 8.1. And sadly right now there is an issue but there is a pull request already to fix this. So the command is simply ignored and the command is using the wrong name. So I'm still using the wrong name here but yeah it will be fixed soon as the SPR made it in. But it will be fixed for 8.2. And here you see the options. This is also wrong. So they have been renamed. Yep, they will be renamed for the PR but it's not there. So I'm sorry. And we also have the actions. So you can add users, groups, commands, command groups and all this to an existing role and you can remove it also or ensure the presence and absence. So this also again, a big enhancement to the upstream modules in Ansible for IDM. And we're going right directly to HPEG rule. So for HPEG rule we also have HPEG rule, we have HPEG command, we have HPEG command group and so on. I'm just limiting here to one. So HPEG servers, I'm sorry, not command group. So here you see we're using, we're adding a HPEG servers, SSHD that we created beforehand to a new HPEG rule that we call login here and here. Now the password is here with a big P, perfect. And we have lots of additional playbooks and also tests for this internally. So in the playbooks folder you will find playbooks to set HPEG rules to ensure the presence and absence and for HPEG services for everything you will find example playbooks there that you might use directly if you don't need to change them. So if you have all your settings in the inventory, perfect. Then you can simply directly use the playbooks that we have there. And here we have the HPEG rule options. So the normal stuff, but please remember the names will change, it's the current state. Okay, I'm going directly to future. So the plans, the plans for Ansible VAPA. So what we are missing right now are the tools and roles for tools like IPA-CA install, IPA-DNS install, etc. They will be added soon or started to work soon. We will also need them, for example, to be able to repair or enhance an existing server replica. So the server and replica role right now are not completely unimportant and they will never be able to do so. To be, because we cannot uninstall or unable something like for example, DNS, CA and so on. It's simply not possible. It's so deep in the server we cannot get rid of it anymore. So the only way in this case is to redeploy. A new machine with the missing parts. So what we will do is if you add something to your inventory file. So, oh, I have not set up DNS before. I'm simply adding set up DNS to the inventory file for the server and start the server deployment again. It will activate the DNS service for you. So it will in fact use the IPA-DNS install role that will be created. And for this, we need IPA-HALF check because right now we are not, it's not simply possible to see what is configured. So we will use IPA-HALF check for this. So IPA-HALF check will be integrated or it will be used in the roles. So in server and replica for client we do not really need it, but maybe we will see. And there will be also a IPA-HALF check role as far as I know at some point. And we plan to have modules for all other IPA commands, but as you know, there are really a lot of IPA commands so it might take some time. And additionally, a role for high level topology management. So to find out, okay, we have a topology here. We are analyzing it with IPA-HALF check. Oh, where do we need to advance this? Where do we need to add a, thank you, topology segment and so on. We will see, but it will also take some time to get there. So I think we are going back to the demo and yeah, the clients have been deployed also, no failures. And you see also here, decline deployment parts. So importing variables, configuring, testing, NTP. The OTP is skipped here because I was providing the password directly and not asking to generate a OTP. And you see some things are skipped because they are in there to make life easier. For example, to use a key tab also. And so it was joining IPA and so on. So we should be able to do step four. So we are adding a topology segment. They can show you afterwards after it's done. So we have two replicas created already for the server before. And we are adding a topology segment for domain, for hyper replica one to hyper replica two. And we can simply redo and you will see it will not say changed anymore. So it says, okay, so no change happened. It's already there. And since we are running out of time, I'll do this. This will create 500 users using IPA host with a JSON file, I can show you. Yeah, this will take a minute. So I think we can start with the questions in between and have a look at this later on. So do you have questions? Yeah, yeah, sure. Oh, the question was if we are able to use the normal Ansible IPA commands, yes we can do with simple command. So, but you will lose a little bit of functionality with this, so yeah, next question. You said that you could assume that it worked the first time, is it rent the same install, the replica install for the second time? So the question was if the roles are item-hardened right now, as we are not able to remove something, are they able to detect what we have already? Well, I'm assuming you rent the same exact script the second time, maybe you get up and enter by mistake. Is it going to change anything or is it just going to say okay? Okay, the first step in the deployment is to analyze. Okay, we have already a server. This is also part of the normal command line tools. They're detecting, oh, we have a server already and please undeploy the server or start a new deployment if you want to redeploy. The roles will detect, okay, we have already the deployment of the server or the replica and skipping all the remaining stuff. They, if we have the IPA health check integration, we are able to see what is there, what we can do, what we need to do. But we need this first. Right now, it's simply skipping the deployment process. Any more questions? Oh, yeah. Paan, can you repeat that? I'm still in perspective. When we are running, if something's broken, should we focus on that? Should we follow on the body logs for my case? So the question is, if we need to concentrate on Ansible Free APA or Free APA if there is something broken, that really depends on the use case, I would say. So if the module is failing because there is an issue in the module, we need to have a look at Ansible Free APA. If there is an issue in Free APA itself, the Ansible module cannot do anything about this. We need to have a look at the logs and Free APA internally. Okay, but I have in my mind, for example, if you run the command feedback, you can see that it's completely... Yes, we can Ansible force to do more debugging, but there is a limitation. We cannot print it out easily. So everything that is printed on standard out will be redirected. So only a log file is possible. Yeah, every output of a module to standard out will be interpreted as part of JSON output. So it will crash. So we have five minutes. Any more questions? Thank you. Oh, yeah. Oh, I'm sorry. So the users, you see, it's done. No error, it didn't fail. And so we can also log into the machine. Wait, this one should be there. This is part of the next... Wait, we can do this also. I was not setting passwords for the users, so I cannot log in. Here's those users, but here there is a password. This is the group test. And so we should be able to log into the client with the password that is provided there. But I think I forgot the MKOder here, maybe. But I can show you the... This here, so it's simply creating a user with a password test. Yeah, it will fail. Not fail, it will complain that the user home directory is not there. I forgot the MKOder for deployment. Yeah, yeah, here you see the directory is not there, but we have been able to log in. So, good example.