 weekly community building call, let's call it that. It really came about because Tito and I were planning to do some Hyssop training in Uganda earlier this year, and then both of us were unable to travel. I mean, this might be a better format anyway, to have a kind of weekly series of meetings. So the idea being that we can touch base regularly together once a week, people might not make it every week. It's really important that you grab the link that Tito has given, plug your name in on the attendance section of the notes. The reason being is when we look back at the end of the year and we see how many people have been attending meetings, we'll help us decide whether it was a good idea and whether we should go forward with it or not. So please grab the link down there. Tito has put it in the chat and put your name on the attendance. I see nobody has done so yet. See who's going to be first. So we took a little bit more. We'll leave ourselves 10 minutes at the end to talk about some topics of the kind of things we might be talking about in these meetings. But for now, OK, the link that maybe people who are joining late, maybe don't get the link. Let me share it. So one of the exciting things about today is that many of you know me, I think, but I've not yet met Tito. So today you're going to meet Tito. Tito is basically taken over the role of shepherding this server admin community. For me, I will be Tito's sidekick from now on. He'll be hosting the meetings. I like to think of it as Tito will be the new Joe Rogan of server admin with a weekly call of interesting items. Besides Tito, some of you know we've got Danny from Solid Lines working with us part-time as well. But Tito is glad you're going to be leading the group. What he's going to be talking about today will be his conversion of all my horrible bash scripts. They're familiar with my horrible bash scripts, which people have used for doing quick setup and maintenance of their DHS2 installations. It's good to see Stephen on the call. Stephen actually contributed quite a bit to those early scripts. Tito's converted all those interansible playbooks, which is something we've been meaning to do for a long time. He's going to introduce a little bit of that today. But I think we'll have lots of opportunity in the weeks ahead to dig into some of those. Then we want to leave ourselves at least 10 minutes at the end that we can have a little bit of a round table about different kind of topics that we might discuss in future meetings. So guys, that's it from me. Tito, can I hand over to you now and forever? You can introduce yourself a little bit and maybe jump into what you're going to show us today about the ensemble tooling. Thank you. Welcome everybody who's made the call. And thanks for filling in the attendance and spread the word. And let's keep rolling. OK, Tito, that's it from me. Thank you. Thank you for the introduction, Bob, to the team. So my name is Tito. I'm from Kurgat and I'm based in Nairobi, Kenya. I'm taking over from Bob on Matters System Administration. But yes, I think he's going to be available maybe for the guidance. But most of the duties and responsibilities I'll be taking over on the system admin community. So yeah, well, I have close to one year right now in the HS2 University of Oslo. And when I joined, yes, we had a way that people used to do installation of an automated way where people would use to install the HS2 in their environments. Those are the Bob's Bashcripts, which kind of make things easier when you do deploy the HS2 and its components into a server. Well, one of the main reasons why or the reason why I got in is to at least support the scripts and also figure out a better way of deploying the HS2 not with Bashcripts or use Ansible for that matter. And I prepared a few slides that I'm going to at least explain the rationale why we are hoping to get to Bashcripts, get to Ansible scripts and do away with the Bashcripts. But I'm not entirely replacing Bashcripts. There are some other tasks that you cannot or Ansible is not going to handle best. Like even backups, backups would need a script that might or run from the background. And again, you cannot use Ansible to do backup because at the end of the day, Ansible would need, say, SSH or LXD to connect to your database. And if that happens, then that means that you need to really have a very good connection. And for you to run a backup and a backup, a very good backup or if you have a very huge database, might take not even or rather more than 30 minutes. And having a tunnel app or other SSH running all that time might be a challenge. Say if you have not good internet connection. That is why for issues backups, we will stick with Bashcripts and even other things. So I'm going to do up to Centation that will give us a brief overview of how Ansible comes into the whole world of deploying DHS to. So this is the slides. And I'm going to explain a bit about Ansible and how we are going to use Ansible to deploy in future DHS to application. And once more, give a few demos on why or explain and demonstrate the rationale why we are using Ansible. So traditionally, DHS2 can be deployed manually. And with that, it's a web-based Java application. And you need to just get the components running. One is the Java application, which is running, of course, on top of Tomcat. And then it needs to at least connect to a database, which is Postgres in our case. That means you need to again install Postgres database and then integrate your app. That is a Tomcat application with the same database. That means you're going to create manually database user and a database and the password. And then those details will get to the DHS2 application. And then it will be able to communicate back to the database, of course, when the app is running. Again, you need to deploy other components like proxy because at the end of the day, you don't want your Tomcat application to be hit directly from the internet. You want it to be hiding behind some proxy. In our case, we are using either Apache 2 or IngenX. That also you need to do it manually and traditionally. Somehow you get to install the application and then do SSL offloading. Of course, our DHS2 application is not doing SSL stuff. While it can do theoretically, you can just do SSL stuff on top of Tomcat, but not the way we are doing our stuff. We are doing SSL termination on the proxy. And then after that, well, at the end of the day, you need to do configuration file on either IngenX or Apache 2 proxy forwarding. At the end of the day, all your requests after SSL stuff is done to the bucket application, which is in our case Tomcat. Yeah, and those are the co-components of DHS2. But at the end of the day, in a very good production environment, it wants me monitoring. So you would also need to deploy monitoring on top of your co-components. So that alone would take a lot of time for you to have all those components set up and all integrated so that they can all work together. It will take a lot of your time. And if, say, you want another instance, again, you have to repeat the whole process and get another instance up and running. So that was monitoring installation. There are documents or documentation about the same or how you could do DHS2 installation step by step. And as I have mentioned, it will take time for you to at least have one instance up and running. And it's prone to errors also because you do interact directly with the system. It's very prone to errors. And also, it may, you may or not, appear to the best security practices when you do manual installation because at the end of the day, you will have to do permissions yourself. You'll have to ensure that Tomcat user is created and at the same time, all those files for Tomcat applications are owned by that user. All those security considerations, you'll have to do it manually. And most of the time, you'll find people forgetting those best practices when they do manual installation. And you would go to an extra mile of even creating system B files for your app. And sometimes people would deploy application that has or doesn't have those system B files so that whenever your server does a reboot, you have to do manual. You have to get your application up manually. So, and there we go. We went through automating stuff. Well, there are scripts developed by the team and both. Those are bash scripts. They do the job well. They do the installation of DHS2 perfectly well. And it gets all those components up and running. You don't have to worry that how to integrate, say proxy DHS2 application, which is the compute part of your stack and then the database. You don't need to worry about the end-to-end communication. It will just happen with the bash scripts because at the end of the day, it does create your config files. And then at the end of it all, you will just have to access the URL that was applied on the variables that you declared before the installation. And you'll have the app up and running. Of course, you'll do a few tricks, maybe for optimization, for the application and also the database. But from the fly, you'll have your instance up and running and you'll be able to access the data. I mean, sorry, the app from the web. Yes, but then the bash scripts is there, but it has a few challenges. One is, say you have an infrastructure on which database is sitting on its own server. Application is sitting on a separate server and even monitoring server is different. I mean, all those components are separated. They are not running from within one host. Then you need to figure out a way you would have the apps deployed on those components running on different servers. And the way bash scripts worked is you would have to be sitting on the server where you're doing deployment and then run the script from within that server. That would ideally or rather practically deploy the application from within that host only. That means it's not supporting that environment that I talked about where you have components running on their separate servers. Yes, so I think I guess we've talked about this. So to eliminate that is when we are opting for Ansible because with Ansible you can use other connection methods. You're not confined to running your script from within the host only. You can use SSH as a connection, underlying connection protocol where you just need to have a deployment server and then from the deployment server you get to run script remotely over SSH. Yes, so that you would have tasks that are related to say data is to application deploying Tomcat and you have those tasks grouped into a role and then it will deploy data is to application on on the application instance and then all the tasks that are related to database are grouped into a different role and they will deploy Postgres database on Postgres server and at the end of the day do the do the do the integration between the two. So with Ansible you're able to achieve that and Ansible has more than 15 connection models. One of them is LXD. That is when you want to deploy DHS2 within one host and you're using LXD containers then you can just connect to those LXD containers with LXD module. And another one is SSH. That is when we want to connect to the components, the server components separately with SSH and deploy DHS2 on those components and even database and monitoring separately. You could also connect with Docker. That is when you're deploying DHS2 with Docker containers. You're not limited to either using LXD or SSH. You can also do Docker and even more connection modules are supported. Yeah, so automation basically means that we don't interact ourselves more with the installation process. It's automated and we will not have or we will eliminate, if not do away with all the errors that normally happen when doing manual installation. And then when you want to deploy new DHS2 application, you just need to run a playbook or rather a bar script and it will do it in a fly. So yeah, that means you're going to spend very, very little time doing the deployment process. Yeah, so the two deployment automation approaches that we have right now is bar scripts that legacy bar scripts that we've been using on unknown. And then we have the DHS2 server tools, which I definitely know. And then these ones now are using Ansible. And right now they support two connection modules, the plugins that is SSH and LXD. So that means you can have DHS2 running on a single server and you'd be using LXD connection plugin. You just need to declare that and it will set up DHS2 and all its components within one server using LXD plugin. And if you want to, if you go to an environment where DHS2 is the components and the application stack are spread over virtual machines or physical servers, then you don't need to worry. As long as you have network connectivity between all these components, that you just need to have one or other small deployments of a way you have Ansible. And then you set your connection to SSH. Of course, prior to that, you need to make sure that you have at least SSH connection to those hosts that you're going to be deploying DHS2 into. Yeah. So, yeah, I've also explained why we want to get to Ansible entirely and afford using Barskips. And one of the reasons is because with multiple connections, we can support multiple architectures. And of course, also there's inter potency. That means Ansible, whenever you run a task and then you repeat the same playbook again, it will not do nothing. It will just tick that that is already done and you don't need to do anything. It will just be skipped. Those tasks are going to be skipped. So, yeah, it is very important and that is a very good feature because you're not going to have undecided effects when you do repeat your playbook. It will just do nothing. So, when you do deployment once, you don't have to worry about what will happen when you do repeat running your playbook. Okay. And I'm going to do a quick demo on the connections that are supported by Ansible and then also, say, demonstrate the inter potency with Ansible. So, I'm going to switch to terminal. Yeah. So, I have a server here that's fresh. It's running Ubuntu 2204 with this IP address. Yeah. So, I'm going to connect into it via SSH. Yeah. And then we're going to check the SSH files, for instance. SSH defined for, just for example. Let me ping. Be sure that the server is reachable from here. Okay. Yeah. LXD list. So, it's just another LXD container. I'm just using SSH server and I want to ping it from my laptop. This server is sitting elsewhere and I am able to reach. I'm accessing it via VPN. So, I'm going to, as I said, into this server and check SSHB configuration file. So, I'm going to edit SSHB config. And this is the, at least the default configurations that you get when you install a fresh Ubuntu server. And of course, enabled SSH. So, it doesn't have much. It has lots of the basic say port 22 for SSH. And with this, even password authentication, as I please know. But then I might, let me just change it to yes. And then I will run later on as Ansible Scripts to change that. That the Ansible Script is supposed to have an SSH, for instance. Yes. And then, yeah. So, it's very fresh config file. It doesn't have, it has defaults. At least I've changed the authentication to allow password authentication. But then I'll run as my Ansible Script and see and we can watch together what it's happening. So, I'm going to run Ansible also from my laptop, Ansible Playbook. And then, of course, the playbook I want to run is to set up. And then I'm going to put the host, which I want to run my playbook against. And the host is this. It has this IP address. It has .179 as its IP address. So, you put its IP address there. And then, yeah. And then with minus K, you will be prompted for a pseudo password. Because at the end of the day, as much as Ansible is connecting via SSH to the remote host, you need, and you need to do tasks that require elevation, it requires pseudo. Then you need to instruct Ansible at least to be able to run elevated privileges remotely. And of course, remote server has pseudo password. So, with minus K, it enables you to supply that pseudo password, which will be used at least to do elevated privileges on the remote server. So, this playbook, toolsetup.yaml, has SSH optimization tasks. And I'm going to run it and then I'm going to repeat. So, this minus K is going to prompt for that, for the become password. So, it has to be minus I, not minus L. Minus L is for limiting, but just minus I. Yeah. So, this is now running all the tasks on that playbook. And it will at least show you what's happening in the scenes. And we have an error, pseudo password, I didn't type it well, let's repeat and see. Yeah. So, the password is correct. So, first task is gathering facts. Normally Ansible when you run and you don't instruct it to not gather facts, then it will gather facts about the OS that you're running against. And facts are actually metadata about the OS or rather the server that you're running playbook against. For instance, in our case, if it's an Ubuntu, then it will catch the OS release and all, even the gateway IP address and all the metadata about that server. There are a lot of information here. So, but you can turn off that if you don't want. So, now it's running the tasks. And those tasks are actually, I mean, adding SSH to make sure that it meets at least the best security settings. And see the first task is disabling with key exchange algorithms and enabling strict symmetric key ciphers and configuring secure message authentication algorithms. So, this task, it checks actually really the configuration files that Ansible, sorry, that SSH has and it's changing if it's not meeting the top security. Like this one now here, password authentication, it's being said to know because I had 33 years when I accessed that server. So, it's now reverting to know and even other lines are being changed right now. So, when this finishes and we check the configuration file on this server, it will have changed. It will have changed a lot. Yeah. So, this playbook is now finished and we can check the configuration file once more and see what's changed. Now, you see the configuration file has a lot of changes. This one was not there before. We have it now that only authentication method allow this public key. And if you go to the very beginning, you see that this whole key parameters that you see and commented here, these four lines here or even five, they were added and they are actually making secure, making SSH more secure and even making the FABOS level, I mean the local level into FABOS and disabling root login, for instance, and enabling only public key authentication or setting it to yes. And even disabling password authentication, which we had said to yes just for demonstration. And even down here, you notice that the other lines that were added. So, upon running this script once more by Ansible playbook once more, I hope I've done correct to the password. You will notice that nothing will happen this time round because all those changes that are declared on the task are done already. So it will not do anything. You're seeing this now that disabling key exchange algorithms is green. Green means it's not doing anything. And everything that happens now this time round will just be green, green, green, because that's now explains the interpotency of Ansible, that it should not repeat the same thing once it's done already. So that explains. You know, you can have to watch your time a little bit if we're going to leave 10 minutes at the end. Okay. So that explains the interpotency. So yeah, and then we want to check also Ansible connection supported. So you'll notice that all that happens here will just be green, green, green. It will not change anything. And this is the desired characteristic of Ansible that once you run your playbook and some changes are made, you don't need to, when you run it again, it will just do nothing. And we watched that also during our, our data is to deployment. Yeah. So let me demonstrate the connection feature. Let me, let me wait for this to finish then I'll demonstrate that also. But at the end of the day, right now, everything that happens here is through SSH. It's happening via SSH connection. This server, as I mentioned, is sitting somewhere else. It's not within a VM here. It's even some other building. And connection to that server is with SSH using at least public private key authentication. So if I do Ansible dots, let me see Ansible and then dots and check. I mean, at least the type connection, the number of connection that we, they are supported. You notice that there are many, there are many. And we are focusing on SSH and at least LXD somewhere here. Yeah, here is LXD. So these are the two connections that we are using right now. But you can even explore LXD because with LXD connection, you can also connect to your containers. There's also Docker connection and even these other connections that we are not using. You can use Ansible to connect to LXD and even KMO, you know, all these connection protocols are supported. Yeah. So Ansible, let me just add hook command. Ansible and then I want to connect to, I want to connect to this server over SSH, this server over SSH and just ping. Ping is just used for testing connectivity. Okay. That is used to test this connectivity. The module I'm running is ping. Just to test if I'm able to connect to this server here using Ansible ad hoc command. And this means that I'm able to connect to that server with SSH. Of course, I could verbose and check connection used under the hood, for instance. And you'll notice that it's using, at the end of the day, SSH connection and it's using my username KT to connect to that server and it's able to connect and it's able to ping. Yeah. Yeah. So when I am sitting within this server and of course LXD containers are running here, I could also run the same ad hoc command from the server. But now this time around, I want to use LXD connection. And for LXD connection, we just connect with them with the container's name, not even the IP address. Let's just connect to the container's name server admin and then use environment variables where you set your first connection really to be LXD and not defaulting to SSH. Because as I said, at the end of today, it's a default connection. So we can connect with that and do a ping and see what happens. It's also successful, it's success. And we can check really and prove that LXD was used under the hood. And this is going to show us that with a little verbose, we're going to check and be sure that really the connection used was LXD. You can also use Docker and all those connections that I did, I showed back here. Yeah. So I've demonstrated Ansible's ability for the, for in-dem potency and also that it can support even SSH and LXD connection. So maybe I can just show you the structure of my Ansible script, HS2 scripts. And yeah, it has this structure. We have two directories, deploy and then docs directory. Of course, this is in GitHub already. And we want to have documentation and how to documents within this folder and then the code of the Ansible script within the deploy folder. And then read me, of course, is on the top of the directory where it gives us at least how you could install or follow the installation process. Yeah. Okay. So within the deploy script, deploy folder, we have Ansible playbook and also the roles. So the main playbook that we normally run is the HS2.yaml. Let me just edit and see, display the same. It has a few roles. It has Postgres. These are roles that are related to Postgres database. Deploying Postgres within either an LXD container or within a server sitting somewhere else and access is over SSH. We have the HS2. This is really focused on deploying the HS2 application either on a standalone server or within the LXD container. This is proxy, which can be in GNEX or Apache 2 and also monitoring. Monitoring is for the Munich, for general server monitoring and also even application monitoring with Glowroot. Yeah. So this is the basic structure. So at the end of the day, it reads variables somewhere and those variables are in inventory host file. And on inventory host file, just edit. This is where you can declare the type of connection that you want to use, either LXD or SSH. In case you have your servers scattered everywhere and you have access with the network, with the IP address, then you would set this to SSH. That way it will connect to those servers with SSH and deploy your HS2. And a few other configuration parameters like SSL type that you want to use, you might have your SSL certificate with you or you want to get that with a net encrypt and even time zone and the network that you want to at least be using. So this is the configuration file that have all those together within one file. Of course, there are other ways that you could declare your variables with Ansible. There are a ton of ways that you could declare your variables. Right now we are using these and these scripts are being improved. They're actively actually developed and we keep improving every time. I think up to that point, I have done a couple of introduction with Ansible and even our tools. Yes. So we have roles done or written into this directory. They're all cooked into this roles directory. If you go into that directory and list the contents, then you have data is to firewall, integration and even monitoring and Postgres directories. Those are hosting raw scripts or other scripts that deploy those applications. Let's just check one script for deploying data is to. It's within data is to folder tasks. And then within that, you have so many tasks that you can see this one, this one, only this one. And this one have YAML scripts. These are now with Ansible. And you see it's somehow has description, the comments. And this one, one comment is for instance, setting up Tomcat and Java. It's installing at the end of the day, Jerry and Zip and Tomcat 9 and Tomcat 9. So it's just like the basic way that you would use to install application or other package with apt. But this now you're using apt module because Ansible have a ton of modules that you could use. Instead of, you could run raw command here, but you can take make use of apt module for the interpreters and even other benefits and install those packages with this single task. And then all the other tasks that are relating to DHS2 will now come until the end. And even like this one, very last one here is getting the file. You can get the file from either a file or from the internet where we normally host our files. So yes, so I think we can now go back to the last section of the agenda. Unless there's a question. Yes, Tito, can I come in? Yes. Okay, thank you very much. I think that's a great job that you have done and looks more interesting to try and find out maybe which area to improve and things like that. Of course, it's good that you have come with another initiative to have multiple alternatives if somebody wants to install DHS2, which scripted we use. We have been using a bash, as you said before, and then coming to this, Ansible looks more a bit interesting. So I think you will try and try to come up maybe the next time we meet. We might have some feedback maybe to share or so where the area to improve and things like that. Yes, yeah, in even sessions that come after today is I would even demonstrate that they all installation with Ansible. I mean, like in a session, do installation from scratch either using LXD connection and deploy our apps within the single server with all of us watching and with all of us on call with share screen and then we run and see all the tasks that happens behind the scenes and then also discuss more about it. Of course, another session we can even schedule connection with SSH, set up virtual machines and try from a deployment server deploy DHS2 using SSH connection to those servers and have a few questions from you and even discuss more about that, yeah. That sounds good. If as many people as possible get the chance to just try them out too in the week, then yeah, maybe next week Tito, maybe you can do a kind of end-to-end installation but also let's deal with feedback and questions and suggestions for improvements from the people. Yes. Moses was worried that maybe the setup of Ansible is a little bit complicated. No, no. Well, from the readme, let me just get to the readme file, DHS2 server tools. I know what I was talking about Michael, I think last month because it's not so much that the setup of Ansible is complicated but the whole layout of Ansible scripts can be a little bit intimidating to start with. But yeah, you've done a good job here of describing the setup. It's not so bad. Yeah. So with these few commands here, you can at least have Ansible setup on the server. Just need to brand them and that will get Ansible platform installed. And then from there, the only thing required now for you is to run the script using the installed Ansible. Yeah. Of course, there are the packages like Python net address that will be required before you start installation but then this will take care of that. Yeah, I think. I can confirm that I was successfully able to set up everything with Ansible. Check this from scratch, no preparation before. There were some minor packages missing and I did them successfully but it was down the pure like Ubuntu setup without any extra packages in the system. So the documentation is sufficient to make it happen. Thanks Michael. Good to hear you, maybe just for the purpose of other people on the call who haven't met you. Michael is our security boss. One of the things that he's doing is going to use these Ansible scripts as a sort of security reference configuration. So everything that we recommend in terms of security compliance to whatever controls we think are suitable all of that should be the reference implementation should implement all of those controls. So it's a good thing to watch and maybe we'll get a chance to interview Michael one of these weeks about some of that work. Yeah, I just wanted to add that our idealistic and probably achievable goal is to set an environment where we ought to configure the environment where we can safely deploy DHS to a system which is secure by default. And the scripts are already doing a lot of the work for that. So the configuration was thoroughly done to ensure that we have important security company where all proper configuration for SSH and other things done by default and we will be assessing this reference setup on our test platform. So I hope that in the near future we'll be to say that once you use these tools and install the system without any extra addition it will be or changes. It will be reasonably secure by default. This is a kind of a super goal for us. Yeah, I agree. And the beauty of the scripts Ansible Script is that you can now improve with time to suit your security requirements and say you want to fix some permission of a fine that will be deployed. You can just with time change that and at the end of the day the end goal is to make sure that whatever the scripts do deploy meets the best security standards. Yeah. Okay, so maybe without getting too far into the love fest of the beauty of your script, let's see if we get a little bit of feedback from people. I know this is a very fast call that we've done and we've got an idea where next week we'll go ahead and you'll continue with doing the full setup. But I listed down a whole lot of possible topics in that agenda item four. I'd be interested to hear from people what's their kind of priority interest? What kind of things would they like to be talking about? Any suggestions? One of the things we can do, so it's not so boring, is we can find interesting people to talk to. They would get Michael on one of these weeks. We can talk to maybe the infrastructure team in Oslo. We could talk to different implementers out there, ISP South Africa, BAO, just get interesting people on, and lots of tutorial sessions. But please, anyone, what's their thinking about topics? Is the weekly call a good idea? It's a good idea. It's a bit of a commitment for everyone on a Thursday morning. And maybe suggestions on maybe other topics that you would need us to talk about? Hello, Tito. Yes. Yes, I think most of the time we have been focusing on installing VCHS to especially when we are online, connect to the internet. But with my experience visiting it to Eritrea, it's just another situation that where it's totally offline and it's somehow very hard to install VCHS to offline, where you might also need to gather doing this virtual thing and clear out that visualization that we have created online to the offline site. Maybe we can find a way to do this kind of VCHS to installation offline. This script that we are creating, all we have been using works fine when we are online. But what if it's offline? How is it going to work? Maybe we have some early exploration on that. Yes, that's a good point. When because the scripts at the end of the day, when you're doing, say for instance, installing Postgres, you pulling it from the official Postgres SQL repositories or even when you're installing Tomcat, you don't get the file. And then you're not doing it from a file. You just get the files from the internet. So there are situations really when internet is locked and you don't have access to any server outside there and you want to deploy VCHS to that way you get your packages and ideally you need to get them into the server, say via SSH and then have VCHS to running. So it's kind of manual setup without internet where you put your packages and put it the right place and then you start Postgres with those, yeah, bin files. I think the way I would probably approach that is to assemble my travel kit before you left. Maybe set up by a kind of a local app repository with all the packages that I've freshened up before I've left taken on my portable hard drive or USB stick or what have you. Steven, you've done quite a lot of installations of odd software in odd places. Including Eritrea. Hi, Steven here. Yeah, it's exactly what you said, Bob. I tend to, when I've done it in difficult places, put together my kit as it were and bring it along. In the past, sort of before Linux containers happened, I was a fan of using tools like VMware, which are more commercial, but they offer you the ability to relatively easy, just grab an entire virtual machine and dump it onto a hard disk and just bring it along with you and just redeploy it. These days, with containers, the other neat thing you can do with either LXC containers natively in Ubuntu or if you use a tool like Proxmox, which makes LXC containers have a nice web UI and all that, to right-click back up, and then you just have the whole container and then you just take the container with you. I mean, the nice thing these days is disk space is cheap, so it's pretty easy to carry things along. Great presentation, by the way. I really welcome seeing people starting to use Ansible, and I make a lot of use of it as well, and if anybody ever wants to have a further talk on this meeting, covering topics like going a little bit further with Ansible about maybe how to deploy in an environment where you have other things running. If anybody's interested in tools like Telegraph or InflexDB, that might be integrated into Monitor, things like DHIS2, love to share. Also, I do something similar when I deploy DHIS2, but I actually make use of the Oslo Docker images because I find Docker really, really useful, so I actually deploy different Docker containers using Ansible. If anybody's interested in that, love to share there. Thanks. Yeah, Stephen, we'll put you on our list of interesting people to enter. Okay. I think it's great that you're having this meeting as well too. I think these face-to-face type discussions are fantastic. Yeah, I think we can, our time is up. We can wrap up today and then, yeah. Feel free to add more topics that we can discuss more about maybe next week and even subsequent calls. It's 13 hours. Cool. Thanks, Tito. I got to get on to another call, so see you all next week. Bye. Okay, thank you very much.