Folks,
I just did an update on a fresh installed system and noticed that a small number of packages are still in need of appropriate config file changes to their spec files. Especially setup and fedora-release should not be creating .rpmnew files on upgrade.
Jon.
On Tuesday 10 March 2009 20:35:36 Jon Masters wrote:
Folks,
I just did an update on a fresh installed system and noticed that a small number of packages are still in need of appropriate config file changes to their spec files. Especially setup and fedora-release should not be creating .rpmnew files on upgrade.
OK, but you need to turn the current distribution of /etc/passwd into a series of "useradd" commands in %post, not just "nowarn" it. Otherwise any additions to the default set of users will get lost (although now I think about it, I don't think you've added any in a long time :o)).
Now, removing no-longer-necessary users without causing problems, is harder ...
Bill Crawford wrote:
On Tuesday 10 March 2009 20:35:36 Jon Masters wrote
I just did an update on a fresh installed system and noticed that a small number of packages are still in need of appropriate config file changes to their spec files. Especially setup and fedora-release should not be creating .rpmnew files on upgrade.
OK, but you need to turn the current distribution of /etc/passwd into a series of "useradd" commands in %post, not just "nowarn" it. Otherwise any additions to the default set of users will get lost (although now I think about it, I don't think you've added any in a long time :o)).
Package setup can't use post scriptlet (ok, maybe can use lua ... but it's not likely to have it there) - due to dependencies. I did quick&dirty way in rawhide - removing the most useless .rpmnew files in postun section - but user will still receive warnings about creating those files. AFAIK there is no other way at the moment (I requested RFE http://www.rpm.org/ticket/6 to have nowarn config file option) - please let me know if you know some way how to not bother users with useless .rpmnew file, but do not replace their files on update (as it would have horrible consequences in the case of file like /etc/passwd and/or /etc/shadow. Just for completeness - now it works the way that user/group added to default set of user/groups is created in post section of the ALL packages which actually need it for 2 Fedora releases. Worth of improvement, but don't know how to handle it better way for updates.
Greetings, Ondřej Vašík
On Wednesday 11 March 2009 11:27:35 Ondřej Vašík wrote: ...
Package setup can't use post scriptlet (ok, maybe can use lua ... but it's not likely to have it there) - due to dependencies. I did quick&dirty way in rawhide - removing the most useless .rpmnew files in postun section - but user will still receive warnings about creating those files. AFAIK there is no other way at the moment (I requested RFE http://www.rpm.org/ticket/6 to have nowarn config file option) - please let me know if you know some way how to not bother users with useless .rpmnew file, but do not replace their files on update (as it would have horrible consequences in the case of file like /etc/passwd and/or /etc/shadow. Just for completeness - now it works the way that user/group added to default set of user/groups is created in post section of the ALL packages which actually need it for 2 Fedora releases. Worth of improvement, but don't know how to handle it better way for updates.
I hadn't thought about the dependencies, and you're absolutely right there. It's always been an issue for update, anyway, so that package just needs to not change at all, ever ;o)
Main problem, of course, is that putting all the users in separate files, or any kind of database, would make this much much more complicated; something that basic really does need to stay in as simple a form as possible. IMHO.
Ondřej Vašík wrote:
do not replace their files on update (as it would have horrible consequences in the case of file like /etc/passwd and/or /etc/shadow.
Ah... given that users should be running as a normal (!root) account created at install time, isn't it *guaranteed impossible* to update /etc/passwd by replacing the old unmodified file with the new?
Here's a pie-in-the-sky idea... store configs as deltas (since at least ~2-4 releases back), write the .rpmnew as always, and notify the user to run a merge tool after the transaction completes. No more diffing and merging by hand, except in the face of merge conflicts...
Matthew Woehlke wrote:
Ondřej Vašík wrote:
do not replace their files on update (as it would have horrible consequences in the case of file like /etc/passwd and/or /etc/shadow.
Ah... given that users should be running as a normal (!root) account created at install time, isn't it *guaranteed impossible* to update /etc/passwd by replacing the old unmodified file with the new?
Yep, you could not replace /etc/passwd (and /etc/group, /etc/shadow, /etc/gshadow) file as it always differs from the file installed by setup (new users/groups, passwords ... ). But you need those files for installation - so they have to be in filelist and they have to be in rpm. AFAIK there is no option to ignore files completely in update, so .rpmnew are created although is always completely useless (unless you have some script to add missing users/groups from that .rpmnew file).
Here's a pie-in-the-sky idea... store configs as deltas (since at least ~2-4 releases back), write the .rpmnew as always, and notify the user to run a merge tool after the transaction completes. No more diffing and merging by hand, except in the face of merge conflicts...
I guess we can't expect user to run some merge tool after transaction. It has to be automated somehow. Maybe some separate file with default users/groups (like existing uidgid file) and something (?cron job) to periodically check it, if those users/groups do exist on system?
Greetings, Ondřej Vašík
Ondřej Vašík (ovasik@redhat.com) said:
Yep, you could not replace /etc/passwd (and /etc/group, /etc/shadow, /etc/gshadow) file as it always differs from the file installed by setup (new users/groups, passwords ... ). But you need those files for installation - so they have to be in filelist and they have to be in rpm. AFAIK there is no option to ignore files completely in update, so .rpmnew are created although is always completely useless (unless you have some script to add missing users/groups from that .rpmnew file).
Right, this is why (historically) we just don't change the stock files, so you won't get .rpmnew files in any case ; all changes to the stock entries would be done by %post scripts in the packages where they're needed.
Of course, with the rpm-4.6 hash change, you now get .rpmnew files on the first upgrade that uses it, regardless of whether or not the file changed.
Bill
Ondřej Vašík wrote:
AFAIK there is no option to ignore files completely in update, so .rpmnew are created although is always completely useless (unless you have some script to add missing users/groups from that .rpmnew file).
I am confused, shouldn't the .rpmnew only get created if the version in the rpm has changed from what was in the last "successfully installed" rpm? IOW I should be able to install 1000 updates to the rpm with /etc/passwd, but as long as the /etc/passwd in the rpm is the same I should never see a .rpmnew.
(Okay, the changed hashes throw a wrench in this, but that's another discussion that has already happened.)
I guess we can't expect user to run some merge tool after transaction.
Why not? We already expect them to do something with the .rpmnew. Why not make "something" easier to do?
It has to be automated somehow.
Automated, unreviewed updates of config files are dangerous :-). It's technically possible (you could run the merge tool automatically) but I don't think it's a good idea.
Maybe some separate file with default users/groups (like existing uidgid file) and something (?cron job) to periodically check it, if those users/groups do exist on system?
/etc/passwd is actually a case where automatic merge is probably fine for additions (removal is more dangerous, of course), but I'm thinking to apply this to config files in general.
On Tue, 2009-03-10 at 16:35 -0400, Jon Masters wrote:
fedora-release should not be creating .rpmnew files on upgrade.
This is a touchy one. We don't necessarily want to overwrite modified site local config in repo files. That would be just rude.
On Wed, 2009-03-11 at 09:29 -0700, Jesse Keating wrote:
On Tue, 2009-03-10 at 16:35 -0400, Jon Masters wrote:
fedora-release should not be creating .rpmnew files on upgrade.
This is a touchy one. We don't necessarily want to overwrite modified site local config in repo files. That would be just rude.
My point (as others made) is that making these files is completely useless. I'm not saying "overwrite the user's files" I'm saying ideally don't make the useless additional files on upgrade.
Jon.
Jon Masters (jcm@redhat.com) said:
My point (as others made) is that making these files is completely useless. I'm not saying "overwrite the user's files" I'm saying ideally don't make the useless additional files on upgrade.
rpm already has code to avoid making them when they're useless. It's just being defeated by the sha256 code for the first upgrade to rawhide/F11.
Bill
On Wed, 2009-03-11 at 17:53 -0400, Bill Nottingham wrote:
Jon Masters (jcm@redhat.com) said:
My point (as others made) is that making these files is completely useless. I'm not saying "overwrite the user's files" I'm saying ideally don't make the useless additional files on upgrade.
rpm already has code to avoid making them when they're useless. It's just being defeated by the sha256 code for the first upgrade to rawhide/F11.
Yeah, this I know. But when would they be useful for the average user, if they'll never know they're "missing" a default user? Didn't we already say all additions should happen via scriplets anyway? If that's the case then only advanced users would know what these additional files were being created for and so think to add any additional users.
Jon.
On Wed, 2009-03-11 at 17:53 -0400, Bill Nottingham wrote:
Jon Masters (jcm@redhat.com) said:
My point (as others made) is that making these files is completely useless. I'm not saying "overwrite the user's files" I'm saying ideally don't make the useless additional files on upgrade.
rpm already has code to avoid making them when they're useless. It's just being defeated by the sha256 code for the first upgrade to rawhide/F11.
So why aren't we putting both old and new hashes in the .rpm, for at least the duration of F11, so that we don't have this problem? RPM could then fall back on the old hashes for the purpose of detecting file modification if that's all that's in the existing RPM db.
On Wed, 2009-03-11 at 15:10 -0400, Jon Masters wrote:
My point (as others made) is that making these files is completely useless. I'm not saying "overwrite the user's files" I'm saying ideally don't make the useless additional files on upgrade.
Its not useless as things /do/ change in the repo files, like we're using metalink now. Its a good place for admins to find changes in repo structure that they can apply to their own already modified config files.
On Wed, 2009-03-11 at 15:06 -0700, Jesse Keating wrote:
On Wed, 2009-03-11 at 15:10 -0400, Jon Masters wrote:
My point (as others made) is that making these files is completely useless. I'm not saying "overwrite the user's files" I'm saying ideally don't make the useless additional files on upgrade.
Its not useless as things /do/ change in the repo files, like we're using metalink now. Its a good place for admins to find changes in repo structure that they can apply to their own already modified config files.
I was actually only referring to the specific case of setup though - apologies if it wasn't clear :)
Jon.