[procps] Re: top buglets + misc
- From: Sami Kerola <kerolasa@xxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Mon, 20 Feb 2012 10:05:46 +0100
On Fri, Feb 17, 2012 at 15:10, Jim Warner <james.warner@xxxxxxxxxxx> wrote:
> I wasn't thinking of a single script but of multiple scripts tailored to
> specific hosts. Maybe named HOSTNAME-top or something like it. Then there
> would be no PATH issues and one could be certain which top was being invoked.
>
> Perhaps such an approach could be combined with Craig's suggestion here. Then
> one would know which top was being invoked and be able to tell at a glance
> which top was being observed.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340751
Think this from environment management point of view. Some people do stuff
link this.
https://github.com/kerolasa/myskel
git://joshtriplett.org/git/home
Some installations use home on NFS, which is not in conflict with 'master'
settings idea above. The NFS simply a distribution channel of the
configuration, which could be puppet or cfengine as well. Pushing 'what has to
go where' being distribution channel problem will upset people (see me, nearly
upset already ;-) simply because it is though way to deal these things.
Just in case you don't believe me have a look of 'A Retrospective on Twelve
Years of LISA' from year 1999.
http://now.cs.berkeley.edu/Sysadmin/categorization/categorize-lisa99.ps
Installations & configuration management has been difficult and unsolved issue
to system administrators since beginning of time. While computing is not quite
the same it was at '80s we still have these problems. For example why there
are rpm, debian, archlinux pacman and so on package manager, which are
distributed with yum, apt, pacman... To manage systems there is cfengine,
puppet, tivoli and how knows what.
AFAIK none of the configuration management silver bullets has really worked.
The rational thing to do seems to be minimize need to manage configuration.
>> if [ 2 -lt $(top -V | awk '$2 ~ /^version$/ {split($3, VER, ".");
>> print VER[1]}') ]; then
>> NEWTOPRC_SUBDIR=.newtop_rcdir
>> if [ ! -d $HOME/$NEWTOPRC_SUBDIR ]; then
>> mkdir -p $HOME/$NEWTOPRC_SUBDIR
>> fi
>> alias top="HOME=$HOME/$NEWTOPRC_SUBDIR top"
>> fi
>>
>> Advising that feels wrong. Is it really hard requirement to have toprc path
>> clash? Attachment related.
>
> There would be no clash if there were multiple scripts. Besides, this patch
> deals with versions of top but not with various systems where top may be run.
That was the reason why I thought environment variable would be handy. One
could do something like
case $HOSTNAME in
moskvax)
TOP3RC=$HOME/.toprc.d/moskvax
*)
TOP3RC=$HOME/.toprc.d/default
esac
And when NEWTOPRC is missing use $HOME/.top3rc or something. IMHO that is
easy to manage and understand. Another advantage is that no matter how complex
the installation is that should not blow up.
> And incidentally, there has been no change the SYS_RCFILESPEC file contents
> since its inception and so never a need to "unclash" it.
>
>> p.s. If not changing rc file name is requirement could at least that
>> scriptlet be part of documentation? I am nearly sure I'm not the only
>> sysadmin looking after heterogeneous non-synchronized systems where there
>> are and isn't NFS shared home directory on nearly random set of servers.
>> This use case might be significant as the top is system admin utility.
>
> I'm not a sysadmin, Sami, nor am I very versed in networking. My experience
> consists solely of ssh'ing around my home network. But I would like to know
> how your original TOPRC approach was to be handled in the environment you
> cite above.
I have had .toprc for about two three years. During that most of the systems I
have worked with has been linuxes, but there are couple FreeBSDs as well. In
this envinronment the settings file has not failed me (yet).
In previous company where there where one of every possible operating
environment I tried to keep my environment as simple and minimal as possible
(no toprc for instance). I would not like to go back to minimal set up.
> At this point, I don't know if you are trying to solve a perceived problem
> for an ordinary user (should they be running top anyway?) or a sysadmin. But
> to suggest that my simple scriptlet become part of the distribution seems a
> little silly.
Could you consider system administrators are users? System admins deserve good
tools as much as any other users.
--
Sami Kerola
http://www.iki.fi/kerolasa/
Other related posts:
