Am Sonntag, 23. Februar 2020, 15:05:43 CET schrieb Ulf Bartholomäus:

Hi Together,

yesterday I updated a system which I not use so often. During the update on the GUI (via Plasma SW-update), this hangs / crashes with 50% progress.

Also at manual start of zypper and yast -i they crashed!

OK, aware the /etc/nsswitch.conf I do at first the "rpmconfigcheck".

cp /etc/nsswitch.conf.rpmnew /etc/nsswitch.conf solve the problem - but how a normal user should know it?

Please due in case of mandatory changes - the changes in the file directly and copy the original one to *.rpmsave - this is the better way from my point of view.

Just to harvest complaints from the other party (that relies on a hand crafted config). No, the better way would have been to save the original as *.save-$(whatever) and modify the file in place. I'm pretty sure, that this will be the way, SLE and probably a future Leap will do this transition... BTW, KF5 doesn't survive all upgrades made by plasma5-pk-updates. Big (KF5) updates a better made logged off, from console/ssh as root with zypper dup. Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am Sonntag, 23. Februar 2020, 16:02:49 CET schrieb Michael Ströder:

On 2/23/20 3:43 PM, Hans-Peter Jansen wrote:

...

Am Sonntag, 23. Februar 2020, 15:05:43 CET schrieb Ulf Bartholomäus:

...

OK, aware the /etc/nsswitch.conf I do at first the "rpmconfigcheck".

cp /etc/nsswitch.conf.rpmnew /etc/nsswitch.conf solve the problem - but how a normal user should know it?

[..] No, the better way would have been to save the original as *.save-$(whatever) and modify the file in place.

No!

If there are changes to passwd or group maps lines in /etc/nsswitch.conf to integrate with a central user management one could not even login anymore.

I cannot follow. If you add usrfiles to services, protocols, rpc, ethers and aliases, why would that change prevent users from login?

...

I'm pretty sure, that this will be the way, SLE and probably a future Leap will do this transition...

I hope not!

You shouldn't always imply the worst, Michael. There were a lot of much more involved transitions in the /etc/pam.d ongoing, and most of us never noticed! If nsswitch.conf would have been treated like this, a lot of churn would have been avoided, sure, but approaching this from the positive side, many users are aware of "rpmcheckconfig" now, some probably of "systemctl enable rpmconfigcheck", and a few even of "etc-update". All the best! Cheers, Pete -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Sunday 2020-02-23 17:33, Ulf Bartholomäus wrote:

Especially a full automatic installed openSUSE - must work w/o any manual action from user !!!

And yet you did *some* action to /etc/nsswitch.conf that changed its content so that it no longer matched the pristine version (and rpm knows that by way of a checksum); subsequently, rather than overwriting whatever change it is you did, rpm created /etc/nsswitch.conf.rpmnew. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Citeren Andrei Borzenkov :

23.02.2020 19:59, Jan Engelhardt пишет:

...

On Sunday 2020-02-23 17:33, Ulf Bartholomäus wrote:

...

Especially a full automatic installed openSUSE - must work w/o any manual action from user !!!

And yet you did *some* action to /etc/nsswitch.conf that changed its content so

No. What is being stubbornly ignored here - no user who reported this problem did consciously modify this file.

The *user* may not have done so, but apparently it *was* modified )otherwise it would have been silently updated). My guess the culprit here is 'nss-mdns', which modifies /etc/nsswitch.conf in the %post install script.

...

that it no longer matched the pristine version (and rpm knows that by way of a checksum); subsequently, rather than overwriting whatever change it is you did, rpm created /etc/nsswitch.conf.rpmnew.

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 24. 02. 20, 6:50, Thorsten Kukuk wrote:

On Sun, Feb 23, Andrei Borzenkov wrote:

...

No. What is being stubbornly ignored here - no user who reported this problem did consciously modify this file.

Which is wrong. RPM is checking the checksum of that file, and the checksum is not lying. This users did modify this file, maybe not implicit, but then by using YaST and making changes to it. Like configuring NIS.

It's actually not that wrong. It's not only configuring NIS. And even if it were, it doesn't matter, people shouldn't care about changed underlying files at all.

