WEBVTT 00:00.000 --> 00:15.400 Take it away. Thanks. Thanks everyone. Welcome. Let's talk about how to go through 00:15.400 --> 00:24.120 the network attached device using Make-O-Sign InterD. The contents would be first of 00:24.120 --> 00:31.680 very brief, mandatory interaction about what are in the interface and why we need them. 00:31.680 --> 00:38.680 Then a very brief mandatory interaction about Make-O-Sign InterD. Then how to translate 00:38.680 --> 00:48.120 the missing functionality in Make-O-Sign InterD using Drake with us a reference. Finally set 00:48.120 --> 00:54.760 up the network using an Apple Manager and two proofs of concept showing how to root 00:54.760 --> 01:05.000 from using NFS and I discuss it. So let's start by introducing myself. My name is Antonio 01:05.000 --> 01:14.120 Albert Féjo and I work at Sousa on the system but I need them and I work mostly on maintaining 01:14.120 --> 01:21.120 it. I re-related topics. This is the currently integrated and open Sousa and Sousa 01:21.120 --> 01:29.400 distribution which is Drakehood and to allow us to understand helping with the system. 01:29.400 --> 01:37.560 So now come on. Usually scenario we start power up after that the firmware does minimally 01:37.560 --> 01:44.120 in the service station. Then it has the controller to bootloader, to bootloader, loads 01:44.120 --> 01:52.680 into memory, a kernel and one or more in the 30 images and then involves a kernel. The kernel 01:52.680 --> 01:59.520 mounts the unit area in the memory of the system. Then it has the controller to it. The 01:59.520 --> 02:05.800 unit area looks for the real root file system and once found and mounted has the controller 02:05.800 --> 02:17.880 over to the host system manor. So let's focus on the unit area part. It is a CPR type. It 02:17.880 --> 02:26.000 can be compressed with the optional. There may be more than one unit at this which will 02:26.000 --> 02:34.120 be concatenated by the bootloader and also, when the system is around, it can be the PID-1 in 02:34.120 --> 02:46.120 the unit area. So the intergenerators, most use, are very good in the RAMFS tools and making 02:46.120 --> 02:54.720 it CPR. They all have in common that pick files from the host system and also they add 02:54.720 --> 03:05.200 custom logic to the good process. We will talk about this custom logic in more detail later. 03:05.200 --> 03:15.240 Then for years ago, it's basically just a smag with this idea of building the interiors. 03:16.200 --> 03:22.680 Make a sinitary, it's a wrapper on top of the make a side, make a size, an image builder. It creates 03:22.680 --> 03:29.400 various types using this between packages, package managers and their dependency resolution 03:29.400 --> 03:39.160 mechanism. So it does not pick files from the host system to be the interding. Well, there 03:39.160 --> 03:44.520 are two steps, because by default it includes the load that kernel modules from the system. 03:45.720 --> 03:52.280 And also it can include other files if the user wants, if it is configured to the so. 03:53.320 --> 04:00.760 And it does not have custom logic to the good process. Right now, that's in a set and a 04:00.840 --> 04:07.880 exception, we do that rules, but already a percent will be in 2 and 80 and the end. 04:11.400 --> 04:20.760 So let's share what I think that are the most important benefits of this approach. 04:23.480 --> 04:28.440 It will sinitary is out of distribution packages, so the source is known beforehand. 04:29.400 --> 04:37.560 It is easy to reproduce, it can be built of host. It is less complex, because ideally, 04:37.560 --> 04:44.120 you have to choose only packages and carry modules. And distribution can provide to the fine 04:44.120 --> 04:53.560 configuration sets to ship specific functionality. We have a clear and a super PACs and it stands 04:53.560 --> 05:02.120 in fails. It should be someone else's fault. For example, if LDN2 files to scan devices in the 05:02.120 --> 05:12.360 inner terde, it should be fault of LDN2 and not because of the inner generator. And any change 05:12.360 --> 05:19.800 from a package will automatically apply to the inner terde, because make a signitary is not adding 05:19.800 --> 05:30.680 custom logic or picking what files from each package will be included. And also, it fits the 05:30.680 --> 05:34.200 maintenance effort from the inner terde, and it is available to the responsible packets. 05:40.200 --> 05:46.120 So what's not so nice, it is fragile to packaging errors. In it does this serve 05:47.000 --> 05:56.760 using more than 100 packages, but on the hand, I will narrow the three and users. It can be 05:56.760 --> 06:07.800 a little detected. And in it the regeneration can be as low, but in proofs, it is because it 06:07.880 --> 06:15.640 uses package manager gases if enabled on the host. The size of the inner terde is large. 06:18.360 --> 06:28.440 There are two approaches to work around this. One is fixing the packaging. For example, 06:28.520 --> 06:36.680 the splitting packages which are very big into the packages like with GLC, with the locals and 06:36.680 --> 06:44.360 us with packets. And the other approaches using the removed files configuration. 06:45.720 --> 06:54.520 And in open system, we were shipping a file, a configuration file, which is the moving 06:54.520 --> 07:00.840 things are needed in the inner terde, like hand pages, cell completions, etc. 07:03.240 --> 07:10.120 And also, I would like to support all the executors in 64 and R64. 07:12.360 --> 07:22.760 And the last thing is intended only for hostility in it. I mean, the funny thing is no hostility 07:22.760 --> 07:31.160 is available with the inner maker side program, but there was an attempt to add hostility 07:31.160 --> 07:43.000 switch and it was rejected. So, how to implement this in functionality in maker as an iterative 07:43.000 --> 07:50.840 for that, I would use a drake with a reference, drake has been around the previous 15 years or so, 07:51.960 --> 07:58.680 and it is the most widely used in the early generator and it works quite well. 08:00.600 --> 08:11.080 So, first thing I did was create a personal fork. So, there I could remove everything I didn't 08:11.160 --> 08:23.400 need, like, no system in the code, unnecessary messy options. And after this cleanup, I could focus 08:23.400 --> 08:33.480 and understand more easily how the functionality is implemented in difficult modules. 08:33.480 --> 08:46.280 So, ideally, I would like to translate every drake with functionality into maker side configuration. 08:47.800 --> 08:53.320 So, maker side configuration can consist of any teleconfiguration files 08:53.640 --> 09:03.880 and extra custom file system to this. And this custom file system 3 is allowed to have an 09:03.880 --> 09:10.920 intermediate state between getting things working and send them to the right up history. 09:11.160 --> 09:24.360 So, how to translate drake with modules into maker's configuration. First, how to identify things 09:24.360 --> 09:35.640 that in every drake with module. Identify binaries, units, libraries and at the packages that provide 09:35.800 --> 09:42.280 them, identify stock and modules and do the same thing at the kind of modules in configuration. 09:43.160 --> 09:51.640 Identify hooks, we will talk about hooks later, but hooks are, as functionality that drake 09:51.640 --> 09:59.320 provides to allow to run a custom sweep at certain point in the good process. 09:59.960 --> 10:08.200 So, how to rework this scripts to be independent of drake with lip, other service in makers 10:08.200 --> 10:14.760 I actually ordered like a drake with dash hook service, pointing, actually started to this script 10:14.760 --> 10:23.560 and then after working, I'll send to the right place. And finally, identify custom system 10:23.560 --> 10:31.480 in the units with every rules, binaries, check if they are required. First, save them in makers 10:31.480 --> 10:41.320 I extra, then, opposite. So, we know how to solve things and what about the custom logic? 10:41.560 --> 10:52.280 We will analyze these six points in the tail, break points, break points, start carrying 10:52.280 --> 10:58.840 common line options to pause, to stop the good process at certain point and drop to work interactive 10:58.840 --> 11:07.320 shell. This is basic for the paving and alternative will be implemented directly in 11:08.200 --> 11:13.960 this is already done and will be included in the next system liberation. 11:15.640 --> 11:21.160 And the good thing about this is now we can stop the good process at the switching route 11:22.440 --> 11:31.880 without the dot press. Next, pass the kernel from a line for that drake provides 11:32.680 --> 11:38.360 pass functions, but the alternative will be that the pack just can provide a binary to this one. 11:39.240 --> 11:42.200 And for example, network manager is already doing that. 11:46.600 --> 11:55.320 Extending a slush plot in the line with files in configuration and drake allows to 11:55.320 --> 12:03.240 extend the kernel command line not only when it builds territory, but only when the system is 12:03.240 --> 12:09.880 booting. And alternative, since this will not be spot by extended, 12:12.040 --> 12:20.840 the only option that I can pick off is use the what the bootloader allowed to define is 12:20.840 --> 12:34.360 that really. Next, hoops, hoops are points that allows to inject and run 12:34.360 --> 12:41.080 externally sweep at certain points in the good process. Also can be injected at build or 12:41.080 --> 12:48.040 while resisting is booting. And drake with the south source, this is creeps during the 12:48.040 --> 12:54.440 build process using its custom drake task system researchers. So the alternative will be 12:55.000 --> 13:03.240 instead of asking drake to run as creep. Packages can provide their own system researchers properly 13:03.240 --> 13:14.440 over. Next, the unit queue. The unit queue allows to wait until all the necessary hardware 13:14.520 --> 13:22.680 has been discovered because the hardware detection is asynchronous. So drake could implement 13:22.680 --> 13:30.920 a blocking loop with several hoops. And it loops until you get a set of and all the 13:30.920 --> 13:38.840 clips in the queue finish straight on through. The alternative is thinking about 13:39.480 --> 13:48.440 ordaining after system users settle would be wrong. Because there is no, we don't know when 13:48.440 --> 13:55.560 the hardware would be ready. So the better alternative would be, not services can subscribe to 13:55.560 --> 14:03.400 you that I haven't seen react when and you hardware is discovered. Using the listening net 14:03.720 --> 14:12.760 property and subscribing to AFK link you have some current events, system in that will be 14:13.480 --> 14:18.760 is doing something similar. So it's a good example of that. But maybe we need to implement 14:18.760 --> 14:27.960 something like this in the future. And the last one is unpacking a load in the 14:28.600 --> 14:36.600 shutdown. This allows to perform plan ups using two special hoops for take with modules. 14:36.600 --> 14:44.360 The alternative is that this is already available in system this shutdown. We can run 14:44.360 --> 14:51.160 a scripts located in this directory. And for example, in the again, it's already 51. 14:52.120 --> 15:02.600 Okay, let's start with the main part of this talk. To put from an appuratized device first, 15:02.600 --> 15:09.960 we need to set up the network for that I chose the network manager because it's the network 15:09.960 --> 15:17.400 100 I use. Although I think that the system the network is should work out at the top. 15:18.360 --> 15:26.120 So first, identify packages, network manager at least. Identify code modules, 15:26.120 --> 15:33.400 makers are in a terriat, currently loaded network modules. If we need more, we have to set 15:33.400 --> 15:40.600 that in configuration. And then analyze what tray could you do in a custom logic. 15:40.600 --> 15:50.360 It's installing a custom configuration file. Then it has two custom system services. The first 15:50.360 --> 15:57.880 one is to set up the network. The second one is already out to the first one and checks whether 15:57.880 --> 16:06.760 we are online. So we will keep both. And also, he installs one hook once in the live hook to 16:06.760 --> 16:13.160 parse the coordinate command line. The good thing is that the binary that he's using is already 16:13.160 --> 16:21.880 provided by the network manager. So we can ship a service properly over calling this binary. 16:23.000 --> 16:28.680 Although I think that maybe a system is in a relatively better instead of regular service 16:29.560 --> 16:37.320 to parse the kernel command line and affect the file unit, okay, depending on that. But for now, 16:38.040 --> 16:46.760 I think this like tray could be. And also, reduce the scope. Use only the network manager 16:46.760 --> 16:55.240 in penalty HP client. So this new services will be order the first one right up to the boot 16:55.320 --> 17:01.560 and before you there parse the carrier command line. We set up the network between network 17:01.560 --> 17:08.040 pre-target and network target. And we said whether we are online between network target 17:08.040 --> 17:18.600 and network online target. So the picture will look like this. We have the configuration file 17:18.600 --> 17:23.880 with the pack to define. If we need more kernel modules, we have to add then there. 17:25.480 --> 17:31.960 And the custom functionality should be up streaming to network manager. I have already 17:31.960 --> 17:39.240 opened a match request and the first feedback was very good. They know they are the best 17:39.240 --> 17:46.680 spontaneous for this functionality. So hopefully it will match soon. And after that, even tray could 17:46.760 --> 17:58.840 be patched to use these services instead of their own custom services. Next, NFS, the same process. 18:00.120 --> 18:08.600 Identify packages, NFS client, live NFS ID map, RPC blind. Identify kernel modules, 18:09.560 --> 18:18.040 the NFS NFS tree, NFS HGLKO, and net sum RPC. And then what tray could 18:18.040 --> 18:25.640 do in a custom logic? It still sim the line hook to parse the carrier command line and also 18:25.640 --> 18:34.280 a few depth hook to start RPC. So I will match both into a existing service order before you 18:35.080 --> 18:46.120 have. Next, NFS root is clip, which actually is the one from Mount NFS. And I would 18:46.120 --> 18:54.440 rate a match in service for that. And finally, a plan up hook to perform plan ups before switching 18:54.520 --> 19:02.280 root. So these new services will be ordered right at, right at the good, 19:02.280 --> 19:11.000 parse the kernel command line and start RPC before you there. After Nargot of Night Target and 19:12.440 --> 19:22.200 remote FS target Mount NFS and right before switching root, profile plan ups. 19:25.080 --> 19:33.080 So this is the whole picture, new staff in blue. We have the NFS configuration here, 19:34.040 --> 19:41.880 are in the packages and the terminal modules. And the new functionality that should be 19:41.880 --> 19:49.160 upesting to NFS utils. And it first to polish this and think about using a generator also to parse 19:49.240 --> 20:01.480 the kernel command line. And finally, I will discuss. I will discuss here is more tricky than in the first, 20:01.480 --> 20:09.880 but the first part is actually like the previous one, the first identify packages should be open. 20:09.880 --> 20:19.320 I discuss here in I discuss here you are here with modules. It should be under drivers, I discuss 20:19.320 --> 20:29.480 with three, but for now I will take the whole tree. And then the custom vehicle functionality, 20:29.480 --> 20:36.920 which is very tricky, because it has a similar line to parse the kernel command line. But 20:36.920 --> 20:45.560 you also parse the kernel command line and I discuss here with the script. And it makes us both 20:48.120 --> 20:56.760 handling of hardware and kernel command line options on the same script. So I analyze what I have to do 20:56.760 --> 21:06.120 and decided to split the functionality in two parts. One read, I discuss parameters for feedback, 21:07.480 --> 21:15.000 a service specific for that. And two services to analyze, to parse the kernel command line from 21:17.320 --> 21:30.360 the kernel command line. So for if the I discuss parameters are provided for feedback, 21:30.360 --> 21:39.880 which does not one service, the mistake here will be that some of low cars don't even need 21:39.880 --> 21:50.120 network to get the parameters from buyers. But for now I will leave this as a proof of concept. 21:50.680 --> 22:00.680 And then to get a configuration from kernel command line first, a service to parse the kernel 22:00.680 --> 22:14.200 command line before I discuss the service and after the register. And start the target after the network 22:14.200 --> 22:23.720 is not like and before remote access feedback. So again the picture is similar to the previous one 22:23.720 --> 22:35.800 with NFS. We have one configuration file defined in packages and kernel modules and custom functionality 22:35.800 --> 22:47.960 that need to be upstream into work and I discuss at the policy. So the conclusion should be 22:49.000 --> 22:54.760 not found any block has yet that can be implemented. It is a benefit for classification 22:54.760 --> 23:00.920 it originators because they can adapt, remove their custom logic to the new upstream functionality. 23:01.880 --> 23:09.080 Also benefit for distributions because it is at least improved packaging. And for me, 23:09.080 --> 23:15.080 make a sign that is doing the right thing, which is being as dumb as possible. I mean not adding 23:15.080 --> 23:25.320 custom logic but selling to the right up streams. And one to end with a question, it is a 23:25.320 --> 23:31.000 good alternative for some use cases but could it become a food replacement for a traditional 23:31.000 --> 23:43.080 internet reader? Let's request the question open because there is a lot of work to do here. 23:43.240 --> 23:56.680 And rate code is very, there is a lot of dependency in rate code everywhere but you know, 23:57.960 --> 24:05.080 let's see what happens with time. So what's next, policy and appsty in NFS and is 24:05.080 --> 24:13.240 cassey more than it was that like NVME over TCP, multi path, there is a lot of work to do 24:13.240 --> 24:24.280 if you want to continue this line. So reference and that should be it. 24:26.840 --> 24:31.320 Do you want to take some questions? Do you have any questions? I would just want to go with my 24:31.320 --> 24:47.800 microphone. Okay. Thank you for the talk. I'm Benjamin working at Knoggle and we plan to switch 24:47.800 --> 24:58.600 to breakout. So the question is, do you have plans to switch to MKOSI? In the RD at some point, 24:58.600 --> 25:04.920 how do you see the future? So what do you say make a sense? Does it make sense for other 25:04.920 --> 25:09.960 distribution like a bunch of web in the search and record before saying, okay, let's move to the next 25:09.960 --> 25:18.200 big thing? We don't have plans to switch to make OSI in it at the, but we are analyzing 25:18.200 --> 25:26.840 the good things it brings. I mean, which is, it allows to claim rate code for example. Yeah, definitely. 25:26.920 --> 25:35.480 And that's great. And it has limitations. I mean, I don't know if it's suitable for all these cases. 25:35.480 --> 25:42.360 For, I mean, it's not a replacement, but maybe for some use cases is good, but for everything, 25:44.120 --> 25:51.160 it lasts a lot of things. Let's see, I mean, there is not anything blocking the technology here. 25:51.160 --> 26:00.040 So it is, if the planning, if people want to continue investing, working on it. 26:02.360 --> 26:15.560 So it's, can you list what's lacking? Sorry? Can you list which features are missing from MKOSI? 26:16.440 --> 26:24.040 Features? A lot of them. I mean, I mean, I'm only implemented NFS and an ISK asset proof of concept, 26:24.040 --> 26:35.800 but Drake with us, like MBD, multi-path, MBME over TCP, MBME over five other channels, and to have everything 26:35.880 --> 26:44.760 to take with you one. And also architecture support, like S390, I would like to see, we don't have anything like that, 26:44.760 --> 26:51.880 and I request that. That's doing it with. I mean, there is a lot of misinformation on it. 26:56.920 --> 27:02.280 Thank you. And thank you for your talk. In line with the question of the previous person, 27:02.520 --> 27:09.160 and do you maybe have things like Seth or maybe GlusterFS on your roadmap? 27:12.440 --> 27:15.000 In a roadmap. Oh, he's not a roadmap. 27:16.840 --> 27:23.560 No, but I'm a proud Debian and Seth user, and yeah, I would be lovely if it would support Seth, I guess. 27:24.200 --> 27:34.200 But just to note it, and maybe you've got time, maybe you don't, but that is mentioned, didn't I? 27:34.200 --> 27:49.640 Okay. Thank you. There was another one there. Hello, it's interesting. I like it. I have a question, 27:50.200 --> 27:56.120 which is not relevant in 95% of cases, but I wonder, how does it compare to Dracula in terms of 27:56.120 --> 28:05.000 how quickly it generates the image? Is this lower, right? I mean, the packages are gas, 28:07.640 --> 28:16.840 the speeding uses, but it is as lower than the echo. I mean, the echo is not installing like 28:16.920 --> 28:23.480 because this uses a make-or-side, which is behind using Super BNF, Pac-Man, whatever, 28:23.480 --> 28:29.560 which is installing the packages, then removes what you don't need. So this is lower. I don't have 28:29.560 --> 28:36.600 specific numbers, but. Okay, and thank you very much, Anthony. I haven't got time for any more questions.