WEBVTT 00:00.000 --> 00:12.240 So, hi everyone, I'm going to talk today a little bit of the amortigration system D. I'm 00:12.240 --> 00:19.440 mostly talking about a bunch of loosely connected features. I'm a true half an hour is 00:19.440 --> 00:22.840 actually going to suffice to go through all the slides, but that's fine. We're just going 00:22.840 --> 00:28.240 to cover as many of the features that we can. The more important ones at the beginning, 00:28.240 --> 00:32.400 the less interesting ones are at the end, so it's certainly fine if we miss some of them. 00:32.400 --> 00:39.560 I usually like my sessions to be interactive, so if you have any questions, feel free to 00:39.560 --> 00:45.840 interrupt me and we'll get to answering them right away. I'm much prefer that we're doing 00:45.840 --> 00:52.160 with all the only at the end. So, yeah, I'm now part of the thing I work at the start 00:52.160 --> 00:58.560 of called Immutable, that we recently found it, yeah, let's jump right in. So, system D, what 00:58.560 --> 01:06.720 was that again? I mean, this is the VM devroom, so I guess system D is not really known for 01:06.720 --> 01:12.400 being a VM thing, but it's a very quick introduction, but I hope it's actually unnecessary, 01:12.400 --> 01:17.120 but yeah, it's a service manager, it's a system manager, I like it not only manager service, 01:17.360 --> 01:22.320 manager system at the whole, and you can see it as a collection of user space components 01:22.320 --> 01:28.480 and some of which we'll talk about in this talk. So, the first thing, system D as a guest, 01:28.480 --> 01:34.080 right? Like, so if you're on system D inside of the VM, there are a couple of nice things 01:34.080 --> 01:41.040 so it can integrate into the VM environment. The first one I want to talk about is, yeah, 01:41.040 --> 01:46.640 simple detection, if you're running in the VM environment. This is exposed in two primary 01:47.600 --> 01:51.680 ways. There's one tool called system D detect word, and if you run it, it just tells you, 01:51.680 --> 01:59.360 I'm running in QE, or I'm running in Hyper-V, or whatever else you have there, and there is 02:00.240 --> 02:04.080 connected to this. There's a unit file setting, it's called condition virtualization, 02:04.080 --> 02:08.640 which allows you to condition certain services to the VM environment you're running in, 02:08.640 --> 02:12.960 right? Like, so you can say basically say that the agent that is specific to some VMM, 02:12.960 --> 02:20.240 only runs inside of that VMM. That's very basic. Yeah, I think it doesn't really deserve 02:20.240 --> 02:25.520 much more explanation, but one thing I would like to know is that, yeah, if you hack on a VMM, 02:25.520 --> 02:30.240 in particular, one of the newer ones, the fancy ones that try to do very, very lightweight, 02:30.240 --> 02:36.960 please implement a mechanism so we can actually detect, but we're running in such a VM, 02:37.520 --> 02:44.960 usually this is done around CPUID, leaves like the specific one, and via SM bias or 02:44.960 --> 02:50.720 device tree, please make at least one of these rings available, because otherwise it's not realistic 02:50.720 --> 02:54.800 to detect that we're running in a virtualized environment. So much about the first thing I think 02:54.800 --> 03:00.480 it's very trivial. Well, let's talk about the second thing. It's a SM bias type 11 stuff. 03:01.200 --> 03:05.760 A ZM bias, I hope, does everybody have a rough idea? Does anyone have not an idea what a 03:05.760 --> 03:11.680 SM bias is? Oh, there are people. Okay, SM bias is this thing. It's like a relatively large data 03:11.680 --> 03:17.520 structure that has been around since bias times, like for long before you if I, which describes 03:17.520 --> 03:23.360 the system, and it's going to be like parameters of the system and passes that to the west, 03:23.360 --> 03:28.560 so that the west can figure out what kind of hardware is there and a couple of other things. 03:30.000 --> 03:33.680 It's the thing that you see if you type DMID code in your Linux shell. 03:34.400 --> 03:41.600 There's one particularly, a particular kind of object in there, which is SM bias type 11 objects. 03:41.600 --> 03:45.200 The type 11 objects, I think they're called vendor strings or something like this, 03:45.200 --> 03:50.720 it's basically a way how arbitrary stuff can be passed into a system. 03:50.720 --> 03:54.880 This is particularly interesting for VMMs rather than a physical device, 03:54.880 --> 04:00.000 because yeah, it's a way how they can parameterize VM, and a really, really efficient way. 04:00.000 --> 04:03.520 Right, because it's just a piece of memory passing. There is no, 04:03.520 --> 04:08.240 like I mean, the traditional way is how you provision a VM system with things like cloud 04:08.240 --> 04:13.120 and an IMDS and an emulated city on drive, so it's all horrible and slow required as the 04:13.120 --> 04:18.560 HCP and is like this massive stack of things. This one's super easy, right? Just some memory 04:18.560 --> 04:24.000 to pass through there. There are free form vendor strings, the ones that a system needs 04:24.000 --> 04:28.400 have a specific form. We'll come to that, but yeah, they are just memory, they're simple, 04:28.560 --> 04:32.400 they're fast. If you want to use them with key, when you just type something like this, 04:32.400 --> 04:38.400 it basically just says, yeah, set another SM bias type 11 object. The value here is IOD 04:38.400 --> 04:42.800 or system need a credential that's simply like how we want them to be formatted so that 04:42.800 --> 04:48.960 system consumes them, they can assign variable food to value bar. For user space, like from 04:48.960 --> 04:52.800 inside of the VM, they show up in a system as file and we can just read this and that what system 04:52.880 --> 05:00.720 it does. There are a couple of them that system defines by default, like the bootloader, 05:00.720 --> 05:04.960 like system to boot for example, allows you to select an additional kernel command line options 05:04.960 --> 05:10.000 or additional boot entries, even the boot menu, or you can tweak the log level with that, 05:10.000 --> 05:14.640 the bootloader has so you can actually see things, can configure the time out and think like this. 05:14.640 --> 05:20.800 Most interesting one is this one, IOS system, the dot credential, which allows passing in 05:20.960 --> 05:27.280 system credentials to the VM. That's a really powerful feature, like that two ways I can do this, 05:27.280 --> 05:33.440 either like there's a simple text form, or there's one that takes base 64 so that you can 05:33.440 --> 05:38.000 pass it arbitrary stuff. To understand what this actually does, let's have a small 05:38.000 --> 05:43.520 admission here about system e-credentials. This is a decredentials as a concept we introduced a 05:43.520 --> 05:48.720 couple of years ago to system the, which is how you're supposed to parameterize the system 05:48.720 --> 05:54.800 as a whole and the service is in particular. It's our answer, you know, the web world likes to 05:54.800 --> 05:59.280 parameterize the containers with environment variables and I think it's a really stupid idea 05:59.280 --> 06:05.600 because they are by default propagated and there's no access control on them, like everybody can 06:05.600 --> 06:11.200 read them and it's just a terrible way to propagate secrets because it's very, like by default, 06:11.200 --> 06:18.240 propagated and very open. So we created this alternative. It's basically small pieces of 06:18.240 --> 06:25.360 information that like we expose ultimately as little files and can carry both secrets and regular 06:25.360 --> 06:32.560 data. They inhabit, in heritable down the tree, like she can inherit them from a host and to a service, 06:32.560 --> 06:39.360 but you can also, from a container manager via that, m into a host and to a service so you can just 06:39.440 --> 06:45.600 propagate it always further down the tree. We define many of them that are well known, like every 06:45.600 --> 06:49.760 service kind of find their own, but a couple of them we define as the vocabulary that always 06:49.760 --> 06:55.200 system the understands. One for the root password for the host name and he thinks like everything 06:55.200 --> 07:02.240 you kind of want. From the service point of view, they show up in a special directory where you get 07:02.240 --> 07:07.200 a environment variable which tells you, look in this directory and you find the files and they'll 07:07.360 --> 07:13.680 have that name. They also have, yeah, so the propagation is always opt in as opposed to environment 07:13.680 --> 07:20.240 variables where the propagation is usually by default and access modes apply. Meaning that, yeah, 07:20.240 --> 07:27.520 the we when we a service gets a credential passed in, we'll make sure that these files are locked 07:27.520 --> 07:31.920 down to that only that service under its user ID can access them and not every everything else. 07:32.880 --> 07:39.920 It also has a hook up to the local TPM so that you can have authenticated credentials like 07:39.920 --> 07:45.920 you can have them encrypted address, you can pass them in to your VMM encrypted, but the moment 07:45.920 --> 07:50.080 the service that it's actually supposed to consume them is activated will unlock them and pass 07:50.080 --> 07:55.760 them to the service and play text. It's our answer to, yes mentioned, environment variables 07:55.760 --> 08:00.720 into these awful provisioning systems that are everywhere like clouded and sync like this, 08:00.720 --> 08:07.760 which have these massive stacks of things. This one is really simple, really like clean in a way 08:07.760 --> 08:13.040 and has all these nice properties that we like. But this was just an information, right? 08:13.040 --> 08:17.520 So if you take the SM files type of live and stuff, you basically that's now way how you can 08:17.520 --> 08:22.640 pass into VM, all these kind of settings, naturally an any system system already out there 08:22.640 --> 08:28.400 and we'll consume them and set a root password and whatever else. Next thing, any question to this point? 08:28.960 --> 08:35.440 No, okay, so the next thing is SD-95 style notification. So SD-95 is a concept in 08:35.440 --> 08:41.040 system deep how originally services could tell the service manager, like system deep, 08:41.040 --> 08:46.400 that they have completed initialization. So this is required to 08:46.400 --> 08:51.840 have a clean boot up, right? Like where one service is started and then another service is started 08:51.840 --> 08:55.440 that might depend on the first one, you need to synchronize this properly so that the first one 08:55.440 --> 08:59.440 has finished thought up so that it is connectable so that the second one that wants to connect 08:59.440 --> 09:04.960 it can do this. So we created SD-95 for this is it's an extremely simple protocol basically 09:04.960 --> 09:10.160 where the service just receives an address of an a-funic socket and then the service just sends 09:10.160 --> 09:16.560 a message to this. It's so basic and so simple and I think an allergen that we just decided to 09:16.560 --> 09:22.640 extend this so that we can also do ready notifications of the VMs as a whole. VMs of course do 09:22.640 --> 09:29.280 not have a a-funics, they have a a-v-zock. So this is what it really is. Like we have like the VMM 09:29.280 --> 09:36.000 can set up an a-v-zock, a socket listen on it and then the payload can send a message when it's ready. 09:36.000 --> 09:42.480 It's extremely powerful. The way how a VMM would communicate this to the payload is by 09:42.480 --> 09:47.840 again setting a system credential. The ones we were just talking about is called VMM.notify socket 09:47.920 --> 09:54.560 and just sets the CID like the a-v-zock address that shall be a cell receives a message and 09:54.560 --> 10:01.440 then we'll connect it and send the the message. This is not just a lot simple ready notification 10:01.440 --> 10:06.400 just about like like as you might think that it will just report when the boot of is complete. 10:06.400 --> 10:12.720 It actually sends up a lot more because it will tell you about like how far the boot has already 10:12.800 --> 10:18.960 progressed. Specifically there's one message that is sent if you have SSH for a sample us up because 10:18.960 --> 10:23.280 for many use cases all you need right like you want to know the moment where you can connect via 10:23.280 --> 10:29.920 a-v-zock to the VM via SSH. We also announce a little bit of meta information there like the 10:29.920 --> 10:34.960 host name machine ID. So this which is sometimes really nice because that means that the VMM 10:34.960 --> 10:41.520 is not as much as the black box to the host anymore but they I mean typically they know the CID 10:41.520 --> 10:45.520 of the VM but with this they also know the host name machine ID really basic information. 10:47.120 --> 10:52.800 There's also announced is a shutdown detail right like when the system goes down again we can 10:52.800 --> 10:57.920 propagate something like an exit status of the VM so the VM starts to feel a bit like a classic 10:57.920 --> 11:02.080 process where you can do exit seven or something like this and this propagated up to the VMM and 11:02.080 --> 11:06.560 can see this. There's also like you know the Linux says this reboot string that you can have 11:07.120 --> 11:12.240 which is used by eminent hardware usually but we generalize this and also propagate this up so that 11:12.240 --> 11:19.200 if you have a VM the other also ends up so it's like a textural form of of an access status that 11:19.200 --> 11:24.000 that you can propagate to the VM of VMM. Questions at this point? 11:24.000 --> 11:32.560 The question was regarding how this information is accessible in the host well the VMM receives 11:32.560 --> 11:38.640 it and how the VMM makes use of this is up to the VMM right so my assumption is which is 11:38.640 --> 11:42.960 provides some API but that's specific to the VMM outside of the scope of systemy. 11:44.640 --> 11:51.520 The next thing is systemy as a guest is we recently added the same where if we like there's a 11:51.520 --> 11:55.520 little generator and systemy generator are these little binaries that can basically extend the 11:55.520 --> 12:03.120 dependency tree of systemy dynamically and locally based on configuration or based on what's 12:03.120 --> 12:08.640 available. There's one that checks if AFV is available like if you're running in a VM where 12:08.640 --> 12:14.240 AFV is enabled then also checks if the SSHD binaries are running in if so it automatically 12:14.240 --> 12:20.080 binds SSH to AFV is. It's extremely simple it's extremely powerful because it basically means that 12:20.160 --> 12:25.360 if you're running VM and you just enable AFVsock you can just connect it without any kind of 12:25.360 --> 12:34.000 network configuration it's very fast very simple it's as secure as SSH is secure and it makes it 12:34.000 --> 12:40.640 so much easier to debug things because you do not have to rely on the unreliableness of of 12:41.440 --> 12:48.560 networking to be able to talk to your VM. And remember we have notifications when SSH is up right 12:48.560 --> 12:54.640 like so you can make use of this without anything like as long as UVM has SSHD around as well and as 12:54.640 --> 13:00.640 long as you enable AFVsock you will get another location basically help it's connectable now 13:00.640 --> 13:04.880 and also remember via the credentials stuff you can also provision SSH keys into the VM so yeah 13:04.880 --> 13:12.640 really really nice way very simple way very fast way how you can configure the SSH inside of it 13:12.640 --> 13:20.640 get notification when it's ready and connected just to make a point here none of this like 13:20.640 --> 13:25.600 the automatically disabled all this logic and confidential computing because then it's more 13:25.600 --> 13:30.080 complicated situation which should maybe not make all this stuff available so that the VM 13:30.080 --> 13:36.800 can basically control access to the VM so the provision says there so that we don't do this the 13:36.800 --> 13:42.400 so we only do this basically if the trust model is the traditional one where the payload has 13:42.400 --> 13:49.760 to trust the VM and then full. Any question at this point okay one more thing here. 13:50.560 --> 13:54.320 SystemD boot you know it's that bootloader of systemD or it's it's actually more of a boot menu 13:55.520 --> 13:59.760 the support has been added to to make it possible to embedded in the UFI firmware 14:00.400 --> 14:06.000 that's really nice because it means that the images that you boot inside of the VM do not have to 14:06.000 --> 14:10.320 contain any bootloader anymore but you still get bootmen you get boot counting you get all this kind of 14:11.280 --> 14:17.120 interactivity but also control an API towards the bootloader pick something without actually having 14:17.120 --> 14:22.080 to include that in the image. This is like the way how you use it risky when you just pass 14:22.080 --> 14:27.360 it by dash kernel and specify the the EFI binary it's not a kernel right it's just how 14:27.360 --> 14:33.360 you can expose this. It will still search the ESP for kernels and boot for minutes it's actually 14:33.360 --> 14:39.200 very nice because that makes means that they discover that the insert just really has to have 14:39.200 --> 14:48.480 the UKI and the root file system. Any question at this point? Next thing you know when you 14:48.480 --> 14:53.280 deal with VMs you also want to have logging so a system to journal which is like the logging 14:53.280 --> 14:59.360 for a framework of system he has this option called forward to suck it initially it was about 14:59.360 --> 15:03.760 forwarding log out for automatic to some IP address but you know what it actually also supports 15:03.760 --> 15:09.440 a WISOC these days. So this is very simple very natural way how you can get live access to the 15:09.440 --> 15:13.600 logs of the VM and you can configure this again via system to credential so you can basically 15:13.600 --> 15:18.720 start a VM and say I want my logging to get out on this AVISOC and you immediately see everything that's 15:18.720 --> 15:26.320 happened. It's simple it's nice it's very efficient very fast very early in boot I mean it's not going to 15:26.320 --> 15:31.200 cover the kernel stuff I mean not at least lives the kernel stuff because after all this is a 15:31.200 --> 15:38.080 journal configuration will only get into effect one's journal these up but yeah. Question at this point? 15:38.640 --> 15:45.520 No. Next thing you system repart this is like this dynamic partition thing and system 15:45.520 --> 15:49.840 need so this one didn't really have any thing to do with VMs but I think it's very useful when 15:49.840 --> 15:55.360 you deal with VMs to know about this system repart is a dynamic repetition and this is particularly 15:55.360 --> 16:01.120 useful in VMs because very often you have like a golden image that you deploy on VM and 16:01.120 --> 16:09.520 then boots up and sets up the disk but sizing the disk is something that shall happen locally 16:09.520 --> 16:14.160 on the individual node way to deploy the thing which system repart you can do is very easily because 16:14.160 --> 16:19.440 it basically means that you can just have to increase the size of the host and they can 16:19.440 --> 16:26.080 let the system repart to the rest where you bump up like it goes the file systems are just 16:26.080 --> 16:33.440 going to create them with keys that are specific to the boot of that VM and things to the actual 16:33.440 --> 16:39.040 disk that you provide it to the VM it's really nice. Again this is not strictly using any VM 16:39.040 --> 16:49.600 concept but it's extremely useful in VMs. Question at this point? The question was regarding which 16:49.600 --> 16:54.080 file systems and it's a typical Linux file system xd4 interface and all these kind of things. 16:56.160 --> 17:05.200 So the question was regarding if it also covers LVM? No. Not a fan of LVM. 17:14.240 --> 17:18.800 What is the question was regarding what is expected from the petition layout of the image that is 17:18.800 --> 17:24.640 booted? Well it has to follow the boot the discoverable image specification which is something 17:24.640 --> 17:29.280 that we put up on your API so you basically have to tag and you don't directly have to that but 17:29.280 --> 17:34.160 it gets very painful if you don't but you have to tag your petition as this is a root file system 17:34.160 --> 17:43.840 for x86 or something like this but it's very like if you are preparing the ms in 2026 there's 17:43.840 --> 17:49.920 a good chance they will be put together like this anyway. Next topic it's second with auto and 17:50.880 --> 17:58.880 if you run a VM and sometimes useful to have like this tofu concept where the image that you 17:58.880 --> 18:05.360 boot you just accept but then you want to want that in specific VM instance so that from that 18:05.360 --> 18:10.320 point on it's only this image that boot inside of the VM and nothing else. And system that we have 18:10.320 --> 18:14.800 since a while a concept of auto and rolling of circuit boot that basically means that if you boot 18:14.800 --> 18:21.280 up a VM was a UFI circuit boot set up mode then the boot loader that we have system to boot 18:21.280 --> 18:29.840 can automatically enroll a key in the db like in the keyring of a circuit boot. Lots of system 18:29.840 --> 18:35.200 down reboot and then goes through. This is extremely useful in VM environment it's not so useful 18:35.200 --> 18:39.600 in physical devices because in physical devices replacing a circuit boot pieces kind of problematic 18:39.600 --> 18:45.360 because you don't know necessarily what kind of hardware you have and if there is a I don't 18:45.360 --> 18:50.640 know Nvidia card in there that really requires signed firmware drivers and then if you kick out 18:50.640 --> 18:56.000 the keys and everything breaks but in the m environment it's very very simple very robust because 18:56.000 --> 19:01.200 yeah the VM m controls what the firmware is and it's typically very simple there are no 19:01.200 --> 19:06.560 extension cars nothing so it's a it's a really lovely concept right like so for me if you prepare 19:06.640 --> 19:10.240 this image you just have to put the circuit boot signing keys that you want to be added in 19:10.240 --> 19:14.640 a special directory and then when a system would seize them and we'll just and figure out that 19:14.640 --> 19:18.720 the system is in setup mode so that it kind of rolled them and we'll just enroll them and reboot 19:18.720 --> 19:23.920 turn off circuit boot set up mode and then you're locked down. It's something I can just recommend 19:23.920 --> 19:31.600 everybody to just do like it's so simple if you build an image just do this because I mean 19:31.600 --> 19:36.080 I personally believe that the value of circuit boot is relatively limited but in this case is really 19:36.080 --> 19:42.800 nice because it's so easy to do and it basically means that you walk down with the m to the 19:42.800 --> 19:48.320 payload that you passed it and if an attacker gets access to the m they cannot use a completely 19:48.320 --> 19:55.280 different payload like I don't know it's install so it's just because fedo I was first booted. 19:58.400 --> 20:05.040 Question at this point? Okay there's more there's a hook up with cocoa I'm not going to go 20:05.040 --> 20:08.560 into this hopefully soon we'll have like the generation ID so that system actually has an 20:08.560 --> 20:15.040 instant and an understanding of when snappers are made and things like this but yeah this doesn't 20:15.040 --> 20:21.040 exist right now. Next I'm going to cover a couple of topics not so many about a systemly on a host 20:21.040 --> 20:26.560 meaning that yeah you have VMs running on the host below the host and what systemly provides 20:26.560 --> 20:32.800 to make it nice. Interfacing with this the first one is something called systemly SSH proxy 20:32.960 --> 20:41.840 it's a trivial proxy for SSH so that you can actually connect via the SSH client to a VM that has 20:41.840 --> 20:48.480 a v-lock and has SSH listening and it's basically the other side from this SSH generated I was 20:48.480 --> 20:54.240 talking earlier about because SSH natively has no clue about how connecting to a v-lock works 20:55.120 --> 21:00.720 on this add this in it's called proxy it's actually not really a proxy proxy kind of suggests to me 21:00.800 --> 21:05.360 that it would actually shift bites around doesn't do this all it does it's a very very short 21:05.360 --> 21:12.480 lift and is a way how you can tell SSH basically when you connect in a v-lock it will return the 21:12.480 --> 21:17.600 actual transport socket back to SSH and from that point on it's out of the loop and just exits 21:18.720 --> 21:23.040 so yeah name is misleading the reason why it's called that way is because SSH names the 21:23.120 --> 21:30.240 that way not because what make any sense it's enabled by default if you have a current systemty 21:31.600 --> 21:37.360 question no question there's one more thing we recently added something called systemly and as 21:37.360 --> 21:44.160 resource the it's basically I mean it does a couple of things like the main purpose of the tools actually 21:44.160 --> 21:50.400 to hand out a username space well I mean you give in the username space which is this Linux 21:50.480 --> 21:54.480 isolation thing that's mostly interesting for containers again it's also interesting for the 21:54.480 --> 22:00.320 ms but it's yeah people don't think so much about it there and it gets a user ID range assigned 22:00.320 --> 22:04.640 but one of the things that you also can do it's can then if you have that assign an app work interface 22:04.640 --> 22:11.280 to it and allow this for unproveletch clients so it's it's very simple while you just do an IPC 22:11.280 --> 22:16.000 call and you get a follow-up to a tap device and then you can pass that to key email and it just works 22:16.640 --> 22:21.040 and there's network d behind it so you actually get an DSCP address and things like this 22:21.040 --> 22:24.640 it's my personal answer you know they're like people always do like with key email like this 22:24.640 --> 22:29.760 user space networking so that they have unproveletch reactions and things like I fucking I don't like this 22:30.480 --> 22:35.600 but this is like our alternative to this you actually get real networking real DHCP was routing 22:35.600 --> 22:42.560 and stuff like this and just works the back end of the networking practice system network D built on DHCP server 22:42.640 --> 22:48.080 blah blah blah blah blah a result is solution as well right like so if you if you have a name 22:48.080 --> 22:52.640 assigned to your VM then you can actually resolve things of the appeared versus go go there 22:55.920 --> 23:01.920 so the question was regarding if we can also do the dynamic VTAP I think I edited for I feel like 23:01.920 --> 23:07.440 I added for one more I don't actually remember which one but if it's if you needed it's 23:07.440 --> 23:12.080 trivial to add right like because we have the code anyway it's just talking them up also an 23:12.240 --> 23:18.080 resource team then this is kind of the last thing I want to talk about that's also 23:18.080 --> 23:23.520 system the machine which simply keeps track of your local machines just I mean it's also 23:23.520 --> 23:28.080 tracks containers but it basically just maintain the list it's very simple it's just you 23:28.080 --> 23:33.360 were just your stuff was it and that makes things like the CID like the AFVs are adders and 23:33.360 --> 23:39.040 think like this available to systemly and we can use it for various things for example system 23:39.040 --> 23:46.240 SSH proxy then can ask that thing for a name so that it can find the CID so in a way it's 23:46.240 --> 23:51.840 acts a little bit like the DNS but for AFVsock on an in a local scope but it's also kind of 23:51.840 --> 23:55.600 interesting because it means then when you can do PS with some options you actually see like 23:55.600 --> 23:59.680 which key move instance actually belongs to which VM it's like this so the less tracking there 24:01.280 --> 24:05.920 this is the very last slide with content any point question at this point I'm kind of impressed 24:05.920 --> 24:10.400 that we actually managed to go through so I didn't expect that this is the last thing like we 24:10.400 --> 24:15.040 added something called system VM star is born to systemly while back we mostly did this for our 24:15.040 --> 24:19.520 own testing stuff because you know all the stuff that I was talking about earlier we got in 24:19.520 --> 24:25.360 integration as these credentials and things like this if you use rock you email you always have 24:25.360 --> 24:30.480 to put together these complicated command lines it's not user friendly it's very you can do it 24:30.480 --> 24:36.080 but it's requires a lot of typing with system the VM spawn what we did is I'm not sure if you 24:36.080 --> 24:40.240 guys know system the n spawn which is like this little container manager that we have in system 24:40.240 --> 24:45.120 d and I don't know I like using it it's like the interface that well I wrote it so 24:47.120 --> 24:51.840 I'm used to that thing and I think it's very user friendly so system VMs won't just 24:51.840 --> 24:58.240 exposes the almost the same interface but it actually just folks off key and does all the parameters 24:58.640 --> 25:02.000 if you want to do ss h stuff and credentials and things like this it will just do the right 25:02.000 --> 25:07.200 thing for you hide all this and just rep a q e-mail register it nicely and things like this so 25:08.560 --> 25:13.680 yeah use it it's mostly not for like production stuff it's mostly for local stuff and that's it 25:15.760 --> 25:19.280 do we have time for question no it's questions one two questions 25:20.240 --> 25:24.880 as a question sorry I don't 25:39.520 --> 25:43.040 like the question was regarding if we can take the a a view of support that we have in 25:43.040 --> 25:45.680 journal d and things like that and make it available for any networking stuff 25:46.640 --> 25:51.840 I mean a system d has it like the socket unit concept and it can listen on a view of 25:51.840 --> 25:58.400 unique sockets and it can listen on IP sockets but it can also always since years it has been 25:58.400 --> 26:03.280 able to listen on a view of sockets so if your application is generic enough that it doesn't 26:03.280 --> 26:08.480 really care about the family ss hd for example is like this then yes you can just use it in 26:08.560 --> 26:12.640 total generic and find anything to it like like a shallow whatever else was another question 26:14.800 --> 26:16.800 sorry I don't 26:22.640 --> 26:28.480 so the question was regarding a system d as a guest if it can be used without root 26:29.680 --> 26:35.520 like I mean if you want to run system d inside of the m but not give the m root I don't understand 26:35.600 --> 26:44.080 the question because yeah 26:47.280 --> 26:52.320 okay so if the like the the functionality that we provide inside of the guest is that can 26:52.320 --> 26:55.520 me like this really depends on what you're talking about like connecting outside 26:57.040 --> 27:03.600 like mostly yes depending on what the kernel policy or things are like on on Linux 27:04.240 --> 27:08.240 like everybody can bind if you like but I don't have any time anymore if you have further questions 27:08.240 --> 27:12.240 let's do the south side thank you very much