Sharing NFS file systems

To share an NFS file system from your Red Hat Linux system, you need to export it. Exporting is done in Red Hat Linux by adding entries into the /etc/exports file. Each entry identifies the directory in your local file system that you want to share. The entry identifies the other computers that can share the resource (or opens it to all computers) and includes other options that reflect permissions associated with the directory.
Remember that when you share a directory, you are sharing all files and subdirectories below that directory as well (by default). So, you need to be sure that you want to share everything in that directory structure. There are still ways to restrict access within that directory structure.

Setting Up an NFS File Server in Red Hat Linux

Instead of representing storage devices as drive letters (A, B, C, and so on), as they are in Microsoft operating systems, Red Hat Linux connects file systems from multiple hard disks, floppy disks, CD−ROMs, and other local devices invisibly to form a single Linux file system. The Network File System (NFS) facility lets you extend your Red Hat Linux file system in the same way, to connect file systems on other computers to your local directory structure as well.
Creating an NFS file server is an easy way to share large amounts of data among the users and computers in an organization. An administrator of a Red Hat Linux system that is configured to share its file systems using NFS has several things to do to get NFS working:
1. Set up the network — If a LAN or other network connection is already connecting the computer on which you want to use NFS (using TCP/IP as the network transport), you already have the network you need.
2. On the server, choose what to share — Decide which file systems on your Linux NFS server you want to be available to other computers. You can choose any point in the file system to make all files and directories below that point accessible to other computers.
3. On the server, set up security — There are several different security features that you can use to suit the level of security with which you are comfortable. Mount−level security lets you restrict the computers that can mount a resource and, for those allowed to mount it, lets you specify whether it can be mounted read/write or read−only. With user−level security, you map users from the client systems to users on the NFS server. In this way, users can rely on standard Linux read/write/execute permissions, file ownership, and group permissions to access and protect files.
4. On the client, mount the file system — Each client computer that is allowed access to the server’s NFS shared file system can mount it anywhere the client chooses. For example, you may mount a file system from a computer called maple on the /mnt/maple directory in your local file system. After it is mounted, you can view the contents of that directory by typing ls /mnt/maple. Then you can use the cd command below the /mnt/maple mount point to see the files and directories it contains.
Although it is often used as a file server (or other type of server), Red Hat Linux is a general−purpose operating system. So, any Red Hat Linux system can share file systems (export) as a server or use other computer’s file systems (mount) as a client. Contrast this with dedicated file servers, such as NetWare, which can only share files with client computers (such as Windows workstations) and will never act as a client.
A file system is usually a structure of files and directories that exists on a single device (such as a hard disk partition or CD−ROM). When I talk about the Linux file system, however, I am referring to the entire directory structure (which may include file systems from several disks or NFS resources), beginning from root (/) on a single computer. A shared directory in NFS may represent all or part of a computer's file system, which can be attached (from the shared directory down the directory tree) to another computer's file system.

Run level directories

All of the programs within the /etc/rcX.d directories (where X is replaced by a run−level number) are symbolic links, usually to a file in /etc/init.d. The /etc/rcX.d directories include the following:
· /etc/rc0.d: Run level 0 directory
· /etc/rc1.d: Run level 1 directory
· /etc/rc2.d: Run level 2 directory
· /etc/rc3.d: Run level 3 directory
· /etc/rc4.d: Run level 4 directory
·/etc/rc5.d: Run level 5 directory

· /etc/rc6.d: Run level 6 directory

System Initialization

In the boot process, the transfer from the kernel phase (the loading of the kernel, probing for devices, and loading drivers) to init is indicated by the following lines:
INIT: version 2.78 booting
Welcome to Red Hat Linux
The init program, part of the SysVinit RPM package, is now in control. Known as “the father of all processes,” the output from ps always lists init as PID (process identifier) 1. Its actions are directed by the /etc/inittab file, which is reproduced next.

