 Okay. Thank you. So, welcome everybody. For the sake of those who are joining for the first time today, my name is Tito, and I'm leading cyber administrators attached to the University of Oslo. I'm based in Nairobi. So, we want to continue the topic that we heard last week that is LXD. And LXD is an engine. It's an engine that runs containers, you know. It's just another, you know, we have Docker. Docker is very popular. And with Docker, you run Docker containers on top. So, LXD is an engine that runs Linux containers or rather LXD because LXD stands for Linux containers. Docker containers are very slim. They do what you want them to do. They don't have much packages in them, while LXD containers have libraries. It emulates a whole complete operating system. So, last week we talked about how you could manage LXD containers with LXD client. Yeah, it's a tool that interacts with LXD engine with over the API. LXD engine exposes an API. It's exposing over the Unix socket, or you can expose that also over the network. But then when you run LXD commands, normally from within the host, you are interacting with LXD engine over the API, you know, Unix socket clients. Yeah. So, and that socket is sitting. Are you all seeing my screen? Yes, we can see your screen. Okay. It's somewhere in VAR, SNAP, I don't know, LXD. Let's check what is there. Somewhere here. And it's when you run a command like LXD list, it's just using that Unix socket API to list your containers and you can manage all your containers here. You can do pretty much everything. The surrounding LXD system, you can create containers, stop containers, restart containers, and you can run, you can do things within those containers. And that was demonstrated last week. However, you could expose that API over the network. Let me just exit from this server and to LXD remote list. And you see I have around six remotes. There's one for images. It's hosting images remotely. And there is these local units. This is now the Unix socket that I was talking about. You can use this API to interact with LXD containers locally. And then there is these, which is connecting to an LXD server running somewhere else. I have two remotes here that runs containers. One is main and another one is Octiplex. These other two are pretty much images repositories. So I could say LXD list and nominate the remotes that I want to say this one. And it will list containers that are running from this remote. So if I change that to the first one that we had here, this one, it will list different containers that are running on these other remotes. Notice that they are not the same. They are containers running on different systems, different server systems. So here, notice that I'm connecting not locally but over the network. So my local clients here is in this MacBook and I'm just running LXD clients here. It doesn't have, there's no LXD engine here. So those are the two ways that you can interact with LXD exposed API. So today we want to talk about Ansible. It's offering a way also that you can manage LXD clients. And our DHI is two server tools. We have two versions of the tools. We have tools that were running bash scripts and the tools that we are using Ansible to, you know, to manage our deployment. So the bash scripts really, if you get into the details is that it's using LXD command line within the scripts. You can, you know, if you go through the scripts, you notice that whenever something is whenever we wanted to do something within the container, we were connecting with LXD and then do things inside the container and then, you know, finish what we were doing. Yeah, that means it's using LXD clients, you know, under the hood. But with Ansible, we are not using LXD clients. How are we connecting with Ansible? That is something that we want to talk about also today. So I'm going to take you through our tools. And these are our tools. With these tools, you can do deploy DHI's tool and its components, you know, application stack, you know, it has one database and then the instance itself, and then other optional items like proxy and monitoring. You can pretty much deploy that with Ansible. So Ansible itself has building blocks. It has items, things that build, makes Ansible complete. And one of those things is modules. I'm going to just edit one of the files that we have here. It has a list of tasks like this one. It has a list of tasks. And on the very top is just a task, the name of your task. And then there is that a few directives here, like become directive. You instructing Ansible that within this task, the task is ending down here. You want to become, you want to innovate rights. That is the purpose of this line here. And that also you could define variables within that task. And then this one here is the module. This one here is one of the modules that I wanted to talk about. It's a building block of Ansible. And what are the modules? The modules are really called written and they are performing particular tasks. Like this module here, its main purpose is just to create container. It's LXP container. It's used to create container. And it has so many things that you're just creating container, but then it has attributes that you want your created container to have. If you follow through this one task here is that you could even state devices that you want for the created container. And this is just one of them. You can also say add other device that you want your created container to have. And you can specify where you want to get your images plus other parameters, as you can see here. So this is just one of the modules. And if we check another task here, is that it has so many tasks. You can see it's a list of, it's a YAML syntax, arranging tasks into lists. You know, this is one of the tasks and then this is another one. And the list goes down, down, down, down, down until I guess to the very end. These all are tasks that are just arranged in particle order. I see your hand raised. This question that has been thinking about for a long time. So I know Ansible, it was developed by Red Hat, right? So now do you think any time maybe in the future these guys from Red Hat might want to push a license on Ansible? What will happen with this installation in the future? Will it remain open source for a long time or for eternity? One is that Ansible is open source and major players within Ansible world is Red Hat. They're starting the Ansible thing. But then if you go to the community and even list the modules that are currently available out there, then you notice that core modules, the core modules of Ansible are nothing compared to the community modules. So it's open source. It's something that is community oriented. If I open another tab here and say Ansible doc and then I want to list type modules. See, sorry, type modules. Ansible doc and then type module or you can just Ansible doc and then list because it defaults to modules. This will give us so many modules. And the way they are organized is that they have fully qualified module name. And they are, you see the first one that we see here is just Amazon AWS EC2 modules and there are so many. There are so many, you know, these are open source and they are not even developed by Red Hat themselves. These are developed by Amazon AWS and after that we have Ansible built in here, you see. These are now the ones that comes with them with a default installed for Ansible. These are the building modules. And after that, we have other modules that are developed by different players. Like AWS here, AWS is, there's another way also you can manage Ansible using Ansible Tower. You all know Ansible Tower. It's web interface that you can interact and manage your Ansible host from it. You know, you can log in to the Ansible Tower and then you can just pretty much do things in an interactive manner. You don't use command line. Right now, our tools are using Ansible command line but Ansible Tower is a tool that is developed by Red Hat and it's licensed. You cannot, it's under the license but then AWS is the open source version of it. You see here and it has modules also surrounding the same. Yeah, so I think Ansible, major players that do develop Ansible are Red Hat and they, it is something that it's outsourced, it's an open source. Anybody that wants to develop their staff on top of Ansible can do that. And that is why you are able to see all these modules that we have right now here and the list goes on and on. Like in our tools, the modules that we use are community general modules. We just try and see if I can, community general. Yeah, these are the modules that we are leveraging, that we are using. And these modules are developed by community but they're not even hooked to Red Hat themselves. They just give you the co-utilities but then everything else that you want to do, you can do yourself. Okay, I think that's enough. At least we should say that we are safe then. Can you confirm that we are okay for the next generation using Ansible? The good thing is right now Ansible is open source too. It's not proprietary. So when we were at that, at your question, we were able to see modules that are available for us because we were talking about modules. So when we get back to this, you see Ansible's built-in set back, set fact, it's a built-in module meaning it comes with the initial install of Ansible. And one of the modules that I can use to demonstrate what modules mean, what we talk about when we talk about module, what we mean is the ACT module. Normally, when you're setting up something, say on a Linux system or on a Red Hat system, you manage your packages pretty much with ACT, right? And you just get into that instance and then you issue commands, say sudo apt update just to make sure that your packages are updated and then sudo apt upgrade, making sure that your updated packages are now, you know, you get the latest versions, and then you issue sudo apt update and then your package name, whatever you want to install. It can be, say, Tomcat 9 or something that you are dealing with. And that pulls the package from the apt repository and it installs into your system. So this task here that I've just highlighted is using the same apt module. And you just give the name of the app packages that you want to install. And this is a list. You can just have it this way or you could even make it nicer by saying that the modules that I want to install are name, you just give this text a list, you know, a list of items that you want to to install. And then you put your list here like now and zip. And then another one is Tomcat 9. And then another one is Tomcat 9. You know, something like this. This, it does the same thing. It does the same thing. You can, mine is just done within single line, but you can put it this way. It also work. So it will use apt module and then the name of the packages that you want to install. And then it will just iterate through the list and install all those packages that you want. But then this is just another version that you could make this look like. Yeah, so this is another module here. It's called file module. And the reason why you see them very simple that they just portrait in a very simple way is that they're Ansible built-in modules. Otherwise, another way you can write this is like this. Ansible built-in apt. This is the fully qualified collection name. You just mean you just put in writing it in a way that it has fully qualified collection name. Otherwise, you could just write it this way and it will work because it is a built-in module. This way you can also make this look like this Ansible built-in file and it will work. So for the built-in modules like file here, apt here and even start here, you don't have to specify fully qualified collection name. But then there are other modules that are not built-in. For instance, the one that we checked in a few seconds, this one, is not a built-in module. That's why you need to really define the fully qualified collection name. It's from community collection and community general LXD container. So that is one of the built-in blocks of Ansible modules. And another one is connection. One of the reasons why we wanted to have tools that's using Ansible is because of the connection. Our batch clips that we had before can deploy the HHS-2 instance. It's 15 hours. But from within the same host, what if you are in an environment where you have a database running on its own dedicated server or a virtual machine, you have proxy sitting somewhere else, you have application server sitting somewhere else and also monitoring server sitting somewhere else. And then you are given a central server in Ansible, we call it controller. And you're told that we want you to deploy the HHS-2 and you have these components over the network. You will not be able to use your, I mean our batch clips in that scenario. And that is where Ansible comes in. It supports connection, it supports different connections. You know, one is SSH. That if you are on an environment like that, you can connect to these components with SSH and then do things on those instances, but over SSH. Or you are sitting on a server, you want to deploy the HHS-2 application stack. And you want to deploy your HHS-2 from just into that host. You don't even want to deploy the HHS-2 within content. You just want to deploy the HHS-2 into that host, you know, boombox. And in that scenario, you use local connection. That means wherever connections that you are making it to the local host, you don't connect to something that is sitting somewhere. Or you could even connect to LXD instance. You could even connect to the LXD engine with Ansible. That is what we are advocating, that whenever you are setting up your LXD in a host, you use LXD containers. That is the third connection. And also, Docker, it supports a connection plugin that enables you to interact with Docker instances so that you can spawn any Docker container name that you want and then you do things within that container. And we could even list supported connection plugins with Ansible, Ansible doc, and then list. We are listing, we just want to list, and then of type connection. And this is a list of connection plugins that are supported. The very first one is local connection plugin. See, and you see as I said here. And I know Docker is somewhere here. And there's also HTTP API. You know, you can connect to an HTTP API endpoint and do stuff with Ansible. It's something that I'm currently even working on with Zabix because I want to enable users support, you know, my tools, I want my tools to support Docker monitoring, Zabix monitoring. Right now we are using Union and we want to explore how we can incorporate Zabix into our tools. And here is LXD. This is the one that is enabling us interact with LXD hosts. You see LXC here. It's not even the only way you could interact with LXD hosts. You can also use LXC if you want. And if you have Kubernetes, you can use Ctl also, you know. Docker, you know, you can manage Podman containers. What is Kubernetes? Sorry. You have Podman connection plugin. And all these other connection plugins are supported. So right now our tools are supporting three connection plugins that is LXD, local and SSH. If we just see what we have with LXD.yaml tasks, see here that we are instructing this particular task that connection plugin that we want to use is local. Because when you are creating a container, you are just creating it within the local host that you are sitting on. That is why you are not connecting anywhere. You are just sitting on that host and you are creating a container. But other things that runs, you know, to do things within containers, like updates, and pretty much things that you do. Even our task here is using LXD plugin. It's using LXD connection to interact with those containers. Yeah. That is another thing that you could have a discussion around Ansible. And there's a variable that we are enabling users to decide which connection plugin they want to use. It's not something I'd call it. You could change within inventory host. There's a variable here where you can define the type of connection that you want to use. It's called LXD connection here and we are here, as you can see. So this connection plugin, this is the default. We want to support LXD by default. We are assuming that you are setting up your own infrastructure within a single host and that host will be having containers. Otherwise, you could change these to SSH. And in future, we want to include Docker and even other things that comes along the way. Something else that we want to talk about that comes when you are talking about Ansible is inventory. What is inventory? Inventory is a list of servers. With Ansible, you can manage a long list of servers. And those servers are defined within an inventory file. Those list of servers are defined within the inventory file. So this is our inventory here, as you can see. And at the very top here, up to this line, is a list of servers. And they are grouped. We have web servers put under that. And then we have database servers and then we have instances. These are just two application instances. We create containers running particular instance and then monitoring. For monitoring, we are using union right now, but in future we want to add also subjects. It's something that I'm working on right now. Now these files are just variables, you know. You could define your variables within the inventory file and there are so many other places that you could define your variables in Ansible. And let me just get to this directory. Yeah. You see, these are all places you could define your variables in. And we, we, in our standard install, we do group Ansible variables within one location that is an inventory file. But there are so many other places like more than 23 other places that you could define your variables. Okay. We want to have them done on a single file here. Inventory host file. We have it open here. Yeah. And then there are filters. Filters is just an Ansible way that enables you to manipulate data when you are running your playbook. And for instance here, you have M64, you have variables that are false, like this one created DB, it's yes, it's either yes or no, you know. And you want these variables to always be a Boolean. You want it to be either true or false, always. And for you to do that, you can use a Boolean filter. Let me just see where I've used that. And here, here we are. You see here, we have this variable, it's create database. But then we want to ensure that this variable that we have here is always a true or false. You know, we want to make sure that it's a Boolean all the time. So this is a filter. It enables you to manipulate your data. This is also being used with the two templates. We could spend a whole hour talking about Ansible filters. And let's see if we can list even things Ansible doc. I don't know if you have type filters. We have type filters Ansible doc of type filters. And then you can just list. See, we have so many filters. Filters helps you manipulate data as you are running your playbooks. And then finally, there are other things like test, you know, that you could use with Ansible. We can talk about that in future. But right now, I want to just give you a brief demonstration on how you could create LXD containers with Ansible. And then after creating those containers, you can do things within those containers. It is what we are doing with Ansible scripts. We are creating containers, and then we do things inside those containers, which is installing Postgres. When we are dealing with Postgres container, installing Tomcat 9 when we are dealing with Tomcat container, right? Any question up to that point? Hello Tito, can you hear me? Yes. Okay, this is actually, thank you for taking us through. But I have been having a hard time. Connect the files. I think that's one of the most that I'm getting hard. Like, before when we use the LXD, we are being shown that this file connects here and when it may be. This file is going to that file. It's going to reveal a certain DC command and the story. So you can precisely recall that after when one line is going to go to another line, maybe it is going to look for another file. So I was also trying hard to know in Ansible. Is it also working in that way? Because there have been some parties and probably we might like to look to those files and see what content that they are there. Yes. Yeah, that is what happens with Ansible. When you, I'm actually sitting on my project directory here, as you can see. And within this project directory, there is Ansible configuration file here, Ansible CFG. Within this file, you can instruct Ansible where you have your playbooks. You can instruct Ansible where you have your roles. I've not even talked about roles, you know, and the main playbook that we run here is the HS2.yaml. It's just few contents of the HS2.yaml. This is the playbook that you run and it deploys the HS2 application stack for you. And as you can see, it is grouped into roles. You see there is a role that deals with Postgres and then there is a role that deals with the HS2. And then the last two are proxy and monitoring. This last two roles is going to set up proxy for you. It's not mandatory, it's optional. If you have a role, maybe you have your proxy configurations managed somewhere else and you just want to run your application server here. Then you don't have to, you don't have to run this kind of role. And then there is also monitoring. Maybe you have your already established monitoring infrastructure in your environment. And you just want to do that manually. Then you don't need to include this role. This is just a way of grouping tasks that are related to one another. Like here, we have Postgres role. These are tasks that are related in a way that, you know, it surrounds setting up Postgres, connecting to that Postgres instance, either with NXD or as I said, and installing Postgres from, you know, maybe you can just even check what is really happening within this Postgres instance. What is Postgres role doing? And these roles are within roles directory, you know, it is the default path that you could potentially put down to your roles. And this content here, we have this. So I'm told by default from the project directory knows that I am to look for the roles from within this directory. And then whatever you have in your main playbook, like this one, just run in this order, like you, the first things that rounds are surrounding Postgres role. When that is completed, it gets to DHS2 role, you know, and to proxy and finally to monitor it. This order is not to be, you know, you cannot today decide that you want to have these on top like here. Because your DHS2 role depends on having Postgres container setup. And then you have to start that your DHS2 setup not to, you know, create, sorry, not to use this database here. You want to use some database running elsewhere. But then if you're going to be using a database defined here, then it means your Postgres role needs to come fast. Because that way it's going to connect to Postgres, your Ansible is going to connect to your Postgres instance, create a database. And then if you create a database variable is true, then it will create a database there and then create a database role and then that role is going to have user name and password. And once that is set up, even the plugins that we normally support, you know, in our standard DHS2 installation, it will create all those. And then after that, it goes to creating your DHS2. And at that moment, the database is already set up, it's just waiting for connections. And then sadly is proxy. Once you have your DHS2 setup correctly, everything works well and Postgres is set up and it works well. You can now move on to proxy because proxy at the end of the day is connecting to your instances. Your instances are connecting to Postgres. So it follows the dependency. Like your DHS2 role is depending on Postgres. So Postgres needs to come fast. And then DHS2 next and then proxy, you know, and finally monitoring, because monitoring is going to be hooking to proxy instances, it's going to be connecting to DHS2. You want to manage, you want to monitor all these instances. So that's why it comes last. Otherwise, if this one comes fast and you don't have your containers that runs Postgres DHS2 and proxy, you know, it will fail because it wants to connect to those instances. So that's why it comes last on this list. And then we get to one of the roles, say P, Postgres, Pim, Roles, Postgres, Task, and then Main. This is the Main. Main is actually the, it's the find that Ansible files within the role. It doesn't see other files. It sees the Main. And then within the Main, you call other files now. You call other files within the Main. And then it follows this order. Okay. It follows this order that you define that it will, it will include tasks specific to the connection that you used. And then after that, it's these are the couple of tasks you see Postgres installed. And the connection that you're using, there are things that needs to happen. That is Postgres SQL installation. Even if you're using connection, as I said, or connection LXT, you need to install Ansible, sorry, you need to install Postgres there. You need to sort of update and then install those packages and run tasks within that instant irrespective of whether it's a container or an integrated host. These are, these are the common tasks. And then the first tasks here are very specific to the type of connection that you're using. This is the, this is a variable. You know, we can talk about variables and the way you can call variables in another call because we are calling Ansible connection variable here. It's a way that we are including, including tasks dynamically. Because if you go to this directory here that we talking about, I just did it right now here is just get into that directory and list content. We have LXD.yamon and then you have this asset.yamon. So if your Ansible connection is as I said, then this playbook is going to be included. You see, and it has things. Sorry. I said there's a set instead of LXD. If your Ansible connection is LXD, this playbook is going to be called. And these are the things that are specific to, they are very specific to the LXD connection that if your connection is LXD then you need to create container. This is why this task here, LXD container create and then after that it does some other tasks within that container. Otherwise, if your Ansible connection is as such, then this, this is going to be called in that order. And these are the things that I want to do with the remote host that I'm connecting with as I said, see notice that I want to enable firewall, but before that I enable SSHB port 22. This is the default. Otherwise, it needs to check SSHB for variable. Otherwise, if that is not defined, then it's using the default which is 22. So these tasks are executed in the order that your playbook is actually calling them. And there is dependencies. I don't know if that answers your question. Yes, yes, a little bit. I think I'll be having, I need to take my time to go through each and every other. Because I think the most important we also have seen it, we need to know the order which is executed the test and which needs to be executed last. That's the most important. So, yeah, let's, because I see time is moving very fast. Let's just stop through the, the demonstration real quick so that things that we're doing here would make sense. I'm going to SSHB to my local host here, local server running here. And then I have some few playbooks here. I'm going to delete this test container. Let's see, remove test. And then we're going to spin it up with Ansible. I'm going to use, we have two playbooks here. One is create container. See this. And on very top of it, we have var prompt. It's going to prompt us to supply the container name. And then it's going to prompt us to supply the containers IP address, you know, whatever that we want. But then notice that within this var prompt, they are defaults. If you don't do anything, you just press enter, then it's going to default to DHS2. It's going to default to default container name DHS2. And if you don't do anything also, it's going to default to the IP address 1.30. This is another way of defining your variables. This is a var prompt. It's prompting user to supply variables during the play runtime. And then we have var. These are variables that you want to statically, you know, you want to force them to, you're defining them statically here. That Ansible connection is going to be local. And then your network is this, you know, just for demonstration purpose. Otherwise, I have set up a network prior to this call, you know, and Ansible, I have initiated my LXD environment, and it's using this network, you know. And then notice that even within this, I am doing some, I'm adding some other DHS2 functions that gives me a gateway out of the LXD network, you know. And things like name here is taking a variables that we just defined here. We said this is container name. It's prompting us to supply container name. And this is where it starts being used within the same playbook. And also IP address. This is a prompt that we got here. IP address, and it's going to use it down here. Yeah. So if we run this Ansible playbook create container. You see it's prompting me to give container name. I can say server admin. If I don't supply name here, it should default to DHS2. And then it asks me for the IP address. Notice that it defaults to the 30, but then you can put something else say 80. And then it will create my container based on these details that I supplied here. So it's creating container now. So we are not using LXC here. LXC command like tune, but we're using Ansible. And you see now container is created. And if I do LXC list, we see server admin container is created. And it has the address that we just supplied here. And this is really what's happening within my Ansible scripts. I'm creating containers with with with with with this module. This module here it's called Ansible Community General LXT. This is the module that is helping you to create container. And you are delegating to local host and these are much more things that you can do Ansible and one of them is delegated to that you want this task to run within my local local computer. I'm not connecting anywhere to create container. I'm just connecting to myself to create this this container. Okay. So container is created now server admin container is created, but then in my in our scripts we want to do things within that container we want to install Tomcat 9. We want to install Postgres for instance we want to install a new name and so many other things we want to run firewall you know. Yeah, so this is another another role that another task that I have here in playbook that I have installed packages this one here. So we have this it's going to install Tomcat 9 for instance for demonstration Tomcat 9 and notice that connection that we are having is LXT now it's not just local it's LXT. So within this very specific task, we are using LXT. You can argue also that up here we have local connection, but that is defined, you know, the way Ansible works is that variables that are defined within a task are going to override. They are going to, you know, override Ansible that are defined on top of the play, you know, on the play level. These are the task specific variables they take lead. So if I just try is accessing this endpoint on my browser. Right now. Tomcat endpoint 8080. It's nothing. There's not that service is not listening. It's not installed, so to speak. But then after running this against I want to delegate to this. You see, I delegated to host before but I want to delegate to server admin container and run Ansible playbook install packages. This is connecting to our Tomcat container. Sorry, our server admin container and it's installing Tomcat 9. That is what we do to our containers with the Ansible scripts. We are installing things. And even add any security running uncomplicated firewalls within containers. Exposing only those ports that we want to be export from those containers. Okay. Another security add any that we do within our Ansible scripts with Ansible you can interact with the firewall can pretty much interact with everything within within your host. Including the files you can, you know, it's stuck with Ansible tasks that you want some file to be owned by some user. And then what happens to the group access to that file. What happens to other, you know, other other access to that file. You can also start Ansible that you want those pretty defined, you know, in detail, permission defined in detail for a file you can do that with Ansible. And it's done. So right now if I go to my browser and access 8080, it works. It means we have Tomcat installed on that. This is just for demonstration but in production environment, we installed Tomcat, we, we even disabled this page, you know, the default Tomcat page and then we get, we do pretty much so many things it's a custom kind of custom configured Tomcat instance that suits our environment. The first task that we did here is just getting container and the second one is doing things within that container and we've just installed Tomcat nine and it's worked. So today we've just checked Ansible NXD and had a very brief demonstration on how it works. Unless the time is up, we can take a few questions and then we can, we can call it a day. You're breaking? Do you guys hear him well? I personally can't hear him. We are not hearing him. Yeah. If we can have like this record and go back because there's too much information in a very few very limited time for me to debate if we can have like kind of record or if maybe you have CPT we can go back and try to learn more or to master what you have, you have shown that. Uh huh. Yeah, before we started this call we recorded, we recorded our sessions. They're going to be uploaded into YouTube. Yeah. Yes. So I want us to just can even repeat sessions like this talking about Ansible every now and then until we all of us really understand what really happens behind the scenes and generally speaking it's just getting container and then doing things within those containers. That is what we are doing with our installed scripts and those are the major things that I have demonstrated within this very short time. Any comments? For me, no comments. I think it needs some more practicing. Because as the previous essay has a lot of learning over a few times, I think we need to do more practice on that. Okay. What do you want us to talk about next week? Yeah, of course I remember in one of the suggestions that I said earlier that we have been doing this server and the probably come up with the some automated script to help us quickly set up the DHS too. But one thing I think that's very important that you have to look at is how we can do it in offline. Like taking an example that you are going to a country that is totally offline. Maybe there is internet restriction, you can access the work. It's like you have to prepare something and then when you come and you go there, you just plug it in and then it works. I think that's another important thing that you might need your support. Okay, we can talk about that next week. I have something to talk about around that. We want to talk about what do we do in a gap environment. We went with Ansible and LXD. I'm going to talk about that, but with Ansible and LXD or just LXD, you know. And I'm going to talk about how you could set up DHS too within a container and then export that container into a file. And then you work with it either in a flash disk and then you can just log into the other server with a very fresh environment and just import that image. And it should have your old setup of DHS too. You don't need to install anything. It has your packages. It's just like you work with your working DHS to instance within a flash disk, bundled into an LXD container. Because if it is on your laptop and you can access to that server, you can just copy that file over as a search and just import as a container. And if you had set it up to have all those packages, it should just be having all those packages again. Is it not so? No, so I think Tito, what the question that he's asking, I think that... A gap environment. He's talking about a gap environment, right? Where you don't have any time. Say for instance, I log into this instance, okay? As I said, once again, 2.patsy.patsy. Sorry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . which is totally offline and you've exported these containers and you want to report it. So you basically have to like install the LXE in the local one. Yeah, I have assumed something. I have assumed that your... Yeah, that's exactly because you... That's an extra term. Yeah, but also I know I have actually used before that I mean the ISO image, the ISO image that has much packages that on a very remote environment you mount that ISO image and then you install your packages from that ISO image. I've used that before, but then you need to Okay, you have to prepare the ISO image of the LXE, okay, that's exactly what I'm trying to do. You prepare your ISO image that has your packages, it has your Tomcat packages, it has your Post-Test packages, it has your pretty much applications or rather the packages that you want when you're setting up the HRS tool and then you mount it on that remote server and then you use or rather you install your packages from that ISO image. I've used that before, that's another way. I think that answers this question because that exactly the next thing you might ask now is how do we create those ISO images? Okay, what? Yeah, it's a good, it's an interesting topic to talk about also. Also, there is as a search, how you can add an as a search, something that we can also talk about. So, I think we can enough, come up. Yes, I have my own question was that with Ansible, the web server that we have was and the engines, well I don't know if the Apache 2 is now working because it is working now. Yeah, it is working now. When we had our initial Ansible tool set up before, you remember the time that I demonstrated how you could set up the HRS tool with Ansible. At that time, we didn't have the Apache module was not working then, but then I have actually completed developing it and it works right now. So, within this, that's as a search, sorry, there is proxy. So, now, yeah, now even my install scripts right now are using Apache 2 because I was testing otherwise before we were using in the next. I'm also thinking of something like proxy, it's another proxy that's out there and it's very robust. Yeah, and right now you don't have to give full path of your, of your DHS 2.1 file, you can just give the fashion. As long as you have internet connection, it will pull the release file and then it will choose the version that you want. You can even change this to 2.9 and it will install your latest version. Right, so it's pretty much looking simple for the end user. However, you put the, if you don't want to use version and you have your own file, then you can say, you can say the HRS 2.1 file and give path to where you have your, your, your DHS 2.5. Yeah, for the cases of custom made, although you build your custom DHS 2.1 and you want to deploy it, then you can just put it here, like you want to deploy your DHS 2.1 from custom one file. Yeah, otherwise for the most use cases of public use cases, they want to just deploy DHS 2 instance developed from University of Oslo and they can just define the fashion that they want and boom, they get that. This, this goes up, this goes up as in, you cannot, you cannot deploy 2.9 and then take it back to 2.7 later on. No, because you can deploy 2.7 and then you go 2.8 or you can only upgrade, so to speak. Okay. So I think we can stop at that point today. Yeah, what do you think? So we, yes, yes, I think this is fine. Can we have both videos? Okay, I'll ask our, our channel manager, the one who's my manager is to channel to get all those videos to the, to the, to the channel. Yeah. But then they are recorded there, we have offline files that, that can just be uploaded to that channel. Okay. Yeah. Okay, thank you. Thank you for joining and please inform others to just be available on this call so that we can talk about so many things, so many other things. You can even talk about Linux, basic administration. You can, how you can navigate here and there within a very fresh install of Linux. Sure, sure. Thank you. I hope next time we'll be too many. Okay. Bye. Thank you for coming also. Thank you. Bye-bye. Bye.