Setting Global Environment
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
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
