Re: [systemd-devel] network unit Match by router advertisement?
On Wed, May 11, 2016 at 7:31 PM, Lennart Poettering wrote: > On Wed, 11.05.16 11:32, Brian Kroth (bpkr...@gmail.com) wrote: > > > Hi again all, > > > > TL;DR: would it be possible (or make sense) to have systemd Match rules > for > > network units that could match on some artifact of the network the link > is > > attached to like vlan tag, router advertisement, wireless access point or > > gateway mac, etc.? > > Well, .network files contain the definition how to set up a network > interface, i.e. how to place it into UP state so that packets can be > received and how to configure IP routing so that communication further > on works. Hence: it uses relatively static properties of the device > that are already available when the device is offline, to find the > right .network file to read the dynamic configuration to apply in > order to put it online. The router advertisment info and things like > the gateway mac are pieces of information that are only available when > the network is already up, when the network configuration is already > applied. Hence using that as match for the configuration can't work: > at the time we could use that information we already would have had to > apply it. And if we don't apply it, we would never get the information > to acquire... > > The VLAN tag is a different case though: it's assigned when the > VLAN networkd device is created, and configured in the .netdev > configuration file for that. Thus, it's already set the moment the > network device pops up, and it could be used nicely for the > matching. So yupp, added a MatchVLANId= or so, might make > sense. Please file an RFE issue on github about this, if you'd like to > see this implemented. > > Matching by AP could work. Iirc today's WLAN drivers actually will > create virtual links for the network you connect to, and the ESSID for > each would be set before networkd would take notice of it, hence this > is probably something we could do. Note however, that networkd does > not interface with the WLAN stack at all at this point, a WLAN device > is treated like any other Ethernet device atm It was always my intention to extend the Match logic to be able to do this kind of matching on the environment. But as Lennart says, it would have to be only based on things we can passively observe. I think it would possibly be acceptable to eagerly UP an interface if it matches all but the "environment" matches (and that is essentially how WLAN must work I guess, though the UP might in that case be done by someone other than us), thought that stuff definitely requires some thinking. I agree that VLANId is totally fine to match on, and that ESSID (and probably similar things for Bluetooth etc) would be fine if they are anyway available. But yeah, whether to match on things that requires us to UP the interface would need to be discussed some more. > > However, the missing bit then would be network address assignment for the > > various instances to the right interfaces. Ideally, I'd just stamp out > > network unit files and have the apache instance units depend upon that, > but > > the trouble is that traditionally NIC naming hasn't always been > consistent > > in the past. > > > > I've read through [1], but it doesn't really provide what I'm looking > for. > > Physical layout of the nic-port-types is semi interesting and perhaps > > consistent, but network operator error may result in a misassigned vlan > > port, or simply the wrong cable to the wrong port (which can be true for > > physical or virtual realms unfortunately), etc. > > > > What I did in the past to work around that was to use ndisc6 or something > > similar to verify that the expected interface had the expected network > > properties - in this case a router advertisement. > > Hmm, schemes like this sound a bit dangerous, no? I mean, if you base > your decision whether to apply the relatively open "internal LAN" > config to an interface or the restricted "internet" config on the > traffic you see on the port, then you make yourself vulnerable to > people sending you rogue IP packets... > > I see your usecase though, but I don't really have any good suggestion > what to do in this case I must say... > > Maybe adding something like a RequireDHCPServer= setting or so, that > allows configuration of a DHCP server address, and when set would > result in logged warnings if DHCP leases are offered from other > servers thatn the configured one, might be an option? i.e. so that you > at least get a loggable event when some .network file is applied to > the wrong iface? > > But dunno, maybe Tom has an idea about this? Tom? > I'm very skeptical about these kind of schemes. We can really not promise anything about where DHCP/NDisc come form. If someone has access to the local lan, they can spoof absolutely anything, so we better not make the impression that we can guarantee anything we can't. If you want some sort of sanity checking, that might make sense, but probably as some
Re: [systemd-devel] network unit Match by router advertisement?
Lennart Poettering 2016-05-11 19:31: On Wed, 11.05.16 11:32, Brian Kroth (bpkr...@gmail.com) wrote: Hi again all, TL;DR: would it be possible (or make sense) to have systemd Match rules for network units that could match on some artifact of the network the link is attached to like vlan tag, router advertisement, wireless access point or gateway mac, etc.? Well, .network files contain the definition how to set up a network interface, i.e. how to place it into UP state so that packets can be received and how to configure IP routing so that communication further on works. Hence: it uses relatively static properties of the device that are already available when the device is offline, to find the right .network file to read the dynamic configuration to apply in order to put it online. The router advertisment info and things like the gateway mac are pieces of information that are only available when the network is already up, when the network configuration is already applied. Hence using that as match for the configuration can't work: at the time we could use that information we already would have had to apply it. And if we don't apply it, we would never get the information to acquire... True. So maybe I needed to use a .link or .netdev unit in this example case instead of a .network. The VLAN tag is a different case though: it's assigned when the VLAN networkd device is created, and configured in the .netdev configuration file for that. Thus, it's already set the moment the network device pops up, and it could be used nicely for the matching. So yupp, added a MatchVLANId= or so, might make sense. Please file an RFE issue on github about this, if you'd like to see this implemented. Matching by AP could work. Iirc today's WLAN drivers actually will create virtual links for the network you connect to, and the ESSID for each would be set before networkd would take notice of it, hence this is probably something we could do. Note however, that networkd does not interface with the WLAN stack at all at this point, a WLAN device is treated like any other Ethernet device atm. I hadn't actually looked at the WLAN side of it too much. For the past many years NetworkManager on my laptop has Just Worked and so I haven't had to worry or think about it as much. I just sort of threw that out there as another example use case and in the spirit of "can I reduce my package dependencies a tad if systemd is already capable of handling some of that for me". However, the missing bit then would be network address assignment for the various instances to the right interfaces. Ideally, I'd just stamp out network unit files and have the apache instance units depend upon that, but the trouble is that traditionally NIC naming hasn't always been consistent in the past. I've read through [1], but it doesn't really provide what I'm looking for. Physical layout of the nic-port-types is semi interesting and perhaps consistent, but network operator error may result in a misassigned vlan port, or simply the wrong cable to the wrong port (which can be true for physical or virtual realms unfortunately), etc. What I did in the past to work around that was to use ndisc6 or something similar to verify that the expected interface had the expected network properties - in this case a router advertisement. Hmm, schemes like this sound a bit dangerous, no? I mean, if you base your decision whether to apply the relatively open "internal LAN" config to an interface or the restricted "internet" config on the traffic you see on the port, then you make yourself vulnerable to people sending you rogue IP packets... Could be. In our particular environment RAs are blocked off to certain trusted switch ports much like DHCPOFFERs are generally, so I'm not as worried about it, but it'd certainly be something people need to be aware of. I guess the bigger idea behind the theory was to make the network configuration determinations based upon what we actually observe or expect the external/physical config to look like, which seemed like a generally powerful and useful technique. I see your usecase though, but I don't really have any good suggestion what to do in this case I must say... That's fine. I'll just stick with some external scripts for the moment. Or maybe try and cook up some Condition*= dependency magic similar to what was being discussed in the dhcpd lint checking thread recently. Maybe adding something like a RequireDHCPServer= setting or so, that allows configuration of a DHCP server address, and when set would result in logged warnings if DHCP leases are offered from other servers thatn the configured one, might be an option? i.e. so that you at least get a loggable event when some .network file is applied to the wrong iface? But dunno, maybe Tom has an idea about this? Tom? [2] Sidenote: In the past I've used an old trick of setting the preferred_lft to 0 for IPv6 addresses that I wanted to be avail
Re: [systemd-devel] network unit Match by router advertisement?
On Wed, 11.05.16 11:32, Brian Kroth (bpkr...@gmail.com) wrote: > Hi again all, > > TL;DR: would it be possible (or make sense) to have systemd Match rules for > network units that could match on some artifact of the network the link is > attached to like vlan tag, router advertisement, wireless access point or > gateway mac, etc.? Well, .network files contain the definition how to set up a network interface, i.e. how to place it into UP state so that packets can be received and how to configure IP routing so that communication further on works. Hence: it uses relatively static properties of the device that are already available when the device is offline, to find the right .network file to read the dynamic configuration to apply in order to put it online. The router advertisment info and things like the gateway mac are pieces of information that are only available when the network is already up, when the network configuration is already applied. Hence using that as match for the configuration can't work: at the time we could use that information we already would have had to apply it. And if we don't apply it, we would never get the information to acquire... The VLAN tag is a different case though: it's assigned when the VLAN networkd device is created, and configured in the .netdev configuration file for that. Thus, it's already set the moment the network device pops up, and it could be used nicely for the matching. So yupp, added a MatchVLANId= or so, might make sense. Please file an RFE issue on github about this, if you'd like to see this implemented. Matching by AP could work. Iirc today's WLAN drivers actually will create virtual links for the network you connect to, and the ESSID for each would be set before networkd would take notice of it, hence this is probably something we could do. Note however, that networkd does not interface with the WLAN stack at all at this point, a WLAN device is treated like any other Ethernet device atm. > However, the missing bit then would be network address assignment for the > various instances to the right interfaces. Ideally, I'd just stamp out > network unit files and have the apache instance units depend upon that, but > the trouble is that traditionally NIC naming hasn't always been consistent > in the past. > > I've read through [1], but it doesn't really provide what I'm looking for. > Physical layout of the nic-port-types is semi interesting and perhaps > consistent, but network operator error may result in a misassigned vlan > port, or simply the wrong cable to the wrong port (which can be true for > physical or virtual realms unfortunately), etc. > > What I did in the past to work around that was to use ndisc6 or something > similar to verify that the expected interface had the expected network > properties - in this case a router advertisement. Hmm, schemes like this sound a bit dangerous, no? I mean, if you base your decision whether to apply the relatively open "internal LAN" config to an interface or the restricted "internet" config on the traffic you see on the port, then you make yourself vulnerable to people sending you rogue IP packets... I see your usecase though, but I don't really have any good suggestion what to do in this case I must say... Maybe adding something like a RequireDHCPServer= setting or so, that allows configuration of a DHCP server address, and when set would result in logged warnings if DHCP leases are offered from other servers thatn the configured one, might be an option? i.e. so that you at least get a loggable event when some .network file is applied to the wrong iface? But dunno, maybe Tom has an idea about this? Tom? > [2] Sidenote: In the past I've used an old trick of setting the > preferred_lft to 0 for IPv6 addresses that I wanted to be available to > services, but not selected for outbound connections from the host. This > was basically to help influence the usual source address selection criteria > which tries to avoid "deprecated" addresses. I didn't see a way to specify > that in the systemd.network man page. Is there one that I'm missing, or is > that another case for an Exec... statement? This has been added very recently to systemd, see #3102, #2166, b5834a0b38c1aa7d6975d76971cd75c07455d129. It will be available with the next release. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] network unit Match by router advertisement?
Hi again all, TL;DR: would it be possible (or make sense) to have systemd Match rules for network units that could match on some artifact of the network the link is attached to like vlan tag, router advertisement, wireless access point or gateway mac, etc.? So, the original motivation for this question comes from a web hosting platform we developed that uses something like lightweight pre-containers for running multiple apache instances per VM. Multiple instances per VM, each running as their own user, in order to avoid the overhead of full on VMs for each apache (which are generally mostly idle) without the performance overhead of something like suexec. In order to run them each as their own user, we bound them each to their own IPv6 address [2]. A separate reverse proxy setup provides IPv4 connectivity, caching, security filters, etc. Anyways, in the past all of this dependency and setup madness was managed with some Perl scripts and a database that would just setup appropriate conf files on disk, addresses on the appropriate network interfaces (there are between two or four on each node), and environment variables before calling the standard sysv init script multiple times to start each instance. As I'm thinking about how I could move towards a systemd integrated system, I'm hoping to summarize this process to just stamping out (possibly instanced) apache service unit files, php-fpm unit files, maybe some slice unit files for arranging them into appropriate cgroup hierarchies, maybe some lightweight container features like fs namespaces, probably grouped by some target(s) for handling batch operations, etc., and just make systemd manage the process dependencies starting/stopping/monitoring/etc. However, the missing bit then would be network address assignment for the various instances to the right interfaces. Ideally, I'd just stamp out network unit files and have the apache instance units depend upon that, but the trouble is that traditionally NIC naming hasn't always been consistent in the past. I've read through [1], but it doesn't really provide what I'm looking for. Physical layout of the nic-port-types is semi interesting and perhaps consistent, but network operator error may result in a misassigned vlan port, or simply the wrong cable to the wrong port (which can be true for physical or virtual realms unfortunately), etc. What I did in the past to work around that was to use ndisc6 or something similar to verify that the expected interface had the expected network properties - in this case a router advertisement. Something similar in a Match section in systemd network units I would think could be useful. It could also be extended to other ideas like which wireless access point you're attached to at the moment, or what the MAC address of the gateway is that DHCP assigned to you, or what tagged vlan attributes you see on the wire, etc. That could be used to fire off other configuration events, especially in the case of mobile clients, when systemd discovers via network artifacts that the machine has moved to a new location and the user may want to perform some extra config actions, a backup job, etc. The only other way I can think of to emulate this might be to write a series of udev rules that executed the appropriate discovery and matching commands and then assigned interface alias names and then match on that in the network units. For instance, through RAs or VLAN tags I might determine that the interface is on VLAN 123, so I create an interface alias of vlan123, and then use network unit rules to match on that name when the link is up and an appropriate service registers a need for the address. I haven't dug through udev enough to try that yet, but it seems too procedural to me for such a general sort of desire. I like the semi-declaritive style of configuration that systemd generally enables. I guess the other option would be to just make them standalone Exec... statement units like I did before, but again that seems too proceedural to me. Make sense? Thoughts? Thanks, Brian [1] < https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ > [2] Sidenote: In the past I've used an old trick of setting the preferred_lft to 0 for IPv6 addresses that I wanted to be available to services, but not selected for outbound connections from the host. This was basically to help influence the usual source address selection criteria which tries to avoid "deprecated" addresses. I didn't see a way to specify that in the systemd.network man page. Is there one that I'm missing, or is that another case for an Exec... statement? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
