WEBVTT 00:00.000 --> 00:11.040 So, hi everybody, I'm here to talk about my NYXOS Powered Home Lab. 00:11.040 --> 00:14.300 This is, I was in a really large auditorium and I was like, wow, I did not think that 00:14.300 --> 00:16.760 this many people were going to be interested in NYX, but there's actually a lot of people 00:16.760 --> 00:19.160 here too, so this is awesome. 00:19.160 --> 00:24.160 Okay, so first of all, I'll tell you what my path is in NYXOS, because I probably took like 00:24.160 --> 00:26.840 a difficult path, and I'll go through this part quickly so we can talk about the interesting 00:26.840 --> 00:29.760 stuff with what time I have left. 00:29.760 --> 00:33.840 I think probably a lot of people start with NYX and NYXOS, probably with like a NYX shell, 00:33.840 --> 00:40.720 because you are dealing with packaged dependents like conflict dependencies and your dependencies. 00:40.720 --> 00:45.040 I ran into that, home manager, if you're trying to like consolidate your dot piles, maybe 00:45.040 --> 00:49.440 as another popular entry point into the NYXOS system, I don't really have opinions about 00:49.440 --> 00:55.040 flakes, but I like didn't do this, right, like maybe this is something I actually do a lot 00:55.040 --> 00:58.280 now, because I work at a company that does click how stuff, you know what I was trying to 00:58.280 --> 00:59.280 tell you about. 00:59.280 --> 01:02.240 So what I do is all the time now, but on my first day with NYXOS, I was like, no, I need 01:02.240 --> 01:07.880 to solve like all these problems, all at once, and yeah, if you want to hear more about 01:07.880 --> 01:14.120 click else, I'll be talking about that later, so the question I was reading with is like, 01:14.120 --> 01:20.120 I want templated VMs for my home lab, and I don't want to have to store multi gigabyte 01:20.120 --> 01:23.840 images for all these templates that I have, and I want to be able to have a lot of them, 01:23.840 --> 01:28.920 and I want to be able to version them, and like use text-based definitions like I'm used 01:28.920 --> 01:32.920 to with like a Docker file, or a Docker composer, or something like that. 01:32.920 --> 01:37.240 I wanted to share parameters between different VMs, and also between the different layers 01:37.240 --> 01:42.880 of my VMs, right, like there's some information in my workloads, and I was using Ansible 01:42.880 --> 01:47.240 to configure Prometheus to monitor my hosts, but maybe I wanted some information about what 01:47.240 --> 01:50.360 ports were exposed by those workloads, or which ones were running in Docker, and maybe 01:50.360 --> 01:54.960 I had C Advisor, and I wanted to get that information into my Prometheus config, and with 01:54.960 --> 02:00.600 Ansible, that was just kind of way too much work, right, it was very difficult. 02:00.600 --> 02:06.840 So I came across, and I saw this sort of the solution, and a way that let me define 02:06.840 --> 02:13.800 my VM images using something similar to a Docker file, and the other challenge with Ansible 02:13.800 --> 02:17.360 way is like keeping track of like, why have I actually applied to each different VM, right? 02:17.360 --> 02:22.560 You have these plays, and they're not as reproducible as we would like, right, because 02:22.560 --> 02:27.160 they're dealing with the state on the target host, and there's just all these things, 02:27.160 --> 02:29.000 right, they're making it so much kind of jiffy-hote. 02:29.000 --> 02:32.880 And Telephone doesn't really fit like a home-ribed context, right, like that's for provisioning 02:32.880 --> 02:35.640 infrastructure, not for configuring hosts. 02:35.640 --> 02:42.700 So why next to us, if first me to use get-ups, it was self-documenting, right, but the next 02:42.700 --> 02:46.300 us, configuration, sub-documenting, and it was portable, reproducible, like much more 02:46.300 --> 02:49.780 so than a multi-gega-by-image, and it was using familiar tools under the hood, where 02:49.780 --> 02:54.180 like I could see that I could use OCI containers, I could use system D services, so these 02:54.180 --> 02:57.620 are things that I'm familiar with, and it was just a nice, declarative way to interact 02:57.620 --> 02:59.620 with them. 02:59.620 --> 03:00.620 And why do I love NICS? 03:00.620 --> 03:04.940 Well, like I mentioned here, it's one language, I have one object tree for everything, 03:04.940 --> 03:08.820 so anything that's a parameter anywhere, I can use it somewhere else, no matter what part 03:08.820 --> 03:10.780 of the layer, what part of the stack it's in. 03:11.100 --> 03:14.460 I will functional languages, so NICS just kind of made sense to me, I don't think that's 03:14.460 --> 03:15.460 true for everyone, right? 03:15.460 --> 03:19.620 Like I think some people just kind of think in that way, where you look at a pure function 03:19.620 --> 03:24.140 and it makes sense, and some people like, no, I want more steep. 03:24.140 --> 03:30.860 And then finally, the NICS module system is probably my absolute favorite thing in NICS. 03:30.860 --> 03:35.580 So for those of you who are not familiar with it, like NICS modules is what's used in 03:35.580 --> 03:43.140 home manager and NICSOS, and it's probably when you've written your modules, maybe 03:43.140 --> 03:44.740 without even knowing it. 03:44.740 --> 03:48.940 But what I love about it is how it lets you override things, right? 03:48.940 --> 03:54.060 So every other configuration tool that I've used, whether it's like how am I Ansible 03:54.060 --> 03:56.260 or what have you, right? 03:56.260 --> 04:00.980 When you're trying to make versions of things or like make an instance of a templated 04:00.980 --> 04:05.540 thing, it's always end up in this challenging situation, or it's like, I can't 04:05.580 --> 04:09.580 override the specific thing that I need to override without going up to the thing that 04:09.580 --> 04:14.700 I'm like, depending on, and or if you do want to override things, you end up having to 04:14.700 --> 04:15.700 be really, really verbose. 04:15.700 --> 04:18.780 Like, I'm going to override this file, this config file, so I actually need to recreate 04:18.780 --> 04:22.220 the whole thing, even though I only wanted to change one value in it. 04:22.220 --> 04:26.940 Or you have to, like, in careers you used something like customized to do that, like, it's 04:26.940 --> 04:27.940 challenging. 04:27.940 --> 04:30.540 NICS module is awesome because it all just gets murdered, right? 04:30.540 --> 04:36.100 Because it's just a tree of configuration options that all gets merged at the end, so 04:36.100 --> 04:40.140 you can override anything anywhere, and you can specifically override just the thing that 04:40.140 --> 04:41.580 you need to override. 04:41.580 --> 04:46.740 Okay, so I'm going to quickly talk about how we use NICSOS Generators to create VM images. 04:46.740 --> 04:50.460 I'm going to talk about some of the NICS configuration, NICS configuration that specifically 04:50.460 --> 04:52.700 is useful for VMs. 04:52.700 --> 04:57.540 I'm going to talk about how I use NICS, a NICS-flake to manage multiple hosts, where I can 04:57.540 --> 05:01.700 just drop and you can dig into a folder and then apply it. 05:01.700 --> 05:04.340 And then finally, we'll talk a little bit about just, like, how I manage my workloads and 05:04.340 --> 05:05.340 services. 05:05.340 --> 05:08.580 Maybe it'll give you some ideas. 05:08.580 --> 05:09.580 Yeah. 05:09.580 --> 05:10.580 So, okay. 05:10.580 --> 05:12.660 NICSOS Generators. 05:12.660 --> 05:18.620 So, and anyone here familiar with this command NICSOS Generator, yeah, okay. 05:18.620 --> 05:21.860 So you can, you can give it a target for that. 05:21.860 --> 05:25.380 Here, I'm using PROXMAX, and actually the output of this is going to be PROXMAX back 05:25.380 --> 05:29.540 up now, that you upload to the, there's a directory that PROXMAX expects its backups 05:29.540 --> 05:30.540 to be in. 05:30.540 --> 05:32.540 It's like, bar of using something. 05:32.540 --> 05:37.740 So, STP, the output of this, which is going to be, uh, simlinked in the folder that you 05:37.740 --> 05:40.380 run this command in, and also in your next store. 05:40.380 --> 05:44.660 Um, and you get this image that you can then restore a backup fund. 05:44.660 --> 05:47.460 And you can use really any complete configuration that next to that. 05:47.460 --> 05:51.340 So, I have kind of a base template that I use, and most of all has, like, it enables 05:51.340 --> 05:55.220 to remove updates, which we'll go through, and it has my SSH key for my default user. 05:55.220 --> 05:59.820 And then I can provision as many VMs as I want using that image, and then use NICSOS rebuild 05:59.820 --> 06:04.620 and target host to update those with the specific configuration that they need, for whatever 06:04.620 --> 06:06.620 that VM is supposed to do. 06:06.620 --> 06:09.900 So, let's talk about the VM specific configuration. 06:09.900 --> 06:14.900 Um, everyone for all of module's path, and anyone who's not module's path is especially 06:14.900 --> 06:20.020 variable that you get in an XOS configuration that points to the actual path, but, like, 06:20.020 --> 06:23.020 in NICS packages, we're all of the modules are. 06:23.020 --> 06:26.820 So, if you look at that git repo, in NICS package, right, and if you look at the NICS packages 06:26.820 --> 06:31.260 git repo, go to the modules directory, and then go to the profiles directory. 06:31.260 --> 06:35.260 You'll see there's actually a bunch of different profiles for different situations, like 06:35.260 --> 06:42.460 there's an LXC profile, um, there's, I think, in ESXi1, um, and since ProxMox, under 06:42.460 --> 06:47.940 hood is using KVM and Cuno, we're going to use the Cuno, um, guest profile. 06:47.940 --> 06:50.700 This basically just includes all the hardware configuration. 06:50.700 --> 06:54.620 There's basically replaces your hardware configuration file for VM, for the most part. 06:54.620 --> 06:57.780 You still need to define some volumes and things like that, but all of you drivers and 06:57.780 --> 06:58.780 everything. 06:58.780 --> 06:59.780 You get with this. 06:59.780 --> 07:03.100 And then we can just, like, turn on the Cuno guest service. 07:03.100 --> 07:08.380 This is nice when you're running in ProxMox, or any other Cuno hypervisor, because it, um, 07:08.380 --> 07:10.860 most importantly, there'll be a lot of safe shutdowns, right? 07:10.860 --> 07:11.860 So, that's really nice. 07:11.860 --> 07:16.060 It also reports some metrics in state and other things like that, like the IP addresses and 07:16.100 --> 07:18.900 stuff that's useful to see from the hypervisor. 07:18.900 --> 07:19.900 Perfect. 07:19.900 --> 07:24.780 So, uh, what goes in our VM specific configuration? 07:24.780 --> 07:27.300 Uh, we want to enable the bootloader. 07:27.300 --> 07:29.780 That's nice, because then we can roll back to the previous config. 07:29.780 --> 07:32.820 I don't like to have a lot of extra volumes in my VMs. 07:32.820 --> 07:35.060 I like everything to just be on one volume. 07:35.060 --> 07:38.700 So I use this, uh, node V, setting for the bootloader. 07:38.700 --> 07:40.980 So it's just on the boot drive. 07:40.980 --> 07:43.820 It's not on a separate volume or device or anything like that. 07:43.820 --> 07:47.620 If I are, yeah, let's just keep it simple, right? 07:47.620 --> 07:50.860 This is the most important thing to put in all of your VM configs. 07:50.860 --> 07:54.100 Uh, I leave this out sometimes and it always bites me. 07:54.100 --> 07:57.380 Uh, what this does is automatically resizes the partition when you reboot the VM. 07:57.380 --> 08:01.340 So if you resize the volume underline the partition, right, next to us, we'll see that. 08:01.340 --> 08:04.020 And when you boot up, and it'll take up the space that you gave it. 08:04.020 --> 08:08.940 Um, I tend to start some VMs right with very small volumes, like eight, ten gigabytes. 08:08.940 --> 08:13.140 And then, uh, if you're using it as a next build host, that can get filled up and 08:13.140 --> 08:14.140 really, really fast. 08:14.140 --> 08:17.060 If you're not garbage collecting the next store, right? 08:17.060 --> 08:19.260 So just like always keep that on as a safety net. 08:19.260 --> 08:23.820 And case you need to increase the size of the volume and recover from something. 08:23.820 --> 08:28.380 Um, this is the other more important part that goes in all of my next configs. 08:28.380 --> 08:31.100 This is, uh, what allows remote updates. 08:31.100 --> 08:36.260 Um, so this we were saying is like, what users other than route apply updates remotely. 08:36.260 --> 08:39.380 So that we can use just a regular pseudo user. 08:39.380 --> 08:43.340 And then we're just enabling the X command and flakes, which is useful for remote updates. 08:43.340 --> 08:47.060 Once we've got that enabled, we can do this. 08:47.060 --> 08:52.660 Um, this is, this is completely replaced like 90% of my Ansible commands. 08:52.660 --> 08:56.940 It's, it's now just this right, update and it's config and apply it. 08:56.940 --> 09:01.900 Okay, please get to something maybe a little more unique, not directly from the documentation. 09:01.900 --> 09:03.660 How do I manage the manager of hosts, right? 09:03.660 --> 09:08.820 Like that, at one point I had, you know, maybe 20 or 30 mixed OSBMs running, um, I've 09:08.820 --> 09:12.300 been simplified, but it, it's a lot to manage all of that. 09:12.300 --> 09:16.140 And, um, you don't necessarily want like a flake for each one, especially if all the hosts are 09:16.140 --> 09:18.980 kind of doing the same thing or based on the same template. 09:18.980 --> 09:24.020 Um, so I had this in my, in my primary flake. 09:24.020 --> 09:29.100 And we're basically just iterating over every configuration file in a directory and turning 09:29.100 --> 09:34.760 it into, uh, an XOS configuration that we can drop into our flake outputs under the 09:34.760 --> 09:41.160 XOS configuration's key and, uh, then you can just drop any new file into that top level 09:41.160 --> 09:44.860 directory and get a new target of the new flake target. 09:44.860 --> 09:51.160 Um, speaking of flakes, right, this, I originally, it was kind of following some of the 09:51.160 --> 09:55.540 patterns that I see in other people's like that files, repos and there are some really 09:55.540 --> 09:57.940 popular people, uh, people's configs right. 09:57.940 --> 10:02.180 And they tend to have this structure where you have like your user's directory, your modules 10:02.180 --> 10:07.860 directory, your host directory, and they're all importing from each other. 10:07.860 --> 10:08.860 Now that's great. 10:08.860 --> 10:14.460 I still use that pattern, like, for Nick Darwin on my laptop, because I like to have 10:14.460 --> 10:18.180 everything in one repo for my actual work machine. 10:18.180 --> 10:22.540 But when I was managing a bunch of VMs, this started to get unworthy because I wouldn't 10:22.540 --> 10:27.820 know, I would want to update maybe some file that was being depended on by all of these 10:27.820 --> 10:33.060 other files and, uh, it would create breaking changes, or I would lose track of, you know, 10:33.060 --> 10:35.780 which version of what I had used where. 10:35.780 --> 10:38.780 So the way that I deal with this now is I've split things out. 10:38.780 --> 10:43.020 My dot file, secret to users, that also contains like, got repositoring, each one of these 10:43.020 --> 10:47.460 circles is separate repository, so that repository also contains, I can think for my 10:47.460 --> 10:49.340 natural work stations. 10:49.340 --> 10:53.980 But then I have a separate repository that has sort of my reusable modules and templates 10:53.980 --> 10:58.260 that I might import into a server specific config. 10:58.260 --> 11:01.420 And then I have a whole bunch of repositories that contain host configs. 11:01.420 --> 11:07.540 And all of those import from the modules repository, some of those import my users and secrets, 11:07.540 --> 11:10.900 so that I can, right, use those in the host configs. 11:10.900 --> 11:15.780 But I try to keep these, um, separated by use case or domain in my life, there are a lot of 11:15.780 --> 11:18.340 different things that I do, a lot of different hats that I wear. 11:18.340 --> 11:25.380 And so, uh, wait, a repo per collection of hosts will call it. 11:25.380 --> 11:30.140 And then by importing those other two things as flakes, it allows me to version it. 11:30.140 --> 11:34.340 So I don't, I'm not, if I, if I update one of those upstream things, I'm not forced to update 11:34.340 --> 11:37.860 all of my hosts at the same time, I can do it, you know, whenever I have some other 11:37.860 --> 11:39.980 thing that I need to change. 11:39.980 --> 11:43.580 Um, I was launching the modules, I think they son, I hope people were able to enhance 11:43.580 --> 11:44.580 everyone knows what this does. 11:44.580 --> 11:46.780 But they, yeah, just, just use these liberally. 11:46.780 --> 11:47.780 They're awesome. 11:47.780 --> 11:48.780 Make default. 11:48.780 --> 11:52.100 So you can write a thing, make force, allows you overwrite a thing that wasn't made 11:52.100 --> 11:54.100 default. 11:54.100 --> 12:00.940 Um, one important note, as you sort of get a proliferation of mixed configs, and I didn't 12:00.940 --> 12:04.780 do this at first, I kind of had system.state version in my templates. 12:04.780 --> 12:07.860 Now I still keep it in my templates because that makes them complete and I can build 12:07.860 --> 12:10.140 them and test them, which is nice. 12:10.140 --> 12:16.460 So I also, like, do explicitly override this in every host specific config, otherwise you 12:16.460 --> 12:20.860 will break things when you update a template and forgot that host was using an older version 12:20.860 --> 12:28.260 of system C, um, and, and also, yeah, commit your configs, um, the next source generate 12:28.260 --> 12:33.020 command that we looked at on like the first slide, it does not put the configuration.nix 12:33.020 --> 12:36.140 into the image that it builds or the outbreak, which I will for you choose, it's not going 12:36.140 --> 12:39.700 to put that configuration that was used to generate it into the output. 12:39.700 --> 12:45.460 So it's on you to save that somehow, like, in your, in your, um, get repository. 12:45.460 --> 12:51.460 So let's talk about workloads and how we get workloads into these reposts, uh, services, 12:51.460 --> 12:52.460 right? 12:52.460 --> 12:59.500 Um, this is just a really simple example of how we are, um, how we can use the module 12:59.500 --> 13:06.580 system right and use the, this make enable option, um, to create modules, so rather than 13:06.580 --> 13:12.260 having, like, rather than copy pasting stuff between nix configs, you can just throw 13:12.260 --> 13:17.100 anything that you ever do into a nix module's repo like they showed, and then you can 13:17.100 --> 13:19.820 make it so that it can be toggled on or off. 13:19.820 --> 13:25.100 And then on all of your host, you just import that module's directory and toggle on the 13:25.100 --> 13:27.900 things that you want to be on. 13:27.900 --> 13:34.460 Um, so, okay, so this really saves you from, from having to keep track of, like, what 13:34.460 --> 13:35.460 code gets copied. 13:35.460 --> 13:36.460 Where? 13:36.460 --> 13:39.980 Because you just, it's just, it's just configuration, where it, like, you're just getting 13:39.980 --> 13:41.500 back to that same simple way. 13:41.500 --> 13:49.140 So, uh, where's the, uh, uh, uh, uh, uh, uh, we saw the services that you knew that enabled 13:49.140 --> 13:50.140 earlier, right? 13:50.140 --> 13:54.660 This allows you to, like, create something that simple for your own custom defined services. 13:54.660 --> 13:58.980 Um, and you've been available, where you can see at the top, I've got, um, some ports 13:58.980 --> 14:01.500 that I might allow myself to configure in the future. 14:01.500 --> 14:05.620 But I just, I sort of wasted those in case I wanted to make those configurable. 14:05.620 --> 14:09.220 Um, and we knew, use similar concept for Docker services, right? 14:09.220 --> 14:16.020 So, um, here's a Docker stack that, um, uses that make enable option, and then, if 14:16.020 --> 14:19.620 it's turned on, right, we're going to, oh, this code got kind of, garbled. 14:19.620 --> 14:21.140 Um, sorry, that's hard to read. 14:21.140 --> 14:24.260 I'll, I'll upload a get repo with, with better examples. 14:24.260 --> 14:29.140 Um, but yeah, this is similar if you step the way enabling portiner with some specific 14:29.140 --> 14:34.580 options, right, and then we're actually defining it as an OCI container that then gets 14:34.580 --> 14:35.580 enabled. 14:35.580 --> 14:38.300 Uh, yeah, that's an option. 14:38.300 --> 14:39.300 Okay. 14:39.300 --> 14:43.060 And then I, he said, uh, where I'm actually using tail skill now, so it's where I go 14:43.060 --> 14:44.460 under the hood. 14:44.460 --> 14:49.980 Um, if you do one user record, there's some documentation on the next, the next was website 14:49.980 --> 14:52.900 rate that shows how to configure it. 14:52.900 --> 14:53.900 It's a lot. 14:53.900 --> 14:56.460 It's actually like, a hundred or so lines. 14:56.460 --> 15:01.380 So I would recommend definitely like just copy that into a mix module and make it as easy 15:01.380 --> 15:03.020 as this, right? 15:03.020 --> 15:06.020 So if this is dot tail skill, about enable equals true, you can make your own little 15:06.020 --> 15:10.460 services dot wire guard dot enable equals true. 15:10.460 --> 15:14.500 Um, tail skill has a, this is another thing that just demonstrates the power of 15:14.500 --> 15:15.740 excellence, right? 15:15.740 --> 15:21.940 Tail skill has, um, pretty extensive documentation for how to set up like a router, right? 15:21.940 --> 15:25.740 So this is a thing that basically allows anything on the subnet that this host is on, 15:25.740 --> 15:30.180 to be advertised to the rest of my tail skill network or a wire guard network. 15:30.180 --> 15:32.540 Um, it's this, that, right? 15:32.540 --> 15:36.700 Like what all that can think that there is depending on, you know, how you're networking 15:36.700 --> 15:37.700 is set up. 15:37.700 --> 15:41.780 Well, in mix OS, you can ignore all of the tail skill documentation and just say, use 15:41.780 --> 15:45.540 routing features, both, which means that it's going forward. 15:45.540 --> 15:49.980 And it's going to accept, um, advertised routes from other posts. 15:49.980 --> 15:50.980 Okay. 15:50.980 --> 15:57.980 So real quickly, in one minute, lessons learned, um, I guess that I used to have a lot 15:57.980 --> 15:58.980 of hosts. 15:58.980 --> 16:02.700 And one of the things I kind of learned along the way was, um, like, I needed to build 16:02.700 --> 16:05.060 all of these things for myself, right? 16:05.060 --> 16:09.780 And, uh, part of what I was trying to do was avoid using Kubernetes, but it turned 16:09.780 --> 16:12.140 out I accidentally built myself a Kubernetes. 16:12.140 --> 16:17.260 Um, so keep it simple, since dramatically reduced the number of hosts, just so that 16:17.260 --> 16:20.700 I don't have to deal with that much proliferation. 16:20.700 --> 16:25.340 And I'm, um, for, for actual production workloads, I'm actually moving away from VMs and 16:25.340 --> 16:29.020 just running the XOS on their metal and keeping it simpler and not worrying about things 16:29.020 --> 16:33.700 like high availability because it turns out that the biggest downs, the biggest cause of 16:33.700 --> 16:37.700 downtime in my home lab is me messing with stuff. 16:37.700 --> 16:41.900 So the more I can separate things out into hosts that I just don't touch and they just 16:41.900 --> 16:46.580 do their job better, uh, and that gives me higher availability than a true replicated 16:46.580 --> 16:47.580 setup. 16:47.580 --> 16:51.540 Um, so yeah, like, you can use proxbox VMs. 16:51.540 --> 16:56.220 I think there's a great one you need to do a quick experiment, um, Nixon, microBMs are 16:56.220 --> 17:00.740 great for a quick test of something, um, and containers are great for workloads when you 17:00.740 --> 17:03.660 don't actually care about security or segmentation, right, because they're a lot later 17:03.660 --> 17:04.660 weight. 17:04.660 --> 17:08.660 Microwave VMs in Nick are also pretty lightweight, um, I actually do this when you have 17:08.660 --> 17:11.780 really tight coupling between the layers, when you're doing this stuff that you don't 17:11.780 --> 17:15.620 want to update often like a Raspberry Pi that's like sitting in a closet, this is my home 17:15.620 --> 17:17.620 lab version of an edge, right? 17:17.620 --> 17:20.900 Um, when you want to do really quick experiments, right, at this point, I've sort of developed 17:20.900 --> 17:24.700 like a whole host of templates and modules and things that I can really quickly turn 17:24.700 --> 17:29.980 on or off so that I can quickly test something against another tool, and, uh, you know, 17:29.980 --> 17:33.180 for a family of VMs, we're just like, I just need this thing to do with thing real quick. 17:33.180 --> 17:37.660 These are all great use cases for this, um, yeah, I don't think I've got time for questions, 17:37.660 --> 17:39.620 but come to the usacan.io, booth. 17:39.780 --> 18:02.540 So yeah, so TASKA needs a secret in order to get started. 18:02.540 --> 18:08.220 Um, so I have an Ansible Play that starts TASKA with my secret, but I'm still using, but 18:08.220 --> 18:12.220 So you could also use something like age next and actually encrypt the secret way in your next 18:12.220 --> 18:15.220 effect.