Bug 14266 - If you accept .rpmnew from the setup package, all your login data is lost and you cannot log in anymore
Summary: If you accept .rpmnew from the setup package, all your login data is lost and...
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 4
Hardware: All Linux
Priority: High critical
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL:
Whiteboard: has_procedure advisory MGA4-64-OK MGA...
Keywords: validated_update
: 12006 15548 (view as bug list)
Depends on:
Blocks: 14516 15548
  Show dependency treegraph
 
Reported: 2014-10-12 00:36 CEST by Frédéric "LpSolit" Buclin
Modified: 2023-10-28 17:58 CEST (History)
20 users (show)

See Also:
Source RPM: rpmdrake
CVE:
Status comment:


Attachments
Patch to filter out critical config files after packages are installed (1.44 KB, text/plain)
2015-03-22 20:03 CET, Martin Whitaker
Details
Patch to filter out critical config files after packages are installed (1.38 KB, text/plain)
2015-03-22 23:05 CET, Martin Whitaker
Details
screenshot (54.14 KB, image/png)
2015-03-23 12:29 CET, claire robinson
Details
Log from upgrading rpmdrake and setup afterwards (8.59 KB, application/save)
2015-03-23 16:26 CET, Rémi Verschelde
Details

Description Frédéric "LpSolit" Buclin 2014-10-12 00:36:57 CEST
Cauldron just offered an update for the "setup" package. It asked me if I wanted to use the .rpmnew file, I said yes. Now I cannot log in anymore.

It seems totally crazy to offer a .rpmnew which deletes all your credentials. Now I cannot log in anymore. Both my account and the root account passwords are gone. What am I supposed to do? What's the point to offer the user to choose .rpmnew, besides shooting himself in the foot?
Comment 1 Sander Lepik 2014-10-12 00:46:08 CEST
Hmm, is it possible that Chris broke something with his last changes? I know we had this problem once before and it got fixed..

CC: (none) => dirteat, mageia, mageia, thierry.vignaud, tmb

Comment 2 Chris Denice 2014-10-12 11:49:22 CEST
Hi there,
I don't think so as the package has not been pushed yet (the new version is 2.7.21)

The fact that a .rpmnew exists is precisely to not overwrite the previous one; so this part of the installation makes sense.

The issue is in the question "asking to use rpmnew" which should not be asked. This does not happen with urpmi; so I would rather report this bug to the gui installation prog! 

