Lennart Poettering <lenn...@poettering.net> 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 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.

Neato.

Thanks,
Brian

Attachment: signature.asc
Description: Digital signature

_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to