Section 2.3. The Linux Filesystem | Run Your Own Web Server Using Linux & Apache

2.3. The Linux Filesystem

2.3.1. Drives and Partitions

If you're used to the drive-oriented layout of Windows, the Linux filesystem structure might be a bit confusing. There is no C: drive; in fact, there are no drives as such, only partitions. To muddy the waters a little more, the partitions' actual locations on the hard drive aren't identified clearly. The Linux filesystem is much more abstract than that.

Let me give you an example. My workhorse machine at home, cortex, contains two physical hard drives. One is an old 40GB drive that contains the operating system and all the programs I use. The other is a new, 160GB behemoth I added later, which is partitioned into two sections. The first section contains my personal files: the photos I've taken with my digital camera, my MP3 collection, and few odds and ends. I leave the second section free for temporary files created by my programs.

On a Windows system , these drives would most likely be seen by both the system and the user as C:, D: and E:. Windows would be installed at C:\WINDOWS\, Firefox would live in C:\Program Files\Mozilla Firefox\, my digital photos would reside in a directory called D:\Photos\, and so on. With Windows, the directory name is directly related to the partition, and therefore the hard disk, on which it's stored. This concept is illustrated in Figure 2-11.

Figure 2-11. How C:, D: and E: relate to my physical hard disks.

The Linux filesystem hides this unnecessary detail from you (until, of course, you want to see it). The operating system kernel is stored in a directory called /boot/, Firefox is in /usr/lib/firefox-1.0.4/, my photos and MP3s go into directories called /home/username/photos/ and /home/username/music/, and temporary files go into a directory called /tmp/. There are no obvious signs that these directories reside in different partitions or on different hard disks.

The Linux filesystem assigns each partition a different mount point : a directory through which we access the partition. In our example, the D: in Windows is analogous to /home/tony/ on our Linux system, E: is similar to /tmp/, and C: would be /, the top of the filesystem hierarchy. This structure is depicted in Figure 2-12.

Figure 2-12. The same partitions viewed in Linux.

There's no doubt that it's confusing when you first make the transition from the physical disk-oriented view of Windows to the hierarchical filesystem of Linux. In time, however, you get over the shock and start to see the sense in viewing the system holistically, rather than as separate compartments.

2.3.2. The ext3 Filesystem

Linux is deservedly renowned for its ability to work with many different filesystems. A modern Linux distribution will read, write, and keep track of files in nearly all the Microsoft filesystemsfrom the original FAT through to NTFSas well as filesystems used by Mac OS X, OS/2, and all sorts of esoteric operating systems. For Linux, it's a simple matter of loading the appropriate kernel module and mounting a partition. This makes it easy to handle files written on other systems on your Linux machine. In this section, we'll look at the filesystem that's native to your Fedora Core server: ext3.

The ext3 filesystem is an extension of the native Linux filesystem, ext2 , and is now the default filesystem for Fedora Core. ext3 extends ext2 with a journaling layer that facilitates quick system recovery, and ensures a high level of data integrity . The journal is constantly updated with notes of file actions that are pending, and those that have been completed.

Journaling protects against data corruption with speed and ease. All pending and completed operations are logged to the journal. The system checks the journal when rebooting , and completes those operations that were pending at the time of a system failure or "dirty shutdown." This protects the consistency of the data that was buffered at the time the system went down.

Recovery time is also decreased by the use of a journaling layer. Rather than checking each file, bit by bit, for consistency, the system merely completes any pending writes noted in the journal. This reduces what was once a 20- to 30-minute reboot operation to mere secondsan improvement that's especially critical in an enterprise environment.

Note: Other Linux distributions utilize different filesystems. SuSE Linux, for example, uses the ReiserFS filesystem by default. Extensive benchmarking has shown that ReiserFS can more efficiently handle large numbers of small files than can ext3. However, we won't have time to look at these other filesystems. If you'd like more information on the other filesystem options available for your Linux system, you can find a detailed list, descriptions and installation instructions online at Linux Gazette.

2.3.3. A Quick Tour of the Filesystem

The Linux filesystem depicted in Figure 2-13 has a different structure than you're probably used to. Let's look at an outline of the filesystem structure, and explore its various functions and elements.

/ (The Root Directory)

This is the top level of any Linux system, known as the root directory. Unfortunately, there's also a directory named root. Don't worry: we'll explain the difference between these directoriesand how to avoid confusionin a minute.

