After you have installed SUSE Linux and created at least one user (yourself) on the system, you must log in. The standard login is pretty straightforward. By default, SUSE Linux boots to a KDE-based graphical login screen, known as the display manager. You enter your username (or click the icon representing you) and password and identify whether you want to start KDE, GNOME, some other X Window manager or a shell/command line (what appears in this drop-down menu is set by the Root user, so your options may differ). Press Enter to finish booting.

As the Internet has just a few specific but well-known top-level domains (.com, .net, .org, .edu, and the like), so are Linux files organized in a particular hierarchy, with specific directories that hold specific types of files.

Virtually all Linux distributions have the same structure, and this is likely to become more entrenched with the Linux Standard Base specifications becoming more universal. The Linux Standard Base (www.linuxbase.org) is an effort to make all Linux distributions more compatible with each other, and with most applications. SUSE is a longtime supporter of this effort, and has been compliant with LSB standards since LSB v1.0. In addition, the Filesystem Hierarchy Standard seeks specifically to standardize the contents of the top-level Unix/Linux directories. This structure is beautiful for software developers because they can know what directories will be present on each user’s machine and can install programs into the appropriate directory. It also enables programmers to build more modular programs, which depend on other standard libraries. It helps packaging systems—such as the Red Hat Package Manager (RPM) that SUSE uses—check and confirm that a file on which a package depends is present on a user’s system. Testing goes easier, too, because fewer things can go wrong.

We went over that structure briefly in Chapter 2, “Preparing to Install SUSE Linux.” To have another look and get your first lesson in using a shell, open the KDE Konsole and type ls /. You should see the following:

bin    dev    home    media    opt    root    srv    usr    windows
boot    etc    lib    mnt    proc    sbin    tmp    var

For a more detailed view of the file system from the shell, use the tree command. This program might not be installed by default, but it is on the CD-ROM. The results displayed by this program include all the top-level directories listed in “How to Partition Your Drive(s)” in Chapter 2, along with a few levels of subdirectories.

In Windows, you have the capability to create, delete, and rename as many top-level directories and subdirectories as you want, and very few bad things can happen to you as a result. Renaming the Program files or Windows directories would cause problems, but the system won’t come to a halt if you installed a program to a directory outside of Program files. Although you have the same technical ability to manipulate the directory structure in SUSE Linux, at least if you have Root privileges, don’t!

The sole exception to this otherwise ironclad rule is in your home directory. As a user, you can and should organize your documents and other data any way you see fit. You will see several recommendations in this book to put particular files and programs in your home directory because it can be the best place for them. If you find it useful, put every file you create in its own directory (although that might be a little extreme).

This recommendation extends to putting files of your own creation into one of the system directories. Say you create a text file that has a collection of tips and tricks you’ve learned about the bash shell over the years, called BashTips. Because you know that man pages and other documentation for bash goes in the /usr/share/doc/bash directory, you might be tempted to store the file there. No problem—unless somewhere down the road one of the developers or documentation writers adds a BashTips file to the bash package. When that file gets installed, your file is replaced with no questions asked, never to be recovered. No program will ever try to copy a file in your home directory, so put things that are yours there.

The /bin (short for binary)directory holds your shell applications and many essential shell commands you need when running and booting Linux. The /sbin (or system binary)directory contains the various installed file systems, YaST, the SUSE Firewall, and other commands needed at boot or for the Root user to solve systemwide problems. On the average system, each directory will have 5–8MB worth of files in them, with /sbin a little bit bigger than /bin. Many, if not all, of these commands are statically linked, not dependent on other software libraries located in other directories (mostly /lib and /usr/lib). Nearly every other application on your system relies on one or more of these external (or shared) libraries to run. These dynamically linked applications create a software ecosystem that ties an application to its operating system. Statically linked applications and commands, along with the kernel, represent the operating system itself.

The /boot directory contains a compressed version of the Linux kernel that loads at boot (earlier versions of the startup script delivered a message that the kernel was “exploding,” which undoubtedly unnerved more than a few novices in those days). When you rebuild or install a new kernel, the new kernel and related files go first into this directory (see Chapter 24, “Kernel and Module Management,” for more information on updating your kernel).

