Setting Global Environment

Latest response

Hello. I want to set an evironment globally on RHEL 5.9 for bash shell. Do I need to just apend the path that I want globally in the /etc/profile file?

Responses

Hi George,

If you are sure it is just the bash shell, that might work. Check out the below though, if you want this for all possible users, some may not use bash (details below)

I happen to be researching this on and off, and the below bits I post here should be treated as merely a starting point and not definitive or complete by any means.

I hope this helps, I've been looking into this (and am still researching) and have found more than I intially bargined for.

It seems that /etc/profile is sourced by all login Bourne shells, but not other shells. From what I have read here,

quote from link above:
bash login shells execute /etc/profile which sources files in 
/etc/profile.d/*.sh, but non-login shells do not.  

csh login shells execute /etc/csh.cshrc which sources files in 
/etc/profile.d/*.sh; non-login shells do also.

Not only are global environments in /etc/profile, but in scripts within /etc/profile.d/ and also global environment variables in /etc/security/pam_env.conf. However, /etc/security/pam_env.conf is only full of "comments" (everything in that file is "commented out" with "#" characters on several of my RHEL servers. (Try "grep -v ^# /etc/security/pam_env.conf")

Here's an example of some default system global environmental variables that are set by scripts in /etc/profile.d/ such as:

[root@test1 profile.d]# echo `pwd`;ls -l
/etc/profile.d
total 60
-rw-r--r--. 1 root root 1127 Oct 17 08:51 colorls.csh
-rw-r--r--. 1 root root 1143 Oct 17 08:51 colorls.sh
-rw-r--r--. 1 root root   92 Jun 24  2013 cvs.csh
-rw-r--r--. 1 root root   78 Jun 24  2013 cvs.sh
-rw-r--r--. 1 root root  192 Aug 27 10:13 glib2.csh
-rw-r--r--. 1 root root  192 Aug 27 10:13 glib2.sh
-rw-r--r--. 1 root root 1741 Oct 10 11:30 lang.csh
-rw-r--r--. 1 root root 2706 Oct 10 11:30 lang.sh
-rw-r--r--. 1 root root  122 Feb  7  2007 less.csh
-rw-r--r--. 1 root root  108 Feb  7  2007 less.sh
-rwxr-xr-x. 1 root root  231 May  4  2011 oracle.csh
-rwxr-xr-x. 1 root root  226 May  4  2011 oracle.sh
-rw-r--r--. 1 root root   97 Feb 17  2012 vim.csh
-rw-r--r--. 1 root root  269 Feb 17  2012 vim.sh
-rw-r--r--. 1 root root  169 May 20  2009 which2.sh

Note that some are ending with 'csh' and 'sh' (I think the ending extension is not really needed, but the extensions show at a glance what shell they are targeted against.

So for instance, there are to shell scripts for every one of the above scripts with the exception of "which2.sh".

Check out:
* As yet another starting point, see this bit at IBM to account for global environments with different shells (IBM often has some amazing documentation), and examine it's use.
* This bit in a red hat article from 2006 shows how to set global path variable in a specific order
* Apparently, some things do not change, like this Red Hat article from 2005 on setting permenant shell enviornments for editors for all or just one user
* This solution ID 500213 from Red Hat speaks of using /etc/profile.d/path.sh to "Define PATH variable for whole system in RHEL 6"

  • Some considerations for global environments:
    1) different users may use different shells and if your export only targets bash, users of csh will not be affected.
    2) If you want automated processes to use the global environment variable, check the automated scripts used to see what shell is cited for the same reason as number 1 just above.

I could not (maybe someone else can) find much at access.redhat.com for guidance on setting global environments. However, I found:
1) This at IBM's website

Lastly, and certainly not least or to end this matter because it deserves more research, check this seemingly very well-sourced bit (keep in mind the link goes to Ubuntu's help pages, Debian based) - the material seems worthwhile at least for a read.

The last 'lastly', I'd recommend when you do implement your global environments, to test them with different users (especially if they have different default shells), test against any automated processes (cron scripts, etc) to see if your settings are being established as you wish.

Hope this helps, I do not consider what I wrote here as definitive nor complete and hopefully this will spark others to converse in this and add other good information.
Remmele