###############################################################################
#
# Environ v1.0.4 -- An Environment Manager
#
# Copyright (C)2000 Mark A. Bentley <bentlema@cs.umn.edu>
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
#
###############################################################################
#
# This file was last modified: August 2, 2000
#
# You can download the latest distribution from my web site:
#
# http://www.cs.umn.edu/~bentlema/projects
#
# For comments, suggestions, bug reports, patches, or whatever,
# you may contact me via email:
#
# Mark A. Bentley <bentlema@cs.umn.edu>
#
###############################################################################
E N V I R O N
Environ provides an interface for manipulating your UNIX environment. The interface enables users to easily add, change, and remove application specific variables and paths from their environment.
Why an environment manager?
An environment manager becomes useful at large sites where the administrator must support many software packages on many different platforms.
At such a large site, the paths to commands/software packages can vary from system to system. Users seeking a consistent environment usually end up writing fairly complex shell startup files. These startup files tend to be filled with nested if-statements, multiple hostname and uname calls, and a myriad of other bits of logic. Everyone has the same goal but everyone does it differently and spends (or wastes?) a lot of time doing it. We want a user to be able to login to any client workstation, regardless of the platform, and have it behave the same.
We don't expect the user to know how to edit their shell config file, or modify their PATH and MANPATH or other environment variables. We don't even want them to know where software is installed. What if we upgrade a piece of software to a newer version? We don't want to have to tell everyone where the new version is. It should be transparent to the user.
That's where an environment manager becomes useful. If we install a new piece of software, we just have to make a "module" available. The user can "load" this module, and the module will take care of modifying their environment so that the software can be found.
The user only needs to know the symbolic name for a given package and he or she will always be assured the the correct paths are being set, no matter which system the user is using.
The system administrator writes these system-wide environment configuration "modules" and makes them available on all platforms. Users can also write their own modules if they wish.
If we install a new version of an already installed piece of software, all we have to do is update its corresponding module. The next time the user logs in and runs the upgraded software, they would be running the new version. The upgrade would be transparent to them.
If we move a piece of software to another partition or server, this would probably be an autofs map update. I'll talk more about autofs and how it works well with the environment manager below.
As any SysAdmin knows, their are many types of users, and we have to support them all. Depending on the politics of your organization, you may be able to get away with making a policy that says: "We only support environments configured by the environment manager. We no longer support other methods of configuring your environment, such as manually setting your PATH env variable." This way, you eliminate having to deal with hundreds of different environments configured by thousands of different users. You could even provide a little script that users could run to restore their "dotfiles" to their original state.
It becomes much easier of a task dealing with user accounts, when you know that your not working with a broken configuration.
We could provide the same functionality with a global set of shell scripts, one for each shell, however an environment manager can improve on that paradigm in several ways:
- Shell independent configuration files
An environment module is configured by the system administrator by creating one file for every package that needs the environment to be modified. With the shell script paradigm, a script for each shell would need to be created.
If a package is moved or goes away, the system administrator needs only update the one module environment file.
- User level customization
Part of the problem with the global shell script paradigm is that it's usually an all or nothing situation for the user. With environment modules, the user can decide which packages he or she wants to be configured for.
Also, an additional benefit to the user is that each module is selfdocumenting. A user can query the module and learn what effect the module will have on his or her environment in addition to any special instructions related to the package.
- Interactive "on-the-fly" environment configuration
Users of the environment manager can load or unload any module interactively.
It's not necessary to clutter your environment with infrequently used configurations. This is especially critical at large sites where hundreds software packages are installed, and the shell variable length limit is easily reached.
- User modules
Anyone can create their own environment modules to supplement those site-wide modules provided by the SysAdmin. Users intent on not being dependent on their system administrators can write their own if they'd like.
How does autofs come into play here?
At any site where software is being made available via NFS, you'll find autofs or automount running. The maps are most likely made available via NIS. Autofs provides a nice abstraction layer between where the software is found in the filesystem, and it's actual location.
To illustrate how autofs works, I'll give an example. Suppose you want to make the Sun JDK available in /soft/java/JDK-1.2 at your site. Perhaps you have several servers, each with several software partitions. You choose one that has sufficient space, and that partition happens to be mounted on /export/soft03 on the NFS server named nfs1. You install the JDK in the java directory within /export/soft03, so your auto.soft map would contain a line like this:
java nfs1:/export/soft03/java
Then, from any client you'd be able to "cd into" the /soft/java directory and see that the JDK lives there.
This is glossing over some of the details. Naturally you'd need to make sure the /export/soft03 partition is being shared, and that nfs1 is a resolvable hostname, etc...
Autofs will automatically mount and unmount NFS shares as needed.
What if you decide to move the JDK to another partition? (for whatever reason.) Well, all you have to do is edit the auto.soft map, and update the java entry to reflect the new location. The next time autofs looks up the key "java" in the auto.soft map, it would see the new location and mount it.
Another nice feature of autofs is the ability to include environment variables in an entry. For example, suppose we have the JDK installed for several architectures in the following locations:
/export/soft03/java/RedHat6.2
/export/soft03/java/SunOS5.7
/export/soft03/java/IRIX6.5
We could use the following entry in auto.soft:
java /export/soft03/java/$OSNAME$OSREL
This way, depending on which platform we login to, autofs would mount the correct software for that architecture and operating system.
Using variables in automount values helps minimize how much work needs to be done in the environment module itself. You no longer have to check what type of system you're on since you know that when you cd into /soft/java the binaries contained within are for that platform.
Some operating systems (like Solaris) automatically define $OSNAME and $OSREL. Others (like Linux autofs) require you to explicitly define these variables with the -D flag. This is actually preferable on Linux systems, as the kernel versions tend to change rapidly. It becomes a pain to make symlinks for every kernel you support pointing back at a common directory. The better way to do it is to define $OSNAME as "Linux" and define $OSREL as the version of the libc library (like "glibc2.1" or "libc5"). Or if you support different distributions which not only use different versions of libc but also different versions of other common libraries, you might define $OSNAME as the name of the distribution (e.g. "RedHat") and $OSREL as the version of the distribution (e.g. "6.2").
Most Linux distributions have a common autofs startup script which contains a line to define extra arguments. For example, RedHat uses a "localoptions" variable in the /etc/rc.d/init.d/autofs startup script:
localoptions='rsize=8192,wsize=8192 -DOSNAME=RedHat -DOSREL=6.1'
You could even use the same options for newer releases (e.g. RedHat 6.2) as long as they use compatible versions of the libraries (glibc, gtk+, etc.)