If you don't exactly know what you are doing does not mean that you are not doing it.

That is what "consciously" means in the above sentence, IMO. Looking at the nth report of the same, whoever introduced this state, should fix it. No matter how /etc/nsswitch.conf was modified, an update shall not break a working system. Period. If it does, _we_ failed, not them. And if we keep repeating "you did update the file, handle it", we are only losing users, right? /me neither changed /etc/nsswitch.conf manually and I had to fix this mess up. If yast or some %post script did it, OK, so what -- should I fix it? Not at all, the update should as I am using high-level tools like yast. If we are to modify files anyway, we can drop yast completely as it becomes useless. If this is not resolved properly, I vote for reverting the change in Tumbleweed, so that it does not propagate any further. Especially to Leap. regards, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Feb 24, Jiri Slaby wrote:

Looking at the nth report of the same, whoever introduced this state, should fix it. No matter how /etc/nsswitch.conf was modified, an update shall not break a working system. Period. If it does, _we_ failed, not them. And if we keep repeating "you did update the file, handle it", we are only losing users, right?

Wrong. You are looking at a very trivial example, which breaks your system visible. So you had luck. We had examples last year, where ignoring *.rpmnew files could lead to security holes, and because of the complex syntax of the config files, a simple approach of fixing this automatically is impossoble. So in that cases, no visible break, but invisible security holes.

/me neither changed /etc/nsswitch.conf manually and I had to fix this mess up. If yast or some %post script did it, OK, so what -- should I fix it? Not at all, the update should as I am using high-level tools like yast. If we are to modify files anyway, we can drop yast completely as it becomes useless.

If this is not resolved properly, I vote for reverting the change in Tumbleweed, so that it does not propagate any further. Especially to Leap.

As I wrote: we have an automatism in place to adjust the config, but it looks like this is not working for everybody. And as I wrote: if this move would be the only root cause, why have so many people still problems after reverting the change? It's simple to jump on a train, but not to jump on the correct train. The update contain many more updates, not only the move of services, like nfs, which seems to contain a config file with syntax errors ... 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 24.02.20 um 06:50 schrieb Thorsten Kukuk:

On Sun, Feb 23, Andrei Borzenkov wrote:

...

No. What is being stubbornly ignored here - no user who reported this problem did consciously modify this file.

Which is wrong. RPM is checking the checksum of that file, and the checksum is not lying. This users did modify this file, maybe not implicit, but then by using YaST and making changes to it. Like configuring NIS. If you don't exactly know what you are doing does not mean that you are not doing it.

look at nss-mdns %post script. This beast is installed in a default installation. Do not blame users who did nothing wrong. nss-mdns's /usr/sbin/nss-mdns-config is also the thing that creates the mysterious /etc/nsswitch.confbak file -- 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 Mon, 2020-02-24 at 10:48 +0100, Stefan Seyfried wrote:

You did nothing wrong. The nss-mdns package messes around with nsswitch.conf (and creates the ...bak file). And because it is installed at least on every desktop default installation, it is obvious that nobody really tested the usr/etc move, or they just waved the problems away with "Let the stoopid users suffer! They deserve it!!!" ;-)

Stefan, Please stay fair and stop spreading this 'nobody tested'-nonsense. You know very well how the process is. This services file move did have a couple of tests revealed during the testing that were addressed - simple things like curl https://localhost did not work. We have a dozen upgrade tests from previous openSUSE versions to Tumbleweed passing with every snapshot being released. Of course, it's all standard test scenarios with 'well defined states' to get started - and that has always been known as a 'shortcoming' of any test done. Generally you only know what to test for once you'd seen a failure in the area. To recap: there were two issues around the /etc/services move to /usr/etc: 1) nsswitch.conf being modified on-disk and RPM thus not replacing it 2) Users not having libnss_usrfiles2 installed for 1): yes, nss-mdns modifying the file is an ugly side effect resulting in this issue. What's not yet fully clear (and we're looking into) is why openQA never stumbled over this in the numerous upgrade test scenarios. This is, frankly speaking, the only interesting and valid question. All the rest in this thread is emotional mumble - which I can understand, but after a while is now just becoming distraction. The pain was heard, there is no reason to repeat it every other day. In order to address that, the %post script of aaa_base has actually been enhanced to try to correct the nsswitch.conf for all users.

