The man page pam_setcred(3) states:
> The credentials should be deleted after the session has been closed
> (with pam_close_session(3)).
Follow-up for 3bb39ea936.
This makes rtnl_resolve_interface() always check the existence of the
resolved interface, which previously did not when a decimal formatted
ifindex is provided, e.g. "1" or "42".
If a nexthop is removed, dependent routes are silently removed by the kernel.
Hence, networkd may be confused that routes that depends on the nexthop still
exist, and may fail to configure other routes or so.
This is the one for routes of 3cbbe8635a.
If we could not remove a route, then previously the corresponding
Route object was never removed, as it was freed only when we receive
remove notification from the kernel. So, we might confused that the
route still exists and being removed, and might block reconfiguring
the route.
With this change, even if we fail to remove a route, the corresponding
Route object will be freed.
This is the one for routes of 56a995fe8e.
Then, replace route_remove_and_drop() with it.
If a route is requested, and the request is already called,
we may not received its reply and notification from the kernel, and
the corresponding Route object may not be remembered. Even in such
case, we need to remove the route, otherwise the route will come
later after the function called.
This is the version for route of f22b586a21.
Previously, a Route object is owned by a Link object corresponding to the
outgoing interface of the route, and a Route object that does not have
outgoing interface is owned by the Manager object.
However, there were several issues:
- if a route has a nexthop ID, then the corresponding nexthop may be
changed to use another interface, hence the outgoing interface of the
route may be changed.
- if a route requested with MultiPathRoute=, then the link who requests
the route is different from the outgoing interface of the configured
route. So, we need to find routes on other interfaces on reconfiguring
or so.
By this change, the limit of the number of routes per-interface is
tentatively dropped. Let's re-introduce the limit later in a nicer way.
Previously,
1. use the passed Route object as is when a route is requested,
2. when the route becomes ready to configure, convert the Route object
if necessary, to resolve outgoing interface name, and split multipath
routes, and save them to the associated interfaces,
3. configure the route with the passed Route object.
However, there are several inconsistencies with what kernel does:
- The kernel does not merge nor split IPv4 multipath routes. However, we
unconditionally split multipath routes to manage.
- The kernel does not set gateway or so to a route if it has nexthop ID.
Fortunately, I do not find any issues caused by the inconsistencies. But
for safety, let's manage routes in a consistent way with the kernel.
This makes,
1. when a route is requested, split IPv6 multipath routes, but keep IPv4
multipath routes as is, and queue (possibly multiple) requests for
the route.
2. when the route becomes ready to configure, resolve nexthop and interface
name, and requeue request if necessary.
3. configure the (possibly split) route.
By using the logic,
- Now we manage routes in a mostly consistent way with the kernel.
- We can drop ConvertedRoutes object.
- Hopefully the code becomes much simpler.
If the requested new name for a network interface is already assigned as a
alternative name, then it is not necessary to and cannot rename the
interface.
This also changes to use sd_device to get some attributes.
So, on moving interfaces back to the parent, we need to populate sysfs
associated to the client netns.
That may look redundant and complicated, but it makes later change
easier, and hopefully faster.
This also introduce an extra argument for route_dup(), but it is
currently unused, will be used later.
No functional change, just preparation for later commits.
- fix memleak in parser,
- fix missing return in parser on failure,
- drop unnecessary temporary argument in command line argument parser,
- use recently introduced macros and helper functions.
- introduce link_required_operstate_for_online() helper function,
- use recently introduced macros and helper functions,
- unconditionally serialize the minimum and maximum of required
operational state.
The kernel uses different logics to find or distinguish IPv4 and IPv6 routes.
Let's follow the same way that the kernel uses.
See comments in the code for more details.
To prevent the request freed in req->process().
This also makes a request that is not requested by a link detached on failure.
Otherwise, the request may periodically processed and failed forever.
If a nexthop is removed, dependent nexthops are silently removed by the
kernel. Hence, networkd may be confused that nexthops that depends on the
nexthop still exist, and may fail to configure other routes or so.
Also, this renames 'req' -> 'm', and makes the function unconditionally
set route type and route metric, and override type later if necessary.
Should not change any effective behavior. Just refactoring.
Yu Watanabe