[nSLUG] abuse of environment variables

George N. White III gnwiii at gmail.com
Sun Sep 21 15:15:02 ADT 2008

On Sun, Sep 21, 2008 at 2:24 PM, Daniel Morrison <draker at gmail.com> wrote:

> 2008/9/21 George N. White III <gnwiii at gmail.com>:
>> I've spent way too much time tracking down places where environment
>> variables have been set to values that cause something to break:
> I agree with all that.  It's a real hassle.
>> http://wuetender-junger-mann.de/wordpress/?p=462
> Unfortunately, this is advice for application programmers, and doesn't
> help poor sysadmins when all sorts of applications that are required use
> environment variables heavily.
> My attempts to mitigate this problem revolve around the idea of setting
> the environment variables as needed for the applications, and NOT in the
> shell in general.
> Halfway there:
> tell your users: before you use package XYZ, type:
>   . /path/to/XYZ.sh
> Then the environment variables are set only in the shell which is about to
> execute the application in question.  However this still leaves the shell
> running with variables set in it, like a time bomb (the user will lose
> track of which shell is which).  It also requires the user to launch
> applications from a cmd line!
> All the way there:
> Better is to create a wrapper script around the application executable.
> This will set the environment variables for the application only.  Then
> the wrapper script can be used in menu items or panel button launchers.
> It always works properly because the env variables are set, and it doesn't
> interfere with anything else.

I've done that with one of our "mission critical" applications, but some
people insist on following the manual, which says to source the
config file in .profile or .login, so not everyone uses the wrapper.

Further complications come up because we need to use more than
one version of the application (e.g., to measure and understand
differences in results between versions).

> If an application has three dozen cmd-line programs that all expect the
> environment variable to be set (e.g. sun grid engine!) then you can a)
> just live with the variables cluttering up the environment :(
> (SGE_HOME=/usr/sungrid is probably pretty safe, if you only have one
> version of SGE), or b) write a wrapper script that checks its $0 to find
> out what was invoked, so as to execute the correct command, and then make
> links so that the script is invoked for every cmd-line program name.

Some applications source a config file in each script, so they don't
clutter the environment, and all the scripts see the same settings.
But then you have the issue of how to manage the config files --
do you pass them out to users, in which updates may not be made,
or have one master version.   Some apps source a default config
file and then check for a user file and source than too.

> If users absolutely require unique env variable configurations, then
> either they're capable enough to do it themselves, or, you'll need to
> add custom options, by username/UID, to the wrapper script (this is where
> making the all those links in the previous step is helpful -- only have to
> customize for a particular user once in the master script!).

Even capable users can get into problems, e.g., blindly following
bad advice from some internet group an app they just want to get
going, or forgetting that they worked around some problem by
setting some variable to a value that only worked one Tuesday
last may deep in a script.

> Hope this might be helpful,

Certainly.  I'm not convinced the problems can be solved with current tools,
but I'm also not current on the ways newer environments handle
configuration settings.  Does dbus offer an alternative?  Should the
environment have namespaces?  Should envt. variables have
extended attributes (e.g., only certain users can change values,
variables that are hidden from some users, debugging hooks that
record when and by what process a given variable is changed).

> PS: I'm enjoying this, but it seems maybe what we really need is a
> "Nova Scotia Sysadmin Sympathy & Support Group" mailing list! (NSSSSG

I'd prefer a NSSSPG (.. Solutions to System Problems Group) where
we come up with some good solutions for the problems we see.
Many of the problems aren't specific to NS, but among recent discussion,
energy accounting and finding electrical contractors who do modern
control signalling systems are.

George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia

More information about the nSLUG mailing list