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'm pretty sure, that this will be the way, SLE and probably a future Leap will do this transition...

I hope not! Ciao, Michael. -- 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!

Yes!!! If you modify the files direct (without *.local) you know the details. So it will be easy for you to do the changes manually. No standard user which only install the openSUSE w/ GUI only and never use the CLI / Terminal at all, will be capable to repair the system. So in best case they need the support from Linux specialists e.g. from the local LUG or in worst case switch to an other OS. This can't be the goal from openSUSE!!! Remark: In the moment I fight in my LUG that additional users switch from *Buntu or similar to openSUSE! With the trouble now, I won't do it due to the additional effort on my side!!!

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.

Yes, but users which have this are familar with Linux CLI / terminal !!!

...

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

I hope not!

I hope yes!!! Especially a full automatic installed openSUSE - must work w/o any manual action from user !!! Ulf -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

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.

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

Am Sonntag, 23. Februar 2020, 21:20:25 CET schrieb Arjen de Korte:

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.

I'm not sure. My System installed with TW 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 release date of the TW ISO and for sure 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

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

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

Am Montag, 24. Februar 2020, 12:25:59 CET schrieb Jiri Slaby:

On 24. 02. 20, 11:57, 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.

rpmconfigcheck is by far the debian thing. The latter has UI, asks, compares, reloads services and more.

This is called etc-update. Having this being called manually is fine with me.

Yeah, rpmconfigcheck is a good start. But when exactly is it run during update?

It's not enabled by default: systemctl enable rpmconfigcheck Of course, this all is doomed as long as any graphical updaters are running: zypper rm PackageKit* plasma5-pk-updates zypper al PackageKit* plasma5-pk-updates The recommended workflow should be: zypper dup rpmconfigcheck etc-update <with top level dir from rpmconfigcheck> Would be nice, if zypper could be tricked into calling these automatically. Cheers, Pete -- 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

Thorsten Kukuk schrieb:

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 the answer is there. That thing needs a different way of configuration so it does the right thing no matter what. What component are you talking about? 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. 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

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? -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Tue, 2020-02-25 at 04:52 -0500, 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?

I applaud you for seeing the target goal! And YES! Once the split is clear that /usr/etc is 'distro default config' and /etc is 'user/admin config', the distro can update the config 'as often as it needs to' without having to worry about .rpmnew/.rpmsave files (nothing in /usr/etc will be marked %config). As to 'are we there yet' - saldy, no. It's still a long road ahead.# $ find /etc -type f | wc -l 2384 Surely not ALL of those will ever vanish - but > 2k is still a lot to claim 'nearly there'. And I intentionally did not go into more details here as to how many of those files would a) already be able to actually not exist, as the daemon would support the separation b) how many of those things are really configurations modified by me c) how many of those files I actually have any clue what they are doing :) Cheers, Dominique

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

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!!!" ;-) -- 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, Feb 24, 2020 at 5:20 AM Dominique Leuenberger / DimStar wrote:

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.

I think this issue shows that someone needs to prioritize fixing how this functionality is supposed to work to begin with. Maybe getting glibc to finally have drop-in files for enabling nsswitch modules? Has anyone responsible for the usrfiles nss module change reached out to upstream yet? -- 真実はいつも一つ！/ 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, 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 ;) For 3) the fix should have gone out before hackweek, have to push that teams ... 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

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

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

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

On Tue, 25 Feb 2020 12:04:47 +0100, Oliver Kurz wrote:

On Tuesday, 25 February 2020 08.40.05 CET AW wrote:

...

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

...

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.

Ah, but you should also look at the dates. If you've never merged .rpmnew or .rpmsave changes, the new .conf (or whatever) might actually be much more recent than the .rpmnew Also note that some files (might) have been changed by YaST, which sometimes leaves a backup of the changed file: $ perl -nE'say for grep{-f&&/yast/i}glob s/\.rpm\w*$/\*/r' /var/adm/rpmconfigcheck /etc/aliases.YaST2save /etc/inittab.yast2.tmp /etc/openldap/slapd.conf.YaSTsave /etc/postfix/sasl_passwd.YaST2.save /etc/postfix/sender_canonical.YaST2save /etc/postfix/virtual.YaST2save Often I get more useful information out of doing a diff -w of that yast backup to the rpmnew then form diffing the current file to the rpmnew Hope this helps at least someone :)

"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`.

👍 -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.31 porting perl5 on HP-UX, AIX, and Linux https://useplaintext.email https://tux.nl http://www.test-smoke.org http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/