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

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.

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

(In reply to Thomas Backlund from comment #3)
> How did you update ?
> rpmdrake or urpmi ?

MageiaUpdate

ok, thats weird then :/

mageiaupdate is part of rpmdrake and calls do_merge_if_needed() wich checks the above mentioned ignores_rpmnew list ...

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

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

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

i guess so marja

CC: (none) => anaselli

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.

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.

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

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.

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.

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?

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

s/jast/just/

(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

*** Bug 13989 has been marked as a duplicate of this bug. ***

CC: (none) => westel

*** Bug 15548 has been marked as a duplicate of this bug. ***

CC: (none) => ashvinlobo

Sorry for comment 19, commented on the wrong bug.
FWIW, this issue has previously been reported as bug 12006

CC: (none) => doktor5000

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

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

Martin, can you please propose a patch then, so we could move on with this bug :)

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.

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

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.

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

Tested the new patch and this time it worked great :-)

I'll push it to git.

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

I'll work on the Mageia 4 tomorrow.

The patch from comment 28 is included in rpmdrake-6.17-1.mga5

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.

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

*** Bug 12006 has been marked as a duplicate of this bug. ***

CC: (none) => andybiker

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

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.

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

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

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

Just for the reference, I introduce a bug in the commit linked in comment 40, but fixed it in a later commit.

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

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

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.

Created attachment 6125 [details]
screenshot

Confirmed that rpmdrake is a priority update though

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

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.

no i misunderstood the code, sorry

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

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.

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

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

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

(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 :-/

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

Hm,

urpmi has logic to re-start itself after update, I wonder if that could be done here too

rpmdrake already does that

Confirm that as tv said, maybe setup was installed first though.

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

I confirm that Rémi and MrsB said.

well to see if it really works, you can look at the log and see if there is any
"restarting rpmdrake" string.

Created attachment 6128 [details]
Log from upgrading rpmdrake and setup afterwards

See the attached stdout log, it looks like drakrpm-update does not restart.

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

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.

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

(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: "

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

(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

(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 :)

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

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.

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

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?

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

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

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

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?

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)

/me whistles innocently :-)

Ok, I'll cherry-pick the commit and release 6.10.5 with this README.6.10.5.upgrade.urpmi.

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

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

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.

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

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

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.

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

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

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.

(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

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

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

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

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