Hi everyone,
I am the author of this issue https://github.com/systemd/systemd/issues/37876,
trying to allow the persistent storage and use of lease under certain
conditions. You can read to catch up on the discussion there. I have been
making some headway through implementing this and was hoping to get some
feedback on pitfalls I’ve encountered. I will also have a draft/review PR up in
this issue by the time you see this, just to ascertain if this is the correct
approach.
1. In storing on persistent storage; /var is the most obvious location for
this, systemd already has a /var/lib/systemd/network, so I am including a
similar ../lease directory in this location to mimic how it is done in the
runtime (/run) location to write the lease file there. However, I can see the
service is seemingly not allowed to write to this location even if it’s owned
by “systemd-network” user. The only way I have been able to achieve write to
this directory is by creating a drop in for the service with
ReadWritePaths=”directory”. This all hinges on creating the directory with the
system-tmpfiles service.
* Is this a safe approach to handling this problem? I assume that
systemd has protection against services (with ProtectSystem=strict) unless
specified but would It be possible to have the lease writing be implemented in
code without having to manually edit the service? Since this would be an opt-in
option, It would be beneficial to have system manage location permissions when
the option is invoked. i.e Can the protection for networkd be lifted or would
additional services need to be made to make this work?
1. This next point is more on an intended DHCP functionality when it comes
to reusing these leases. As @Pottering said in the above issue, “We should be
able to use the lease as long as it is valid, and if a reboot happens in the
middle that's just a small greyout zone we can ignore. Of course, even if the
lease from the previous boot is immediately applied, we should also immediately
refresh it just in case”. Currently, leases are not stored with any timestamp
info (or indication when it was acquired, since most timing operations work
within runtime scope), which means that during reboots, links established with
any saved leases are treated as a fresh lease instead of maybe deducting the
already expired time from the lease and running on the rest of the lease
lifetime.
* In the spirit of somewhat adhering to the DHCP protocols, for an
option where you want to use a saved valid lease (during greyout zone), would
storing the Realtime (UTC) timestamp in the lease file be effective? Or is
there some other way to go about it?
* As far as I am aware, Lease renewals are invoked into about halfway
the lease time and rebinding about 90% through. If the greyout happens just
before the renewal time but comes back just after, we would have to wait till
the remainder time to get to rebinding. Is this an acceptable outcome when it
comes to doing refresh for persisted leases? Is there a way for to do
timed/periodic requests when using this option, so that we can try to establish
something new in the event that the server comes back before rebinding time?
Apologies, this is my first contribution to this mailing list, so it might not
be formatted correctly.
Merci,
Rahman