# Fix /etc/nsswitch.conf, either because admin ignored *.rpmnew, # or because of YaST bug [bsc#1162916] grep -q ^services.*usrfiles /etc/nsswitch.conf if [ $? -eq 1 ]; then cp /etc/nsswitch.conf /etc/nsswitch.conf.pre-usrfiles sed -e 's|^\(services:.*[[:space:]]\)files\>([[:space:]].*\)*$|\1files usrfiles\2|' /etc/nsswitch.conf > /etc/nsswitch.conf.usrfiles mv /etc/nsswitch.conf.usrfiles /etc/nsswitch.conf fi

This script has been in TW since snapshot 0206. Well possible that fix is incomplete (@Thorsten: possibly it should be enhanced for protocols/rpc/aliases?) for 2) libnss_usrfiles2 has been required by patterns-base-minimal_base since Snapshot 20190919 (long before we switched services to /usr/etc). What we had not anticipated was that there were users that removed this pattern from their system - and users building up containers without the pattern. we thus added a dependency from netcfg (the thing owning /usr/etc/services) to require libnss_usrfiles2 - fix was also published in snapshot 0206. So, while yo uall stay emotional on the topic, I very much would like to ask you to 'park' the emotion and bring the discussion on a technical level. It would be much easier to identify possible further gaps and address them - without having to find the technical needle in an emotional haystack. For people still facing issues with current TW snapshots: please be sure to not just 'jump the gun' and assume this to be the problem. I hope we can finally move forward to actually FIX the issues - if there are really still some left (and people not just being on older snapshots) - and move on. It's less the 'bug' that drives people away, but the way people communicate about the problem. And in this area we all have a lot of room to improve. Cheers, Dominique

24.02.2020 13:19, Dominique Leuenberger / DimStar пишет:

In order to address that, the %post script of aaa_base has actually been enhanced to try to correct the nsswitch.conf for all users.

...

# Fix /etc/nsswitch.conf, either because admin ignored *.rpmnew, # or because of YaST bug [bsc#1162916] grep -q ^services.*usrfiles /etc/nsswitch.conf if [ $? -eq 1 ]; then cp /etc/nsswitch.conf /etc/nsswitch.conf.pre-usrfiles sed -e 's|^\(services:.*[[:space:]]\)files\>([[:space:]].*\)*$|\1files usrfiles\2|' /etc/nsswitch.conf > /etc/nsswitch.conf.usrfiles mv /etc/nsswitch.conf.usrfiles /etc/nsswitch.conf fi

This script has been in TW since snapshot 0206. Well possible that fix is incomplete (@Thorsten: possibly it should be enhanced for protocols/rpc/aliases?)

If protocol name cannot be resolved, mount.nfs fails.

On 2/24/20 8:18 PM, Stefan Seyfried wrote:

...

I do not know whether this excerpt of a former mail can help but my original /etc/nsswitch.conf was modified, the initial version being renamed /etc/nsswitch.confbak

Here is the change, which added "mdns_minimal [NOTFOUND=return]" on line 29

# diff nsswitch.conf nsswitch.confbak 29c29 < hosts: files mdns_minimal [NOTFOUND=return] dns ---

...

hosts: files dns #

I may have caused it unwittingly, but I never knew it had occured until now, and I still do not know what caused it. Actually I did not even know what it meant until I searched yesterday. And now that I know, I still wonder what it is useful for. You did nothing wrong. The nss-mdns package messes around with nsswitch.conf (and creates the ...bak file). And because it is installed at least on every desktop default installation, it is obvious that nobody really tested the usr/etc move, or they just waved the

Am 24.02.20 um 10:12 schrieb Bernard Lang: problems away with "Let the stoopid users suffer! They deserve it!!!" ;-)