cheers,
chris.
Comment 3 Thomas Backlund 2014-10-12 12:25:17 CEST
(In reply to Frédéric Buclin from comment #0)
> Cauldron just offered an update for the "setup" package. It asked me if I
> wanted to use the .rpmnew file, I said yes. Now I cannot log in anymore.
> 

How did you update ?
rpmdrake or urpmi ?

> It seems totally crazy to offer a .rpmnew which deletes all your
> credentials. Now I cannot log in anymore. Both my account and the root
> account passwords are gone. What am I supposed to do? What's the point to
> offer the user to choose .rpmnew, besides shooting himself in the foot?

atleast rpmdrake has a blacklist for critical files:
http://gitweb.mageia.org/software/rpmdrake/tree/Rpmdrake/rpmnew.pm#n42

I dont remember if urpmi obey the same list...
Comment 4 Frédéric "LpSolit" Buclin 2014-10-12 14:24:36 CEST
(In reply to Thomas Backlund from comment #3)
> How did you update ?
> rpmdrake or urpmi ?

MageiaUpdate
Comment 5 Thomas Backlund 2014-10-12 15:14:16 CEST
ok, thats weird then :/

mageiaupdate is part of rpmdrake and calls do_merge_if_needed() wich checks the above mentioned ignores_rpmnew list ...
Comment 6 Colin Guthrie 2014-10-12 18:31:13 CEST
Perhaps for files like /etc/passwd we should ghost them and then populate them at first install in the %post or, better, via tmpfiles or, even better, sysusers.

This avoids marking the files as config (and thus getting rpmnew) and avoids any chance of rpm overwriting them on upgrade. It also ensures the system can self populate after an rm -rf /etc/* which is a good aim generally (it'll be a long time before we can really offer this as a feature, but baby steps towards it don't hurt).
Rémi Verschelde 2015-03-21 15:48:30 CET

Severity: major => critical
CC: (none) => remi
Priority: Normal => High

Comment 7 Rémi Verschelde 2015-03-21 15:51:16 CET
(In reply to Thomas Backlund from comment #5)
> ok, thats weird then :/
> 
> mageiaupdate is part of rpmdrake and calls do_merge_if_needed() wich checks
> the above mentioned ignores_rpmnew list ...

Thierry, any idea why this is not working as expected?
Marja Van Waes 2015-03-21 16:51:51 CET

Blocks: (none) => 15548

Comment 8 Marja Van Waes 2015-03-21 16:53:42 CET
For the record, when updating with urpmi --auto-updates, I was *not* asked whether I wanted to use rpm.new, but only saw this message:

  8/22: setup                 ###################################################warning: /etc/shadow created as /etc/shadow.rpmnew
#####

So the problem seems to be with MageiaUpdate.
Just asked in bug 15548 how the user (if he was indeed bitten by this issue) updated his system.

CC: (none) => marja11

Comment 9 Angelo Naselli 2015-03-21 17:19:01 CET
i guess so marja

CC: (none) => anaselli

Comment 10 Chris Denice 2015-03-21 18:18:34 CET
I am playing the old guy here but it does not make *any* sense to even ask such a horrible thing to use an .rpmnew file after a package update. This breaks completely the purpose of config(noreplace).

If an user wants to tweak his system, he has to play with a terminal and root privileges. Offering this to lamda users is an open door to hell!

cheers,
chris.
Comment 11 Angelo Naselli 2015-03-21 18:54:08 CET
well installing is already a thing that requires root/admin rights...
Moreover a dialog is offered and you can see the differences and choose
also to leave things as they are (.rpmew and the current config file) to do any actions later.
Comment 12 Frédéric "LpSolit" Buclin 2015-03-21 20:10:21 CET
(In reply to Angelo Naselli from comment #11)
> Moreover a dialog is offered and you can see the differences

Being able to see the differences doesn't mean you understand what you are seeing. I hate when people think that all admins are Linux experts. This would mean that only geeks should install Linux, and that all other users should stay with Windows (or Mac OS X).

The fact that rpmnew is unable to merge old settings is also a pain. It's a all or nothing.
Rémi Verschelde 2015-03-21 21:31:17 CET

Blocks: (none) => 14516

Comment 13 Angelo Naselli 2015-03-21 22:08:37 CET
Well take as it if you don't know what you're doing you'll do at your own risk.

And yes merging is not easy, so all or nothing, why? because  you can have keys
that have been added or removed, or values that have been changed in their default
or set, so it's not easy, yes maybe a merge-tool could be used or iirc just adding
a configuration to rpmdrake to do nothing by default.
But sooner or later someone has to check if configuration has changed, because it
can happen that the program does not work properly any more...
So if you don't know what you're doing and the you have the choice of doing nothing i think there is nothing crazy there but doing things.

BTW i've never thought that someone needs to be geek to use and install linux
and who is not or does not understand things has to stay in windows. Otherwise
i would have never been part of a community and associotions.

Just to clarify, my comment #11 was in reply to comment #10.
Comment 14 Colin Guthrie 2015-03-22 09:25:46 CET
FWIW, there is code in place to NOT do rpmnew questions for the setup package. This is just a bug, it surfaced a while back but it's certainly not meant to do it. Thierry has looked at it in the past but not sure of the current state of things.
Comment 15 Rémi Verschelde 2015-03-22 10:12:39 CET
Looking at the date of the initial report, I wonder if it's not due to the RPM 4.12 update? Maybe the way we're blacklisting some config files from the .rpmnew logic maybe does not work well with the new RPM API?
Comment 16 Marja Van Waes 2015-03-22 10:17:20 CET
Or it only occurs when .rpmnew files have been created for more packages than jast setup?

see attachment 6111 [details] and 6114 from bug 15548
Comment 17 Marja Van Waes 2015-03-22 10:18:18 CET
s/jast/just/
Comment 18 Martin Whitaker 2015-03-22 15:40:31 CET
(In reply to Marja van Waes from comment #16)
> Or it only occurs when .rpmnew files have been created for more packages
> than jast setup?
> 
No, it happens even if setup is the only package being installed (I just tested this by downgrading the setup package and then reinstalling via rpmdrake).

CC: (none) => mageia

Comment 19 Florian Hubold 2015-03-22 16:41:02 CET
*** Bug 13989 has been marked as a duplicate of this bug. ***

CC: (none) => westel

Comment 20 Florian Hubold 2015-03-22 16:42:04 CET
*** Bug 15548 has been marked as a duplicate of this bug. ***

CC: (none) => ashvinlobo

Comment 21 Florian Hubold 2015-03-22 16:51:26 CET
Sorry for comment 19, commented on the wrong bug.
FWIW, this issue has previously been reported as bug 12006

CC: (none) => doktor5000

Comment 22 Barry Jackson 2015-03-22 17:15:47 CET
Slightly  /OT
Recently also the rpmnew questions dialog does not show the 3 split screens with file, new file and diff evenly spaced - only one is visible such that a new user would not know that the others were there for inspection (unless this has been fixed very recently).

I too was always very confused by this dialog.
At every php update I am asked this question.

If I select to delete .rpmnew, am I missing some new config setting that is  better, safer or really required by the new version? I have no way of knowing.

If I accept to use rpmnew I lose my date/location settings in php.ini which causes zoneminder to spew out masses of error logs.

If I "do nothing" then I am not told what action will in fact (not) be taken. I now understand that rpmnew will not be deleted and not be used but will remain in the directory alongside the original config which will continue to be used.

This GUI dialog does need to give a clearer explanation of itself.

CC: (none) => zen25000

Comment 23 Martin Whitaker 2015-03-22 18:07:32 CET
(In reply to Colin Guthrie from comment #14)
> FWIW, there is code in place to NOT do rpmnew questions for the setup
> package. This is just a bug, it surfaced a while back but it's certainly not
> meant to do it. Thierry has looked at it in the past but not sure of the
> current state of things.

I've had a look at the code, and the code Colin is remembering is only used when the --merge-all-rpmnew option is passed to drakrpm. This option searches for any .rpmnew files left lying around the system (from previous installs) and brings up the dialogue to select whether to use or delete them.

It wouldn't be hard to apply the same filter after installing packages, but that's not what the code is currently designed to do.
Comment 24 Sander Lepik 2015-03-22 18:23:42 CET
Martin, can you please propose a patch then, so we could move on with this bug :)
Comment 25 Martin Whitaker 2015-03-22 20:03:49 CET
Created attachment 6120 [details]
Patch to filter out critical config files after packages are installed

This should do the job. I've checked it works on my cauldron system with both drakrpm and drakrpm-update.
Comment 26 Rémi Verschelde 2015-03-22 22:51:33 CET
Thanks for the patch Martin!

There seems to be a couple of issues though:
- your patch has the exact same chunk repeated twice, so the second chunk must be removed to apply it
- with the edited patch applied, rpmdrake throws me this error when updating the setup package (which should trigger the .rpmnew logic):

  Fatal error: Undefined subroutine &Rpmdrake::pkg::ignore_rpmnew called at /usr/lib/perl5/vendor_perl/5.20.1/Rpmdrake/pkg.pm line 858
Comment 27 Rémi Verschelde 2015-03-22 23:05:34 CET
I fixed the fatal error by using:

  $pkg2rpmnew{$pkg->fullname} = [ grep { (-r "$_.rpmnew" || -r "$_.rpmsave") && !$ignores_rpmnew{$_} } $pkg->conf_files ];

But then it doesn't fix the bug, I still get the dialog that proposes to check the .rpmnew and eventually use it for /etc/fstab, /etc/resolv.conf and /etc/shadow when updating the setup package.
Comment 28 Martin Whitaker 2015-03-22 23:05:57 CET
Created attachment 6121 [details]
Patch to filter out critical config files after packages are installed

Must have mistyped when combining the two diffs! Here's what it should have been.

Attachment 6120 is obsolete: 0 => 1

Comment 29 Rémi Verschelde 2015-03-22 23:10:02 CET
Tested the new patch and this time it worked great :-)

I'll push it to git.
Comment 30 Mageia Robot 2015-03-22 23:18:28 CET
commit 80efbb77104557345ee9e45504f5c8827c241a4f
Author: Rémi Verschelde <remi@...>
Date:   Sun Mar 22 23:17:12 2015 +0100

    rpmdrake: filter out critical config files from the .rpm{new,save} handling logic after installing packages (Martin Whitaker, mga#14266)
---
 Commit Link:
   http://gitweb.mageia.org/software/rpmdrake/commit/?id=80efbb77104557345ee9e45504f5c8827c241a4f
Comment 31 Rémi Verschelde 2015-03-22 23:20:56 CET
I'll work on the Mageia 4 tomorrow.
Comment 32 Rémi Verschelde 2015-03-22 23:21:28 CET
The patch from comment 28 is included in rpmdrake-6.17-1.mga5
Comment 33 Rémi Verschelde 2015-03-23 08:20:18 CET
I did some additional testing this morning and Martin's patch doesn't seem to introduce regressions. I managed to install updates with non-blacklisted %config(noreplace) files and go the UI proposing to handle them. I also tested adding a non-blacklisted %config(noreplace) file to the setup package, downgrade my setup package locally and could make sure that I get the UI *only* for my test config file, not for /etc/shadow and Co., even though their .rpmnew were created properly.

Preparing the Mageia 4 update now.
Comment 34 Mageia Robot 2015-03-23 08:25:28 CET
commit 535660fde655bbde76eb84f4d451044b8a2a2dbf
Author: Rémi Verschelde <remi@...>
Date:   Mon Mar 23 08:24:25 2015 +0100

    rpmdrake: filter out critical config files from the .rpm{new,save} handling logic after installing packages (Martin Whitaker, mga#14266)
---
 Commit Link:
   http://gitweb.mageia.org/software/rpmdrake/commit/?id=535660fde655bbde76eb84f4d451044b8a2a2dbf
Comment 35 Rémi Verschelde 2015-03-23 08:28:26 CET
*** Bug 12006 has been marked as a duplicate of this bug. ***

CC: (none) => andybiker

Comment 36 Rémi Verschelde 2015-03-23 08:36:10 CET
Update candidate pushed to Mageia 4 core/updates_testing:
- rpmdrake-6.10.4-1.mga4.noarch

from SRPM:
- rpmdrake-6.10.4-1.mga4


Suggested advisory:
===================

Updated rpmdrake package filters out critical config files from its simplified handling logic

  Mageia's graphical frontend for software installation (drakrpm) and update
  (drakrpm-update) have a feature to let the user handle new config files on
  updates using a friendly graphical user interface.

  Before rpmdrake 6.10.4, this feature did not filter out critical configuration
  files such as /etc/fstab or /etc/shadow, and a misguided user could have reset
  those files during an upgrade of their setup package (mga#14266).

  This upgrade fixes it by filtering out such critical files from this feature.


References:
 - https://bugs.mageia.org/show_bug.cgi?id=14266
 - http://gitweb.mageia.org/software/rpmdrake/commit/?id=535660fde655bbde76eb84f4d451044b8a2a2dbf

Assignee: bugsquad => qa-bugs

Comment 37 Rémi Verschelde 2015-03-23 08:40:03 CET
Testing procedure:
==================

Basically we need to test that:

1) rpmdrake and MageiaUpdate still work fine for installation/uninstallation and udpates (they should, but that's usual QA procedure)

2) Packages with modified critical config files such as "setup" do _not_ bring up the UI asking what you want to do with the .rpmnew files. Basically you can test this update together with the setup update candidate that would trigger the issue.
You can downgrade setup to the core/release version if need be.

3) Packages with modified non-critical config files still trigger the feature, i.e. rpmdrake or MageiaUpdate will propose you to handle the .rpmnew or .rpmsave graphically.
Rémi Verschelde 2015-03-23 09:12:07 CET

Version: Cauldron => 4

Rémi Verschelde 2015-03-23 09:12:19 CET

Whiteboard: (none) => has_procedure

Comment 38 andré blais 2015-03-23 09:32:29 CET
By "filter out", does that mean that these critical .rpmnew files will NOT be left on the system ?  That would be safer.

Since they serve no purpose if left lying around, and some inexperienced user could still replace them, after seeing a few safe .rpmnew files replaced by the dialog.
Any experienced user that wants to see what those .rpmnew config files look like can just extract them from the package.

CC: (none) => andre999mga

Comment 39 Rémi Verschelde 2015-03-23 09:56:55 CET
(In reply to andré blais from comment #38)
> By "filter out", does that mean that these critical .rpmnew files will NOT
> be left on the system ?  That would be safer.
Nope
> 
> Since they serve no purpose if left lying around, and some inexperienced
> user could still replace them, after seeing a few safe .rpmnew files
> replaced by the dialog.
Any inexperienced user who does "mv -f /etc/fstab.rpmnew /etc/fstab" is just plain silly and we shouldn't bother handling such cases.
The _purpose_ of %config(noreplace) is to put .rpmnew files on the system but leave the original files untouched. And these .rpmnew files are only added when the actual config template changed in the main package, so in most cases there will be no .rpmnew files. And if the file did change, then experienced user probably want to check the diff and see if they need to backport some changes to their own config.

> Any experienced user that wants to see what those .rpmnew config files look
> like can just extract them from the package.
That's just plain silly IMO. What's the purpose of having %config(noreplace) if it means that you have to extract the files from the RPM to check them?
Comment 40 Mageia Robot 2015-03-23 10:08:56 CET
commit bbb23d5e8e55648b5c717d2a08be1f5ec848aaf1
Author: Rémi Verschelde <remi@...>
Date:   Mon Mar 23 10:08:41 2015 +0100

    rpmdragora: filter out critical config files from the .rpm{new,save} handling logic after installing packages (Martin Whitaker, mga#14266)
---
 Commit Link:
   http://gitweb.mageia.org/software/adminpanel/commit/?id=bbb23d5e8e55648b5c717d2a08be1f5ec848aaf1
Comment 41 Rémi Verschelde 2015-03-23 10:17:57 CET
Just for the reference, I introduce a bug in the commit linked in comment 40, but fixed it in a later commit.
Comment 42 andré blais 2015-03-23 11:54:03 CET
(In reply to Rémi Verschelde from comment #39)
> (In reply to andré blais from comment #38)
> > By "filter out", does that mean that these critical .rpmnew files will NOT
> > be left on the system ?  That would be safer.
> Nope

> > Since they serve no purpose if left lying around, and some inexperienced
> > user could still replace them, after seeing a few safe .rpmnew files
> > replaced by the dialog.
> Any inexperienced user who does "mv -f /etc/fstab.rpmnew /etc/fstab" is just
> plain silly and we shouldn't bother handling such cases.

They could do that much easier from their file manager with root privileges.  Inexperienced users tend to do things like that.  I've seen that many times.

> The _purpose_ of %config(noreplace) is to put .rpmnew files on the system
> but leave the original files untouched. And these .rpmnew files are only
> added when the actual config template changed in the main package, so in
> most cases there will be no .rpmnew files. And if the file did change, then
> experienced user probably want to check the diff and see if they need to
> backport some changes to their own config.
> 
> > Any experienced user that wants to see what those .rpmnew config files look
> > like can just extract them from the package.
> That's just plain silly IMO. What's the purpose of having %config(noreplace)
> if it means that you have to extract the files from the RPM to check them?

I think you missed my point.  I was referring only to those few .rpmnew config files that we are hiding from users during the update process, such as fstab and *shadow* and possibly some others.  Most are NOT hidden, and never have been.
As far as "silly" goes, one could say the same thing about experienced users who accept using the .rpmnew without checking.  It does happen.
Comment 43 Rémi Verschelde 2015-03-23 12:02:08 CET
(In reply to andré blais from comment #42)
> As far as "silly" goes, one could say the same thing about experienced users
> who accept using the .rpmnew without checking.  It does happen.

That's why we are now hiding this from rpmdrake/MageiaUpdate, so you only get notified about the .rpmnew file if you use urpmi. It does _not_ prompt you to take any action, it just says that some file got installed on your system.

Experienced or not, if afterwards users decide to play with their files in /etc that's their problem, that's beside the point of this bug report. We won't start implementing safeguards for every bad idea that one user could get, else we should alias "rm -f" with "touch".

And it has been expressed already that yes, it's non-optimal to have such files packaged as %config files, they should not be packaged at all. But that's for another bug report and for Mageia 6.
Comment 44 claire robinson 2015-03-23 12:28:23 CET
Tested in vbox and took a snapshot before starting.

It's still not ideal as it presents a window which says files have been created as rpmnew which has "Inspect" buttons for each file to show the diff and all still allow to overwrite the setup files.

I'll attach a screenshot.

It would be better/safer for these to install them silently.
Comment 45 claire robinson 2015-03-23 12:29:13 CET
Created attachment 6125 [details]
screenshot
Comment 46 claire robinson 2015-03-23 12:30:35 CET
Confirmed that rpmdrake is a priority update though
Comment 47 Rémi Verschelde 2015-03-23 12:43:22 CET
(In reply to claire robinson from comment #44)
> 
> It's still not ideal as it presents a window which says files have been
> created as rpmnew which has "Inspect" buttons for each file to show the diff
> and all still allow to overwrite the setup files.

That's precisely what the update is supposed to fix, I'll double check my package.
Comment 48 Angelo Naselli 2015-03-23 13:08:12 CET
Just out of curiosity but setting merge-all-rpmnew to 0 suould not be enough?
That should avoid to call merge-all-rpmnew in MageiaUpdate and so dialog_rpmnew.
The code seems clear to me there :
sub do_merge_if_needed() {
    if ($rpmdragora_options{'merge-all-rpmnew'}) {

and that is used in init.pm and rpmnew.pm so that seems to be the aim of this
flag.
Comment 49 Angelo Naselli 2015-03-23 13:12:17 CET
no i misunderstood the code, sorry
Comment 50 Rémi Verschelde 2015-03-23 14:03:38 CET
(In reply to Rémi Verschelde from comment #47)
> (In reply to claire robinson from comment #44)
> > 
> > It's still not ideal as it presents a window which says files have been
> > created as rpmnew which has "Inspect" buttons for each file to show the diff
> > and all still allow to overwrite the setup files.
> 
> That's precisely what the update is supposed to fix, I'll double check my
> package.

I did not reproduce the issue on Mageia 4 32bit, but I made sure to install first the rpmdrake update, restart MageiaUpdate and install setup.

I'll revert to preview versions and see what happens if I install them both in the same instance, maybe the code is in memory in some way and not reloaded.
Comment 51 Rémi Verschelde 2015-03-23 15:02:09 CET
I confirm that I can reproduce the issue in comment 44 when installing the rpmdrake and setup updates in the same MageiaUpdate instance.

So basically the rpmdrake update is working OK, but we need to push rpmdrake first and only validate the setup update once we are confident enough that most users did their regular updates... That's far from optimal but I don't really see a better fix.
Comment 52 Rémi Verschelde 2015-03-23 15:03:01 CET
Adding the feedback marker for now so that we don't validate this one before rpmdrake has been pushed.

Whiteboard: has_procedure => has_procedure feedback

Comment 53 Rémi Verschelde 2015-03-23 15:04:13 CET
Sorry I mistook this bug report for the setup update bug report since the RPM package field was wrong, removing the feedback marker and OK'ing Mageia 4 32bit as per comment 50 and 51.

Whiteboard: has_procedure feedback => has_procedure MGA4-32-OK
Source RPM: setup => rpmdrake

Comment 54 Sander Lepik 2015-03-23 15:07:29 CET
AFAIK it should be possible to make the setup package update conflict with older rpmdrake, so it won't be installed before newer rpmdrake is installed. That's the only way to make this update work as else you would have to wait for the EOL of mga4 as people can always make a fresh install and screw their setup with one wrong click :)
Comment 55 Rémi Verschelde 2015-03-23 15:10:51 CET
(In reply to Sander Lepik from comment #54)
> AFAIK it should be possible to make the setup package update conflict with
> older rpmdrake, so it won't be installed before newer rpmdrake is installed.

I wonder if that would work because in the test case of comment 44, the rpmdrake update _is_ installed before the setup update, but it's still the old rpmdrake which is running when installing setup. Would adding a conflict force the user to restart rpmdrake? I fear it wouldn't be sufficient :-/
Comment 56 David GEIGER 2015-03-23 15:21:43 CET
The only works and better solution is to restart mageiaupdate before updating setup package, otherwise new patched rpmdrake does not work as it should.

CC: (none) => geiger.david68210

Comment 57 Thomas Backlund 2015-03-23 15:29:29 CET
Hm,

urpmi has logic to re-start itself after update, I wonder if that could be done here too
Comment 58 Thierry Vignaud 2015-03-23 15:30:19 CET
rpmdrake already does that
Comment 59 Angelo Naselli 2015-03-23 15:34:26 CET
Confirm that as tv said, maybe setup was installed first though.
Comment 60 Rémi Verschelde 2015-03-23 15:45:02 CET
(In reply to Angelo Naselli from comment #59)
> Confirm that as tv said, maybe setup was installed first though.

Well as both MrsB and I stated, rpmdrake proposes one update: rpmdrake. It gets installed, then it searches for updates again and proposes setup. So I guess there is no doubt on the install order. But someone rpmdrake is not using the new logic when installing setup if you don't restart it manually.
Comment 61 David GEIGER 2015-03-23 15:49:11 CET
I confirm that Rémi and MrsB said.
Comment 62 Angelo Naselli 2015-03-23 16:11:40 CET
well to see if it really works, you can look at the log and see if there is any
"restarting rpmdrake" string.
Comment 63 Rémi Verschelde 2015-03-23 16:26:07 CET
Created attachment 6128 [details]
Log from upgrading rpmdrake and setup afterwards

See the attached stdout log, it looks like drakrpm-update does not restart.
Comment 64 Rémi Verschelde 2015-03-23 16:26:47 CET
Adding the feedback marker for now since we might try to fix rpmdrake's behaviour on self upgrades before pushing this one.

Whiteboard: has_procedure MGA4-32-OK => has_procedure feedback

Comment 65 Martin Whitaker 2015-03-23 20:37:52 CET
I think the restart got broken a while ago. This seems to fix it:

--- pkg.pm	2015-03-22 22:21:53.000000000 +0000
+++ pkg.pm.new	2015-03-23 19:28:04.763376617 +0000
@@ -877,7 +877,7 @@
                      );
 
     #- restart rpmdrake if needed, keep command line for that.
-    if ($need_restart && !$exit_code && $something_installed) {
+    if ($need_restart && !$exit_code) {
         log::explanations("restarting rpmdrake");
         #- it seems to work correctly with exec instead of system, provided we stop timers
         #- added --previous-priority-upgrade to allow checking if yet if


The problem is that $something_installed is unassigned at that point - maybe the code got reordered.

I've not tested this extensively - need to check it doesn't force a restart unnecessarily.
Comment 66 David Walser 2015-03-23 21:00:41 CET
(In reply to Colin Guthrie from comment #6)
> Perhaps for files like /etc/passwd we should ghost them and then populate
> them at first install in the %post or, better, via tmpfiles or, even better,
> sysusers.
> 
> This avoids marking the files as config (and thus getting rpmnew) and avoids
> any chance of rpm overwriting them on upgrade. It also ensures the system
> can self populate after an rm -rf /etc/* which is a good aim generally
> (it'll be a long time before we can really offer this as a feature, but baby
> steps towards it don't hurt).

If they were %ghost'ed the files would be removed on package removal (which is the purpose of %ghost).  I see no value in that, so no the files shouldn't be %ghost'ed.

Otherwise, I completely agree with Colin.  The files should not be packaged, they should be created by a scriplet (probably %pretrans to be safe).  That's the real solution here.  MageiaUpdate/rpmdrake shouldn't need an exception list.  All of those files should be changed to not be package-owned.  However, that's work for later, not now :o)
Comment 67 Rémi Verschelde 2015-03-23 21:08:23 CET
(In reply to Martin Whitaker from comment #65)
> I think the restart got broken a while ago. [...]
> 
> The problem is that $something_installed is unassigned at that point - maybe
> the code got reordered.
> 
> I've not tested this extensively - need to check it doesn't force a restart
> unnecessarily.

I haven't tried your patch yet, but I tried to do some (basic) debugging earlier and with the following patch, I found that both $need_restart and $something_installed were undefined:


--- /home/akien/Mageia/git/software/rpmdrake/Rpmdrake/pkg.pm    2015-03-23 19:25:18.772473091 +0100
+++ /usr/lib/perl5/vendor_perl/5.20.1/Rpmdrake/pkg.pm   2015-03-23 19:54:53.902472531 +0100
@@ -876,6 +876,7 @@
                          },
                      );
 
+    interactive_msg(N("Error"), N("need: %s -- exit: %s -- something: %s", $need_restart, $exit_code, $something_installed));
     #- restart rpmdrake if needed, keep command line for that.
     if ($need_restart && !$exit_code && $something_installed) {
         log::explanations("restarting rpmdrake");


Basically the dialog gives me this output:
  "need:  -- exit: 0 -- something: "
Comment 68 Mageia Robot 2015-03-23 21:10:19 CET
commit 9ad335dd726ba4f73177c4407c37904fc073c316
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Mon Mar 23 21:07:48 2015 +0100

    Revert "(perform_installation) do not restart if we didn't install any package"
    
    This reverts commit 478c89356f66dd86488242e877b7b6a88e7218a8.
    
    which was totally bogus, thus fixing restarting on priority updates
    (mga#14266)
---
 Commit Link:
   http://gitweb.mageia.org/software/rpmdrake/commit/?id=9ad335dd726ba4f73177c4407c37904fc073c316
Comment 69 Thierry Vignaud 2015-03-23 21:12:23 CET
(In reply to Martin Whitaker from comment #65)

Thanks Martin for pointing the issue.
Indeed this earlier commit was bogus.


(In reply to Rémi Verschelde from comment #67)
It is normal that $need_restart is undefined if there was no priority updates
Comment 70 Rémi Verschelde 2015-03-23 21:20:12 CET
(In reply to Thierry Vignaud from comment #69)
> It is normal that $need_restart is undefined if there was no priority updates

I was testing with a bumped release of perl-URPM on my custom repo, but I'm not 100% sure it qualifies it as a priority update indeed. Martin said the patch fixed the issue for him, so I guess it's pretty safe and my debugging procedure was incomplete :)
Comment 71 andré blais 2015-03-24 06:32:09 CET
(In reply to David Walser from comment #66)
> (In reply to Colin Guthrie from comment #6)
> > Perhaps for files like /etc/passwd we should ghost them and then populate
> > them at first install in the %post or, better, via tmpfiles or, even better,
> > sysusers.
> > 
> > This avoids marking the files as config (and thus getting rpmnew) and avoids
> > any chance of rpm overwriting them on upgrade. It also ensures the system
> > can self populate after an rm -rf /etc/* which is a good aim generally
> > (it'll be a long time before we can really offer this as a feature, but baby
> > steps towards it don't hurt).
> 
> If they were %ghost'ed the files would be removed on package removal (which
> is the purpose of %ghost).  I see no value in that, so no the files
> shouldn't be %ghost'ed.
> 
> Otherwise, I completely agree with Colin.  The files should not be packaged,
> they should be created by a scriplet (probably %pretrans to be safe). 
> That's the real solution here.  MageiaUpdate/rpmdrake shouldn't need an
> exception list.  All of those files should be changed to not be
> package-owned.  However, that's work for later, not now :o)

If using a scriplet is the solution, why couldn't we do it now ?
We need to find a way to make existing files "unowned" by a package (no idea how easy that is),
and the "scriptlet" files unowned (I assume that isn't a problem).

If we can do that, it might be a little more work now, but we would definitively solve the problem.
Could we try that ?

Now we seem to be going in circles with unexpected side effects.
Comment 72 Rémi Verschelde 2015-03-24 08:10:25 CET
Well so far the unexpected side effects are regressions found in rpmdrake, so it's quite good to expose them and fix them.

But if you want to get started on the scriplet work, feel free. It's just that we are so busy right now with all the other release blockers that I don't think it would be nice to introduce potential regressions with such a change so close the RC.
Comment 73 Rémi Verschelde 2015-03-24 08:18:16 CET
(In reply to Mageia Robot from comment #68)
> commit 9ad335dd726ba4f73177c4407c37904fc073c316
> Author: Thierry Vignaud <thierry.vignaud@...>
> Date:   Mon Mar 23 21:07:48 2015 +0100
> 
>     Revert "(perform_installation) do not restart if we didn't install any
> package"
>     
>     This reverts commit 478c89356f66dd86488242e877b7b6a88e7218a8.
>     
>     which was totally bogus, thus fixing restarting on priority updates
>     (mga#14266)

I've built rpmdrake with this fix locally, put it on my custom repo and did the upgrade. This time with my small addition from comment 67 I got:
  "need: 1 -- exit:  -- something: "

So it looks alright, unless exit_code should have been 0? Anyway I did not see a "restarting rpmdrake" log entry, but is it logged to stdout/stderr?
Comment 74 Rémi Verschelde 2015-03-24 08:24:01 CET
Ok, I did a second upgrade of rpmdrake with the fixed rpmdrake already installed, and then I got this in the log:
"urpmi a été relancé et la liste des paquetages prioritaires est inchangée"
("urpmi was restarted and the priority package list is unchanged")

so I guess the fix is working, just not used yet when upgrading rpmdrake at first.
So for this one time, we're back to the problem of rpmdrake not forcefully restarting that would trigger the .rpmnew issue with the setup upgrade.

Should we add a %post or something to the rpmdrake upgrade that would force rpmdrake to restart? Or just a README.urpmi explaining that the user should restart rpmdrake before continuing their updates?
Comment 75 Mageia Robot 2015-03-24 08:52:07 CET
commit b9f6bb9014c9367cc5aec45f60f2976dc18b9e9d
Author: Angelo Naselli <anaselli@...>
Date:   Tue Mar 24 08:51:41 2015 +0100

    from rpmdrake: fix restarting on priority updates (mga#14266)
---
 Commit Link:
   http://gitweb.mageia.org/software/adminpanel/commit/?id=b9f6bb9014c9367cc5aec45f60f2976dc18b9e9d
Comment 76 Sander Lepik 2015-03-24 12:24:40 CET
(In reply to Rémi Verschelde from comment #74)
> Ok, I did a second upgrade of rpmdrake with the fixed rpmdrake already
> installed, and then I got this in the log:
> "urpmi a été relancé et la liste des paquetages prioritaires est inchangée"
> ("urpmi was restarted and the priority package list is unchanged")
> 
> so I guess the fix is working, just not used yet when upgrading rpmdrake at
> first.
> So for this one time, we're back to the problem of rpmdrake not forcefully
> restarting that would trigger the .rpmnew issue with the setup upgrade.
> 
> Should we add a %post or something to the rpmdrake upgrade that would force
> rpmdrake to restart? Or just a README.urpmi explaining that the user should
> restart rpmdrake before continuing their updates?

There must be a better way to do this. Thierry, any ideas?
Comment 77 Thierry Vignaud 2015-03-24 12:48:34 CET
The log says "urpmi was restarted" for all users of urpm module (urpmi, rpmdrake, ...)
See http://gitweb.mageia.org/software/rpm/urpmi/tree/urpm/select.pm#n34

Of course, it won't fix the issue with the old rpmdrake.
A fix could be to add a note in README.<version>.upgrade.urpmi

Eg:
We currently have rpmdrake-6.10.4-1.mga4.
If we run "git cherry-pick 9ad335dd726ba4f73177c4"
then bump version to 6.10.5, then update the package:
Then we can add in the spec file a README.6.10.4.upgrade.urpmi file that would say:
>> WARNING: this rpmdrake update fixes a major issue.
>> Please restart rpmdrake prior to install any other updates (especially the "setup" one).

See http://gitweb.mageia.org/software/rpm/urpmi/tree/urpm/install.pm#n146
Comment 78 Rémi Verschelde 2015-03-24 12:58:18 CET
This sounds like a good compromise IMO, I'm not sure we can handle it in a better way as long as the old rpmdrake is in place.

About the README.<version>.upgrade.urpmi, is there a way to make it non-version specific? We need to handle updates from any rpmdrake 6.10.{0,1,2,3} (6.10.4 won't be validated, we'll push 6.10.5 instead).

Would README.upgrade.urpmi work?
Comment 79 Thierry Vignaud 2015-03-24 13:08:43 CET
If you'd read the link I provided :-) you would have seen that README.6.10.4.upgrade.urpmi means that it'll be popup for whatever rpmdrake whose version is < 6.10.4.
So if you want to include 6.10.4 too, it shouls be README.6.10.5.upgrade.urpmi.

We don't want README.upgrade.urpmi as we don't want to popup for further updates (eg for 6.10.8 -> 6.11.3)
Comment 80 Rémi Verschelde 2015-03-24 14:18:31 CET
/me whistles innocently :-)

Ok, I'll cherry-pick the commit and release 6.10.5 with this README.6.10.5.upgrade.urpmi.
Comment 81 Mageia Robot 2015-03-24 14:23:04 CET
commit 36dadddada0cc2ee3c989de37ea1c3b2af0a2566
Author: Thierry Vignaud <thierry.vignaud@...>
Date:   Mon Mar 23 21:07:48 2015 +0100

    Revert "(perform_installation) do not restart if we didn't install any package"
    
    This reverts commit 478c89356f66dd86488242e877b7b6a88e7218a8.
    
    which was totally bogus, thus fixing restarting on priority updates
    (mga#14266)
---
 Commit Link:
   http://gitweb.mageia.org/software/rpmdrake/commit/?id=36dadddada0cc2ee3c989de37ea1c3b2af0a2566
Comment 82 Rémi Verschelde 2015-03-24 14:39:32 CET
Update candidate pushed to Mageia 4 core/updates_testing:
- rpmdrake-6.10.5-1.mga4.noarch

from SRPM:
- rpmdrake-6.10.5-1.mga4


Suggested advisory:
===================

Updated rpmdrake package fixes two important usability bugs

  Mageia's graphical frontends for software installation (drakrpm) and update
  (drakrpm-update) have a feature to let the user handle new config files on
  updates using a friendly graphical user interface.

  Before rpmdrake 6.10.4, this feature did not filter out critical configuration
  files such as /etc/fstab or /etc/shadow, and a misguided user could have reset
  those files during an upgrade of their setup package (mga#14266).

  rpmdrake before 6.10.5 was also omitting to restart itself after priority
  updates (such as updates of rpmdrake or urpmi). This update fixes it, however
  the fix will only be effective after a restart of rpmdrake, hence an update
  warning will be displayed to ask users to do so.


References:
 - https://bugs.mageia.org/show_bug.cgi?id=14266
 - http://gitweb.mageia.org/software/rpmdrake/commit/?h=distro/mga4&id=535660fde655bbde76eb84f4d451044b8a2a2dbf
 - http://gitweb.mageia.org/software/rpmdrake/commit/?h=distro/mga4&id=36dadddada0cc2ee3c989de37ea1c3b2af0a2566

Whiteboard: has_procedure feedback => has_procedure

Comment 83 Rémi Verschelde 2015-03-24 14:43:50 CET
Testing procedure:
==================

See comment 37 for instructions on how to test the first issue.

Testing that rpmdrake will restart after priority updates will be a bit tricker, since the only priority update currently is rpmdrake; you should confirm that the README.6.10.5.upgrade.urpmi file is displayed with a warning notifying the user of the need to restart rpmdrake manually.

Starting from there, the fix will be applied and rpmdrake should restart properly (check the console output after you've run drakrpm-update from there) on priority upgrades (important packages such as rpmdrake, RPM, meta-task, etc.). To test it, you'll probably need to build a custom "priority update" and put it on a custom mirror used as an update source.
Comment 84 David Walser 2015-03-24 17:59:15 CET
(In reply to andré blais from comment #71)
> If using a scriplet is the solution, why couldn't we do it now ?
> We need to find a way to make existing files "unowned" by a package (no idea
> how easy that is),
> and the "scriptlet" files unowned (I assume that isn't a problem).
> 
> If we can do that, it might be a little more work now, but we would
> definitively solve the problem.
> Could we try that ?
> 
> Now we seem to be going in circles with unexpected side effects.

It wouldn't be appropriate to do a major change like that as an update for stable.  It'll take some time to bake in Cauldron to get that kind of transition working properly (without any unintended side effects).

For instance, one problem we'll have to handle, is as soon as these files become unowned by packages, they'll get moved to an .rpmsave file, thus breaking systems.
Comment 85 andré blais 2015-03-25 09:42:06 CET
(In reply to David Walser from comment #84)
> (In reply to andré blais from comment #71)
> > If using a scriplet is the solution, why couldn't we do it now ?
> > We need to find a way to make existing files "unowned" by a package (no idea
> > how easy that is),
> > and the "scriptlet" files unowned (I assume that isn't a problem).
> > 
> > If we can do that, it might be a little more work now, but we would
> > definitively solve the problem.
> > Could we try that ?
> > 
> > Now we seem to be going in circles with unexpected side effects.
> 
> It wouldn't be appropriate to do a major change like that as an update for
> stable.  It'll take some time to bake in Cauldron to get that kind of
> transition working properly (without any unintended side effects).
> 
> For instance, one problem we'll have to handle, is as soon as these files
> become unowned by packages, they'll get moved to an .rpmsave file, thus
> breaking systems.

You give me ideas.  I'm going to work on this.
Comment 86 Chris Denice 2015-03-25 10:52:20 CET
Are you all crazy? :)

Guys, that bug only started because a bug on systemd decided to touch these files independently of the rpm installer. There is no issue in the packaging of these files, they are created with the correct permissions, and nothing was wrong in the setup package. 

Please, do not recreating another layer of programs touching the setup package files because some people don't understand config((no)replace). If you want to take this route, just remove completely setup and find another way of deal with the configuration. But mixing both approach is not an option!

cheers.
Comment 87 James Kerr 2015-03-25 15:17:14 CET
I created a custom repo containing only the rpmdrake and setup updates and tagged it as an update source. I started the update by clicking on the red icon when it appeared.

After rpmdrake was installed I saw a message that there was upgrade information available. In order to see the warning about restarting rpmdrake, I had to select to read the upgrade information. If I just clicked OK on that dialogue I did not see the warning and the setup package was offered.

Given that this change is for the benefit of people who do not read the upgrade information about setup, will those users actually see the warning?

The warning itself could be more emphatic. They will just have been told that rpmdrake is going to restart anyway. I'm not sure that they will understand that they must actually click on the Quit button before allowing any more packages to be installed.

Perhaps something like "This rpmdrake update fixes a major issue, which could result in your being unable to login to your system. You must close the package updater by clicking on the Quit button and then restart the updater before installing any further updates (especially the setup update)."
Comment 88 Rémi Verschelde 2015-03-25 15:31:24 CET
(In reply to James Kerr from comment #87)
> 
> Given that this change is for the benefit of people who do not read the
> upgrade information about setup, will those users actually see the warning?

That's not really true actually, users who do not read upgrade information about setup would have no problem. The users having problems are the ones that read the upgrade information, then chose to check the diff between the previous config files and the .rpmnew, and then chose to use the .rpmnew against the recommendation of rpmdrake (which says something like "If you're unsure, choose 'delete the .rpmnew'").

So the users who would potentially do this mistake would most likely first read the upgrade information about rpmdrake, since they like reading upgrade information and acting upon it :)

> The warning itself could be more emphatic. They will just have been told
> that rpmdrake is going to restart anyway. I'm not sure that they will
> understand that they must actually click on the Quit button before allowing
> any more packages to be installed.

The current warning is:
  IMPORTANT: This rpmdrake update fixes a major issue.
  Please restart rpmdrake prior to installing any other update
  (especially the setup security update).

  See https://bugs.mageia.org/show_bug.cgi?id=14266 for more details.

I does not say that rpmdrake is going to restart, it says "please restart rpmdrake".

But I guess I could add something like:
  If you chose to go on without restarting rpmdrake, make sure NOT TO use the
  .rpmnew files proposed after the "setup" update. You should keep your original
  files, they contain information required to boot your system.

And also make the "please restart rpmdrake" message more specific by telling the users to close it with the "Quit" button indeed.
Comment 89 Rémi Verschelde 2015-03-25 15:37:36 CET
I uploaded a new package with this message:

  IMPORTANT: This rpmdrake update fixes a major issue.

  Please restart the package updater prior to installing any other update
  (especially the setup security update), by closing it using the "Quit" button.

  If you nevertheless choose to go on without restarting rpmdrake, make sure
  NOT TO use the .rpmnew files proposed after the "setup" update. You should keep
  your original files, they contain information required to start your system.

  See https://bugs.mageia.org/show_bug.cgi?id=14266 for more details.


RPM: rpmdrake-6.10.5-2.mga4.noarch
SRPM: rpmdrake-6.10.5-2.mga4

Same advisory as in comment 82.
Comment 90 David Walser 2015-03-26 19:20:37 CET
(In reply to Chris Denice from comment #86)
> Are you all crazy? :)

That's fair to ask.

> Guys, that bug only started because a bug on systemd decided to touch these
> files independently of the rpm installer. There is no issue in the packaging
> of these files, they are created with the correct permissions, and nothing
> was wrong in the setup package. 

No, this has nothing to do with systemd.  You've mistaken this with a different issue, likely the one in Cauldron only where systemd was setting the permissions to 0000.

This bug really was caused by the setup package.  tmb previously identified this commit as the source of the bug:
http://svnweb.mageia.org/packages/cauldron/setup/current/SPECS/setup.spec?r1=407081&r2=407080&pathrev=407081

> Please, do not recreating another layer of programs touching the setup
> package files because some people don't understand config((no)replace). If
> you want to take this route, just remove completely setup and find another
> way of deal with the configuration. But mixing both approach is not an
> option!

I don't know what you're talking about.  What I do know is that /etc/shadow should not be packaged owned, and thus should not be config(noreplace).  Unfortunately, it was added to the setup package in this commit, further complicating things:
http://svnweb.mageia.org/packages/cauldron/setup/current/SPECS/setup.spec?r1=410770&r2=410769&pathrev=410770
Comment 91 Herman Viaene 2015-03-27 11:32:07 CET
MGA4-64 on HP Probook 6555b KDE and MGA4-32 on AcerD620 Xfce.
This is getting awkward. I was testing bug 15569 and got the updated rpmdrake package "for free" in the process. I was not aware of THIS issue, so I did not pay attention to what it did.
The only thing that struck me was that a second MCC-Software screen was opened, which I only noticed after I have been trying to read all info on this bug.
So I restarted both my laptops. I did not notice anything abnormal on the HP (quadcore), both the old Acer (single core) started very slowly, and at the end, the Xfce buttons for halting or restarting were greyed out. Starting Firefox was so slow, that after 30 min. after the new startup I pushed the power button.
The second start of the Acer was now back to its usual "speed".
At the end, all seems to be well on both PC's.

CC: (none) => herman.viaene

Comment 92 Rémi Verschelde 2015-03-27 11:42:44 CET
> (In reply to Herman Viaene from comment #91)
> So I restarted both my laptops. I did not notice anything abnormal on the HP
> (quadcore), both the old Acer (single core) started very slowly, and at the
> end, the Xfce buttons for halting or restarting were greyed out. Starting
> Firefox was so slow, that after 30 min. after the new startup I pushed the
> power button.
> The second start of the Acer was now back to its usual "speed".
> At the end, all seems to be well on both PC's.

It's not required to restart the computer for this update, *only* to close rpmdrake before doing further updates.

As for the boot issue, I don't see how the rpmdrake update could have caused this, the only changes are that it does not tell you about .rpmnew if you update the setup package, and it restarts itself after a priority update from now on.
Comment 93 Dave Hodgins 2015-03-27 19:39:31 CET
Testing complete on Mageia 4 i586 and x86_64. Advisory committed to svn.

Someone from the sysadmin team please push 14266.adv to updates.

Whiteboard: has_procedure => has_procedure advisory MGA4-64-OK MGA4-32-OK
Keywords: (none) => validated_update
CC: (none) => davidwhodgins, sysadmin-bugs

Comment 94 Mageia Robot 2015-03-27 22:12:50 CET
An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0028.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED

Comment 95 Jim Darpan 2022-10-04 11:47:01 CEST Comment hidden (spam)

CC: (none) => gatenbourque0834

Comment 96 alisha kihn 2022-12-21 04:24:03 CET Comment hidden (spam)

CC: (none) => alishakihn1

Comment 97 Trilaen Trilaen 2023-01-28 05:14:04 CET Comment hidden (spam)

CC: (none) => mr.trilaen

Alexander Barlow 2023-07-08 12:56:55 CEST

CC: (none) => picipib743

sturmvogel 2023-07-08 13:51:33 CEST

CC: alishakihn1, gatenbourque0834, mr.trilaen, picipib743 => (none)

Comment 99 remy kyro 2023-10-28 17:58:16 CEST Comment hidden (spam)

CC: (none) => remykyro677


Note You need to log in before you can comment on or make changes to this bug.