[opensuse-factory] New Tumbleweed snapshot 20200220 released!
Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&groupid=1&version=Tumbleweed&build=20200220 Please do not reply to this email to report issues, rather file a bug on bugzilla.opensuse.org. For more information on filing bugs please see https://en.opensuse.org/openSUSE:Submitting_bug_reports Packages changed: apache2-mod_perl baloo5 drbd-utils git (2.25.0 -> 2.25.1) gstreamer-editing-services ibus-table indent java-11-openjdk kcmutils man-pages (5.04 -> 5.05) nodejs12 (12.16.0 -> 12.16.1) ovmf pcsc-asedriveiiie-usb pcsc-asekey plasma5-thunderbolt (5.18.0 -> 5.18.1) zsh (5.8~pre3 -> 5.8) === Details === ==== apache2-mod_perl ==== - define %license for older codestreams ==== baloo5 ==== Subpackages: baloo5-file baloo5-file-lang baloo5-imports baloo5-imports-lang baloo5-kioslaves baloo5-kioslaves-lang baloo5-tools baloo5-tools-lang libKF5Baloo5 libKF5BalooEngine5 libKF5BalooEngine5-lang - Fix FileIndexScheduler being stuck after suspending it: 0001-FileIndexScheduler-Force-evaluation-of-indexerState-.patch - Add Sync-IndexerConfig-on-exit.patch to fix settings not getting saved (kde#417127) ==== drbd-utils ==== - BuildRequire pkgconfig(udev) instead of udev: allow OBS to shortcut through the -mini flavors. - Remove obsolete Groups tag (fate#326485) ==== git ==== Version update (2.25.0 -> 2.25.1) Subpackages: git-core git-cvs git-daemon git-email git-gui git-svn git-web gitk - git 2.25.1: * "git commit" now honors advise.statusHints * various updates, bug fixes and documentation updates ==== gstreamer-editing-services ==== Subpackages: libges-1_0-0 typelib-1_0-GES-1_0 - Switch to meson buildsystem: Remove all conditionals. - Replace gcc-c++ with generic c++_compiler BuildRequires. - Add pkgconfig(gstreamer-plugins-bad-1.0) BuildRequires, meson checks for it. - Add python3-gobject-devel, new dependency, needed due to changes elsewhere in the stack. - Disable pkgconfig(bash-completion) BuildRequires and resulting file, not built when using meson buildsystem. ==== ibus-table ==== - Add ibus-table_fix_other_tables_compile_error.patch: Fix ibus other tables compile errors(bnc#1160315). ==== indent ==== - Use xz sources - Split lang package - Fetch keyring from savannah ==== java-11-openjdk ==== Subpackages: java-11-openjdk-headless - DependOnVariableHelper.patch: Fix DependOnVariableHelper for make 4.3 - Install java icons not only versioned, but also postfixed by the "openjdk", in order to prevent install conflicts with other jdk 11 flavours. ==== kcmutils ==== Subpackages: libKF5KCMUtils5 libKF5KCMUtils5-lang - Add Check-activeModule-before-using-it.patch to fix crash when opening Kontact's settings (kde#417396) ==== man-pages ==== Version update (5.04 -> 5.05) - version update to 5.05 * Newly documented interfaces in existing pages clone.2 Add clone3() set_tid information Document CLONE_CLEAR_SIGHAND fcntl.2 Update manpage with new memfd F_SEAL_FUTURE_WRITE seal memfd_create.2 Update manpage with new memfd F_SEAL_FUTURE_WRITE seal loop.4 Document LOOP_SET_BLOCK_SIZE Document LOOP_SET_DIRECT_IO proc.5 Document /proc/sys/vm/unprivileged_userfaultfd - deleted patches - man-pages-somaxconn-default-value.patch (upstreamed) ==== nodejs12 ==== Version update (12.16.0 -> 12.16.1) Subpackages: nodejs12-devel npm12 - Update to LTS release 12.16.1: * Reverted regressions from 12.16.0 + accidental unflagging of self resolving modules - it now requires - -experimental-modules flag to enable. + process cleanup changes introduced WASM-Related assertion + use of largepages runtime option introduced linking failure + async_hooks was causing an exception when handling errors + enumerable Read-Only property on EventEmitter breaks @types/extend + exceptions in the HTTP parser were not emitting as an uncaughtException ==== ovmf ==== Subpackages: qemu-ovmf-x86_64 - Add ovmf-bsc1163959-PiDxeS3BootScriptLib-fix-numeric-truncation.patch to fix the numeric truncation to avoid the potential memory corruption (bsc#1163959, CVE-2019-14563) ==== pcsc-asedriveiiie-usb ==== - BuildRequire pkgconfig(udev) instead of udev: allo OBS to shortcut through -mini flavors. ==== pcsc-asekey ==== - BuildRequire pkgconfig(udev) instead of udev: allow OBS to shortcut through -mini flavors. ==== plasma5-thunderbolt ==== Version update (5.18.0 -> 5.18.1) Subpackages: plasma5-thunderbolt-lang - Update to 5.18.1 * New bugfix release * For more details please see: * https://www.kde.org/announcements/plasma-5.18.1.php - No code changes since 5.18.0 ==== zsh ==== Version update (5.8~pre3 -> 5.8) - Update to version 5.8 * Fixes CVE-2019-20044 bsc#1163882 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
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. Thanks Ulf -- 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, 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
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!
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
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
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
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
Citeren Andrei Borzenkov <arvidjaar@gmail.com>:
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
Am Sonntag, 23. Februar 2020, 21:20:25 CET schrieb Arjen de Korte:
Citeren Andrei Borzenkov <arvidjaar@gmail.com>:
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 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. 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 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 2020-02-24T08:45:57, Jiri Slaby <jslaby@suse.cz> 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?
I tend to agree. I'm not entirely stupid, but it took me a bit to hunt down why my system suddenly stopped working for some tools and things failed to even start after a reboot. Trying to justify this with "but it's technically correct, read the docs" doesn't help. How "files" didn't just default to include "usrfiles", with the option of disabling that if not wanted or needing to have that happen at a different search step, is entirely beyond me. I do understand the need to depreciate things from time to time and to eventually cut them out. And we obviously have the ability to communicate important information on updates - e.g., re-agreeing to licenses. At the very very least, this should have been an "emergency" message on update that is truly shoved into a user's face. Yes, yes, I can go hunting for rpmnew files. You are technically absolutely correct. Here's a cookie. -- SUSE Software Solutions Germany GmbH, MD: Felix Imendörffer, HRB 36809 (AG Nürnberg) "Architects should open possibilities and not determine everything." (Ueli Zbinden) -- 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 24. 02. 20, 9:53, Thorsten Kukuk wrote:
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.
It's still an issue of the system, not of the user. We are still missing debian's check-config-after-update thing. 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. But we had a discussion about the debian tool in the past with no apparent results… Not sure if only missing manpower is the blocker on that front. 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 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
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. Yeah, rpmconfigcheck is a good start. But when exactly is it run during update? thanks, -- js suse labs -- 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 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 Mon, Feb 24, 2020 at 5:57 AM Andreas Schwab <schwab@suse.de> 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, 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
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
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
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 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 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
On Tuesday 2020-02-25 10:58, Dominique Leuenberger / DimStar wrote:
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
60% files, 20% symlinks and 20% directories. Well that looks like an easy 40% to get rid of :-> -- 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
* Jiri Slaby <jslaby@suse.cz>, le 24-02-20, a écrit:
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.
In support: 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. Then how am I to know how to operate the merge between /etc/nsswitch.conf and nsswitch.conf.rpmnew ? Tools that edit configuration files should leave comments so that users do not have to make choices they do not understand. Cheers -- 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
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, 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
On Mon, Feb 24, 2020 at 5:20 AM Dominique Leuenberger / DimStar <dimstar@opensuse.org> 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
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 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
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
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
24.02.2020 13:19, Dominique Leuenberger / DimStar пишет:
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.
Like this? https://lists.opensuse.org/opensuse/2020-03/msg00004.html
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 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
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
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.
Thanks Ulf
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. Regards, Alexander -- 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
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? -- 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 <okurz@suse.de>, 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
On Tue, 25 Feb 2020 12:04:47 +0100, Oliver Kurz <okurz@suse.de> 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/
participants (21)
-
Andreas Schwab -
Andrei Borzenkov -
Arjen de Korte -
AW -
Bernard Lang -
Dominique Leuenberger -
Dominique Leuenberger / DimStar -
Felix Miata -
H.Merijn Brand -
Hans-Peter Jansen -
Jan Engelhardt -
Jiri Slaby -
Lars Marowsky-Bree -
Ludwig Nussel -
Michael Ströder -
Neal Gompa -
Oliver Kurz -
Simon Lees -
Stefan Seyfried -
Thorsten Kukuk -
Ulf Bartholomäus