i think that previous versions did this as well, but for sure the newest ypserv in 5.3 replaces /var/yp/Makefile with a new copy. needless to say if you've made any changes to that file, you will not be happy. we had a couple hours of phone calls after passwords stopped working. the original file is save as Makefile.rpmsave, so recovery of the file is straightforward.
the issue has been flagged upstream and it sounds like it should be fixed before any new updates to ypserv are made. /etc/ypserv.conf is another file that can get overwritten.
On Fri, 2009-04-03 at 14:04 -0700, Joe Pruett wrote:
i think that previous versions did this as well, but for sure the newest ypserv in 5.3 replaces /var/yp/Makefile with a new copy. needless to say if you've made any changes to that file, you will not be happy. we had a couple hours of phone calls after passwords stopped working. the original file is save as Makefile.rpmsave, so recovery of the file is straightforward.
the issue has been flagged upstream and it sounds like it should be fixed before any new updates to ypserv are made. /etc/ypserv.conf is another file that can get overwritten.
Although it would sure be nice if *all* updates to config files could be counted on to not replace customized/local ones, this has not been reliable at all. After each upgrade, I normally post about this as a reminder. This time I thought "Everybody knows by now". Sheesh. So here it is again.
Folks, be sure to do an updatedb and then locate rpmsave and rpmnew after upgrading the system. Then you can make sure your local changes get propagated into the updated system.
<snip sig stuff>
Belatedly,
Folks, be sure to do an updatedb and then locate rpmsave and rpmnew after upgrading the system. Then you can make sure your local changes get propagated into the updated system.
If the case is a file gets overwritten, and not a case of a file gets copied to a new one called *.rpm{save|new} during an upgrade, what exactly does the above do?
On Fri, 2009-04-03 at 15:40 -0600, Joseph L. Casale wrote:
Folks, be sure to do an updatedb and then locate rpmsave and rpmnew after upgrading the system. Then you can make sure your local changes get propagated into the updated system.
If the case is a file gets overwritten, and not a case of a file gets copied to a new one called *.rpm{save|new} during an upgrade, what exactly does the above do?
ABSOLUTELY NOTHING!
I presume that was a rhetorical question. Fortunately for me, I have not hit that situation.. But I have a very small simple desktop setup. Folks that provide services have it much tougher.
I would presume that those follow "best practices", like having test platforms, backups of locally changed files, well defined, documented and executed transition plans and testing, ...
Am I in the right universe? I remember those days and nothing that we planned on ever got done when management decided things were too hot to do all that. It was easy 'cause he was at home sleeping while we picked up the pieces.
They used to ask why I was "so hard to manage". <harumph>
<snip sig stuff>
Not letting bad memories ruin a *beautiful* Friday,
on 4-3-2009 2:40 PM Joseph L. Casale spake the following:
Folks, be sure to do an updatedb and then locate rpmsave and rpmnew after upgrading the system. Then you can make sure your local changes get propagated into the updated system.
If the case is a file gets overwritten, and not a case of a file gets copied to a new one called *.rpm{save|new} during an upgrade, what exactly does the above do?
That is what them backup thingies are for!
On Fri, 03 Apr 2009 16:15:40 -0700, Scott Silva wrote:
on 4-3-2009 2:40 PM Joseph L. Casale spake the following:
Folks, be sure to do an updatedb and then locate rpmsave and rpmnew after upgrading the system. Then you can make sure your local changes get propagated into the updated system.
If the case is a file gets overwritten, and not a case of a file gets copied to a new one called *.rpm{save|new} during an upgrade, what exactly does the above do?
That is what them backup thingies are for!
i agree with your backup argument.
actually, backup thingies can prove worthful in other scenarios too. but restores are only necessary when something or somehow messed something up. in the perfect world backups are taken but a restore is never necessary.
anyhow, i am not sure what could be done better. if a rpm builder forgets to define a file correct than it will be overwritten, of course. i am sitting in front of a OS-X right now. if apple does an update, files are overwritten *poof* . but rpm provides the infrastructre to do it right. thats a good thing, but its not foolproof of course.
so, backup. please.
best regards, markus
-
Joe Pruett -
Joseph L. Casale -
Markus Falb -
Scott Silva -
William L. Maltby