/boot

This directory contains all the files necessary to boot the operating system, including the Linux kernel.

/bin and /sbin

These folders are similar in their contentsthey both contain executable binary files but differ in purpose. /bin contains executables that you're likely to use from the command line: commands such as ls, mv, and cp, which we'll be looking at in Chapter 3, live in this folder. /sbin contains commands and processes that are used by the operating system itself, so it might be best to stay away from this folder if you're just starting out.

/dev

These are the device files abstractions of all the devices that are actually in the system, as well as all devices that could be added to the system. These files provide the operating system with a description of, and instructions for handling, each device.

/etc

This directory contains system-specific configuration files.

As an administrator, you're likely to spend quite a bit of time in the /etc directory, because it contains configuration instructions for most of the applications on the system. For example, the configuration file for Apache is located at /etc/httpd/conf/httpd.conf.

/home

This directory contains the home directories for each user of the system. For instance, our example user has the home directory /home/kermit, and other users on the same system have home directories /home/gonzo and /home/fozzie. By default, Gonzo or Fozzie can't read from or write to Kermit's files, and Kermit can't read from or write to theirs (only the root user has this ability).

/root (The root Directory)

This is the home directory of the root user, and is not to be confused with the other "root directory", /.

/lib

The /lib directory contains all the shared libraries that will be accessed by various applications in the system. It also contains libraries that will be used by the kernel in various system operations.

/media

/mnt

These directories serve as mount points for temporarily mounted filesystems. For example, the CD-ROM drive will be accessible from /media/cdrom.

/opt

This directory offers storage for packages that have been added to the system.

/tmp

This directory provides system-wide storage for temporary files.

/usr

Contains user commands and binaries, graphical interface files, include files for use in system applications, and optional source code files.

/var

The /var directory contains variable data files: files that may change during the operation of an application with which they're associated, including log files and mailbox files.

Tip: The concept of mount points may be a bit confusing, despite their existence in every operating system, including Windows. To avoid confusion, think of mount points as containers into which the contents of a device or filesystem will be emptied. For example, /media/cdrom is a mount point for the contents of the CD-ROM device. Emptying the contents of the device into the mount point makes the files accessible to the system and its users. In general, devices and filesystems must be mountedattached to a mount pointbefore they can be used. In a later chapter, we'll discuss a way by which we can mount these devices and filesystems automatically in Linux.

Figure 2-13. The Linux filesystem displaying in the File Browser application.

2.3.4.1. Navigating the Filesystem

Navigating the filesystem begins on the desktop with Nautilus , GNOME's graphical representation of the filesystem. There are two icons sitting on the desktop that act as starting points to Nautilus: Computer and username's Home, as shown in Figure 2-14.

Figure 2-14. The desktop filesystem icons.

The Computer icon begins at the top level of the system, similar to My Computer in Windows; while the username's Home icon begins within the current user's home directory.

Double-clicking the Computer icon presents us with a view similar to that shown in Figure 2-15. We see the removable media attached to the computer, as well as icons representing the root of the local filesystem and any other filesystems to which we have access over the network.

Double-clicking on the Filesystem icon opens a new window displaying the root directory of the filesystem, as shown in Figure 2-16. Double-clicking any of these icons will open another window, providing a view of the contents of the chosen directory, just like Windows Explorer or Finder on a Mac.

Figure 2-15. The Computer icon's top-level view.

Figure 2-16. Viewing the Computer icon filesystem.

Figure 2-17. The Home icon view.

Double-clicking on the username's Home icon on the desktop will jump straight to the current user's home directory. To start with, the home directory will only contain one visible folder icon, Desktop, as depicted in Figure 2-17.

2.3.4. Handling Linux Files

Literally everything in a Linux system is a file, including directories, links, and so on. Even the commands are files, ranging from the simple to the extremely complex. Because of the nature of the Linux system and its files, it's important to understand the processes of file handling and editing on your new system.

In this section, we'll take a quick spin through the file permissions structure, get a grip on the system's ability to link from one file to another, and explore some of the more common text editing applications for Linux. Because everything in Linux is a file, it's very important that you understand how files are accessed and edited. These are skills you'll find yourself using nearly every day.

2.3.5.2. File Permissions

