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.
--
Les Mikesell
lesmikesell at gmail.com