[systemd-devel] Custom options and passing options via command line.

[Lennart Poettering]

On Mo, 09.05.22 18:12, Kamil Jońca (kjonca at op.pl) wrote:

> For now I do not know how handle multiple interface where:
> 1. set routing according to classles routes from dhcp on some
> interfaces.

We don't do that anyway?

> 2. set NAT (ie call nftables sctipts) with multitple egress interfaces and bunch
> of VM-s inside host.

we have native NAT support in .network files? what is missing there?

> 3. decide where to resolve names based on domain and existence of ipsec
> or openvpn tunnel.

Sounds like a job for the resolved domain routing logic, which already
exists?

it appears you can use what's already there for these cases. And if
not, it seems like we could extend things.

maybe in the end things wouldn't work exactly the same as before, but
should deliver the same results?

> With systemd-networkd I even do not know where to start. And when I try
> to test somenthig, almost immediately I see that I systemd cannot do
> something I need.

Start with the documentation? But take a step back, i.e. what is the
stuff you actually intend to do conceptually, instead of already
assuming the tech you want to do it with.

> > or are you saying that you intend to change which one is preferred
> > dynamically? but the network callouts à la networkd-dispatcher run at
> > configuration time, not on request iiuc...
>
> I simply want to pass  option during disposinng interface up, and expect
> this option will be honored. (IE. interface will be default or
> not.[1])

Afaics RouteMetric= [DHCPv4] section already does all you need. just
give the iface whose default route you want to take precedence a lower
metric and you are done.

Note anyway that networkd assumes it manages an interface in its
entirety: if you muck with what it sets up it likely will override
your changes sooner or later, when some event happens... you have a
choice: make networkd manage it, or manager it with your own scripts,
but interfering with routing via manual "ip" invocations on the
interface's routes will sooner or later break.

Lennart

--
Lennart Poettering, Berlin