Well it wasn't installed on my default desktop installation (which is less commonly selected) so I guess your statements aren't completely true (that doesn't mean it shouldn't be fixed somehow). -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Mon, Feb 24, Jiri Slaby wrote:

It's still an issue of the system, not of the user.

We have a service for that since two decades, but users always complain about the amount of work if we enable it.

We are still missing debian's check-config-after-update thing.

Stop thinking in single Desktop users ...

The system should at least notify the updater about the config changes. Doing find / -name '*.rpm*' after each update is a silly approach and clearly doesn't work as you write.

rpmconfigcheck ? systemctl enable --now rpmconfigcheck ? 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 Mon, Feb 24, 2020 at 5:57 AM Andreas Schwab wrote:

On Feb 24 2020, Jiri Slaby wrote:

...

It's still an issue of the system, not of the user. We are still missing debian's check-config-after-update thing.

It's called rpmconfigcheck.

Actually no, rpmconf is the closer equivalent, since it's designed to be invoked automatically with package managers. For example, when using DNF with the rpmconf plugin installed (dnf-plugin-rpmconf), you're prompted after transactions to resolve altered configuration files. -- 真実はいつも一つ！/ Always, there's only one truth! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, 2020-02-24 at 12:31 +0100, Thorsten Kukuk wrote:

On Mon, Feb 24, Dominique Leuenberger / DimStar wrote:

...

To recap: there were two issues around the /etc/services move to /usr/etc:

1) nsswitch.conf being modified on-disk and RPM thus not replacing it 2) Users not having libnss_usrfiles2 installed

3) config tools are removing usrfiles

...

This script has been in TW since snapshot 0206. Well possible that fix is incomplete (@Thorsten: possibly it should be enhanced for protocols/rpc/aliases?)

You only need to accept aaa_base in some of your stagings ;)

Evil :) But at least the SR was created later than my email.. lucky me. I should get a suitable staging ready this afternoon, once I can accept B and C (waiting for ARM to finish building of 0222) Cheers, Dominique

Am Montag, 24. Februar 2020, 06:50:57 CET schrieb Thorsten Kukuk:

On Sun, Feb 23, Andrei Borzenkov wrote:

...

No. What is being stubbornly ignored here - no user who reported this problem did consciously modify this file.

Which is wrong. RPM is checking the checksum of that file, and the checksum is not lying. This users did modify this file, maybe not implicit, but then by using YaST and making changes to it. Like configuring NIS. If you don't exactly know what you are doing does not mean that you are not doing it.

But if other setup routines change it, the user don't know it. My System installed with 20200211 - the original version was: # ls -l -rw-r--r-- 1 root root 1189 24. Jan 14:14 /etc/nsswitch.conf # ls -lc -rw-r--r-- 1 root root 1189 8. Feb 17:03 /etc/nsswitch.conf The last modified date was before installation!!! So seams that checksum was wrong or change date. Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Doinique, excuse starting this discussion :-/ Some remarks/proposals from a stupid home office user. 1. It will be nice if there are initial information present during bigger changes. So that a normal user can be aware (clear summary at zypper dup, yast update or plasmoid for aupdate. 2. If there is a non clear behavior, address it to a standard user with links to something like a wiki - which are (not mandatory the developer) shows some remarks and step by step descriptions (in best case for GUI only users too) how to solve the issues. 3. Updates in live systems, which have an issue, should be communicated fast and open to the users/customers. Now one is perfect - all users accept this if the problem is open and fast addressed. Ok, seems to be, that I'm to often addressing also in our company, but each person knows the complexity of the today world, but don't tell them that there are not capable to know the problems. Best Regards Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

[?] Hi Ulf, hi ?all?,

I'm a user of TW, but not an IT-professional. So I'd really like to avoid the trouble of a non booting or hanging system after the 20200220 update.

After reading this thread, I tested my sytem:

=== === === linux-izun:/home/AW # rpmconfigcheck Searching for unresolved configuration files Please check the following files (see /var/adm/rpmconfigcheck): /etc/nsswitch.conf.rpmnew /etc/postfix/main.cf.rpmnew /etc/postfix/master.cf.rpmnew /etc/profile.d/zzz-texlive.csh.rpmsave /etc/profile.d/zzz-texlive.sh.rpmsave /etc/pulse/client.conf.d/50-system.conf.rpmsave /etc/sysctl.conf.rpmnew /etc/systemd/system.conf.rpmnew /etc/zypp/zypp.conf.rpmnew

=== === ===

So it seems my sytem is affected, right?

What is the best way to avoid havoc while upgrading using zypper dup? I'd like to do something _in_advance_ to the upgrade to prevent the trouble.

By the way: I never touched nsswitch.conf.

I don't think you can find out which config files *would* be changed by upgrade without conducting the actual upgrade. What you can do *before* upgrade already is check if there might be config changes still pending based on rpmconfigcheck to keep the difference low and prepare for further config changes. After upgrade make sure to run rpmconfigcheck and fix all reported problems as soon as possible. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 24. 02. 20, 14:15, Hans-Peter Jansen wrote:

The recommended workflow should be:

zypper dup rpmconfigcheck etc-update <with top level dir from rpmconfigcheck>

Ugh, too complicated and too error-prone (easy to forget). On the top of that, despite using TW since the beginning, I don't even know about these tools (the last one is not even installed by default). How an average user should know this then? (And sure, it's not only about TW.) And still, if a tool (yast or rpm %post) changed a config, not a user, how the user is supposed to decide? Namely, I mean the nsswitch.conf issue? Well, look at a today's example: https://lists.opensuse.org/opensuse-factory/2020-02/msg00521.html

Would be nice, if zypper could be tricked into calling these automatically.

+1 -- that was exactly my point. And that's what apt/aptitude in debian does. So far, as it stands, it still holds that *noone* can expect users are scanning / for .rpm{new,save} and handle them. Despite everyone is expected to. No matter how incorrect/unsafe/non-technical/whatever it is, the users don't. Note that my oldest .rpmnew (hiding somewhere in /usr) was from 2007, but who cares. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, Feb 25, Ludwig Nussel wrote:

If the config is too complex to fix automatically, what kind of qualification does a human have to have to sort it out manually by staring at rpmnew files? IOW no matter what, having to manually sort out rpmnew files is a clear indication of a deeper problem that needs to be solved at the root. Anything built to deal with rpmnew files is just papering over the problem.

Correct, we need to fix the problem that every typo fix in a configuration file will lead to a *.rpmnew or *.rpmsave file. And this is this whole exercise about: minimize the situations, where RPM has to create a rpmnew or rpmsave file. And not doing the opposite, mess even more around with configuration file automatically so that RPM has to create even more rpmnew and rpmsave files which will even more likely break users systems earlier than later. -- 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-25 10:52, Felix Miata wrote:

Thorsten Kukuk composed on 2020-02-25 10:44 (UTC+0100):

...

Correct, we need to fix the problem that every typo fix in a configuration file will lead to a *.rpmnew or *.rpmsave file. And this is this whole exercise about: minimize the situations, where RPM has to create a rpmnew or rpmsave file. And not doing the opposite, mess even more around with configuration file automatically so that RPM has to create even more rpmnew and rpmsave files which will even more likely break users systems earlier than later.

Doesn't this whole subject become moot when the /usr/etc/ transition is complete??? Aren't we nearly there already?

Well no, because nss-mdns manually editing nsswitch.conf outside of rpm's knowledge is not fixable by moving stuff into (our out of) /usr/etc. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tuesday, 25 February 2020 08.40.05 CET AW wrote:

Am Dienstag, 25. Februar 2020, 08:28:26 CET schrieb Oliver Kurz:

...

...

[?] Hi Ulf, hi ?all?,

I'm a user of TW, but not an IT-professional. So I'd really like to avoid the trouble of a non booting or hanging system after the 20200220 update.

After reading this thread, I tested my sytem:

=== === === linux-izun:/home/AW # rpmconfigcheck Searching for unresolved configuration files

