 Hello, my name is Pavel Shimelda, I'm working currently for Red Hat. I was actually working for like one year on the Network Manager project. So I would like to tell you that I'm no longer officially on this project inside Red Hat, but here in the open source world, so I'm still an upstream contributor, I'm still quite active, it's just not my everyday work, and I cannot really speak for all the developers of Network Manager, because I have some vision, they have some personal visions as well, so we often try to put our visions together and do something useful. I participated on a major redesign of the whole thing, which has been done during past like three quarters of a year, so it's quite a new thing, it's not something you can see in the released versions of Network Manager, so you can learn what's going on and what's up if you don't follow my English closely sometimes even the mailing list and stuff like that don't show you everything. My personal focus was Network Manager, Linux kernel interoperability and the whole part of the code that deal with the Linux kernel configuration, so it's pretty much a good topic for this conference. As well, I'm very much focused in address and routing configuration stuff, which is pretty much related to what the kernel does, and there are some other things I've been doing, like the key file configuration, which is the native Network Manager configuration format, we have a couple of other formats supported such as Red Hat's IFCFG files, and I've also done something about testing and stuff like that. Very, very briefly about Network Manager, there's a couple of points what I would expect for Network Configuration service to achieve, so it's reading configuration from files, but not only that, it's simple scripts and distributions like Fedora and Debian and so on, always could treat configuration files and do something with that, but what we expect with a modern Network Configuration service is to allow other tools, other services to talk to the service and change the configuration of the fly, which is a bit important for stuff like virtualization and so on. Also, the other tools need to learn about the changes, so we need to be able to notify them, and there has to be done some actual configuration, so we need to turn the internal state into kernel configuration and configuration of other tools like the ACB clients and TeamDemon for machines that use teaming and so on. So this is quite a lot of stuff, but it's very self-contained because you know usually exactly what you want to work, the complexity lies in how to achieve that and how to interoperate it. I think really the most of the work with Network Manager is about interoperability and nothing else. We have a stable branch where you don't see much from what I will be talking about here. There are some important fixes. I mean, during the development of the branch, there are some important fixes, otherwise it has its new features as well. There are recent changes, recent releases for OS5 support, but that's something I'm not really interested so much in, so I'll skip that quickly. And there's what we call 0910, which has not been released, and this is the topic of the talk. So first of all, it would be good to know why there had to be a larger-scale redesign or what was the purpose of it. And traditionally, Network Manager was used for desktops and laptops. I think most of you knew about this already, who's using Network Manager on some laptop or desktop environment, most of you would say, and who's using Network Manager on a server? Okay, yeah, that's exactly why the redesign was started, because nobody wants to use Network Manager on server, but there are some difficulties with that because if you use different tools for servers, different tools for laptops and so on, what should I do if I want to install virtualization on my laptop and experiment and at the same time connect it to the Wi-Fi and so on? So is it a server or is it a laptop still? That's a big problem. There are also some use cases for a dynamic service, even for servers. For example, DHCP is sometimes useful even for servers. Some people use it. Is there anyone who uses DHCP configuration on a server here? Do you know about someone? I think maybe. It depends. A possible use case is if you have a small server, which is more like a network of the storage or something like that, and you bring it from one network to another, it's a typical server because it serves the storage, the files, but it's often easily integrated into the network by just connecting it. Some of you said you're disabling network manager for servers. Do you have any specific reasons? Yeah, yeah. So this is actually my third point here. Network manager in its current release versions often does something that breaks the configuration that is prepared by your other tools. So that is a big problem and it's maybe the main reason why the redesign was started. There are some minor issues that we want to have support for in interim FS and that we want to be able to restart or all of the processes a network manager has when there's a security update with the least possible disturbance of the network configuration. So very simply you install an update of either a network manager or some tool that is used by network manager, then you want to restart network manager, but you want to still continue with your network connections, for example, DCB connections. There's one point that makes this a little bit harder and that the network manager team or network manager project still tries to stay compatible with its previous versions. There has not been made any decision to break compatibility again and such a decision is never, never popular. So let's say we need to look at the inner workings a little bit because all the features are related to the core workings of network manager. At the beginning we need to read the on-disk files, on-disk configuration and we need to also start tracking devices that we find in the system. We need to initialize the network interfaces. This is really, really easy, but we also need to initialize devices that appear during the runtime so that it gets a little bit complicated. We need to, for each device, check the existing kernel configuration to see how the device is configured. We actually, with the new code, generate a connection profile or a connection object which is the same type of object that we read from the files on the disks. So we can then compare the configuration. You can imagine that we read a connection configuration from disk as well as from the kernel and other tools possibly. On the disk there may be multiple configurations for the same device or there may be a configuration that can be applied to any device. So that's quite a lot of options, quite a lot of stuff that needs to be solved. And then when we can compare the existing configuration with, let's say, the list of configurations available for the device in network manager, we need to do some decision. This is a critical point because there we decide whether network manager will touch the device at all. This is so important because when you have already some configuration from other tools that you need to be kept from breaking by network manager, this is the point where you want network manager to decide not to work with it, not to do anything with it. There's also a possibility to configure these explicitly so you can blacklist devices in network manager and not manage them at all. But this is not so useful for virtualization because with virtualization you create all the devices dynamically and you need network manager to just detect that it's not meant for it to manage. Then there are some device-specific initialization actions. For example, if you have Ethernet, network manager sets the Ethernet up. It's necessary, at least from the stop point of view. It's a little bit trickier from the Sarah point of view. Normally you don't apply any connections to a device that's not connected by a cable to some other device, let's say switch. So the only way to detect carrier is to already allow the device to communicate over the wire. It's level one or level two communication, but you still need it. If we left the device down, we would not get the carrier detection information. This may be a problem in some cases because sometimes you just don't want that. So again, step back to decide about device management and you have to make network manager ignore your device if this is not what you want. Then there's a purely desktop feature to generate a default profile when there's no configuration detected from the kernel and as well there's no configuration found on the disk. Typically Ethernet devices on laptops and desktops are just connected using DHCP. So here that's not new. The new thing is that you can explicitly disable it. It's a couple of options already that you would probably like to use on servers. The network manager project now ships a configuration file that's called server.conf and that carries a couple of usual server settings for you. So you can just take this file and drop it in a special directory for that and you're done with basic server configuration. Because by default we still want to keep the same behavior so the default behavior is more suitable for laptops. Then if we did not detect any configuration but found some suitable configuration on the disk or the default one was generated, we need to activate it. There's also a similar procedure. If we actually found a configuration on the disk that matches the actual configuration of the device imagine you're booting up a system. In your NFS there's some network configuration. You start network manager in the real system. This is a newly started service that reads the kernel configuration and sees that the kernel configuration matches what it would configure otherwise or matches one of the possibilities it could configure otherwise. So then we just need to pick up the connection as it is and there are some of the steps from profile activation is used as well. Some of the steps are skipped because they are not needed. That's how it works. I will not go very carefully through this list. Just that some of the supported devices in network manager are pretty new. It's the teaming which is a replacement for bonding. It's devices like TAN, TAP, tunnels using GRE, McVeeLan, McVeeTap. These are just new additions. And there's something that's a little bit more interesting than the individual device types and that's generic device support. That's a possibility to use network manager to manage a device whose low level configuration is handled by some other tool. It does not sound so amazing like that but actually there was a longstanding problem of network manager not actually detecting the real network configuration. For example, if you had default routes set by another tool and it went through a device not managed by network manager, network manager would report that we are not connected. For example, we are not connected to the internet in these terms. This will now be different because we can manage just any device and we can follow the state of devices that are not managed. Even if network manager doesn't touch the configuration of devices it needs to follow the information that the kernel provides. For example, if there's a default route through let's say a bridge that is set up by virtualization tools, network manager does not manage the bridge but it can see that there's a default route and it will not make configuration changes that would break that. This is a theory so far. It's not yet committed into Git. There are some branches with some development so be a little bit careful when testing it even if you work with the Gitmaster. Not everything is there yet. There's a natural conclusion of what I was talking about and that's that the state of network manager devices or network manager managed or even unmanaged devices needs to be kept and does not necessarily reflect the on-disk configuration. This is a big change because so far network managers internal configuration or untimed configuration was always the same as the configuration written on the disk. This is no longer the case. You have runtime connection profiles. Those can receive information not only from the disk files but also from the kernel for example. So if you use tools like IP route or IF config to add IP addresses then network manager is capable of accepting those addresses and adding them to its internal configuration. If you then use a tool, command line tool for a network manager called nmcli you could eventually save the resulting configuration to again have the same state on the disk as you have in runtime instance. There is some notion about active connections because they have some attributes that do not belong to configuration stored on the disk. For example, a list of dynamic addresses doesn't really belong to the on-disk configuration but is still kept at runtime network manager. The same is the list of DNS servers taken from DHCP and so on. So many examples of data that is important that sometimes needs to be queried by other tools and that do not belong to the on-disk configuration. There are a number of questions about the behavior of disconnected devices as well as the behavior of devices that are for some reason unmanaged or not managed by network manager. Be it auto detection that the device was created or configured by a different tool or be it explicit configuration doesn't matter so much. So if you have runtime connections, you also have on-disk connections there is a relation between them. Typically on-disk connections when network manager stars are turned into runtime connections you can have connections at runtime that don't have there on-disk counterparts or are different. Typically network manager or the previous versions of network manager always reloaded the configuration when you modify the files. It was using kernel's I-notify mechanism which is not really very good for this purpose because various tools perform the editing in various ways so sometimes you end up with network manager reading something that was not really meant as a final configuration. Sometimes you want to add some configuration that depends on another configuration. You don't want to track all the dependencies and put things in the configuration in the right order. You want simply to make the changes then ask for an explicit reload. This is already possible with Gitmaster as far as I know and it is possible already to disable the autoreal feature. It's still being discussed because the last thing was that LibVid has problems with that. Everybody expected or at least everybody I know expected that turning off automatic reloading is a great thing but LibVirt now just did not know what to do to make network manager reload connections again. So we realized network manager only exposes support for reloading all connections at once but it's not what they wanted and so on and so on. Those are implementation details but I'm talking about them just to show you that there are still minor glitches that you see each time you make any modifications. There's nothing like the way A is wrong, the way B is right, change the behavior from A to B and you're done with it. It's not like that. Any changes that are reflected in the API are really, really difficult to sell to the other projects. So as I said network manager can accept external events. Those are not only new addresses like I talked about but those are also edit or removed interfaces because in Linux you have lots of software interfaces that you can create and destroy bridges, bonds and so on. So this is also something that needs to be acted upon. There needs to be some logging support that's already quite good and that's for now. At the beginning I was briefly talking about the use case where you want to take over some existing configurations. So I already told you about the reasons to do that. There are just some let's say challenges maybe in doing that because if you want a configuration to be taken over then that means you have to be able to leave the configuration still working when quitting network manager. My opinion is that network manager or any other system demon when it stopped that it should stop all processes that it used including stuff like WPA's application for Wi-Fi including stuff like DACP client and so on and so on. That's because if you want to start a service again you always want to have all of those services in their fresh state or you want new versions of them that you just installed to be already used for security reasons. So there is a question which connections can be left working for taking over. So far it's quite easy with Ethernet unless of course you are using 801.1.x which is via VPA's applicant. So whenever you are using WPA as applicant you cannot leave the connections working. That means secure Ethernet that means Wi-Fi. For Wi-Fi it's not a big problem because Wi-Fi is also often disconnected for other reasons so that's not a big deal. But also you need to look at the upper layers like DHCP, router advertisement and so on. For DHCP on IPv4 it's pretty easy because the implementation of the DHCP network manager was simply a call to DH client and an action script or rather action executable which is given to DH clients to use instead of its usual actions. So when DH client asks for the configuration information the action executable is used to convey the information to network manager. Otherwise normally if you run DH client by hand it's directly configuring the kernel which is wrong because in the context of network manager it is wrong because you might want to run VPN software on top of the Ethernet and so on. So you never know whether the configuration is final unless it goes to network manager. With router advertisement there was a big problem because first of all router discovery in the kernel the client side of router discovery is implemented in the kernel it's really buggy, it does do many many things wrong so we considered the option to fix it somewhere. When we wanted to fix it we realized that even if we fix all of the individual problems we still have the largest problem and that is that the router discovery support in kernel writes the configuration directly to the routing tables and to the list of addresses and so on. So this is totally unsuitable for the same reasons and we had to switch to user space implementation. It was just an example of what needs to be done for proper connection takeover. Now we can work easily with DACP for IPv4 as well as router discovery as well as DACP for IPv6 all of those are supported. We can possibly take over software devices. It's not a big problem. We just need to compare them with the configuration we have and either accept them or usually when a software device does not match any known configuration in network manager that means it's created by another tool so we don't want to manage it. Even things as simple as the address list have some improvements now we found quite a lot of interesting things in there because typically if you want to add an IP address to your device you need to specify the device, you need to specify the address family and you need to give it the address data and the length of the prefix so that an automatic route can be created to contact other machines on the local network. So this is pretty easy but formerly network manager also used gateway in its internal representation of the address which does not match the kernel and does not match how things work so this will be eventually removed but it did not include the lifetime of the address which is quite funny because the lifetime is normally not very useful for you because either the address is working or it's already expired but for network manager the lifetime can be also used to see whether the address is dynamic or not in dynamic I mean even DACP for IPv4 as that one did not use the lifetime even in the kernel which we changed that, we asked a colleague that knows a bit more about the kernel to add support to address lifetimes to Linux's IPv4 stack so that now if network manager is looking at the interface and looking at a list of addresses it can distinguish which addresses are dynamic and which are static Dynamic addresses from the kernel, from the kernel auto-discovery are easy to see because they have lifetimes Dynamic addresses from network manager's DH client instance is easy to see as well it's the same, there's still a problem that by default if you run DH client directly it does not use the lifetime at all so in that case you will not detect that properly and network manager will think the addresses are static that's not such a big problem because usually you expect to take over configuration in network manager from previous instance of network manager there's one small thing we may be adding also it's the support for address labels which is usually just plain old Linux alias device support it's only because the IF configuration is built on top of that so for full compatibility we can't live without that but this is up to the regular developers from Red Hat who need to get this supported it's very similar if you look at the routes the lifetime is not currently implemented as it's not as important as with addresses but eventually it will be there as well we currently only support single hop routes that means you are sending the packets to just one router around you're supporting just one gateway on the network I'm a little bit oversimplifying it but that's not something I would like to talk about here for a long time still the default gateway information which originally was bound to addresses will not be moved to the internal list of routes because it needs more special treatment than ordinary routes often if you have a configuration that does not make it to be the default one for default routing imagine a computer with two Ethernet devices both connected to some networks typically you can have only one default route so one of them has to be chosen the same is for DNS which also needs only one of the configuration to be chosen there's the special handling normally if those two networks are distinct all other routes can be edited from both configurations there's one new thing that I did not even yet talk about with the other developers but we've talked about it with people from the community it's policy routing which is typically not supported by default or not configured by default in Linux but that's a pretty neat thing because if you have two links to the internet it's useful in very simple use cases where one of the links is the main one and the second one is only for maintenance purposes if you disable one of them for example if you disable the main connectivity because there's some problem security attack or something like that then because the default route goes through that one you typically cannot connect to the computer anymore so this feature is about the ability to connect to any of the public addresses they don't need to be fully public but to connect over any of the channels and to choose the channel from outside by choosing the IP address of the machine the only thing, the only technical thing you want from the machine is to answer you over the same channel, answer you over the same network that's all if that is done there's another thing that can be used and it's called multi-path TCP it's a protocol that allows you to switch between multiple TCP channels so if you disconnect from one of the networks you can just continue the connection over the other one if you connect back and then disconnect the second one you can continue the connection of the first one technically you have connections open over all of the interfaces but usually you're only using one for sending the data and the other ones are backup if you want to know more about this either you can look for it on the internet or you can send me an email at the end of the presentation there will be again a slide with contacts so you should be able to reach me easily when I was talking about the dynamic configuration I did not talk much into the details but there's just a couple of things because when it's done, when it's finished it's very easy to look at it because we just decided to perform all of the network configuration protocols in user space which was a good thing and then simply the core network manager decides what to do with the data so there's quite a lot of flexibility recently there were some minor improvements with the dynamic configuration it was about the ACP for IPv6 DUID support it's also very simple because we are just reusing ETC machine ID from SystemD to construct a unique identifier that's I don't know if you heard about how it works with the ACP v6 and that you can't really use MAC addresses for identifying client computers as you did with IPv4 and so on again if you want to go into details we can talk about it somewhere you can often find me at the Fedora booth so we can talk about it outside of the talk there's one thing that I recently looked at and that's network manager IP connectivity methods I would like to show you if I'm connected, yes I started a page on the Fedora wiki and I'm trying to summarize the way IP configuration methods are used currently in network manager and also to propose some better solutions because currently I don't know if it's big enough, probably yes but let's try a little bit currently if you read through the table my advice is to read separately the blue lines and the green lines because it's the two separate protocol versions you can see that IPv4 supports disabled a special link local method, manual, automatic, and shared shared is for a connection sharing where the computer acts as a network at its translation router for the network it's like the classic one from who used to use Windows I used to use it in the time of Windows XP so for me that's the source if you look at IPv6 it's a little bit different there's a special ignore method that comes from the times when network manager did not support IPv6 properly it did you the favor of not touching the IPv6 configuration in the kernel at all it's becoming less and less useful so we may eventually phase it out but there's nothing that would be called disabled in IPv6 and as well if you look at the column of link local you can see that there's a difference between IPv4 and IPv6 IPv4 does not use link local addresses at all except when you use the link local method so link local IPv4 addresses are used usually for fallback situations where you don't have any DACP router you have directly connected computers or a couple of computers connected via a switch and all of them can fall back to link local method which is not a feature in network manager this is how it's typically used so it's not even supported in that way it's supported by Windows and Apple I think mostly but with IPv6 the link local address is always there because it's used for all of the other protocols so my idea is actually to break down all of those methods and use actually the features individually there are some possibilities you can get with that if you just say link local, manual, automatic and G is gateway for other hosts or shared you can construct a table of all possibilities some of the configurations don't make sense those are the gray ones some of the configurations actually have some method in network manager so this is how it already works but you can see many many combinations of possibilities that are not supported for some reason and one of them is what's called disabled in IPv4 IPv4 means that you don't have any link local address means that you don't have any manual address not any automatic, not any ACP address and connection sharing is turned off this is something we currently don't support with IPv6 and when we wanted to add this we realized there's a kernel problem because we can't turn off link local addresses in kernel which are indeed generated by the kernel so we don't have the choice in network manager either to add them or not as well we can work around this by disabling IPv6 entirely but there's some implementation issues in the kernel so there will be things to be researched in the kernel I will not go through all of them because it's just for those who are really really interested in the deep details and those of you can find this page and look at that there are some typical examples of things that are not supported for example it's a situation where you have IPv6 or is it? no sorry IPv4 you have IPv4 you want to have a link local address to be able to communicate over it anytime as is usual with IPv6 and that's all and that's currently not supported you can't use those two features together the same combination but for IPv6 is normally supported because in IPv6 the link local address is usually perceived as a must but if you just swap the first value whether you want the link local address or not you're getting to another line and it's when you want only only manual IPv6 address for IPv4 it's supported but if you want to have one manual IPv6 address it's possible it's even used by tools like OpenVZ which is a virtualization or container virtualization tool which sometimes just adds single IPv6 global addresses to your virtuals with a network manager you can't currently set this up because you can't simply disable the link local address and only use the global one that you set up like it was used with IPv4 this is not possible again this is not possible in the kernel so I hope I did not bore you to death with this table there are a couple of things that will need a bit more research and then we could end up with instead of having IPv4 method IPv6 method we could actually end up this is really just a proposal in a couple of configuration values that would allow you a lot of more flexible configurations including it's not the end of all tables but almost for example I heard about a new draft or maybe it was an older draft resurrected to only do the ACP on IPv6 I don't know how far it got but I heard it as an argument against my previous proposal so this modification counts with that possibility as well so you want to have a link local IPv6 address actually you need it in order to perform the ACP but you would want to explicitly skip the discovery with the current state of the art this is not possible according to the standards because the ACP version 6 cannot convey routing information but if there are some drafts to add stuff like that it could be possible so the final proposal is very very flexible and it would also allow you to do stuff like use link local addresses as fallback to AC a little bit I will need to fix this table a little bit if you ignore the header of the table it just should mean that you want to fallback to link local address after the ACP is tried without success so this is something we don't support currently but with a set of options like this it could be very easily supported because you would just choose to link local address and fallback so why am I showing you features we don't have? why am I showing you stuff that has not yet been even very much consulted because I just posted links to this page to various places where it's due for example to all related bugzilla reports those are listed at the bottom of the page you have the chance to look at stuff like this not only this particular thing you have the chance to look at the bugzilla and actually either by coding or by just answering or presenting your use cases you can change or you can affect how the future development of network mesh will be done so this is mostly the reason why am I showing you details like this one because you may have found something that constitutes a feature you would like or you would need and unless we can really justify it by real use cases it won't be there I will not much go into the details of connection sharing you can think yourself about challenges of connection sharing with IPv6 where network address translation is maybe not an option because applications may not be ready for it technically you can translate addresses you can do the same as you do with IPv4 but you may come into problems because applications just expect full global routeability of IPv6 addresses so this is something for thinking about there are some possibilities like DACP can provide you with addresses even for your other networks not only for your connection to the local network it's called prefix delegation you can read more about it it's all in theory there's one bug report for that on network manager upstream bugzilla so that people can put their ideas we are getting close to the end currently the DNS backends can do various things for you the core DNS support just writes ETC resolve conf which is a very basic or even stupid way to configure DNS we have support for DNS mask which can act as local resolver or local recursive name setter and with DNS mask it's also possible to direct some queries to some domains to their respective name servers for example if you're connecting to your company VPN you sometimes may have to use your company DNS servers for your company host names but you still may want to use the ordinary DNS servers for everything else so that's not possible with resolve conf that's possible with DNS mask which is supported unbound is not yet supported but that would allow you to do the same with some improvements as unbound does not need to be restarted for reconfiguration and it would also add you the support for DNS sec which is the main point of integrating unbound and network manager there have been already done some work using dispatcher D scripts my colleague Tomas Hossa was working on this and most of this feature is now done using the script it's not perfect but it's pretty good I think after rewrite to a module for network manager it will work much better I don't think I want to go into details about DNS sec here but there's again the same problem if you turn on DNS sec and require DNS sec validation for global DNS route then you can have a problem with your company host names and company name servers which you still need to resolve the company host names for you and as well you may need to not use the requirement for DNS sec validation for them because they probably don't support it and you need to have configuration that will turn the support for DNS sec pair your connection for example VPN it could even be a wired connection if you are in the company inside it doesn't matter so much what type of connection it is and you can have then configuration of DNS and DNS sec different for each interface and different globally as well the API is being improved that's the main message here the command line tool is now being improved so much that it can be used instead of the API the API is you can choose the bus for the API or you can use a library that sits on top of the bus it's up to you it's quite easy to interface with network manager from C or Python maybe some other languages just any language supporting D bus and so on so there's not much to talk about I think just the CLI you need to try it you need to install the git version or wait for the release and try the nmcli because before now the nmcli was not really usable for anything useful for anything real so try it and see what it can do for you network manager has four regular developers at adhat I'm not one of them anymore but there's a new guy so there are four again it has individual contributors like me it has distribution maintainers contributing to it I don't know if anyone is here at linuxcon from debian, susai, gen 2 and so on multiple people from gen 2 I forgot to mention ubuntu because there's some guy trying to do testing and so on people can help by trying the bugs by going through them explaining some more things to the reporters and so on currently it's mostly just the developers and me who do that using testing bug reports everything is good good for the project so it's not only one company project so it's a real open source project it has been getting better over the past one year so I hope it will get even better in the future as well that's all from me because there's no one going just after me to talk we have enough time for questions anyone can ask me about questions currently fireworld integration is done only by publishing zone information that means you can attach some zone it's really very similar to how windows firewalling works if you attach a public zone or work zone or something fireworld can then reconfigure the firewall for the specific device further network manager needs to add some rules to the kernel for network sharing so I'm mostly focusing those two things the second one is currently done by ip tables commands not fireworld which is a problem on systems where fireworld is used the zone for fireworld is based on the connection profile that is used for the interface so you can actually have multiple zones active if you have multiple interfaces and what you're asking for is to detect the local network to see whether this specific network should be marked as home or work or something else is it true? this would actually be implied by a feature to apply connections according to this criteria so it would not be a specific feature relating to fireworld integration but it's really a wanted feature to have a simple example I connect my computer by cable in the company I want network manager to detect where I am and I want to perform network configuration based on that including the zone this is a desired feature there's no one currently working on it contribution would be welcome of course but it's a rather complicated task not very complicated but still on the basic one more questions next February release is 20 actually I will apologize and avoid this question as this is up to the other developers who are also maintaining network manager in Fedora because if I answer some guesses here it's better to write them it's better to write either to mailing list or to enable them directly they're responsible for this I'm sorry the date? no it's based on the features and actually there are lots of features wanted for that release so we'll see the solution for distributions like Fedora which are a little bit more a beating edge than usual is usually to use snapshots from the Gitmaster yes yes it depends on how you define embedded environments because it was in the previous talk the question was asked but for example if I consider my home router as embedded I would like it to support VPNs as network manager does for example if it wasn't some sort of appliance that I can bring somewhere I also would like to use the VPNs I think the VPNs are currently the main driver because otherwise in OpenWRT there's an activity which is used by OpenWRT which seems to be also quite good for the purposes where you don't have desktop tools sitting on top and so on so yes, yes, I indeed do also for IPv6 configuration and stuff like that it depends on if you have a simpler tool that is good enough for you that might be more suitable than network manager but if you don't have such a tool network manager is not so big it's not so bloated as it's sometimes told by people so it can be used for its features even in embedded you ask a difficult question I gave a stupid answer, I know it but it really depends on the case so if that is all any questions can be asked via email or we can talk about stuff after we finish here thank you for your patience thank you for being here and we are finished