Re: [Cooker] /etc/passwd in RPMs
--- Ed Wilts [EMAIL PROTECTED] wrote: On Tuesday 03 April 2001 15:42, John Cavan wrote: what's wrong with .rpmnew ? Nothing for me, but think about it from a newbie perspective. They will likely think that something went wrong during installation and around a rather critical file. Basically, all I'm suggesting is that we treat /etc/passwd and similar files like XF86Config... create it, never install it. After that, specific packages can add or remove as needed, including setup. I disagree. I regularly go through and search for .rpmnew files and then compare what's in them with my own versions. Sometimes there are new defaults or options that weren't there when I did my own customizations. I then decide to either toss my file and start with the .rpmnew version, or apply some changes to my own. I do the same as you with rpmnew, rpmorig and rpmsave files, but I think you are wrong. The diff technique is difficult to apply to the password or group files, just because of the nature of those files. For instance, there may be entries that are not on the defult file, but where *not* created by you, instead by some rpm or non-rpm software package install. These issues may be easy to sort out by a competent admin that knows each and every one of the IDs byu memory, but can become very confusing for the average Unix competent joe. They issue at hand is that having an rpmnew file implies there are changes to be made, when in fact the setup rpm package runs the update-password utility. You do one of the two, but not both ... Besides, the default master lists are always available as: /usr/share/base-passwd/group.master /usr/share/base-passwd/passwd.master So why also have them as rpmnew? = Eugenio Diaz, BSEE/BSCE Linux Engineer [EMAIL PROTECTED] __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
Re: [Cooker] /etc/passwd in RPMs
What John means is from an *absolute* newbie's perspective. I still remembered when I use rpm the first time, when I saw those rpmsave, rpmnew etc, I wondered if my config files are trashed or completely replaced or something.. completely no idea what's going on at that time. Abel Cheung On Tue, 3 Apr 2001, Ed Wilts wrote: On Tuesday 03 April 2001 15:42, John Cavan wrote: what's wrong with .rpmnew ? Nothing for me, but think about it from a newbie perspective. They will likely think that something went wrong during installation and around a rather critical file. Basically, all I'm suggesting is that we treat /etc/passwd and similar files like XF86Config... create it, never install it. After that, specific packages can add or remove as needed, including setup. I disagree. I regularly go through and search for .rpmnew files and then compare what's in them with my own versions. Sometimes there are new defaults or options that weren't there when I did my own customizations. I then decide to either toss my file and start with the .rpmnew version, or apply some changes to my own.
Re: [Cooker] /etc/passwd in RPMs
John Cavan [EMAIL PROTECTED] writes: Is it really necessary to have /etc/passwd and /etc/group in RPMs? I yes, needed for install in any case new/removed groups are merged by update-passwd file. -- MandrakeSoft Inc http://www.chmouel.org --Chmouel
Re: [Cooker] /etc/passwd in RPMs
Chmouel Boudjnah wrote: John Cavan [EMAIL PROTECTED] writes: Is it really necessary to have /etc/passwd and /etc/group in RPMs? I yes, needed for install in any case new/removed groups are merged by update-passwd file. Would it not make more sense for the install program to create the base files in /etc and then execute update-passwd? Keeps /etc from being littered with *.rpmnew files and keeps newbies from wondering what the heck is going on. Anyways there are users in the default passwd file that should only be added by the RPM for the software they belong to. Users like postgres, dhcpd, named, etc are not mandatory system users if you don't have the packages for them installed. John
Re: [Cooker] /etc/passwd in RPMs
John Cavan [EMAIL PROTECTED] writes: Would it not make more sense for the install program to create the base files in /etc and then execute update-passwd? Keeps /etc from being littered with *.rpmnew files and keeps newbies from wondering what the heck is going on. what's wrong with .rpmnew ? -- MandrakeSoft Inc http://www.chmouel.org --Chmouel
Re: [Cooker] /etc/passwd in RPMs
On 3 Apr 2001, Chmouel Boudjnah wrote: John Cavan [EMAIL PROTECTED] writes: Would it not make more sense for the install program to create the base files in /etc and then execute update-passwd? Keeps /etc from being littered with *.rpmnew files and keeps newbies from wondering what the heck is going on. what's wrong with .rpmnew ? Nothing for me, but think about it from a newbie perspective. They will likely think that something went wrong during installation and around a rather critical file. Basically, all I'm suggesting is that we treat /etc/passwd and similar files like XF86Config... create it, never install it. After that, specific packages can add or remove as needed, including setup. John
Re: [Cooker] /etc/passwd in RPMs
On Tuesday 03 April 2001 15:42, John Cavan wrote: what's wrong with .rpmnew ? Nothing for me, but think about it from a newbie perspective. They will likely think that something went wrong during installation and around a rather critical file. Basically, all I'm suggesting is that we treat /etc/passwd and similar files like XF86Config... create it, never install it. After that, specific packages can add or remove as needed, including setup. I disagree. I regularly go through and search for .rpmnew files and then compare what's in them with my own versions. Sometimes there are new defaults or options that weren't there when I did my own customizations. I then decide to either toss my file and start with the .rpmnew version, or apply some changes to my own. .../Ed -- Ed Wilts, Mounds View, MN, USA mailto:[EMAIL PROTECTED]
Re: [Cooker] /etc/passwd in RPMs
Ed Wilts wrote: Basically, all I'm suggesting is that we treat /etc/passwd and similar files like XF86Config... create it, never install it. After that, specific packages can add or remove as needed, including setup. I disagree. I regularly go through and search for .rpmnew files and then compare what's in them with my own versions. Sometimes there are new defaults or options that weren't there when I did my own customizations. I then decide to either toss my file and start with the .rpmnew version, or apply some changes to my own. Not thinking like a newbie. :o) I do the same as you, but I'm not a newbie. What I'm suggesting applies mostly to system critical files that can easily be manipulated through existing tools and are expected to change. Look at the case that I keep bringing up... It is pretty simple for the pre-install script of the postgres RPM to run useradd and post-uninstall script to run userdel (and trap errors should the user exist/not exist). Why would you create users to run software that isn't installed? The same applies to other such files or RPMs. For configuration files which are not expected to change (such XftConfig), by all means, install them, even if they do end up with a .rpmnew extension. If the user has changed the file, then they can inspect for differences and make the change. Realizing, of course, that people who are newbies won't typically change these files and people who are experienced know what to do when a new file comes in. Just my opinion. John