Please check the following files (see /var/adm/rpmconfigcheck): /etc/nsswitch.conf.rpmnew /etc/postfix/main.cf.rpmnew /etc/postfix/master.cf.rpmnew /etc/profile.d/zzz-texlive.csh.rpmsave /etc/profile.d/zzz-texlive.sh.rpmsave /etc/pulse/client.conf.d/50-system.conf.rpmsave /etc/sysctl.conf.rpmnew /etc/systemd/system.conf.rpmnew /etc/zypp/zypp.conf.rpmnew

=== === ===

So it seems my sytem is affected, right?

What is the best way to avoid havoc while upgrading using zypper dup? I'd like to do something _in_advance_ to the upgrade to prevent the trouble.

By the way: I never touched nsswitch.conf.

I don't think you can find out which config files *would* be changed by upgrade without conducting the actual upgrade. What you can do *before* upgrade already is check if there might be config changes still pending based on rpmconfigcheck to keep the difference low and prepare for further config changes. After upgrade make sure to run rpmconfigcheck and fix all reported problems as soon as possible.

Oliver, thank you, but...

According to rpmconfigcheck (why isn't there any manpage?) the file nsswitch.conf has been altered.

So the new TW snapshot 20200220 will, according to this thread, break my system.

And my apologies, but »fix all reported problems as soon as possible« isn't helpfull to me. Hey, I'm a user!

So how to proceed?

Right, Sorry :) You should compare each ".rpmnew" file against the source file and merge the files. E.g. based on for i in $(cat /var/adm/rpmconfigcheck); do vimdiff $i ${i%.rpm*}; done you should take over as much as possible from .rpmnew files to be consistent with new syntax but preserve any changes that you personally directly or indirectly introduced and want to keep. "Indirect" changes could happen if you use e.g. YaST to configure services. After you merged and crosschecked all files you should delete all .rpmnew and .rpmsave files to have an empty list which you can check with another call of `rpmconfigcheck`. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

* Oliver Kurz , le 25-02-20, a écrit:

...

You should compare each ".rpmnew" file against the source file and merge the files. E.g. based on for i in $(cat /var/adm/rpmconfigcheck); do vimdiff $i ${i%.rpm*}; done you should take over as much as possible from .rpmnew files to be consistent with new syntax but preserve any changes that you personally directly or indirectly introduced and want to keep. "Indirect" changes could happen if you use e.g. YaST to configure services. After you merged and crosschecked all files you should delete all .rpmnew and .rpmsave files to have an empty list which you can check with another call of `rpmconfigcheck`.

Hi Much of the discussion is beyond me, still ... My feeling is that it is essential to know, for future maintenance, where all changes came from in the past. My own example is the usefulness of the file nsswitch.confbak to determine that line 29 of nsswitch.conf has been modifed in my system, and that this modification should probably be applied to nsswitch.conf.rpmnew before substituing it to nsswitch.conf. I would not know of this modification without nsswitch.confbak. Hence my own suggestion would be to keep the history by preserving all files, adequately renamed and dated with the command "old". Maybe we do not need it all, or we can mechanize much of the process (there is literature on automatic merge of independent changes), but that should be analyzed formally by theoretical means. -- Bernard.Lang@datcha.net ,_ /\o \o/ mobile +33 6 6206 1693 http://www.datcha.net/ ^^^^^^^^^^^^^^^^^ fixe +33 1 3056 1693 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Thorsten Kukuk schrieb:

On Tue, Feb 25, Ludwig Nussel wrote:

...

If the config is too complex to fix automatically, what kind of qualification does a human have to have to sort it out manually by staring at rpmnew files? IOW no matter what, having to manually sort out rpmnew files is a clear indication of a deeper problem that needs to be solved at the root. Anything built to deal with rpmnew files is just papering over the problem.

Correct, we need to fix the problem that every typo fix in a configuration file will lead to a *.rpmnew or *.rpmsave file. And this is this whole exercise about: minimize the situations, where RPM has to create a rpmnew or rpmsave file. And not doing the opposite, mess even more around with configuration file automatically so that RPM has to create even more rpmnew and rpmsave files which will even more likely break users systems earlier than later.

So what's the takeaway for libnss_usrfiles2 then? And what's the case that caused security issues you mentioned? 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