Table of Contents
System management is a broad term. It is my attempt to cover the system administration tasks that almost every administrator (or end user) will need to know for his system, such as time management, language management, keyboard settings and more.
The Linux operating system makes extensive use of environment variables.
An environment variable is simply a key-value pair which a process can read out.
For instance, the environment variable
EDITOR (with, as
an example, value
/bin/nano) informs the process who
reads it that the default text editor is (in this case) nano. These
variables are not system-wide: if you alter the value of a variable, the
change is only active in the session where you are in (which is your shell
and the processes started from the shell).
There are quite a few environment variables you'll come across often.
DISPLAY environment variable is used when you're logged on to a
Unix/Linux system graphically. It identifies where X applications
should "send" their graphical screens to. When you log on to a system
remotely, this variable is set to your local IP address and the screen
number you're using on this system. Most of the time, when you're
logged on locally, it's content is ":0.0" (the first screen on the
Note that "screen" here isn't the hardware device, but a name given to a running X instance.
EDITOR variable identifies the default text editor you want to
use. Applications that spawn a text editor (for instance, visudo) to
edit one or more files, use this variable to know which text editor to
Locales are discussed later in this chapter. Its environment
LANG and the various
LC_* variables) identify the users' language,
time zone, currency, number formatting and more.
The PATH variable identifies the directories where the system should look for executable files (being binaries or shell scripts). If unset or set incorrectly, you cannot execute a command without providing the entire path to this command (except built-in shell commands as those are no executable files).
Below is a small example of a PATH variable:
~$ echo $PATH /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.1.2: /opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin: /usr/kde/3.5/bin:/usr/qt/3/bin:/usr/games/bin:/home/swift/bin/
An example of what happens when PATH is not set:
~$ ls (... listing of current directory ...) ~$ unset PATH ~$ ls -bash: ls: No such file or directory ~$ /bin/ls (... listing of current directory ...)
TERM variable allows command-line programs with special
characters to identify which terminal you use to run them. Although
nowadays the xterm TERM is most used, sometimes you will find yourself
logged on to a different system which doesn't know xterm or where the
application looks really awkward. In such cases a solution could be to
set the TERM variable to, for instance, vt100.
Environment variables are user specific, but can be set on three levels: session (only valid for the current, open session), user (only valid for this user and used as default for all sessions of this user) or system wide (used as a global default).
~$ ls -z ls: invalid option -- z Try `ls --help` for more information. ~$ export LANG="fr" ~$ ls -z ls: option invalide -- z Pour en savoir davantage, faites: `ls --help`
Which one to use depends on what you actually want to achieve:
With set, you change the environment variable for this session, but not for the subshells you might want to start from the current shell. In other words, set is local to the shell session.
With export, you change the environment variable for this session as well as subshells you might want to start from the current shell from this point onward. In other words, export is global.
User specific environment settings are best placed inside the
.bashrc file. This file is automatically read when a user is
logged on (at least when he is using the bash shell). A more
shell-agnostic file is
.profile. Inside the file, define the variables as you would for
a specific session:
To make an environment variable system wide, you must make sure
that your environment variable is stored in a file or location that
every session reads out when it is launched. By convention,
/etc/profile is a script in which system wide
environment variables can be placed. Gentoo offers a nice interface
for this: inside
/etc/env.d you can manage
environment variables in a more structured approach, and the
env-update script will then make sure that the
environment variables are stored elsewhere so that
/etc/profile reads them out.
The /etc/profile script does not read out all values inside /etc/env.d itself for (at least) two reasons:
The structure used in /etc/env.d uses a specific "appending" logic (i.e. variables that are defined several times do not overwrite each other; instead, their values are appended) which could be too hard to implement in /etc/profile without too much overhead. After all, /etc/profile is read by every newly launched session, so if it took too much time, your system would start up much slower.
The system administrator might want to make a set of changes which should be made atomic (for instance, remove a value from one variable and add it to another). If changes are publicized immediately, a session could read in /etc/profile which loads an at that time incorrect environment variable set (especially when a process is launched after the administrators' first change but before the second).
On Linux, the behaviour of many commands is manipulated by values
of environment entries, or environment variables. Within Gentoo Linux,
you can manage the system-wide environment variables through the
Inside /etc/env.d, you will find environment files which use a simple key=value syntax. For instance, the /etc/env.d/20java file defines, amongst other environment variables, the PATH and MANPATH variables:
# cat /etc/env.d/20java ... MANPATH=/opt/blackdown-jdk-1.4.2.03/man PATH=/opt/blackdown-jdk-1.4.2.03/bin:/opt/blackdown-jdk-1.4.2.03/jre/bin
With these settings, the value of MANPATH (location where man will search for its manual pages) and PATH (location where the system will look for executable binaries every time you enter a command) is extended with the given values (note that the variables are not rewritten: their value is appended to the value previously assigned to the variable).
The order in which variable values are appended is based on the
file name inside
/etc/env.d. This is why most
files start with a number (as most people find it easier to deal with
order based on numbers, plus that the filenames themselves are still
explanatory to what purpose they serve).
If you want to change a system variable globally, you can either
add another file to
/etc/env.d or manipulate an
existing one. In the latter case, you should be aware that application
upgrades automatically update their entries inside
/etc/env.d without warning (this location is not
protected, unlike many other configuration locations).
As such, it is advisable to always add your own files rather than manipulate existing ones.
This command will read in all environment files and write the
final result in
/etc/profile.env (which is
/etc/profile, which is always sourced
when a user logs on).
When I talk about location specific settings, I mean the settings that your neighbour is most likely to need as well: language settings, keyboard settings, time zone / currency settings, ... Within the Linux/Unix environment, these settings are combined in the locale settings and keyboard settings.
A locale is a setting that identifies the language, number format,
date/time format, time zone, daylight saving time and currency
information for a particular user or system. This locale information is
stored inside a variable called
LANG; however, it
is possible to switch a particular locale setting to another locale (for
instance, use the American English settings for everything, but currency
to European Euro).
The following table gives an overview of the most important variables:
Table 14.1. Locale variables supported on a Linux system
|A catch-all setting which identifies the locale for all possible features. However, individual topics can be overridden using one of the following variables.|
|Character handling (which characters are part of the alphabet) and (alphabetical) order|
|Applications that use message-based output use this setting to identify what language their output should be|
|Formatting of numerical values|
|Time related settings|
There is another variable available as well, called
LC_ALL. If this variable is set, none of the
above variables is used any more. However, use of this variable is
The format of a locale variable is as follows:
The settings used in this format are:
Table 14.2. List of settings used in a locale definition
|language||Language used. Examples are "en" (English), "nl" (Dutch), "fr" (French), "zh" (Chinese)|
|territory||Location used. Examples are "US" (United states), "BE" (Belgium), "FR" (France), "CN" (China)|
|codeset||Codeset used. Examples are "utf-8" and "iso-8859-1"|
|modifier||Modifier used, which allows a different definition of a locale even when all other settings are the same. Examples are "euro" and "preeuro" (which has its consequences on the monetary aspect).|
So, a few examples are:
LANG="en" LANG="nl_BE" LANG="en_US.utf-8" LANG="nl_NL@euro"
These settings are read as environment variables (which were
discussed earlier) by the applications. You can mark locales system
wide, but it is advised that this is stored on a per-user basis. As
such, I recommend that you set something like the following in your
~/.bashrc file (and in
/etc/skel/.bashrc so that newly created user
accounts have this set automatically as well):
$ nano -w ~/.bashrc ... # Put your fun stuff here LANG="en_US.utf-8"
When you aren't using the default qwerty layout, you'll need to
modify the keyboard mapping setting on your system. Gentoo makes this
easy for you: edit
/etc/conf.d/keymaps and set the
keymap variable to the mapping you need:
# nano -w /etc/conf.d/keymaps ... keymap="be-latin1"
A list of supported keymaps can be found in the subdirectories of
# loadkeys <keymap>
# date 093017342008
If your system has Internet access, it is wise to install ntp-supporting tools such as the net-misc/ntp package. With ntpdate (and other similar tools), you can use online time servers to set the time of your system correct to the second.
# ntpdate pool.ntp.org
# hwclock --systohc
Within Unix/Linux, the default scheduler often used is called cron. There are quite a few cron implementations available, such as the popular cronie, fcron, bcron and anacron. Once installed, you start the cron service through an init script (which you most likely add to the default runlevel):
# rc-update add cronie default # /etc/init.d/cronie start
When the cron service is running, every user can define one or more commands he wants to periodically execute.
$ crontab -e
Your current rule file will be shown in the default editor (nano, vim, ...). A crontab entry has 6 columns:
Table 14.3. Crontab columns
|Minute||Minute of the hour (0-59)|
|Hour||Hour of the day (0-23)|
|Day||Day of the month (1-31)|
|Month||Month of the year (1-12 or use names)|
|Weekday||Day of the week (0-7 or use names. 0/7 are Sunday)|
|Command||Command to execute|
Next to the number representation, you can use ranges (first-last), summation (1,3,5), steps (0-23/2) and wildcards.
For instance, to execute "ntpdate ntp.pool.org" every 15 minutes, the line could look like:
*/15 * * * * ntpdate ntp.pool.org
0,15,30,45 * * * * ntpdate ntp.pool.org
If you just want to view the scheduled commands, run crontab -l.