WEBVTT 00:00.000 --> 00:11.520 For your few minutes of your lives, basically what I want to present you today is what 00:11.520 --> 00:14.800 I use daily as my home networking. 00:14.800 --> 00:22.520 I think it's not anything completely out of the question that we want to have next 00:22.520 --> 00:27.520 OS everywhere, but still I would like to ask, why would I want to do it? 00:27.520 --> 00:34.400 Why would I want to have NYXOS in my road truss in my networking gear? 00:34.400 --> 00:39.740 And the reason is basically that I can unify the deployment for the servers, for the road 00:39.740 --> 00:46.240 truss, for the access points, this means that they are managed the same, they can be monitored 00:46.240 --> 00:53.240 the same, and in the end it's just a complete unified truss set, where basically you don't 00:53.240 --> 00:57.760 move between anything else, so everything is unified. 00:57.760 --> 01:02.720 Of course, and then you have a responsibility, so if update breaks something, you just 01:02.720 --> 01:09.120 roll back it back and just use the other version, pin the next packages and so on. 01:09.120 --> 01:15.560 You probably know these reasons, and that is probably why are you in this room, and it's 01:15.600 --> 01:22.080 not my presentation, partly just for saying that you can do it. 01:22.080 --> 01:27.520 You can take the router and build your own home router on NYXOS. 01:27.520 --> 01:38.400 This is my setup, one of them, actually, manage like two parents, homes and my own with 01:38.400 --> 01:46.400 these routers, you can see they are doing something, and with the fetch fast fetch, 01:46.400 --> 01:54.600 you can see that it's running NYXOS, and pretty new upstream menus currently. 01:54.600 --> 02:01.840 And what do you need to do to actually get that networking work as the router? 02:01.840 --> 02:08.520 Basically, this is really a lot of configuration, but it shines down to just enabling. 02:08.520 --> 02:13.520 For a partying, configuring it, it will form the traffic for you. 02:13.520 --> 02:20.480 Next part is that the standard script that you might be using on the servers, they are 02:20.480 --> 02:26.560 not suitable for it, they don't have the features that we need, thus I would suggest switching 02:26.560 --> 02:33.560 to network D, system D, and this is the configuration that you can use, where basically 02:33.560 --> 02:39.040 at the internet one interface would be our one interface, and we would configure it in such 02:39.040 --> 02:48.520 a way that we say the address range is this one, we will be doing IPv4 forwarding, IPv6 forwarding, 02:48.760 --> 02:55.560 there will be the HTTP server, there is going to be practice delegation, the IPv6 will 02:55.560 --> 03:01.760 be sending router advertisements, so basically all of this is just the part of the system 03:01.760 --> 03:04.960 the configuration. 03:04.960 --> 03:11.520 Next we of course have to configure the DHCP server that we enabled, and both for IPv6 03:11.520 --> 03:25.520 and IPv4, this way we have a turn that one configured to serve as DHCP, and of course 03:25.520 --> 03:32.320 the second service is resolving, most we want to have some resolving in our network, of 03:32.320 --> 03:39.720 course you can use as the fallback to some well-known DNS provider, but it's better to provide 03:39.720 --> 03:46.720 your own local cashing resolver, so even system D provides that nice build and it's called 03:46.720 --> 03:54.720 Resolve D, you can just enable it in XOS, configure it, the important part is that you 03:54.720 --> 04:01.720 must set up here, this configuration DNS stop-list center extra, that tells the resolution 04:01.720 --> 04:06.920 that you should listen on this address as well, you should see that it's the address of that 04:06.920 --> 04:16.920 we configured for our LAN network, and then you just have to configure it that the DHCP server 04:16.920 --> 04:25.920 config to emit DNS, so your computers in your network, they'll use your DNS, that's it, 04:25.920 --> 04:33.920 we have configured DNS, and the last part is just to open the appropriate parts, and enable network 04:33.920 --> 04:39.920 address translation for IPv4, if of course you don't have the huge prefix, that probably 04:39.920 --> 04:46.920 I would be jealous if you would have IPv4 prefix at home, that's it pretty much, everything for 04:46.920 --> 04:51.920 the configuration, but the important part I would say is the choosing of the hardware, I am just 04:51.920 --> 05:00.920 outlining here to variation that we would want to think about, I think, the primary part or the 05:00.920 --> 05:05.920 requirement is that you probably need some, I don't know if it interfaces, you might need or 05:05.920 --> 05:11.920 don't need Wi-Fi, storage should be for an XOS, at least I think 16 gigabytes, gigabytes, sorry, 05:11.920 --> 05:22.920 and the CPU architecture that depends heavily on the XOS support, where basically you are choosing 05:23.920 --> 05:31.920 between ARM and XOS 86, I'm sorry, I run out of the time, so I will just let you read the 05:31.920 --> 05:38.920 reason of the presentation from the protocol you can download it, and I have to skip the 05:38.920 --> 05:43.920 bonus, or download it from this URL, and thank you for the watching, there is also a 05:43.920 --> 05:49.920 URL to my personal configuration, where there is a much more complicated version of what 05:49.920 --> 05:57.920 I showed you in here, so you can try and configure some machine that has at least two 05:57.920 --> 06:04.920 advantage devices to serve you as your home router or office router, that's it for me, thank 06:04.920 --> 06:14.920 you very much, thank you very much, we are still in time now, so let's have some 06:14.920 --> 06:22.920 questions for Kevin, who was just talking about Nixon routers, or also for Zabi, who 06:22.920 --> 06:28.920 was talking about Nixon's SS, so maybe Zabi, you can come back to the stage, we have the first 06:28.920 --> 06:38.920 question here, you have told us about the Wi, you have attempts for a nice talk, but you completely 06:38.920 --> 06:46.920 missed the part of the wireless configuration, and this is actually the hardest part 06:46.920 --> 06:55.920 usually, because of the minis drivers and so on, I completely agree, I would point you, actually 06:55.920 --> 07:00.920 this is the shortened part, shortened variant of my presentation that I actually made in 07:00.920 --> 07:10.920 check last year, I have the working wireless part, as you could see that basically in here, 07:10.920 --> 07:17.920 I have of course wireless routers, so I have it working, but it was outside completely 07:17.920 --> 07:23.920 of the fact, I got here, so unfortunately it was not possible to say anything about Wi 07:24.920 --> 07:30.920 much more into that, I think we can, for example, meet on the whole way, if you are interested 07:30.920 --> 07:51.920 how to configure Wi-Fi a little bit more, I have a quick question, did you have any problems 07:51.920 --> 07:57.920 running system did result with the IP, I thought that the system did result was only like 07:57.920 --> 08:05.920 a compatibility layer for NSS switch, when you don't, when some service doesn't use the 08:05.920 --> 08:12.920 device or borrowing KPIs, they talk with the local host DNS server, it isn't really thought 08:12.920 --> 08:19.920 for DNS server, did you have some problems about it, or I mean, I think not exactly, 08:19.920 --> 08:26.920 because basically the purpose you would describe is correctly, it actually is there 08:26.920 --> 08:32.920 outers are saying that it should not be the public for others, so I wouldn't say that it is 08:32.920 --> 08:37.920 the best solution, for example, if you would want something more, I would suggest for example 08:37.920 --> 08:43.920 not resolver, that you would have to deploy, but of course that is much more complicated to deploy 08:43.920 --> 08:50.920 than the system did result, but on the other hand, at the same time you just need standard 08:50.920 --> 08:56.920 formatting resolver, and at that point they needed to implement it anyway for the use case 08:56.920 --> 09:01.920 you describe, so you end up with working for running resolver, which doesn't matter 09:01.920 --> 09:07.920 about the original outers, they don't want it, the only possible issue might be some security 09:07.920 --> 09:13.920 issues, if it would be publicly connected to the internet, where it could be used to 09:13.920 --> 09:16.920 flooding and de-dios attacks.