* John Paul Adrian Glaubitz [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

* John Paul Adrian Glaubitz [06-11-18 16:48]:

On 06/11/2018 10:16 PM, Patrick Shanahan wrote:

...

* John Paul Adrian Glaubitz [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

* John Paul Adrian Glaubitz [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 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 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 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: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 Acked-By: Dan Williams 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 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 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 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, 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 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 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 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

* Andreas Schwab [06-12-18 02:59]:

On Jun 11 2018, John Paul Adrian Glaubitz 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 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:

https://wiki.archlinux.org/index.php/systemd-networkd

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

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

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

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 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

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