On Wed, 11.05.16 11:32, Brian Kroth ([email protected]) 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 [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
