[opensuse-factory] Why is systemd-networkd included at all if it is unusable?
see $SUBJECT. https://bugzilla.opensuse.org/show_bug.cgi?id=1018387 is open for over than one year, nobody even attempts to fix it. Even more: because of a bug / issue in another place (live image building), systemd-networkd is kept unusable. Then let's at least be honest and disable sytemd-networkd. We are making a mockery of ourselves by shipping unusable stuff. Last week, I attended a workshop on how to use systemd-networkd. Of course the trainer advised everyone not to use openSUSE but Arch, fedora, ... you name it, because "SUSE does not even include it" (he was used to SLES12...). I convinced everyone that current openSUSE and SLES versions do include it. Only to find out, directly afterwards, that it's unusable. And when I try to fix it (https://build.opensuse.org/request/show/616099), it gets declined because the maintainer (who has done nothing about this bug for over one year) wants a perfect solution, not a working one. Never ever again complain why not enough people are willing to fix up things. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Never ever again complain why not enough people are willing to fix up things.
I share your feeling Stefan, and in the meantime, still believe there will be a complete solution. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe supporter GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/11/2018 09:22 PM, Stefan Seyfried wrote:
https://bugzilla.opensuse.org/show_bug.cgi?id=1018387 is open for over than one year, nobody even attempts to fix it.
I looked at the original bug report and at first look, the symbolic link is just wrong. /etc/resolv.conf should point to /run/systemd/ resolve/resolv.conf: root@tirpitz:~> ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 32 Apr 27 2016 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf root@tirpitz:~>
Even more: because of a bug / issue in another place (live image building), systemd-networkd is kept unusable.
That's a shame. I like systemd-networkd and -resolved, it just works(TM). I use it on lots of the buildds I am maintaining for Debian Ports and I never ran into any issues. It works on any architecture, even on my Amiga 4000 with Debian unstable ;).
Last week, I attended a workshop on how to use systemd-networkd. Of course the trainer advised everyone not to use openSUSE but Arch, fedora, ... you name it, because "SUSE does not even include it" (he was used to SLES12...).
Works on Debian as well.
I convinced everyone that current openSUSE and SLES versions do include it. Only to find out, directly afterwards, that it's unusable.
That's a pity, really.
And when I try to fix it (https://build.opensuse.org/request/show/616099), it gets declined because the maintainer (who has done nothing about this bug for over one year) wants a perfect solution, not a working one.
Hmm, I would also agree to rather fix the actual bug instead of adding a hack. I don't quite understand what the original issue is that we don't use the proper symlink that upstream uses. If the fix involves upstream work, I can help with that. I have contributed something like 10 patches to systemd upstream in the past. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> [06-11-18 15:45]:
On 06/11/2018 09:22 PM, Stefan Seyfried wrote:
https://bugzilla.opensuse.org/show_bug.cgi?id=1018387 is open for over than one year, nobody even attempts to fix it.
I looked at the original bug report and at first look, the symbolic link is just wrong. /etc/resolv.conf should point to /run/systemd/ resolve/resolv.conf:
root@tirpitz:~> ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 32 Apr 27 2016 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf root@tirpitz:~>
that's somewhat odd or just plain not so. I have been running Tumbleweed since before it was called that and /etc/resolv.conf has never been a sym-link. it has always been a file. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/11/2018 10:16 PM, Patrick Shanahan wrote:
* John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> [06-11-18 15:45]:
On 06/11/2018 09:22 PM, Stefan Seyfried wrote:
https://bugzilla.opensuse.org/show_bug.cgi?id=1018387 is open for over than one year, nobody even attempts to fix it.
I looked at the original bug report and at first look, the symbolic link is just wrong. /etc/resolv.conf should point to /run/systemd/ resolve/resolv.conf:
root@tirpitz:~> ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 32 Apr 27 2016 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf root@tirpitz:~>
that's somewhat odd or just plain not so. I have been running Tumbleweed since before it was called that and /etc/resolv.conf has never been a sym-link. it has always been a file.
Whether it's a file or a symlink depends on the type of network management you are using, of course. It's a symbolic link for network-manager, systemd- resolved and - if I remember correctly - dhclient. The location /etc/resolv.conf is basically just kept for compatibility reasons. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> [06-11-18 16:48]:
On 06/11/2018 10:16 PM, Patrick Shanahan wrote:
* John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> [06-11-18 15:45]:
On 06/11/2018 09:22 PM, Stefan Seyfried wrote:
https://bugzilla.opensuse.org/show_bug.cgi?id=1018387 is open for over than one year, nobody even attempts to fix it.
I looked at the original bug report and at first look, the symbolic link is just wrong. /etc/resolv.conf should point to /run/systemd/ resolve/resolv.conf:
root@tirpitz:~> ls -l /etc/resolv.conf lrwxrwxrwx 1 root root 32 Apr 27 2016 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf root@tirpitz:~>
that's somewhat odd or just plain not so. I have been running Tumbleweed since before it was called that and /etc/resolv.conf has never been a sym-link. it has always been a file.
Whether it's a file or a symlink depends on the type of network management you are using, of course. It's a symbolic link for network-manager, systemd- resolved and - if I remember correctly - dhclient.
The location /etc/resolv.conf is basically just kept for compatibility reasons.
# systemctl status NetworkManager ● NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/NetworkManager.service.d └─NetworkManager-ovs.conf Active: active (running) since Sat 2018-06-09 12:03:00 EDT; 2 days ago Docs: man:NetworkManager(8) Main PID: 1062 (NetworkManager) Tasks: 3 (limit: 4915) CGroup: /system.slice/NetworkManager.service └─1062 /usr/sbin/NetworkManager --no-daemon Jun 11 12:55:07 toshiba NetworkManager[1062]: <info> [1528736107.7629] device (wlp7s0): Activation: successful, device activated. Jun 11 12:55:08 toshiba NetworkManager[1062]: <info> [1528736108.0413] manager: NetworkManager state is now CONNECTED_GLOBAL Jun 11 12:55:09 toshiba NetworkManager[1062]: <info> [1528736109.4209] policy: set 'ATT5Q3n7V4_Ext2' (wlp7s0) as default for IPv6 routing and DNS Jun 11 12:55:09 toshiba dns-resolver[25657]: You can find my version in /etc/resolv.conf.netconfig Jun 11 12:55:09 toshiba NetworkManager[1062]: <13>Jun 11 12:55:09 dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Jun 11 12:55:09 toshiba NetworkManager[1062]: <13>Jun 11 12:55:09 dns-resolver: You can find my version in /etc/resolv.conf.netconfig Jun 11 12:55:09 toshiba NetworkManager[1062]: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Jun 11 12:55:09 toshiba NetworkManager[1062]: You can find my version in /etc/resolv.conf.netconfig ... Jun 11 12:55:09 toshiba NetworkManager[1062]: nisdomainname: you must be root to change the domain name Jun 11 12:55:09 toshiba NetworkManager[1062]: <warn> [1528736109.5812] dns-mgr: could not commit DNS changes: Error calling netconfig: exited with status 20 ls -la /etc/resolv.conf -rw-r--r-- 1 root root 900 Jun 11 16:57 /etc/resolv.conf -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/11/2018 11:02 PM, Patrick Shanahan wrote:
# systemctl status NetworkManager ● NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/NetworkManager.service.d └─NetworkManager-ovs.conf Active: active (running) since Sat 2018-06-09 12:03:00 EDT; 2 days ago Docs: man:NetworkManager(8) Main PID: 1062 (NetworkManager) Tasks: 3 (limit: 4915) CGroup: /system.slice/NetworkManager.service └─1062 /usr/sbin/NetworkManager --no-daemon
Jun 11 12:55:07 toshiba NetworkManager[1062]: <info> [1528736107.7629] device (wlp7s0): Activation: successful, device activated. Jun 11 12:55:08 toshiba NetworkManager[1062]: <info> [1528736108.0413] manager: NetworkManager state is now CONNECTED_GLOBAL Jun 11 12:55:09 toshiba NetworkManager[1062]: <info> [1528736109.4209] policy: set 'ATT5Q3n7V4_Ext2' (wlp7s0) as default for IPv6 routing and DNS Jun 11 12:55:09 toshiba dns-resolver[25657]: You can find my version in /etc/resolv.conf.netconfig Jun 11 12:55:09 toshiba NetworkManager[1062]: <13>Jun 11 12:55:09 dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here is the important part.
Jun 11 12:55:09 toshiba NetworkManager[1062]: <13>Jun 11 12:55:09 dns-resolver: You can find my version in /etc/resolv.conf.netconfig Jun 11 12:55:09 toshiba NetworkManager[1062]: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Jun 11 12:55:09 toshiba NetworkManager[1062]: You can find my version in /etc/resolv.conf.netconfig ... Jun 11 12:55:09 toshiba NetworkManager[1062]: nisdomainname: you must be root to change the domain name Jun 11 12:55:09 toshiba NetworkManager[1062]: <warn> [1528736109.5812] dns-mgr: could not commit DNS changes: Error calling netconfig: exited with status 20
ls -la /etc/resolv.conf -rw-r--r-- 1 root root 900 Jun 11 16:57 /etc/resolv.conf
Yes, because network-manager detected that another process has touched your resolv.conf :). Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> [06-11-18 17:17]:
On 06/11/2018 11:02 PM, Patrick Shanahan wrote:
# systemctl status NetworkManager ● NetworkManager.service - Network Manager Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/NetworkManager.service.d └─NetworkManager-ovs.conf Active: active (running) since Sat 2018-06-09 12:03:00 EDT; 2 days ago Docs: man:NetworkManager(8) Main PID: 1062 (NetworkManager) Tasks: 3 (limit: 4915) CGroup: /system.slice/NetworkManager.service └─1062 /usr/sbin/NetworkManager --no-daemon
Jun 11 12:55:07 toshiba NetworkManager[1062]: <info> [1528736107.7629] device (wlp7s0): Activation: successful, device activated. Jun 11 12:55:08 toshiba NetworkManager[1062]: <info> [1528736108.0413] manager: NetworkManager state is now CONNECTED_GLOBAL Jun 11 12:55:09 toshiba NetworkManager[1062]: <info> [1528736109.4209] policy: set 'ATT5Q3n7V4_Ext2' (wlp7s0) as default for IPv6 routing and DNS Jun 11 12:55:09 toshiba dns-resolver[25657]: You can find my version in /etc/resolv.conf.netconfig Jun 11 12:55:09 toshiba NetworkManager[1062]: <13>Jun 11 12:55:09 dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here is the important part.
Jun 11 12:55:09 toshiba NetworkManager[1062]: <13>Jun 11 12:55:09 dns-resolver: You can find my version in /etc/resolv.conf.netconfig Jun 11 12:55:09 toshiba NetworkManager[1062]: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... Jun 11 12:55:09 toshiba NetworkManager[1062]: You can find my version in /etc/resolv.conf.netconfig ... Jun 11 12:55:09 toshiba NetworkManager[1062]: nisdomainname: you must be root to change the domain name Jun 11 12:55:09 toshiba NetworkManager[1062]: <warn> [1528736109.5812] dns-mgr: could not commit DNS changes: Error calling netconfig: exited with status 20
ls -la /etc/resolv.conf -rw-r--r-- 1 root root 900 Jun 11 16:57 /etc/resolv.conf
Yes, because network-manager detected that another process has touched your resolv.conf :).
only yast, not edited by hand. but if you wish, I *can* provide output that does not claim a modified /etc/resolv.conf and with networkmanager active still provides resolv.conf /as a file below /etc. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/11/2018 11:25 PM, Patrick Shanahan wrote:
Yes, because network-manager detected that another process has touched your resolv.conf :).
only yast, not edited by hand.
but if you wish, I *can* provide output that does not claim a modified /etc/resolv.conf and with networkmanager active still provides resolv.conf /as a file below /etc.
And you're still wrong, sorry.
From the NEWS file of NetworkManager:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS#n347
* Management of resolv.conf can be changed at runtime, private resolv.conf is always written in /run. * NetworkManager can now write DNS options to resolv.conf. * Added an option to enable the old-fashioned /etc/resolv.conf handling (using a symlink) You might want to Google the term "stateless system" so you understand why many modern plumberland parts are moving towards a read-only /etc and put runtime data into /run. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Dienstag, 12. Juni 2018 01:23:31 CEST John Paul Adrian Glaubitz wrote:
On 06/11/2018 11:25 PM, Patrick Shanahan wrote:
Yes, because network-manager detected that another process has touched your resolv.conf :).> only yast, not edited by hand.
but if you wish, I *can* provide output that does not claim a modified /etc/resolv.conf and with networkmanager active still provides resolv.conf /as a file below /etc.
And you're still wrong, sorry.
From the NEWS file of NetworkManager:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS#n347
* Management of resolv.conf can be changed at runtime, private resolv.conf is always written in /run. * NetworkManager can now write DNS options to resolv.conf. * Added an option to enable the old-fashioned /etc/resolv.conf handling (using a symlink)
You might want to Google the term "stateless system" so you understand why many modern plumberland parts are moving towards a read-only /etc and put runtime data into /run.
From the Networkmanager.conf manpage: rc-manager ---------- Set the resolv.conf management mode. The default value depends on NetworkManager build options, and this version of NetworkManager was build with a default of "netconfig". Regardless of this setting, NetworkManager will always write resolv.conf to its runtime state directory /run/NetworkManager/ resolv.conf. netconfig directly modifies /etc/resolf.conf Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019
On 06/12/2018 02:29 AM, Stefan Brüns wrote:
From the Networkmanager.conf manpage:
rc-manager ---------- Set the resolv.conf management mode. The default value depends on NetworkManager build options, and this version of NetworkManager was build with a default of "netconfig". Regardless of this setting, NetworkManager will always write resolv.conf to its runtime state directory /run/NetworkManager/ resolv.conf.
netconfig directly modifies /etc/resolf.conf
This is still considered legacy, see my reference to stateless systems with an unpopulated /etc directory. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
On 06/12/2018 02:29 AM, Stefan Brüns wrote:
From the Networkmanager.conf manpage:
rc-manager ---------- Set the resolv.conf management mode. The default value depends on NetworkManager build options, and this version of NetworkManager was build with a default of "netconfig". Regardless of this setting, NetworkManager will always write resolv.conf to its runtime state directory /run/NetworkManager/ resolv.conf.
netconfig directly modifies /etc/resolf.conf
This is still considered legacy, see my reference to stateless systems with an unpopulated /etc directory.
netconfig maintaining directly /etc/resolv.conf fits perfect with your stateless system and an unpopulated /etc/ directoy. It's neither legacy nor in conflict with this. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 02:22 PM, Thorsten Kukuk wrote:
This is still considered legacy, see my reference to stateless systems with an unpopulated /etc directory.
netconfig maintaining directly /etc/resolv.conf fits perfect with your stateless system and an unpopulated /etc/ directoy. It's neither legacy nor in conflict with this.
Putting runtime data into a runtime directory seems more reasonable to me than putting it into a configuration directory which is why most distributions are moving towards /run. But I don't want to delve into bike-shedding. I'm just reporting what upstream does and what most distributions use these days. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
But I don't want to delve into bike-shedding.
I'm just reporting what upstream does
Upstream is still using /etc/resolv.conf and I haven't seen any discussions to change that.
and what most distributions use these days.
All different four distributions I regular look at are still using /etc/resolv.conf. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 03:11 PM, Thorsten Kukuk wrote:
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
But I don't want to delve into bike-shedding.
I'm just reporting what upstream does
Upstream is still using /etc/resolv.conf and I haven't seen any discussions to change that.
So "old-fashioned" is the new NEW?
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS#n350
and what most distributions use these days.
All different four distributions I regular look at are still using /etc/resolv.conf.
At least Debian doesn't use /etc/resolv.conf but a symlink and I am quite confident Fedora doesn't do that either, see:
Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 03:23 PM, John Paul Adrian Glaubitz wrote:
On 06/12/2018 03:11 PM, Thorsten Kukuk wrote:
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
But I don't want to delve into bike-shedding.
I'm just reporting what upstream does
Upstream is still using /etc/resolv.conf and I haven't seen any discussions to change that.
So "old-fashioned" is the new NEW?
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS#n350
And here is the commit upstream:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=4805be...
dns-manager: make /etc/resolv.conf a symlink to /run/NetworkManager/resolv.conf.default Related: * https://bugzilla.gnome.org/show_bug.cgi?id=732941 * https://bugzilla.redhat.com/show_bug.cgi?id=1116999 Acked-By: Thomas Haller <thaller@redhat.com> Acked-By: Dan Williams <dcbw@redhat.com> Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
On 06/12/2018 03:23 PM, John Paul Adrian Glaubitz wrote:
On 06/12/2018 03:11 PM, Thorsten Kukuk wrote:
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
But I don't want to delve into bike-shedding.
I'm just reporting what upstream does
Upstream is still using /etc/resolv.conf and I haven't seen any discussions to change that.
So "old-fashioned" is the new NEW?
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS#n350
And here is the commit upstream:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=4805be...
NertworkManager is not the owner of /etc/resolv.conf, so this is not upstream (if they would be, they wouldn't need to create the symlink at all). It's only one project of many with a different opinion and implementation details. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 04:31 PM, Thorsten Kukuk wrote:
NertworkManager is not the owner of /etc/resolv.conf, so this is not upstream (if they would be, they wouldn't need to create the symlink at all). It's only one project of many with a different opinion and implementation details.
I never claimed that. I claimed that many resolvers these days, including NetworkManager, systemd-resolved and resolvconf set /etc/resolv.conf as a symbolic link these days and many distributions usually follow upstram in this regard. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
On 06/12/2018 04:31 PM, Thorsten Kukuk wrote:
NertworkManager is not the owner of /etc/resolv.conf, so this is not upstream (if they would be, they wouldn't need to create the symlink at all). It's only one project of many with a different opinion and implementation details.
I never claimed that.
To quote yourself: On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
I'm just reporting what upstream does
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
I claimed that many resolvers these days, including NetworkManager, systemd-resolved and resolvconf set /etc/resolv.conf as a symbolic link these days and many distributions usually follow upstram in this regard.
None of this are resolvers, all of this are nameserver proxys, configuration tools, or however you want to call them. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 04:37 PM, Thorsten Kukuk wrote:
I claimed that many resolvers these days, including NetworkManager, systemd-resolved and resolvconf set /etc/resolv.conf as a symbolic link these days and many distributions usually follow upstram in this regard.
None of this are resolvers, all of this are nameserver proxys, configuration tools, or however you want to call them.
You are splitting hairs. Does this change the fact that these tools set a symbolic instead of writing to a file? No. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
On 06/12/2018 04:37 PM, Thorsten Kukuk wrote:
I claimed that many resolvers these days, including NetworkManager, systemd-resolved and resolvconf set /etc/resolv.conf as a symbolic link these days and many distributions usually follow upstram in this regard.
None of this are resolvers, all of this are nameserver proxys, configuration tools, or however you want to call them.
You are splitting hairs. Does this change the fact that these tools set a symbolic instead of writing to a file? No.
Most problems arise as people speak about something else than what they mean. If you speak about configuration management tools, you should not write resolvers. So I'm not splitting haris, you are changing your wording as you like so that nobody can follow you and start a real discussion. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 05:11 PM, Thorsten Kukuk wrote:
Most problems arise as people speak about something else than what they mean. If you speak about configuration management tools, you should not write resolvers.
I used the wrong word in one context. That doesn't invalidate my whole argument.
So I'm not splitting haris, you are changing your wording as you like so that nobody can follow you and start a real discussion.
Yes, you are. Since I named the individual tools, you knew what I was talking about and there was no reason to assume an incorrect context. But again, I don't think this discussion leads to anything, it won't fix systemd-networkd/resolved in particular which is what this discussion was about in the first place. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 12 Jun 2018 15:29:54 +0200 John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
On 06/12/2018 03:23 PM, John Paul Adrian Glaubitz wrote:
On 06/12/2018 03:11 PM, Thorsten Kukuk wrote:
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
But I don't want to delve into bike-shedding.
I'm just reporting what upstream does
Upstream is still using /etc/resolv.conf and I haven't seen any discussions to change that.
So "old-fashioned" is the new NEW?
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS#n350
And here is the commit upstream:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=4805be...
dns-manager: make /etc/resolv.conf a symlink to /run/NetworkManager/resolv.conf.default Related:
* https://bugzilla.gnome.org/show_bug.cgi?id=732941 * https://bugzilla.redhat.com/show_bug.cgi?id=1116999
Acked-By: Thomas Haller <thaller@redhat.com> Acked-By: Dan Williams <dcbw@redhat.com>
Adrian
Please note that this change only one of backends for writting dns.resolv. Network manager currently support 5 backends and two use symlink ( default and systemd-resolved ), other two not and the last one does not modify it at all. So in fact part of backends find that useful, but not all of them. And also default backend can be configured to not use symlink. So it use symlink as default, but can operate also with file. see https://developer.gnome.org/NetworkManager/stable/NetworkManager.conf.html keys dns and rc-manager So some only some projects find useful to use symlink and even network manager have it only optional and not mandatory. But I am pretty sure that if we by default change to symlink many parts will break and it also will require non-trivial changes in YaST. Josef -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
On 06/12/2018 03:11 PM, Thorsten Kukuk wrote:
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
But I don't want to delve into bike-shedding.
I'm just reporting what upstream does
Upstream is still using /etc/resolv.conf and I haven't seen any discussions to change that.
So "old-fashioned" is the new NEW?
You only disqulify yourself with such comments. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 04:33 PM, Thorsten Kukuk wrote:
So "old-fashioned" is the new NEW?
You only disqulify yourself with such comments.
But making statements without being able to prove them is considered "qualified"? You claimed that NetworkManager doesn't set a symbolic link, I showed you the upstream commit and Fedora bug report which proves the opposite and instead of admitting I was right, your answer is to dismiss my opinion completely. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, John Paul Adrian Glaubitz wrote:
But making statements without being able to prove them is considered "qualified"?
I never did taht.
You claimed that NetworkManager doesn't set a symbolic link,
I never did that. In your first posts on which I answered you did never mention NetworkManager but "upstream". I spoke about "upstream", as you started with "upstream" which are glibc, bind, etc, but not some network configuration management tools only some people are using and are not even the standard tool. If "upstream" would change it, you wouldn't need /etc/resolv.conf as symlink. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 05:08 PM, Thorsten Kukuk wrote:
You claimed that NetworkManager doesn't set a symbolic link,
I never did that. In your first posts on which I answered you did never mention NetworkManager but "upstream".
I spoke about "upstream", as you started with "upstream" which are glibc, bind, etc, but not some network configuration management tools only some people are using and are not even the standard tool.
NetworkManager is a package in openSUSE which has an upstream project, hence the name upstream can be used in this context.
If "upstream" would change it, you wouldn't need /etc/resolv.conf as symlink.
That's not "upstream", that's basically the ABI which they can't change unless they want to break compatibility. But anyway, I'm leaving this discussion. It's not leading anywhere. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12.06.2018 01:23, John Paul Adrian Glaubitz wrote:
On 06/11/2018 11:25 PM, Patrick Shanahan wrote:
Yes, because network-manager detected that another process has touched your resolv.conf :).
only yast, not edited by hand.
but if you wish, I *can* provide output that does not claim a modified /etc/resolv.conf and with networkmanager active still provides resolv.conf /as a file below /etc.
And you're still wrong, sorry.
Maybe on $SOME_DISTRIBUTION_THAT_JUST_WORKS, but please look at a SUSE system first.
From the NEWS file of NetworkManager:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS#n347
* Management of resolv.conf can be changed at runtime, private resolv.conf is always written in /run. * NetworkManager can now write DNS options to resolv.conf. * Added an option to enable the old-fashioned /etc/resolv.conf handling (using a symlink)
You might want to Google the term "stateless system" so you understand why many modern plumberland parts are moving towards a read-only /etc and put runtime data into /run.
but not on SUSE/openSUSE AFAICT :-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 09:08 AM, Stefan Seyfried wrote:
On 12.06.2018 01:23, John Paul Adrian Glaubitz wrote:
On 06/11/2018 11:25 PM, Patrick Shanahan wrote:
Yes, because network-manager detected that another process has touched your resolv.conf :).
only yast, not edited by hand.
but if you wish, I *can* provide output that does not claim a modified /etc/resolv.conf and with networkmanager active still provides resolv.conf /as a file below /etc.
And you're still wrong, sorry.
Maybe on $SOME_DISTRIBUTION_THAT_JUST_WORKS, but please look at a SUSE system first.
Sure, some distributions are more progressed in adopting certain standards than others. However, I am confident that openSUSE will adopt a stateless /etc at some point in the future as well. It's just too useful for cloud and container instances to not use it.
From the NEWS file of NetworkManager:
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS#n347
* Management of resolv.conf can be changed at runtime, private resolv.conf is always written in /run. * NetworkManager can now write DNS options to resolv.conf. * Added an option to enable the old-fashioned /etc/resolv.conf handling (using a symlink)
You might want to Google the term "stateless system" so you understand why many modern plumberland parts are moving towards a read-only /etc and put runtime data into /run.
but not on SUSE/openSUSE AFAICT :-)
See above :). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Jun 12, Stefan Seyfried wrote:
On 12.06.2018 01:23, John Paul Adrian Glaubitz wrote:
You might want to Google the term "stateless system" so you understand why many modern plumberland parts are moving towards a read-only /etc and put runtime data into /run.
but not on SUSE/openSUSE AFAICT :-)
Welcome back from your winter sleep ;) Of course we are moving to a strict seperation of the different kind of data and did a lot of changes for that in the last months already. And this will include /etc, too. But it is not as simple as some people think. The biggest problem with /etc and "stateless" is, that most people go the cheap route: copy everything from somewhere else if /etc is empty. This does not solve any problem, but will only create new ones. Instead, there should be a directory like /usr/etc, which contains the original config files, and /etc only contains the changes. This would really solve a lot of problems and would make it easier to find out what was changed on the system. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Jun 11 2018, John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
Jun 11 12:55:07 toshiba NetworkManager[1062]: <info> [1528736107.7629] device (wlp7s0): Activation: successful, device activated. Jun 11 12:55:08 toshiba NetworkManager[1062]: <info> [1528736108.0413] manager: NetworkManager state is now CONNECTED_GLOBAL Jun 11 12:55:09 toshiba NetworkManager[1062]: <info> [1528736109.4209] policy: set 'ATT5Q3n7V4_Ext2' (wlp7s0) as default for IPv6 routing and DNS Jun 11 12:55:09 toshiba dns-resolver[25657]: You can find my version in /etc/resolv.conf.netconfig Jun 11 12:55:09 toshiba NetworkManager[1062]: <13>Jun 11 12:55:09 dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here is the important part.
Run netconfig update -f to fix that. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Andreas Schwab <schwab@suse.de> [06-12-18 02:59]:
On Jun 11 2018, John Paul Adrian Glaubitz <adrian.glaubitz@suse.com> wrote:
Jun 11 12:55:07 toshiba NetworkManager[1062]: <info> [1528736107.7629] device (wlp7s0): Activation: successful, device activated. Jun 11 12:55:08 toshiba NetworkManager[1062]: <info> [1528736108.0413] manager: NetworkManager state is now CONNECTED_GLOBAL Jun 11 12:55:09 toshiba NetworkManager[1062]: <info> [1528736109.4209] policy: set 'ATT5Q3n7V4_Ext2' (wlp7s0) as default for IPv6 routing and DNS Jun 11 12:55:09 toshiba dns-resolver[25657]: You can find my version in /etc/resolv.conf.netconfig Jun 11 12:55:09 toshiba NetworkManager[1062]: <13>Jun 11 12:55:09 dns-resolver: ATTENTION: You have modified /etc/resolv.conf. Leaving it untouched... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here is the important part.
Run netconfig update -f to fix that.
which creates another /etc/resolv.conf, but subsequent systemctl status NetworkManager still results in the ATTENTION: You have modified messages. just tested. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 11.06.2018 21:43, John Paul Adrian Glaubitz wrote:
Hmm, I would also agree to rather fix the actual bug instead of adding a hack. I don't quite understand what the original issue is that we don't use the proper symlink that upstream uses.
The problem is that, as openSUSE does not use systemd-networkd/resolved but wicked by default, this symlink leads to a non-working name resolution in default configuration. tmpfiles.d/etc.conf, when resolved is enabled at systemd build, creates the symlink on boot, if /etc/resolv.conf does not exist. Every "standard" SUSE installation has /etc/resolv.conf, created by yast/whatever. The Live iso, created by kiwi has no resolv.conf. If resolved is *enabled* at boot, tmpfiles.d/etc.conf will create the symlink, but networkd/resolved will not be used. Life will be bad.
If the fix involves upstream work, I can help with that. I have contributed something like 10 patches to systemd upstream in the past.
I have just commented out the symlink creation in tmpfiles.d/etc.conf, allowing to build resolved without breaking name resolution for default setups. I'm not arguing (anymore, as it will not be heard anyway) the crazy wicked default, but I would really like to have the option of using systemd-networkd. And if "we" do not want to give that option to users, then at least be honest and remove systemd-networkd from sytemd pacakge, so that everone knows they just should go and use $SOME_OTHER_DISTRIBUTION_THAT_WORKS. My solution was not acceptable to (one of) the systemd maintainer(s), and a proper solution seems overly complicated (hack the tmpfiles.d code to first check if networkd/resolved is enabled) for upstream to accept it for no visible gain. Another solution would be to fix image building to just create an empty(?) resolv.conf in the image. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/12/2018 09:06 AM, Stefan Seyfried wrote:
On 11.06.2018 21:43, John Paul Adrian Glaubitz wrote:
Hmm, I would also agree to rather fix the actual bug instead of adding a hack. I don't quite understand what the original issue is that we don't use the proper symlink that upstream uses.
The problem is that, as openSUSE does not use systemd-networkd/resolved but wicked by default, this symlink leads to a non-working name resolution in default configuration.
Nothing unusual. Debian defaults to NetworkManager on desktop/laptops and to ifupdown on other systems by default.
tmpfiles.d/etc.conf, when resolved is enabled at systemd build, creates the symlink on boot, if /etc/resolv.conf does not exist.
I usually just follow the instructions from the Arch Wiki on Debian:
I haven't tried that on openSUSE yet.
Every "standard" SUSE installation has /etc/resolv.conf, created by yast/whatever.
The Live iso, created by kiwi has no resolv.conf. If resolved is *enabled* at boot, tmpfiles.d/etc.conf will create the symlink, but networkd/resolved will not be used. Life will be bad.
I see, thanks for summarizing the bug.
If the fix involves upstream work, I can help with that. I have contributed something like 10 patches to systemd upstream in the past.
I have just commented out the symlink creation in tmpfiles.d/etc.conf, allowing to build resolved without breaking name resolution for default setups.
I'm not arguing (anymore, as it will not be heard anyway) the crazy wicked default, but I would really like to have the option of using systemd-networkd.
I agree. systemd-networkd *should* be usable as customers certainly expect it to work, in particular in cloud instances or containers for which it was specifically designed.
And if "we" do not want to give that option to users, then at least be honest and remove systemd-networkd from sytemd pacakge, so that everone knows they just should go and use $SOME_OTHER_DISTRIBUTION_THAT_WORKS.
No, I think that should definitely get fixed.
My solution was not acceptable to (one of) the systemd maintainer(s), and a proper solution seems overly complicated (hack the tmpfiles.d code to first check if networkd/resolved is enabled) for upstream to accept it for no visible gain.
I have to admit, I have never used the tmpfiles.d mechanism and the machines where I used systemd-networkd don't have an /etc/tmpfiles.d/etc.conf which creates the symlink, so I had to create the symlink manually.
Another solution would be to fix image building to just create an empty(?) resolv.conf in the image.
That would probably work, too. Adrian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 11-06-2018 a las 15:22, Stefan Seyfried escribió:
see $SUBJECT.
https://bugzilla.opensuse.org/show_bug.cgi?id=1018387 is open for over than one year, nobody even attempts to fix it.
Even more: because of a bug / issue in another place (live image building), systemd-networkd is kept unusable.
Then let's at least be honest and disable sytemd-networkd. We are making a mockery of ourselves by shipping unusable stuff.
I use it everyday.. removing it will break my workflow.. what part is unusable to you.. I use it for basic networking only..(DHCP, static IP.. nothing fancy). There is one situation where I need resolved that I have to build it myself. it is included in all systemd based distros except *SUSE..for reasons best known to $DEITY, whatever the problem is/was is pretty moot because resolved does not enter into the mix unless the administrator manually changes nsswitch.conf. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 12.06.2018 00:04, Cristian Rodríguez wrote:
El 11-06-2018 a las 15:22, Stefan Seyfried escribió:
see $SUBJECT.
https://bugzilla.opensuse.org/show_bug.cgi?id=1018387 is open for over than one year, nobody even attempts to fix it.
Even more: because of a bug / issue in another place (live image building), systemd-networkd is kept unusable.
Then let's at least be honest and disable sytemd-networkd. We are making a mockery of ourselves by shipping unusable stuff.
I use it everyday.. removing it will break my workflow.. what part is unusable to you.. I use it for basic networking only..(DHCP, static IP.. nothing fancy).
How do you configure it to write resolv.conf from DHCP reply? I read the documentation that systemd-resolved is needed for that. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 12-06-2018 a las 3:10, Stefan Seyfried escribió:
How do you configure it to write resolv.conf from DHCP reply? I read the documentation that systemd-resolved is needed for that.
I don't. I use a fixed list of known working and fast dns servers (from my location google DNS and Quad9 DNS are the fastest) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 12.06.2018 um 15:54 schrieb Cristian Rodríguez:
El 12-06-2018 a las 3:10, Stefan Seyfried escribió:
How do you configure it to write resolv.conf from DHCP reply? I read the documentation that systemd-resolved is needed for that.
I don't. I use a fixed list of known working and fast dns servers (from my location google DNS and Quad9 DNS are the fastest)
But they won't resolve my hosts at home or at work. So for a "normal" setup, systemd-networkd is mostly useless without systemd-resolved. One more package in home:seife:fixsuse to make things somewhat usable. "Excited" to see what will be next... -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2018-06-12 19:16, Stefan Seyfried wrote:
Am 12.06.2018 um 15:54 schrieb Cristian Rodríguez:
El 12-06-2018 a las 3:10, Stefan Seyfried escribió:
How do you configure it to write resolv.conf from DHCP reply? I read the documentation that systemd-resolved is needed for that.
I don't. I use a fixed list of known working and fast dns servers (from my location google DNS and Quad9 DNS are the fastest)
But they won't resolve my hosts at home or at work.
So for a "normal" setup, systemd-networkd is mostly useless without systemd-resolved.
I object. I have networkd running, without resolved, and it's anything but useless to me. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 12.06.2018 um 19:27 schrieb Jan Engelhardt:
So for a "normal" setup, systemd-networkd is mostly useless without systemd-resolved.
I object. I have networkd running, without resolved, and it's anything but useless to me.
How do you set nameservers received from DHCP? Yes, I know, you don't. But that's still the most common network setup, and one that should just work. Anyway, instead of reporting bugs, in the future I will just fix things in home:seife and not worry about the rest of the world anymore. Have a lot of fun... -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2018-06-12 19:29, Stefan Seyfried wrote:
Am 12.06.2018 um 19:27 schrieb Jan Engelhardt:
So for a "normal" setup, systemd-networkd is mostly useless without systemd-resolved.
I object. I have networkd running, without resolved, and it's anything but useless to me.
How do you set nameservers received from DHCP?
I didn't say I am using it for DHCP...
But that's still the most common network setup
Possibly, but it's not the most commen setup *for servers*, which is what my use case is. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2018-06-12 19:29, Stefan Seyfried wrote:
Am 12.06.2018 um 19:27 schrieb Jan Engelhardt:
So for a "normal" setup, systemd-networkd is mostly useless without systemd-resolved.
I object. I have networkd running, without resolved, and it's anything but useless to me.
How do you set nameservers received from DHCP?
Yes, I know, you don't. But that's still the most common network setup, and one that should just work.
It works for me in 42.3 and Networkmanager. Only that I'm not happy with the result and I edit the file. In this setup I use today (15.0), I use wicked and my DNS is automatically filled in /etc/resolv.conf with my ISP servers. -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.0 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 12-06-2018 a las 13:16, Stefan Seyfried escribió:
One more package in home:seife:fixsuse to make things somewhat usable. "Excited" to see what will be next...
Frank fixed this issue now it seems. pkgs on home:fbui:systemd:Factory now contain resolved. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 13.06.2018 um 17:47 schrieb Cristian Rodríguez:
Frank fixed this issue now it seems. pkgs on home:fbui:systemd:Factory now contain resolved.
Doesn't help on Leap 15. I'll try to get it in via SLES ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/11/2018 11:04 PM, Cristian Rodríguez wrote:
El 11-06-2018 a las 15:22, Stefan Seyfried escribió:
see $SUBJECT.
https://bugzilla.opensuse.org/show_bug.cgi?id=1018387 is open for over than one year, nobody even attempts to fix it.
Even more: because of a bug / issue in another place (live image building), systemd-networkd is kept unusable.
Then let's at least be honest and disable sytemd-networkd. We are making a mockery of ourselves by shipping unusable stuff.
I use it everyday.. removing it will break my workflow.. what part is unusable to you.. I use it for basic networking only..(DHCP, static IP.. nothing fancy).
There is one situation where I need resolved that I have to build it myself. it is included in all systemd based distros except *SUSE..for reasons best known to $DEITY, whatever the problem is/was is pretty moot because resolved does not enter into the mix unless the administrator manually changes nsswitch.conf.
We are also using systemd-network in some OpenStack projects. It's shame that we don't have the 'resolved' part of it but that doesn't make systemd-networkd unusable. -- markos SUSE LINUX GmbH | GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409, Nürnberg
participants (12)
-
Andreas Schwab -
Bruno Friedmann -
Carlos E. R. -
Cristian Rodríguez -
Jan Engelhardt -
John Paul Adrian Glaubitz -
Josef Reidinger -
Markos Chandras -
Patrick Shanahan -
Stefan Brüns -
Stefan Seyfried -
Thorsten Kukuk