Lesson 1: Chapter 2, Installation Overview; Chapter 11, Files, Directories,
and File Systems
Objectives:
This lesson reviews concepts from two chapters of the text. Objectives
important to this lesson:
Choosing a Linux distribution
Downloading an Live image or an ISO
Burning an ISO to a disc or a memory stick
Installing Linux and testing
Do not mount the Windows partition
in class labs
Important directories
Startup files
Network configuration files
Login configuration files
Device files
Seven file types
File system types
Concepts:
Chapter 2
Chapter 2 is pretty disjointed. The author throws in a section about
his font conventions that might have appeared in the foreword. We can
ignore that part and start our reading on page 29 with the material on
Planning the Installation. Note that that the author is writing the text
from the perspective of Fedora or RHEL (Red Hat Enterprise Linux), but
his advice throughout the text applies to other Linux distributions as
well.
With that in mind, the author presents a brief description of Fedora,
RHEL, and CentOS on page 33. Note that all are versions of Red Hat.
Fedora is easy to say, easy to install, but it has frequent updates
and releases, which make it a little unstable for an enterprise solution.
We can think of it as the tryout operating system that often has its
best features adopted by Red Hat. It is more cutting edge, so more likely
to have problems than Red Hat. This is kind of like "Red Hat Experimental".
Red Hat Enterprise Linux is often referred to as RHEL, mainly to save
typing. The text also refers to it as Red Hat. The main differences about
this one are that it costs money to install and use it, and it is meant
to be more reliable, less buggy, and more ready to be used as an enterprise
solution than the other Linux versions discussed in the text. This is
"Red Hat Official".
CentOS can be said a number of ways, and there seems to be little
agreement about which is correct. This video
clip seems pretty definitive, and it explains that CentOS is made
by the people who make Red Hat, it has fewer features, and it is free,
in the sense that does not cost the user anything. I know, that's what
most people would think the word free means with regard to a product,
but Linux is also free in the sense that it can be modified by the user.
They should use another label for that concept. User configurable, perhaps?
The text mentions that CentOS is unsupported, which means that it is
provided as is, and the publisher offers no warranty to users. This
could be considered "Red Hat Light".
In case you need to hear about other Linux distributions, take a few
minutes to look at the ten
on this video.
The text returns to Fedora to discuss three kinds of images you may want
to download from a reliable source, depending on your needs. Note that
all are available as ISO image files, so their formal names mean less
than you might think:
Fedora Desktop Live Media
- The text calls this one the Live
Image version. It can be put on a DVD or a USB stick (as long
as your computer can boot from one of those) and run without installing
it on a hard drive, which gives you a chance to try it out before you
commit a device to it. This may be one reason Red Hat is not available
this way, but Fedora is. If you are happy with the Live Image, you can
do a hard drive install from it. You can also just boot from this version
and run Fedora. The text notes that if you do so from a DVD, you will
not be able to save files, but you should be able to do so if you boot
from a USB device. The text gives us a URL to an article with instructions
for setting up a Live Image USB. Entering the URL took me to a different
(dead) site, but a Google search took me to the
right one.
Fedora DVD - The text tells
us that this version is also called Install
Media, but it prefers to call it an Install
Image, and that it does not have to be written to a DVD. Booting
from this version goes directly into an install process. Note the comment
in the text that you can install more options on this version than you
can when you install the Live Image version (described above) itself.
This version, and the Network version, also allow you to run a Rescue
a Fedora system session.
Fedora Network Install CD
- The text calls this version the Network
Image. The network part of this image is that the local files
are only the Anaconda installation utility (used by all versions for
a hard drive installation) and a capability to access the rest of the
install files across a network, usually the Internet. As noted above,
you can do a Rescue session with it, which makes sense because you will
have access to the same (or newer) installation files that are used
in the Install Image version. If the installation files are stored on
a local mirror, access to the Internet is not required for a network
installation, but access to the local store is required.
The text briefly discusses other versions of Fedora that are available,
which it call spins. You should run the Linux distributions video behind
the link above for a more varied presentation. Or just take what you are
given and do
what you need to do.
The text continues on page 36 with a discussion that loses me in the
second paragraph. Start with the third
paragraph, the one the defines a partition as "a logical section
of a hard disk" that has been given a device name. It is a physical
division of the hard drive, as well as a logical one. That paragraph mentions
several utilities that can be used to manage partitions after they are
created. Each hard drive must have at least one partition in order to
be used, and typically has one or more partitions for each operating system
installed on the drive.
In
the image on the right, a common Linux file structure is shown
on the left side of the picture, and a common Windows file
structure is shown on the right. In both cases there are icons
for devices and for folders, and if we opened a folder we would see icons
for files as well.. If you click the image, you will open a browser window
on a short article which introduces some of the concepts in this chapter.
The author of that article points out that the beginning of UNIX and Linux
file systems is always called the root, and is represented by the
slash, also called forward
slash character: /. The
slash is also used as a marker between directory names in a path to a
file. Note that UNIX/Linux systems use the slash for this purpose, but
Windows systems use the backslash:
\. Paths in URLs follow UNIX notation
perhaps because most servers on the Internet were running UNIX when the
Internet was created.
The text reminds us that folders are also called directories,
which you will need to know when creating, removing, or otherwise managing
them from a UNIX or Linux command line. Directories can, and often do,
contain other directories. These directories are in a parent/child
relationship, and the child can be called a subdirectory
with respect to its parent. We will talk more about folders and files
in a bit, but the text covers two other concepts first.
Before you can add a file system to a hard drive, you have to create
a partition on that drive to hold the file system. A partition
may be an entire hard drive or only a portion of it, which allows you
to create several partitions on a hard drive, within the limits discussed
below.
Partitions can be subdivided into volumes, which are logical
divisions of the partition. Volumes may also stand for devices or peripherals.
The text recommends that we use the LVM (Logical Volume Manager,
which is probably LVM2 on your system) utility to create, resize,
and manage volumes as needed. Use it to organize your folders and other
objects. Remember that there is, by default, only one file system tree
under Linux, so every volume will be on a branch of that same tree,
unless you use a utility like LVM to add new volumes that contain different
file systems. The text complicates this concept by introducing the term
namespace on page 37. For our purposes, a namespace is a file system.
All objects in a Linux/UNIX namespace must have unique names,
regardless of the volumes they are on, but LVM can make the Linux
namespace act more like a Windows namespace, in which objects are
only required to have names that are unique to their current volume.
On page 37, we get some of the bad news. Partitions are limited by rules
that were made long ago and far away, for DOS (Disk Operating System)
which was a big deal when it was created, but it seems very dated now.
Some rules about partitions:
a hard drive can have up to 63 partitions if it is an IDE,
ATA, or SATA drive
a hard drive can have up to 15 partitions if it is a SCSI drive
(which almost no one uses)
a hard drive can have up to 4primary partitions, and
you can only boot from primary partitions
you can only subdivide 1 of the primary partitions into logical
partitions, which makes it an extended partition; tricky part:
you can't actually store anything on the extended partition, but you
can store things on the logical partitions that are parts of it
The author advises us that a common partition scheme is to create three
primary partitions, sized according to expected need, and one extended
partition that takes up the rest of the hard drive, which can then be
subdivided as needed into logical partitions.
The text mentions mount points on page 38. Going into that for
a moment:
Partitions must be mounted to make them part of the file system.
The article linked above does a good job of explaining that UNIX and
Linux think every partition is part of the same file system tree. Here
is a quote that may make you want to read the article (nudge, nudge,
hint, hint). I have added bold to some of the author's text:
"The way Linux works is that it puts everything onto a tree.
If you have another partition or disk, it gets mounted as a branch
in a specific folder, usually /media or /mnt. The
directory that a partition gets mounted to is called a mount point.
This method works better with Linux's tree structure, and you can mount
partitions as folders nearly anywhere. In Windows, this is not so easily
done; new partitions generally show up as separate drives. In addition,
Linux can work with many more types of file systems natively than Windows."
This fits the illustration above. The admin for that system has created
a folder called mnt in which he has mounted partitions for the
floppy drive and the CD-ROM drive. These could have been mounted in
other locations, as were the music drive and the home
drive.
Having warned us for several pages that we need to think about space
when making partitions, we finally see some requirements and advice on
page 40.
You should have at least a root (/) partition, a /swap
partition for swap files, and a /home partition for user folders,
each having a separate file system. They should be sized for expected
growth in the operating system, changes in RAM, and changing needs of
users.
You should consider separate partitions for bits that change
frequently (e.g. data) and bits that do not change frequently
(e.g. programs), to reduce overall fragmentation. The text recommends
a /var partition for variable data, and separate folders for
data, mail, and print queues.
Placing a separate swap partition on each hard drive may improve
performance. The size of that partition should be determined by experience
with your users, your hardware, and your system. If you are unsure of
any of those, ignore the minimum sizes mentioned on page 40, and take
the advice in the same paragraph about making your swap partitions
one and a half times the size of the RAM on the device.
The text also recommends a /boot partition, for files required
to start the operating system, including the kernel. The text cautions
us to put this partition on the drive that is used to boot the system,
which I hope is obvious to you.
The text presents some material out of order on the next few pages:
The chapter closes with a check list of information you should
know about your hardware and your network before you do
the steps below starts on page 50.
A discussion about downloading installation files starts on
page 45.
Information about preparing a memory stick or a DVD as an installation
medium starts on the bottom of page 49 (there is a separate section
for each).
Information about performing an installation from a DVD or
a USB stick starts on page 44.
Chapter 11
The chapter begins with a discussion of files and directories commonly
used by a system administrator. It becomes incredibly dry within a few
pages. Browse through it, use it for reference, and note the highlights
below.
lost+found
- Assuming you know that the fsck
utility (see page 525) is used for file system checks and repairs, this
folder holds pointers to bad memory locations in the file system found
by fsck. It is important to have this folder because the fsck utility
would use the bad addresses again if it did not have a place to keep
track of them.
~/.bash_profile - Located in each user's home directory, this
script runs the login shell, which means that if the user's .bashrc
script exists, this script starts a bash shell and runs the .bashrc
script. This script is called when the user logs in to the system.
Note in the example shown on the right that this script also appends
two user related folders to the PATH variable, then exports that variable
to make it available to all shells that will be called in this session.
The text explains that other environment choices can be set in this
script for the user.
~/.bashrc - The text explains that this script runs every time
the user starts a new shell. It is automatically run by the script above
so that the user is in a shell when the session starts, but the important
thing is that it runs for the user automatically when a new shell opens.
/dev - A folder that holds drivers and pointers to drivers
for devices attached to the system.
/etc/hostname - This is file that stores the name of the system
(the computer being used).
/etc/hosts - Before the invention of DNS, this file was used
to hold device names, associated IP addresses , and aliases
for each device a system was expected to contact across an IP network.
The file still exists to enable a device to contact other devices by
hostname or alias when DNS and/or NIS are down, and to hold contact
information for devices that are not listed in DNS or NIS.
/etc/resolv.conf - This is a configuration file that provides
two kinds of information to the system.
The first line should begin with the word search, which is followed
by up to six domain names which are used by any domain resolver process,
such as that used by a web browser. This allows a user to enter a simple
object name in a browser's address line, and the browser then queries
DNS for the object in each of the named domains, one at a time, until
it finds a match or runs out of choices. This line may be omitted in
this file.
The second kind of information in this file begins on the second line,
or the first if there is no search line. Up to three lines may be included,
each of them holding the word nameserver, followed by a space,
then followed by the IP address of a preferred DNS or NIS server. The
servers in this list are queried in order, until a match is found, or
there are no more choices.
Moving on to page 514, there is a list of seven (or ten, or eleven...)
types of files that are supported by Linux. You should know something
about each type. The author seems to want to talk about most types in
each paragraph, which may make them seem more familiar to you by the end
of this section. Or it may just irritate you, as it did me.
Ordinary files, directories, links and inodes - Ordinary files
are most files created by users or applications, including executable
files and application data files. Directories are folders that files and other directories are
stored in. Inodes are information nodes, or index nodes. They are data structures
that hold information about, and point to, a files or a directories.
UNIX and Linux use inodes the same way that DOS and Windows use File
Allocation Table information to find files and note their size. Links, in the context of this section, are pointers to files,
and are associated with inodes. For a file's space to be release for
reuse by the system, all links to that file must be removed, making
the inode for that space available again.
Symbolic links - You could easily miss the text's discussion of this
one on page 515. Links to a file in it's own file system are
called hard links. Links to a file in another file system
are called symbolic links.
Device special files - Typically device special files are device
drivers, but this is also a category that includes other file types.
FIFO special files - Think of FIFO files as files that
represent memory locations in a system. They are shared by "otherwise
unrelated programs". A program can write information in these
files that other programs are allowed to access. For example, an
application can send a print job to a print queue file, which
is then read by a printer application which would remove the job
as it is handed to the actual printing device. A FIFO file can also
be called a named pipe.
Sockets - Unfortunately, the word socket has several definitions,
most of which are unrelated. In this case, a socket is like
an email ID that allows processes to exchange information with
each other directly, typically faster than a FIFO file, and
in full duplex.
Block and character devices - Block devices send their
output in blocks (clusters) of data. Character devices
send one character at a time, like a serial device..
Raw devices - The text explains that a raw device is an
access point to a device driver that allows utilities
to access the device without dealing with the actual block size
the device uses. The text uses fsck as an example of a program
that accesses devices (hard drives) by their raw device interface
to avoid the need to have a special driver for every kind of hard
drive.
The text presents a list on pages 519 and 520 of file systems that Linux
supports. This list is for reference. This section also reviews some commands
associated with file systems:
mount - to make a file system available
unmount - to remove a file system from the server
du - to display statistics on disk usage
fsck - to run a check and repair function on
an unmounted file system
Week 1 Assignments:
Assignment 1,Exercises from chapter 2:1, 2, 4, and 6.
Assignment 2, Exercises
from chapter 11: 1, 2, and 5.