Linux utilizes one of the most granular file permissions systems of any computer operating system. As we've already seen, that granularity is due, in part, to the fact that everything in Linux is a file. Commands, configurations, device files: all are editable, depending upon who the editing user is, and how the permissions on the file have been set. Accordingly, it's important to understand the permissions structure and how it will affect both your and your users' interaction with system files.

At their most basic, Linux permissions are broken into three sets of permissions. These are:

Owner (or user): The permissions granted to the user who owns the file (usually the user who created the file).
Group: The permissions granted to a specified group of users. Users can be added to any number of available groups, each of which can have permissions on files.
Other: The permissions granted to anyone who isn't the owner, or a member of a group that has permissions to access the file.

Each of these sets can grant any combination of the following, self-explanatory permissions:

read
write
execute

What's especially interesting in the Linux permissions structure is how these three sets of three permissions interact. A particular user may belong to a group that can only read a particular file, but if that user also happens to be the file's owner, the owner permissions of the file might also grant the user access to write to the file's contents.

Figure 2-18. Default permissions for a text file.

As an example, let's look at the default permissions structure of a simple text file. Open the gedit application by choosing Applications > Accessories > Text Editor from the menu. Enter some text into gedit, then save the file in your home directory. Locate the file in Nautilus, right-click on the file, and select Properties. Click the Permissions tab to see the permissions that have been given to the file as shown in Figure 2-18.

Let's take an in-depth look at this dialog.

File owner

This identifies the user who owns the file. By default, the owner is the user who created the file; however, a user that has sufficient privilegesroot, for examplecan change the file ownership details.

File group

The group of users that has access to this file: in this case, a group named kermit. When you create a user, Linux will automatically create a group with the same name as that user. This allows us to give a user access to another user's files. For example, if we added the user gonzo to the group kermit, Gonzo would have access to Kermit's files.

Owner, Group and Others

These checkboxes allow the actual setting of permissions. You can grant the owner, the group you've selected, or everyone else any combination of read, write, and/or execute permissions. That combination of three sections of three permission types results in 512 possible combinations for the permissions on this file. That's a pretty flexible structure! We'll look more closely at file permissions in a moment.

Special flags

Special extensions to the permissions system allow us to flag a file for special treatment by the filesystem. We won't need to use these flags within this book.

Text view and Number view

These alternative ways of viewing file permissions will be familiar to anyone who's dealt with file permissions via the command line.

The text view is made up of ten characters. The first indicates the file type: if the file is a directory, this character will be d; if the file is a regular file, it'll be -. The remaining nine characters indicate the read, write, and execute permissions for the owner, the group, and everyone else. For example, -rw-rw-r-- represents a regular file with read and write permissions for the owner, read and write permissions for the group, and read-only permission for everyone else. You can see this view change as you change the checkboxes above.

The number view is a more compact view of the text view. The numbers represent, from left to right, the permissions given to the owner, the group, and to everyone else. This view, too, changes as you change your selections in the checkboxes.

Last changed

This field identifies the date and time at which the file was last changed. As this file hasn't been reopened and modified, Linux doesn't consider it to be changed yet. Open the file and modify it to see this date change.

2.3.5. Symlinks, or Linking Files: More Abstraction

Most people who have ever worked with Windows understand the concept of shortcuts. A shortcut is really a pointer from one location to a file in another area of the system. In fact, some users understand and become so obsessed with shortcuts in Windows that their desktops are eventually covered with them! The ability to launch a file from somewhere other than its real location clearly has value for computer users. And Linux offers such capabilities, too. As an administrator, you'll find Linux's shortcuts nearly as exciting as those in Windows.

A shortcut in Windows and a symbolic link in Linux really amount to the same thing: they're abstractionsmere representationsof the original file. Creating a shortcut in Windows doesn't actually move the executable file to the desktop. Similarly, in Linux, we can write for a file an abstraction that appears to be the file itself. The file doesn't really exist in the new location, it just operates as if it does.

One important difference between the way Windows and Linux create shortcuts is that a Linux symbolic link (normally called a symlink) can be treated exactly as if it were the file for most purposes. For example, if you open a symlink in your editor, and make changes to the file, the editor will edit the actual file to which the symlink points. If you try that under Windows, you're likely to get a surprise when the editor opens up the shortcut file for editing, rather than the file that to which the shortcut links! Symlinks are used frequently under Linux because they're a powerful abstraction that can make it seem as if a file is in multiple places at once.

You can create a symbolic link in Nautilus by right-clicking on a file or folder, and selecting Make Link, as shown in Figure 2-19. This will create a symlink with "link to" at the start of the filename, as depicted in Figure 2-20. You can drag and drop this file anywhere, and rename it as you choose.

Figure 2-19. Creating a symlink in Nautilus.

Figure 2-20. A newly created symlink.

2.3.6. Editing Text Files

A reasonable command of a Linux-compatible text editor will be crucial to the success of your day-to-day administration. As most of the configuration in a Linux system is done via text files, you'd be wise to find one that works for you. In fact, Linux is replete with text editors: editors without a GUI, editors with a GUI, editors intended primarily for programmers, editors targeted at HTML developersthere's no shortage of tools to make your administrative tasks easier. In this section, we'll take a look at some of the GUI-based text editors that are available to you. We'll look at some of the command line-based editors a little later.

Fedora Core provides two robust GUI text editors in the default installation: gedit and Kate. gedit is the default text editor for the GNOME desktop environment, and Kate is the default for KDE , but both will work in either desktop environment.

If you were a longtime Notepad or Wordpad user in Windows, you'll find that many of the same features are available in Linux's GUI text editors, plus much, much more.

2.3.7.3. gedit

gedit is GNOME's default text editor. Pictured in Figure 2-21, it offers a full range of features, including:

Full support for internationalized text, including UTF-8
Tabbed multi-document interface
Syntax highlighting
Plugins and a plugin manager
A complete preferences interface

In addition to these standard features, the following plugins can be added to extend the gedit application:

Spell checker
Insert date and time
Word count
Change case of selected text
Indent or unindent blocks of text
Ascertain the differences between two documents or files
Insert output from the command line
Markup language tag lists for common markup languages such as HTML, LaTeX, etc.

Figure 2-21. The main gedit screen, ready to edit the Apache configuration file.

Tip: You'll quickly realize that most GUI applications for Linux are written specifically for one desktop environment or another. The naming conventions for these applications remain fairly consistent, and reasonably obvious. Most applications written for the GNOME desktop environment will begin with the letter "G," while applications written specifically for the KDE desktop environment will begin with the letter "K."

2.3.7.4. Kate

The KDE counterpart to gedit is Kate, the "KDE Advanced Text Editor," pictured in Figure 2-22. If it's not available in the Applications menu, you can start it by selecting Applications > Run Application… and entering kate.

Note: The Kate text editor, originally a standalone application, is now included in the kdebase package. It's not available as a separate download. In order to use Kate, you'll need to have all the KDE libraries and base applications installed. To install additional applications, select Desktop > System Settings > Add/Remove Applications.

Like gedit, Kate is a multi-view editor: it will allow you to open and edit multiple documents in the same window. As well as that single, very useful feature, Kate offers a full range of other capabilities that make it a very powerful text editor. Its features include:

Kate allows you to edit all kinds of text files, even if they're big. Kate can open a 50MB file in a few seconds.
Kate's powerful syntax highlighting engine is extensible via XML files.
The editor offers code folding capabilities for many programming languages, including: C++, C, PHP, etc.
Kate offers split window views, allowing you to view different parts of the document simultaneously.
Kate allows users to choose the encoding we want to use for each file via the save/open dialog.
Kate boasts built-in terminal emulation.
Kate's sidebar displays a list of open documents, a filesystem browser, and more.
Kate provides a handy plugin interface that allows third party plugins.
The editor provides project handling capabilities (which can be overridden by project handling plugins).

Figure 2-22. The main Kate screen, in which the Apache configuration file is being edited.

Ultimately , Kate is a bit more friendly, and offers greater flexibility for editing configuration files and writing shell scripts, than do some other editors. The syntax highlighting capabilities are unsurpassed, as Kate makes available a full range of programming languages and styles. Additionally, Kate provides such features as an open document listing (shown in Figure 2-23) and an integrated filesystem browser (Figure 2-24).

Figure 2-23. Kate's Documents tab.

While Linux does provide other GUI text editing options, gedit and Kate are two of the most powerful and user-friendly on offer. Either will suit your Linux text-editing purposes well.

Figure 2-24. Kate's Filesystem Browser tab.