Applications, for example bash, often use variables. These variables are not necessarily available as environment variables, but often have a local scope: they are available for the process, but not for its children. On the other hand, every environmental variable set by an application is available for every child of that application. For example: within a shell you can access environment variables as if they were locally defined shell-variables. You can “promote” a shell variable to an environment variable by using the export builtin.

Many environment settings influence the behaviour of applications. Some of them are very specific for just one application. But there are a number of standard variables that many application will use or expect to be in place. A list of the most commonly used environment variables follows:

To see your environment from within a shell, type env or set. Of course, the value of individual variables can be printed using the echo.

The file /etc/shells lists the valid login shells on your system. It requires fully specified filenames. An example file is:

/bin/bash
/bin/sh
/bin/tcsh
/bin/csh
/bin/ash
/bin/bsh
/bin/ksh
/bin/false

/bin/false is not a real shell, however, sometimes you want to add a user to your system that is not allowed to log in (e.g. wwwrun. Adding a user to your system requires giving him an entry in /etc/passwd, which in turn requires you to specify a valid login shell. Being able to specify /bin/false as “shell” prevents users to obtain a shell. The command chsh can be used by the user to set his preferred shell. “root” can use this command to set any user's shell. This command with the -l option will list the available shells. The -s option will allow the user to change his login shell:

$ chsh -s /bin/sh 

Most of your users log in and are presented with a shell. A shell's behaviour typically is controlled by setting a number of environmental variables. These are typically set at two levels: system wide and per user. To set them, a start-up file is loaded and executed. There are many shells - most of them have specific start-up files. Additionally, it depends on whether or not the shell is spawned by the login program or by another shell which startup files are executed. However, when shells are reported to display unexpected behaviour, often something is set wrongly in one of the start up files.

Most login-shells will check for /etc/profile first. Typically, this file sets the TERM and PATH variables. The format for this file is the same as that of a (Posix) shell. It hence contains calls to external programs: in older days, the fortune command was often called here: it generates a random epigram. On older systems the contents of the message of the day file (/etc/motd) were displayed here too, on newer systems this is often done by the login program itself.

More settings can be put in (often shell-specific) startup files in the users HOME directory. Posix compliant shells will check for $HOME/.profile. bash will behave likewise, if invoked as sh. Often, on Linux systems, /bin/sh is a (symbolic) link to /bin/bash. Some distributions put calls to distribution or shell specific central startup files into the user level files. This can be confusing at times.

bash is the most commonly used shell for Linux systems. It will run /etc/profile if invoked from login, then look for $HOME/.bash_profile, $HOME/.bash_login and $HOME/.profile, in that order. It and reads and executes commands from the first one that exists and is readable. When a bash login shell exits it reads and executes commands from the file $HOME/.bash_logout if readable. A common mistake is to create a userlevel start up file as “root” - and forget to set the permissions correctly. At least the user should have execute and read permissions. Typically the permissions should be -rwxr-x--- (assuming the file is owned by the user).

If users complain that their shell does not recognize certain key strokes or reacts strangely on them, chances are that either the TERM variable does not match the (virtual) terminal type in use or the key bindings for the application (often a shell) are wrongly set. If the TERM setting is invalid the display will often be garbled too.

The behaviour of programs that use the readline library to fetch input from the keyboard are influenced by key bind settings. The readline library supports emacs and vi key bindings by default and allows you to configure key bindings to certain functions within applications, for example bash. If the shell variable INPUTRC is set (often in /etc/profile) key-bindings are set by the file declared in the its value. Otherwise the key-bindings are set in the file $HOME/.inputrc for each individual user, or system wide in the file /etc/inputrc. The syntax for controlling key bindings is simple. All that is required is the name of the command or the text of a macro and a key sequence to which it should be bound, see the manual pages for readline(3). bash allows the current key bindings to be displayed or modified with the bind builtin command. The editing mode bash uses may be switched during interactive use by using the set -o option, e.g. set -o vi. Often, the user sets his preference in one of the startup files. A simple typo there can result in eccentric behaviour of the shell (at least for that user).

The file /etc/login.defs (man login.defs(5)) defines the behaviour of login on the system on systems that use shadow passwords. With it, you control the behaviour of related programs too, for example chfn, chsh or groupadd. It is a plain text configuration file, used to set the initial PATH and other parameters, including how often a user must change passwords and what is acceptable as a password.

Many applications make use of other configuration files in the users HOME directory, for example:

It's easy for a user to overwrite (clobber) existing files when they are redirecting output to a file. To prevent this from happening to them you can set the noclobber setting by adding the line

set -o noclobber 

to their shell start-up file.

The Unix system engineer or system administrator can barely do his work without a proper editor. The definition of “proper editor” however is, and always has been, discussed at length. Roughly, there are two main stream editors available in the Unix world - thought strictly speaking one of them is far more than just an editor - emacs and vi.

vi - or one of its clones, for example the popular vim by Bram Molenaar, used on most Linux installations - is a crude, but effective editor. It supports an interface that allows you to keep your fingers on the keyboard all the time, and by design makes you use as less keys as possible. E.g. the use of arrow keys, function keys and other non standard keys is non-mandatory. This results in a steep learning curve for novice users but they gain a high return on that investment. They will be able to process texts faster and will be able to maintain an ergonomically acceptable working position. They will be able to work on even slightly defective keyboards/terminals. vi has limited functionality, but everything one needs to effectively and efficiently edit texts is available.

On the other side of the spectrum resides emacs. Strictly speaking, it is a text processing system. It makes use of ELISP programs to enhance its functionality. emacs also supports an interface that allows you to keep your fingers on the keyboard all the time. The amount of features and extensions emacs offers can initially be somewhat overwhelming, but it comes with excellent built in documentation. Additionally a lot of people wrote extensions for emacs. For example evi, which emulates vi within emacs.

Both emacs and vi are widely used, however, vi is much smaller in size than the complete emacs package. Hence, and given its longer history, vi is available on almost every Unix platform (including Linux) and on every Unix system. I therefore strongly suggest that novices start using vi for a while. It is omnipresent and will fit on a boot disk or rescue disk, with plenty of room to spare. Check out emacs if you need features like spell-checking or syntax highlighting. There is no reason not to use both applications, but as a system administrator you must know the vi basics, especially if you have to work on older systems. Many systems do not have emacs installed, most Linux systems do, however.

The sysctl command is used to modify kernel parameters at runtime. In Linux, it's a front end to the /proc filesystem, hence you should have compiled support for procfs if you want to use sysctl on Linux.

Typically you can read or set things like whether or not the kernel reacts to the three finger salute (ctrl+alt+del), the abilities of certain devices, such as your CDROM's ability to be able to close and open its tray, information about the way the kernel handles filesystem, such as the maximal number of inodes a filesystem can have, network information like whether or not the kernel should use IP forwarding, the kernel type and release and many, many more.

To see a list of all options available on your system you can issue the command

# sysctl -a |more

You will see a listing that could start like this:

# sysctl -a |more
sunrpc.nlm_debug = 0
sunrpc.nfsd_debug = 0
sunrpc.nfs_debug = 0
sunrpc.rpc_debug = 0
dev.cdrom.check_media = 0
dev.cdrom.lock = 1
dev.cdrom.debug = 0
dev.cdrom.autoeject = 0
dev.cdrom.autoclose = 1
dev.cdrom.info = CD-ROM information, Id: cdrom.c 3.11 2000/06/12
dev.cdrom.info =
dev.cdrom.info = drive name:            hdc
dev.cdrom.info = drive speed:           24
dev.cdrom.info = drive # of slots:      1
dev.cdrom.info = Can close tray:        1
dev.cdrom.info = Can open tray:         1
dev.cdrom.info = Can lock tray:         1
dev.cdrom.info = Can change speed:      1
dev.cdrom.info = Can select disk:       0
dev.cdrom.info = Can read multisession: 1
dev.cdrom.info = Can read MCN:          1
dev.cdrom.info = Reports media changed: 1
--More--                                    

As you can see, the variable names (a.k.a. key names) consist of dot delimited parts. Each part of a variable name correlates to a directory under the /proc/sys hierarchy, for example /proc/sys/dev/cdrom/info corresponds to dev.cdrom.info. An alternate method to set or read the variables is by using plain old cat, e.g. you can either type:

# cat /proc/sys/dev/cdrom/info

.. or ..

# sysctl dev.cdrom.info

Note, however, that sysctl will prepend the key name by default, use the -n option to suppress this. To confuse matters more, you are also allowed to use the “/” slash as a separator with sysctl, hence these two alternate forms are valid too:

# sysctl dev/cdrom/info
.. 
# sysctl /dev/cdrom/info
..

sysctl can load configuration files and set the kernel environment accordingly. The default location for the configuration file is /etc/sysctl.conf. Its syntax is simple: it contains simple token = value pairs, along with comment lines and/or blank lines. An example follows:

# sysctl.conf sample
#
kernel.domainname = yellow.snow.nl
net.ipv4.ip_forward = 0

This example just sets the domain name and disables IP forwarding. You can use the -p option to instruct sysctl to read this file (or specify another one to read). Note, that it is possible to put whitespace and other (unmeant) tokens in the right hand side of the expressions in the configuration file. Also note that you can use the /proc interface to influence these variables, for example:

# echo "/sbin/modprobe" >/proc/sys/kernel/modprobe

A library is an archive whose members are object files i.e., pre-compiled program code. A library makes it possible for a program to use common routines without the administrative overhead of maintaining source code. Additionally the objects in the library do not have to be compiled each time the program is compiled.

There are two types of libraries: static libraries and shared or dynamic libraries.

The term “static” refers to the fact that, when a static library is used whilst creating a program, the linker links in the relevant parts of the library statically, i.e., they become part of the resulting executable file. This consumes unnecessary memory and disk space since each new instance of a statically linked program loads parts of the same program-code its predecessors did. The exact same code will be on disk and in memory many times. Also, bug-fixing code in a statically linked library requires recompilation of all programs that use the older version of the statically linked program.

To improve this shared libraries were invented. When a program uses a shared library, the binary just contains a reference to the library, not the code itself. A special run time loader, ld.so (for a.out format files) or ld-linux.so (for ELF format files) finds the library at run-time and loads it into memory. Some additional naming conventions are used to allow real-time updates for shared libraries and support for non-backward-compatible versions. Understanding these conventions is key to your ability to maintain a Linux system.

Linker uses..                    Executable asks loader for..     Loader finds..               

+-linkname--------+              +-soname----------+              +-real name-------+ 
|                 |---symlink--->|                 |---symlink--->|                 |
| libfoo.so       |              | libfoo.so.1     |              | libfoo.so.1.0.4 |
+-----------------+              +-----------------+              +-----------------+

Linker uses..                Executable asks loader for..  Loader finds..               

+-linkname--------+          +-soname----------+           +-real name-------+ 
|                 |--------->|                 |---------->|                 |
| libfoo.so       |    ^     | libfoo.so.1     |    ^      | libfoo.so.1.0.4 |
+-----------------+    |     +-----------------+    |      +-----------------+
                       |                            |
                      symlink,                   symlink,
                   set up manually           set up by ldconfig

Linker uses..                Executable asks loader for..  Loader finds..               

+-linkname----+              +-soname----------+           +-real name-------+ 
|             |              |                 |-symlink-->|                 |
| libfoo.so   |              | libfoo.so.1     |           | libfoo.so.1.0.4 |
+-------------+              +-----------------+           +-----------------+
       | 
       |                     +-----------------+           +-----------------+ 
       +-----symlink-------->| libfoo.so.1.0.2 | ......... | libfoo.so.1.0.2 |
                             +-----------------+           +-----------------+

Linker uses..                Executable asks loader for..  Loader finds..               

                                                           +-real name-------+
                                                    +----->|                 |
                                                   /  ^    | libfoo.so.1.2.0 |
                                                  /   |    +-----------------+
+-linkname--------+          +-soname----------+ /    |    +-----------------+ 
|                 |-symlink->|                 |/     |    |                 |
| libfoo.so       |          | libfoo.so.1     |      |    | libfoo.so.1.0.4 |
+-----------------+          +-----------------+      |    +-----------------+
                                                      |
                                          symlink, set up by ldconfig

$ objdump -p /usr/lib/libesd.so.0.2.16 |grep SONAME
  SONAME      libesd.so.0
$_

# ldd /usr/bin/vim
        libncurses.so.5 => /lib/libncurses.so.5 (0x4001a000)
        libc.so.6 => /lib/libc.so.6 (0x40063000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
# _

gcc -shared -Wl,-soname,libjvc.so.1 -o libjvc.so.1.0.1 jvc.o
ln -sf libjvc.so.1.0.1 libjvc.so.1.0
ln -sf libjvc.so.1.0 libjvc.so.1
ln -sf libjvc.so.1 libjvc.so