On 2024-12-13 07:07:14 +0300, Michael Tokarev wrote:
> 13.12.2024 03:24, Vincent Lefevre wrote:
> > I suppose that this is the following in the 3.9.1-4 changelog:
> >
> > * run configure-instance.sh (for chroot) from within postfix-script,
> > so every invocation of `postfix start' will run it, not just the
> > startup scripts. Add a patch to upstream postfix-script.
> > This is to prepare for multiple instances mostly, and for consistency
> Yes, but this is not our problem still.
>
> network-manager is supposed to run /etc/network/ip-up.d/* etc scripts,
> which either it doesn't or the scripts don't work. I'll provide
> native hooks for N-M for this task.
Well, in the tests I did last night, I just tested the manual change
of the /etc/resolv.conf file. I did not test the change of the wifi
network.
Anyway, /usr/share/doc/network-manager/NEWS.Debian.gz says:
network-manager (1.44.2-2) unstable; urgency=medium
NetworkManager or rather NetworkManager-dispatcher will no longer execute
ifupdown hook scripts from /etc/network/if-*.d/ on network state changes.
Packages that want to be notified and react on such network state changes
are advised to ship native NetworkManager scripts in
/usr/lib/NetworkManager/dispatcher.d.
Users may provide local hook scripts or override package provided ones by
installing those into /etc/NetworkManager/dispatcher.d.
For further information about the NetworkManager-dispatcher interface see
the NetworkManager-dispatcher(8) man page.
-- Michael Biebl <bi...@debian.org> Wed, 18 Oct 2023 13:55:54 +0200
So that's clear. You must not rely on the /etc/network/if-*.d/
directories, even for the case where the interface is brought up.
Note that before this change, the /etc/network/if-*.d/ scripts
were executed by NetworkManager via a script
/etc/NetworkManager/dispatcher.d/01-ifupdown
which had:
# Run the right scripts
case "$2" in
up|vpn-up)
export MODE="start"
export PHASE="post-up"
run-parts /etc/network/if-up.d
;;
down|vpn-down)
export MODE="stop"
export PHASE="post-down"
run-parts /etc/network/if-post-down.d
;;
# pre-up/pre-down not implemented. See
# https://bugzilla.gnome.org/show_bug.cgi?id=387832
# pre-up)
# export MODE="start"
# export PHASE="pre-up"
# run-parts /etc/network/if-pre-up.d
# ;;
# pre-down)
# export MODE="stop"
# export PHASE="pre-down"
# run-parts /etc/network/if-down.d
# ;;
hostname|dhcp4-change|dhcp6-change)
# Do nothing
;;
So, the if-up.d and if-post-down.d scripts were supported when
the interface was brought up and down. But nothing was done for
DHCP changes, and AFAIK, running such scripts on DHCP changes
was not done with just ifupdown either. When I was using wicd
and isc-dhcp-client to connect to wifi networks, I had to use
the /etc/dhcp/dhclient-exit-hooks.d scripts to handle the DHCP
changes. IIRC, this was still working with NetworkManager and
isc-dhcp-client (when enabled). Then isc-dhcp-client became
obsolete.
The real solution for NetworkManager is to use the
/{etc,usr/lib}/NetworkManager/dispatcher.d directories. See the
NetworkManager-dispatcher(8) man page. In particular, it has:
dhcp4-change
The DHCPv4 lease has changed (renewed, rebound, etc).
dhcp6-change
The DHCPv6 lease has changed (renewed, rebound, etc).
(mentioned in /etc/NetworkManager/dispatcher.d/01-ifupdown above,
but with "Do nothing").
> And here's something else for you to consider, which'll fix the issue
> for sure. Please consider running some local caching DNS resolver.
> Like systemd-resolver, or dnsmasq. They're small things and work
> well with network-manager too, and helps with DNS in general. With
> any of these, the 'nameserver' line in your resolv.conf will always
> point to localhost. I think I can add a Recommends: to postfix for
> any of these.
Well, I had tried unbound to bypass the DNS servers of my ISP (like
I did on other machines, due to censorship via DNS in France), but
as a side effect, I could not use the DNS server 192.168.1.1 of my
FTTH router to resolve the hostnames of the machines on the local
network:
https://serverfault.com/questions/1145392/how-to-configure-unbound-to-forward-local-hostname-resolution-to-my-local-dns-se
and I could find no good workaround to resolve the local machines.
Also, for my last try, unbound was not working at all, and I did not
have the time to debug it yet.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