The following text shows the contents of the /etc/inittab file as it is delivered with Red Hat Linux:
#
# inittab This file describes how the INIT process should set up
the system in a certain run level.
#
# Author: Miquel van Smoorenburg,
# Modified for RHS Linux by Marc Ewing and Donnie Barnes
#
# Default runlevel. The runlevels used by RHS are:
# 0 − halt (Do NOT set initdefault to this)
# 1 − Single user mode
# 2 − Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 − Full multiuser mode
# 4 − unused
# 5 − X11
# 6 − reboot (Do NOT set initdefault to this)
#
id:3:initdefault:
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
l0:0:wait:/etc/rc.d/rc 0
l1:1:wait:/etc/rc.d/rc 1
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
# Things to run in every runlevel.
ud::once:/sbin/update
.
.
.
# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm −nodaemon

Administrative configuration files

Configuration files are another mainstay of Linux administration. Almost everything you set up for your particular computer — user accounts, network addresses, or GUI preferences — is stored in plain−text files. This has some advantages and some disadvantages.
The advantage of plain−text files is that it is easy to read and change them. Any text editor will do. On the downside, however, is that as you edit configuration files, no error checking is going on. You have to run the program that reads these files to find out if you set up the files correctly. A comma or a quote in the wrong place can sometimes cause a whole interface to fail.
There are several locations in the Red Hat Linux file system where configuration files are stored. Here are some of the major locations:
$HOME — All users store information in their home directories that directs how their login accounts behave. Most configuration files begin with a dot (.), so they don’t appear as a user’s directory when you use a standard ls command (you need to type ls −a to see them). There are dot files that define how each user’s shell behaves, the look and feel of the desktop, and what options are used with your text editor. There are even files (such as .rhosts) that configure network permissions for each user.
/etc — This contains many of the most basic Linux system configuration files.
Here are some /etc configuration files that are of interest:
aliases — Can contain distribution lists used by the Linux mail service.
crontab — Sets cron environment and times for running automated tasks.
exports — Contains a list of local directories that are available to be shared by remote computers using the Network File System (NFS).
fstab — Identifies the devices for common storage media (hard disk, floppy, CD−ROM, etc.) and locations where they are mounted in the Linux system. This is used by the mount command to choose which file systems to mount.
group — Identifies group names and group IDs (GIDs) that are defined on the systems. Group
permissions in Red Hat Linux are defined by the second of three sets of rwx (read, write, execute) bits associated with each file and directory.
host.conf — Sets the locations in which domain names (e.g., redhat.com) are searched for on TCP/IP networks (such as the Internet). By default, the local hosts file is searched, then any nameserver entries in resolv.conf.
hosts — Contains IP addresses and hostnames that you can reach from your computer. (Usually this file is used just to store names of computers on your LAN or larger private network.)
xinetd.conf — Contains simple configuration information used by the xinetd daemon process.
This file mostly points to the /etc/xinetd.d directory for information about individual services (described later).
info−dir — Contains the top heading for information that is available from the info command.
inittab — Contains information that defines what programs start and stop when Red Hat Linux boots, shuts down, or goes into different states in between.
lilo.conf — Sets various parameters used by the Linux boot loader (lilo) to boot your Linux system. In particular, it lists information about the bootable partitions on your computer. (If you are using grub, which has replaced lilo as the default boot manager, the lilo.conf file is not used.)
passwd — Stores account information for all valid users for the system. Also includes other information, such as the home directory and default shell.
rpmfind — Contains configuration information used by the rpmfind command to search for RPM software packages on the Internet.

services — Defines TCP/IP services and their port assignments.
shadow — Contains encrypted passwords for users that are defined in the passwd file. (This is
viewed as a more secure way to store passwords than the original encrypted password in the passwd file. The passwd file needs to be publicly readable, whereas the shadow file can be unreadable by all but the root user.)
shells — Lists the shell command line interpreters (bash, sh, csh, etc.) that are available on the system, as well as their locations.
/etc/httpd — Contains a variety of files used to configure the behavior of your Apache Web server (specifically, the httpd daemon process).
/etc/init.d — Contains the permanent copies of run−level scripts. These scripts are linked to files in the /etc/rc?.d directories to have each service associated with a script started or stopped for the particular run level. The ? is replaced by the run level number (0 through 6).
/etc/xinetd.d — Contains a set of files, each of which defines a network service that the xinetd
daemon listens for on a particular port. When the xinetd daemon process receives a request for a service, it uses the information in these files to determine which daemon processes to start to handle the request.