Hi *,
I'm trying to understand, how netconfig and NetworkManager are playing together in openSUSE regarding ntpserver client settings. System is openSUSE Tumbleweed 20230308.
Excerpt from my journal:
NetworkManager[18524]: debug: ntp-runtime Module called NetworkManager[18524]: debug: Resolved ntp-policy 'auto' for service 'NetworkManager' to 'STATIC_FALLBACK NetworkManager' NetworkManager[18524]: debug: Static Fallback NetworkManager[18524]: debug: Use NetworkManager policy merged settings NetworkManager[18524]: debug: exec get_ntp_settings: /run/netconfig/ NetworkManager.netconfig NetworkManager[18524]: debug: get_ntp_settings: NTP_SERVER_LIST='' NetworkManager[18524]: debug: exit get_ntp_settings: /run/netconfig/ NetworkManager.netconfig NetworkManager[18524]: debug: write_chrony_servers: 192.168.1.1 NetworkManager[18524]: debug: ntp servers written to /run/netconfig/ chrony.servers NetworkManager[18524]: debug: write_ntpd_servers: 192.168.1.1 NetworkManager[18524]: debug: ntp servers written to /run/ntp/servers- netconfig
As I found out, there is an nm module /usr/libexec/netconfig/netconfig.d/ntp- runtime, that is responsible for supplying ntpservers to chrony. But there seems to be a problem retrieving dynamically by dhcp assigned ntpservers - in any case I tested, get_ntp_settings didn't return an ntpserver list. Only statically assigned servers are written to the chrony file. Reason for this seems to be, that /run/netconfig/NetworkManager.netconfig does not contain an entry NTPSERVERS. Where is this entry supposed to come from? nm itself knows about the ntpservers for an interface:
/usr/bin/nmcli --terse --fields "DHCP4.OPTION" connection show 25b6d1be-8a6b-4762-88da-cd27eb0a0c89 ... DHCP4.OPTION[10]:ntp_servers = 192.168.9.254 ...
Thx and bye. Michael.
On 11.03.2023 14:32, mh@mike.franken.de wrote:
Hi *,
I'm trying to understand, how netconfig and NetworkManager are playing together in openSUSE regarding ntpserver client settings.
NetworkManager calls "netconfig modify --service NetworkManager" and provides DNS settings. What netconfig does with it is out of scope for NetworkManager.
System is openSUSE Tumbleweed 20230308.
Excerpt from my journal:
NetworkManager[18524]: debug: ntp-runtime Module called NetworkManager[18524]: debug: Resolved ntp-policy 'auto' for service 'NetworkManager' to 'STATIC_FALLBACK NetworkManager' NetworkManager[18524]: debug: Static Fallback NetworkManager[18524]: debug: Use NetworkManager policy merged settings NetworkManager[18524]: debug: exec get_ntp_settings: /run/netconfig/ NetworkManager.netconfig NetworkManager[18524]: debug: get_ntp_settings: NTP_SERVER_LIST='' NetworkManager[18524]: debug: exit get_ntp_settings: /run/netconfig/ NetworkManager.netconfig NetworkManager[18524]: debug: write_chrony_servers: 192.168.1.1 NetworkManager[18524]: debug: ntp servers written to /run/netconfig/ chrony.servers NetworkManager[18524]: debug: write_ntpd_servers: 192.168.1.1 NetworkManager[18524]: debug: ntp servers written to /run/ntp/servers- netconfig
As I found out, there is an nm module /usr/libexec/netconfig/netconfig.d/ntp- runtime, that is responsible for supplying ntpservers to chrony. But there seems to be a problem retrieving dynamically by dhcp assigned ntpservers
I already told you on another list that NetworkManager does not provide and NTP related information to netconfig.
- in any case I tested, get_ntp_settings didn't return an ntpserver
list. Only statically assigned servers are written to the chrony file. Reason for this seems to be, that /run/netconfig/NetworkManager.netconfig does not contain an entry NTPSERVERS. Where is this entry supposed to come from?
It is not supposed to come from anywhere because NetworkManager does not use netconfig to manage NTP configuration.
nm itself knows about the ntpservers for an interface:
/usr/bin/nmcli --terse --fields "DHCP4.OPTION" connection show 25b6d1be-8a6b-4762-88da-cd27eb0a0c89 ... DHCP4.OPTION[10]:ntp_servers = 192.168.9.254 ...
Thx and bye. Michael.
On Samstag, 11. März 2023 13:38:21 CET Andrei Borzenkov wrote:
On 11.03.2023 14:32, mh@mike.franken.de wrote:
Hi *,
I'm trying to understand, how netconfig and NetworkManager are playing together in openSUSE regarding ntpserver client settings.
NetworkManager calls "netconfig modify --service NetworkManager" and provides DNS settings. What netconfig does with it is out of scope for NetworkManager.
Yep, so far I did understand that (hopefully).
[...]
As I found out, there is an nm module /usr/libexec/netconfig/netconfig.d/ntp- runtime, that is responsible for supplying ntpservers to chrony. But there seems to be a problem retrieving dynamically by dhcp assigned ntpservers
I already told you on another list that NetworkManager does not provide and NTP related information to netconfig.
[...]
It is not supposed to come from anywhere because NetworkManager does not use netconfig to manage NTP configuration.
This is, what I observed. What's confusing me, is that netconfig seems to rely on getting ntp information from nm!?!? At least the ntp-config module tries to read it from NetworkManager.netconfig. This is the reason, why I now asked on an openSUSE list instead of the nm list.
[...]
Thx and bye. Michael.
On 11.03.2023 15:47, mh@mike.franken.de wrote:
What's confusing me, is that netconfig seems to rely on getting ntp information from nm!?!?
You seem to believe that netconfig was developed for NetworkManager. netconfig existed long before NetworkManager in SLE. NetworkManager is just one of possible source of information.
At least the ntp-config module tries to read it from NetworkManager.netconfig.
ntp-config tries to read from the sources according to the configured policies. Default policy if NetworkManager is active includes information from NetworkManager. Whether NetworkManager actually provides any meaningful data for this specific netconfig module is entirely different question. You can redefine netconfig NTP policy to omit NetworkManager (or to ignore NTP completely).
This is all documented in "man 8 netconfig".
This is the reason, why I now asked on an openSUSE list instead of the nm list.
Well, actually *this* is the question for NetworkManager. NetworkManager does not have any framework for managing dynamic NTP informational at all, so there is no way to feed it to netconfig. It has to be implemented in NetworkManager first.
On 11.03.2023 16:02, Andrei Borzenkov wrote:
Well, actually *this* is the question for NetworkManager. NetworkManager does not have any framework for managing dynamic NTP informational at all, so there is no way to feed it to netconfig. It has to be implemented in NetworkManager first.
And if it is implemented in NetworkManager, it will "just work" in netconfig exactly because netconfig already reads information from NetworkManager. So any enhancements need to go into NetworkManager.
On Samstag, 11. März 2023 14:02:42 CET Andrei Borzenkov wrote:
On 11.03.2023 15:47, mh@mike.franken.de wrote:
What's confusing me, is that netconfig seems to rely on getting ntp information from nm!?!?
You seem to believe that netconfig was developed for NetworkManager. netconfig existed long before NetworkManager in SLE. NetworkManager is just one of possible source of information.
No, this is not what I believe. I know that netconfig is much older, because I use SuSE Linux for at least 25 years.
At least the ntp-config module tries to read it from NetworkManager.netconfig.
ntp-config tries to read from the sources according to the configured policies. Default policy if NetworkManager is active includes information from NetworkManager. Whether NetworkManager actually provides any meaningful data for this specific netconfig module is entirely different question. You can redefine netconfig NTP policy to omit NetworkManager (or to ignore NTP completely).
This is all documented in "man 8 netconfig".
I know this and I read this man page among dozens of other documents including the nm docs on the website. But obviously I can't express myself correctly 8-<
This is the reason, why I now asked on an openSUSE list instead of the nm list.
Well, actually *this* is the question for NetworkManager. NetworkManager does not have any framework for managing dynamic NTP informational at all, so there is no way to feed it to netconfig. It has to be implemented in NetworkManager first.
Why is this the question for nm? The question for me is, why netconfig relies on a value from NetworkManager.netconfig, that is never provided? What makes netconfig believe it can get the value from there, if it is a known fact, that the necessary enhancement never made it to nm?
Bye. Michael.
On 12.03.2023 01:37, mh@mike.franken.de wrote:
Why is this the question for nm? The question for me is, why netconfig relies on a value from NetworkManager.netconfig, that is never provided?
netconfig does not "rely" on anything.
What makes netconfig believe it can get the value from there,
You as administrator of your system told netconfig to look at the information provided by NetworkManager. Even if it was just by your silent consent to use default policy (you claimed to have read netconfig documentation so you are aware about default policy).
Why would anyone waste time implementing special case for NTP and NetworkManager? What exactly will it fix? What is the exact difference between "no data provided by NetworkManger" and "do not check data from NetworkManager"? In both cases netconfig continues to use other sources of information according to configured policy.
What exact problem in netconfig are you trying to solve beyond "NetworkManager does not have ability to manage dynamic NTP information"?
On Sonntag, 12. März 2023 08:02:29 CET Andrei Borzenkov wrote:
On 12.03.2023 01:37, mh@mike.franken.de wrote:
Why is this the question for nm? The question for me is, why netconfig relies on a value from NetworkManager.netconfig, that is never provided?
netconfig does not "rely" on anything.
Maybe "rely" is too strong, but how would you call the fact, that ntp-config wants to read NTPSERVERS from NetworkManager.netconfig and in fact also reads the DNS variables from this file?
What makes netconfig believe it can get the value from there,
You as administrator of your system told netconfig to look at the information provided by NetworkManager. Even if it was just by your silent consent to use default policy (you claimed to have read netconfig documentation so you are aware about default policy).
Ok, so maybe the question is: Why is the behaviour of the default policy as it is?
According to the man page (that you already mentioned) the default policy is "auto", whcih means:
The auto policy value is resolved to "STATIC_FALLBACK NetworkManager" causing to use the NetworkManager built-in merge policy with a fallback to the static settings defined in netconfig variables when the NetworkManager does not provide any. Note: NetworkManager is not using any of the statically defined netconfig settings.
Which means this policy is using some features from nm. Of course this is, what the admin (me) wanted, otherwise he would have changed it. But this decision implies the use of the nm module ntp-config, which can only be prohibited by modifying or deleting it, but which is part of the distribution itself.
Why would anyone waste time implementing special case for NTP and NetworkManager? What exactly will it fix? What is the exact difference between "no data provided by NetworkManger" and "do not check data from NetworkManager"? In both cases netconfig continues to use other sources of information according to configured policy.
What exact problem in netconfig are you trying to solve beyond "NetworkManager does not have ability to manage dynamic NTP information"?
You still misunderstand my intentions. I don't want anything to be changed or "fixed". I want to understand, why things are as they are - mostly to implement my things in a better or more conformable way. And using something from a script/module, that can never exist, seemed senseless to me, so I tried to verify, if it is senseless or my understanding is wrong.
Bye. Michael.
On 2023-03-12 10:58, mh@mike.franken.de wrote:
On Sonntag, 12. März 2023 08:02:29 CET Andrei Borzenkov wrote:
On 12.03.2023 01:37, mh@mike.franken.de wrote:
Why would anyone waste time implementing special case for NTP and NetworkManager? What exactly will it fix? What is the exact difference between "no data provided by NetworkManger" and "do not check data from NetworkManager"? In both cases netconfig continues to use other sources of information according to configured policy.
What exact problem in netconfig are you trying to solve beyond "NetworkManager does not have ability to manage dynamic NTP information"?
You still misunderstand my intentions. I don't want anything to be changed or "fixed". I want to understand, why things are as they are - mostly to implement my things in a better or more conformable way. And using something from a script/module, that can never exist, seemed senseless to me, so I tried to verify, if it is senseless or my understanding is wrong.
I don't understand what is going on, but let me say something I heard somewhere long ago.
It was the idea that the network administrator (on an enterprise building, say), would install a time server, and wanted this server to be published via DHCP so that all machines in the building would know about it and sync to it.
I assume they were using Windows. Indeed, Microsoft covers this.
https://www.greyware.com/software/domaintime/v5/installation/dhcp.asp
How to use DHCP Servers to specify time server addresses to Domain Time Client
Domain Time II Client using automatic discovery mode can be configured to check for the presence of a DHCP server on the local subnet. If a DHCP server is found, the DHCP options 004 and/or 042 can be examined to provide the IP address(es) of time servers for the Client to use.
Note: It is not necessary to set the TCP/IP protocol stack to get its IP address from a DHCP server in order for the Domain Time II Client to get a time server address. The Client uses its own independent inquiry of the DHCP server to discover the time server options. Therefore DHCP discovery of time servers can be used on a machine with either a static or a DHCP-assigned IP address.
An automatic Domain Time client with DHCP enabled will broadcast to locate a DHCP Server. Note that DHCP broadcasts usually do not cross routers.
On Sonntag, 12. März 2023 12:08:52 CET Carlos E. R. wrote:
On 2023-03-12 10:58, mh@mike.franken.de wrote:
[...]
You still misunderstand my intentions. I don't want anything to be changed or
"fixed". I want to understand, why things are as they are - mostly to
implement my things in a better or more conformable way. And using something from a script/module, that can never exist, seemed senseless to me, so I tried to verify, if it is senseless or my understanding
is wrong.
I don't understand what is going on, but let me say something I heard somewhere long ago.
It was the idea that the network administrator (on an enterprise building, say), would install a time server, and wanted this server to be published via DHCP so that all machines in the building would know about it and sync to it.
Thx for your answer, but I have a working setup with systemd-timesyncd and a Networker dispatcher script for DHCP connections. The following website has an example: https://wiki.archlinux.org/title/ NetworkManager#Dynamically_set_NTP_servers_received_via_DHCP_with_systemd- timesyncd
I observed, though, that for static interface configurations this won't work, because nm doesn't have an ntp server address for the connection. So I tried to find out, what would be the best way to configure this. During my research I came across nm and netconfig config files and tried to understand, how they are playing together, and if I could make use of any setting they provide for static interface settings.
[...]
An automatic Domain Time client with DHCP enabled will broadcast tolocate a DHCP Server. Note that DHCP broadcasts usually do not cross routers.
AFAIK systemd-timesyncd doesn't do this.
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
Bye. Michael.
Hi,
in case anyone needs this functionality:
function ntp2timesyncd { # add ntp servers to systemd-timesyncd MYACTION="$1" CON_UUID="$2" [ -z "$MYACTION" -o -z "$CON_UUID" ] && return
_svc="systemd-timesyncd" if [ "$( ${SYSCTL} is-enabled ${_svc}.service )" = "enabled" ] # { then NTPCFGD="/etc/systemd/timesyncd.conf.d" mkdir -p "$NTPCFGD" [ -d "$NTPCFGD" ] || return NTPCFG="${NTPCFGD}/${CON_UUID}.conf" RST=0 case "$MYACTION" in # { down|vpn-down) /usr/bin/rm -f "$NTPCFG" RST=1 ;; up|vpn-up|dhcp4-change|dhcp6-change) _NTP="${DHCP4_NTP_SERVERS} ${DHCP6_NTP_SERVER}" # if no ntpservers provided by dhcp, try to get them from the # static netconfig configuration if [ -z $_NTP ] then NCNETCFG="/etc/sysconfig/network/config" [ -n "$NCNETCFG" -a -r "$NCNETCFG" ] \ && source <( cat "$NCNETCFG" \ | grep "^NETCONFIG_NTP_STATIC_SERVERS=" \ ) _NTP="$NETCONFIG_NTP_STATIC_SERVERS" fi [ -z $_NTP ] && return _NTP=$( echo "$_NTP" | sed -r -e "s/\s+$//" ) echo "[Time]" >"$NTPCFG" echo "NTP=${_NTP}" >>"$NTPCFG" RST=1 ;; esac # } [ "$RST" -eq 1 -a \ $( ${SYSCTL} is-active ${_svc}.service ) = "active" ] \ && ${SYSCTL} restart ${_svc}.service >/dev/null 2>&1 & fi # } } # // end ntp2timesyncd
If anyone has any improvement or critics ...
Bye. Michael.
On 2023-03-12 13:38, mh@mike.franken.de wrote:
Hi,
in case anyone needs this functionality:
function ntp2timesyncd { # add ntp servers to systemd-timesyncd MYACTION="$1" CON_UUID="$2" [ -z "$MYACTION" -o -z "$CON_UUID" ] && return
_svc="systemd-timesyncd" if [ "$( ${SYSCTL} is-enabled ${_svc}.service )" = "enabled" ] # { then NTPCFGD="/etc/systemd/timesyncd.conf.d" mkdir -p "$NTPCFGD" [ -d "$NTPCFGD" ] || return NTPCFG="${NTPCFGD}/${CON_UUID}.conf" RST=0 case "$MYACTION" in # { down|vpn-down) /usr/bin/rm -f "$NTPCFG" RST=1 ;; up|vpn-up|dhcp4-change|dhcp6-change) _NTP="${DHCP4_NTP_SERVERS} ${DHCP6_NTP_SERVER}" # if no ntpservers provided by dhcp, try to get them from the # static netconfig configuration if [ -z $_NTP ] then NCNETCFG="/etc/sysconfig/network/config" [ -n "$NCNETCFG" -a -r "$NCNETCFG" ] \ && source <( cat "$NCNETCFG" \ | grep "^NETCONFIG_NTP_STATIC_SERVERS=" \ ) _NTP="$NETCONFIG_NTP_STATIC_SERVERS" fi
Wouldn't
. /etc/sysconfig/network/config
work? Then just test/use $NETCONFIG_NTP_STATIC_SERVERS
On Sonntag, 12. März 2023 13:47:53 CET Carlos E. R. wrote: [...]
Wouldn't
. /etc/sysconfig/network/config
work? Then just test/use $NETCONFIG_NTP_STATIC_SERVERS
I didn't want to have all vars from /etc/sysconfig/network/config in my namespace.
-- Cheers / Saludos,
Carlos E. R. (from 15.4 x86_64 at Telcontar)
Bye. Michael.
On Sun, 12 Mar 2023 14:24:31 +0100 mh@mike.franken.de wrote:
On Sonntag, 12. März 2023 13:47:53 CET Carlos E. R. wrote: [...]
Wouldn't
. /etc/sysconfig/network/config
work? Then just test/use $NETCONFIG_NTP_STATIC_SERVERS
I didn't want to have all vars from /etc/sysconfig/network/config in my namespace.
So do it in a subshell? Or equivalent technique.
On Sonntag, 12. März 2023 17:14:27 CET Dave Howorth wrote:
On Sun, 12 Mar 2023 14:24:31 +0100
mh@mike.franken.de wrote:
On Sonntag, 12. März 2023 13:47:53 CET Carlos E. R. wrote: [...]
Wouldn't
. /etc/sysconfig/network/config
work? Then just test/use $NETCONFIG_NTP_STATIC_SERVERS
I didn't want to have all vars from /etc/sysconfig/network/config in my namespace.
So do it in a subshell? Or equivalent technique.
Yep, of course this would also be possible, but what is wrong with
source <( cat "$NCNETCFG" \ | grep "^NETCONFIG_NTP_STATIC_SERVERS=" \ )
? Takes too much time? Is too bash specific?
On Sun, 12 Mar 2023, 17:24:35 +0100, mh@mike.franken.de wrote:
On Sonntag, 12. März 2023 17:14:27 CET Dave Howorth wrote:
On Sun, 12 Mar 2023 14:24:31 +0100
mh@mike.franken.de wrote:
On Sonntag, 12. März 2023 13:47:53 CET Carlos E. R. wrote: [...]
Wouldn't
. /etc/sysconfig/network/config
work? Then just test/use $NETCONFIG_NTP_STATIC_SERVERS
I didn't want to have all vars from /etc/sysconfig/network/config in my namespace.
So do it in a subshell? Or equivalent technique.
Yep, of course this would also be possible, but what is wrong with
source <( cat "$NCNETCFG" \ | grep "^NETCONFIG_NTP_STATIC_SERVERS=" \ )
? Takes too much time? Is too bash specific?
If you know where this would have to be put into, why don't you propose a suitable patch? It appears you are mostly worried about this, while others don't, so...
Cheers.
l8er manfred
On 2023-03-12 14:24, mh@mike.franken.de wrote:
On Sonntag, 12. März 2023 13:47:53 CET Carlos E. R. wrote: [...]
Wouldn't
. /etc/sysconfig/network/config
work? Then just test/use $NETCONFIG_NTP_STATIC_SERVERS
I didn't want to have all vars from /etc/sysconfig/network/config in my namespace.
Oh.
cer@Telcontar:~> egrep -v "^[[:space:]]*$|^#" /etc/sysconfig/network/config | wc -l 41 cer@Telcontar:~>
Ok :-)
-
Andrei Borzenkov -
Carlos E. R. -
Dave Howorth -
Manfred Hollstein -
mh＠mike.franken.de