[opensuse-factory] Tumbleweed 20200201 move of services file from /etc/services to /usr/etc/services
I know what is happening here in theory, but not all installed programs do. For example fetchmail stopped working after this update until I added a symlink to the old location. Is there a "proper" way to handle this apart from what I did? -- ============================ Roger Whittaker roger@disruptive.org.uk ============================ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2020-02-04 14:12, Roger Whittaker wrote:
I know what is happening here in theory, but not all installed programs do. For example fetchmail stopped working after this update until I added a symlink to the old location.
Is there a "proper" way to handle this apart from what I did?
I think the proper solution is to have netcfg provide exactly that kind of symlink. Just like we have /var/run and /etc/resolv.conf. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-02-04 at 14:38 +0100, Jan Engelhardt wrote:
On Tuesday 2020-02-04 14:12, Roger Whittaker wrote:
I know what is happening here in theory, but not all installed programs do. For example fetchmail stopped working after this update until I added a symlink to the old location.
Is there a "proper" way to handle this apart from what I did?
I think the proper solution is to have netcfg provide exactly that kind of symlink. Just like we have /var/run and /etc/resolv.conf.
No - the move of the files to /usr/etc is so that /etc stays clean for the admin to override things as he needs. And not to pullute it with symlinks. Please read my other mail in this thread. Working arund this issue with more workarounds is just not going to be the way forward. cheers, Dominique
On Tuesday 2020-02-04 15:01, Dominique Leuenberger / DimStar wrote:
Is there a "proper" way to handle this apart from what I did?
I think the proper solution is to have netcfg provide exactly that kind of symlink. Just like we have /var/run and /etc/resolv.conf.
No [... nsswitch ...]
Ah yes, the nsswitch feature. Some of those files under nsswitch control change soooo rarely — and most of the time, it is not even the user touching it, but some system-induced update —, I fell prey to momentarily believe they are not under nsswitch control. There might even be programs that operate the same. Luckily, fetchmail is not one of them. So, all good. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 02/04/2020 08:01 AM, Dominique Leuenberger / DimStar wrote:
On Tue, 2020-02-04 at 14:38 +0100, Jan Engelhardt wrote:
On Tuesday 2020-02-04 14:12, Roger Whittaker wrote:
I know what is happening here in theory, but not all installed programs do. For example fetchmail stopped working after this update until I added a symlink to the old location.
Is there a "proper" way to handle this apart from what I did?
I think the proper solution is to have netcfg provide exactly that kind of symlink. Just like we have /var/run and /etc/resolv.conf.
No - the move of the files to /usr/etc is so that /etc stays clean for the admin to override things as he needs. And not to pullute it with symlinks.
Please read my other mail in this thread. Working arund this issue with more workarounds is just not going to be the way forward.
Is this really warranted? When workarounds are needed to correct a new change -- there is a problem. And for 20+ years, every program that needs a specific port has looked to /etc/services. That means every program (other than those updated or patched by the opensuse team) will fail to find the services file in the new location (unless patched by the user) The Linux: Filesystem Hierarchy Standard (latest March 19, 2015 - 3.0) https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard States: "The following files, or symbolic links to files, must be in /etc if the corresponding subsystem is installed: ... services Port names for network services (optional) ..." It seems contrary to move a file from the position mandated by the Linux FHS -- David C. Rankin, J.D.,P.E.
On Wed, Feb 05, David C. Rankin wrote:
Is this really warranted? When workarounds are needed to correct a new change -- there is a problem. And for 20+ years, every program that needs a specific port has looked to /etc/services. That means every program (other than those updated or patched by the opensuse team) will fail to find the services file in the new location (unless patched by the user)
No application is reading /etc/services directly. They all use the glibc interface for this. No need to patch any application. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 6, 2020 at 8:44 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Wed, Feb 05, David C. Rankin wrote:
Is this really warranted? When workarounds are needed to correct a new change -- there is a problem. And for 20+ years, every program that needs a specific port has looked to /etc/services. That means every program (other than those updated or patched by the opensuse team) will fail to find the services file in the new location (unless patched by the user)
No application is reading /etc/services directly. They all use the glibc interface for this. No need to patch any application.
Tell that SAP installer which not only reads it directly but also modifies this file directly. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 06, Andrei Borzenkov wrote:
On Thu, Feb 6, 2020 at 8:44 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Wed, Feb 05, David C. Rankin wrote:
Is this really warranted? When workarounds are needed to correct a new change -- there is a problem. And for 20+ years, every program that needs a specific port has looked to /etc/services. That means every program (other than those updated or patched by the opensuse team) will fail to find the services file in the new location (unless patched by the user)
No application is reading /etc/services directly. They all use the glibc interface for this. No need to patch any application.
Tell that SAP installer which not only reads it directly but also modifies this file directly.
I'm pretty sure your SAP installer will not allow you to install on Tumbleweed at all. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 06.02.20 um 08:02 schrieb Thorsten Kukuk:
I'm pretty sure your SAP installer will not allow you to install on Tumbleweed at all.
...and SLES4SAP will ship a glibc with this /usr/etc stuff reverted... :-P -- 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 Thu, Feb 06, Stefan Seyfried wrote:
Am 06.02.20 um 08:02 schrieb Thorsten Kukuk:
I'm pretty sure your SAP installer will not allow you to install on Tumbleweed at all.
...and SLES4SAP will ship a glibc with this /usr/etc stuff reverted... :-P
Nobody knows if and when there will be the next SLES(4SAP) version and how Tumbleweed will look like, but we will clearly not revert the glibc changes in regard to /usr/etc, because this would really break customer systems ;) -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk schrieb am 06.02.20 um 08:02:
On Thu, Feb 06, Andrei Borzenkov wrote:
On Thu, Feb 6, 2020 at 8:44 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Wed, Feb 05, David C. Rankin wrote:
Is this really warranted? When workarounds are needed to correct a new change -- there is a problem. And for 20+ years, every program that needs a specific port has looked to /etc/services. That means every program (other than those updated or patched by the opensuse team) will fail to find the services file in the new location (unless patched by the user)
No application is reading /etc/services directly. They all use the glibc interface for this. No need to patch any application.
Tell that SAP installer which not only reads it directly but also modifies this file directly.
I'm pretty sure your SAP installer will not allow you to install on Tumbleweed at all.
It will. You only have to replace /etc/os-release with the corresponding file from SLES4SAP. At least for SAP HANA, this works. Werner --
On Fri, 2020-02-07 at 10:36 +0100, Werner Flamme wrote:
I'm pretty sure your SAP installer will not allow you to install on Tumbleweed at all.
It will. You only have to replace /etc/os-release with the corresponding file from SLES4SAP.
At least for SAP HANA, this works.
Please let us know how it goes when you file a support request for SAP for anything not working ;) Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown schrieb am 07.02.20 um 11:46:
On Fri, 2020-02-07 at 10:36 +0100, Werner Flamme wrote:
I'm pretty sure your SAP installer will not allow you to install on Tumbleweed at all.
It will. You only have to replace /etc/os-release with the corresponding file from SLES4SAP.
At least for SAP HANA, this works.
Please let us know how it goes when you file a support request for SAP for anything not working ;)
I use this for non-production HANA only. HANA is a very nice and admin-friendly part of software, at least compared to Oracle ;) So, it is very unlikely I'll ever have to open a bug against SAP :) Of course all my productive HANA and all application servers run on SLES. Conveniently, SLES licenses cost about half of the amount RHEL would be, so I'm not forced to leave my favourite distributor :) Regards, Werner --
On Thu, Feb 6, 2020 at 6:44 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Wed, Feb 05, David C. Rankin wrote:
Is this really warranted? When workarounds are needed to correct a new change -- there is a problem. And for 20+ years, every program that needs a specific port has looked to /etc/services. That means every program (other than those updated or patched by the opensuse team) will fail to find the services file in the new location (unless patched by the user)
No application is reading /etc/services directly. They all use the glibc interface for this. No need to patch any application.
True for clients that access service definitions. Not at all true for software installers that add services to the services file. Our installer is not RPM based as it does lots of things beyond what RPM allows. It will have to now detect where to add new services. If there was a program that could be told a service and add it if it does not exist, then what you say might be true. But most installers like ours check if a service is defined, and if not, add it to the services file. So it needs to know the location. Is there a user command that tells the name of this file? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 07.02.20 um 08:16 schrieb Roger Oberholtzer:
On Thu, Feb 6, 2020 at 6:44 AM Thorsten Kukuk <kukuk@suse.de> wrote:
No application is reading /etc/services directly. They all use the glibc interface for this. No need to patch any application.
True for clients that access service definitions. Not at all true for software installers that add services to the services file. Our installer is not RPM based as it does lots of things beyond what RPM allows. It will have to now detect where to add new services.
🤦 No. It will still have to add it to /etc/services. Nothing/nobody but the distribution maintainer should ever mess with /usr/etc/services. That's the whole idea behind this change. -- 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 Fri, Feb 07, Roger Oberholtzer wrote:
On Thu, Feb 6, 2020 at 6:44 AM Thorsten Kukuk <kukuk@suse.de> wrote:
On Wed, Feb 05, David C. Rankin wrote:
Is this really warranted? When workarounds are needed to correct a new change -- there is a problem. And for 20+ years, every program that needs a specific port has looked to /etc/services. That means every program (other than those updated or patched by the opensuse team) will fail to find the services file in the new location (unless patched by the user)
No application is reading /etc/services directly. They all use the glibc interface for this. No need to patch any application.
True for clients that access service definitions. Not at all true for software installers that add services to the services file.
Adding new entries to /etc/services is absolute fine, and now you even don't have the problem anymore that the next distribution update will overwrite your entries.
Our installer is not RPM based as it does lots of things beyond what RPM allows. It will have to now detect where to add new services.
No! You will continue to use /etc/services, nothing else. You cannot write to /usr/etc.
If there was a program that could be told a service and add it if it does not exist, then what you say might be true. But most installers like ours check if a service is defined, and if not, add it to the services file. So it needs to know the location. Is there a user command that tells the name of this file?
So your installer is already broken today if the customer is using LDAP or NIS? The only correct way to check if an entry exist, and that since over 20 years (yes, this was already on Solaris the case) is: "getent services ...". Checking /etc/services did never told you if a service exist. At least not since the day SUN introduced NIS, and especially no longer when SUN introduced /etc/nsswitch.conf. So check with "getent services" if the service exist, if not, add to /etc/services, and be happy that from now openSUSE will not overwrite your service with the next update. Quite simple. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/7/20 8:27 AM, Thorsten Kukuk wrote:
On Fri, Feb 07, Roger Oberholtzer wrote:
If there was a program that could be told a service and add it if it does not exist, then what you say might be true. But most installers like ours check if a service is defined, and if not, add it to the services file. So it needs to know the location. Is there a user command that tells the name of this file?
So your installer is already broken today if the customer is using LDAP or NIS?
I'm in the LDAP world for 20+ years now. I don't know any deployment where services map is delivered via LDAP (even though RFC 2307 defines the schema and nss_ldap and nss-pam-ldap aka nslcd support services map). It would also be pretty stupid to do that.
The only correct way to check if an entry exist, and that since over 20 years (yes, this was already on Solaris the case) is: "getent services ...".
Checking /etc/services did never told you if a service exist. At least not since the day SUN introduced NIS, and especially no longer when SUN introduced /etc/nsswitch.conf. So check with "getent services" if the service exist,
In general this is true. But sometimes a software might want to find out if a NSS map entry is defined *locally*. You might argue that the software should just use getent -s usrfiles passwd but that has to be done just like the update of nsswitch.conf. Which adds more complexity to installers because NSS module usrfiles is not available on many platforms yet. Still NSS maps are a fairly easy case because glibc will just try every module listed for a map in /etc/nsswitch.conf. I have strong doubts for general handling of config files in /etc/. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Feb 07, Michael Ströder wrote:
On 2/7/20 8:27 AM, Thorsten Kukuk wrote:
On Fri, Feb 07, Roger Oberholtzer wrote:
If there was a program that could be told a service and add it if it does not exist, then what you say might be true. But most installers like ours check if a service is defined, and if not, add it to the services file. So it needs to know the location. Is there a user command that tells the name of this file?
So your installer is already broken today if the customer is using LDAP or NIS?
I'm in the LDAP world for 20+ years now. I don't know any deployment where services map is delivered via LDAP (even though RFC 2307 defines the schema and nss_ldap and nss-pam-ldap aka nslcd support services map). It would also be pretty stupid to do that.
Depends how you distribute your software. If you install the software on every single machine: ok. If you, like we did at university, distribute the software via NFS, you don't want to mess around with /etc/services on every single of the 5000 machines, you want to add the necessary entries for the software in one central place. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, 2020-02-07 at 11:36 +0100, Thorsten Kukuk wrote:
On Fri, Feb 07, Michael Ströder wrote:
On 2/7/20 8:27 AM, Thorsten Kukuk wrote:
On Fri, Feb 07, Roger Oberholtzer wrote:
If there was a program that could be told a service and add it if it does not exist, then what you say might be true. But most installers like ours check if a service is defined, and if not, add it to the services file. So it needs to know the location. Is there a user command that tells the name of this file?
So your installer is already broken today if the customer is using LDAP or NIS?
I'm in the LDAP world for 20+ years now. I don't know any deployment where services map is delivered via LDAP (even though RFC 2307 defines the schema and nss_ldap and nss-pam-ldap aka nslcd support services map). It would also be pretty stupid to do that.
Depends how you distribute your software. If you install the software on every single machine: ok. If you, like we did at university, distribute the software via NFS, you don't want to mess around with /etc/services on every single of the 5000 machines, you want to add the necessary entries for the software in one central place.
Indeed, I've been in the LDAP world as long as Michael, and had a former life a sysadmin in academia. Thorsten's use case rings true to exactly how we used to deploy things in my previous job. Works very well when you have a multi-thousand workstation network being consumed by multi-tens-of-thousands LDAP tree with a churn rate of ~15,000 users added/removed each academic year. Regards, -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/7/20 11:36 AM, Thorsten Kukuk wrote:
On Fri, Feb 07, Michael Ströder wrote:
I'm in the LDAP world for 20+ years now. I don't know any deployment where services map is delivered via LDAP (even though RFC 2307 defines the schema and nss_ldap and nss-pam-ldap aka nslcd support services map). It would also be pretty stupid to do that.
Depends how you distribute your software. If you install the software on every single machine: ok. If you, like we did at university, distribute the software via NFS, you don't want to mess around with /etc/services on every single of the 5000 machines, you want to add the necessary entries for the software in one central place.
Well, today we have config management to distribute fairly constant files to thousands of systems. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk writes:
No application is reading /etc/services directly. They all use the glibc interface for this. No need to patch any application.
But postinstall scripts do. I've seen messages caomplaining about that at least twice in the last days. They scroll by too quickly so unless these get logged somewhere I haven't yet looked I can't tell you which packet that was. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Citeren Achim Gratz <Stromeko@nexgo.de>:
Thorsten Kukuk writes:
No application is reading /etc/services directly. They all use the glibc interface for this. No need to patch any application.
But postinstall scripts do. I've seen messages caomplaining about that at least twice in the last days. They scroll by too quickly so unless these get logged somewhere I haven't yet looked I can't tell you which packet that was.
Maybe /var/log/zypp/history provides a clue.
Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-02-04 at 13:12 +0000, Roger Whittaker wrote:
I know what is happening here in theory, but not all installed programs do. For example fetchmail stopped working after this update until I added a symlink to the old location.
Is there a "proper" way to handle this apart from what I did?
Check your /etc/nsswitch.conf - do you happen to have a .rpmnew lingering around there with a diff? Generally, those service file moves are handled by libnss_usrfiles (make sure you have libnss_usrfiles2 instaled - but this should be a required by patterns already) in your /etc/nsswitch.conf, make sure you have services: files usrfiles protocols: files usrfiles ethers: files usrfiles (that's the three files moved in this snapshot) Cheers, Dominique
On Tue, Feb 04, 2020 at 02:42:23PM +0100, Dominique Leuenberger / DimStar wrote:
On Tue, 2020-02-04 at 13:12 +0000, Roger Whittaker wrote:
I know what is happening here in theory, but not all installed programs do. For example fetchmail stopped working after this update until I added a symlink to the old location.
Is there a "proper" way to handle this apart from what I did?
Check your /etc/nsswitch.conf - do you happen to have a .rpmnew lingering around there with a diff? Generally, those service file moves are handled by libnss_usrfiles (make sure you have libnss_usrfiles2 instaled - but this should be a required by patterns already)
in your /etc/nsswitch.conf, make sure you have
services: files usrfiles protocols: files usrfiles ethers: files usrfiles
(that's the three files moved in this snapshot)
Thanks - this is really good to know. -- ============================ Roger Whittaker roger@disruptive.org.uk ============================ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2020-02-04 14:42, Dominique Leuenberger / DimStar wrote:
On Tue, 2020-02-04 at 13:12 +0000, Roger Whittaker wrote:
I know what is happening here in theory, but not all installed programs do. For example fetchmail stopped working after this update until I added a symlink to the old location.
Is there a "proper" way to handle this apart from what I did?
Check your /etc/nsswitch.conf - do you happen to have a .rpmnew lingering around there with a diff?
Ha! Mine has passwd: compat sss as content, which is probably why an rpmnew was produced in the first place, because that rpmnew tries to match and apply this logic: -passwd: compat +passwd: compat usrfiles (which it obviously can't). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dominique Leuenberger / DimStar schrieb:
On Tue, 2020-02-04 at 13:12 +0000, Roger Whittaker wrote:
I know what is happening here in theory, but not all installed programs do. For example fetchmail stopped working after this update until I added a symlink to the old location.
Is there a "proper" way to handle this apart from what I did?
Check your /etc/nsswitch.conf - do you happen to have a .rpmnew lingering around there with a diff? Generally, those service file moves are handled by libnss_usrfiles (make sure you have libnss_usrfiles2 instaled - but this should be a required by patterns already)
in your /etc/nsswitch.conf, make sure you have
services: files usrfiles protocols: files usrfiles ethers: files usrfiles
That's a pretty nasty trap. How about making "files" just do the right thing itself? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 04, Ludwig Nussel wrote:
services: files usrfiles protocols: files usrfiles ethers: files usrfiles
That's a pretty nasty trap. How about making "files" just do the right thing itself?
That's only a trap for people who don't care about their configuration files after an update. And this people are always in big danger about insecure systems or broken services ... And exactly this is what we want to prevent with this changes. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 04.02.20 um 18:09 schrieb Thorsten Kukuk:
On Tue, Feb 04, Ludwig Nussel wrote:
services: files usrfiles protocols: files usrfiles ethers: files usrfiles
That's a pretty nasty trap. How about making "files" just do the right thing itself?
That's only a trap for people who don't care about their configuration files after an update.
Probably you should also fix nsswitch to be in /usr/etc/ and have /etc/nsswitch only contain the changes that the user wants. And in this case, a %post that inserts usrfiles after files would have been the minimal sensible thing to do, the obvious being just making "files" do the same as "files usrfiles" It was your idea of breaking everyone's system after all with this obviously half-baked solution, so you cannot blame users who did not change anything for years.
And this people are always in big danger about insecure systems or broken services ...
And exactly this is what we want to prevent with this changes. Doesn't feel exactly like that...
BTW: all that I did after installing was enabling NIS client via YaST. No manual changes to nsswitch. Now it's broken and I need to fix it. -- 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, Feb 04, Stefan Seyfried wrote:
Probably you should also fix nsswitch to be in /usr/etc/ and have /etc/nsswitch only contain the changes that the user wants.
Do you volunteer for it?
It was your idea of breaking everyone's system after all with this obviously half-baked solution, so you cannot blame users who did not change anything for years.
Sorry, but we tell since ages that you have to check after update for *.rpmsave and *.rpmnew files. If you ignore that for month, it's not my fault if a long prepared, announced and well tested update breaks your system. If you ignore *.rpmsave and *.rpmnew files for weeks this can happen to you every day again with any other version update.
BTW: all that I did after installing was enabling NIS client via YaST. No manual changes to nsswitch. Now it's broken and I need to fix it.
It was broken on your system for at minimum two month. Luck for you that no other update broke your system before. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2020-02-04 21:10, Thorsten Kukuk wrote:
Sorry, but we tell since ages that you have to check after update for *.rpmsave and *.rpmnew files. If you ignore that for month, it's not my fault if a long prepared, announced and well tested update breaks your system.
It's easy to claim "well tested" when the testsuite does not test a system with .rpmnew files in it.
If you ignore *.rpmsave and *.rpmnew files for weeks this can happen to you every day again with any other version update.
How does one know that there are rpmnew files, apart from remembering to run `rpmconfigcheck` at regular intervals? If you run zypper (possibly unattended), the info scrolls past out of the viewport (if only enough packages are installed), e.g. # zypper in vim xinetd ... (1/3) Installing: xinetd-2.3.15.3-lp151.4.3.x86_64 .......................[done] Additional rpm output: warning: /etc/xinetd.conf created as /etc/xinetd.conf.rpmnew Updating /etc/sysconfig/xinetd ... (2/3) Installing: vim-data-common-8.0.1568-lp151.5.3.1.noarch ............[done] (3/3) Installing: vim-8.0.1568-lp151.5.3.1.x86_64 ........................[done] I don't know if this gets displayed at all when using some update from a graphical environment (and then, if it sticks to the screen). -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 04, Jan Engelhardt wrote:
On Tuesday 2020-02-04 21:10, Thorsten Kukuk wrote:
Sorry, but we tell since ages that you have to check after update for *.rpmsave and *.rpmnew files. If you ignore that for month, it's not my fault if a long prepared, announced and well tested update breaks your system.
It's easy to claim "well tested" when the testsuite does not test a system with .rpmnew files in it.
There are many ways you can re-configure your system, it's impossible to test all possible configuration variants ...
If you ignore *.rpmsave and *.rpmnew files for weeks this can happen to you every day again with any other version update.
How does one know that there are rpmnew files, apart from remembering to run `rpmconfigcheck` at regular intervals?
ls /etc/*.rpm*?
I don't know if this gets displayed at all when using some update from a graphical environment (and then, if it sticks to the screen).
It does not get displayed, that's why there are so many systems out there with broken or insecure configurations. One of the main reasons for the try to make the update of configuration files more robust. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/4/20 10:19 PM, Thorsten Kukuk wrote:
On Tue, Feb 04, Jan Engelhardt wrote:
I don't know if this gets displayed at all when using some update from a graphical environment (and then, if it sticks to the screen).
It does not get displayed, that's why there are so many systems out there with broken or insecure configurations.
You're implying that upstream config from .rpmnew files is always more secure. IMHO the opposite is true if one tweaks the local config e.g. to add security options or to turn off unused features etc.
One of the main reasons for the try to make the update of configuration files more robust.
Well, let's see whether that works. I have some doubts. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 04, Michael Ströder wrote:
On 2/4/20 10:19 PM, Thorsten Kukuk wrote:
On Tue, Feb 04, Jan Engelhardt wrote:
I don't know if this gets displayed at all when using some update from a graphical environment (and then, if it sticks to the screen).
It does not get displayed, that's why there are so many systems out there with broken or insecure configurations.
You're implying that upstream config from .rpmnew files is always more secure.
Neither upstream nor customer modified config is always more secure, but we had enough cases last year, where, if you didn't integrated the upstream changes, your system was insecure. Like the key handling of the kernel per user and systemd/PAM enabling this.
IMHO the opposite is true if one tweaks the local config e.g. to add security options or to turn off unused features etc.
There are enough real world openSUSE examples from last year to prove you wrong. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tuesday 2020-02-04 22:19, Thorsten Kukuk wrote:
Sorry, but we tell since ages that you have to check after update for *.rpmsave and *.rpmnew files. If you ignore that for month, it's not my fault if a long prepared, announced and well tested update breaks your system.
If you ignore *.rpmsave and *.rpmnew files for weeks this can happen to you every day again with any other version update.
One of the main reasons for the try to make the update of configuration files more robust.
Ah yes, I can relate to that (some states cannot be prettified in an automated fashion - or only at a bad ratio of invest and return). You get my upvote. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2020-02-04 at 22:19 +0100, Thorsten Kukuk wrote:
How does one know that there are rpmnew files, apart from remembering to run `rpmconfigcheck` at regular intervals?
ls /etc/*.rpm*?
etc-update can be pretty nifty tool for handling this problem It's been patched from it's Gentoo origins to handle ".rpm*" files and part of all openSUSE distributions since 13.1 https://news.opensuse.org/2013/11/13/sneak-peek-opensuse-13-1-geeko-tips/ http://michal.hrusecky.net/2013/04/fosdem-2013-and-etc-update/ -- Richard Brown Linux Distribution Engineer - Future Technology Team Phone +4991174053-361 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 5. Februar 2020, 10:54:19 CET schrieb Richard Brown:
On Tue, 2020-02-04 at 22:19 +0100, Thorsten Kukuk wrote:
How does one know that there are rpmnew files, apart from remembering to run `rpmconfigcheck` at regular intervals?
ls /etc/*.rpm*?
etc-update can be pretty nifty tool for handling this problem
It's been patched from it's Gentoo origins to handle ".rpm*" files and part of all openSUSE distributions since 13.1
https://news.opensuse.org/2013/11/13/sneak-peek-opensuse-13-1-geeko-tips/
http://michal.hrusecky.net/2013/04/fosdem-2013-and-etc-update/
Thanks a lot, Tomas and Richard, for this suggestion. etc-update is nice. The only thing, that should be noted, is that it requires the same careful attention, that complete manual integration usually needs. One should always be alerted, when *.rpm{orig,save} comes into play. Option 2) "Delete update" is almost always the way to go (for a working system). Hence "update" is a bit misleading here. And a look at the timestamp helps for cases like /etc/pam.d modifications, where the current ones are almost the ones to preserve, since *.rpmnew are considerably older. Obviously, one of the latest pam updates has created *.pam-config-backup files, and updated common-* dynamically. This is exactly, what was missing for /etc/nsswitch.conf. Adding usrfiles dynamically wouldn't have been such a big problem in the first place, given the risk of snafu-ed systems, as it happened now.. Cheers, Pete who still has a significant number of systems to tidy... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 04, 2020 at 10:19:01PM +0100, Thorsten Kukuk wrote:
On Tue, Feb 04, Jan Engelhardt wrote:
On Tuesday 2020-02-04 21:10, Thorsten Kukuk wrote:
Sorry, but we tell since ages that you have to check after update for *.rpmsave and *.rpmnew files. If you ignore that for month, it's not my fault if a long prepared, announced and well tested update breaks your system.
It's easy to claim "well tested" when the testsuite does not test a system with .rpmnew files in it.
There are many ways you can re-configure your system, it's impossible to test all possible configuration variants ...
If you ignore *.rpmsave and *.rpmnew files for weeks this can happen to you every day again with any other version update.
How does one know that there are rpmnew files, apart from remembering to run `rpmconfigcheck` at regular intervals?
ls /etc/*.rpm*?
I don't know if this gets displayed at all when using some update from a graphical environment (and then, if it sticks to the screen).
It does not get displayed, that's why there are so many systems out there with broken or insecure configurations.
One of the main reasons for the try to make the update of configuration files more robust.
So does zypper now alert you that there are conflicting configuration changes? Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
05.02.2020 00:19, Thorsten Kukuk пишет:
One of the main reasons for the try to make the update of configuration files more robust.
Before: user edits file in /etc. Package update installs new version as .rpmnew. User misses important changes. After: user copies file from /usr/etc into /etc. Package update installs new version in /usr/etc. This version is ignored because file in /etc exists. User misses important changes. Where exactly is difference and advantage from end-user perspective? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 5. Februar 2020, 19:33:48 CET schrieb Andrei Borzenkov:
05.02.2020 00:19, Thorsten Kukuk пишет:
One of the main reasons for the try to make the update of configuration files more robust.
Before: user edits file in /etc. Package update installs new version as .rpmnew. User misses important changes.
After: user copies file from /usr/etc into /etc. Package update installs new version in /usr/etc. This version is ignored because file in /etc exists. User misses important changes.
Where exactly is difference and advantage from end-user perspective?
The idea in the long run is teaching apps to merge their config values, similar to what systemctl edit (without --full) does. /etc should only contain values, that deviate from system standards. So far the theory. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/02/2020 20.07, Hans-Peter Jansen wrote: | Am Mittwoch, 5. Februar 2020, 19:33:48 CET schrieb Andrei | Borzenkov: |> 05.02.2020 00:19, Thorsten Kukuk пишет: |>> One of the main reasons for the try to make the update of |>> configuration files more robust. |> |> Before: user edits file in /etc. Package update installs new |> version as .rpmnew. User misses important changes. |> |> After: user copies file from /usr/etc into /etc. Package update |> installs new version in /usr/etc. This version is ignored because |> file in /etc exists. User misses important changes. |> |> Where exactly is difference and advantage from end-user |> perspective? | | The idea in the long run is teaching apps to merge their config | values, similar to what systemctl edit (without --full) does. | | /etc should only contain values, that deviate from system | standards. | | So far the theory. So I change the defaults to suit my needs by dropping a file to /etc. Months later, the defaults change again. How do I see what are the new defaults, how do I notice that I have to change the file in /etc again? Because now I simply do: meld /etc/configfile /etc/configfile.rpmnew and instantly I see what is new and I can decide to use it or not, entry by entry. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXjs5dQAKCRC1MxgcbY1H 1fOFAJ0RXbFHrgY3FzVHsl1dBL8v2hRTDQCfcJzqlPxBx7Jsw8Qp1tLl3YmYB00= =hYj2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, [...]
So I change the defaults to suit my needs by dropping a file to /etc. Months later, the defaults change again. How do I see what are the new defaults, how do I notice that I have to change the file in /etc again?
that is my main concern. If I understood correctly, an rpm package should drop the config files to /usr/etc, while an admin or a distribution can save altered or own config files to /etc. Applications/services will follow nsswitch.conf and check /etc/whatever for existance. If the file is found, it will be used. If not, /usr/etc/whatever will be used. If this is correct, lets assume we have /usr/etc/whatever from whatever.rpm. Me as an admin copies that file to /etc and modifies everything which seems to be necessary for my system. The next update for whatever.rpm contains a change for /usr/etc/whatever - maybe security relevant or even crucial for the system to come up. On the next boot, whatever will still read and use /etc/whatever and will either fail or use unsecure settings. Will anything tell me, that I will run into this problem? zypper?
Because now I simply do:
meld /etc/configfile /etc/configfile.rpmnew
and instantly I see what is new and I can decide to use it or not, entry by entry.
Right!
- -- Cheers / Saludos,
Carlos E. R.
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 06, Michael Hirmke wrote:
Hi,
[...]
So I change the defaults to suit my needs by dropping a file to /etc. Months later, the defaults change again. How do I see what are the new defaults, how do I notice that I have to change the file in /etc again?
that is my main concern.
I would really suggest to read the openSUSE wiki documentation, reading documentation really helps and saves more work than it is to read it. You have the distribution default in /usr/etc You have your own "change" in /etc. If we take login.defs as example: /usr/etc/login.defs uses for NIS DES. You create a file like /etc/login.defs.d/crypt.defs and changes the default to SHA512. You have in /etc/ only the variable with SHA512, nothing else. You can lookup everytime in /usr/etc/login.defs what the current default is. But you don't need to care. If you we look at it for Leap: You have /etc/login.defs You change the hash for NIS from DES to SHA512. We update that file. You get a *.rpmnew file, and until you notice this and fixes it, all changed password will use the insecure DES hash! This can not happen today on Tumbleweed anymore! And if we take the /usr/etc/services example: Your /etc/services file contains only your change, nothing more. If there is an update, you don't need to manual merge them, it's done automatically for you by glibc. Of course, you can copy /usr/etc/services to /etc/services and modify that. In this case, you can diff /etc/services against /usr/etc/services and you will get the same result as today by diffing /etc/services against /etc/services.rpmnew. No change, only other path. But this doesn't make much sense as you would get a lot of duplicate entries.
If I understood correctly, an rpm package should drop the config files to /usr/etc, while an admin or a distribution can save altered or own config files to /etc.
He should save the modified/new entries there, not a copy of the whole file!
Applications/services will follow nsswitch.conf and check /etc/whatever for existance. If the file is found, it will be used. If not, /usr/etc/whatever will be used.
No, completly wrong. If you use nsswitch.conf, it will be merged.
If this is correct, lets assume we have /usr/etc/whatever from whatever.rpm. Me as an admin copies that file to /etc and modifies everything which seems to be necessary for my system. The next update for whatever.rpm contains a change for /usr/etc/whatever - maybe security relevant or even crucial for the system to come up. On the next boot, whatever will still read and use /etc/whatever and will either fail or use unsecure settings.
If that would be the case (and most likely will for some applications and their configuration files in the future), you are right and the result is exaclty the same as today.
Will anything tell me, that I will run into this problem? zypper?
The problem is the same as today for you, absolut no difference. If there will be a change, we have ideas for a tool to display the changes. Which would mean, it's even in that case better than today! But up to now, it's not needed.
Because now I simply do:
meld /etc/configfile /etc/configfile.rpmnew
and instantly I see what is new and I can decide to use it or not, entry by entry.
Right!
meld /etc/configfile /usr/etc/configfile? Where's the problem? Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk wrote:
You have the distribution default in /usr/etc You have your own "change" in /etc.
If we take login.defs as example: /usr/etc/login.defs uses for NIS DES. You create a file like /etc/login.defs.d/crypt.defs and changes the default to SHA512.
So this one uses the same approach as systemd, yes? Overwrite files in <something>.d
Your /etc/services file contains only your change, nothing more. If there is an update, you don't need to manual merge them, it's done automatically for you by glibc.
But services is different? So not /etc/services.d/mychange.conf? How do I know which 'type' a config is?
He should save the modified/new entries there, not a copy of the whole file!
Might be helpful to create an empty file with hints how to proceed?
Will anything tell me, that I will run into this problem? zypper?
The problem is the same as today for you, absolut no difference. If there will be a change, we have ideas for a tool to display the changes. Which would mean, it's even in that case better than today! But up to now, it's not needed.
No, at the moment the existence of a *.rpm* file (if I check for it) tells me that there had been a change. With the new method I cannot easily find out if there had been a change in the config file. So I'd never notice I am missing something.
meld /etc/configfile /usr/etc/configfile?
Where's the problem?
I need someone to tell me that I need to run this ;^> -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Thorsten,
On Thu, Feb 06, Michael Hirmke wrote:
[...]
I would really suggest to read the openSUSE wiki documentation, reading documentation really helps and saves more work than it is to read it.
you are right and I would have done, if I would have known it contains this documentation. But in this case, I would have missed your perfect explanation :) Thx a lot - things are mostly clear now. [...]
Thorsten
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/02/2020 13.11, Thorsten Kukuk wrote: | On Thu, Feb 06, Michael Hirmke wrote: | |> Hi, |> |> [...] |>> So I change the defaults to suit my needs by dropping a file to |>> /etc. Months later, the defaults change again. How do I see |>> what are the new defaults, how do I notice that I have to |>> change the file in /etc again? |> |> that is my main concern. | | I would really suggest to read the openSUSE wiki documentation, | reading documentation really helps and saves more work than it is | to read it. Links, please? | | You have the distribution default in /usr/etc You have your own | "change" in /etc. | | If we take login.defs as example: /usr/etc/login.defs uses for NIS | DES. You create a file like /etc/login.defs.d/crypt.defs and | changes the default to SHA512. You have in /etc/ only the variable | with SHA512, nothing else. You can lookup everytime in | /usr/etc/login.defs what the current default is. But you don't need | to care. | | If you we look at it for Leap: You have /etc/login.defs You change | the hash for NIS from DES to SHA512. We update that file. You get a | *.rpmnew file, and until you notice this and fixes it, all changed | password will use the insecure DES hash! This can not happen today | on Tumbleweed anymore! | | And if we take the /usr/etc/services example: | | Your /etc/services file contains only your change, nothing more. If | there is an update, you don't need to manual merge them, it's done | automatically for you by glibc. | | Of course, you can copy /usr/etc/services to /etc/services and | modify that. In this case, you can diff /etc/services against | /usr/etc/services and you will get the same result as today by | diffing /etc/services against /etc/services.rpmnew. No change, only | other path. Well, no. Because by running "rpmconfigcheck" I know instantly which are the packages that need attention. | | But this doesn't make much sense as you would get a lot of | duplicate entries. | |> If I understood correctly, an rpm package should drop the config |> files to /usr/etc, while an admin or a distribution can save |> altered or own config files to /etc. | | He should save the modified/new entries there, not a copy of the | whole file! | |> Applications/services will follow nsswitch.conf and check |> /etc/whatever for existance. If the file is found, it will be |> used. If not, /usr/etc/whatever will be used. | | No, completly wrong. If you use nsswitch.conf, it will be merged. | |> If this is correct, lets assume we have /usr/etc/whatever from |> whatever.rpm. Me as an admin copies that file to /etc and |> modifies everything which seems to be necessary for my system. |> The next update for whatever.rpm contains a change for |> /usr/etc/whatever - maybe security relevant or even crucial for |> the system to come up. On the next boot, whatever will still read |> and use /etc/whatever and will either fail or use unsecure |> settings. | | If that would be the case (and most likely will for some | applications and their configuration files in the future), you are | right and the result is exaclty the same as today. | |> Will anything tell me, that I will run into this problem? |> zypper? | | The problem is the same as today for you, absolut no difference. | If there will be a change, we have ideas for a tool to display the | changes. Which would mean, it's even in that case better than | today! But up to now, it's not needed. | |>> Because now I simply do: |> |>> meld /etc/configfile /etc/configfile.rpmnew |> |>> and instantly I see what is new and I can decide to use it or |>> not, entry by entry. |> |> Right! | | meld /etc/configfile /usr/etc/configfile? | | Where's the problem? That I do this only when rpmconfigcheck tells me I should do it, and only on a few files. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXjyQrAAKCRC1MxgcbY1H 1TCaAJ9teenu6/z1xf5L3ysOaS2Pjrb/QACeNMtFXU9PdMgal8AwxywvfTwLZik= =vVS8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 06, Carlos E. R. wrote:
On 06/02/2020 13.11, Thorsten Kukuk wrote:
| I would really suggest to read the openSUSE wiki documentation, | reading documentation really helps and saves more work than it is | to read it.
Links, please?
For you again: https://en.opensuse.org/openSUSE:Packaging_UsrEtc Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Feb 07, 2020 at 08:38:41AM +0100, Thorsten Kukuk wrote:
Looking at Variant 1 is the following statement true in all cases? "So the change in the latest file wins." Assuming these three localised config system/admin config files are modified in the following time order, with one parameter set differently in each: /etc/example.conf /etc/example.conf.d/zaks_overide.conf /etc/example.conf /etc/example.conf.d/anns_overide.conf Won't conflicting changes from Zak's mods win over Ann's in turn winning of over the localised-system/admin settings of /etc/example.conf? Sorry, I don't have a better word to suggest for the union of a localised file overlaid with files from a subdirectory which are applied in alphabetic (alphanumeric?) order, but "latest" is ambiguous ;-) Daniel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Feb 07, Daniel Morris wrote:
On Fri, Feb 07, 2020 at 08:38:41AM +0100, Thorsten Kukuk wrote:
Looking at Variant 1 is the following statement true in all cases?
"So the change in the latest file wins."
If you use the sentence out of the context, it is misleading, yes. So use it in the full context: Files are read in alphabetical order, and the change in the latest read file wins.
Assuming these three localised config system/admin config files are modified in the following time order, with one parameter set differently in each:
/etc/example.conf /etc/example.conf.d/zaks_overide.conf /etc/example.conf /etc/example.conf.d/anns_overide.conf
At least systemd and libeconf would read the files in this order: /etc/example.conf /etc/example.conf.d/anns_overide.conf /etc/example.conf.d/zaks_overide.conf So if all three modifies the same variable, the value from zaks_overide.conf will win. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/02/2020 08.38, Thorsten Kukuk wrote: | On Thu, Feb 06, Carlos E. R. wrote: | |> On 06/02/2020 13.11, Thorsten Kukuk wrote: | |> | I would really suggest to read the openSUSE wiki |> documentation, | reading documentation really helps and saves |> more work than it is | to read it. |> |> Links, please? | | For you again: | | https://en.opensuse.org/openSUSE:Packaging_UsrEtc Thanks. I was not aware of this. It seems oriented to packagers, not end users. How will a user/admin know which variant (1, 2, or 3) is in use? It seems packagers have liberty to choose for each package, so /etc would have a mixture of all methods. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXj1OjgAKCRC1MxgcbY1H 1UGkAKCV714bhgcrMCdBMwah/GqWgNZzmgCeMr9U/IfGvvpeLO9UwL59EqLQUuo= =zK+9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Together, I'm not sure if this is the right thread but if not please excuse me. What happens till now: Since this update, my nis+nfs clients hangs. After following the discussion here I repaired them, and also solved the *.rpm{new/save}* on my server according my best knowladge. But the server crashes completly, so nothing works anymore. The only possible solution was to install him new with 20200205 tumbleweed install package. Due to the fact, that the installation hangs, I disconnected all not root HDDs and installed him new and connect afterwords all HDDs and mount them again (mainly /home). Afterwords I installed dns_server, dhcpd, nis_server and nfs_server. I cofigured all via yast2 <servicename>. All works fine, only problem is the nis_server. After configuration, I closed yast window an during generation of the configfiles, there was an error, but if I open the log via button in the message, it was empty. Afterwords yast2 nis_server crashes during reading of the configfiles with: ----- Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs. Caller: /usr/share/YaST2/modules/DNS.rb:200:in `Read' Details: uninitialized constant Yast::Lan ----- Beside nis, all works fine and "rpmconfigcheck" shows now entry to do. Am Donnerstag, 6. Februar 2020, 13:11:34 CET schrieb Thorsten Kukuk:
If we take login.defs as example: /usr/etc/login.defs uses for NIS DES. You create a file like /etc/login.defs.d/crypt.defs and changes the default to SHA512. You have in /etc/ only the variable with SHA512, nothing else. You can lookup everytime in /usr/etc/login.defs what the current default is. But you don't need to care.
I've also done this. Additional, I linked all files in /usr/etc in the related /etc drive. Additional I added in each service of nsswitch.conf the entry "usrfiles" (remark by the way, this is according hearder "# Legal entries are:" not a valid entry). Any proposal, what can be done? Remark: My family is not so happy, with the not running network since one week and requested to solve it in a short time :-( Regards Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, Am Samstag, 8. Februar 2020, 10:32:18 CET schrieb Ulf Bartholomäus:
Afterwords I installed dns_server, dhcpd, nis_server and nfs_server. I cofigured all via yast2 <servicename>. All works fine, only problem is the nis_server. After configuration, I closed yast window an during generation of the configfiles, there was an error, but if I open the log via button in the message, it was empty. Afterwords yast2 nis_server crashes during reading of the configfiles with: ----- Internal error. Please report a bug report with logs. Run save_y2logs to get complete logs.
Caller: /usr/share/YaST2/modules/DNS.rb:200:in `Read'
Details: uninitialized constant Yast::Lan -----
YaST already gave you the best advice - please open a bugreport for YaST, and attach the logs as collected by save_y2logs. For your actual problem, I'm afraid I don't have a solution, but at least a possible workaround: Downgrade to an earlier Tumbleweed snapshot. The easiest way to do this is via tumbleweed-cli (see https://review.tumbleweed.boombatower.com/about.html for details). See http://download.opensuse.org/history/ for available snapshots. Regards, Christian Boltz -- in the obs, I'm the guy breaking MySQL and MariaDB. [Michal Hrusecky in opensuse-project] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Sonntag, 9. Februar 2020, 20:23:31 CET schrieb Christian Boltz:
YaST already gave you the best advice - please open a bugreport for YaST, and attach the logs as collected by save_y2logs.
save_y2logs done, but entering a bugreport (this isn't user friendly webpage - in the past it was easy possible without any account via Dr. Konqi :-( ), the Submitting canceled with error 500 (I reported this via on the page linked eMail).
For your actual problem, I'm afraid I don't have a solution, but at least a possible workaround: Downgrade to an earlier Tumbleweed snapshot. The easiest way to do this is via tumbleweed-cli (see https://review.tumbleweed.boombatower.com/about.html for details). See http://download.opensuse.org/history/ for available snapshots.
Seems to be not possible, due to the new installation: # zypper in tumbleweed-cli Repository-Daten werden geladen... Installierte Pakete werden gelesen... Paketabhängigkeiten werden aufgelöst... Das folgende NEUE Paket wird installiert: tumbleweed-cli 1 neues Paket zu installieren. Gesamtgröße des Downloads: 13,1 KiB. Bereits im Cache gespeichert: 0 B. Nach der Operation werden zusätzlich 10,3 KiB belegt. Fortfahren? [j/n/v/...? zeigt alle Optionen] (j): Paket tumbleweed-cli-0.3.3-1.1.noarch abrufen (1/1), 13,1 KiB ( 10,3 KiB entpackt) Abrufen: tumbleweed-cli-0.3.3-1.1.noarch.rpm .......................................................................................................................................................... [fertig] Überprüfung auf Dateikonflikte läuft: ................................................................................................................................................................. [fertig] (1/1) Installieren: tumbleweed-cli-0.3.3-1.1.noarch ................................................................................................................................................... [fertig] # tumbleweed init backup /etc/zypp/repos.d/download.opensuse.org-non-oss.repo backup /etc/zypp/repos.d/download.opensuse.org-oss.repo # tumbleweed status latest : 20200207 target : 20200207 installed: 20200207 # tumbleweed uninit revert 2 repos? [y/n] (y): # tumbleweed status repositories have not been initialized for snapshots Try /usr/bin/tumbleweed init Regards Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Montag, 10. Februar 2020, 21:50:45 CET schrieb Ulf Bartholomäus:
Am Sonntag, 9. Februar 2020, 20:23:31 CET schrieb Christian Boltz:
YaST already gave you the best advice - please open a bugreport for YaST, and attach the logs as collected by save_y2logs.
save_y2logs done, but entering a bugreport (this isn't user friendly webpage - in the past it was easy possible without any account via Dr. Konqi ), the Submitting canceled with error 500 (I reported this via on the page linked eMail).
This is a known problem, y2logs are read-only for root (due to potentially confidential informations). So either upload as root, or make them rw for the user who uploads See: https://github.com/yast/yast-yast2/issues/978 HTH Axel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Many Thanks Axel, Am Montag, 10. Februar 2020, 22:24:05 CET schrieb Axel Braun:
This is a known problem, y2logs are read-only for root (due to potentially confidential informations). So either upload as root, or make them rw for the user who uploads
Arrggg... stupid beginner error :-/ Now it works - many thanks :-) Reported as Bug 1163305 yast2 nis_server crashes during reading of the configfiles Regards Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/02/2020 21.50, Ulf Bartholomäus wrote: | Am Sonntag, 9. Februar 2020, 20:23:31 CET schrieb Christian Boltz: |> YaST already gave you the best advice - please open a bugreport |> for YaST, and attach the logs as collected by save_y2logs. | | save_y2logs done, but entering a bugreport (this isn't user | friendly webpage - in the past it was easy possible without any | account via Dr. Konqi :-( ), the Submitting canceled with error 500 | (I reported this via on the page linked eMail). Yeah, as Axel has said, a user can not read them: Telcontar:~ # save_y2logs Saving YaST logs to /tmp/y2log-kEkUyD.tar.xz Telcontar:~ # l /tmp/y2log-kEkUyD.tar.xz - -rw------- 1 root root 17328060 Feb 11 09:37 /tmp/y2log-kEkUyD.tar.xz Telcontar:~ # | |> For your actual problem, I'm afraid I don't have a solution, but |> at least a possible workaround: Downgrade to an earlier |> Tumbleweed snapshot. The easiest way to do this is via |> tumbleweed-cli (see |> https://review.tumbleweed.boombatower.com/about.html for |> details). See http://download.opensuse.org/history/ for available |> snapshots. | | Seems to be not possible, due to the new installation: # zypper in | tumbleweed-cli Repository-Daten werden geladen... Installierte | Pakete werden gelesen... Paketabhängigkeiten werden aufgelöst... A suggestion. So that anybody can read the output of commands, it is better to get them in English. For instance, do: # LANG=en_US.UTF-8 zypper in tumbleweed-cli I do it with a script: cer@Telcontar:~> cat /usr/local/bin/ingles #!/bin/sh LANG=en_US.UTF-8 \ ~ LC_ALL=en_US.UTF-8 \ ~ DICTIONARY=english \ ~ KDE_LANG=en_US.UTF-8 \ ~ exec "$@" cer@Telcontar:~> - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXkJo9wAKCRC1MxgcbY1H 1RG5AKCPWyWoKKAtuMjbAYJe+XycUgBnPwCeKSZ19h3MnG8UKse3WFTvQJTz9r8= =45gE -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Carlos, Am Dienstag, 11. Februar 2020, 09:42:33 CET schrieb Carlos E. R.:
Yeah, as Axel has said, a user can not read them: [...]
Was yesterday done (see my answer): https://bugzilla.opensuse.org/show_bug.cgi?id=1163305
A suggestion. So that anybody can read the output of commands, it is better to get them in English. For instance, do:
# LANG=en_US.UTF-8 zypper in tumbleweed-cli
I do it with a script:
cer@Telcontar:~> cat /usr/local/bin/ingles #!/bin/sh LANG=en_US.UTF-8 \ ~ LC_ALL=en_US.UTF-8 \ ~ DICTIONARY=english \ ~ KDE_LANG=en_US.UTF-8 \ ~ exec "$@"
Thanks for the script :-), but so the relevant information was in English, I expected no problem (only the installation info - which was passed was in German). ------- # ingles zypper in tumbleweed-cli Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: tumbleweed-cli 1 new package to install. Overall download size: 13.1 KiB. Already cached: 0 B. After the operation, additional 10.3 KiB will be used. Continue? [y/n/v/...? shows all options] (y): Retrieving package tumbleweed-cli-0.3.3-1.1.noarch (1/1), 13.1 KiB ( 10.3 KiB unpacked) Retrieving: tumbleweed-cli-0.3.3-1.1.noarch.rpm ......................................................................................................................................................... [done] Checking for file conflicts: ............................................................................................................................................................................ [done] (1/1) Installing: tumbleweed-cli-0.3.3-1.1.noarch ....................................................................................................................................................... [done] # ingles tumbleweed init backup /etc/zypp/repos.d/download.opensuse.org-non-oss.repo backup /etc/zypp/repos.d/download.opensuse.org-oss.repo # ingles tumbleweed status latest : 20200209 target : 20200209 installed: 20200209 # ingles tumbleweed uninit revert 2 repos? [y/n] (y): # ingles tumbleweed status repositories have not been initialized for snapshots Try /usr/bin/tumbleweed init ------- From my point of view, there is no older version due to the fact it is a new installation (the old was unusable due to about 10 or more years continuous running and updating. So nothing worked anymore after the update to 20200201 :-( - so I was requested to find a fast solution, it was to reinstall the root system with 20200205. Regards Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 11.02.20 um 19:21 schrieb Ulf Bartholomäus:
# ingles tumbleweed init backup /etc/zypp/repos.d/download.opensuse.org-non-oss.repo backup /etc/zypp/repos.d/download.opensuse.org-oss.repo # ingles tumbleweed status latest : 20200209 target : 20200209 installed: 20200209 # ingles tumbleweed uninit revert 2 repos? [y/n] (y): # ingles tumbleweed status repositories have not been initialized for snapshots Try /usr/bin/tumbleweed init ------- From my point of view, there is no older version due to the fact it is a new installation (the old was unusable due to about 10 or more years continuous running and updating. So nothing worked anymore after the update to 20200201 :-( - so I was requested to find a fast solution, it was to reinstall the root system with 20200205.
After "tumbleweed init" the command "tumbleweed list" gives you the available snapshots that can be installed by "tumbleweed switch --install yyyymmdd"(cf. https://download.opensuse.org/history/). Regards, Frank -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Frank, Am Dienstag, 11. Februar 2020, 19:31:21 CET schrieb Frank Krüger:
Am 11.02.20 um 19:21 schrieb Ulf Bartholomäus:
# ingles tumbleweed status latest : 20200209 target : 20200209 installed: 20200209 ------- From my point of view, there is no older version due to the fact it is a new installation (the old was unusable due to about 10 or more years continuous running and updating. So nothing worked anymore after the update to 20200201> :-( - so I was requested to find a fast solution, it was to reinstall the
root system with 20200205.
After "tumbleweed init" the command "tumbleweed list" gives you the available snapshots that can be installed by "tumbleweed switch --install yyyymmdd"(cf. https://download.opensuse.org/history/).
Upps.. that was not visible at the description on referenced link: https://review.tumbleweed.boombatower.com/about.html ------------------- # tumbleweed list 20200209 20200207 20200205 20200201 20200128 20200127 20200125 20200124 20200123 20200122 20200121 20200118 20200117 20200116 20200115 20200114 20200113 20200112 20200111 20200110 ------------------- Due to the fact, that all works fine before 20200201, I switched back to 20200128 via: # tumbleweed switch --install 20200128 ... After the required reboot, the servers don't start anymore (I expect due to some issues with the meanwhile updated config files). So I would also replay the /etc tgz from 20200130. But either "mc" nor "tar" works still (breaks with segmentation fault) so I looks much more crazy with my main server (the meanwhile working dns, dhcpd and nfs-server are now also down :-( ) Pfff.. I won't install the server again :-/ tumbleweed switch --install 20200209 hangs since 30 min. with only something like switching from 20200128 to 20200209 [y/n] (y): (for sure I entered the yes) Seems to be a new installation loop (about one day) is required :-P Regards Ulf Regards Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/02/2020 19.21, Ulf Bartholomäus wrote: | Hi Carlos, Am Dienstag, 11. Februar 2020, 09:42:33 CET schrieb | Carlos E. R.: |> A suggestion. So that anybody can read the output of commands, it |> is better to get them in English. For instance, do: |> |> |> # LANG=en_US.UTF-8 zypper in tumbleweed-cli |> |> |> I do it with a script: |> |> cer@Telcontar:~> cat /usr/local/bin/ingles #!/bin/sh |> LANG=en_US.UTF-8 \ ~ LC_ALL=en_US.UTF-8 \ ~ DICTIONARY=english |> \ ~ KDE_LANG=en_US.UTF-8 \ ~ exec "$@" | | Thanks for the script :-), but so the relevant information was in | English, I expected no problem (only the installation info - which | was passed was in German). Oops. I should have said that it was a suggestion for the future ;-) - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXkPVfwAKCRC1MxgcbY1H 1a9gAJ9JeHijrR/zmMzX1eVofOeivohMhACfcYV6LsmzVvH028kESERxAbM+1Pk= =0PJs -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Thu, Feb 6, 2020 at 10:41, Michael Hirmke <mh@mike.franken.de> wrote:
Will anything tell me, that I will run into this problem? zypper?
Please keep in mind many people will have auto-update set up for security updates, in that case relying on zypper for notifications is foolish at best, and dangerous at worst. LCP [Stasiek] https://lcp.world -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/4/20 10:15 PM, Jan Engelhardt wrote:
On Tuesday 2020-02-04 21:10, Thorsten Kukuk wrote:
If you ignore *.rpmsave and *.rpmnew files for weeks this can happen to you every day again with any other version update.
How does one know that there are rpmnew files, apart from remembering to run `rpmconfigcheck` at regular intervals?
Running rpmconfigcheck and manually diffing the files is also pretty useless because most of the diffs are trivial changes in comments etc. I cannot understand why a required change to nsswitch.conf with potentially bigger impact was not announced here. I vaguely remembered discussions about the transition to /usr/etc but I was not aware that it happens now. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk writes:
Sorry, but we tell since ages that you have to check after update for *.rpmsave and *.rpmnew files. If you ignore that for month, it's not my fault if a long prepared, announced and well tested update breaks your system.
Then why doesn't zypper do the same thing as apt-get does and tell you which files are affected and then ask what you want to do about it (including the ability to show you a diff and bump you into an editor should you want to make changes right then and there)? Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/4/20 10:47 PM, Achim Gratz wrote:
Then why doesn't zypper do the same thing as apt-get does and tell you which files are affected and then ask what you want to do about it (including the ability to show you a diff and bump you into an editor should you want to make changes right then and there)?
No, please not. This often miserably fails with automation. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michael Ströder writes:
On 2/4/20 10:47 PM, Achim Gratz wrote:
Then why doesn't zypper do the same thing as apt-get does and tell you which files are affected and then ask what you want to do about it (including the ability to show you a diff and bump you into an editor should you want to make changes right then and there)?
No, please not. This often miserably fails with automation.
You can configure that behaviour, both permanently and on the command line. I wouldn't mind having to run yet another command in the zypper shell either. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 04.02.20 um 21:10 schrieb Thorsten Kukuk:
Do you volunteer for it?
putting everything back into /etc? Yes.
It was broken on your system for at minimum two month. Luck for you that no other update broke your system before.
netcfg update broke it recently, as the files were removed from /etc with 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
Thorsten Kukuk wrote:
Sorry, but we tell since ages that you have to check after update for *.rpmsave and *.rpmnew files. If you ignore that for month, it's not my fault if a long prepared, announced and well tested update breaks your system. If you ignore *.rpmsave and *.rpmnew files for weeks this can happen to you every day again with any other version update.
Well, as a start, a change that supposedly makes your system unusable usually forces the new config in and creates a *.rpmsave. Didn't happen for this one. Why? And *if* this checking is so crucial, why doesn't zypper (or whatever you run to update the system) do this check and at least print out a warning at the end that config files have unresolved changes? It also checks for processes using deleted files, so this would only be straight forward.... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/5/20 11:54 AM, Peter Suetterlin wrote:
Thorsten Kukuk wrote:
Sorry, but we tell since ages that you have to check after update for *.rpmsave and *.rpmnew files. If you ignore that for month, it's not my fault if a long prepared, announced and well tested update breaks your system. If you ignore *.rpmsave and *.rpmnew files for weeks this can happen to you every day again with any other version update.
Well, as a start, a change that supposedly makes your system unusable usually forces the new config in and creates a *.rpmsave. Didn't happen for this one. Why?
/etc/nsswitch.conf can contain module names for central user management. If you mess around with that without knowing what's in there the bad impact could have been much worse.
And *if* this checking is so crucial, why doesn't zypper (or whatever you run to update the system) do this check and at least print out a warning at the end that config files have unresolved changes? It also checks for processes using deleted files, so this would only be straight forward....
This would be a better approach. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 04, 2020 at 09:10:30PM +0100, Thorsten Kukuk wrote:
On Tue, Feb 04, Stefan Seyfried wrote:
Probably you should also fix nsswitch to be in /usr/etc/ and have /etc/nsswitch only contain the changes that the user wants.
Do you volunteer for it?
It was your idea of breaking everyone's system after all with this obviously half-baked solution, so you cannot blame users who did not change anything for years.
Sorry, but we tell since ages that you have to check after update for *.rpmsave and *.rpmnew files. If you ignore that for month, it's not my fault if a long prepared, announced and well tested update breaks your system. If you ignore *.rpmsave and *.rpmnew files for weeks this can happen to you every day again with any other version update.
BTW: all that I did after installing was enabling NIS client via YaST. No manual changes to nsswitch. Now it's broken and I need to fix it.
It was broken on your system for at minimum two month. Luck for you that no other update broke your system before.
How exactly was it broken? When the system works for two months without the .rpmnew file I conclude it was not needed to start with. Also does zypper even tell you that there was a conflict or does it just silently drop the .rpmnew file to your system? I know the Debian packages are quite noisy about config changes but don't have any .rpmnew files on my system so can't tell how it works with rpm. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michal Suchánek wrote:
Also does zypper even tell you that there was a conflict or does it just silently drop the .rpmnew file to your system?
rpm does, when installing. But that message is lost in estimated 99.9% of the cases because it just scrolls through way too fast. So it really needs some addition to zypper&co to check this at the end of an up{grad,dat}e and print a summary/warning. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Peter Suetterlin píše v St 05. 02. 2020 v 13:04 +0100:
Michal Suchánek wrote:
Also does zypper even tell you that there was a conflict or does it just silently drop the .rpmnew file to your system?
rpm does, when installing. But that message is lost in estimated 99.9% of the cases because it just scrolls through way too fast.
So it really needs some addition to zypper&co to check this at the end of an up{grad,dat}e and print a summary/warning.
Yeah summary might be nice. FWIW when I moved my stuff from Gentoo years ago I also made sure we have etc-update. But this still does not solve the issue of mandatory user interaction that leads to broken systems if not done. Cheers Tom
On Wednesday 2020-02-05 13:15, Tomas Chvatal wrote:
Also does zypper even tell you that there was a conflict or does it just silently drop the .rpmnew file to your system?
rpm does, when installing. But that message is lost in estimated 99.9% of the cases because it just scrolls through way too fast.
So it really needs some addition to zypper&co to check this at the end of an up{grad,dat}e and print a summary/warning.
Yeah summary might be nice.
Given zypper already does print a final summary for "... services need restarting, see `zypper ps`", it would not be hard to print another line for "hey you've got new rpmnew files". -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
04.02.2020 20:51, Stefan Seyfried пишет:
Am 04.02.20 um 18:09 schrieb Thorsten Kukuk:
On Tue, Feb 04, Ludwig Nussel wrote:
services: files usrfiles protocols: files usrfiles ethers: files usrfiles
That's a pretty nasty trap. How about making "files" just do the right thing itself?
That's only a trap for people who don't care about their configuration files after an update.
It may come unexpectedly, but TW *is* used by mere mortals who do not have the slightest idea what /etc/protocols or /etc/nsswitch.conf is, nor understand how to interpret "Protocol not supported" from their NFS mount, nor are professional system administrators. If TW is for geeks only, you should remove it from www.opensuse.org entirely. At least, remove this elevator pitch Fast! Integrated! Stabilized! Tested! If you ... need a stable platform ... and replace it with clear explanation that TW is only for those who want to tinker with Linux daily instead of using Linux to do their actual job.
Probably you should also fix nsswitch to be in /usr/etc/ and have /etc/nsswitch only contain the changes that the user wants.
And in this case, a %post that inserts usrfiles after files would have been the minimal sensible thing to do, the obvious being just making "files" do the same as "files usrfiles"
Exactly. This would avoid this problem in the first place. This is what name service switch abstraction is for. What's the point in having "file" abstraction if every time file is relocated we need another abstraction for this specific case only? Unless intention is to support *both* "files" and "usrfiles" in any combination. Because this is the only reason to have "usrfiles" as separate NSS module. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op 09-02-2020 om 07:23 schreef Andrei Borzenkov:
04.02.2020 20:51, Stefan Seyfried пишет:
Am 04.02.20 um 18:09 schrieb Thorsten Kukuk:
On Tue, Feb 04, Ludwig Nussel wrote:
services: files usrfiles protocols: files usrfiles ethers: files usrfiles That's a pretty nasty trap. How about making "files" just do the right thing itself? That's only a trap for people who don't care about their configuration files after an update. It may come unexpectedly, but TW *is* used by mere mortals who do not have the slightest idea what /etc/protocols or /etc/nsswitch.conf is, nor understand how to interpret "Protocol not supported" from their NFS mount, nor are professional system administrators.
If TW is for geeks only, you should remove it from www.opensuse.org entirely. At least, remove this elevator pitch
Fast! Integrated! Stabilized! Tested!
If you ... need a stable platform ...
and replace it with clear explanation that TW is only for those who want to tinker with Linux daily instead of using Linux to do their actual job.
I'm afraid I'm one of them. Never even heard of rpmnew... So I would think it's wise to not install TW snapshots until I'm sure that "zypper dup --no-allow-vendor-change" does the job without human interference afterwards? regards, Jogchum
Probably you should also fix nsswitch to be in /usr/etc/ and have /etc/nsswitch only contain the changes that the user wants.
And in this case, a %post that inserts usrfiles after files would have been the minimal sensible thing to do, the obvious being just making "files" do the same as "files usrfiles"
Exactly. This would avoid this problem in the first place. This is what name service switch abstraction is for. What's the point in having "file" abstraction if every time file is relocated we need another abstraction for this specific case only?
Unless intention is to support *both* "files" and "usrfiles" in any combination. Because this is the only reason to have "usrfiles" as separate NSS module.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Tue, 4 Feb 2020 18:09:18 +0100 schrieb Thorsten Kukuk <kukuk@suse.de>:
That's only a trap for people who don't care about their configuration files after an update.
So, this covers in practice almost everyone (leaving aside the few who move forward with 'zypper dup'). How do you envision an offline upgrade to the coming SLE/Leap? I may have missed the statement about how this will be handled automatically. Olaf
Thorsten Kukuk schrieb:
On Tue, Feb 04, Ludwig Nussel wrote:
services: files usrfiles protocols: files usrfiles ethers: files usrfiles
That's a pretty nasty trap. How about making "files" just do the right thing itself?
That's only a trap for people who don't care about their configuration files after an update. And this people are always in big danger about insecure systems or broken services ...
I don't agree with that point of view and claim the opposite. Operating system features that rely on a human reviewing rpm{old,new} files are flawed. We must design the system in such a way that it does not require interaction. Especially in cases where the user only used "approved" methods to configure the system. Means that if eg yast did the change it is in our responsibility to not maneuver the system into a state that it cannot recover from itself. If the way nsswitch.conf works is incompatible with those requirements the concept has to be retired and replaced by something smarter. Looks like nsswitch.conf kind of states the obvious most of the time anyways. Maybe we don't need it at all? Even extra authentication methods could probably be determined automatically by looking at the system. Ie if sssd or ypbind are enabled it's not unlikely that those are meant to be used for authentication, right? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 05-02-2020 10:01, Ludwig Nussel wrote:
Thorsten Kukuk schrieb:
On Tue, Feb 04, Ludwig Nussel wrote:
services: files usrfiles protocols: files usrfiles ethers: files usrfiles
That's a pretty nasty trap. How about making "files" just do the right thing itself?
That's only a trap for people who don't care about their configuration files after an update. And this people are always in big danger about insecure systems or broken services ...
I don't agree with that point of view and claim the opposite. Operating system features that rely on a human reviewing rpm{old,new} files are flawed. We must design the system in such a way that it does not require interaction. Especially in cases where the user only used "approved" methods to configure the system. Means that if eg yast did the change it is in our responsibility to not maneuver the system into a state that it cannot recover from itself.
If the way nsswitch.conf works is incompatible with those requirements the concept has to be retired and replaced by something smarter.
Looks like nsswitch.conf kind of states the obvious most of the time anyways. Maybe we don't need it at all?
Even extra authentication methods could probably be determined automatically by looking at the system. Ie if sssd or ypbind are enabled it's not unlikely that those are meant to be used for authentication, right?
cu Ludwig
I fully agree with the notion of Ludwig. Relying on users to hunt for rpmnew files can only come form people who are detached form real users/life. --- Frans. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Feb 05 2020, Ludwig Nussel wrote:
Even extra authentication methods could probably be determined automatically by looking at the system. Ie if sssd or ypbind are enabled it's not unlikely that those are meant to be used for authentication, right?
NSS is not about authentication, it is about database lookup. But like PAM, size^Worder matters. And just because there is nss_ldap in your system does not mean that you can do an LDAP lookup. 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 schrieb:
On Feb 05 2020, Ludwig Nussel wrote:
Even extra authentication methods could probably be determined automatically by looking at the system. Ie if sssd or ypbind are enabled it's not unlikely that those are meant to be used for authentication, right?
NSS is not about authentication, it is about database lookup.
Sure. Still, a very common case when modification of nsswitch.conf is needed is when the system is switched from pure local authentication to something remote which then also requires changing DB lookups. So the point is if we can determine that automatically we don't need several places to configure something that can then lead to inconsistencies. Ie right now one has to usually - configure some service - enable that service - adjust the pam config - adjust nsswitch Maybe the first two¹ could be sufficient if the system was smart? Looking at nss/nsswitch.c in glibc at least it has built in defaults. Means as a first step we don't even need to ship any nsswitch.conf anymore as we can build glibc to have the right defaults for our main distros.
But like PAM, size^Worder matters.
That still allows to implicitly assume the most common order while keeping the possibility to change it via config. I don't think that eg yast allows to change the order where it inserts eg NIS either.
And just because there is nss_ldap in your system does not mean that you can do an LDAP lookup.
Ok so pure presence of the file isn't good enough for auto detection. That doesn't invalidate the point though :-) cu Ludwig [1] I'm sure you will come up with an example where it is either a service or a config file. Doesn't change overall idea though :-) -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/7/20 10:08 AM, Ludwig Nussel wrote:
Looking at nss/nsswitch.c in glibc at least it has built in defaults. Means as a first step we don't even need to ship any nsswitch.conf anymore as we can build glibc to have the right defaults for our main distros.
Which defaults would that be? E.g. I'm always removing the nis map modules from my /etc/nsswitch.conf. I'm over-writing /etc/nsswitch.conf via config management. In general: Don't put more pseudo config management into build defaults and RPM scripts! Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Michael Ströder schrieb:
On 2/7/20 10:08 AM, Ludwig Nussel wrote:
Looking at nss/nsswitch.c in glibc at least it has built in defaults. Means as a first step we don't even need to ship any nsswitch.conf anymore as we can build glibc to have the right defaults for our main distros.
Which defaults would that be?
Glibc has built in defaults. Default of defaults is "files" if a datase does not define a different one: glibc/nss $ git grep DEFAULT_CONFIG XXX-lookup.c:|* DEFAULT_CONFIG - string for default conf (e.g. "dns files") *| XXX-lookup.c:#ifndef DEFAULT_CONFIG XXX-lookup.c:#define DEFAULT_CONFIG NULL XXX-lookup.c: DEFAULT_CONFIG, &DATABASE_NAME_SYMBOL) < 0) grp-lookup.c:# define DEFAULT_CONFIG "compat [NOTFOUND=return] files" grp-lookup.c:# define DEFAULT_CONFIG "files" hosts-lookup.c:#define DEFAULT_CONFIG "dns [!UNAVAIL=return] files" key-lookup.c:#define DEFAULT_CONFIG "nis nisplus" network-lookup.c:#define DEFAULT_CONFIG "dns [!UNAVAIL=return] files" nsswitch.c:# define DEFAULT_CONFIG "compat [NOTFOUND=return] files" nsswitch.c:# define DEFAULT_CONFIG "files" nsswitch.c: nss_load_all_libraries ("passwd", DEFAULT_CONFIG); nsswitch.c: nss_load_all_libraries ("group", DEFAULT_CONFIG); pwd-lookup.c:# define DEFAULT_CONFIG "compat [NOTFOUND=return] files" pwd-lookup.c:# define DEFAULT_CONFIG "files" sgrp-lookup.c:#define DEFAULT_CONFIG "files" spwd-lookup.c:# define DEFAULT_CONFIG "compat [NOTFOUND=return] files" spwd-lookup.c:# define DEFAULT_CONFIG "files" And: nsswitch.c:# define DEFAULT_DEFCONFIG "files" nsswitch.c: *ni = nss_parse_service_list (defconfig ?: DEFAULT_DEFCONFIG); Iow as of today if you delete {/usr,}/etc/nsswitch.conf you could still use the system with local databases (in /etc). Means the nsswitch.conf we shipped has been redundant all the time. Only now with the introduction of nss_usrfiles2 that fallback got broken. So instead of now shipping an nsswitch.conf that contains "files usrfiles" we could just as well not ship it at all and either a) patch aforementioned defaults to include "usrfiles" already b) patch "files" to also check /usr/etc
E.g. I'm always removing the nis map modules from my /etc/nsswitch.conf. I'm over-writing /etc/nsswitch.conf via config management.
In general: Don't put more pseudo config management into build defaults and RPM scripts!
Not sure what you are trying to say. The possibility to change any config file is not taken aways by using sane built in defaults. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/7/20 12:18 PM, Ludwig Nussel wrote:
Michael Ströder schrieb: So instead of now shipping an nsswitch.conf that contains "files usrfiles" we could just as well not ship it at all and either a) patch aforementioned defaults to include "usrfiles" already b) patch "files" to also check /usr/etc
E.g. I'm always removing the nis map modules from my /etc/nsswitch.conf. I'm over-writing /etc/nsswitch.conf via config management.
In general: Don't put more pseudo config management into build defaults and RPM scripts!
Not sure what you are trying to say. The possibility to change any config file is not taken aways by using sane built in defaults.
Mainly I would not like to see nis or similar to be a compile-time default. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.02.20 um 01:09 schrieb Michael Ströder:
On 2/7/20 12:18 PM, Ludwig Nussel wrote:
Not sure what you are trying to say. The possibility to change any config file is not taken aways by using sane built in defaults.
Mainly I would not like to see nis or similar to be a compile-time default.
well, now it is in nsswitch.conf by default, so having it compiled in would not change anything. And if you don't have ypbind running, it simply does nothing 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
08.02.2020 13:11, Stefan Seyfried пишет:
Am 08.02.20 um 01:09 schrieb Michael Ströder:
On 2/7/20 12:18 PM, Ludwig Nussel wrote:
Not sure what you are trying to say. The possibility to change any config file is not taken aways by using sane built in defaults.
Mainly I would not like to see nis or similar to be a compile-time default.
well, now it is in nsswitch.conf by default,
On my TW the only database that has NIS by default is automount. so having it compiled in
would not change anything.
And if you don't have ypbind running, it simply does nothing AFAICT.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.02.20 um 12:14 schrieb Andrei Borzenkov:
08.02.2020 13:11, Stefan Seyfried пишет:
Am 08.02.20 um 01:09 schrieb Michael Ströder:
On 2/7/20 12:18 PM, Ludwig Nussel wrote:
Not sure what you are trying to say. The possibility to change any config file is not taken aways by using sane built in defaults.
Mainly I would not like to see nis or similar to be a compile-time default.
well, now it is in nsswitch.conf by default,
On my TW the only database that has NIS by default is automount.
I just looked and found out that I use it mostly via the "compat" module. But NIS just works OOTB without any nsswitch config change ;-) -- 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 2/8/20 11:11 AM, Stefan Seyfried wrote:
Am 08.02.20 um 01:09 schrieb Michael Ströder:
On 2/7/20 12:18 PM, Ludwig Nussel wrote:
Not sure what you are trying to say. The possibility to change any config file is not taken aways by using sane built in defaults.
Mainly I would not like to see nis or similar to be a compile-time default.
well, now it is in nsswitch.conf by default, so having it compiled in would not change anything.
Security best practices mandate that you only have needed functionality enabled. Bear in mind that nss_ modules listed in /etc/nsswitch.conf get linked into every process. Thus I always remove unneeded stuff from nsswitch.conf, especially the nis module. Yes, today I can completely override the compile-time defaults with /etc/nsswitch.conf. But I suspect that the other day somebody has this great idea of making this impossible. Ciao, Michael. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 08.02.20 um 12:57 schrieb Michael Ströder:
Security best practices mandate that you only have needed functionality enabled. Bear in mind that nss_ modules listed in /etc/nsswitch.conf get linked into every process.
Thus I always remove unneeded stuff from nsswitch.conf, especially the nis module.
Well, and you do exactly the same in the future: by providing your own nsswitch.conf, you override the defaults. Nothing really changes.
Yes, today I can completely override the compile-time defaults with /etc/nsswitch.conf. But I suspect that the other day somebody has this great idea of making this impossible.
Has anybody spoken about "let's remove nsswitch.conf and just compile in the only possible setup"? I have not read anything resembling this. But instead of "shipping a default config file where you need to guess at next update if it has been changed" I think that "do not ship a default config file, but just set the defaults to what used to be in this file" seems sensible, because then you know *if* there is a config file, the admin has expressed his wishes -- and you can obey them. Or warn with a postinst message that he needs to look because something changed. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/02/2020 13.47, Stefan Seyfried wrote: | Am 08.02.20 um 12:57 schrieb Michael Ströder: |> Security best practices mandate that you only have needed |> functionality enabled. Bear in mind that nss_ modules listed in |> /etc/nsswitch.conf get linked into every process. |> |> Thus I always remove unneeded stuff from nsswitch.conf, |> especially the nis module. | | Well, and you do exactly the same in the future: by providing your | own nsswitch.conf, you override the defaults. | | Nothing really changes. | |> Yes, today I can completely override the compile-time defaults |> with /etc/nsswitch.conf. But I suspect that the other day |> somebody has this great idea of making this impossible. | | Has anybody spoken about "let's remove nsswitch.conf and just | compile in the only possible setup"? I have not read anything | resembling this. | | But instead of "shipping a default config file where you need to | guess at next update if it has been changed" I think that "do not | ship a default config file, but just set the defaults to what used | to be in this file" seems sensible, because then you know *if* | there is a config file, the admin has expressed his wishes -- and | you can obey them. Or warn with a postinst message that he needs to | look because something changed. | Having the defaults in the binary means that we users/admins will not know when the defaults change. Same problem as with removal of rpmnew files. - -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXj/uzQAKCRC1MxgcbY1H 1dSYAJ9D8+nM0iu7N9JmV5ppKOLtVBuzYQCeMeAW94gDonro/5a8ENaqaS3QemQ= =iQny -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, [...]
Operating system features that rely on a human reviewing rpm{old,new} files are flawed. We must design the system in such a way that it does not require interaction. Especially in cases where the user only used "approved" methods to configure the system. Means that if eg yast did the change it is in our responsibility to not maneuver the system into a state that it cannot recover from itself.
If the way nsswitch.conf works is incompatible with those requirements the concept has to be retired and replaced by something smarter.
Looks like nsswitch.conf kind of states the obvious most of the time anyways. Maybe we don't need it at all?
Even extra authentication methods could probably be determined automatically by looking at the system. Ie if sssd or ypbind are enabled it's not unlikely that those are meant to be used for authentication, right?
I fully agree, though I always check my .rpm* files and merge whatever seems to be necessary!
cu Ludwig
Bye. Michael. -- Michael Hirmke -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Dominique Leuenberger / DimStar writes:
Check your /etc/nsswitch.conf - do you happen to have a .rpmnew lingering around there with a diff? Generally, those service file moves are handled by libnss_usrfiles (make sure you have libnss_usrfiles2 instaled - but this should be a required by patterns already)
Yes, I had. I have never touched nsswitch.conf after installation myself, so obviously whatever check was applied to determine it was changed from the default did make some unwarranted assumptions. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Feb 04, Achim Gratz wrote:
Dominique Leuenberger / DimStar writes:
Check your /etc/nsswitch.conf - do you happen to have a .rpmnew lingering around there with a diff? Generally, those service file moves are handled by libnss_usrfiles (make sure you have libnss_usrfiles2 instaled - but this should be a required by patterns already)
Yes, I had. I have never touched nsswitch.conf after installation myself, so obviously whatever check was applied to determine it was changed from the default did make some unwarranted assumptions.
RPM compares the hash of the old original file from the RPM database with the current installed one to find out if there was a modification. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Mittwoch, 5. Februar 2020, 07:43:15 CET schrieb Thorsten Kukuk:
On Tue, Feb 04, Achim Gratz wrote:
Dominique Leuenberger / DimStar writes:
Check your /etc/nsswitch.conf - do you happen to have a .rpmnew lingering around there with a diff? Generally, those service file moves are handled by libnss_usrfiles (make sure you have libnss_usrfiles2 instaled - but this should be a required by patterns already)
Yes, I had. I have never touched nsswitch.conf after installation myself, so obviously whatever check was applied to determine it was changed from the default did make some unwarranted assumptions.
RPM compares the hash of the old original file from the RPM database with the current installed one to find out if there was a modification.
While this is technically correct, it ignores the fact, that many operations in YaST result in modifications of the files in question. Consequently, we have an impedance mismatch here: either don't use YaST for anything, that modifies those files (note, how vague this expression is on it's own), or fix the system with rpmcheckconfig, diff and vi after *any* update. And if not using YaST, you're on your own, anyway. Please note, how *any* possibility to adjust a system to your needs results in inconvenient activities, and the only convenient way to deal with this situation is *not* adjusting a system *at* *all*. Now, explain your aunt Annie, how to deal with this situation. You will fail miserably. The only option we have, is fixing all those systems ourselves. This is exactly the reason, why using Linux keeps to be a nerdy thing still. Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Thorsten Kukuk writes:
Yes, I had. I have never touched nsswitch.conf after installation myself, so obviously whatever check was applied to determine it was changed from the default did make some unwarranted assumptions.
RPM compares the hash of the old original file from the RPM database with the current installed one to find out if there was a modification.
The assumption when using that facility then is that the file in question is actually never touched -- and it obviously is a wrong assumption. I've in the meantime updated a second system that got a fresh install just about half a year ago and also there nsswitch.conf was modified, again without me changing anything directly. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (31)
-
Achim Gratz -
Andreas Schwab -
Andrei Borzenkov -
Arjen de Korte -
ASSI
-
Axel Braun -
Carlos E. R. -
Christian Boltz -
Daniel Morris -
David C. Rankin -
Dominique Leuenberger / DimStar -
Frank Krüger -
Frans de Boer -
Hans-Peter Jansen -
Jan Engelhardt -
Jogchum Reitsma -
Ludwig Nussel -
mh＠mike.franken.de -
Michael Ströder -
Michal Suchánek -
Olaf Hering -
Peter Suetterlin -
Richard Brown -
Roger Oberholtzer -
Roger Whittaker -
Stasiek Michalski -
Stefan Seyfried -
Thorsten Kukuk -
Tomas Chvatal -
Ulf Bartholomäus -
Werner Flamme