Greetings,
At our institute we use UNIX on a variety of platforms. To shield users
from system (e.g., Linux, IRIX, OS/X, etc.) differences we have
developed our own common shell environment, basically a big dot-profile
shared by all users - but with hooks for customization - that sorts out
things so that end users get the same "look and feel" on all systems.
This POSIX shell based environment does not (or need not) conform to
LAM requirements (e.g., it can produce output on stderr, among other
things.)
Of course since we have complete control over our shell initialzation
we can make it LAM-compliant when needed. The problem is LAM doesn't
identify itself.
Specifically, when lamboot (and recon) starts a daemon on a remote host
it does not provide any information in the shell variable environment to
indicate that LAM is starting. Hence we cannot disable the
LAM-unnecessary and/or unfriendly parts of .profile (or .login, .cshrc,
.bashunderscorewhaterver).
The quick and dirty workaround is to set LAMRSH to point to a script
that takes the arguments to SSH - we use the LAM that comes with RedHat
- and adds something like "export LAM=yes" to the "-n" option just
before "./.profile" is dotted. Works like a charm. Our environment
sees the LAM=yes and does the right thing.
As a newbie to LAM I would have expected that this problem would have
been addressed in the LAM framework. For example, by a setting in the
config file, or by a command-line argument (to lamboot/recon), or by
default. Perhaps I've missed something in the documentation, in which
case I'd appreciate a pointer.
Otherwise, I'd like to suggest to the LAM community defining a shell
variable - the name and value are insignificant if unique - whenever any
shell-related process or program is started so that non-LAM code can
detect LAM and take appropriate action.
Cheers,
Irv Elshoff @ WL
|