Linux device files are located in the /dev directory. As noted earlier, nearly everything in Linux is represented as a file. No further proof is needed than a peek into this directory. There you will find about 7,500 files representing devices that are or may some day be attached (or not) to your system. The more commonly used devices include the following:

If you’re running short of disk space, you might think cleaning out some of these files would help you. Closer inspection reveals that they are all 0byte files. Leave them alone.

One of the beauties of Linux applications is the way you can make software your own. Whether it’s changing the behavior of a command, adding a keyboard shortcut, or changing the color of the application title bar, there are lots of ways to make the applications you use work the way you want them to. Often, you don’t even have to open the application you want to modify to make the changes you want. Most applications store their configurations in a simple text file located in the /etc directory. Scroll through the directory to see exactly what is there. Check to see which user owns a file before trying to edit it—if Root owns the configuration file, you’ll have to log in as the SuperUser to make changes.

Some of the more important system-related configuration files in this directory are

Ultimately, the most important data on any computer belongs in this directory—the files you create for yourself. Every “real” (in contrast to a system) user on a Linux system gets a /home directory labeled with their username. That user has complete control over folders and files created in this directory and control over all access to those files except for the Root user.

In an effort to be helpful, SUSE Linux adds a few subdirectories to the /home directory by default:

You can work with these subdirectories, create more, delete some—your /home is your playground. But remember, back up your /home directory regularly. It’s designed for that.

The Filesystem Hierarchy Standard (FHS) says, “The /opt/ directory provides storage for large, static application software packages.” In practice, this seems to mean applications oriented to the desktop. Confined within /opt are all the built-in KDE and GNOME applications, Mozilla and its Firefox progeny, Softmaker Office files, and the Zope web application server. Depending on what you have installed, your mileage may vary.

The /usr directory is somewhat surprising when you look at it, because it has a parallel structure to the main (/) directory. This is why some folks give /usr its own mount point (that is, in DOS/Windows it would have its own drive letter). This directory is usually quite large (in the multigigabyte range, depending on how many applications you install) and contains many shared files and applications. It also houses the X Window System for graphical and remote computing. This directory is the place to start when looking for a particular application on your system, to handle troubleshooting, desktop icon placing, and everything in between.

The /var directory holds subdirectories used by various system services for spooling and logging. Some of the files in this directory are temporary, like a printer queue spooler file. System and kernel logs keep much longer and so are renamed and rotated through periodically. Incoming local email is usually directed to /var/spool/mail as well.

Linux also uses /var for other system services. YaST keeps backup boot sectors and YaST Online Update files, among other things, in /var/lib/YaST2. The RPM package database is also stored in /var/lib/rpm.

Unix was born in a multiuser environment at Bell Labs and was widely used in university computer science labs with a bunch of students floating in and out using whatever terminal was available. Defining users in a system was a necessity in the early days of Unix. As more users came on to systems with the advent of the PC, requiring users to log in was the touchstone of security measures. Today, because of viruses, worms, and assorted evildoers trying to break into networks almost constantly, named users and passwords are essential elements in any secure computing environment.

The Root user, who is responsible for all administrative tasks on the system, creates an account for each user. This involves assigning a username and creating an initial password for that user. You created the first user account for your system during the installation in Chapter 3, “Installing SUSE Linux.”

The Root user can delegate responsibilities to a single user or a group of users by sharing the Root password. Those users can then run the SuperUser program (su) to act as the Root user. You will learn more about SuperUsers in Chapter 19.

Individual users cannot change their usernames. System administrators of large user communities like to have some consistency in usernames, especially considering that a username is a central element of that user’s email address. Users can, however, change the information associated with their name and contained with your other login information in /etc/passwd and in your public “finger” file. This is generally phone-directory information that may need to be public, but that otherwise may be an artifact of a bygone era.

Finger was a program developed to help Unix users find each other, both electronically and physically. Typing finger <username> delivered whatever was in that user’s finger file. To see what’s in yours, type chfn (change finger information) at the shell prompt. By default, SUSE Linux does not create additional user information with new users, but it is easily configured by Root. You’ll see something like this:

Name:
Office:
Office Phone:
Home Phone:

You’re led through a series of prompts to enter new or updated information. Feel free to leave items blank (or change them appropriately).

The shell is perhaps the most underappreciated feature of a modern Linux system. New users try to avoid it, preferring the GUI tools that they are used to. Old-timers are wedded to the shell they learned at school. There’s no real reason to give the shell a second thought, is there? Of course there is!

By default, SUSE Linux (and pretty much all the other Linux distributions) installs the bash (Bourne Again SHell) shell as the standard command-line interface. There’s certainly no reason not to take this fine choice and run with it. But this is Linux, and there’s absolutely no reason not to explore some or all of the alternatives to bash included in SUSE Linux. This section will introduce you to these options, tell you how to change shells temporarily and permanently, and then offer pointers on how to use a shell productively.

#
# Colored file listings
#
if test -x /usr/bin/dircolors ; then
    #
    # set up the color-ls environment variables:
    #
    if test -f $HOME/.dir_colors ; then
    eval `dircolors -b $HOME/.dir_colors`
    elif test -f /etc/DIR_COLORS ; then
    eval 'dircolors -b /etc/DIR_COLORS'
    fi
fi

#
# Set some generic aliases
#

alias rd=rmdir
alias md='mkdir -p'
alias which='type -p'
alias rehash='hash -r'
alias you='yast2 online_update'

alias unmount='echo "Error: Try the command: umount" 1>&2; false'
test -s $HOME/.alias && . $HOME/.alias
fi

    # Do not save dupes and lines starting by space in the bash history file
    HISTCONTROL=ignoreboth
    if test "$is" = "ksh" ; then
    # Use a ksh specific history file and enable
        # emacs line editor
        HISTFILE=$HOME/.kshrc_history
        VISUAL=emacs
    fi
    ;;
esac

if test "$is" != "ash" ; then
    #
    # And now let's see if there is a local bash.bashrc
    # (for options defined by your sysadmin, not SuSE Linux)
    #
    test -s /etc/bash.bashrc.local && . /etc/bash.bashrc.local
fi

Managing Files with Midnight Commander

Whatever shell you choose for your everyday use, you may find the Midnight Commander a handy in-between tool for moving files around. In between? Suppose you don’t need to load a full GUI desktop to move a batch of files, but even all the wildcards and completion shortcuts offered by your shell won’t let you easily copy a set of files from different directories into one other directory. You need something else—something that will display two directories side by side and let you drag or move things from one place to another. You need Midnight Commander!

To open Midnight Commander, type mc at the shell prompt. Figure 5.1 shows the initial default display of your home directory on both sides of the screen. Use the arrow keys to navigate in the left pane. Use the Tab key to move from one side to the other, and then move around. Select a file or folder and press Enter to open that item. Mouse support is excellent; click any menu at the top to see your choices. Along the bottom are the F-key bindings: pressing F1 brings up the Help file, F2 displays a context-sensitive menu of choices for the selected file or directory, and so on.

Figure 5.1. The Midnight Commander shell.

To copy a set of documents with the .sxw extension from ~/documents to a directory on a remote server called /backup/mikemc, follow these steps:

1. In the left pane, use the arrow keys to navigate to the /Documents directory. Press Enter to open this directory.

2. Tab to the right pane. At the bottom of the Midnight Commander, you will see a flashing cursor. This is a shell prompt. Type cd /backup/mikemc to navigate to this directory. You could use the parent folders, marked .., to find the directory, but this is faster.

3. Tab back to the left pane. Press Alt-+ to open the Select Group dialog. Type *.sxw and press Enter to select all files with the .sxw extension.

4. Press F5 to open the Copy dialog box. Confirm that the correct files are going to the correct directory. Select any options you want by navigating with the Tab key and selecting with the spacebar. Press Enter to complete the operation.

Midnight Commander is a program ripe for exploration. The first few times you work with it, play around a little. Go to a menu, or press an F key to see what a command does.

The help files are indeed helpful! This is a full-featured file manager: View hidden files if you like, access FTP sites, and upload or download files (at the same time, if you want to), run executables, and change permissions (if you can) and owners with the ChMod and ChOwn commands. In short, just about everything you can do with a file in a shell, you can do with Midnight Commander. It even has a command history.

Tip

The KDE Konsole lets you open a new Midnight Commander session from the Session menu. Choose regular or Root (with your password).

Choosing a Shell

You now know a little bit about each shell. How do you decide which to use? The easiest thing is, of course, to stick with what you know. If you have used a shell before, there should be some compelling reason to switch. Similarly, if you don’t ever intend to do anything fancy with your shell, you might as well stick with bash. You can certainly do very fancy things with bash, but why change from the default?

Bash is also a great tool to learn scripting from. Resources abound on the Net to help you do that, and you’ll learn more about that in Chapter 8 as well. If you don’t want to write scripts, use an interactive shell such as tcsh, pd-ksh, or zsh.

If you are a lousy typist, you should certainly consider one of the shells with a spell checker. tcsh spell checks by default; zsh spell checks with a very quick configuration file edit. The fancier you want to get with file and command completion, the more you’ll probably want zsh.

As recommended at the beginning of this section, try out all the shells, at least once. All you have to do is type the name of the shell at any other shell prompt. When you’re done and want to return to bash, type exit. Look over the documentation. All the shells have extensive man or info pages. After you’ve settled on a shell, run the Change Shell (chsh) program to identify your choice. Then take some time to read those docs thoroughly.

Now that you’ve settled one of the interminable Linux wars to your satisfaction, you can choose a text editor.

Running YaST from the Shell

YaST is a tool older than most GUI desktop environments, and it runs beautifully from any shell. Log in as the SuperUser with the su command, and then type yast at the prompt. Figure 5.2 shows the opening screen in a KDE Konsole.

Figure 5.2. YaST works just as well from the shell as from a GUI environment.

This is especially useful in an emergency, when the system won’t boot to the GUI login screen. To restore your system from a previous backup (see Chapter 20, “Managing Data: Backup, Restoring, and Recovery,” for more information on backing up and restoring your system), follow these steps:

1. Run YaST by typing yast at the rescue prompt.

2. Use the arrow key to select System from the listing on the left.

3. Tab to the module section on the right, and then arrow down to Restore System.

4. Follow the instructions on the page or view details in the “Using System Restore” section of Chapter 20.

To maneuver around the menus and choices, use the accelerator keys highlighted on each screen. Press the Alt key with the highlighted letter to move to the item you want. For example, in any screen, press Alt+H to get Help on that screen. When finished, press Alt+Q to Quit and return to the shell prompt.

All YaST modules that are in the GUI version work in the command-line version as well, although Online Update (YOU) is dependent on the state of your Internet connection.

Because Unix and Linux are rooted in the hacker/geek/programmer culture, where coding was (and is) the most important function of any computer, having robust shells and editors were essential parts of the experience. It is no accident that Bill Joy wrote both the C shell and the vi editor, nor that Richard Stallman created the GNU Project and the emacs editor (and that each has completely different views about how to create and license software).

Of course, that was in the bygone early days of Unix. Why does it matter what text editor you should use now? And why do you need one, anyway? Consider this: Word processors are wonderful things, but often they are the very essence of overkill. One of the beauties of Linux is that nearly all the configuration and customization options for applications are contained in simple text files. This is true whether the program has a GUI or not. So making changes in the way a program works doesn’t necessarily have to require opening the program; just open the config file in a text editor!

There’s one other reason to be at least somewhat comfortable with at least one nongraphical editor. One of the truly cool things about Linux is the capability to access many different computers regardless of where you happen to physically be located at a given moment.

Remote access to other servers and workstations is another beauty of Linux, but most times, those remote machines (especially the servers) don’t even have X installed. To get any work done, you need a text editor.

SUSE Linux offers no fewer than 22 text editors through YaST, as shown in Table 5.1. Don’t be overwhelmed by the number of choices, though. Basically, text editors fall into one of two major camps: editors that behave like vi and editors that behave like emacs. This list also has a few line editors that work directly in the shell.

The next few sections will help you work with these various editors.

