On 6/28/2010 1:01 PM, Whit Blauvelt wrote:
That's why I always thoroughly log all stuff installed by hand, along with extra configuration steps taken with RPM-installed items, and make sure the log's someplace where the next person can find it. In our case we maintain wikis for this sort of thing. It would be nice if there were a standard for where such notes should be left on the systems themselves. Not aware that there is one, though.
The standard place is for the rpm database to hold the list of files in each package and to the extent possible values for local config options to be split out as a file under /etc/sysconfig and somehow merged at runtime. And the standard for documentation would be matching man pages included in the package.
Les, that's not my question. My question is about there being a standard place to record what's installed _outside_ of the distro's package management scheme. IMHO telling people it's not proper to do that is an attempt to impose a local custom in a world where many people are more sophisticated, and blend customs from various communities.
I don't think there is such a standard and it doesn't make much sense for it to be a part of the machine itself anyway. You really need this stuff on a separate system where it will be available when you are trying to re-create the machine in question after it dies or you are reinstalling your backups. Wiki's are probably a common choice - or documents managed in a well-backed-up revision control repository. On the machine itself, if I edit things by hand I try to include comments if possible, and leave the original lines intact but commented out - and in a few cases I grab copies of these files via rsync to a central location and commit to a subversion repository periodically. Then running 'viewvc' with that repository permits web viewing of color-coded diffs of any versions that have ever been committed. This is also a good way to handle things like router configs that can be handled as text files. If you do the commit step by hand you can add comments about why the change was made that you will be able to read in the revision history. It isn't hard to set up subversion and viewvc (although somewhat related to this discussion, you'd want much newer releases like those at rpmforge), but it would be nice if something like that was set up to store at least everything under /etc that didn't match the rpm-installed version came as part of the system - and even better if it could treat many similar systems as branches from the base install in the versioning scheme.
I'm certainly not coming to this list and complaining when anything I've built by hand on top of CentOS doesn't do what I want. I get it that the regulars here don't want to support that. Trying to convince everyone not to build and install anything from tar, ever, may be overkill. Wearing my sysadmin hat I appreciate the conservative approach; but I also wear a developer hat, from which POV sticking with obsolete programs just to make the sysadmin half of me maximally comfortable is too serious a compromise.
Developers typically know how to build things such that multiple versions of the same libraries and apps can co-exist at once. RPM, unfortunately, isn't that bright. I'm not a purist about using RPM myself and consider it entirely reasonable to have locally built versions of a few things in your $HOME/user/bin or /user/local/bin directories as long as you understand the side effects - and that includes knowing the search order of $PATH and perhaps $LD_LIBRARY_PATH that other things on the machine might be using.