Print

This article is complimentary to the previous article "User Profile and Environment".  Broad topics include: Which Shell?, Utilities, Managing Open Source.

 

Which Shell?

In short, CSH and its variants aren't worth messing with unless absolutely coerced.  I have found explainable and repeatable bugs that make no sense with Csh.  There is quite a choice for Bourne shell variants.  I look for the lowest common equivalent between the OS variants.  I have found that Bash is the most widely supported at the same major version that can be compatibly used out-of-box across the network.  The last thing I would care to do is re-invent the wheel of a basic foundational component of the OS.

Utilities

Working with more than one OS variant will present issues for providing consistent utilities such as Perl, Python, Sudo, etc. since these essential tools are at various obsolete versions.  As well as managing a consistent set of plugin modules can be difficult to maintain, especially when loaded on each individual host in the network.  I have found it prudent to download the source to these utility software along with desirable modules that provide extended utility.  The rule of thumb here is if all your OS variants sufficiently support an out-of-box version, then use the default; if not, compile it and manage it to provide consistency in your holistic network.

Managing Open Source Code

Granted binary compatibility doesn't cross OS platform and sometimes does not cross OS version, I have found it is easier to compile and manage my homogeneous utility set on each OS variant and share it transparently across the network leveraging off of the automounter service.  First, let's look at a structure that will support a network share for your homogeneous utility set.

There are binary, configuration and log data on a filesystem to be shared.  Below is a diagram for implementing a logical filesystem supporting your homogeneous utility set.

 

 

I create the automount map supporting this directory structure with embedded tokens on the "Shared on like OS variant" subdirectories that give identity to the OS variant. The size is fairly small.  I simplify by storing all these mounts on the same volume.  By doing this, you can replicate between sites, which will yield a consistent deployment as well as provide for your disaster recovery plan.  I also provide for a pre-production mount as well.  The "Shared on all OS variants" exist on a shared filesystem that is replicated for disaster recovery, but not used at other sites.  Below is a sample for structuring the filesystem share.

Shared on All Hosts Shared on All Like OS Variant

 

 Here is a sample indirect automap defining the key value pairs supporting mount point /global that is stored in the "auto.global" map.

Key Value
etc nas001:/vol1/global_common/$ENVN/etc
log nas001:/vol1/global_common/$ENVN/log
bin nas001:/vol2/$OSV/$ENVN/bin
sbin nas001:/vol2/$OSV/$ENVN/sbin
lib nas001:/vol2/$OSV/$ENVN/lib
lib64 nas001:/vol2/$OSV/$ENVN/lib64

 

Embedded tokens are resolved through the client automounter configuration.  For Linux this is done either in the /etc/auto.master file or in the /etc/sysconfig/autofs (RedHat).  This is a sample for configuring in the /etc/auto.master configuration file.

/global    -DOSV=rhel5,-DENVN=prod   auto.global

 This is what would be added to /etc/sysconfig/autofs configuration file.  Note that this affects all entries where /etc/auto.master affects only the single map referenced.