If there’s one thing that is important to know about Linux, it is that everything on your computer exists as a file. Your printer, sound card, hard-drive partitions, monitor, directories—a file on your system represents that item. And each file has rules about who can access it and in what manner.

In this section, you will get an introduction to permissions. This is covered in more depth in Chapter 19. No matter what your skill level is, you should read the “User Accounts and Permissions” section of that chapter.

Linux is a multiuser operating system, with a minimum of two users on any machine: the Root user and a “generic user.

Each file (again, that means everything on your system) has an owner and is assigned to a group when it is created. Read, write, and execute permissions are set for three types of user: Owner, group, and the rest of the world.

The ls -l (long format) directory listing command displays the permissions for each file. To see the system default permissions for a file, use the touch command to create an empty file and then run ls -l, like this:

touch file
mikemc@linux:~> ls -l file
-rw-r--r--    1 mikemc   users           0 2004-12-08 09:43 file

Looking at this listing, you see a 10-character block of dashes and letters (-rw-r--r--). These characters identify the permissions for this file.

The first character in the block indicates whether it is a special file in some way (d identifies it as a directory, c is for a character device, and b is for a block device, such as a hard drive). We know this is a plain data file because there is a dash, noting it is not any of these special types.

The default permissions for this file show us that the Owner of the file can Read and Write it (rw-); it is Read-Only (r--)for both the Group and Others (the rest of the world). If this was supposed to be an executable program file, a problem would exist, because no one has permission to execute it.

The next columns tell us other important things about this file:

You may better understand this as the number of copies of this file that exist on the system. Files almost always have just one link/copy. Directories nearly always have at least two because it is linked in its parent directory.

chown user2 file

chown user2 file*

chgrp writers file

chmod g+w file

chmod 664 file

drwxr-xr-x   64 mikemc   users        4056 2004-12-09 15:02

Permissions, more importantly the lack of them, mean a lot on a Linux (or Unix) system, especially if you’re “just a user.” Permissions are all about security—keeping the system safe from harm. In this case, harm can come from many directions. When you think about computer security, the vision that comes to your head is mostly likely that of the evil hacker who attempts to steal your passwords, credit card numbers, critical data, or even your identity. Security on the Internet is certainly an important consideration, and protecting your networks and systems against that type of criminal activity is essential.

In Linux and Unix, however, security and permissions also keep you from the more mundane harm and the bad things that can happen to any user at any time, such as the time you accidentally deleted an entire folder of documents relating to your company’s latest merger from your machine, and it took the IT staff a week to reconstruct it from backups.

As Root, you have inestimable power at your fingertips. You can keep the system humming, or you can bring it down with a few keystrokes. All you have to do to destroy a system is type this command (Don’t try this at home!):

rm -fr /

This command removes (rm) all files and directories recursively from the root of the tree. If you’re dual-booting with a mounted Windows partition, that partition will be gone, too. If you happen to be logged in to some remote machine somewhere that is now part of your system, it’s best to get on the phone now. The remote files are disappearing, too.

So don’t take chances. Even if you are the all-powerful Root on your machine, always log in as the humble user unless you have system work to do. Even though you can add the Root user to your SUSE Linux graphical Login screen, don’t. Save it for emergencies.

Now that you’re properly terrified, let me tell you that there are essential tasks that must be performed by the Root user. You can do these things safely, too. We will go into detail about many of these things in Parts 3 and 4, but for now here is a small list:

The best way to perform all these tasks is to use the su (SuperUser) command and type the Root password. You can do whatever tasks you need to, then return to the shell prompt, and type Exit to return to your user prompt.

As Root, you can allow specific users to perform specific tasks using the sudo command. This is described in detail in Chapter 19.

useradd drone77

passwd drone77
Changing password for user drone77
New password:
Retype new password:
passed: all authentication tokens updated successfully.

userdel -r drone77

shutdown -h now

shutdown -h 0

shutdown -h 18:30 "System is going down for maintenance this evening"

This chapter covered a lot of ground. The references will help you go into more depth on the Linux file system, shells, editors, and permissions. When choosing a shell or an editor, I highly recommend reviewing their man (or info) pages, as well as their websites.