Linux bashrc profile etc

What is the difference between the various shell profiles?

What’s the difference between ~/.bashrc, ~/.bash_login, ~/.bash_logout, ~/.bash_profile, ~/.profile, /etc/profile, /etc/bash.bashrc, /etc/ssh/ssh_config and sshd_config, when are they loaded and what are their purposes?

2 Answers 2

The man page for bash says there are the following initialization files for bash shells:

/etc/profile The systemwide initialization file, executed for login shells /etc/bash.bashrc The systemwide per-interactive-shell startup file /etc/bash.bash.logout The systemwide login shell cleanup file, executed when a login shell exits ~/.bash_profile The personal initialization file, executed for login shells ~/.bashrc The individual per-interactive-shell startup file ~/.bash_logout The individual login shell cleanup file, executed when a login shell exits ~/.inputrc Individual readline initialization file 

Apparently there seem to be different configuration files for the different shells (bash, zsh, csh, and others). There seem to be as many shells as different linux and unix versions: csh, ksh, bash, zsh, . Bash has a .bashrc , Zsh has a .zshrc , etc. One can also distinguish between login shells and non-login shells and between system-wide defaults and user-specific defaults.

It makes sense to distinguish between login and non-login shells, because some commands should be processed only at login, while other commands should run everytime you open a new terminal window. That is the difference between .bash_profile and .bashrc. For bash the .bashrc is reloaded every time you start a new copy of bash, i.e. when you start a new bash but do not login. The .bash_profile or .profile is loaded only when you login. The abbtreviation rc in bashrc stands for «run commands» or «run control» and is a convention adopted from older Unix systems.

• /etc/profile ..login shells, for interactive shells with login
• /etc/bashrc ..non-login Bash shells

user-specific defaults in home directory ~ for..

• ~/.profile ..login shells, called after login
• ~/.bashrc ..non-login shells, if already logged in
• ~/.bash_profile ..login shells, called after login (lower priority)

user-specific defaults in home directory for login and logout

• ~/.bash_login ..login shells (called upon login)
• ~/.bash_logout ..login shells (called upon logout)

Источник

How to customize Linux user environments

System security is a major concern. As a sysadmin, as I’ve stated before, it’s your primary concern. Adding users to a system decreases security. Your job is to create a usable but secure environment for your users. You have corporate assets to protect, systems to maintain, and users to satisfy. There’s often a conflict among those three aspects of system administration, as you well know. One way to satisfy all three is to customize your user’s environments by implementing and enforcing a corporate standard. Striking a balance between user productivity and system security isn’t easy. I can’t write specifications for your particular situation, but I can show you where to make the necessary changes so that you can do so.

Great Linux resources

This article covers customizing your user’s environments using files found in the /etc/skel and /etc/profile.d directories. With a fresh system install, you’ll find three files under /etc/skel: .bash_logout , .bash_profile , and .bashrc . When you create a new user account on a system, these three files are copied to the user’s home directory and are owned by the user. In case you don’t know, so-called dot files (those named with a preceding dot (.) are hidden from standard file lists. To see them, you must use the -a switch with the ls command.

-rw-r--r--. 1 root root 18 Mar 31 21:17 .bash_logout -rw-r--r--. 1 root root 193 Mar 31 21:17 .bash_profile -rw-r--r--. 1 root root 231 Mar 31 21:17 .bashrc

As you can see, these files are owned by root and can only be edited or changed by the root user.

.bash_profile

The .bash_profile file is the most important of the three files listed. It’s most important because it is the only «required» file in the list. It executes every time the user logs into a system, it launches the .bashrc file, and defines and exports the PATH variable. Its default settings are simple.

# .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=$PATH:$HOME/.local/bin:$HOME/bin export PATH 

The .bash_profile can also be used to define a custom shell prompt, define one’s editor of choice, or anything else that you want to place into the file for the user.

.bashrc

The contents of the .bashrc file, by default, only call the /etc/bashrc file. The /etc/bashrc file consists of settings that can be configured for all users.

# .bashrc # Source global definitions if [ -f /etc/bashrc ]; then . /etc/bashrc fi # Uncomment the following line if you don't like systemctl's auto-paging feature: # export SYSTEMD_PAGER= # User specific aliases and functions

You could call other files configured for certain user groups as well. For example, if a user is a member of the finance group, you could call a file to set up a particular set of variables for all users in the finance group.

/etc/bashrc and /etc/profile

The listing for /etc/bashrc is far too long for this venue, but you can look at it and see what it does. The /etc/bashrc file refers to the /etc/profile file for more environment variables and settings. Both files come with the following warning.

# It's NOT a good idea to change this file unless you know what you # are doing. It's much better to create a custom.sh shell script in # /etc/profile.d/ to make custom changes to your environment, as this # will prevent the need for merging in future updates.

So, you see, customizing a user environment is not as simple as you thought.

/etc/profile.d

If you list the files in /etc/profile.d , you’ll see the following:

-rw-r--r--. 1 root root 771 Mar 31 21:50 256term.csh -rw-r--r--. 1 root root 841 Mar 31 21:50 256term.sh -rw-r--r--. 1 root root 196 Mar 24 2017 colorgrep.csh -rw-r--r--. 1 root root 201 Mar 24 2017 colorgrep.sh -rw-r--r--. 1 root root 1741 Aug 6 2019 colorls.csh -rw-r--r--. 1 root root 1606 Aug 6 2019 colorls.sh -rw-r--r--. 1 root root 80 Mar 31 23:29 csh.local -rw-r--r--. 1 root root 1706 Mar 31 21:50 lang.csh -rw-r--r--. 1 root root 2703 Mar 31 21:50 lang.sh -rw-r--r--. 1 root root 123 Jul 30 2015 less.csh -rw-r--r--. 1 root root 121 Jul 30 2015 less.sh -rw-r--r--. 1 root root 81 Mar 31 23:29 sh.local -rw-r--r--. 1 root root 164 Jan 27 2014 which2.csh -rw-r--r--. 1 root root 169 Jan 27 2014 which2.sh

You can see that many of the files are for use in the C shell. The most important file for this article’s focus is sh.local . The contents of sh.local is listed below.

#Add any required envvar overrides to this file, it is sourced from /etc/profile

As you can see from the message, if you want to override any currently configured envvar (Environment variables) entries with a corporate standard, make entries in this file to do that.

Caveats

As users learn more about their environments and Google things, they’ll customize their own—often to their detriment. You have to strike a balance between being a laissez-faire sysadmin and a heavy-handed dictator sysadmin. You want users to be productive but have some limited control over their own environments. My suggestion to make both sides happy is to set all corporate standard user environment parameters in /etc/bashrc and in /etc/profile.d/sh.local that you don’t want to be edited or changed.

Realize that the /home/user/.bash_profile , .bashrc , and .bash_logout are user-editable files. The only way around this is to change permission on those files with a root user script after you create the accounts. In other words, run a script after you create a user account to change the permissions on the /home/user/.bash* files to root: rw-r—r— . The user won’t be able to alter the files.

If you want to lock down the environment by changing the .bash* files to root ownership, you could create a new file in /etc/skel such as a .user file that the user can edit and include it in the .bash_profile file.

Wrap up

Customizing a user’s environment can enhance system security and standardize what users see and how they interact with a system. Granting shell access to a production system has its own implications, but you must provide resources for your users to maximize their productivity and maximize system security. If you find that perfect balance, please write it up into an article for Enable Sysadmin. In my own experience, every user feels that they are the exception to the corporate standard and, pretty soon, you have a bunch of exceptions and no corporate standard at all.

Источник